Mysql
 sql >> Datenbank >  >> RDS >> Mysql

Mehrsprachige Best-Practice-Website

Prämisse des Themas

Es gibt drei unterschiedliche Aspekte in einer mehrsprachigen Website:

  • Schnittstellenübersetzung
  • Inhalt
  • URL-Routing

Obwohl sie alle auf unterschiedliche Weise miteinander verbunden sind, werden sie aus CMS-Sicht mit unterschiedlichen UI-Elementen verwaltet und unterschiedlich gespeichert. Sie scheinen von Ihrer Umsetzung und Ihrem Verständnis der ersten beiden überzeugt zu sein. Die Frage bezog sich auf letzteren Aspekt - "URL-Übersetzung? Sollen wir das tun oder nicht? Und auf welche Weise?"

Aus was kann die URL bestehen?

Eine sehr wichtige Sache ist, sich nicht mit IDN zu beschäftigen . Bevorzugen Sie stattdessen Transliteration (auch:Transkription und Romanisierung). Während IDN auf den ersten Blick eine praktikable Option für internationale URLs zu sein scheint, funktioniert es tatsächlich aus zwei Gründen nicht wie beworben:

  • Einige Browser verwandeln Nicht-ASCII-Zeichen in 'ч' oder 'ž' in '%D1%87' und '%C5%BE'
  • Wenn der Benutzer benutzerdefinierte Designs hat, enthält die Schriftart des Designs höchstwahrscheinlich keine Symbole für diese Buchstaben

Ich habe vor einigen Jahren in einem Yii-basierten Projekt (schreckliches Framework, IMHO) versucht, einen IDN-Ansatz zu verwenden. Ich bin auf beide oben genannten Probleme gestoßen, bevor ich diese Lösung abgekratzt habe. Außerdem vermute ich, dass es sich um einen Angriffsvektor handeln könnte.

Verfügbare Optionen ... wie ich sie sehe.

Grundsätzlich haben Sie zwei Möglichkeiten, die wie folgt abstrahiert werden könnten:

  • http://site.tld/[:query] :wobei [:query] bestimmt sowohl die Sprach- als auch die Inhaltswahl

  • http://site.tld/[:language]/[:query] :wobei [:language] Teil der URL definiert die Wahl der Sprache und [:query] dient nur zur Identifizierung des Inhalts

Abfrage ist Α und Ω ..

Nehmen wir an, Sie wählen http://site.tld/[:query] .

In diesem Fall haben Sie eine primäre Sprachquelle:den Inhalt von [:query] Segment; und zwei weitere Quellen:

  • Wert $_COOKIE['lang'] für diesen bestimmten Browser
  • Liste der Sprachen im HTTP-Accept-Language-Header

Zuerst müssen Sie die Abfrage einem der definierten Routing-Muster zuordnen (wenn Sie Laravel auswählen, dann hier lesen ). Bei erfolgreicher Übereinstimmung des Musters müssen Sie dann die Sprache finden.

Sie müssten alle Segmente des Musters durchlaufen. Finden Sie die möglichen Übersetzungen für all diese Segmente und bestimmen Sie, welche Sprache verwendet wurde. Die beiden zusätzlichen Quellen (Cookie und Header) würden verwendet, um Routing-Konflikte zu lösen, wenn (nicht "wenn") sie auftreten.

Nehmen Sie zum Beispiel:http://site.tld/blog/novinka .

Das ist die Transliteration von "блог, новинка" , das bedeutet auf Englisch ungefähr "blog", "latest" .

Wie Sie bereits sehen können, wird „блог“ im Russischen mit „Blog“ transkribiert. Das bedeutet für den ersten Teil von [:query] Sie (im besten Fall ) endet mit ['en', 'ru'] Liste der möglichen Sprachen. Dann nehmen Sie das nächste Segment - "novinka". Das könnte nur eine Sprache auf der Liste der Möglichkeiten haben:['ru'] .

Wenn die Liste einen Eintrag enthält, haben Sie die Sprache erfolgreich gefunden.

