Pluralisierungsregeln in verschiedenen Sprachen: Ein Entwic…

Pluralisierungsregeln in verschiedenen Sprachen: Ein Entwicklerhandbuch

Sie haben ein Feature veröffentlicht. Übersetzungen sind eingepflegt. Auf Englisch sieht alles großartig aus. Dann meldet jemand einen Bug: „Die App sagt ‚1 Artikel im Warenkorb' und ‚5 Artikel im Warenkorb'." Sie beheben es mit einem schnellen ternären Ausdruck. Sechs Monate später berichtet ein Nutzer aus Polen, dass die App durchgehend grammatikalisch falschen Text anzeigt. Sie haben die Pluralisierung nicht kaputt gemacht — Sie haben sie nie wirklich gelöst.

Pluralisierung ist eines der am meisten unterschätzten Probleme bei der Internationalisierung. Die meisten Entwickler behandeln es als binäres Englisch-Problem: Singular versus Plural. Aber natürliche Sprachen sind weit komplexer als das, und im Produktions-i18n schlägt diese Komplexität hart zurück. Dieser Leitfaden erläutert, wie Pluralisierung tatsächlich sprachübergreifend funktioniert, wie man sie korrekt implementiert und wie man die Fehler vermeidet, die bei jedem Code-Review durchrutschen.

Wenn Sie neu bei Internationalisierungskonzepten sind, bietet der Leitfaden zu Lokalisierung und Internationalisierung eine nützliche Grundlage, bevor Sie in sprachspezifische Pluralisierungsmechanismen eintauchen.

Warum Pluralisierung wichtiger ist, als Sie denken

Hier ist ein häufiges Muster in Codebasen:

const label = count === 1 ? 'Artikel' : 'Artikel';

Das funktioniert für Englisch. Für genau zwei Sprachen: Englisch und eine Handvoll ähnlicher Sprachen. In dem Moment, in dem Sie auf Türkisch, Arabisch, Russisch oder Polnisch umsteigen, produziert dieser Ansatz Unsinn — oder schlimmer, Text, der auf eine Weise subtil falsch ist, die sich für Muttersprachler respektlos anfühlt.

Pluralisierungsfehler in der Produktion haben reale Konsequenzen:

Vertrauensverlust: Muttersprachler erkennen schlechte Grammatik sofort. Es signalisiert, dass das Produkt nicht für sie gebaut wurde.
Rechtliches Risiko: In manchen Regionen müssen Mengenausdrücke in Verträgen, Rechnungen oder Compliance-Texten grammatikalisch korrekt sein.
Barrierefreiheitsprobleme: Screenreader und Hilfsmittel sind auf grammatikalisch korrekten Text angewiesen.

Die Ursache ist fast immer dieselbe: Entwickler kodieren englische Plural-Logik fest, und dann bekommen Übersetzer eine Zeichenkette ohne Kontext darüber, welche Form verwendet werden soll.

Englische Pluralformen: Täuschend einfach

Englisch hat zwei Pluralformen: Singular (1) und Plural (alles andere). Das lässt sich sauber auf einen ternären Ausdruck abbilden, weshalb Entwickler standardmäßig darauf zurückgreifen.

// Englisch: zwei Formen, Singular und Plural
`${count} ${count === 1 ? 'Datei' : 'Dateien'} hochgeladen`

Selbst im Englischen wird das mit Randfällen kompliziert:

Null: „0 Dateien" liest sich natürlich, aber manche UIs bevorzugen „Keine Dateien". Das ist eine Designentscheidung, keine Übersetzungsentscheidung — erfordert aber dennoch Unterstützung für Pluralformen.
Brüche: „1,5 Dateien" ist grammatikalisch mehrdeutig. Englisch verwendet für nicht-ganzzahlige Werte typischerweise den Plural, aber das variiert je nach Domäne.
Unregelmäßige Substantive: „1 Person" / „2 Personen", „1 Kind" / „2 Kinder". Diese werden nicht durch einfache Suffixregeln behandelt.

Englisch fühlt sich einfach an, weil es das, relativ gesehen, ist. Sobald man es verlässt, skaliert die Komplexität dramatisch.

Wie andere Sprachen Pluralformen handhaben

Arabisch: Sechs Formen

Arabisch hat sechs grammatikalisch unterschiedliche Pluralformen je nach Zahl:

