Splitting resources into multiple files about i18n-node-2 HOT 7 OPEN

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 !

from i18n-node-2.

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

from i18n-node-2.

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 [email protected] 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
#65 (comment).

from i18n-node-2.

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.

from i18n-node-2.

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.

from i18n-node-2.

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

from i18n-node-2.

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

from i18n-node-2.