Dan’s Web Tipps

Sprachen

Deutsche Übersetzung von Worldliterate.com – Originaltext: https://webtips.dan.info/language.html | Alle Rechte vorbehalten © 2018

Sprachen

[<== Zurück] | [Nach oben] | [Weiter ==>]

Da “World Wide” Teil des Namens des Webs ist, war es nie als Medium auf Englisch gedacht. Sie können jede Sprache in Ihren Websites verwenden, und den Standards des Webs wurden verschiedene Funktionen hinzugefügt, damit Sie angeben können, welche Sprachen Sie zum Nutzen von Indexern und Übersetzern verwenden und sogar verschiedene Sprachversionen Ihres Seiten entsprechend den Benutzereinstellungen. Diese Seite beschreibt einige dieser Techniken.

Die hier betrachteten “Sprachen” sind menschliche Sprachen wie Spanisch und Mandarin, keine Computersprachen wie HTML und JavaScript. Welche Computersprachen Sie auf Ihrer Website verwenden, ist ebenfalls eine wichtige Wahl, aber das ist nicht das Thema dieses Artikels!

Anzeigesprache

HTML gibt Ihnen die Möglichkeit, ein Dokument oder einen Teil davon mit der Sprache zu versehen, in der es geschrieben ist. Dies geschieht mit dem LANGAttribut, das in fast jedem Tag platziert werden kann.

Um anzuzeigen, dass die gesamte Seite in Englisch ist, würden Sie dies am Anfang in das HTML- Tag einfügen:

<HTML lang="en">

Der Wert des Attributs ist der Code für die Sprache, in der sich das Dokument befindet. Die meisten der gebräuchlichen Sprachen der Welt haben Zwei-Buchstaben-Codes (definiert in der Norm ISO 639-1) und eine größere Liste (einschließlich “toter” Sprachen) ) haben Drei-Buchstaben-Codes (in ISO 639-2). RFC 3066 besagt, dass der Zwei-Buchstaben-Code gegenüber dem Drei-Buchstaben-Code verwendet werden muss, wenn einer existiert, so dass normalerweise nur Zwei-Buchstaben-Codes in Web-Sprachattributen gefunden werden. Hier und hier sind einige Hinweise auf die Zwei-Buchstaben-Codes.

Um einen bestimmten Dialekt zu spezifizieren, kann einem Sprachcode ein Bindestrich und ein zusätzlicher Code, oft ein Ländercode, hinzugefügt werden. Wenn dies erfolgt ist, wird der Basissprachcode traditionell in Kleinbuchstaben und der Suffix-Ländercode in Großbuchstaben angegeben (obwohl dies nicht erforderlich ist; die Codes unterscheiden nicht zwischen Groß- und Kleinschreibung). So kann amerikanisches Englisch als en-USund britisches Englisch als angegeben werden en-GB. (Beachten Sie, dass GBist der richtige Ländercode für das Vereinigte Königreich, nicht UK, obwohl .uk das dort verwendete Domain – Suffix ist. In anderen Fällen jedoch der Standard – Ländercode stimmt mit der Land-Code – Domain für ein bestimmtes Land.) es-MXIst der Code für mexikanisches Spanisch. Nicht-nationale Dialekte können durch ihre vollständigen Namen angezeigt werden –en-cockney für den Cockney-Dialekt des Englischen.

Sie können auch kleinere Teile eines Dokuments in einer bestimmten Sprache angeben, indem Sie langdem öffnenden Tag eines Elements ein Attribut zuweisen. Sie können beispielsweise die Sprache eines Zitats angeben, indem Sie ein langAttribut in das blockquoteTag einfügen. Wenn kein einzelnes Element den Abschnitt des Dokuments bedeckt, den Sie markieren möchten, können Sie hierfür ein Element DIV oder SPANverwenden. ( DIVist ein Element auf Blockebene, das ganze Absätze und andere Blockelemente einschließen kann; SPANist ein Element auf Zeichenebene, das in einem Absatz oder einem anderen Block enthalten sein kann.) Zum Beispiel:

<BLOCKQUOTE lang="en">How are you? Or, as I'd say in Spanish, "<SPAN lang="es">¿Como estás, o como diga en inglés, '<SPAN lang="en">How are you?</SPAN>'?</SPAN>"</BLOCKQUOTE>

Das kommt in Ihrem Browser so aus:

Wie geht es dir? Oder, wie ich auf Spanisch sagen würde: Wie geht es dir ?

Wahrscheinlich gibt es keinen sichtbaren Effekt von diesen verschiedenen Sprachattributen, obwohl in einigen Fällen ein Browser sie verwenden wird, um die Präsentation in einer Weise zu variieren, die für eine bestimmte Sprache geeignet ist, wie zum Beispiel eine andere Standardschriftart zu verwenden. In einem normalen graphischen Browser, der Sprachen wie Englisch und Spanisch anzeigt, die in Standard-ASCII- und Latein-1-Zeichen ausgedrückt werden können, besteht jedoch wenig Bedarf für solche Dinge. (Für andere Sprachen, die mehr “exotische” Zeichensätze verwenden, variieren Netscape 7 und Mozilla in der Tat die Schrift basierend auf derlangAttribut.) In jedem Fall wird die Information darüber, in welcher Sprache sich jeder Abschnitt der Passage befindet, von jedem Benutzeragenten verwendet, der eine Verwendung dafür hat, wie ein sprechender Browser, der seine Aussprache entsprechend anpassen kann, oder eine Indizierung Roboter, der verschiedene Materialindizes in verschiedenen Sprachen erstellt. (In der Tat, die IBM Home Page Reader sprechen Browser tut „lang“ Attribute erkennen und dies wirkt sich auf die Art und Weise es Text spricht.) Die W3C Zugänglichkeitsrichtlinien verlangen , dass Sie treu die Sprache aller Texte auf Ihrer Website markieren.

Beachten Sie, dass Elemente mit Sprachattributen in einer beliebigen Tiefe verschachtelt werden können. Das innerste Element, das einen bestimmten Textabschnitt umgibt, ist immer derjenige, der bestimmt, in welcher Sprache es ist. Im obigen Beispiel ist das Zitat als Ganzes in Englisch, aber es hat einen Abschnitt im Spanischen, der wiederum einen Unterabschnitt enthält Das ist auf Englisch.

Eine andere Möglichkeit, die Sprache des Dokuments anzugeben