Aber wenn Sie am Ende 2 (Beispiel:Russisch und Ukrainisch) oder mehr Möglichkeiten haben ... oder 0 Möglichkeiten, je nach Fall. Sie müssen Cookies und/oder Header verwenden, um die richtige Option zu finden.

Und wenn alles andere fehlschlägt, wählen Sie die Standardsprache der Website aus.

Sprache als Parameter

Die Alternative ist die Verwendung einer URL, die als http://site.tld/[:language]/[:query] definiert werden kann . In diesem Fall müssen Sie beim Übersetzen der Abfrage die Sprache nicht erraten, da Sie zu diesem Zeitpunkt bereits wissen, welche zu verwenden ist.

Es gibt auch eine sekundäre Sprachquelle:den Cookie-Wert. Aber hier macht es keinen Sinn, sich mit dem Accept-Language-Header herumzuschlagen, da Sie es im Falle eines "Kaltstarts" (wenn der Benutzer die Site zum ersten Mal mit einer benutzerdefinierten Abfrage öffnet) nicht mit einer unbekannten Anzahl möglicher Sprachen zu tun haben.

Stattdessen haben Sie 3 einfache, priorisierte Optionen:

  1. wenn [:language] Segment gesetzt ist, verwenden Sie es
  2. if $_COOKIE['lang'] gesetzt ist, verwenden Sie es
  3. Standardsprache verwenden

Wenn Sie die Sprache haben, versuchen Sie einfach, die Abfrage zu übersetzen, und wenn die Übersetzung fehlschlägt, verwenden Sie den "Standardwert" für dieses bestimmte Segment (basierend auf den Routing-Ergebnissen).

Gibt es hier nicht eine dritte Option?

Ja, technisch gesehen können Sie beide Ansätze kombinieren, aber das würde den Prozess verkomplizieren und nur Personen entgegenkommen, die die URL von http://site.tld/en/news manuell ändern möchten zu http://site.tld/de/news und erwarten, dass die Nachrichtenseite auf Deutsch wechselt.

Aber selbst dieser Fall könnte wahrscheinlich mit einem Cookie-Wert (der Informationen über die vorherige Sprachwahl enthalten würde) abgemildert werden, um ihn mit weniger Magie und Hoffnung zu implementieren.

Welcher Ansatz soll verwendet werden?

Wie Sie vielleicht schon erraten haben, würde ich http://site.tld/[:language]/[:query] empfehlen als die sinnvollere Variante.

Auch in einer realen Wortsituation hätten Sie einen 3. Hauptteil in der URL:"Titel". Wie im Namen des Produkts im Online-Shop oder in der Überschrift des Artikels auf der Nachrichtenseite.

Beispiel:http://site.tld/en/news/article/121415/EU-as-global-reserve-currency

In diesem Fall '/news/article/121415' wäre die Abfrage und der 'EU-as-global-reserve-currency' ist Titel. Rein für SEO-Zwecke.

Kann es in Laravel gemacht werden?

Irgendwie, aber nicht standardmäßig.

Ich bin damit nicht allzu vertraut, aber nach dem, was ich gesehen habe, verwendet Laravel einen einfachen musterbasierten Routing-Mechanismus. Um mehrsprachige URLs zu implementieren, müssen Sie wahrscheinlich Kernklasse(n) erweitern , da mehrsprachiges Routing Zugriff auf verschiedene Speicherformen (Datenbank, Cache und/oder Konfigurationsdateien) benötigt.

Es wird weitergeleitet. Was nun?

Als Ergebnis erhalten Sie zwei wertvolle Informationen:aktuelle Sprache und übersetzte Segmente der Anfrage. Diese Werte können dann verwendet werden, um an die Klasse(n) zu senden, die das Ergebnis erzeugen.

Grundsätzlich die folgende URL:http://site.tld/ru/blog/novinka (oder die Version ohne '/ru' ) wird in so etwas wie

umgewandelt 
$parameters = [
   'language' => 'ru',
   'classname' => 'blog',
   'method' => 'latest',
];

Was Sie nur zum Versenden verwenden:

$instance = new {$parameter['classname']};
$instance->{'get'.$parameters['method']}( $parameters );

.. oder eine Variation davon, abhängig von der jeweiligen Implementierung.