Splitting resources into multiple files

[stevehobbsdev]

I would like to implement a feature of the library where localisation keys can be split amongst multiple files, which can be 'namespaced' by the file name. The reason is mainly for organisation on large sites where there may be hundreds or thousands of keys.

Things for consideration:

• There would be the default locale file plus n 'namespaced' files
• The default file could remain en.js whereas additional files could be countries-en.js, months-en.js, etc.
• We would need some kind of marker to indicate which file to pull from if not the default. Something like i18n.__("countries.Germany") or i18n.__("Germany", "countries"). Either with some kind of marker in the key name as in the former example, or with a method parameter as in the latter (I'm leaning towards the latter)
• If no file is specified, then the key is pulled from the default file
• If a file is specified but a key name is not found, then it is searched for in the default file. If it is not found in the default file, then a key is created as in the current behaviour

Is there anything else I should consider?

[gjuchault]

Be careful about the base option, that will cause you somme trouble. But if you make a decent PR (please, include tests / version push / documentation); that would be an amazing feature !

[stevehobbsdev]

After some more thought, I think my initial considerations may be too simplistic. The fact that real language is supported within the key name makes any kind of delimiter difficult as in the first option, and since __() supports the sprintf syntax makes the second option difficult.

It doesn't look like this fork supports the passing of the options object when translating a string, as in __({ phrase: 'hello', locale: 'fr' }) as I could have put an extra option on there for the file you wish to pull from.

One option I'm considering is to just implement another method alongside __() and __n() which accepts an argument indicating the file, e.g. __f('labels', "Let's go to %s", 'Spain') where the first argument is the file and following arguments are the translation arguments.

Another thing I'm thinking about is whether to only support a flat file structure or nest directories. The directory structure could influence how the locale keys are named which might aid organisation, and accessing the language keys would utilise a path-style syntax.

For example, consider the following folder structure:

locale
|-- geo
|   | countries-en.js
|   | countries-fr.js
|-- de.js
|-- en.js
|-- fruits-en.js
|-- fruits-de.js

To access the key Spain inside countries, one might use __('geo/countries/Spain'), which would search inside the geo/countries local files. Accessing the 'fruits' language keys would be __('fruits/Apple'). It would also get around the problem of having to have another method as in the above example.

@gjuchault Oh yes, full tests and whatnot will be written

[gjuchault]

So you think about __f and __fn (because you must reimplement __ and __n) ? I do prefer the options object as first argument. But that would be : __({ key: 'foo', path: 'geo/countries/spain' }) No use oflocale(usesetLocale` instead)

Did you think about using requires in one file instead and using that file as locale ?

Le mar. 4 août 2015 à 11:04, Steve Hobbs notifications@github.com a écrit :

After some more thought, I think my initial considerations may be too simplistic. The fact that real language is supported within the key name makes any kind of delimiter difficult as in the first option, and since __() supports the sprintf syntax makes the second option difficult.

It doesn't look like this fork supports the passing of the options object when translating a string, as in __({ phrase: 'hello', locale: 'fr' }) as I could have put an extra option on there for the file you wish to pull from.

One option I'm considering is to just implement another method alongside () and n() which accepts an argument indicating the file, e.g. __f('labels', "Let's go to %s", 'Spain') where the first argument is the file and following arguments are the translation arguments.

Another thing I'm thinking about is whether to only support a flat file structure or nest directories. The directory structure could influence how the locale keys are named which might aid organisation.

For example, consider the following folder structure:

locale |-- geo | | countries-en.js | | countries-fr.js |-- en.js |-- de.js

To access the key Spain inside countries, one might use __('geo/countries/Spain'), which would search inside the geo/countries local files.

— Reply to this email directly or view it on GitHub https://github.com/jeresig/i18n-node-2/issues/65#issuecomment-127533522.

[stevehobbsdev]

I was thinking about __f and __fn as a last resort, just to distinguish from the base methods, since it would be difficult to implement the new functionality based on the arguments alone, but I don't think that will be necessary if we were to reference the keys by a path name.

Using requires would be interesting.. I wonder if this whole issue could be solved using a build step which effectively concatenates the language files together. The benefits of all this only really come into effect at design time, after all.

[blowsie]

Using requires would be interesting.. I wonder if this whole issue could be solved using a build step which effectively concatenates the language files together. The benefits of all this only really come into effect at design time, after all.

Interesting, however in my scenario I would like the language files separated for different reasons. I need a clear separation between my templates and their localisation files , so that they can use the same keys, and provide different translations.

[gjuchault]

@blowsie could you give a short example; I did not get the interest to have a template file

[guumo]

I think its necessary separated files in production.

Options:

• Developer defines the files and pattern to retrieve, for example using glob
• Use a file prefix in keys, for example for file en/demo.js, the title key is demo.title.
• Add a config parameter for define logical
• Remove the write option and create a cli package for work with literals using yeoman