Re: [Taler] i18n

[Florian Dold]

This is not really surprising, considering that the string and comment
syntax for pre-ES6 JavaScript is basically the same as for C.

The real question is, do we want to give up on using string
interpolation and switch to printf (which printf? JavaScript doesn't
have a native one), or do we want to keep it?

Creating the .po file for the wallet and integrating it in the build
system would take 1-2 hours of work and 100 lines of code maximum.  It's
a matter of looking at all "TaggedTemplateExpression" nodes in the JSON
parse tree that esprima gives us [1].

It allows us to use all the other existing GNU gettext tooling, while
not sacrificing the ability to write idiomatic JavaScript.

- Florian

[1] http://esprima.org/demo/parse.html, try i18n`Hello ${name}!`

On 01/26/2016 05:52 PM, Christian Grothoff wrote:
> Florian,
> 
> I don't know if you saw this, but GNU Gettext supports extraction using
> xgettext:
> 
> https://www.gnu.org/software/gettext/manual/html_node/JavaScript.html
> 
> Just FYI.
> 
> -Christian
> 
> On 01/26/2016 04:26 PM, Florian Dold wrote:
>> Hi!
>>
>> Gabor pointed me to some resources for JavaScript internationalization
>> (i18n), I'll summarize how the situation looks to me here.
>>
>> In general, there are two distinct flavors of i18 approaches:
>>
>> 1. resource-based:  Most of today's larger (web) applications seem to
>> use this.  The programmer never writes string constants directly, but
>> always refers to a resource, like:
>>
>> showDialog(getTranslation(MessageResources.Welcome, args))
>>
>> This is more tedious for the programmer, but allows to use the
>> MessageFormat [1] translation standard, which allows all kinds of fancy
>> things (complex queries, support for gender, ...).
>>
>> Enterprise-y frameworks like AngularJS follow this style as well [2].
>>
>>
>> 2. gettext-style:  Programmers just write all strings that should be
>> translated in their favorite language and mark then, usually via this
>> underscore macro.  Some helper program then extracts the translatable
>> string.
>>
>> JavaScript has enough libraries to *read* .po/.mo files, but barely any
>> support for extracting these strings from source.
>>
>> However, it would be trivial(ish) to just use an off-the-shelf JS parser
>> (esprima [3] is very good for that) to extract marked strings,
>> preferably tagged template literals like:
>>
>> i18n`This is a translated message.  Hello ${user}.`
>>
>> Alternatively, we'd just have to hack together our own message catalogue
>> for gettext by grepping the source code in the beginning.
>>
>>
>> Does anybody have more experience with i18n in JavaScript projects?
>>
>> Do we want to do gettext or resource-based translations?
>>
>> Personally as a developer I'd prefer gettext-style, but in the end I
>> wouldn't mind either too much.
>>
>> - Florian
>>
>>
>> [1] http://userguide.icu-project.org/formatparse/messages
>> [2] https://docs.angularjs.org/guide/i18n
>> [3] http://esprima.org/
>> [4] https://github.com/gmarty/xgettext
>>
>

signature.asc
Description: OpenPGP digital signature