gettext-style keys with i18next, and general workflow

Question

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?

Answer 1

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

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

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

Answer 2

You could try using https://github.com/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.