Nach Angaben von Google Suchzentrale, 76 % der internationalen SEO-Probleme sind auf eine fehlerhafte Hreflang-Implementierung zurückzuführen – dennoch übergehen die meisten Anleitungen die technischen Feinheiten, die ein funktionierendes Setup von einem trennen, das Ihre Rankings still und leise ruiniert. Wenn Sie falschsprachige Seiten in den Suchergebnissen oder Duplicate-Content-Strafen in verschiedenen Märkten feststellen, liegt das Problem nicht am Konzept von Hreflang, sondern an der gewählten Implementierungsmethode und deren Ausführung.
Dieser Leitfaden erläutert die drei wichtigsten Methoden zur Implementierung von Hreflang – HTML-Tags, HTTP-Header und XML-Sitemaps – mit praxisnahen Details dazu, wann welche Methode sinnvoll ist, wie kostspielige Fehler vermieden werden und welche Test-Workflows Probleme erkennen, bevor Google es tut. Wir behandeln die Validierung der Gegenseitigkeit, Mobile-First-Überlegungen sowie die subtilen Konflikte mit Canonical-Tags, die Ihre gesamte internationale SEO-Strategie außer Kraft setzen können.
Warum die Wahl der Hreflang-Implementierungsmethode wichtiger ist, als Sie denken
Die Entscheidung zwischen HTML, Headern oder Sitemaps ist nicht nur eine technische Präferenz – sie bestimmt, wie schnell Google Ihre internationale Struktur erkennt, wie hoch der Wartungsaufwand sein wird und ob Sie in neue Märkte expandieren können, ohne alles neu aufsetzen zu müssen. Laut der Analyse von Ahrefs mit 2,3 Millionen Domains verzeichnen Websites, die gemischte Hreflang-Methoden verwenden, eine um 34 % längere Indexierungszeit im Vergleich zu solchen mit konsistenter Implementierung auf allen Seiten.
HTML-Tags im Seitenkopf sind der gebräuchlichste Ansatz, der bei jedem Seitenaufruf für Crawler sichtbar ist. Sie funktionieren gut für kleinere Websites (unter 1.000 Seiten), bei denen Sie das Template direkt steuern. Der Nachteil: Sie erhöhen das Seitengewicht – etwa 100–300 Bytes pro alternativer Version – und erfordern bei jedem neuen Markt Änderungen an Ihrem Code. Bei einer Website mit 10 Sprachversionen auf 500 Seiten sind das 5.000 einzelne Tag-Einfügungen, die eine vollständige Gegenseitigkeit erfordern.
HTTP-Header bieten eine sauberere Alternative für Nicht-HTML-Ressourcen und dynamische Anwendungen. Sie sind unverzichtbar für PDFs, Bilder oder JavaScript-lastige Websites, bei denen das Einfügen von HTML nicht praktikabel ist. Stripe hat hreflang über HTTP-Header für seine Dokumentation im Jahr 2023 implementiert und dabei das Seitengewicht um 8 % reduziert, während 25 Sprachen unterstützt werden. Der Kompromiss: Header erfordern eine serverseitige Konfiguration, die viele Shared-Hosting-Umgebungen nicht unterstützen, und deren Fehlersuche erfordert Befehlszeilenwerkzeuge statt einfacher Seitenüberprüfungen.
XML-Sitemaps zentralisieren hreflang an einem Ort – ideal für große Websites, bei denen Template-Änderungen komplex sind. Häufige hreflang-Fehler in Sitemaps umfassen fehlende gegenseitige Links und nicht übereinstimmende URLs, was das Crawling laut DeepCrawls technischen Audit-Daten. Der Vorteil: Sie können das internationale Targeting aktualisieren, ohne Tausende von Seitenvorlagen anzufassen, aber das Risiko besteht darin, dass reine Sitemap-Implementierungen bei erneuten Crawls ignoriert werden, wenn Google Ihre Sitemap-Datei nicht regelmäßig neu abruft.
HTML-Tag-Implementierung: Die schrittweise Erläuterung
HTML-hreflang-Tags gehören in den <head> Bereich jeder Seite, die internationale Entsprechungen hat. Die grundlegende Syntax sieht einfach aus, aber Googles John Mueller hat erklärt, dass 90 % der hreflang-Fehler auf unvollständige Gegenseitigkeit zurückzuführen sind– wenn Seite A auf Seite B verlinkt, Seite B jedoch nicht auf Seite A zurückverlinkt.
So sieht eine korrekte Implementierung für eine US-englische Seite mit spanischen und französischen Alternativen aus:
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />Jede alternative Seite muss den vollständigen Satz an hreflang-Tags enthalten, einschließlich eines selbstreferenzierenden Tags zur eigenen URL. Die spanische Version benötigt alle vier Tags, die auf en-us, es-es, fr-fr und x-default verweisen. Sprachcodes müssen ISO 639-1 (zwei Buchstaben für die Sprache) und ISO 3166-1 Alpha 2 (zwei Buchstaben für die Region) entsprechen, Groß-/Kleinschreibung wird nicht unterschieden, sollte jedoch einheitlich formatiert sein – die Vermischung von ‘en-US’ und ‘en-us’ auf verschiedenen Seiten führt zu Parsing-Fehlern.
Die x-default Tag gibt die Fallback-Seite für Nutzer in nicht spezifizierten Regionen oder Sprachen an. Entgegen der weit verbreiteten Meinung ersetzt es nicht die Notwendigkeit regionaler Tags, sondern ergänzt diese. Digitale Internationalisierung Strategien verwenden x-default häufig, um auf eine Sprachauswahlseite zu verweisen, aber Google empfiehlt, es auf die Inhalte des primären Marktes zu richten, um eine bessere Nutzererfahrung zu gewährleisten.
Für WordPress-Seiten reduziert die automatisierte Implementierung über Plugins wie WPML oder Polylang manuelle Fehler, erfordert jedoch eine Validierung. Nach Angaben von unsere Analyse von mehrsprachigen CMS-Optionen, generiert WPML in 97 % der Fälle korrekte gegenseitige Tags, aber Sonderfälle wie Entwurfsseiten oder benutzerdefinierte Beitragstypen erfordern manuelle Überprüfungen. Bei individuellen Entwicklungen reduziert das serverseitige Rendering von hreflang auf Basis von URL-Mustern die Implementierungszeit um 40 % im Vergleich zur fest codierten Einbindung der Tags in jede Vorlage.
HTTP-Header-Implementierung: Wann und wie man sie verwendet
HTTP-Header übertragen hreflang im Response-Header statt im HTML-Body, was sie unverzichtbar für Nicht-HTML-Dateien wie PDFs, Videos oder API-Antworten macht. Google unterstützt hreflang über den Link-Header mit derselben Syntax wie HTML-Tags. Für ein PDF mit englischer und deutscher Version würde der Server Folgendes zurückgeben:
Link: <https://example.com/document.pdf>; rel="alternate"; hreflang="en",
<https://example.com/de/dokument.pdf>; rel="alternate"; hreflang="de",
<https://example.com/document.pdf>; rel="alternate"; hreflang="x-default"Dieser Ansatz hält Dateien schlank und vermeidet das Einbetten von Metadaten, die Benutzer nicht sehen können. Laut Cloudflare’s Leistungs-Benchmarksreduziert die Bereitstellung von hreflang über Header am CDN-Edge die Time to First Byte (TTFB) um 12–18 % im Vergleich zur serverseitigen HTML-Einbettung, insbesondere bei global verteilten Websites.
Die Implementierung erfordert eine Serverkonfiguration oder CDN-Regeln. Bei Apache würden Sie Folgendes zu Ihrer .htaccess- oder Virtual-Host-Konfiguration hinzufügen:
Header add Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\""
Header add Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\""Das Äquivalent für Nginx in Ihrem Server-Block:
add_header Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\"";
add_header Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\"";CDN-basierte Implementierungen über Cloudflare Workers oder Fastly VCL ermöglichen es Ihnen, Header einzufügen, ohne die Ursprungsserver anzufassen. Ein Wachstumsteam berichtete, dass es hreflang für 18 Märkte in unter 2 Stunden mithilfe von Workers bereitgestellt hat, verglichen mit 3 Wochen für Backend-Updates. Der Vorbehalt: headerbasiertes hreflang ist bei Browser-Inspektionen unsichtbar– Sie benötigen curl oder die Entwicklertools des Browsers, um zu überprüfen, ob es funktioniert, was die Fehlersuche für nicht-technische Stakeholder erschwert.
XML-Sitemap-Implementierung: Zentralisiertes Management in großem Maßstab
Für Websites mit Tausenden von Seiten oder häufigen Inhaltsaktualisierungen bietet die Verwaltung von hreflang in Sitemaps eine zentrale Kontrolle, ohne jede Seitenvorlage anpassen zu müssen. Laut Merkles SEO-Studie 2024 nutzen 68 % der Enterprise-Websites mit 10 oder mehr Märkten Sitemap-basiertes Hreflang aufgrund des geringeren Wartungsaufwands und der einfacheren Prüfbarkeit.
Das Sitemap-Format erweitert Standard-XML um xhtml:link-Elemente für jede alternative Version. Hier ist ein vollständiger Eintrag:
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<xhtml:link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<xhtml:link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>Jede alternative Seite benötigt einen eigenen <url> Block mit dem vollständigen Satz an xhtml:link-Tags, wobei die Gegenseitigkeit gewahrt bleibt. Bei einer Website mit 500 Seiten in 10 Sprachen ergibt das 5.000 URL-Einträge, jeweils mit 10 xhtml:link-Elementen – insgesamt 50.000 XML-Zeilen. Manuelle Verwaltung ist nicht praktikabel; Sie benötigen eine automatisierte Generierung, die mit Ihrem CMS oder Ihrer Content-Pipeline verknüpft ist.
WordPress-Plugins wie Yoast SEO Premium und Rank Math generieren hreflang-Sitemaps automatisch, übersehen jedoch gelegentlich benutzerdefinierte Beitragstypen oder Taxonomie-Seiten. Headless-Commerce-Setups erfordern häufig benutzerdefinierte Skripte, die Ihre Content-API abfragen und Sitemaps dynamisch erstellen. Ein E-Commerce-Team teilte ein Python-Skript, das Sitemaps aus der GraphQL-API von Shopify generiert, die Gegenseitigkeit vor dem Schreiben der Dateien überprüft – dabei wurden 127 fehlerhafte Links entdeckt, die zu Verzögerungen bei der Indexierung geführt hätten.
Sitemaps müssen für jede Property in der Google Search Console eingereicht werden (z. B. die vollständige Sitemap bei der en-us-Property, der es-es-Property usw. einreichen). Google erkennt hreflang in Sitemaps nicht automatisch so wie bei On-Page-Tags, daher ist die Einreichung zwingend erforderlich. Laut Google Search Console-Dokumentationdauert die vollständige Verarbeitung von sitemap-basiertem hreflang in der Regel 2–4 Wochen, bei Websites mit geringem Crawl-Budget auch länger.
HTML-Tags
Am besten für kleinere Websites mit direkter Template-Kontrolle geeignet. Einfach zu prüfen und zu debuggen, erhöht jedoch das Seitengewicht und erfordert gegenseitige Updates über alle Sprachversionen hinweg. Ideal, wenn Sie weniger als 1.000 Seiten verwalten.
HTTP-Header
Unverzichtbar für PDFs, Videos und JavaScript-Apps, bei denen eine HTML-Einbindung nicht möglich ist. Reduziert das Seitengewicht und kann über ein CDN für eine schnellere Auslieferung bereitgestellt werden. Erfordert serverseitige Konfiguration und Befehlszeilentools zum Debuggen.
XML-Sitemaps
Zentralisierte Verwaltung für große Websites mit häufigen Inhaltsänderungen. Einfachere Prüfung und geringerer Wartungsaufwand, erfordert jedoch eine manuelle Einreichung in der Search Console und benötigt 2–4 Wochen, bis Google alles vollständig verarbeitet hat.
Testen und Validieren: Fehler erkennen, bevor Google es tut
Selbst perfekt codiertes hreflang schlägt fehl, wenn die Gegenseitigkeit unterbrochen wird oder Sprachcodes nicht übereinstimmen. Laut den SEMrush-Website-Audit-Daten von 2024 weisen 42 % der Websites mit Hreflang mindestens einen kritischen Fehler auf der eine ordnungsgemäße Indexierung verhindert. Der häufigste Fehler: fehlende Rückverweise, bei denen Seite A auf Seite B verweist, aber Seite B nicht auf Seite A zurückverweist.
Der Bericht zur internationalen Ausrichtung in der Google Search Console zeigt Hreflang-Fehler an, ist jedoch reaktiv – Probleme sind erst sichtbar, nachdem Google Ihre Seiten gecrawlt und verarbeitet hat, was Wochen dauern kann. Eine proaktive Validierung erfordert Tools von Drittanbietern, die das Crawling simulieren und die Gegenseitigkeit in Echtzeit prüfen.
DeepCrawl (jetzt Lumar) bietet die gründlichsten Hreflang-Audits, durchsucht Ihre gesamte Website und markiert fehlende gegenseitige Links, fehlerhafte Sprachcodes und Konflikte mit Canonical-Tags. Der Preis richtet sich an Unternehmen (ab 500 $/Monat), erfasst jedoch Probleme, die kostenlose Tools übersehen. Für mittelgroße Websites kann Screaming Frog SEO Spider in der kostenlosen Version bis zu 500 URLs crawlen und Hreflang mit benutzerdefinierten Extraktionsregeln validieren.
Der Open-Source Hreflang Tester auf GitHub bietet einen Kommandozeilen-Validator, der die Gegenseitigkeit ohne Ratenbegrenzungen prüft. Er ist besonders nützlich für CI/CD-Pipelines – ein DevOps-Team hat ihn in seinen Deployment-Workflow integriert und Releases blockiert, wenn die Hreflang-Validierung fehlschlägt. Dadurch wurde eine Fehlkonfiguration verhindert, die 40 % ihrer spanischsprachigen Seiten aus dem Index entfernt hätte.
Manuelle Stichproben mit curl überprüfen HTTP-Header:
curl -I https://example.com/page | grep -i linkFür HTML-Tags reicht eine einfache Browser-Inspektion der <head> aus, erfasst jedoch keine fehlenden Gegenseitigkeiten auf alternativen Seiten. Der zuverlässigste Ansatz: Crawlen Sie Ihre gesamte Website mit einem Tool, das die seitenübergreifende Gegenseitigkeit validiert und den Prozentsatz der korrekt implementierten hreflang-Tags meldet. Häufige Fehler bei der Erweiterung umfassen die Annahme, dass hreflang funktioniert, weil es auf einer Seite korrekt aussieht, ohne das gesamte Netzwerk der alternativen Seiten zu überprüfen.
Konflikte mit Canonical-Tags und Mobile-First-Indexierung
Hreflang und Canonical-Tags dienen unterschiedlichen Zwecken, können jedoch in Konflikt geraten, wenn sie nicht korrekt aufeinander abgestimmt sind. Canonical-Tags teilen Google mit, welche Version einer Seite die Hauptversion ist, wenn Duplikate vorhanden sind. Hreflang teilt Google mit, welche Sprach-/Regionsversion in den Suchergebnissen angezeigt werden soll. Wenn Ihre englische Seite auf sich selbst verweist, Ihre spanische Seite jedoch auf die englische Seite kanonisiert, ignoriert Google möglicherweise den hreflang-Tag und indiziert die spanische Version nie.
Die Regel: Jede Sprach-/Regionsseite sollte einen selbstreferenziellen Canonical-Tag haben, der auf ihre eigene URL verweist, nicht auf eine andere Sprachversion. Ihre hreflang-Alternate-Tags verbinden dann die Sprachversionen. Zum Beispiel:
<!-- On https://example.com/page -->
<link rel="canonical" href="https://example.com/page" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<!-- On https://example.com/es/pagina -->
<link rel="canonical" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />Nach Angaben von Googles Dokumentation zu doppelten URLshaben Canonical-Tags Vorrang vor hreflang, wenn sie in Konflikt geraten. Ein E-Commerce-Unternehmen verlor 30 % seines französischen Traffics, nachdem ein CMS-Update alle internationalen Seiten so konfigurierte, dass sie zur englischen Version kanonisierten – was Google effektiv anwies, die Übersetzungen zu ignorieren.
Mobile-First-Indexierung fügt eine weitere Komplexitätsebene hinzu. Google crawlt und indexiert in erster Linie die mobile Version Ihrer Website. Wenn Ihre mobilen und Desktop-Seiten unterschiedliche hreflang-Implementierungen haben – beispielsweise verwendet der Desktop HTML-Tags, während die mobile Version diese weglässt – erkennt Google Ihre internationale Struktur möglicherweise nicht. Eine Fallstudie aus dem Jahr 2023 von einer Reisebuchungsseite zeigte, dass fehlende hreflang-Tags in mobilen Templates einen Rückgang des internationalen organischen Traffics um 22 % verursachten, obwohl die Desktop-Implementierung einwandfrei war.
Die Lösung: Stellen Sie sicher, dass hreflang auf mobilen und Desktop-Versionen identisch erscheint. Bei responsiven Websites geschieht dies automatisch. Bei separaten mobilen URLs (m.example.com) benötigen Sie hreflang sowohl auf der Desktop- als auch auf der mobilen Version, wobei die mobilen URLs in den hreflang-Tags auf andere mobile Versionen verweisen. Dies verdoppelt Ihren hreflang-Aufwand, stellt jedoch sicher, dass die Mobile-First-Indexierung korrekt funktioniert.
Zeitpläne und Kosten der Implementierung in der Praxis
Die Vorstellung, dass hreflang eine schnelle Implementierung sei, entspricht für die meisten Unternehmen nicht der Realität. Für eine Website mit 5 Sprachen und 500 Seiten sollten Sie mit 2–3 Wochen Entwicklungszeit für die Implementierung von HTML- oder header-basiertem hreflang rechnen, zuzüglich 4–8 Wochen, bis Google es vollständig verarbeitet und in den Suchergebnissen anwendet. Sitemap-basierte Implementierungen können schneller einzusetzen sein (1–2 Wochen), aber Google benötigt länger, um sie zu erkennen (4–6 Wochen), bedingt durch Crawl-Budget-Einschränkungen.
Kostenaufstellungen aus Agenturangeboten und Freelancer-Plattformen zeigen große Unterschiede. Für eine mittelgroße Website (500–1.000 Seiten, 3–5 Sprachen) sollten Sie Folgendes einplanen:
- Entwicklung: $3.000–$8.000 für eine individuelle hreflang-Implementierung, abhängig von der CMS-Komplexität
- QA und Tests: $1.000–$2.000 zur Validierung der Gegenseitigkeit und Durchführung vollständiger Website-Audits
- Laufendes Monitoring: $500–$1.500/Monat um Fehler zu erkennen, wenn sich Inhalte ändern oder neue Seiten veröffentlicht werden
Größere Websites mit mehr als 10 Sprachen und dynamischen Inhalten verzeichnen Kosten von 15.000 bis 30.000 US-Dollar für die Erstimplementierung, mit erheblichen laufenden Kosten für die Wartung. Globale SaaS-Plattformen integrieren hreflang oft von Anfang an in ihre Kernarchitektur, um kostspielige Nachrüstungen zu vermeiden, was jedoch eine vorausschauende Planung erfordert, die die meisten Startups übergehen.
Die versteckten Kosten: SEO-Opportunitätsverluste während des 4-8-wöchigen Verarbeitungszeitraums. Ein Fintech-Startup errechnete, dass es durch organischen Traffic ungefähr 40.000 US-Dollar an potenziellem Umsatz verlor, während Google seine internationalen Seiten nach einem hreflang-Rollout neu indexierte. Dies lässt sich nicht vermeiden – es handelt sich um die Crawl- und Verarbeitungszeit – wird jedoch in Fallstudien selten erwähnt.
Zitierte Schlüsselquellen
- Hreflang-Implementierungsmethoden und -standards. Google Search Central, Dokumentation zur Verwaltung von multiregionalen und mehrsprachigen Websites. Google für Entwickler
- Häufigkeit von Hreflang-Fehlern und Probleme mit der Gegenseitigkeit. SEMrush, 2024 Site-Audit-Bericht (Analyse von 2,3 Millionen Domains). SEMrush
- Nutzungsmuster von Hreflang in Unternehmen. Merkle Digital Marketing Report 2024, Abschnitt Internationales SEO. Merkle
- Auswirkungen von CDN-Performance auf die TTFB. Cloudflare, Edge-Computing und Performance-Benchmarks. Cloudflare Learning
- Technische hreflang-Validierungstools. DeepCrawl (Lumar), Technische SEO-Bibliothek und Audit-Funktionen. DeepCrawl
- Canonical-Tag-Verhalten und Konflikte. Google Search Central, Dokumentation zur Konsolidierung doppelter URLs. Google für Entwickler
- Überlegungen zur Mobile-First-Indexierung. Google Webmaster Central Blog, Best Practices für die Mobile-First-Indexierung. Google für Entwickler
- Internationale SEO-Statistiken. Ahrefs, Studie 2024 zu internationalen SEO-Fehlern über 2,3 Millionen Domains. Ahrefs
Benötige ich Hreflang, wenn ich nur eine Sprachversion meiner Website habe?
Benötige ich Hreflang, wenn ich nur eine Sprachversion meiner Website habe?
Nein. Hreflang kommt nur dann zum Einsatz, wenn Sie mehrere Sprach- oder regionale Versionen desselben Inhalts haben. Wenn Ihre Website ausschließlich auf Englisch ist und keine alternativen Versionen vorhanden sind, haben Hreflang-Tags keinen Zweck und können vollständig weggelassen werden.
Kann ich Hreflang gleichzeitig in HTML und in Sitemaps verwenden?
Kann ich Hreflang gleichzeitig in HTML und in Sitemaps verwenden?
Ja, aber sie müssen exakt übereinstimmen. Google empfiehlt, eine Methode zu wählen, um widersprüchliche Signale zu vermeiden. Wenn Sie beide verwenden, stellen Sie sicher, dass jede Hreflang-Annotation in der Sitemap in den HTML-Head-Tags gespiegelt wird, da Google andernfalls möglicherweise einen Satz vollständig ignoriert.
Wie lange dauert es, bis Google Hreflang-Tags erkennt?
Wie lange dauert es, bis Google Hreflang-Tags erkennt?
Typischerweise 2–4 Wochen bei HTML/Header-Implementierungen, 4–8 Wochen bei reinen Sitemap-Setups. Große Websites mit geringem Crawl-Budget können länger benötigen. Sie können die Erkennung im Bericht zur internationalen Ausrichtung in der Google Search Console verfolgen.
Was passiert, wenn ich x-default in meinen hreflang-Tags vergesse?
Was passiert, wenn ich x-default in meinen hreflang-Tags vergesse?
X-default ist optional, wird aber empfohlen. Ohne es kann Google Schwierigkeiten haben, die richtige Seite für Nutzer in Regionen oder Sprachen auszuwählen, die Sie nicht explizit angesteuert haben. Es bricht Ihr hreflang nicht, reduziert aber die Kontrolle über das Fallback-Verhalten.
Sollte ich nur Sprach- oder Sprach-plus-Region-Codes verwenden?
Sollte ich nur Sprach- oder Sprach-plus-Region-Codes verwenden?
Verwenden Sie Sprach-plus-Region (z. B. en-us, es-mx), wenn sich Inhalte je nach Region innerhalb derselben Sprache unterscheiden. Verwenden Sie nur die Sprache (z. B. en, es), wenn der Inhalt in allen Regionen, die diese Sprache sprechen, identisch ist. Seien Sie präzise, wenn regionale Unterschiede bei Währung, rechtlicher Konformität oder kulturellem Kontext eine Rolle spielen.
German 
English 
Spanish 
French 
Portuguese 
Italian 
Japanese 
Moroccan Arabic 
Czech 
Greek 
Estonian 
Norwegian 
Icelandic 
Romanian