URL-Format für internationalisierte Web-App?

Ich würde nicht Option 1 wählen, wenn Ihre Seiten öffentlich verfügbar sind, d. h. Sie müssen sich nicht anmelden, um die Seiten anzuzeigen. Der Grund ist, dass eine Suchmaschine die verschiedenen Sprachversionen der Seite nicht scannt. Der gleiche Grund gilt für die Option Nr. 5. Eine Suchmaschine identifiziert zwei Seiten weniger als separate Seiten, wenn die Sprachidentifikation in die Abfragezeichenfolge aufgenommen wird.

Sehen wir uns Option 4 an und platzieren die Sprache im Hostnamen. Ich würde diese Option verwenden, wenn die verschiedenen Sprachversionen der Website völlig unterschiedliche Inhalte enthalten. Auf einer Website wie Wikipedia zum Beispiel enthält die griechische Version einen eigenen vollständigen Satz von Artikeln, und die englische Version enthält einen weiteren Satz von Artikeln.

Wenn Sie also keinen komplett anderen Inhalt haben (was in Ihrem Post nicht so aussieht), bleiben Sie bei Option 2 oder 3. Ich weiß nicht, ob es überzeugende Argumente für einen über den andere, aber nein. 3 sieht in meinen Augen schöner aus. Also das würde ich verwenden.

Aber nur ein Kommentar zur Inspiration. Ich arbeite derzeit an einer Webanwendung, die aus drei Hauptteilen, einem öffentlichen und zwei Teilen für zwei verschiedene Benutzertypen besteht. Ich habe das folgende URL-Schema gewählt (natürlich mit Bezug auf die Sprache):

Der Grund dafür ist, dass wenn ich die drei Teile in separate Anwendungen aufteilen würde, es eine einfache Neukonfiguration im Webserver wäre, wenn ich den Namen des Teils oben auf dem Pfad hätte. Z.B. wenn wir ein kommerzielles CMS-System für den öffentlichen Teil der Website verwenden würden

Bearbeiten: Ein weiteres Argument gegen Option Nr. Wenn Sie nur die Sprache akzeptieren, geben Sie dem Benutzer keine Wahl. Der Benutzer kann möglicherweise nicht wissen, wie die in einem Browser eingerichtete Sprache geändert wird, oder er verwendet eine frinds-Computereinrichtung für eine andere Sprache. Sie sollten dem Benutzer zumindest eine Auswahlmöglichkeit geben (Speichern in einem Cookie oder im Benutzerprofil).

Ich würde Nummer 3 wählen und auf http://example.com/el/folder/page umleiten, weil:

1. Die Sprachauswahl ist wichtiger als eine Seitenauswahl, daher sollte die ausgewählte Sprache zuerst in einer echten visuell lesbaren URL angezeigt werden.
2. Nur eine Domain erhält alle PRs von Google. Das ist gut für SEO.
3. Sie können Ihre Website lokal mit einem integrierten Sprachencode anzeigen. Z.B. In Griechenland würden Sie als http://example.com/el/ anzeigen, so dass jeder lokale Besucher auf eine Website in Griechenland gelangt und eine Sprache vermeiden würde, die Frustration auswählt.

Alternativ können Sie auch die Nummer 5 verwenden: Für Google und Freunde ist dies in Ordnung, für einen Nutzer jedoch nicht so nett.

Wir sollten es auch unterlassen, einen Benutzer irgendwo umzuleiten, wenn dies nicht erforderlich ist. Aus diesem Grund sollte ein Benutzer, der http://example.com/folder/page öffnet, keine Umleitung, sondern eine Seite in einer Standardsprache erhalten.

Nummer vier ist die beste Option, weil sie den Sprachencode ziemlich früh festlegt. Wenn Sie Weiterleitungen bereitstellen möchten, verwenden Sie immer ein kanonisches Link-Tag.

Wählen Sie Option 5, und ich glaube nicht, dass es schlecht für SEO ist.

