Wege zur Integration mehrerer Sprachen in Internetplattformen und virtuelle Gemeinschaften
Dieser Artikel ist ein Kapitel aus meiner Diplomarbeit (3.2 Sprache, S.35-39). Alle Stellen, die das in der Arbeit konzipierte Projekt betreffen, wurden herausgekürzt. Ansonsten ist der Text unverändert und zitierfähig. Auch eine englische Übersetzung ist verfügbar.
Eine der wichtigsten Entscheidungen beim Aufbau einer Internetplattform betrifft die zu unterstützenden Sprachen.
Die von den meisten Internetnutzern verstandene Sprache ist – wenig überraschend – Englisch. Schon allein die knapp 300 Millionen Muttersprachler (vgl. Global Reach 2004) sind eine beeindruckende Masse, zu der noch die Menschen hinzugerechnet werden müssen, die Englisch als Fremdsprache beherrschen. Auch die Zahl der Benutzer mit Breitbandanschlüssen […] ist im englischen Sprachraum größer. (vgl. Internet World Stats 2004)
Langsam beginnt Englisch allerdings seine Dominanz zu verlieren. Insbesondere der chinesische Internetsprachraum wächst rasant (vgl. iResearch 2005), aber auch Japanisch und Spanisch nehmen an Bedeutung zu (vgl. Internet World Stats 2005).
Trotzdem dürfte für ein deutsches Projekt außer Deutsch lediglich noch Englisch in Frage kommen. Andere aufstrebende Sprachen sind zu wenig verbreitet um den Aufwand der Übersetzung (zumindest in der Startphase) zu rechtfertigen. Zudem spricht in Deutschland kaum jemand diese Sprachen, sodass der Aufwand bei der Wartung und Kontrolle der eigenen Plattform deutlich vergrößert wird. Ganz zu schweigen davon, dass man auch Mitarbeiter braucht, die die fremdsprachlichen Gruppen in der Gemeinschaft betreuen können.
Deutsch als Nische
„Sogar eine globale Marke braucht eine nationale Identität.“ (Ries / Ries 2001, S. 97) Bei einem rein englischen Angebot würde einem wahrscheinlich mangelndes Lokalbewusstsein unterstellt werden (vgl. Michael 2003, S. 9). Zudem ist man für gewöhnlich im Umgang mit seinem eigenen Kulturkreis am sichersten. Dies ist besonders in der Anfangsphase wichtig, wenn sich die Gemeinschaft noch entwickeln muss und auch die Betreiber und Betreuer der Plattform erst ein Gefühl dafür entwickeln müssen, wie sie mit der entstehenden Community umgehen sollen.
Erfahrungsgemäß erlangen viele virtuelle Gemeinschaften – falls sie nicht mit einem massiven Werbebudget ausgestattet sind – den ersten Schub an Mitgliedern durch intensive Mundpropaganda. (vgl. Sotira 2003) Wenn so Freunde für die Plattform begeistert werden sollen, macht es auf diese wiederum keinen überragend guten Eindruck, wenn nur eine Fremdsprache angeboten wird – denn 79% der Deutschen bevorzugen Webseiten in ihrer Muttersprache (vgl. Maceviciute o.D.). Auch die Bindung der deutschen Nutzer an die Plattform ist höher, wenn sie sich aufgrund der vertrauten Sprache mehr „zuhause“ fühlen.
[…]
Englisch als Option
Dennoch liegt der Versuch nahe, auch den internationalen Markt mit seinem enormen Nutzerpotential zu erschließen. Schließlich erweitert man damit nicht nur den Kreis der Menschen, die angesprochen werden können, sondern bekämpft von Anfang an das Aufkeimen internationaler Konkurrenz.
Englisch hat dabei den Vorteil, dass man trotz der stärkeren Verbreitung von Sprachen wie Chinesisch und Spanisch noch immer die meisten Menschen damit erreicht. Zudem finden sich leichter Mitarbeiter, die Englisch sprechen, als Mitarbeiter, die irgendeine andere Fremdsprache sprechen. Dies erleichtert die Wartung und Mitgliederbetreuung der englischen Fassung.
Es gibt drei grundsätzliche Möglichkeiten, mehrsprachige Webseiten aufzubauen:
- verschiedene Sprachfassungen unter demselben Serverpfad
- verschiedene Sprachfassungen unter verschiedenen Serverpfaden
- verschiedene Sprachfassungen auf verschiedenen Domains
Bei Variante 1 wird bei Abruf der Seiten vom Webserver überprüft, welche Sprache gewünscht wird, und die entsprechende Fassung ausgeliefert. Besucht ein Benutzer mit einer anderen Sprachpräferenz dieselbe Seite, bekommt er auch die Fassung in der von ihm gewünschten Sprache. Da alle gebräuchlichen Browser eine Sprachkennung mitliefern, kann den Benutzern so ohne ihr Zutun die passende Sprache geliefert werden. Natürlich ist es auch möglich, diese Voreinstellung auf Wunsch des Benutzers zu übergehen.
Eine andere Möglichkeit besteht darin, die einzelnen Sprachfassungen unter unterschiedlichen Adressen abrufbar zu machen. Dann wäre die Adresse für eine deutsche Seite beispielsweise http://server.de/de/xyz/ und die Adresse für den entsprechenden englischen Inhalt http://server.de/en/xyz/. Bei diesem Modell muss einmal eine Entscheidung für eine Sprache getroffen werden – entweder wieder automatisch, oder per manueller Auswahl des Benutzers -, die den Benutzer auf den richtigen Pfad führt. Danach bewegt sich der Benutzer sowieso immer im selben Sprach-Pfad, bis er sich gezielt entscheidet ihn zu wechseln.
Für die dritte Variante benötigt man zwei Domains, also beispielsweise domain.de und domain. com. Unter jeder Domain ist jeweils eine Sprachfassung zu erreichen. Nicolas Michael (2003, S.8) bezeichnet dies als die beste, wenn auch teuerste Lösung. Allerdings bezieht er sich dabei auf Lösungen, die auch auf komplett getrennten Systemen und getrennter Administration basieren, deswegen muss der Preisunterschied nicht zwangsweise eintreten. Technisch ist es problemlos möglich – und häufig die Regel – mehrere Domains auf demselben Server zu betreiben.
Da alle Varianten technisch kein Problem darstellen, ist es letztlich eine Frage des „URIDesigns“ (vgl. Lima / Powell o.D.; Berners-Lee 1998; Théreaux et al. 2003), für welches Adress-Schema man sich entscheidet.
Nachtrag (nicht Teil der Diplomarbeit)
Das erste Schema bringt allerdings einige Schwierigkeiten mit sich. Dadurch, dass sich die Sprache automatisch an die Browser-Einstellungen anpasst, sind verschiedene Sprachen nicht mehr unter einer eindeutigen Adresse erreichbar. So ist es nicht möglich, beispielsweise einen Link auf einen englischen Text zu setzen, da sich erst beim Abruf der Inhalte entscheidet, in welcher Sprache sie ausgeliefert werden. Dies ist insbesondere für Suchmaschinen problematisch, da diese nicht in der Lage sind, verschiedensprachige Inhalte unter der selben Adresse zu indexieren. Auch die verbreiteten Zugriffsanalyse-Programme können die Nutzung der einzelnen Sprachen nicht differenzieren.
Für solche Fälle müssen also spezielle Lösungen geschaffen werden (beispielsweise ein zusätzlicher optionaler URL-Parameter um die Sprache gezielt festzulegen), die mehr Aufwand und mehr Komplikationen bedeuten. Dieser Aufwand erscheint zumindest mir nicht gerechtfertigt, daher möchte ich von dieser Lösung abraten.
Literatur
Ahmed, Bashir / Cha, Sung-Hyuk / Tappert, Charles (2004): Language Identification from Text Using N-gram Based Cumulative Frequency Addition
In: Proceedings of Student/Faculty Research Day, CSIS, Pace University, May 7th, 2004
Berners-Lee, Tim (1998): Cool URIs don’t change
Cavnar, William B. / Trenkle, John M. (1994): N-Gram-Based Text Categorization
In: Proceedings of SDAIR-94, 3rd Annual Symposium on Document Analysis and Information Retrieval
Global Reach (2004): Global Internet Statistics
Grefenstette, Gregory (1995): Comparing two language identification schemes
In: Proceedings of the 3rd International Conference on the Statistical Analysis of Textual Data
Grefenstette, Gregory / Nioche, Julien (2000): Estimation of English and non-English Language Use on the WWW
In: Proceedings of RIAO’2000, „Content-Based Multimedia Information Access“, Paris, April 12-14,2000, pp. 237-246
Internet World Stats (2004): DSL Broadband Internet Subscribers – Top 20 Countries
Internet World Stats (2005): Internet Usage By Language
iResearch (2005): China’s Internet Users Top 100 Million
Lima, Joe / Powell, Thomas A. (ohne Datum): Towards Next Generation URLs
Maceviciute, Elena (ohne Datum): Multilingual Virtual World: Languages on the Internet
Michael, Nicolas (2003): Sprache im Internet
Ries, Al / Ries, Laura (2001): Die 11 unumstößlichen Gebote des Internet-Branding
Sotira, Angelo (2003): The real story behind devART
Théreaux, Olivier / Bournez, Carine / Dubost, Karl / Guild, Ted / Lafon, Yves (2003): Common HTTP Implementation Problems
© 2005 Florian Sander