Re: [Taler] i18n

[Florian Dold]

It's implemented [1]!

It doesn't use esprima, but the TypeScript compiler directly (less
dependencies...).

The program could have been shorter, but:
 * it handles msgid wrapping correctly
 * source location is there
 * it parses comments and includes them in the .po file, with the same
rules as xgettext

Note that we're using the csharp-format flag, since that allows us to
use numbered placeholders for the "holes" in the template literal.

There's also an example file (with some contrived examples) in the repo,
together with the .po output file [2].

- Florian

[1]
http://www.git.taler.net/?p=wallet.git;a=blob;f=wallet_webextension/extension/pogen/pogen.ts
[2]
http://www.git.taler.net/?p=wallet.git;a=tree;f=wallet_webextension/extension/pogen/example

On 01/26/2016 07:07 PM, Florian Dold wrote:
> 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