-
Notifications
You must be signed in to change notification settings - Fork 4
Description
The configurable option is well documented on this npm i18next-client.
Basically, support for this structure:
locales/en-US/ns.common.json
locales/en-US/ns.special.json
locales/en/ns.common.json
locales/en/ns.special.json
locales/dev/ns.common.json
locales/dev/ns.special.json
... with the namespace and extended name being able to be set and called as per requirement. ie:
$.i18n.init({
lng: 'en-US',
ns: { namespaces: ['ns.common', 'ns.special'], defaultNs: 'ns.special'}
}, function() {
$.t('app.name'); // -> i18n (from en-US resourcefile)
$.t('app.area'); // -> Area 51 (from en resourcefile)
$.t('ns.common:app.company.name'); // -> my company (from dev resourcefile)
$.t('ns.common:add'); // -> add (from dev resourcefile)
});
For English, as an example, one can set up a primary file dev/app.common.json, and if only minor differences are being applied to localise then en-US/app.local.json and en-UK/app.local.json etc could be used as spelling overrides. In the era of modularity, the different namespace can be used to assist organisation en-CA/news.local.json or if one wants to separate the translations to match primary views or templates fr-CA/forms.json, fr/static.common.json.
All in all, it would just require a hook for this wrapper to accept new/override parameters to the defaults you've set. ie:
i18n: {
ns: {
namespaces : ['oss.common', 'oss.special'],
defaultNs : 'oss.common'
},
fallbackOnNull : true,
fallbackOnEmpty : true
}