The i18n API of defuss is already decent enough for multi-language translations, dynamic runtime translation switching with hot DOM patching, comes with JSX support and features nested addressing of keys such as x.y.z mapping to { x: { y: { z: 'foo' }}}. It also features a <T /> and t() API for both JSX and functional-call translations. It supports interpolating the translation values, too.
Although this API is already elegant and powerful, the our i18n implementation could use some more power-ups, such as the possibility for:
- translation key type-inference, possibly even constrained by the language loaded
- thus making it clear at implementation time when translation keys are lacking for a specific language
- making it possible to customize behaviour of the i18n implementation using
setI18nConfig({ ... }) with:
defaultLanguage: string - defaults to enmapLanguageKeyFn: async(key: string) => Promise<string> - called internally and allows for mapping a language key to an internal available key -- default implementation will split by ('-' and '_') and find the closest match of any language loaded by startsWith()autoDetectLanguageFn: async() => Promise<string> - only called internally if autoDetectLanguage is true. Runs the most decent and modern client-side (browser) automatic language detect. Does NOT run in SSR.autoDetectLanguage: boolean - defaults to false for deterministic behaviour. When true, runs autoDetectLanguageFn(). If also changeLanguage() is called, the last call wins.i18nStore: I18nStore - defaults to the result of an internal createI18n() call. Developers should be able to override it with their own implementation to control i18n behaviour even at the lowest level , if desired.
- Developers can already call the exposed
createI18n() function to create their own i18n stores, but:
- the implementation sets default language to
en in the closure. This should use the new i18nConfig.
The i18n API of defuss is already decent enough for multi-language translations, dynamic runtime translation switching with hot DOM patching, comes with JSX support and features nested addressing of keys such as
x.y.zmapping to{ x: { y: { z: 'foo' }}}. It also features a<T />andt()API for both JSX and functional-call translations. It supports interpolating the translation values, too.Although this API is already elegant and powerful, the our
i18nimplementation could use some more power-ups, such as the possibility for:setI18nConfig({ ... })with:defaultLanguage: string- defaults toenmapLanguageKeyFn: async(key: string) => Promise<string>- called internally and allows for mapping a language key to an internal available key -- default implementation will split by ('-' and '_') and find the closest match of any language loaded by startsWith()autoDetectLanguageFn: async() => Promise<string>- only called internally ifautoDetectLanguageistrue. Runs the most decent and modern client-side (browser) automatic language detect. Does NOT run in SSR.autoDetectLanguage: boolean- defaults tofalsefor deterministic behaviour. Whentrue, runs autoDetectLanguageFn(). If alsochangeLanguage()is called, the last call wins.i18nStore: I18nStore- defaults to the result of an internalcreateI18n()call. Developers should be able to override it with their own implementation to control i18n behaviour even at the lowest level , if desired.createI18n()function to create their own i18n stores, but:enin the closure. This should use the new i18nConfig.