Form	Zahlen
zero	0
one	1
two	2
few	3–10
many	11–99
other	100+ (und Dezimalzahlen)

Jede Form erfordert ein anderes Wort oder Suffix. Die Zeichenkette „Sie haben X Nachrichten" benötigt auf Arabisch sechs Übersetzungen, nicht zwei. Einem arabischen Übersetzer nur Singular und Plural zu schicken bedeutet, ihn raten zu lassen — und das können sie nicht, weil sich die Nachrichtenstruktur für jede Form unterscheidet.

Russisch und Polnisch: Drei bis vier Formen mit komplexen Regeln

Russisch verwendet drei Formen: Singular (1), wenige (2–4 und Zahlen, die auf 2–4 enden, außer 12–14) und viele (alles andere).

Die Regel für Russisch ist nicht trivial:

n % 10 === 1 && n % 100 !== 11  → Singular
n % 10 >= 2 && n % 10 <= 4 && (n % 100 < 10 || n % 100 >= 20) → wenige
alles andere → viele

Also: „21 файл" (Singular), „22 файла" (wenige), „25 файлов" (viele), „11 файлов" (viele — nicht Singular, weil 11 eine Ausnahme ist).

Polnisch fügt weitere Komplexität mit vier Formen und leicht unterschiedlichen Grenzen hinzu. Wenn Sie das falsch machen, merkt ein russischer oder polnischer Nutzer es sofort. Das sind keine obskuren Randfälle — das sind Zahlen, die in alltäglichen UIs auftauchen.

Japanisch, Chinesisch, Koreanisch: Überhaupt keine Pluralformen

Diese Sprachen unterscheiden grammatikalisch nicht zwischen Singular und Plural. „1 Datei" und „100 Dateien" verwenden dieselbe Substantivform. Stattdessen wird die Menge durch Ziffern, Zähler (Klassifikatoren) oder Kontext ausgedrückt.

Das bedeutet:

Sie sollten für diese Sprachen keine Pluralformen an Übersetzer schicken — Sie bitten sie, Unterschiede zu übersetzen, die nicht existieren.
Die Zahl wird noch angezeigt, inflektiert aber das Substantiv nicht.
Falsche Pluralbehandlung äußert sich hier meist darin, dass Übersetzer die „other"-Form duplizieren, was technisch in Ordnung ist, aber redundante oder unnatürliche Formulierungen erzeugen kann.

Weitere bemerkenswerte Fälle

Slawische Sprachen allgemein (Tschechisch, Slowakisch, Kroatisch): Drei bis vier Formen, komplexe Modulo-Regeln.
Walisisch: Sechs Formen mit sehr unregelmäßigen Grenzen.
Gälisch (Schottisch und Irisch): Formen, die bei 1, 2, 3–10, 11–19 und 20+ aufgeteilt werden.
Hebräisch: Separate Formen für Singular, Dual (genau 2) und Plural.

Der CLDR-Standard für Pluralregeln

Das Unicode Common Locale Data Repository (CLDR) definiert Pluralregeln für jede wichtige Sprache. Das sind die kanonischen Regeln, die von Browsern, Betriebssystemen und i18n-Bibliotheken verwendet werden. Das CLDR kategorisiert Pluralformen in sechs benannte Kategorien:

zero
one
two
few
many
other

Jede Sprache verwendet eine Teilmenge davon. Englisch verwendet one und other. Arabisch verwendet alle sechs. Japanisch verwendet nur other.

Diese Regeln sind in maschinenlesbarer Form verfügbar und bereits in den meisten ausgereiften i18n-Bibliotheken eingebettet. Sie müssen die Mathematik nicht selbst implementieren. Sie müssen verstehen, dass diese Kategorien existieren und dass Ihr Übersetzungs-Workflow alle Formen berücksichtigen muss, die eine bestimmte Sprache erfordert.

ICU MessageFormat: Die richtige Abstraktion

ICU MessageFormat ist der am weitesten verbreitete Standard zur Darstellung von Pluralisierung in Übersetzungszeichenketten. Er bettet die Plural-Logik in die Nachricht selbst ein, sodass Übersetzer jede Form unabhängig bearbeiten können.

Die Syntax für Englisch:

