Hinweis: Dieser Inhalt wurde automatisch übersetzt. Feedback senden

Mehrsprachiges Portfolio: ein globales Publikum erreichen

Rolle: Full-Stack-EntwicklerDez. 2025

Ein Portfolio in sechs Sprachen, bei dem das Schwierigste war zu entscheiden, was nicht übersetzt wird.


Die Entscheidung, die alles geprägt hat

Wer in Brasilien entwickelt und über "data pipelines" liest, erwartet data pipelines, nicht canalizações de dados. Der englische Begriff ist der Begriff der Branche. Ihn zu übersetzen wirkt bestenfalls hölzern, schlimmstenfalls herablassend.

Dieses eine Beispiel hat die Regel für das ganze System gesetzt: Die Arbeit besteht nicht darin, ein Portfolio in sechs Sprachen zu übersetzen. Sie besteht darin, Begriff für Begriff zu entscheiden, was unübersetzt bleiben soll — und diese Entscheidung dann reproduzierbar zu machen.

Was das System macht

Die Site läuft auf next-intl mit localePrefix: 'always', jede Route liegt also unter einem Locale-Segment. i18n/config.ts definiert sechs:

export const locales = ['en', 'pt-BR', 'es', 'ja', 'fr', 'de'] as const;
Englische Quelle
Einmal auf Englisch schreiben
DeepL oder Claude
Übersetzung oder Transkreation
Localization-Regeln
Regeln für Fachbegriffe anwenden
Locale-Dateien
Sechs Locale-Versionen

Content liegt in Dateien mit Locale-Suffix. hello-world.mdx ist die englische Basis; hello-world.pt-BR.mdx und hello-world.ja.mdx liegen daneben. lib/content.ts sucht die Datei des angefragten Locale und fällt auf die englische Basis zurück, wenn sie fehlt.

Sortier-Metadaten kommen immer aus der Basisdatei. Datum, pinned und lastUpdated werden unabhängig vom gerenderten Locale aus der englischen Quelle gelesen. Ein Beitrag kann in der japanischen Liste also keine andere Position einnehmen als in der englischen.

UI-Strings fallen per Deep Merge zurück. i18n/request.ts lädt messages/en.json als Basis und merged den Locale-Katalog darüber, Key für Key. Ein fehlender Key rendert den englischen String statt eines MISSING_MESSAGE-Fehlers, und ein halbfertiger Katalog lässt sich gefahrlos ausliefern.

Der Fallback ist gekennzeichnet, nicht stumm

Eine frühere Fassung dieser Seite behauptete, der Fallback auf Englisch passiere stillschweigend. Das war das falsche Ziel, und so verhält sich die Site nicht.

Wenn eine Seite zurückfällt, gibt getContentLocaleStatus() 'fallback' zurück, und zwei Dinge folgen: Das Content-Element wird mit lang="en" markiert, damit Screenreader und Suchmaschinen erfahren, welche Sprache sie tatsächlich bekommen, und über dem Inhalt erscheint ein sichtbarer Übersetzungshinweis.

Unter einer /ja/-URL klammheimlich Englisch auszuliefern würde Lesende wie Crawler in die Irre führen. Es zu sagen kostet eine Zeile UI.

Zwei Pipelines, zwei Aufgaben

DeepL übernimmt die direkte Übersetzung: schnell, konsistent und anfällig dafür, Fachvokabular zu übersetzen, das besser englisch bliebe. Ein Claude-Agent übernimmt die Transkreation: Er passt Redewendungen an, stellt Sätze für einen natürlichen Fluss um und hält Fachbegriffe nach den Regeln unten auf Englisch.

npm run translate      # DeepL: messages/*.json
npm run translate:mdx  # DeepL: MDX content
npm run i18n:mdx       # Claude: transcreation
npm run i18n:sync      # Claude: fill missing translations

Beide schreiben Dateien mit Locale-Suffix neben die englische Quelle. Keiner wird blind übernommen: Das Ergebnis wird vor dem Ausliefern gegengelesen — Frontmatter-Keys bleiben englisch, Bildpfade und URLs unverändert, Codeblöcke und Tabellen intakt, className-Werte nicht übersetzt.

Localization-Regeln in der Praxis

Immer übersetzen: Navigation und UI-Labels, Artikelinhalte, Formularfelder, Calls to Action.

Immer englisch lassen: Produktnamen (Next.js, TypeScript, Claude), Firmennamen (Nike, Meta) und das Fachvokabular, das das jeweilige Publikum ohnehin englisch benutzt — API, Dashboard, Data Pipeline, Template.

Pro Locale:

  • pt-BR — "dashboard" statt "painel", "template" statt "modelo", "e-commerce" statt "comércio eletrônico"
  • es — "dashboard" statt "panel de control", "marketers" statt "vendedores"
  • ja — Produktnamen in lateinischer Schrift, nicht in Katakana; Katakana für gängige Lehnwörter
  • fr — "dashboard" statt "tableau de bord"; natürliche CTAs ("Contactez-moi")
  • de — informelles "du", englische Lehnwörter für Fachbegriffe, Substantive großgeschrieben
Wie 'Projects' in jeder Sprache erscheint

Projects

ENWörtliche Übersetzung

canalizações de dados

PT-BRLokalisiert (beibehalten)

data pipelines

Was ich mir am Anfang sagen würde

Localization ist eine Produktentscheidung im technischen Kostüm. Die Pipeline war der leichte Teil; die Regeln darüber, was man in Ruhe lässt, waren die eigentliche Arbeit — und genau der Teil, der aufgeschrieben gehört, weil ein Übersetzungstool ihn jedes Mal fröhlich falsch macht.

Der Maßstab ist nicht, dass die Site sechs Sprachen hat. Der Maßstab ist, dass jemand in São Paulo oder Tokio genau das Vokabular vorfindet, das er selbst benutzt hätte.

Hinweis zu den Übersetzungen

Die Übersetzungen hier entstehen maschinell und werden anschließend gegen die obigen Regeln geprüft. Maschinelle Übersetzung ist ein Ausgangspunkt, kein fertiges Produkt.

Wenn etwas in deiner Sprache schief klingt, freue ich mich über die Korrektur über das Kontaktformular. Muttersprachler bemerken, was Automatisierung übersieht.

Ergebnisse

  • Sechs Locales: Englisch, Portugiesisch (Brasilien), Spanisch, Japanisch, Französisch und Deutsch
  • Zwei Pipelines: DeepL für direkte Übersetzung, ein Claude-Agent für Transkreation
  • URLs pro Locale mit hreflang-Alternates für jede Sprache
  • Fehlende Übersetzungen fallen auf Englisch zurück, gekennzeichnet statt versteckt
  • Localization-Regeln halten die Fachbegriffe auf Englisch, die das jeweilige Publikum erwartet