feat(i18n): export locale subpaths from viewer packages

[yunfeizhu]

What does this change?

Applications can import reference translations from the viewer package they already install:

import { translationsZhCN } from 'pptx-react-viewer/i18n/zh-CN';

Fixes #282. Follows the agreed direction in #280 and builds on the Chinese dictionary merged in #281.

Add i18n/fr, i18n/es, i18n/de, and i18n/zh-CN to all five viewer packages. Each subpath ships standalone ESM and CommonJS files with matching declarations. A shared build step copies the existing compiled dictionaries into the viewer artifacts, keeping their source in the private locale workspace. No additional npm package is published or required.

The existing English and root exports are unchanged. The localization guide and package READMEs now show public imports instead of asking applications to copy dictionary source. Vue still uses toVueI18nSyntax when registering a reference dictionary.

Type of change

• New feature (non-breaking)

Cross-binding parity

Binding	Implemented	Validation
React	All four locale subpaths	Actual npm tarball, ESM/CommonJS imports, bundling, declarations
Vue	All four locale subpaths	Same
Angular	All four locale subpaths in the published ng-packagr dist	Same
Svelte	All four locale subpaths	Same; the data-only entries also support CommonJS
Vanilla	All four locale subpaths	Same

Packaging and releases

• Dictionaries remain maintained in one place under packages/locales.
• Each viewer build copies the standalone artifacts after its framework build, so cleaning dist cannot discard the locale files.
• The release planner now treats locale changes as changes to every viewer that contains them. A regression test makes a dictionary-only commit in an isolated repository and verifies the five viewer patch releases.
• CI checks each binding's packed locale imports immediately after building it.

The npm tarballs include the four dictionaries. Applications load only the language subpaths they import; those entries do not import the viewer, other languages, or the private workspace.

Testing

• bun run build: passed across the full workspace.
• Packaged-consumer checks: 20 locale subpaths passed across the five bindings. Each tarball was extracted into an isolated consumer with no framework or private workspace installed; both import and require returned the exact reference dictionary. TypeScript NodeNext and Bundler resolution passed for .mts and .cts consumers, and each Rollup entry contained only that dictionary module.
• Before the change, the Chinese import throws ERR_PACKAGE_PATH_NOT_EXPORTED. The packaging check also fails when the manifest declares an entry whose artifact is missing.
• node --test scripts/*.test.mjs: 87 passed, 1 skipped, including the dictionary-only release regression.
• bun run typecheck: passed, with five existing Svelte warnings.
• bun run lint --deny-warnings: passed.
• bun run fmt:check: passed.
• bun run test: 41,549 passed, 18 failed, 234 skipped. All 18 failing cases also fail in an unchanged checkout of 5444979ac2bc06b0d3352db9c34fa150044c7535: six React list-formatting cases, six shared bullet-toggle cases, one Svelte connector case, one Vanilla paragraph-command case, and four Vue connector cases. No additional failing cases were introduced. The core suite, including the previously missing fixture registration, passes.

No UI rendering or language-switching behavior changes here. The new regression coverage exercises published package boundaries rather than adding another demo-only browser test.

Conventional Commits

• Commit follows Conventional Commits.

[yunfeizhu]

@ChristopherVR I looked into the failures in the latest CI run. The React list-formatting, shared bullet-toggle, and Vanilla paragraph-command assertion failures also reproduce without this PR's changes, in the unchanged 5444979ac2bc06b0d3352db9c34fa150044c7535 checkout used for the baseline comparison in the description. These failures are not introduced by the locale subpath exports. The React 18 job reports the same React cases; Angular also hits a 5-second timeout in the GIF export test, which needs separate investigation.

I initially planned to fix these alongside this PR, but tracing them led into shared text/list editing behavior and several bindings, rather than just the CI configuration. The scope was larger than expected, and I was concerned about regressions in core editing functionality, so I reverted the local attempts and left those areas unchanged in this PR.

Could you please prioritize a separate follow-up for these failures when you have a chance? Getting the test suite back to green would make this PR and subsequent contributions much easier to validate. Thanks!