Mehrsprachiges Portfolio: Ein globales Publikum erreichen

Warum Sprache wichtig ist

Hier ist eine Zahl, die verändert hat, wie ich über das Web denke: 75% der Internetnutzer kaufen lieber Produkte in ihrer Muttersprache. Selbst wenn sie Englisch verstehen, vertrauen sie Inhalten in ihrer eigenen Sprache mehr. Sie bleiben länger. Sie engagieren sich tiefer.

Für ein Portfolio trägt diese Erkenntnis Gewicht. Ein Personalverantwortlicher in São Paulo, der meine Arbeit durchsieht, sollte nicht mental übersetzen müssen, während er meine Fähigkeiten bewertet. Ein potenzieller Mitarbeiter in Tokio sollte das Gefühl haben, dass die Website mit ihm im Sinn gebaut wurde. Sprache geht nicht nur ums Verstehen. Es geht um Respekt, Vertrauen und das Gefühl, dass man hierher gehört.

Ein nur-englisches Portfolio sendet eine unbeabsichtigte Botschaft: "Das ist zuerst für Englischsprachige, alle anderen zweitrangig." Ich wollte das umdrehen. Ich wollte, dass Besucher aus Brasilien, Spanien, Japan und Frankreich auf meiner Website landen und denken: "Oh, diese Person versteht es."

Übersetzung vs. Lokalisierung: Eine wichtige Unterscheidung

Früh in diesem Projekt lernte ich etwas, das die meisten Menschen übersehen: Übersetzung und Lokalisierung sind nicht dasselbe.

Übersetzung konvertiert Wörter von einer Sprache in eine andere. Es ist mechanisch. "Contact me" wird zu "Contáctame" auf Spanisch. Fertig.

Lokalisierung passt das gesamte Erlebnis für eine spezifische Kultur an. Sie berücksichtigt Kontext, Erwartungen und Konventionen. Eine lokalisierte Website tauscht nicht nur Wörter aus. Sie fühlt sich nativ an.

Hier wird diese Unterscheidung in der Tech-Welt relevant: Ein brasilianischer Entwickler, der über "Data Pipelines" liest, erwartet "Data Pipelines" zu sehen, nicht "canalizações de dados". Der englische Begriff ist Industriestandard. Ihn zu übersetzen würde sich seltsam anfühlen, sogar herablassend. Ebenso bleibt "Dashboard" ein "Dashboard", weil das ist, was Entwickler in São Paulo, Tokio und Paris tatsächlich sagen.

Lokalisierung bedeutet zu wissen, wann man NICHT übersetzen sollte. Es bedeutet zu verstehen, dass japanische Leser "Next.js" und "TypeScript" auf Englisch erwarten, aber Navigationslabels auf Japanisch. Es bedeutet zu erkennen, dass ein französischer Marketer "Growth Marketing" in Gesprächen verwendet, nicht "marketing de croissance".

Diese Erkenntnis formte das gesamte System. Ich baute kein Übersetzungstool. Ich baute eine Lokalisierungsengine, die Übersetzung strategisch einsetzt.

Die Herausforderung

Manuelle Lokalisierung skaliert nicht. Übersetzer für jeden Blogpost, jedes Projekt-Update und jede UI-Änderung zu beauftragen, würde einen Engpass schaffen. Schlimmer noch, es würde mich so sehr verlangsamen, dass ich ganz aufhören würde, in mehreren Sprachen zu veröffentlichen. Die Wartungslast würde gewinnen.

Ich brauchte ein System mit drei Eigenschaften:

1. Geschwindigkeit. Neue Inhalte sollten in Minuten lokalisiert werden, nicht in Tagen.
2. Intelligenz. Das System sollte wissen, was zu übersetzen und was zu bewahren ist.
3. Resilienz. Unvollständige Übersetzungen sollten die Website nie kaputt machen.

Die Lösung

Die Architektur kombiniert next-intl für locale-bewusstes Routing mit DeepLs Übersetzungs-API für hochwertige automatisierte Übersetzung. Eine benutzerdefinierte Übersetzungspipeline behandelt die Nuancen.

Das Besuchererlebnis:

Wenn jemand ankommt, erkennt das System seine Browsersprache. Wenn er auf Portugiesisch eingestellt ist, sieht er /pt-BR/blog mit portugiesischen Inhalten. Japanische Besucher sehen /ja/projects mit japanischem Text. Die URL-Struktur ist sauber, lesbar und suchmaschinenfreundlich.

Wenn eine bestimmte Seite noch nicht übersetzt wurde, sehen Besucher stattdessen die englische Version. Dieser Fallback passiert still. Keine kaputten Seiten, keine "Übersetzung kommt bald"-Nachrichten. Nur Inhalt.

Der Content-Workflow:

