@docx-editor.dev/i18n

Locale data for the editor UI. Both adapters consume it through the i18n prop.

npm install @docx-editor.dev/i18n

Add this package as a direct dependency when importing its catalogs, including for the editor's i18n prop.

UI language and date input

i18n supplies UI translations; locale selects regional date input and generated document labels. Neither setting infers the other. UI strings default to English or an inherited catalog; locale defaults to en-US.

import { DocxEditor } from '@docx-editor.dev/react';
import { pl } from '@docx-editor.dev/i18n';

// English UI, Polish dates (with no inherited catalog)
<DocxEditor document={bytes} locale="pl-PL" />;

// Polish UI, Polish dates
<DocxEditor document={bytes} locale="pl-PL" i18n={pl} />;

In Vue, use locale="pl-PL" and :i18n="pl" on <DocxEditor>. For composed editors, wrap Root and its chrome in LocaleProvider; Root has no i18n prop. See the React and Vue examples. See form fields for supported date input.

Available locales

Two import shapes are supported:

• Named exports off the root (import { pl } from '@docx-editor.dev/i18n'). Use this when you ship a small static list of locales. Hyphenated codes (pt-BR, zh-CN) become camelCase exports (ptBR, zhCN).
• Per-locale subpath imports (import pl from '@docx-editor.dev/i18n/pl'). Use this when you dynamically load locales; the per-locale subpath code-splits so users only download the language they need.

Verify what your installed version ships:

ls node_modules/@docx-editor.dev/i18n/

Wiring into the editor

Pass the catalog to i18n. These examples change UI language only; date input keeps the default en-US conventions.

import { DocxEditor } from '@docx-editor.dev/react';
import { pl } from '@docx-editor.dev/i18n';

<DocxEditor document={bytes} i18n={pl} />;

<script setup lang="ts">
import { DocxEditor } from '@docx-editor.dev/vue';
import { pl } from '@docx-editor.dev/i18n';
</script>

<template>
  <DocxEditor :document="bytes" :i18n="pl" />
</template>

For several editors, or for chrome parts you compose yourself, put the catalog in context once instead:

import { DocxEditor, LocaleProvider } from '@docx-editor.dev/react';

<LocaleProvider i18n={pl}>
  <DocxEditor.Toolbar />
  <DocxEditor document={bytes} />
</LocaleProvider>;

<script setup lang="ts">
import { DocxEditor, DocxEditorToolbar, LocaleProvider } from '@docx-editor.dev/vue';
import { pl } from '@docx-editor.dev/i18n';
</script>

<template>
  <LocaleProvider :i18n="pl">
    <DocxEditorToolbar />
    <DocxEditor :document="bytes" />
  </LocaleProvider>
</template>

In both cases, the catalog merges over English, so a locale that has not translated every key falls back per key rather than per language. Providers nest: an inner one, or an i18n prop under an outer provider, overrides only the keys it names. Chrome you write from scratch reads the same catalog through useTranslation():

import { useTranslation } from '@docx-editor.dev/react';

const { t } = useTranslation();
<button>{t('formattingBar.bold')}</button>;

<script setup lang="ts">
import { useTranslation } from '@docx-editor.dev/vue';

const { t } = useTranslation();
</script>

<template>
  <button type="button">{{ t('formattingBar.bold') }}</button>
</template>

Next steps

• Contributing a translation: add or improve a locale with one JSON file
• i18n API reference
• React API reference and Vue API reference