Die obigen Attribute sind Teil von HTML. Eine weitere Schicht der Standards und Protokolle, durch die Webdokumente die Benutzer erreichen, ist HTTP, das HyperText Transfer Protocol. Das hat auch eine Methode, um anzugeben, in welcher Sprache das Dokument ist. Wenn Ihr Server diesen Header sendet:

Content-Language: en-US

dann wird dies anzeigen, dass die Seite in amerikanischem Englisch ist. Ich bespreche das HTTP-Protokoll und die Konfiguration Ihres Servers für sprachbezogene Einstellungen im Abschnitt zur Sprachverhandlung. Wenn Sie keine Aushandlung von Inhaltssprachen durchführen, müssen Sie sich wahrscheinlich nicht mit den HTTP-Protokolleinstellungen anlegen. Die HTML-Sprachattribute sind einfacher zu verwenden und flexibler (da sie Abschnitte einer Seite markieren können, nicht nur die Seite als Ganzes).

Online-Übersetzer

Ein Typ von Benutzeragenten, der diese Attribute in großem Umfang nutzen könnte, ist ein Online-Übersetzer, der eine Webseite aufnimmt und ihren Text in eine andere Sprache übersetzt. Leider scheinen diejenigen, die gegenwärtig verwendet werden, diese Attribute nicht besonders zu nutzen. Der AltaVista Babelfish-Übersetzer, der zu der Zeit, als er ursprünglich geschrieben wurde, am beliebtesten war (aber jetzt nicht mehr funktioniert; siehe hier für einen neueren “Klon”) oder “http://translate.google.com/”>Google Translator verwenden ), scheinen sich diese Attribute überhaupt nicht zu interessieren, sondern verlassen sich darauf, dass der Benutzer über ein Pulldown-Menü angibt, in welcher Sprache sich das Quelldokument befindet, und darauf vertrauen, unabhängig davon, was die Seite tatsächlich anzeigt. Einige andere Online-Übersetzer verwenden nur minimale langAttribute,HTML Element, das die Sprache des gesamten Dokuments angibt, aber andere langAttribute an anderen Stellen im Dokument nicht berücksichtigt . Dies führt zu merkwürdigen Situationen, wenn eine Seite meistens in einer Sprache ist, aber Zitate in anderen Sprachen enthält. Die Übersetzer werden versuchen, die Zitate so zu übersetzen, als ob sie in der Hauptsprache wären (zB in einem spanischen Zitat auf einer englischen Seite, es wird das Wort “sin”, spanisch für “ohne”, als englisches Wort “sin” sehen) , und übersetzen Sie es als “pecado”.) Dies ist ein Fall, in dem ein intelligenter Übersetzer Attribute erkennen könnte, die die Sprache von Dokumentteilen bezeichnen und erkennen, dass diese Abschnitte entweder nicht übersetzt oder aus einer anderen Ursprungssprache übersetzt werden sollten.

Diese Situation scheint eines der vielen “Chicken-or-the-egg” Dilemmas zu sein, die die Einführung von logischen, strukturellen Elementen und Attributen in HTML erschweren; Programmentwickler kümmern sich nicht darum, Unterstützung für sie zu implementieren, weil nur wenige Webautoren sie verwenden, und Webautoren kümmern sich nicht darum, sie zu benutzen, weil nur wenige Programme etwas mit ihnen machen. Diese Art von gordischen Knoten scheint keine “presentationalistischen” Verbesserungen zu bewirken, die darauf abzielen, “saubere” visuelle Effekte zu erzeugen, wie sie im Laufe der Jahre von Netscape und Microsoft mehrfach eingeführt wurden; Diese Dinge scheinen eine große Schar Fans zu haben, die begierig darauf sind, sie zu benutzen, selbst wenn die Browser-Unterstützung immer noch unpassend ist (ein “Best Angesehen mit der neuesten Version von My Favorite Browser” -Symbol auf der Titelseite, um Leute zum Upgrade zu bringen) . Oder, zumindest war dies in den frühen Jahren der Massenpopularität des Webs der Fall; die Dinge scheinen jetzt viel mehr gereift und stabilisiert zu sein. Aber jede Verbesserung, die die zugrunde liegende logische Struktur hinter den Kulissen ohne erkennbare visuelle Effekte beeinflusst, erregt bei Webdesignern oder Softwareentwicklern nicht das gleiche Interesse, so dass diese Dinge viel langsamer eingesetzt werden müssen.

Um diesen Zyklus zu durchbrechen, befürworte ich, dass Webautoren ihr Bestes geben, um diese Art von logischem Markup zu verwenden. Das Rendering ihrer Seiten wird nicht beeinträchtigt, und es wird dazu beitragen, dass zukünftige Generationen von User Agent-Autoren endlich versuchen, etwas Nützliches mit den betreffenden Tags und Attributen zu tun.

Verknüpfen von Links

Sie können nicht nur die Sprache von Textabschnitten auf Ihrer eigenen Seite angeben, sondern auch die Sprache anderer Dokumente angeben, auf die Sie verlinken. Dies verwendet das hreflangAttribut. Zum Beispiel:

<A hreflang="es" lang="en" href="spanish.html">A page in Spanish</A>

Beachten Sie, dass das obige Element sowohl a langals auch ein hreflangAttribut hat. Das langAttribut gibt die Sprache des Textes innerhalb des Elements an, in diesem Fall “Eine Seite in Spanisch”, die wie angegeben in Englisch ist. Das hreflangAttribut gibt an, dass die verknüpfte Seite in Spanisch ist.

Obwohl für dieses Attribut nicht viele Benutzerprogramme verfügbar sind, zeigt der Mozilla- Browser die Zieldokumentsprache im Informationsfenster an, die beim Klicken auf einen Link mit dem Element “Eigenschaften” im Kontextmenü aufgerufen werden kann.

Sprachverhandlung

