i18next / i18next-express-middleware

[deprecated] can be replaced with i18next-http-middleware
https://github.com/i18next/i18next-http-middleware
MIT License
207 stars 55 forks source link

Feature idea: Merge resources for "dialects" #166

Closed lucasfeliciano closed 5 years ago

lucasfeliciano commented 5 years ago

Currently i18n needs to have one locale per language but these is not optimal since this will lead to duplicated translations.

One thing that we could do is merge the translation files before serving it.

Example:

en.json

const en = {
  "hello": "world",
  "button": "Personalise"
}

en_GB.json

const en_GB = {
  "button": "Personalize"
}

Then the middlewere would serve

Object.assign({}, en, en_GB)

Doing that we just need to translate specific strings and would have a fallback to the "main" language.

Is there any technical limitation to do that?

jamuhl commented 5 years ago

i18next does this basically without merging:

setting language to en-US it will lookup keys in en if not found in en-US -> so en-US has only to contain values different than to en (assuming en is english in british flavor)

lucasfeliciano commented 5 years ago

So it needs to be en-US instead of en_US right?

jamuhl commented 5 years ago

yes en-US. Just for more details: https://www.i18next.com/principles/fallback#language-fallback

lucasfeliciano commented 5 years ago

I'm feeling so bad because I searched the documentation before open the issues, and I couldn't find it. 🙈

Sorry for that

jamuhl commented 5 years ago

nothing to worry...the documentation while improved over the time still could need a lot of improvement.