Die Übersetzungsfalle: Was mir der Aufbau einer mehrsprachigen Website über Respekt beigebracht hat
Ich dachte, fünf Sprachen zu meinem Portfolio hinzuzufügen wäre eine technische Herausforderung. Es stellte sich als Lektion in Empathie heraus.
Als ich in Brasilien aufwuchs, lernte ich Englisch durch amerikanische TV-Shows mit Untertiteln. Ich erinnere mich an die ungeschickten Übersetzungen. "Cool" wurde zu "legal." Slang wurde zu Lehrbuch-Portugiesisch abgeflacht. Die Wörter waren korrekt. Das Gefühl war falsch.
Zwanzig Jahre später baute ich ein Übersetzungsskript für mein Portfolio. Innerhalb einer Stunde konvertierte es "Next.js dashboard" in "painel do Next.js."
Ich zuckte zusammen. Kein brasilianischer Entwickler sagt "painel." Wir sagen einfach Dashboard.
Ich tat dasselbe wie diese Untertitel-Übersetzer. Wörter konvertieren statt Bedeutung anzupassen.
Warum das wichtig ist
Untersuchungen zeigen, dass 75% der Internetnutzer Inhalte in ihrer Muttersprache bevorzugen, selbst wenn sie Englisch verstehen. Es geht nicht ums Verstehen. Es geht um Vertrauen. Das Gefühl von "das wurde für jemanden wie mich gemacht."
Für ein Portfolio ist dieses Gefühl wichtig. Wenn ein Personalverantwortlicher in Tokio auf meiner Website landet, möchte ich, dass er meine Arbeit bewertet, nicht im Kopf übersetzt. Wenn jemand in Paris über meine Projekte liest, möchte ich, dass er über Ideen nachdenkt, nicht über Sprache.
Ein englischsprachiges Portfolio sendet eine Botschaft: "Das ist zuerst für Englischsprachige, alle anderen sind zweitrangig." Ich wollte das umdrehen.
Was mir die Lokalisierungscommunity beigebracht hat
Dieser "Dashboard"-Fehler schickte mich in den Lokalisierungs-Kaninchenbau. Ich las Blogposts von i18n-Engineers, durchsuchte GitHub-Diskussionen und studierte, wie große Tech-Unternehmen mit Übersetzung umgehen.
Das Muster war konsistent über alle Quellen hinweg.
Technische Zielgruppen teilen ein Vokabular, das Grenzen überschreitet. Brasilianische Entwickler sagen "Data Pipeline," nicht "canalização de dados." Japanische Engineers behalten "TypeScript" als TypeScript. Französische Marketer verwenden "Growth Marketing," nicht das Lehrbuch-französische Äquivalent.
Diese Begriffe wurden auf Englisch gelernt. Sie werden auf Englisch diskutiert. Sie zu übersetzen schafft Verwirrung, nicht Klarheit.
Mein Skript war zu gründlich. Es übersetzte Dinge, die auf Englisch bleiben sollten.
Übersetzung versus Lokalisierung
Diese Unterscheidung wurde zur Kernerkenntnis des Projekts.
Übersetzung konvertiert Wörter. Lokalisierung passt Erlebnisse an.
Eine übersetzte Website sagt "painel de controle", weil das Wörterbuch es so sagt. Eine lokalisierte Website sagt "Dashboard", weil das brasilianische Entwickler tatsächlich sagen.
Eine übersetzte Website konvertiert jeden Begriff. Eine lokalisierte Website weiß, wann man aufhören sollte. Ein Entwickler in Japan braucht Navigation auf Japanisch, erwartet aber technische Begriffe auf Englisch. Diese Balance lässt Inhalt native wirken statt übersetzt.
Ich schrieb meinen Ansatz um. Navigationslabels werden übersetzt. Produktnamen bleiben Englisch. Technische Begriffe bleiben Englisch. Erklärender Inhalt wird natürlich übersetzt.
Die Regeln, die ich aufgestellt habe
Nach genug behobenen Fehlern tauchten Muster auf. Ich dokumentierte sie:
Auf Englisch belassen: Produktnamen wie Next.js, TypeScript, Claude. Branchenbegriffe wie Dashboard, Data Pipeline, Growth Marketing, E-Commerce. Skills-Sektionen und Zertifizierungsnamen.
Übersetzen: Navigationselemente, Formularlabels, narrativen Inhalt, Abschnittsüberschriften.
Sprachspezifische Anpassungen:
Für Portugiesisch, verwende "dashboard" nicht "painel," verwende "template" nicht "modelo." Brasilianische Entwickler haben diese Begriffe auf Englisch gelernt und verwenden sie täglich.
Für Spanisch, verwende "dashboard" nicht "cuadros de mando," verwende "marketers" nicht "vendedores," verwende "data pipelines" nicht "canalizaciones de datos."
Für Japanisch, behalte Produktnamen auf Englisch (Next.js, nicht ネクストジェイエス). Katakana funktioniert für gängige Lehnwörter wie ダッシュボード (Dashboard).
Für Französisch, verwende "dashboard" nicht "tableaux de bord," verwende "marketers" nicht "spécialistes du marketing."
Für Deutsch, verwende "Dashboard" nicht "Armaturenbrett," verwende "Template" nicht "Vorlage" im Tech-Kontext. Deutsche Entwickler sind mit englischen Fachbegriffen sehr vertraut.
Diese Regeln leben jetzt in meiner Projektdokumentation. Jedes Mal, wenn ich Inhalte übersetze, prüfe ich sie dagegen.
Der Moment, als es klickte
Das erste Mal, als ich meine Website auf Japanisch lud, veränderte sich etwas.
Ich spreche kein Japanisch. Ich kann es nicht lesen, außer ein paar Zeichen. Aber da war es: mein Portfolio, meine Projekte, in einer Sprache dargestellt, die ich nicht kenne.
Die Navigation sagte "プロジェクト" (Projekte). Der Fließtext war auf Japanisch. Aber "Next.js" blieb "Next.js." "TypeScript" blieb "TypeScript." Die Balance fühlte sich richtig an.
Inhalt, der für jedes Publikum geschrieben wurde, nicht an sie übersetzt. Diese Unterscheidung fasst alles zusammen, was ich gelernt habe.
Die Kosten, es nicht zu tun
Die meisten Portfolios, die ich sehe, sind nur auf Englisch. Das ist okay. Englisch ist die Lingua Franca der Tech-Welt.
Aber wenn jemand auf deiner Website landet und mentale Übersetzungsarbeit leisten muss, hast du Reibung hinzugefügt. Sie könnten schneller abspringen. Sie könnten weniger verstehen. Sie könnten weniger vertrauen. Diese kognitive Belastung ist unsichtbar, aber real.
Eine mehrsprachige Website sagt: "Ich habe an dich gedacht. Ich habe das für dich gemacht. Dein Kontext ist wichtig."
In einem Bereich, in dem jedes Portfolio auf denselben Frameworks läuft und ähnliche Projekte zeigt, fällt diese Rücksichtnahme auf.
Der technische Teil, kurz
Das System verwendet next-intl für Routing und die DeepL-API für die initiale Übersetzung. Ich schrieb Skripte, die MDX-Dateien verarbeiten, Frontmatter bewahren und Lokalisierungsregeln anwenden. Die ganze Pipeline läuft in unter 30 Sekunden.
Aber automatisierte Übersetzung ist nur der erste Durchgang. Nachdem DeepL die initiale Version generiert, bitte ich Claude, jede Übersetzung gegen Lokalisierungs-Best-Practices zu prüfen. Claude fängt Begriffe ab, die auf Englisch bleiben sollten, korrigiert ungeschickte Formulierungen und stellt sicher, dass technisches Vokabular dem entspricht, was Entwickler in jedem Locale tatsächlich verwenden.
Diese Kombination aus Geschwindigkeit und Qualität ist wichtig. Wenn Lokalisierung stundenlange manuelle Arbeit kosten würde, würde ich aufhören, es zu tun.
Für technische Details siehe die Projektseite. Dieser Post handelt von der Reise.
Was ich gelernt habe
Ich begann mit Gedanken an Reichweite. Mehr Sprachen, mehr Besucher, besseres SEO. Diese Dinge sind wahr, aber sie sind nicht der Punkt.
Die echte Lektion war Empathie. Für ein globales Publikum zu bauen zwang mich, über Menschen nachzudenken, deren Kontext ich nicht teile.
Für Portugiesisch hatte ich einen Vorteil. Ich bin Muttersprachler. Ich kann Ungeschicklichkeit sofort erkennen. Für Japanisch und Französisch musste ich mich darauf verlassen, was die Lokalisierungscommunity dokumentiert hat. Was Blogposts und Style Guides darüber sagen, wie technische Zielgruppen tatsächlich kommunizieren.
Diese Abhängigkeit von externem Wissen ist demütigend. Du kannst nicht annehmen, dass deine Defaults universell sind. Du musst Menschen dort abholen, wo sie sind.
Eine stehende Einladung
Die Übersetzungen auf dieser Website sind nicht perfekt. Automatisierte Übersetzung ist ein Ausgangspunkt. Muttersprachler fangen Nuancen ab, die Algorithmen übersehen.
Wenn du etwas auf Portugiesisch, Spanisch, Japanisch, Französisch oder Deutsch liest, das sich falsch anhört, lass es mich über das Kontaktformular wissen. Ich würde es schätzen.
Lokalisierung ist nie fertig. Es ist ein fortlaufendes Gespräch zwischen Builder und Publikum. Für ein globales Publikum zu bauen bedeutet, offen zu bleiben für Feedback von Menschen, die ihren Kontext besser kennen als du es jemals wirst.