-
Notifications
You must be signed in to change notification settings - Fork 59
/
qa-when-lang-neg.de.html
139 lines (117 loc) · 15.5 KB
/
qa-when-lang-neg.de.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8" />
<title>Wann es angebracht ist, Sprachvereinbarung (language negotiation) einzusetzen</title>
<meta name="description" content="Wann ist es angebracht und wann nicht, Sprachvereinbarung () einzusetzen?" />
<script>
var f = { }
// AUTHORS should fill in these assignments:
f.directory = 'questions'+'/' // the path to this file, not including /International or the file name
f.filename = 'qa-when-lang-neg' // the file name WITHOUT extensions
f.authors = 'François Yergeau' // author(s) and affiliations
f.previousauthors = '' // as above
f.modifiers = '' // people making substantive changes, and their affiliation
f.searchString = 'qa-when-lang-neg' // blog search string - usually the filename without extensions
f.firstPubDate = '2004-02-26' // date of the first publication of the document (after review)
f.lastSubstUpdate = { date:'2004-02-26', time:'15:10'} // date and time of latest substantive changes to this document
f.status = 'published' // should be one of draft, review, published, notreviewed or obsolete
f.path = '../' // what you need to prepend to a URL to get to the /International directory
// AUTHORS AND TRANSLATORS should fill in these assignments:
f.thisVersion = { date:'2016-03-04', time:'16:32'} // date and time of latest edits to this document/translation
f.contributors = '' // people providing useful contributions or feedback during review or at other times
// also make sure that the lang attribute on the html tag is correct!
f.sources = '' // describes sources of information
// TRANSLATORS should fill in these assignments:
f.translators = '<a href="http://bittersmann.de/">Gunnar Bittersmann</a> mit <a href="http://julianewuensche.de/">Juliane Wünsche</a>' // translator(s) and their affiliation - a elements allowed, but use double quotes for attributes
f.breadcrumb = 'navigation'
f.additionalLinks = ''
</script>
<script src="qa-when-lang-neg-data/translations.js"> </script>
<script src="../javascript/doc-structure/article-dt.js"> </script>
<script src="../javascript/boilerplate-text/boilerplate-de.js"> </script>
<!--TRANSLATORS must change -en in the line just above to the subtag for their language! -->
<script src="../javascript/doc-structure/article-2022.js"> </script>
<script src="../javascript/articletoc-2022.js"></script>
<link rel="stylesheet" href="../style/article-2022.css" />
<link rel="copyright" href="#copyright"/>
</head>
<body>
<header>
<nav id="mainNavigation"></nav><script>document.getElementById('mainNavigation').innerHTML = mainNavigation</script>
<h1>Wann es angebracht ist, Sprachvereinbarung (<span lang="en">language negotiation</span>) einzusetzen</h1>
</header>
<div id="audience">
<div id="updateInfo"></div><script>document.getElementById('updateInfo').innerHTML = g.updated</script>
</div>
<section id="question">
<h2>Frage</h2>
<p class="question">Wann ist es angebracht und wann nicht, Sprachvereinbarung einzusetzen?</p>
<aside class="insideinfonote"><p class="footnote">In deutschsprachigen Quellen wird oft die englische Bezeichnung „<span lang="en">language negotiation</span>“ beibehalten. In der deutschen Ausgabe <em><span lang="en">Apache</span> – Das umfassende Handbuch</em> von B. & P. <span lang="en">Laurie</span> (<span lang="en">O’Reilly</span>) findet man „Sprachvereinbarung“. (Anm. d. Übers.)</p></aside>
<p>Sprachvereinbarung (<span lang="en">language negotiation</span>)* ist eine Funktion des HTTP-Protokolls, die einen Server aus mehreren Sprachversionen einer Seite eine auswählen lässt, basierend auf der Information über die bevorzugten Sprachen, die der Browser übermittelt (speziell im <span lang="en"><code class="kw" translate="no">Accept-Language</code>-Header</span>). Dies unterscheidet sich von der Auswahl anhand der IP-Adresse des Browsers oder von der manuellen Auswahl durch den Benutzer auf einer Sprachauswahl-Seite. Wenn es keine Übereinstimmung zwischen den vom Browser bevorzugten Sprachen und den auf dem Server verfügbaren Sprachen gibt, wird entweder eine Sprachauswahl-Seite angezeigt oder die Seite in einer voreingestellten Sprache ausgeliefert.</p>
<p>In vielen Fällen ist die Voreinstellung der bevorzugten Sprachen im Browser in Ordnung. Hat jemand bspw. die japanische Version eines Browsers, so geht der Browser typischerweise davon aus, dass der Nutzer Seiten vorzugsweise auf Japanisch liest, und sendet diese Information zum Server. Mainstream-Browser erlauben es dem Nutzer, die bevorzugten Sprachen einzustellen. Für weitere Information siehe <a class="print" href="qa-lang-priorities"><cite>Einstellung der bevorzugten Sprachen im Browser</cite></a>.</p>
<p>Diese FAQ behandelt die Frage, wann es ratsam ist und wann nicht, Sprachvereinbarung auf dem Server einzusetzen.</p>
</section>
<section id="answer">
<h2>Antwort</h2>
<p>Einfache Antwort: <em>immer</em>.</p>
<p>Etwas ausführlicher: <em>fast</em> immer, <em>aber nicht ausschließlich</em>.</p>
<p>Sprachvereinbarung <a href="#shortcomings">funktioniert nicht immer wie gewünscht</a>; es gibt aber Wege, <a href="#overrides">die Schwachstellen zu beheben</a>; und man sollte für eine <a href="#stickyness">konsistente Navigation</a> sorgen.</p>
<section id="shortcomings">
<h3>Schwachstellen der Sprachvereinbarung</h3>
<p>Sprachvereinbarung ist offensichtlich eine nützliche Sache, aber bevor man sie implementiert, ist es wichtig, ihre Grenzen zu kennen. Um diese zu veranschaulichen, nehmen wir als Beispiel eine Website www.example.be, die ihre Inhalte in Flämisch, Französisch und Deutsch anbietet. Unsere Besucherin Sylvia spricht Italienisch, versteht aber auch Deutsch. Verschiedene Situationen können eintreten:</p>
<ol>
<li>Sylvias Browser ist korrekt konfiguriert; er gibt Italienisch als erste bevorzugte Sprache an, dann Deutsch als zweite. Italienisch ist auf dem Server www.example.be nicht verfügbar, die Seiten werden auf Deutsch ausgeliefert, die Benutzerin ist zufrieden, alles in Ordnung. Dafür ist Sprachvereinbarung da!</li>
<li>Sylvia ist technisch nicht so versiert, hat nie von HTTP-Sprachvereinbarung gehört und noch nie das Bedürfnis gehabt, die Einstellungen ihres Browsers zu verändern. Dieser ist eine italienische Version und gibt (korrekt) Italienisch als bevorzugte Sprache an. Aber www.example.be gibt es nicht auf Italienisch und die Website-Voreinstellung Flämisch wird ausgeliefert, obwohl Deutsch verfügbar ist. Schlecht.</li>
<li>Sylvia benutzt nicht ihren eigenen Browser, sondern sitzt in einem Internet-Café in Moskau. Der Browser dort ist auf Russisch eingestellt. Und wieder bekommt sie Flämisch zu lesen. Schlecht.</li>
</ol>
<p>Die Beispiele zeigen: Sprachvereinbarung liefert nicht immer das gewünschte Ergebnis.</p>
<p id="equivalence">Außerdem ist Sprachvereinbarung <em>irrelevant</em>, wenn die Seiten nicht äquivalent sind, also in verschiedenen Sprachen nicht den gleichen Inhalt haben. Die FAQ <a class="print" href="qa-mono-multilingual"><cite>Einsprachige vs. mehrsprachige Websites</cite></a> beleuchtet diesen Aspekt, siehe insbesondere die Abschnitte <em>„Mehrsprachig, gleicher Inhalt“</em> und <em>„Mehrsprachig, verschiedener Inhalt“</em>. Allerdings führt ein gewisses Maß an kultureller Anpassung (z.B. Angaben in einer anderen Währung) nicht zwangsläufig zu nicht äquivalenten Webseiten. Sprachvereinbarung kann aber nicht mehr sinnvoll eingesetzt werden, wenn Webseiten nicht äquivalent sind, d.h. Language-Negotiation stößt an ihre Grenzen, wenn eine <em>Website</em> so übertragen wurde, dass sich Seiten in verschiedenen Sprachversionen nicht einander entsprechen.</p>
</section>
<section id="overrides">
<h3>Behebung der Schwachstellen</h3>
<p>Trotz ihrer Grenzen ist Sprachvereinbarung eine nützliche Funktion und sollte bei mehrsprachigen Websites implementiert werden. Aber ihre Schwachstellen müssen beachtet werden. Kurz gesagt, es ist wichtig, dem Besucher Mittel in die Hand zu geben, die automatische Sprachauswahl zu <em>umgehen</em>, falls erforderlich. Das bedeutet, Interface-Elemente in die Seite zu einzubauen (nennen wir sie hier <em>Sprachauswahl-Elemente</em>), die zu den anderen verfügbaren Sprachversionen verlinken. Diese Sprachauswahl-Elemente müssen natürlich klar erkennbar sein und dem Nutzer verständlich, auch wenn er mit der gerade angezeigten Sprache nicht vertraut ist.</p>
<p>Es stellt sich die Frage: Sollen Sprachvereinbarung und manuelle Sprachauswahl für alle Seiten implementiert werden oder nur für die Startseite? Die beste Antwort ist „für alle Seiten“, außer für solche Seiten, die nicht <a href="#equivalence">hinreichend äquivalent</a> sind. Sprachvereinbarung ist nützlich, denn wenn Jaap einen Link innerhalb von www.example.be an Pierre mailt, bekommt Pierre die französische Version zu lesen, obwohl Jaap die flämische gelesen hatte. Sprachauswahl-Elemente müssen immer angeboten werden, egal ob Sprachvereinbarung implementiert ist oder nicht. Wenn keine Sprachvereinbarung durchgeführt wird, benötigt Pierre die Sprachauswahl-Elemente, um von Jaaps Link zur französischen Version zu gelangen; auch wenn Sprachvereinbarung durchgeführt wird, muss Sylvia in den oben genannten Situationen 2 und 3 manuell auf Deutsch umschalten können.</p>
<p>Übrigens: Einige Websites liefern eine spezielle Sprachauswahl-Seite aus, wenn es keine Übereinstimmung zwischen den vom Nutzer bevorzugten und den verfügbaren Sprachen gibt. (www.example.be könnte dies auch tun, anstatt Flämisch auszuliefern.) Das hat den Vorteil, dass die Situation klar ist und keine Sprache einer anderen vorgezogen wird, was politisch bedenklich sein könnte. Unglücklicherweise liefern einige Websites immer eine solche Seite (als Startseite) <em>anstatt</em> Sprachvereinbarung durchzuführen. Dadurch muss jeder über diese Seite gehen – ohne ersichtlichen Nutzen. Nicht nutzerfreundlich.</p>
</section>
<section id="stickyness">
<h3>Navigation</h3>
<p>Angenommen, Sylvia besucht www.example.be und bekommt Flämisch (Situationen 2 und 3). Sie wählt dann die deutsche Version aus, kein Problem. Aber dann folgt sie einem Link zu einer anderen interessanten Seite auf dieser Website. Oh, wieder Flämisch! Glücklicherweise ist das Sprachauswahl-Element für Deutsch immer noch vorhanden, aber nach einigem solchen Hin-und-Her wird sie verständlicherweise verärgert sein. Kann sich www.example.be nicht einfach merken, dass sie kein Flämisch lesen kann? Was hier fehlt, ist <em>Konsistenz</em>, eine Art „Gedächtnis“ für die explizite Sprachauswahl.</p>
<p>Es gibt verschiedene Wege, wie sich www.example.be die Sprachauswahl merken kann. Welcher gewählt wird, hängt von der auf dem Server verfügbaren Technologie und dem zu erwartenden Arbeitsaufwand ab.</p>
<p>Wenn die Website einen <em>Session</em>-Mechanismus bereitstellt (z.B. durch <a
class="print" href="ftp://ftp.rfc-editor.org/in-notes/rfc2965.txt">Cookies</a>), dann ist es ein Leichtes, die Sprache mit in den Session-Zustand einfließen zu lassen. Wenn Sylvia auf das Sprachauswahl-Element für Deutsch clickt, wird dies gespeichert (entweder im Cookie selbst oder auf dem Server, Zuordnung über eine <em>Session-Nummer</em> im Cookie) und von da an bekommt sie die deutschen Sprachversionen der Seiten, wenn sie durch die Website navigiert. Der Cookie kann sogar dauerhaft gespeichert werden (allerdings kommen hier Fragen des Datenschutzes ins Spiel), so dass Sylvia auch wieder automatisch die deutschen Seiten bekommt, wenn sie das nächste Mal www.example.be besucht. Websites, die einen Login-Mechanismus anbieten, können die bevorzugten Sprachen auch in den Nutzerprofilen speichern und die Seiten entsprechend ausliefern. Sprachvereinbarung kommt dann nur bei nicht eingeloggten Nutzern zur Anwendung.</p>
<div class="sidenoteGroup">
<p>Ein anderer Weg, der Verärgerung entgegenzuwirken, ist, alle internen Links innerhalb der Website <em>sprachspezifisch</em> zu machen. Auf der deutschen Homepage hätten Links zu weiteren Seiten die Form <code>href="company/about<b>.de</b>.html"</code> (anstatt <code>company/about.html</code>, was <em>generisch</em> wäre)*. Bei der Navigation bleibt man auf den deutschen Seiten, bis man wieder eine andere Sprache auswählt. Dies hat jedoch auch einige Nachteile. Einer ist, dass alle internen Links bei der Übersetzung angepasst werden müssen, was sowohl die Kosten als auch das mögliche Fehlerpotential erhöht. Ein anderer ist: Wenn Jaap einen Link an Pierre schickt, dann ist der URI (aus der Adressleiste des Browsers herauskopiert) sprachspezifisch; Pierre wird die flämische Seite bekommen. Keiner dieser Nachteile ist jedoch gravierend, und so sind sprachspezifische Links ein gangbarer Weg, wenn die Konsistenz nicht mit einem Session- oder Nutzerprofil-Mechanismus erreicht werden kann.</p>
<aside class="sideinfonote"><p class="footnote">Die tatsächlichen Formen der hier gezeigten sprachspezifischen und generischen URIs (company/about<b>.de</b>.html bzw. company/about.html) hängen von der Technologie ab, mit der Sprachvereinbarung auf dem Server implementiert wurde. Wenn <a class="print" href="/International/questions/qa-apache-lang-neg" lang="en">Apache MultiViews</a> verwendet wurde, würde man auch eher company/about.html<b>.de</b> bzw. company/about.html sehen oder ganz ohne .html-Endung: company/about<b>.de</b> bzw. company/about.</p></aside>
</div>
</section>
</section>
<section id="bytheway">
<h2>Übrigens</h2>
<p>Der HTTP-<span lang="en"><code class="kw" translate="no">Accept-Language</code>-Header</span> ist nicht die einzige verfügbare Quelle für die Sprachinformation. Alle Browser senden auch einen <span lang="en"><code class="kw" translate="no">User-Agent</code>-Header</span>, der den Hersteller, die Versionsnummer und in einigen Fällen auch die Sprachversion des Browsers angibt. Dieser kann genutzt werden, um die bevorzugte Sprache des Nutzers zu erraten, wenn der <span lang="en"><code class="kw" translate="no">Accept-Language</code>-Header</span> fehlt, was aber nicht so zuverlässig und nur auf eine Sprache beschränkt ist. Nur mit äußerster Vorsicht zu benutzen.</p>
<p>Sprachvereinbarung ist nur ein Aspekt von HTTP-Inhaltsvereinbarung (<span lang="en">content negotiation</span>). Andere Aspekte, die automatisch vereinbart werden können, sind der Medientyp (d.h. das Format: z.B. HTML, PDF oder Text), die Zeichencodierung und die Übertragungscodierung (verschlüsselt, komprimiert usw.). Sprachvereinbarung ist der nützlichste und am meisten verwandte.</p>
</section>
<section id="endlinks">
<h2>Literaturhinweise</h2>
<aside class="section" id="survey"> </aside><script>document.getElementById('survey').innerHTML = g.survey</script>
<ul id="full-links">
<li>
<p><a href="qa-lang-priorities">Einstellung der bevorzugten Sprachen im Browser</a> </p>
</li>
<li>
<p><a href="qa-apache-lang-neg">Einrichtung von MultiViews-Sprachvereinbarung auf Apache</a> </p>
</li>
<li>
<p>Verwandte Links: <cite>Server-Konfiguration</cite></p>
<ul>
<li><a href="/International/techniques/server-setup#language">Sprache</a></li>
<li><a href="/International/techniques/server-setup#multiviews">Einrichtung von MultiViews-Sprachvereinbarung auf Apache</a></li>
<li><a href="/International/techniques/server-setup#langvalues">Sprachkennzeichnungen wählen</a></li>
</ul>
</li>
</ul>
</section>
<footer id="thefooter"></footer><script>document.getElementById('thefooter').innerHTML = g.bottomOfPage</script>
<script>completePage()</script>
</body>
</html>