Diese Option ist gut, weil es zeigt, dass der Inhalt für sagen:
http://domain.com/about/corporate/locations ist der gleiche wie der Inhalt in
http://domain.com/about/corporate/locations?hl=el mit der Ausnahme, dass die Sprache unterschiedlich ist.
Der Parameter hl sollte den Header Accept-language überschreiben, damit der Benutzer die Angelegenheit leicht steuern kann. Der Header würde nur verwendet werden, wenn der Parameter hl fehlt. Das Verlinken gestaltet sich dadurch etwas komplizierter und sollte wahrscheinlich durch einen Cookie behoben werden, der die Umleitung auf die vom Parameter hl gewählte Sprache beschränkt (da sie möglicherweise vom Benutzer aus der Einstellung Accept-language geändert wurde) oder indem alle Links auf der Seite verarbeitet werden, um den aktuellen hl -Parameter hinzuzufügen.

Die SEO-Probleme können durch Erstellen von Indexdateien für alles wie stackoverflow behoben werden, diese könnten mehrere Sätze von Indizes für die verschiedenen Sprachen enthalten, was hoffentlich dazu führt, dass Ergebnisse in der Nicht-Standardsprache angezeigt werden.

Die Verwendung von 1 nimmt das Unterscheidungsmerkmal in der URL weg. Die Verwendung von 2 und 3 legt nahe, dass die Seite anders ist, möglicherweise über die Sprache hinaus, wie Wikipedia es ist. Und die Verwendung von 4 legt nahe, dass der Server selbst getrennt ist, vielleicht sogar geografisch.

Da es eine überraschend geringe Korrelation zwischen dem geografischen Standort und den Spracheinstellungen gibt, sollte das Problem der Bereitstellung geografisch naher Server einem richtigen CDN-Setup überlassen werden.

Meine eigene Wahl ist # 3: http://domain.com/el/folder/page . Es scheint das populärste da draußen im Internet zu sein. Alle anderen Alternativen haben Probleme:

1. http://domain.com/folder/page --- Schlecht für SEO?
2. http://domain.com/folder/page/el --- Funktioniert nicht für Seiten mit Parametern. Das sieht seltsam aus: ... page? Par1 = x & amp; par2 = y / el
3. http://domain.com/el/folder/page --- Sieht gut aus!
4. http://el.domain.com/folder/page --- Für die Bereitstellung ist mehr Arbeit erforderlich, da Subdomänen hinzugefügt werden müssen.
5. http://domain.com/folder/page?hl=el --- Schlecht für SEO?

Es kommt darauf an. Ich würde Nummer vier persönlich wählen, aber viele erfolgreiche Unternehmen haben unterschiedliche Möglichkeiten, dies zu erreichen.

• Wikipedia verwendet Subdomains für verschiedene Sprachen (el.wikipedia.org).
  • Also Yahoo (es.yahoo.com für Spanisch), obwohl es kein Griechisch unterstützt.
  • Auch Gravatar (el.gravatar.com)
• Google verwendet ein Verzeichnis / intl / el /.
• Apple verwendet ein / gr / -Verzeichnis (wenn auch in Englisch und auf eine iPhone-Seite beschränkt)

Es liegt wirklich an dir. Was werden Ihrer Meinung nach Ihre Kunden am meisten mögen?

Keine von ihnen. Ein 'normaler Benutzer' würde diese Abkürzungen nicht verstehen (und sich daran erinnern).

In der Reihenfolge der Präferenz würde ich vorschlagen:

1. Ссылка
2. Ссылка
3. Ссылка

3 oder 4.

3: Kann leicht mit htaccess / mod_rewrite behandelt werden. Der einzige Nachteil ist, dass Sie eine Methode schreiben müssen, um automatisch den Sprachcode als erstes Segment des URIs einzufügen.

4: Wahrscheinlich die beste Methode. Mit Host-Headern kann alles an die gleiche Webanwendung / den gleichen Webinhalt gesendet werden, aber Sie können dann Code verwenden, um den Sprachcode zu extrahieren und von dort aus zu gehen.

Einfach. ;)

Ich bevorzuge 3 oder 4