{count, plural,
  one {# Datei hochgeladen}
  other {# Dateien hochgeladen}
}

Für Russisch (wie von einem Übersetzer angegeben, der die Sprache kennt):

{count, plural,
  one {Загружен # файл}
  few {Загружено # файла}
  many {Загружено # файлов}
  other {Загружено # файлов}
}

Das # wird durch die tatsächliche Zahl ersetzt. Die Bibliothek wertet die Pluralregel für das aktive Gebietsschema aus und wählt die richtige Form.

Dieser Ansatz hat gegenüber der String-Verkettung entscheidende Vorteile:

Jede Form ist ein vollständiger Satz, sodass Übersetzer den vollen grammatikalischen Kontext haben.
Keine String-Assemblierung zur Laufzeit — die Nachricht wird vor der Anzeige in eine endgültige Zeichenkette aufgelöst.
Sprachgerechte Formen — Übersetzer stellen genau die Formen bereit, die ihre Sprache benötigt.
Tool-Unterstützung — Linter, Extraktions-Tools und Übersetzungsplattformen verstehen dieses Format.

Pluralisierung mit i18next implementieren

i18next ist eine der am häufigsten verwendeten i18n-Bibliotheken im JavaScript-Ökosystem und verarbeitet CLDR-Pluralregeln nativ.

Grundlegende Einrichtung

import i18next from 'i18next';

i18next.init({
  lng: 'en',
  resources: {
    en: {
      translation: {
        file_count: '{{count}} Datei',
        file_count_other: '{{count}} Dateien',
      },
    },
  },
});

i18next verwendet eine Schlüssel-Suffix-Konvention: key für die Singularform, key_other für den Standard-Plural und key_zero, key_one, key_two, key_few, key_many für zusätzliche CLDR-Formen. Sie übergeben count als Interpolationsvariable, und die Bibliothek wählt automatisch den richtigen Schlüssel.

i18next.t('file_count', { count: 1 });   // "1 Datei"
i18next.t('file_count', { count: 5 });   // "5 Dateien"

React-Integration

Mit react-i18next:

import { useTranslation } from 'react-i18next';

function FileCount({ count }: { count: number }) {
  const { t } = useTranslation();
  return <span>{t('file_count', { count })}</span>;
}

Für /i18n/react-Setups ist das das empfohlene Muster. Die count-Variable steuert sowohl die Interpolation (Anzeige der Zahl) als auch die Auswahl der Pluralform.

Mehrere CLDR-Formen verarbeiten

Für Russisch muss Ihre Übersetzungsdatei alle erforderlichen Formen enthalten:

{
  "file_count_one": "{{count}} файл",
  "file_count_few": "{{count}} файла",
  "file_count_many": "{{count}} файлов",
  "file_count_other": "{{count}} файлов"
}

i18next wendet die korrekte CLDR-Regel für das Gebietsschema an und wählt den richtigen Schlüssel. Die Regelauswertung ist eingebaut — Sie schreiben die Modulo-Logik nicht selbst.

Next.js mit next-i18next

Für /i18n/nextjs-Apps, die next-i18next verwenden, ist das Muster dasselbe, aber Übersetzungen liegen in public/locales/{lng}/{ns}.json:

// public/locales/ru/common.json
{
  "file_count_one": "{{count}} файл",
  "file_count_few": "{{count}} файла",
  "file_count_many": "{{count}} файлов",
  "file_count_other": "{{count}} файлов"
}

import { useTranslation } from 'next-i18next';

export function FileCount({ count }: { count: number }) {
  const { t } = useTranslation('common');
  return <p>{t('file_count', { count })}</p>;
}

Häufige Fallstricke

1. Falscher Variablenname

i18next verwendet speziell count, um die Auswahl der Pluralform auszulösen. Die Verwendung eines anderen Variablennamens überspringt die Plural-Logik vollständig:

// FALSCH — Pluralauswahl wird nicht ausgelöst
t('file_count', { number: 5 });

// RICHTIG
t('file_count', { count: 5 });

Das ist ein stilles Versagen. Die Fallback-Form (_other) wird verwendet, sodass Englisch gut aussehen kann, während andere Sprachen still kaputt gehen.

2. Fehlende Pluralformen für das Zielgebietsschema

Wenn Sie für ein russisches Gebietsschema nur key und key_other definieren, fällt die Bibliothek für alle Formen auf key_other zurück. Russische Nutzer erhalten grammatikalisch falschen Text, und es gibt keinen Fehler in der Konsole. Das ist der häufigste Pluralisierungsfehler in ausgelieferten Softwareprodukten.

Die Lösung besteht darin, alle CLDR-Formen für jedes Gebietsschema vor dem Ausliefern zu verlangen. Automatisieren Sie diese Prüfung — verlassen Sie sich nicht auf manuelle Überprüfung.

3. String-Verkettung statt Plural-Schlüssel

// FALSCH
const message = t('you_have') + ' ' + count + ' ' + t('messages');

// RICHTIG — Zahl und umgebende Wörter sind eine übersetzbare Einheit
t('you_have_messages', { count });

Verkettung macht es strukturell unmöglich, Sprachen zu handhaben, in denen sich Wortstellung, Substantivform oder Verbkongruenz mit der Zahl ändern. Der gesamte Satz, der die Zahl enthält, muss ein einziger Übersetzungsschlüssel sein.

4. Ordinalzahlen mit Pluralformen verwechseln

Ordinalzahlen ("1.", "2.", "3.") folgen völlig anderen Regeln als Kardinalplural. Verwechseln Sie sie nicht. i18next hat separate Ordinal-Unterstützung über die Option ordinal: true:

t('position', { count: 1, ordinal: true });  // "1. Platz"
t('position', { count: 2, ordinal: true });  // "2. Platz"

Ordinalregeln sind ebenfalls gebietsschemaspezifisch — Französisch verwendet beispielsweise „1er" für den ersten und dann dasselbe Suffix für alle folgenden Ordinalzahlen.

5. Null als spezielle Pluralform behandeln

Manche Designs verlangen „Keine Dateien" statt „0 Dateien". Das ist keine Pluralform — es ist eine UI-Entscheidung. Behandeln Sie es explizit im Code, bevor Sie die Übersetzungsfunktion aufrufen, oder verwenden Sie einen separaten Übersetzungsschlüssel:

const key = count === 0 ? 'no_files' : 'file_count';
t(key, { count });

Verlassen Sie sich nicht auf die CLDR-Form zero für UI-Textentscheidungen. Die zero-Form existiert für Sprachen, die Null grammatikalisch von anderen Werten unterscheiden, nicht als Design-Hook.

Pluralübersetzungen testen

Pluralisierungsbehandlung wird notorisch wenig getestet. Einen umfassenderen Blick auf die Strukturierung Ihres i18n-Qualitätsprozesses bietet der Leitfaden zu i18n-Testwerkzeugen und Automatisierungsstrategien, der Werkzeuge behandelt, die neben diesen Mustern integriert werden können.

Grenzwerttests

Testen Sie jeden Grenzwert für die Gebietsschemata, die Sie ausliefern:

const testCounts = [0, 1, 2, 3, 4, 5, 11, 12, 21, 22, 100, 101];

for (const count of testCounts) {
  console.log(`${count}: ${t('file_count', { count })}`);
}

Für Russisch insbesondere: 1, 2, 5, 11, 12, 21, 22, 25, 100, 101, 111, 121.

Snapshot-Tests für jedes Gebietsschema

describe('file_count Pluralisierung', () => {
  it.each([
    ['en', 1, '1 file'],
    ['en', 5, '5 files'],
    ['ru', 1, '1 файл'],
    ['ru', 2, '2 файла'],
    ['ru', 5, '5 файлов'],
    ['ru', 11, '11 файлов'],
    ['ru', 21, '21 файл'],
    ['ar', 1, '1 ملف'],
    ['ar', 3, '3 ملفات'],
  ])('Gebietsschema %s, Anzahl %d → %s', (lng, count, expected) => {
    i18next.changeLanguage(lng);
    expect(i18next.t('file_count', { count })).toBe(expected);
  });
});

Das fängt fehlende Formen, falsche CLDR-Grenzen und Übersetzerfehlern ab, bevor sie Nutzer erreichen.

Lint für fehlende Formen

Schreiben Sie ein Skript, das Ihre Quellgebietsschema-Schlüssel liest, alle Pluralschlüssel identifiziert (die auf _other enden) und dann jedes Zielgebietsschema auf die von diesem Gebietsschema erforderlichen CLDR-Formen überprüft. Lassen Sie CI fehlschlagen, wenn Formen fehlen. Das verhindert die Klasse von Silent-Fallback-Bugs vollständig.

Wo Typsicherheit das Spiel verändert

Eine Schwäche schlüsselstring-basierter i18n ist, dass nichts die korrekte Verwendung an der Aufrufstelle erzwingt. Sie können number statt count übergeben, den Count ganz weglassen oder einen nicht vorhandenen Schlüssel referenzieren — und all diese scheitern zur Laufzeit still.

Typsichere i18n-Werkzeuge generieren TypeScript-Typen aus Ihren Übersetzungsschlüsseln, sodass der Compiler folgendes abfängt:

Fehlende erforderliche Interpolationsvariablen
Verwendung des falschen Variablennamens (number vs. count)
Referenzierung nicht vorhandener Schlüssel

Better i18n baut auf diesem Muster mit SDKs auf, die Ihr Übersetzungsschema verstehen und Plural-Vollständigkeit zur Veröffentlichungszeit erzwingen. Wenn Sie einen neuen Plural-Schlüssel hinzufügen, generiert das SDK aktualisierte Typen — und jede Aufrufstelle, die die erforderliche count-Variable nicht bereitstellt, wird zu einem Typfehler. Für Teams, die Dutzende von Gebietsschemata mit Hunderten von Schlüsseln verwalten, fängt das eine ganze Klasse von Pluralisierungsbugs vor dem Code-Review ab.

Die Features der Plattform, die für die Pluralisierung am wichtigsten sind: erzwungene Formvollständigkeit (alle erforderlichen CLDR-Formen müssen vor der Veröffentlichung vorhanden sein), KI-Übersetzung, die Kontext versteht ("das ist eine Dateianzahl, verwenden Sie die entsprechende Pluralform"), und Glossar-Durchsetzung, damit domänenspezifische Substantive konsistent flektiert werden.

Pluralisierungskorrektheit ist auch eng mit einem gut strukturierten Website-Übersetzungs- und Lokalisierungsworkflow verbunden — wenn Pluralformen als Teil desselben Prozesses wie der Rest der Übersetzung gesammelt und überprüft werden, ist es viel unwahrscheinlicher, dass sie unvollständig durchrutschen.

Praktische Zusammenfassung

Korrekte Pluralisierung erfordert:

Verwenden Sie ICU MessageFormat oder eine Bibliothek, die CLDR-Regeln implementiert. Schreiben Sie keine eigene Plural-Logik.
Verwenden Sie immer count als Interpolationsvariable in i18next. Andere Namen umgehen die Pluralauswahl.
Stellen Sie alle CLDR-Formen für jedes Gebietsschema bereit. Prüfen Sie, welche Formen eine Sprache benötigt, bevor Sie Zeichenketten an Übersetzer senden.
Verketten Sie niemals Zeichenketten mit Zahlen. Der gesamte Satz ist ein Übersetzungsschlüssel.
Testen Sie Grenzwerte für jedes Gebietsschema. Besonders Russisch, Polnisch, Arabisch und andere Sprachen mit komplexen Regeln.
Erzwingen Sie Formvollständigkeit in CI. Fehlende Pluralformen verursachen stille Fallbacks, die bei englischen Tests unsichtbar sind.
Unterscheiden Sie Ordinal- von Kardinalzahlen. Sie folgen unterschiedlichen Regeln und benötigen separate Behandlung.

Die Werkzeuge existieren, um das richtig zu machen. Die CLDR-Regeln sind standardisiert. Die Bibliotheken implementieren sie. Der Fehlerfall in den meisten Codebasen ist nicht technisch — es ist die Annahme, dass englische Plurallogik verallgemeinert, und kein Workflow aufgebaut wird, um zu erkennen, wenn das nicht der Fall ist.

Bringen Sie Ihre App mit better-i18n global

better-i18n kombiniert KI-gestützte Übersetzungen, git-native Workflows und globale CDN-Bereitstellung in einer entwicklerorientierten Plattform. Hören Sie auf, Tabellenkalkulationen zu verwalten, und fangen Sie an, in jeder Sprache auszuliefern.

Kostenlos starten → · Features erkunden · Dokumentation lesen

Pluralisierungsregeln in verschiedenen Sprachen: Ein Entwicklerhandbuch