Starting from version 0.8.0 scanning i18n.t(var1 + var2) is broken about i18next-parser HOT 8 CLOSED

In that case I made a buzz about nothing 😪. @karellm already added comment-line switch --ignoreVariables with version 0.10. Then it provides a warning instead of an error.

from i18next-parser.

I see that is introduced in PR #40 by @laszlopandy .

We use a mix of i18n.t("mykey") and i18n.t(myvar)
i18n.t support both, using the variable is typically for translating dynamic texts. Which is very common in general programs.

We use the scanner only to extract the string version and are completely fine with the fact that the scanner ignores the one with the variable. I can imagine that you want to have a commandline argument to enable warning about it, but don't allowing this kind of use can not be the intention I suppose.

from i18next-parser.

Can you explain to me how you translate dynamic texts? I mean, how will the translated string be available for the I18n.t() to return if the scanner cannot identify that this string is one to be translated?

from i18next-parser.

Typically the dynamic strings aren't part of the frontend, but the backend.
In our case the dynamic returned strings are in the form of a i18next key.

We provide a separate namespace file for those items (no conflict with the namespaces generated by the scanner ). Those namespace files can be either generated from master data or manually put together.

The separate namespace files are merged and upload to https://localise.biz/, after translation we download a file per language.

from i18next-parser.

If you anyway have the strings in a different namespace, why don't you use a different function to get the translation for them? I18n.t for literals and I18n.v for variables for example. Then the scanner would still give you a warning if you accidentally did this:

var msg = "Really long translatable string which we put into a variable so the next line doesn't wrap";
initializeWidgets([Buttons.OK, Buttons.CANCEL], I18n.t(msg), callback);

from i18next-parser.

Your suggestion make sense. Only now you force existing code to be changed, to support the detection.

The scanner behaves different after the patch then before, rather I would prefer that in such cases that new behavior can be enable or disabled by command-line.

from i18next-parser.

I'm ok with having a command line switch as well. That is a reasonable solution.

from i18next-parser.

@bitkeeper You shoudn't use https://localise.biz/ but our own service http://locize.com -> this way you support the future of i18next ;)

from i18next-parser.