Feature Request: Support Maketext strings

[konobi]

Maketext has a more powerful format, that allows for more precise translation. For example: International Date Formatting.

http://search.cpan.org/~toddr/Locale-Maketext-1.26/lib/Locale/Maketext.pod

More info about the Maketext format makes sense for linguistics:

http://search.cpan.org/~toddr/Locale-Maketext-1.26/lib/Locale/Maketext/TPJ13.pod

[gjuchault]

I'm not sure how you'd like to see that in i18n-node-2.

[konobi]

So take the following string:

"Your search matched [quant,_1,document]!"

the square brackets become a routine. On the object that represents the "language", there's a "quant" function that is used with the values passed in and in turn in spits out the proper string. But for example, if the current language is changed to japanese, I'll need a quant function that is specific to japanese. Since the function just hangs off of the "object", I can have a different quant function only for japanese, or for whatever language is wanted.

A good example is things like date or currency formatting, which can be wildly different based on locale.

[gjuchault]

I do prefer the idea of a function (https://github.com/jeresig/i18n-node-2/issues/78) that could handle the parameters than trying to make a maketext parser on a string

[konobi]

Well, the nice thing is that you can pre-compile all of the strings as functions and then use the string as a lookup key. And the ability to have any function (not just quant, etc.) makes it more attractive. If you read the second link above (TPJ13), you'll see how this maps better to i18n as a whole. Since it's just matching braces, there's plenty of parsers already available to handle that.

[gjuchault]

I'll wait for @jeresig opinion on that