Skip to main content

i18next JSON format

The i18next JSON format reads i18next / react-i18next resource bundles — the conventions of the dominant web i18n library. It is built on the JSON format and selected explicitly (-f i18next), because i18next files use the generic .json extension owned by the JSON format and cannot be reliably auto-distinguished.

Beyond plain JSON extraction, it protects {{interpolation}}, {{var, format}}, and $t() nesting as inline codes; annotates v4 CLDR plural sibling keys (key_zero/key_one/…/key_other, plus legacy key_plural and key_0/key_1) with their base key and plural category; annotates context keys (key_male/key_female); and names blocks by their full namespace key path. Round-trip is byte-faithful.

IDi18next
SourceBuilt-in
CapabilitiesRead + Write

Parameters

ParameterTypeDefaultDescription
legacyPluralFormsbooleantrueRecognise the legacy v1–v3 plural sibling keys (key_plural and the numeric key_0 / key_1 / key_2 … forms) in addition to the v4 CLDR suffixes (_zero / _one / _two / _few / _many / _other).
protectInterpolationbooleantrueDetect i18next interpolation ({{var}}, {{var, format}}) and nesting ($t(key)) and protect them as inline codes so they are never translated.
subfilterHtmlValuesbooleanfalseHand values whose key ends in "_html" (the i18next convention for markup) to the HTML subfilter so tags are protected and text remains translatable. Off by default: the HTML subfilter is not byte-faithful for bare markup fragments.

Configure these parameters interactively and copy the YAML on the Format Reference.

Examples

Protect HTML in _html values

Enable the HTML subfilter for keys ending in _html.

subfilterHTMLValues: true

Processing notes

  • Plural sibling keys stay 1:1 blocks (preserving byte-faithful round-trip) but are annotated with base key + CLDR category.

  • {{interpolation}} and $t() nesting are protected as inline codes.

  • Block names use the full namespace key path for nested objects.

← Back to the Format Reference