Ich schreibe alles einmal auf Englisch. Ein Übersetzungsskript verarbeitet den Inhalt durch DeepL, wendet Lokalisierungsregeln an und generiert locale-spezifische Dateien. Die gesamte Pipeline läuft in unter 30 Sekunden.

Wie das Übersetzungsskript funktioniert

Das Skript verarbeitet sowohl UI-Strings (Buttons, Navigation, Fehlermeldungen) als auch Langform-Inhalte (Blogposts, Projektbeschreibungen, die Über-Seite). Es bewahrt die Frontmatter-Struktur, erhält Markdown-Formatierung und lässt Codeblöcke unberührt.

Der Prozess:

1. Englische Quelldateien lesen (MDX oder JSON)
2. Übersetzbaren Inhalt extrahieren, während die Struktur erhalten bleibt
3. Text an DeepL API mit Zielsprache senden
4. Lokalisierungsregeln anwenden (technische Begriffe, Produktnamen bewahren)
5. Locale-spezifische Dateien schreiben (z.B. post.pt-BR.mdx)

Lokalisierungsregeln in der Praxis

Das System folgt expliziten Regeln darüber, was zu übersetzen und was zu bewahren ist:

Immer übersetzen:

• Navigation und UI-Labels
• Artikelinhalte und Beschreibungen
• Formularfelder und Fehlermeldungen
• Calls to Action

Immer auf Englisch bewahren:

• Produktnamen: Next.js, TypeScript, DeepL, Cursor
• Firmennamen: Nike, Meta, Rocket Internet
• Technische Begriffe: API, Dashboard, Data Pipeline, Template
• Code-Beispiele und Dateipfade

Sprachspezifische Anpassungen:

• Portugiesisch (Brasilien): "dashboard" nicht "painel", "template" nicht "modelo"
• Spanisch: "marketers" nicht "vendedores", "data pipelines" nicht "canalizaciones de datos"
• Japanisch: Produktnamen auf Englisch, gängige Lehnwörter in Katakana
• Französisch: "dashboard" nicht "tableaux de bord", natürliche CTAs wie "Contactez-moi"

Diese Regeln produzieren Übersetzungen, die sich für technikaffine Leser in jedem Locale natürlich anfühlen. Der Inhalt liest sich, als wäre er für sie geschrieben, nicht an sie übersetzt.

Ergebnisse

Für Besucher:

• Inhalte von Tag eins in 5 Sprachen verfügbar
• Automatische Spracherkennung basierend auf Browser-Einstellungen
• Konsistente Erfahrung über alle Seiten und Sprachen
• Keine Sackgassen, kaputten Seiten oder "Inhalt nicht verfügbar"-Nachrichten

Für Suchmaschinen:

• Einzigartige, indexierbare URLs für jede Sprache (/en/blog, /ja/blog, /pt-BR/blog)
• Korrekte hreflang-Tags für genaue Sprachindexierung
• Bessere Sichtbarkeit in lokalen Suchergebnissen über mehrere Länder

Für laufende Wartung:

• Neue Inhalte in unter 30 Sekunden lokalisiert
• Single Source of Truth auf Englisch
• Keine manuelle Dateiverwaltung pro Sprache
• Sicher veröffentlichen, während Übersetzungen in Arbeit sind

Was ich gelernt habe

Dieses System zu bauen lehrte mich, dass Lokalisierung eine Produktentscheidung ist, nicht nur eine technische. Jede Entscheidung darüber, was übersetzt werden soll (und was nicht), spiegelt ein Verständnis der Zielgruppe wider.

Die größte Erkenntnis: Respektiere die Expertise deiner Nutzer. Ein Entwickler in Japan braucht "TypeScript" nicht ins Japanische übersetzt. Er braucht den Inhalt drumherum, der sich in seiner Sprache natürlich anfühlt. Diese Balance richtig hinzubekommen ist der Unterschied zwischen einer Website, die sich übersetzt anfühlt, und einer, die sich nativ anfühlt.

Dieses Portfolio erreicht jetzt ein globales Publikum ohne den Overhead, separate Codebases für jede Sprache zu pflegen. Noch wichtiger, es zeigt Besuchern, dass ihre Sprache und ihr Kontext mir wichtig sind. In einem Bereich, wo jedes Portfolio gleich aussieht, macht das einen Unterschied.

Ein Hinweis zu den Übersetzungen

Die Übersetzungen auf dieser Website werden mit der DeepL API generiert und dann basierend auf den oben beschriebenen Lokalisierungsrichtlinien überprüft und verfeinert. Automatisierte Übersetzung ist ein Ausgangspunkt, kein fertiges Produkt.

Wenn dir etwas auffällt, das sich in deiner Sprache seltsam liest, oder du Verbesserungsvorschläge hast, würde ich mich über dein Feedback über das Kontaktformular freuen. Lokalisierung ist ein fortlaufender Prozess, und Muttersprachler fangen Nuancen ab, die Automatisierung übersieht.