Emnets forudsætning
Der er tre forskellige aspekter i et flersproget websted:
- grænsefladeoversættelse
- indhold
- url-routing
Mens de alle er forbundet på forskellige måder, styres de fra et CMS-synspunkt ved hjælp af forskellige UI-elementer og lagres forskelligt. Du ser ud til at være sikker på din implementering og forståelse af de to første. Spørgsmålet handlede om det sidste aspekt - "URL-oversættelse? Skal vi gøre dette eller ej? og på hvilken måde?"
Hvad kan URL'en være lavet af?
En meget vigtig ting er, ikke få lyst med IDN . Foretræk i stedet translitteration (også:transskription og romanisering). Selvom IDN ved første øjekast ser ud til at være en levedygtig mulighed for internationale URL'er, fungerer det faktisk ikke som annonceret af to grunde:
- nogle browsere vil ændre ikke-ASCII-tegn som
'ч'eller'ž'ind i'%D1%87'og'%C5%BE' - hvis brugeren har brugerdefinerede temaer, er det meget sandsynligt, at temaets skrifttype ikke har symboler for disse bogstaver
Jeg forsøgte faktisk at IDN-tilgange for nogle år siden i et Yii-baseret projekt (forfærdelig ramme, IMHO). Jeg stødte på begge de ovennævnte problemer, før jeg skrabede den løsning. Jeg formoder også, at det kan være en angrebsvektor.
Tilgængelige muligheder ... som jeg ser dem.
Grundlæggende har du to valg, der kunne abstraheres som:
-
http://site.tld/[:query]:hvor[:query]bestemmer både sprog- og indholdsvalg -
http://site.tld/[:language]/[:query]:hvor[:language]del af URL definerer valget af sprog og[:query]bruges kun til at identificere indholdet
Forespørgsel er Α og Ω ..
Lad os sige, at du vælger http://site.tld/[:query] .
I så fald har du én primær sprogkilde:indholdet af [:query] segment; og to yderligere kilder:
- værdi
$_COOKIE['lang']for den pågældende browser - liste over sprog i HTTP Accept-Language header
Først skal du matche forespørgslen til et af definerede routingmønstre (hvis dit valg er Laravel, så læs her ). Ved vellykket match af mønster skal du finde sproget.
Du skal gennemgå alle mønstrets segmenter. Find de potentielle oversættelser for alle disse segmenter, og find ud af, hvilket sprog der blev brugt. De to yderligere kilder (cookie og header) vil blive brugt til at løse routingkonflikter, når (ikke "hvis") de opstår.
Tag for eksempel:http://site.tld/blog/novinka .
Det er translitteration af "блог, новинка" , der på engelsk betyder cirka "blog", "latest" .
Som du allerede kan bemærke, vil "блог" på russisk blive translittereret til "blog". Hvilket betyder, at for den første del af [:query] dig (i bedste tilfælde). ) vil ende med ['en', 'ru'] liste over mulige sprog. Så tager du næste segment - "novinka". Det har måske kun ét sprog på listen over muligheder:['ru'] .
Når listen har ét element, har du fundet sproget.
Men hvis du ender med 2 (eksempel:russisk og ukrainsk) eller flere muligheder .. eller 0 muligheder, som et tilfælde kan være. Du bliver nødt til at bruge cookie og/eller header for at finde den rigtige mulighed.
Og hvis alt andet fejler, vælger du webstedets standardsprog.
Sprog som parameter
Alternativet er at bruge URL, der kan defineres som http://site.tld/[:language]/[:query] . I dette tilfælde behøver du ikke at gætte sproget, når du oversætter forespørgslen, for på det tidspunkt ved du allerede, hvilket du skal bruge.
Der er også en sekundær sprogkilde:cookieværdien. Men her er der ingen mening i at rode med Accept-Language header, fordi du ikke har at gøre med ukendt antal mulige sprog i tilfælde af "kold start" (når brugeren første gang åbner site med tilpasset forespørgsel).
I stedet har du 3 enkle, prioriterede muligheder:
- hvis
[:language]segment er indstillet, brug det - hvis
$_COOKIE['lang']er indstillet, skal du bruge det - brug standardsprog
Når du har sproget, forsøger du blot at oversætte forespørgslen, og hvis oversættelsen mislykkes, skal du bruge "standardværdien" for det pågældende segment (baseret på routingresultater).
Er her ikke en tredje mulighed?
Ja, teknisk set kan du kombinere begge tilgange, men det ville komplicere processen og kun rumme folk, der manuelt ønsker at ændre URL-adressen til http://site.tld/en/news til http://site.tld/de/news og forventer, at nyhedssiden skifter til tysk.
Men selv denne sag kunne sandsynligvis afbødes ved hjælp af cookieværdi (som ville indeholde oplysninger om tidligere valg af sprog), for at implementere med mindre magi og håb.
Hvilken tilgang skal jeg bruge?
Som du måske allerede har gættet, vil jeg anbefale http://site.tld/[:language]/[:query] som den mere fornuftige mulighed.
Også i virkelige ord-situationer ville du have 3. hoveddel i URL:"title". Som i navnet på produktet i online butik eller overskriften på artiklen på nyhedssiden.
Eksempel:http://site.tld/en/news/article/121415/EU-as-global-reserve-currency
I dette tilfælde '/news/article/121415' ville være forespørgslen og 'EU-as-global-reserve-currency' er titel. Rent til SEO-formål.
Kan det gøres i Laravel?
Lidt, men ikke som standard.
Jeg er ikke så bekendt med det, men fra hvad jeg har set, bruger Laravel en simpel mønsterbaseret routingmekanisme. For at implementere flersprogede URL'er skal du sandsynligvis udvide kerneklass(er) , fordi flersproget routing kræver adgang til forskellige former for lagring (database, cache og/eller konfigurationsfiler).
Den er dirigeret. Hvad nu?
Som et resultat af alt ville du ende med to værdifulde oplysninger:det aktuelle sprog og oversatte forespørgselssegmenter. Disse værdier kan derefter bruges til at sende til klassen/klasserne, som vil producere resultatet.
Grundlæggende er følgende URL:http://site.tld/ru/blog/novinka (eller versionen uden '/ru' ) bliver forvandlet til noget lignende
$parameters = [
'language' => 'ru',
'classname' => 'blog',
'method' => 'latest',
];
Som du bare bruger til afsendelse:
$instance = new {$parameter['classname']};
$instance->{'get'.$parameters['method']}( $parameters );
.. eller en variation af det, afhængigt af den særlige implementering.