We would like to exchange PO files with translators, and convert these to i18next's native JSON format. This sounds pretty straightforward using the i18next-conv utility.

However, i18next expects more or less special keys; for example the dot has special meaning with regard to i18next namespaces. In contrast, gettext PO files are intended to carry source strings (in the original language) for their message IDs.

We know that message IDs can be arbitrary, and can thus be mapped to i18next keys directly, but we would like to use source strings and use PO files as they were intended for various reasons.

The main reason is that all the translation tools we would like to use, and probably those of all our translators, expect this. Using symbolic keys would make translating a real pain. In any case, we figured from the debates around this that this is mainly a matter of opinion; we kind of made ours, and we would like to put this restriction as a requirement for this question.

1. Is it really a bad idea to use source strings as i18next keys from a technical standpoint? How hard is it to escape them? Is there anything else than the dot and namespaces that we should care about?
2. If we determine that we want to keep using symbolic keys, is there an alternative to i18next-conv that can generate i18next JSON translation files from PO files using source strings as message IDs? We understand that we would most likely need to maintain a separate mapping between the symbolic names and the original language strings, and we're prepared to do so.

Moreover, we wonder about the general workflow. How is the original PO file generated? How are the translation files maintained?

1. If we use source strings as keys in i18next, what are the best tools to extract strings from the codebase? xgettext doesn't seem to support Javascript.
2. If we use symbolic keys in i18next, how can we best generate the original PO file? Is writing a POT file by hand a good practice?
3. Again, if we use symbolic keys, how can we easily invalidate translations whenever we update the original language strings? Are there tools for that?

We understand these questions are very basic, but we were a bit surprised at how little information we could find about i18next-gettext integration. The i18next-conv tool exists and works perfectly as advertised, but is it actually useful? Do people actually use it? If so, are our questions relevant?

Finally, are our expectations about the maturity of the system a little too high?

We would like to exchange PO files with translators, and convert these to i18next's native JSON format. This sounds pretty straightforward using the i18next-conv utility.

However, i18next expects more or less special keys; for example the dot has special meaning with regard to i18next namespaces. In contrast, gettext PO files are intended to carry source strings (in the original language) for their message IDs.

We know that message IDs can be arbitrary, and can thus be mapped to i18next keys directly, but we would like to use source strings and use PO files as they were intended for various reasons.

The main reason is that all the translation tools we would like to use, and probably those of all our translators, expect this. Using symbolic keys would make translating a real pain. In any case, we figured from the debates around this that this is mainly a matter of opinion; we kind of made ours, and we would like to put this restriction as a requirement for this question.

1. Is it really a bad idea to use source strings as i18next keys from a technical standpoint? How hard is it to escape them? Is there anything else than the dot and namespaces that we should care about?
2. If we determine that we want to keep using symbolic keys, is there an alternative to i18next-conv that can generate i18next JSON translation files from PO files using source strings as message IDs? We understand that we would most likely need to maintain a separate mapping between the symbolic names and the original language strings, and we're prepared to do so.

Moreover, we wonder about the general workflow. How is the original PO file generated? How are the translation files maintained?

1. If we use source strings as keys in i18next, what are the best tools to extract strings from the codebase? xgettext doesn't seem to support Javascript.
2. If we use symbolic keys in i18next, how can we best generate the original PO file? Is writing a POT file by hand a good practice?
3. Again, if we use symbolic keys, how can we easily invalidate translations whenever we update the original language strings? Are there tools for that?

We understand these questions are very basic, but we were a bit surprised at how little information we could find about i18next-gettext integration. The i18next-conv tool exists and works perfectly as advertised, but is it actually useful? Do people actually use it? If so, are our questions relevant?

Finally, are our expectations about the maturity of the system a little too high?

• javascript
• localization
• internationalization
• gettext
• i18next

Share Improve this question Follow asked Oct 16, 2013 at 12:44 tnetne 7,27133 gold badges4848 silver badges7070 bronze badges 2

• You can try out l10ns then you don't need to deal with PO files. – einstein Commented Oct 27, 2014 at 2:08
• Thanks for the suggestion. Note that l10ns uses ICU MessageFormat exclusively. While it certainly has its advantages in parison to gettext portable objects, the implied goal in this question is very much to support them, in part for external reasons (existing tooling for non-programmers, familiarity, etc). No doubt there are MessageFormat alternatives, but sometimes the cost of switching technologies isn't worth their advantages. – tne Commented Oct 27, 2014 at 8:40

Add a ment  | 

2 Answers 2

Sorted by: Reset to default 5

if you like to use source strings as keys just change the

nsseparator = ':::'
keyseparator = '::'

so . and : could be used inside the key without fear.

You could try using https://github./cheton/i18next-text. It allows you using i18next translation without having the key as strings, and you do not need to worry about i18n key naming. Furthermore, you can also register the i18n helper with Handlebars.

Following is a simple example:

var i18n = require('i18next');

// extends i18n object to provide a new _() method
i18n._ = require('i18next-text')._;

i18n._('Save your time and work more efficiently.');

Check out the demo on JSFiddle.