<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>DECAF° blog für digitale kommunikation &#187; Mehrsprachigkeit</title>
	<atom:link href="http://blog.decaf.de/schlagwort/mehrsprachigkeit/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.decaf.de</link>
	<description></description>
	<lastBuildDate>Thu, 17 Nov 2011 09:55:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Gebrauchstaugliche Mehrsprachigkeit: it&#8217;s all about Sprachfolge</title>
		<link>http://blog.decaf.de/2007/10/gebrauchstaugliche-mehrsprachigkeit-its-all-about-sprachfolge/</link>
		<comments>http://blog.decaf.de/2007/10/gebrauchstaugliche-mehrsprachigkeit-its-all-about-sprachfolge/#comments</comments>
		<pubDate>Fri, 19 Oct 2007 07:57:08 +0000</pubDate>
		<dc:creator>Dirk Schürjohann</dc:creator>
				<category><![CDATA[#]]></category>
		<category><![CDATA[Wichtige Artikel]]></category>
		<category><![CDATA[CMS]]></category>
		<category><![CDATA[Kommunikation]]></category>
		<category><![CDATA[Mehrsprachigkeit]]></category>

		<guid isPermaLink="false">http://blog.decaf.de/2007/10/gebrauchstaugliche-mehrsprachigkeit-its-all-about-sprachfolge</guid>
		<description><![CDATA[Mehrsprachige Websites zu entwickeln scheint im ersten Moment recht einfach: man spiegelt die vorhandene Struktur und den Content, done. Wer&#8217;s genau nimmt, macht sich noch Gedanken &#252;ber URL-Schemata und die Sprachauswahl (automatisch und manuell), interne Verlinkung oder eine m&#246;gliche Mehrfachverwertung von Inhalten. Und diejenigen, die es sehr genau nehmen, fangen nicht eher mit der Umsetzung ]]></description>
			<content:encoded><![CDATA[<p>Mehrsprachige Websites zu entwickeln scheint im ersten Moment recht einfach: man spiegelt die vorhandene Struktur und den Content, done. Wer&#8217;s genau nimmt, macht sich noch Gedanken &#252;ber URL-Schemata und die Sprachauswahl (automatisch und manuell), interne Verlinkung oder eine m&#246;gliche Mehrfachverwertung von Inhalten. Und diejenigen, die es sehr genau nehmen, fangen nicht eher mit der Umsetzung an, bevor nicht das Wort »<a href="http://de.wikipedia.org/wiki/Content_Negotiation"><strong>Content Negotiation</strong></a>« gefallen ist.</p>
<p>Letzterer ist der Punkt, der von den eben genannten am meisten auf die <strong>Gebrauchstauglichkeit</strong> der Website abzielt. Content Negotiation ist die M&#246;glichkeit, dass ein <em>Jaap</em> einem <em>Pierre</em> einen Link von www.example.be schicken kann, und dass <em>Pierre</em> mit diesem Link die <em>franz&#246;sische</em> Variante der Website aufruft, w&#228;hrend <em>Jaap</em> doch die <em>fl&#228;mische</em> Version der Seite gelesen hatte &mdash; so erkl&#228;rt man es beim <a href="http://www.w3.org/International/questions/qa-when-lang-neg">W3C</a>. Gebrauchstauglichkeit deshalb, weil die Ausgabe des Inhalts sich nach der im Browser angegebenen Sprachfolge von Jaap und Pierre richtet, ohne dass die Jungs daf&#252;r irgendwas auf der Website angeklicken m&#252;ssen (wobei sie nat&#252;rlich auch manuell die Sprache wechseln k&#246;nnen).</p>
<p>It&#8217;s all about Sprachfolge, und das macht&#8217;s im Backend ein St&#252;ck weit komplizierter als anfangs noch angenommen. Neben den technischen Fragen sollte man auch &#252;ber <em>konzeptionelle</em> Fragen nachdenken, etwa: was bekommen Nutzer zu sehen, die wichtige Einstellungsm&#246;glichkeiten ihres Browsers zurecht nicht auf der vierten Ebene eines unscheinbaren Men&#252;s vermuten, und dessen Firefox deshalb ausschlie&#223;lich Englisch spricht? Und wie l&#228;uft das eigentlich f&#252;r mich als Anbieter mit Fotos und anderen Medieninhalten auf meiner Website: muss ich nun jedes Bild in allen Sprachen einstellen und klicke mich in Bildergalerien noch um den Verstand?</p>
<p>Nein, Mehrsprachigkeit ist nicht einfach. Aber wenn wir schonmal dabei sind, sollten wir drei Ma&#223;nahmen beachten:</p>
<p><span id="more-98"></span></p>
<div class="clear mb2"></div>
<h3>3x Mehrsprachigkeit mit Gebrauchstauglichkeit, bitte! Zum Mitnehmen.</h3>
<ol>
<li>
<p><strong>Eine sinnvolle Sprachfolge</strong></p>
<p>Die Inhalte der Website sollten nat&#252;rlich zuerst in der prim&#228;ren Landessprache des Nutzers erscheinen. Ist der Inhalt einer Seite jedoch nicht in dieser Sprache verf&#252;gbar, wird auf die n&#228;chste Sprache zugegriffen, die der Nutzer &ndash; falls er denn mehrere Sprachen spricht &ndash; hoffentlich in seinem Browser angegeben hat.</p>
<p>Diese Sprachfolge sollte sich nicht nur auf ganze Seiten innerhalb des Webangebots beziehen, sondern kann auch <strong>einzelne Inhaltsbereiche</strong> betreffen. So kann es in der Praxis zum Beispiel vorkommen, dass ein neues Produkt in den Onlinekatalog des Unternehmens aufgenommen wird, ohne dass zu diesem Zeitpunkt schon alle &#220;bersetzungen verf&#252;gbar sind. In diesem Fall ist es sinnvoll, dass <i>Jaap</i>, der Fl&#228;me, nicht etwa alles auf Englisch sieht, sondern dass die Navigation und alle begleitenden Inhalte in Fl&#228;misch ausgegeben werden, w&#228;hrend nur der innere Teil der Produktansicht, f&#252;r den noch keine &#220;bersetzungen verf&#252;gbar sind, auf Englisch ausgegeben wird. An dieser Stelle wird der nachfolgende Punkt besonders wichtig:</p>
</li>
<li>
<p><strong>Ein Hinweis auf fehlende Inhalte in der ausgew&#228;hlten Landessprache</strong></p>
<p>Ist ein Inhalt nicht in der Landessprache des Benutzers vorhanden, sollte dieser einen Hinweis darauf &ndash; nat&#252;rlich in seiner Landessprache formuliert &ndash; bekommen. Als freundlicher Inhaltsanbieter k&#246;nnte man dem Nutzer bei der Gelegenheit auch gleich mitteilen, an wen er sich mit dringenden Fragen wenden kann, um eine &#220;bersetzung zu erhalten.</p>
<p>Wichtig also: fehlende Inhalte in einer Sprachversion m&#252;ssen markiert werden.</p>
</li>
<li>
<p><strong>Inhalte im Backend direkt f&#252;r alle Sprachen &#252;bernehmen</strong></p>
<p>Gebrauchstauglichkeit nicht nur f&#252;r den Nutzer, sondern auch f&#252;r den Anbieter: Beim Einpflegen von Inhalten kann man ihm viele Schritte abnehmen, wenn man Inhalte, die f&#252;r alle Sprachen in gleicher Form gelten, von Anfang an verf&#252;gbar macht und f&#252;r alle Sprachen &#252;bernimmt. Das betrifft z.B. das Bildmaterial, Links/URLS, verkn&#252;pfte Download-Ressourcen, Kontaktdaten, etc. &#8211; Vielleicht gibt das CMS von Haus aus bereits alle Inhalte vor, um sie 1:1 lesen und &#252;bersetzen zu k&#246;nnen &ndash; prima. In allen anderen F&#228;llen &ndash; und die werden in unserer Gegend der kleinen und <del>feinen</del> freien CMS &#252;berwiegen &ndash; sollte man es nicht allein dem Redakteur &#252;berlassen, die Inhalte vollst&#228;ndig und in richtiger Reihenfolge erfassen zu m&#252;ssen, sondern man kann ihm einen Haufen Arbeit dadurch abnehmen, dass man ihm bekannte Strukturen und Inhalte schon vorgibt, um die er <i>drumrum</i> schreiben kann.</p>
<p>Davon profitiert letztendlich wieder der Nutzer, auch wenn er das wohl niemals erfahren wird.</p>
</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://blog.decaf.de/2007/10/gebrauchstaugliche-mehrsprachigkeit-its-all-about-sprachfolge/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

