Ämnets premiss
Det finns tre distinkta aspekter på en flerspråkig webbplats:
- gränssnittsöversättning
- innehåll
- url routing
Även om de alla är sammankopplade på olika sätt, hanteras de från CMS-synpunkt med hjälp av olika UI-element och lagras på olika sätt. Du verkar vara säker på din implementering och förståelse för de två första. Frågan gällde den senare aspekten - "URL-översättning? Ska vi göra detta eller inte? och på vilket sätt?"
Vad kan webbadressen vara gjord av?
En mycket viktig sak är att inte bli sugen på IDN . Föredrar istället translitteration (även:transkription och romanisering). Även om IDN vid första anblicken verkar fungerande alternativ för internationella webbadresser, fungerar det faktiskt inte som annonserat av två skäl:
- en del webbläsare kommer att ändra icke-ASCII-tecken som
'ч'eller'ž'till'%D1%87'och'%C5%BE' - om användaren har anpassade teman är det mycket troligt att temats teckensnitt inte har symboler för dessa bokstäver
Jag försökte faktiskt att närma mig IDN för några år sedan i ett Yii-baserat projekt (hemsk ram, IMHO). Jag stötte på båda de ovan nämnda problemen innan jag skrapade den lösningen. Jag misstänker också att det kan vara en attackvektor.
Tillgängliga alternativ ... som jag ser dem.
I grund och botten har du två val, som kan abstraheras som:
-
http://site.tld/[:query]:där[:query]avgör både språk- och innehållsval -
http://site.tld/[:language]/[:query]:där[:language]del av URL definierar valet av språk och[:query]används endast för att identifiera innehållet
Frågan är Α och Ω ..
Låt säga att du väljer http://site.tld/[:query] .
I så fall har du en primär språkkälla:innehållet i [:query] segmentet; och ytterligare två källor:
- värde
$_COOKIE['lang']för just den webbläsaren - lista över språk i HTTP Accept-Language header
Först måste du matcha frågan till ett av definierade routingmönster (om du väljer Laravel, läs här ). Vid framgångsrik matchning av mönstret måste du sedan hitta språket.
Du skulle behöva gå igenom alla segment i mönstret. Hitta potentiella översättningar för alla dessa segment och bestäm vilket språk som användes. De två ytterligare källorna (cookie och rubrik) skulle användas för att lösa routingkonflikter när (inte "om") de uppstår.
Ta till exempel:http://site.tld/blog/novinka .
Det är translitteration av "блог, новинка" , som på engelska betyder ungefär "blog", "latest" .
Som du redan kan märka kommer "блог" på ryska att translittereras till "blogg". Vilket betyder att för den första delen av [:query] dig (i bästa fall). ) kommer att sluta med ['en', 'ru'] lista över möjliga språk. Sedan tar du nästa segment - "novinka". Det kanske bara har ett språk på listan över möjligheter:['ru'] .
När listan har ett objekt har du hittat språket.
Men om du slutar med 2 (exempel:ryska och ukrainska) eller fler möjligheter .. eller 0 möjligheter, som ett fall kan vara. Du måste använda cookie och/eller rubrik för att hitta rätt alternativ.
Och om allt annat misslyckas väljer du webbplatsens standardspråk.
Språk som parameter
Alternativet är att använda URL, som kan definieras som http://site.tld/[:language]/[:query] . I det här fallet, när du översätter en fråga, behöver du inte gissa språket, eftersom du då redan vet vilket du ska använda.
Det finns också en sekundär språkkälla:cookievärdet. Men här är det ingen idé att bråka med Accept-Language header, eftersom du inte har att göra med ett okänt antal möjliga språk i händelse av "kallstart" (när användaren första gången öppnar webbplatsen med anpassad fråga).
Istället har du 3 enkla, prioriterade alternativ:
- om
[:language]segmentet är satt, använd det - om
$_COOKIE['lang']är inställd, använd den - använd standardspråk
När du har språket försöker du helt enkelt översätta frågan, och om översättningen misslyckas, använd "standardvärdet" för det specifika segmentet (baserat på routingresultat).
Finns inte här ett tredje alternativ?
Ja, tekniskt sett kan du kombinera båda tillvägagångssätten, men det skulle komplicera processen och bara ta emot personer som manuellt vill ändra webbadressen till http://site.tld/en/news till http://site.tld/de/news och förvänta dig att nyhetssidan ändras till tyska.
Men även detta fall skulle sannolikt kunna mildras med hjälp av cookie-värde (som skulle innehålla information om tidigare språkval), för att implementera med mindre magi och hopp.
Vilket tillvägagångssätt att använda?
Som du kanske redan gissat skulle jag rekommendera http://site.tld/[:language]/[:query] som det mer förnuftiga alternativet.
Även i riktiga ord-situationer skulle du ha tredje huvuddelen i URL:"titel". Som i namnet på produkten i onlinebutiken eller rubriken på artikeln på nyhetssajten.
Exempel:http://site.tld/en/news/article/121415/EU-as-global-reserve-currency
I det här fallet '/news/article/121415' skulle vara frågan och 'EU-as-global-reserve-currency' är titel. Enbart för SEO-ändamål.
Kan det göras i Laravel?
Lite, men inte som standard.
Jag är inte så bekant med det, men från vad jag har sett använder Laravel en enkel mönsterbaserad routingmekanism. För att implementera flerspråkiga webbadresser måste du förmodligen förlänga kärnklass(er) , eftersom flerspråkig routing behöver tillgång till olika former av lagring (databas, cache och/eller konfigurationsfiler).
Den är dirigerad. Vad nu?
Som ett resultat av allt skulle du få två värdefulla delar av information:aktuellt språk och översatta frågesegment. Dessa värden kan sedan användas för att skicka till den eller de klasser som kommer att producera resultatet.
I princip följande URL:http://site.tld/ru/blog/novinka (eller versionen utan '/ru' ) förvandlas till något liknande
$parameters = [
'language' => 'ru',
'classname' => 'blog',
'method' => 'latest',
];
Som du bara använder för att skicka:
$instance = new {$parameter['classname']};
$instance->{'get'.$parameters['method']}( $parameters );
.. eller någon variant av det, beroende på den specifika implementeringen.