international-types is a focused TypeScript package that provides essential utility types for constructing robust and type-safe internationalization (i18n) solutions. It is designed to enhance developer experience by offering strong type inference and autocompletion for translation keys, message scopes, and interpolation parameters within i18n implementations. The current stable version is 0.8.1. While this package does not provide any runtime i18n functionality itself, it serves as the foundational typing layer for higher-level i18n libraries, such as `next-international`. Its core differentiators are compile-time validation, preventing common i18n-related errors like missing keys or incorrect parameter types, and promoting maintainability in localized applications by ensuring all translation requirements are met at build time. Its release cycle is often synchronized with its primary consumer, `next-international`.
npm install international-typesVerified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates how to set up type-safe translation keys, scopes, and parameters using `international-types`. It shows how to define a locale type, create a `t` function with robust type inference, and ensures that translation keys exist and all required interpolation parameters are provided at compile time, reducing runtime errors.
Pair `international-types` with a full-fledged i18n runtime library to handle translation string loading, interpolation, and locale management.
Carefully review the `Locale` type definition to ensure it accurately reflects your translation structure, matching string literals for keys and values, and using dot notation for nested keys if desired.
While generally performant, consider flattening extremely deep locale structures if compile times become an issue, or ensure your TypeScript configuration is optimized (e.g., using project references, incremental builds).
Ensure translation keys are always string literals for direct calls. If dynamic keys are necessary, you might need a runtime lookup combined with type assertion (e.g., `t(dynamicKey as LocaleKeys<AppLocale, undefined>)`) or rethink the approach, acknowledging a loss of compile-time key validation for that specific call.
Provide all necessary parameters as defined in your `Locale` type for the specific translation key. Double-check the parameter names and their types.
Run `npm install international-types` or `pnpm install international-types`. Ensure `tsconfig.json` includes `node_modules` in its `typeRoots` or `include` paths, or that `moduleResolution` is set appropriately for your project (e.g., `bundler` or `node`).
No dependency data recorded yet.