Jetzt für etwas Komplexeres. Sie haben möglicherweise Versionen einer Seite in verschiedenen Sprachen. Es gibt einen Mechanismus, mit dem Sie Benutzern ihre bevorzugte Sprache mit derselben URL geben können. Dieser Mechanismus, der “Content Language Negotiation” genannt wird, ist seit Jahren im HTTP-Protokoll vorhanden, wird aber selten verwendet. Stattdessen haben Web-Entwickler dies als eines der Räder, die sie immer wieder neu erfinden, auf verschiedene Arten ausgewählt, die normalerweise dem ursprünglichen System unterlegen sind. Daher sind Websites mit komplizierten Methoden mit Cookies und JavaScript gefüllt, um Menschen zu ihrer bevorzugten Sprache zu leiten (möglicherweise werden sie nirgendwohin geführt, wenn Cookies oder JavaScript deaktiviert sind) oder versuchen, den Benutzer basierend auf dem Land, in dem der Server denkt, umzuleiten sind in (eine sehr unzuverlässige Sache zu bestimmen,

Es gibt einen besseren Weg. Browser bieten als Teil ihrer Konfiguration die Möglichkeit, in der bevorzugten Reihenfolge festzulegen, welche Sprachen der Benutzer verwenden möchte. Dies wird als Teil der HTTP-Anforderung für alle Webseiten gesendet, die der Benutzer abruft, und der Server kann damit die zu sendende Version auswählen.

Konfigurieren der Spracheinstellungen Ihres Browsers

Gewöhnlich ist die Browserpräferenz in Form einer Auswahlliste von Sprachen, die der Benutzer einzeln auswählen kann, um eine geordnete Liste zu bilden. In Mozilla und Netscape finden Sie dies unter “Einstellungen” im Menü “Bearbeiten”. innerhalb dieser ist es die Unterkategorie “Sprachen” im Bereich “Navigator”. In Opera ist dies der Menüpunkt “Einstellungen” im Menü “Datei” unter “Sprachen”. In MSIE ist dies der Menüpunkt “Internetoptionen” im Menü “Extras”; Drücken Sie die Schaltfläche “Sprachen” am unteren Rand der Registerkarte “Allgemein”.

Leider macht es keiner dieser Browser so gut, dem Benutzer zu erklären, wie er seine Spracheinstellungen vornimmt. Insbesondere wird das Verhältnis von generischen Sprachen ( es= Spanisch) und spezifischen Sprachvarianten ( es-MX= mexikanisches Spanisch) nicht erläutert. Wenn ein Benutzer eine bestimmte Varietät einer Sprache auswählt (z. B. die Variante eines Landes), aber auch andere Dialekte dieser Sprache versteht, sollte der Benutzer auch die generische Version auswählen, um sicherzustellen, dass Seiten aller Varianten der bevorzugten Sprache des Benutzers vorhanden sind verfügbar, nicht nur diejenigen des Landes, die der Benutzer am meisten bevorzugt. Zum Beispiel kann jemand, der Spanisch und Englisch versteht und die mexikanische Variante der spanischen und amerikanischen Variante des Englischen bevorzugt (aber andere Sorten akzeptiert), diese Vorzugsreihenfolge festlegen:

es-MX, es, en-US, en

Wenn in diesem Fall ein angefordertes Dokument in mexikanischem Spanisch verfügbar ist, wird es bevorzugt vor allen anderen Versionen geliefert. Wenn jedoch keine solche Version verfügbar ist , aber es ist eine in der venezolanischen Spanisch ( es-VE), dann wird es als eine Übereinstimmung mit dem allgemeinen spanischen Eintrag behandelt werden, und bevorzugt gegenüber anderen Sprachen bedient werden. Wenn keine spanische Version verfügbar ist, wird eine amerikanische englische Version zuerst überprüft, aber wenn keine verfügbar ist, wird eine englische ( en-GB) oder eine undifferenzierte generische englische ( en) Version geliefert. Beachten Sie, dass es wichtig ist , die generische Version in Ihrer Liste zu setzen , nachdemalle spezifischen Varianten der gleichen Sprache, oder die generische Version wird mit jedem Untertyp der gegebenen Sprache übereinstimmen, nicht unbedingt der Subtyp, den Sie am meisten bevorzugen. Wenn eine Site sowohl eine US – Englisch – als auch eine Britisch – Englisch – Version hat, wird das en Element in Ihrer Präferenzliste entweder übereinstimmen (wobei die Präferenz zwischen den beiden zufällig aufgelöst wird oder durch eine “Qualitätsstufe” in der Serverkonfiguration Webmaster entschied, welche Version vorzuziehen ist, wenn es dem Endbenutzer egal ist), aber wenn der en-USArtikel an erster Stelle in Ihrer Liste steht, wird er eindeutig Ihre Präferenz für amerikanisches Englisch ausdrücken.

Wenn Ihre Präferenzliste jedoch die generischen Versionen nicht enthält:

es-MX, en-US

dann sagst du dem Server, dass du nur mexikanisches Spanisch oder US-Englisch willst, keine andere Sorte. Wenn die Site Versionen in panamaischem Spanisch und australischem Englisch hat, würde keines Ihrer Präferenzliste entsprechen, so dass Sie dem Willen des Servers ausgeliefert sind, wenn keine Sprache übereinstimmt. (Im Folgenden finden Sie einige Hinweise, wie ein Webmaster mit solchen Fällen umgehen kann.) Es ist wahrscheinlich, dass Sie in diesem Fall nicht mit Ihrer bevorzugten Sprache enden, also sollten Sie dies vermeiden. Leider warnen die großen Browser Sie nicht davor, und einige von ihnen werden solche fehlerhaften Präferenzen ohne Beschwerde munter akzeptieren. (Es gibt seltene Fälle, in denen jemand tatsächlich eine Vorliebe dieser Art haben könnte, besonders im Fall von Sprachen mit gegenseitig unverständlichen Dialekten,

Opera vermeidet dieses Problem, indem es im Allgemeinen nur generische Sprachen und nicht spezifische Varietäten einbezieht (mit einigen Ausnahmen wie Chinesisch, für die mehrere Varietäten enthalten sind); dies beseitigt die Fähigkeit des Benutzers, in den “Stau” zu geraten, nur eine Sorte ohne seinen generischen Elternteil auszuwählen, auf Kosten der Beseitigung der Fähigkeit, unter Dialekten eine fein abgestimmte Präferenz auszudrücken. Auf der anderen Seite, MSIE enthält meist spezifische Sorten in seiner Liste, und im Falle von vielen Sprachen ist die generische Vielfalt nicht einmal verfügbar (obwohl es einen “Write-in-Slot” gibt, wo Sie zusätzliche Sprachen Ihrer Wahl hinzufügen können) . Dies macht es für Benutzer schwierig, ihre Spracheinstellungen korrekt zu konfigurieren, sowohl mit spezifischen als auch mit generischen Versionen, selbst wenn sie wissen, dass sie dies tun müssen.

Der beste Weg, dies zu handhaben, wäre meiner Meinung nach, sowohl Generika als auch Spezifika (wie Mozilla und Netscape) zu verwenden, aber eine Warnmeldung zu haben, wenn der Benutzer eine Einstellung vornimmt, die die Generika auslässt (wie es diese Browser leider nicht tun) ).

“Out-of-the-Box” -Browser werden normalerweise mit Spracheinstellungen konfiguriert, die der Sprache der Benutzeroberfläche des Browsers entsprechen. Wenn Sie einen Computer kaufen, der speziell für ein bestimmtes Land eingerichtet wurde, wird jeder vorinstallierte Browser wahrscheinlich auf die dominierende Sprache dieses Landes eingestellt. Wenn Sie den Computer aus einem anderen Land gekauft haben (z. B. Mexikaner beziehen ihre Computer oft aus den Vereinigten Staaten), und sie wurde nicht von einem lokalen Händler neu konfiguriert, könnte sie für eine Fremdsprache eingestellt sein. Wenn Sie einen Browser herunterladen, haben Sie möglicherweise die Möglichkeit, während der Installation Versionen in verschiedenen Sprachen oder eine Konfigurationseinstellung für die Sprache herunterzuladen. Da die meisten Benutzer dazu neigen, ihre Software in ihrer ursprünglichen Standardkonfiguration zu belassen, bedeutet dies, dass einige, aber nicht alle, Die verwendeten Browser sind entsprechend den Spracheinstellungen ihrer Benutzer konfiguriert. Aufgrund der Tatsache, dass die Browserhersteller das generische vs. spezifische Problem nicht richtig handhaben konnten, sind viele Browser dafür konfiguriert, nur eine bestimmte Variante einer Sprache und nicht diese Sprache im Allgemeinen zu akzeptieren en-US statt en.

Aufgrund dieser Probleme stellen einige Webmaster die Frage, ob der Einsatz von Sprachverhandlungen eine gute Idee ist, und dies kann zu philosophischen Debatten darüber führen, ob es besser ist, Benutzer darüber aufzuklären, wie sie die Funktionen ihres Browsers oder Entwickler nutzen können Ich sollte das aufgeben und einfach auf das angenommene Maß an Ignoranz der Nutzer hoffen. Bei solchen Debatten stehe ich normalerweise auf der Seite der Fraktion, die die Features richtig nutzen und versuchen möchte, anderen das beizubringen; Der andere Weg führt zur Verdummung des Internets und zur ständigen Erneuerung der Räder auf minderwertige Weise.

Einrichten von Sites für die Sprachaushandlung

Wie Sie Ihre Site einrichten, um diese Funktion zu nutzen, hängt von der verwendeten Server-Software ab. Da Apache derzeit der populärste Webserver ist, werde ich beschreiben, wie man es unter diesem System macht, aber es sollte Methoden geben, dies auch in anderer Server-Software zu erreichen.

Dokumente erstellen

Zuerst müssen Sie verschiedene Sprachversionen Ihrer Dokumente mit einem konsistenten Namensschema erstellen. Eigentlich ist es möglich, Sprachverhandlungen zu konfigurieren, unabhängig davon, wie Sie die verschiedenen Versionen benennen. Am einfachsten ist es jedoch, wenn Sie den Erweiterungen neben der Dateierweiterung, die bereits vorhanden ist, den Datentyp zuweisen . Zum Beispiel, wenn Sie früher nur eine einsprachige Version einer Seite hatten, benannt mypage.htmlund Sie möchten nun zwischen englischen und spanischen Versionen davon verhandeln, Sie können sie benennen mypage.html.en und mypage.html.es. (Ich werde später noch auf die Frage eingehen, ob das Sprachsuffix vor oder nach der anderen Dateierweiterung gesetzt werden .htmlsoll und wie sich das auf den Zugriff auf die Seiten auswirkt. Fürs Erste nehme ich an, dass das Sprachsuffix zuletzt gesetzt wird. )

Konfiguration einrichten

Jetzt müssen Sie dem Server mitteilen, was die Suffixe bedeuten und dass Sie beabsichtigen, sie für Verhandlungen zu verwenden. Ein Weg, um dies zu tun ist mit einer .htaccessDatei (der Dateiname ist genau das, .htaccessmit dem Punkt als der erste Buchstabe, so unnatürlich wie dies für MS-Windows-Benutzer mehr an das Schema verwendet scheinen kann filename.ext; Leider macht es manche PC-Software schwierig, Dateien mit solchen Namen zu erstellen, da sie versuchen, den Dateinamen in einen “vertrauteren” Stil umzuwandeln, mit den folgenden Zeilen:

Options +MultiViews

AddLanguage en-US .en


AddLanguage es-MX .es


LanguagePriority en-US es-MX

Die erste Zeile weist Apache an, den Modus “MultiViews” zu aktivieren, in dem er zwischen verschiedenen Versionen eines Dokuments wählen kann, anstatt nur dieselbe Datei für alle Benutzer bereitzustellen. Die nächsten zwei Zeilen sagen, dass es .enein Dokument in englischer Sprache (US-Sorte) darstellt, und .esstellt ein Dokument in Spanisch (mexikanische Variante) dar. (Legen Sie hier die Sprachen Ihrer Wahl fest; Sie können so viele verschiedene Sprachen haben, wie Sie möchten, mit jeweils einer anderen Erweiterung, die möglicherweise nicht mit dem Sprachencode übereinstimmen muss – normalerweise verwenden Benutzer Polnisch als eine der unterstützten Sprachen benutze etwas anderes als das.plSprachcode, da dies im Web als Dateierweiterung für Perl-Skripte gebräuchlich ist). Die letzte Zeile legt die Reihenfolge der Priorität für die verschiedenen Sprachen in Fällen nahe, in denen der Benutzeragent keine Präferenz äußert; Hier machte ich Englisch zur ersten Wahl. Wahrscheinlich möchten Sie die Sprache verwenden, die Ihrer Meinung nach die höchste Qualität auf Ihrer Website hat, vielleicht die Sprache Ihrer Originalschrift, von der die anderen möglicherweise etwas in der Übersetzung verlieren könnten.

.htaccessDateien können in einem beliebigen Unterverzeichnis Ihrer Site gespeichert werden und gelten für alles in diesem Verzeichnis und alle untergeordneten Verzeichnisse. Daher sollten Sie Ihre Datei im Server-Stammverzeichnis Ihrer Site (dem obersten Verzeichnis, in dem öffentliche Web-Daten gespeichert sind, normalerweise dort, wo sich die Haupt-Homepage befindet) ablegen, wenn sie auf Ihre gesamte Site oder in einem Unterverzeichnis angewendet werden soll wenn Sie diese Funktionen nur in einer Untergruppe Ihrer Website verwenden und nicht möchten, dass sie den Rest Ihrer Inhalte beeinträchtigt.

Jetzt versuchen Sie, darauf zuzugreifen!

Nachdem Sie die .htaccessDatei eingerichtet mypage.html.enund mypage.html.esDateien online gestellt haben, können Sie versuchen, auf die URL zuzugreifen http://yoursite.example/mypage.html(wo http://yoursite.example/mypage.html wird durch die Domain Ihrer Website und alle Pfadinformationen ersetzt, die erforderlich sind, um zu dem Ort zu gelangen, an dem sich Ihre Seite befindet). Wenn Sie alles richtig gemacht haben, sollten Sie abhängig von Ihrer Sprachkonfiguration die englische oder spanische Version der Seite erhalten.

Whoops … Ich habe immer noch die alte Version der Seite!

Wenn Sie stattdessen mit der alten Version von mypage.html Bevor Sie mit dem Versuch begonnen haben, eine Sprachverhandlung hinzuzufügen, bedeutet dies, dass Sie diese Datei an der richtigen Stelle neben der neuen Datei belassen haben mypage.html.en und mypage.html.es Dateien. Wenn ein Benutzer versucht, auf die URL mit der Endung mypage.html, Apache sucht zuerst nach einer Datei, die exakt mit diesem Namen übereinstimmt. Wenn es einen findet, werden keine “MultiViews” versucht; Die gefundene Datei wird sofort geliefert. Daher sollten Sie die alte Datei löschen, damit Apache die Dateien finden kann, die wirklich geliefert werden sollen. Wenn keine übereinstimmende Datei gefunden wird, fährt Apache mit der Verhandlungsphase fort und betrachtet alle Dateien, die benannt sind mypage.html mit zusätzlichen Erweiterungen danach, und zu sehen, welche von ihnen am besten mit den akzeptablen Sprachen (oder, was das betrifft, Datenformate; Verhandlung kann theoretisch verwendet werden, um HTML, PDF und MS-Word zu dienen Versionen eines Dokuments, das auf Benutzereinstellungen basiert, obwohl populäre Browser diese Fähigkeit derzeit nicht wirklich nutzen.) Wenn Englisch die erste Sprachwahl des Benutzers ist, mypage.html.en wird abgestimmt und serviert.

Tatsächlich ist der .htmlTeil des Dateinamens nicht einmal notwendig, um in die URL aufgenommen zu werden, wenn MultiViews aktiviert ist, da dieser Teil auch verhandelt werden kann und alle gängigen Browser HTML als einen ihrer akzeptierten Inhaltstypen enthalten. Eine Anfrage für die URL endet in mypage (ohne Verlängerung angegeben) mypage.html.en angepasst werden, da Apache .htmlmit dem text/htmlMIME-Typ verknüpft ist und Sie .en mit der englischen Sprache verbunden sind.

Einige Entwickler bevorzugen die Verwendung von erweiterungsfreien URLs dieser Form, da sie kürzer, sauberer und “zukunftssicherer” sind (Sie können das Datenformat oder die Skriptsprache in Zukunft ändern, ohne die URLs zu ändern). Andere empfinden sie als etwas unnatürlich, da sie an URLs mit Dateiendungen am Ende gewöhnt sind, wenn sie keine Unterverzeichnisse sind, die mit Schrägstrichen enden. Wenn Sie eine MultiViews-Verhandlung zu einer bereits vorhandenen Website hinzufügen, verwenden Sie wahrscheinlich bereits Links zu URLs, die auf.html(oder andere Erweiterungen) und möchten sie möglicherweise nicht ändern. Es gibt also Vor- und Nachteile für beide Möglichkeiten, aber beide funktionieren. Ein Vorteil des Löschens der Erweiterung aus der URL besteht darin, dass Sie mehrere Erweiterungen in beliebiger Reihenfolge hinzufügen können, um den Inhaltstyp, die Sprache und andere Aushandlungsprozesse zu erreichen..html.en und .en.html wird identisch funktionieren. Wenn Ihre URLs enden .html, Ihre Dateinamen dürfen zuvor keine anderen Erweiterungen enthalten oder sie werden nicht korrekt übereinstimmen.

Was aber, wenn der Benutzer keine der beiden Sprachen in die Anfrage aufnimmt?

Ein Problem, mit dem Sie möglicherweise konfrontiert sind, ist der Umgang mit Anfragen, die keine Ihrer unterstützten Sprachen als akzeptabel kennzeichnen. Wenn ein Benutzer den Akzeptanz-String sendetfr-CA, fr, deWenn Ihre bevorzugten Sprachen kanadisches Französisch, generisches Französisch und generisches Deutsch sind, stimmen weder Ihre englische noch Ihre spanische Seite überein. Technisch gesehen ist nichts in Ihrer Site für den Benutzer akzeptabel, und mit der obigen Konfiguration wird dem Benutzer eine Fehlerseite angezeigt, die das sagt. (Leider ist diese Fehlerseite im Allgemeinen auf Englisch, obwohl der Benutzer angegeben hat, dass dies keine akzeptable Sprache ist!) Obwohl dies technisch korrekt ist, würden es die meisten Webmaster bevorzugen, dass dies nicht geschieht. Es ist eine hässliche und schwer verständliche Seite, die mit “Nicht akzeptabel” beginnt und die Benutzer zu der Annahme verleitet, dass sie etwas falsch gemacht haben. Daher würden die meisten Webmaster es bevorzugen, stattdessen eine Version ihres echten Inhalts zu verwenden, selbst wenn sie sich in einer Sprache befindet, die der Benutzer nicht versteht. Diese Notwendigkeit wird aufgrund der Tatsache, dass falsch konfigurierte Browser keine Sprachakzeptanzstrings senden, die mit den tatsächlichen Präferenzen ihrer Benutzer übereinstimmen, dringender. Wenn zum Beispiel ein Browser eine Zeichenkette sendet, die die generischen Versionen der bevorzugten Sprachen ausschließt, wieen-GB, es-VE, dann werden weder die Versionen in US-Englisch noch in Mexikanisch-Spanisch übereinstimmen und der Benutzer wird die Fehlerseite erhalten, eine unglückliche Wendung der Ereignisse.

Zum Glück gibt es einen Workaround. Wenn Sie eine Version der Datei ohne Sprachcode angeben, wird diese geliefert, wenn keine der sprachcodierten Versionen übereinstimmt. Du musst das aber sorgfältig tun. Das haben wir schon gesehen, wenn man eine Ebene verlässt mypage.html Datei neben um mypage.html.en usw., dann wird es bevorzugt als Antwort auf eine Anfrage für mypage.html. Wenn Sie jedoch die “extensionless” -Version der URL verwenden, können Sie diese Dateien nebeneinander haben, wobei die Verhandlung verwendet wird, um zu entscheiden, welche Version verwendet wird und welche ohne Sprachcode nur verwendet wird, wenn keine Sprache übereinstimmt. Wenn Ihr Link jedoch die Erweiterung hat, können Sie es dennoch etwas komplizierter machen. Erstellen Sie einfach eine Datei mypage.html.htmlmit einer doppelten Erweiterung. Dies wird nicht sofort mit der Anfrage übereinstimmen, so dass die Verhandlung fortgesetzt werden kann, aber sie wird immer noch als Standard übereinstimmen, nachdem alles andere fehlgeschlagen ist.

Selbst wenn Sie “extensionless” -Links verwenden und somit die doppelte Erweiterung umgehen können, müssen Sie immer noch die Standard-Indexseiten für jedes Verzeichnis berücksichtigen. Wahrscheinlich wurde Ihr Server so konfiguriert, dass er nach bestimmten Namen sucht index.html und nicht ohne Verlängerungen Index. index.html.enund index.html.htmlwird durch Aushandlung abgeglichen, aber wenn es ein gibt index.html, würde es zuerst abgeglichen werden und die Aushandlung für den Standardindex verhindern. Daher müssen Sie wahrscheinlich “doppelte Erweiterungen” für die Standardversionen von diesen verwenden, auch wenn Sie an anderer Stelle mit einzelnen Erweiterungen davonkommen.

Wahrscheinlich möchten Sie, dass die Standardversion mit der Datei Ihrer bevorzugten Sprache identisch ist. Sie können einfach die andere Datei unter diesem neuen Namen kopieren, aber dann müssen Sie daran denken, beide Versionen zu aktualisieren, wenn sich die Seite ändert. Eine bessere Technik, wenn Sie es können, besteht darin, den Standarddateinamen als “Link” zu einer der anderen Dateiversionen zu verwenden. Wenn sich Ihr Server auf einer Unix-ähnlichen Plattform befindet und Sie Shell-Zugriff haben, können Sie den folgenden Befehl verwenden:

ln mypage.html.en mypage.html.html

um mypage.html.htmlals “Link” zu erstellen , der immer den gleichen Inhalt zurückgibt, wie er mypage.html.enautomatisch aktualisiert wird, wenn sich die Datei ändert.

Die neueste Version von Apache hat einige weitere Befehle, die in .htaccessDateien verwendet werden können, um das Ausweichverhalten für die Aushandlung auf einfachere Weise zu spezifizieren, aber viele Seiten (einschließlich meiner) werden immer noch von Anbietern gehostet, die ältere Versionen verwenden, daher ist die obige Technik für jetzt notwendig.

Ein anderes Problem … Und ein hässlicher Kluddel um ihn herum

Wie oben erwähnt, gibt es eine beunruhigende Tendenz für aktuelle Browser, mit nur einer regionalen Variante einer Sprache und nicht ihrer generischen Vielfalt konfiguriert zu werden en-US nicht begleitet von de. Technisch bedeutet dies, dass der Benutzer nur amerikanisches Englisch und nicht irgendeine andere Vielfalt an Englisch möchte; Wenn also ein Dokument in britischem Englisch und Französisch verfügbar ist und die Standardsprache auf dieser Site auf Französisch eingestellt ist, wird dem Benutzer die französische Version geliefert, obwohl die englische Version wahrscheinlich bevorzugt wird. Ich habe dieses Problem in einer Website, die ich eingerichtet habe, wo die beiden Versionen waren en-US und Es-MX, die Standardeinstellung war die englische Version, und ich fand, dass viele Besucher für spanische Varietäten wie Es-PR (Puerto Rican Spanish) und bekam somit die englische Version, wo der mexikanisch-spanische Sinn sinnvoller gewesen wäre. Dies ist alles in perfekter Übereinstimmung mit den Standards – das ist, wonach der Benutzer tatsächlich gefragt hat – aber der Zweck der fraglichen Website ist es nicht, mit Besuchern zu streiten oder ihnen beizubringen, wie sie ihren Browser konfigurieren. Daher habe ich nach einigem Probieren einen wirklich hässlichen “Klud” gefunden, der eine bessere Chance gab, den Benutzern das zu geben, was sie wahrscheinlich wirklich wollten, anstatt das, wonach sie eigentlich gefragt hatten. Das ist nicht etwas, das ich guten Gewissens empfehlen kann – es läuft ganz und gar gegen meine normale Web-Entwicklungsphilosophie, die Standards akribisch zu befolgen und die geringste Andeutung der verdammten Denkweise zu vermeiden, die heutzutage das Internet durchdringt – aber in diesem Fall verbessern Sie die Benutzererfahrung, also hier ist es, falls Sie es auch versuchen möchten.

Was ich tat, war, die spanischen Versionen meiner Dokumente so zu machen, als ob sie neben der mexikanischen auch andere spanische Versionen wären. In Serverprotokollen und Browserkonfigurationen habe ich die gebräuchlichen spanischen Varianten und die zugehörigen Codes aufgelistet und zu meiner .htaccessDatei hinzugefügt :

AddLanguage es .es1

AddLanguage es-CL .es2


AddLanguage es-CO .es3


AddLanguage es-CR .es4


AddLanguage es-PA .es5


AddLanguage es-PE .es6


AddLanguage es-PR .es7


AddLanguage es-PY .es8


AddLanguage es-SV .es9


AddLanguage es-AR .es10


AddLanguage es-DO .es11


AddLanguage es-US .es12


AddLanguage es-UY .es13


AddLanguage es-BO .es14


AddLanguage es-EC .es15


AddLanguage es-GT .es16


AddLanguage es-HN .es17


AddLanguage es-NI .es18


AddLanguage es-ES .es19


AddLanguage es-VE .es20

Dies deckt eine Reihe von nationalen Varianten ab, plus die allgemeine für gute Maßnahme (die nicht wirklich notwendig ist, wie es von jeder Variante abgestimmt werden sollte, aber mein Versuch und Irrtum zeigte, dass es gelegentlich die spanische Version verursacht hat als Antwort auf eine Variante geliefert werden, die aus irgendeinem Grund nicht in der Liste enthalten ist), wobei jeder mit einer anderen Dateierweiterung verknüpft wird, .es1, .es2, etc.

Als Nächstes habe ich für jede Seite der spanischen Version “symlinked” -Dateien erstellt, mit Namen wie: index.html.es1.es2.es3.es4.es5.es6.es7.es8.es9.es10

index.html.es11.es12.es13.es14.es15.es16.es17.es18.es19.es20

Dies wäre wirklich mühsam, um von Hand zu erstellen, aber ich bin ein Programmierer … Ich habe nur ein Perl-Skript, um es für meine gesamte Website zu tun!

Das Endergebnis ist, dass, wenn der Browser eines Benutzers konfiguriert ist Es-PE Der Server “lügt” und behauptet, dass die spanische Version tatsächlich von dieser Sorte ist. Mit anderen Worten, ich breche die Standards, aber das Ergebnis ist, dass der Benutzer eine spanische Version wie gewünscht anstelle einer englischen Version bekommt.

Tun Sie dies oder nicht, wie Sie wollen … wir können hoffen, dass Browser irgendwann zu vernünftigeren Konfigurationen übergehen, so dass dies nicht notwendig ist.

Schließen Sie immer auch einen regulären Link ein

Wie bereits erwähnt, konfigurieren Benutzer ihre Browser leider nicht immer korrekt für ihre Spracheinstellungen. Außerdem verwenden Benutzer manchmal Browser, die zu anderen Personen gehören (einschließlich an öffentlichen Orten, wie z. B. Bibliotheken und Internetcafés), die möglicherweise für andere Spracheinstellungen als die des Benutzers konfiguriert sind. Die Benutzer könnten auch daran interessiert sein, mehr als eine Ihrer Sprachversionen anzusehen, weil sie mehr als eine Sprache fließend sprechen oder weil sie versuchen, eine andere Sprache zu lernen. Daher ist es wichtig, dem Benutzer die Möglichkeit zu geben, zu anderen Versionen Ihrer mehrsprachigen Seiten zu gelangen, als sie standardmäßig ausgeliefert werden. Sie können dies tun, indem Sie Links zu allen anderen Sprachversionen der Seite auf jeder Seite, die mit einer Sprache verhandelt wird, einfügen. Durch direkte Verbindung zumypage.html.es, Sie gehen immer zur spanischen Version, egal welche Konfiguration der Benutzer eingestellt hat.

Ich empfehle jedoch, dass Sie keine Bilder von Flags für diese Links verwenden, obwohl das ziemlich üblich ist; Es ist ein falscher Ansatz, da Flaggen Länder und nicht Sprachen repräsentieren. Sollte Englisch durch eine britische Flagge oder eine amerikanische Flagge vertreten sein? Welche Sprache sollte eine kanadische Flagge repräsentieren? (Sowohl Englisch als auch Französisch sind Amtssprachen in diesem Land.) Und Flaggen sind nicht notwendigerweise sogar einzigartig ! Es ist besser, den Namen jeder Sprache in dieser Sprache als Linktext zu verwenden.

Sie können auch ein LINKTag einschließen, das auf die alternativen Sprachversionen verweist:

<link rel="alternative" lang="fr" hreflang="fr" title="En Français" href="mypage.html.fr">

Dies bewirkt, dass Browser, die dieses Element unterstützen, eine Art Benutzerschnittstelle bereitstellen, die den Zugriff auf die verschiedenen Sprachversionen ermöglicht. Da die Unterstützung in heutigen Browsern jedoch nicht sehr gut ist, sollte dies nicht die einzige Möglichkeit sein, auf die alternativen Versionen zu verlinken.

Eine interessante Frage ist, wenn Sie alle Seiten Ihrer Website so eingerichtet haben, dass sie durch Sprachvermittlung bedient werden, ob Navigationslinks innerhalb der Website zu den “generischen” URLs jeder Seite gehen sollen (also Thema bei jedem Link zu Sprachvermittlung) oder zu den spezifischen Sprachversionen, die der Sprachversion der aktuell angezeigten Seite entsprechen. Das ist ein schwieriges Thema. Wenn Sie “generische” URLs verwenden, kann es frustrierend für jemanden sein, der aus irgendeinem Grund versucht, die Site in einer anderen als der in den Browsereinstellungen konfigurierten Sprache zu durchsuchen, sich aber in einer anderen Sprachversion aufhält Klicken Sie auf den Link zur richtigen Sprache auf jeder Seite. Es gibt ein gutes Argument dafür, den Benutzer in der aktuellen Sprache zu belassen, wenn man einen bestimmten Link ausgewählt hat. Auf der anderen Seite, wenn Sie dies tun, ermutigen Sie andere, die auf Ihre Website verlinken, sowie Suchmaschinen-Indexer, die URLs in der spezifischen Sprache zu verlinken und die Verhandlung zu umgehen, da die generischen URLs unter Ihren nicht erscheinen interne Links. Dies bedeutet, dass viele neue Nutzer direkt über solche Links auf Ihre Website gelangen und die Verhandlungen nie eine Chance haben, fortzufahren. Sie hätten es in diesem Fall auch gar nicht hinzufügen können. Durch das Verknüpfen der generischen URLs behalten Sie die ausgehandelten Links als Zugangspunkte zu Ihrer Site bei (obwohl die spezifischen Sprachen auch verlinkt und indexiert werden, da Sie auch Links direkt zu ihnen haben). Umgehen der Verhandlung, da die generischen URLs unter Ihren internen Links nicht angezeigt werden. Dies bedeutet, dass viele neue Nutzer direkt über solche Links auf Ihre Website gelangen und die Verhandlungen nie eine Chance haben, fortzufahren. Sie hätten es in diesem Fall auch gar nicht hinzufügen können. Durch das Verknüpfen der generischen URLs behalten Sie die ausgehandelten Links als Zugangspunkte zu Ihrer Site bei (obwohl die spezifischen Sprachen auch verlinkt und indexiert werden, da Sie auch Links direkt zu ihnen haben). Umgehen der Verhandlung, da die generischen URLs unter Ihren internen Links nicht angezeigt werden. Dies bedeutet, dass viele neue Nutzer direkt über solche Links auf Ihre Website gelangen und die Verhandlungen nie eine Chance haben, fortzufahren. Sie hätten es in diesem Fall auch gar nicht hinzufügen können. Durch das Verknüpfen der generischen URLs behalten Sie die ausgehandelten Links als Zugangspunkte zu Ihrer Site bei (obwohl die spezifischen Sprachen auch verlinkt und indexiert werden, da Sie auch Links direkt zu ihnen haben).

Ich habe schließlich eine Lösung für dieses Dilemma gefunden; Wenn Sie dieses JavaScript zum HEAD-Abschnitt Ihrer Seiten hinzufügen:

<SCRIPT LANGUAGE="JavaScript" type="text/javascript"> function settaglinks(tag, lang) { anchors = document.getElementsByTagName(tag); for (i=0;anchors[i];i++) { if (anchors[i].href.lastIndexOf(‘.html’) == anchors[i].href.length-5 && anchors[i].href.indexOf(‘yourdomain.example’) >= 0) { anchors[i].href = anchors[i].href+’.’+lang; } else if (anchors[i].href.charAt(anchors[i].href.length – 1) == ‘/’ && anchors[i].href.indexOf(‘yourdomain.example’) >= 0) { anchors[i].href = anchors[i].href+’index.html.’+lang; } } } function setlinks(lang) { if (document.location.href.lastIndexOf(‘.’+lang) == document.location.href.length-3) { settaglinks(‘a’, lang); settaglinks(‘link’, lang); } } </SCRIPT>

und dann onload="setlinks('en')"in deine einfügen<BODY>tag (ändert ‘en’ in den für die angegebene Seite passenden Sprachencode und ‘yourdomain.example’ in den Domainnamen Ihrer Site), dann werden alle Links von generischen in sprachspezifische Versionen geändert, wenn der Benutzer mit a auf die Seite zugreift sprachspezifische URL, aber nicht, wenn sie über eine generische URL, die sprachverhandelt ist, auf die Seite gelangen. Zumindest wird dies passieren, wenn der Benutzer JavaScript aktiviert hat und sein Browser alle Funktionen dieses Skripts unterstützt. Wenn nicht, sollte es sich “graziös verschlechtern”, indem die Links in Ruhe gelassen werden. Der Effekt ist, dass Benutzer, die eine Sprachversion explizit auswählen, indem sie einem Link zu ihr folgen, von dieser Zeit an Links in dieser Sprache erhalten, während Nutzer, die ihren Browser die Sprache für sie auswählen, an den generischen URLs bleiben; ebenfalls,

Einige der Sachen, die ich hier mache, sind weit weg von meiner normalen Philosophie “Keep It Simple, Stupid”, aber manchmal muss man genauso kompliziert werden, wie es sein muss, um den Job zu erledigen … aber nicht mehr.

Zeichensätze und Kodierungen

Ich führe hier nur Zeichensätze und Kodierungen auf, um zu bemerken, dass sie ein anderes Thema als Sprachen sind, obwohl sie oft verwirrt sind. Ich habe schon eine andere Seite bei Zeichen- und Zeichensatzproblemen. Die Spezifikation einer bestimmten Sprache durch ein HTML-Attribut oder einen HTTP-Header hat keine Auswirkungen darauf, welche Zeichencodierung das Dokument verwendet oder welche Schriftart verwendet werden sollte, um anzuzeigen, obwohl Browser möglicherweise unterschiedliche Standardschriftarten abhängig von der Sprache verwenden. Die Verwirrung rührt von der Tatsache her, dass verschiedene Sprachen ein anderes Zeichenrepertoire erfordern, manchmal nur geringfügig voneinander (dasselbe Grundalphabet, aber verschiedene Akzentbuchstaben oder andere diakritische Zeichen und Interpunktion) und manchmal radikal verschieden (ein anderes Alphabet wie Griechisch) oder kyrillisch oder ein nonalphabetisches Schriftsystem wie Chinesisch oder Japanisch), und daher gibt es spezifische Kodierungen und Schriftarten, die mit einer gegebenen Sprache verbunden sind.

Es ist immer noch unangemessen anzunehmen, dass ein Dokument eine bestimmte Zeichenkodierung verwendet, nur weil es am häufigsten in der Sprache verwendet wird. Ein Zitat in einem Dokument wird möglicherweise als lang="ru" “in Russisch” gekennzeichnet, aber nicht im kyrillischen Alphabet, da es in das lateinische Alphabet transkribiert wird (wie ” Glasnost ” und ” Perestroika “). Auch wenn das kyrillische Alphabet verwendet wird, gibt es eine Reihe verschiedener Kodierungen, die dieses Repertoire enthalten. Daher ist die Verwendung von Language Tagging kein Ersatz für die korrekte Zeichencodierung des Dokuments in der HTTP-Antwort Ihres Servers. Dies kann in einer .htaccessDatei erfolgen:

AddDefaultCharset ISO-8859-1

Diese Zeile kann verwendet werden, wenn alle Dokumente in der ISO-8859-1-Codierung vorliegen (für die meisten westeuropäischen Sprachen verwendbar); Wenn Sie mehrere Kodierungen für Dokumente in verschiedenen Sprachen verwenden, müssen Sie etwas weiter entwickelt werden. Vielleicht verwenden Sie für jede Datei unterschiedliche Dateierweiterungen und richten die Konfigurationen entsprechend ein. (Als ich das vor einigen Jahren zum ersten Mal schrieb, war eine solche Vielzahl von Codierungen immer noch üblich, aber heutzutage wird es immer beliebter, alles in UTF-8 zu tun, einer Codierung, die das gesamte Unicode-Repertoire unterstützt. einschließlich der, die ich benutze, UltraEdit), unterstützt die native Bearbeitung in UTF-8, also ist dies machbar.)

Links

Diese Seite wurde zuerst am 3. November 2002 erstellt und wurde zuletzt am 23. März 2015 geändert. Copyright © 1997-2018 by Daniel R. Tobias. Alle Rechte vorbehalten.