@eigenpal/docx-editor-i18n

Why the split

In 0.x, locales lived inside @eigenpal/docx-js-editor at /i18n/<code>.json. With a Vue adapter joining React in 1.0, that path would have meant duplicating the same JSON in two places. -i18n extracts it to a standalone package both adapters depend on.

npm install @eigenpal/docx-editor-i18n

You usually don't install this directly. -react and -vue pull it in transitively. Install it explicitly only when you're using the locale data outside the editor (a custom toolbar, a search dropdown, that kind of thing).

Available locales

Two import shapes are supported in 1.0.1+:

• Named exports off the root (import { pl } from "@eigenpal/docx-editor-i18n"). Use this when you ship a small static list of locales.
• Per-locale subpath imports (import pl from "@eigenpal/docx-editor-i18n/pl"). Use this when you dynamically load locales; the per-locale subpath code-splits so users only download the language they need.

The 0.x import pl from "@eigenpal/docx-js-editor/i18n/pl.json" JSON pattern is gone, but the new subpath form covers the same use case. See the migration guide for the rewrite.

Verify what your installed version ships:

ls node_modules/@eigenpal/docx-editor-i18n/

To contribute a locale, PR the JSON to packages/i18n/<code>.json upstream.

Importing

Named exports off the package root:

import { en, pl, de, ptBR } from "@eigenpal/docx-editor-i18n";

Hyphenated codes (pt-BR, zh-CN) become camelCase named exports (ptBR, zhCN).

Wiring into the editor

Pass the locale object to the i18n prop. React:

import { DocxEditor } from "@eigenpal/docx-editor-react";
import { pl } from "@eigenpal/docx-editor-i18n";
 
<DocxEditor documentBuffer={buf} i18n={pl} />;

Vue:

<script setup>
import { DocxEditor } from "@eigenpal/docx-editor-vue";
import { pl } from "@eigenpal/docx-editor-i18n";
</script>
 
<template>
  <DocxEditor :document-buffer="buf" :i18n="pl" />
</template>

Where to next

• i18n API reference
• React API reference: i18n prop
• Migration: i18n restructure