Improve string extraction for JavaScript and EJS #1132

ozten opened this Issue Feb 16, 2012 · 7 comments


None yet

6 participants

ozten commented Feb 16, 2012

As part of localization, we have to pull all of the "strings" out of the code and templates. Strings are just copy, labels, and other words shown to users.

Our current script scripts/ is okay, but lacks the following features:

  • Robust JS support
  • Gettext Comments in JS
  • Robust EJS support
  • Gettext Comments in EJS

If you read you'll be horrified to find that we parse JS files via xgettext in Perl mode. Similarly, we EJS files are parsed via xgettext in PHP mode.

Ideally we'd either use Translate Toolkit, patch Translate Toolkit with Node.js support, patch GNU Gettext (good luck with that) or ... maybe you have some ideas.

Gettext comments mean that I can do this

/* l10n: This %s will be the user's name */
var msg = "Hello %s, welcome back!";

After string extraction, the po file has not only our string, but a special comment, so the localizer knows what %s is supposed to mean.

@ozten is happy to mentor first time contributors on this issue.


When I extract new strings using, I get different POTs generated if I leave existing POTs in the templates directory than if I empty the old POTs.

The difference is that strings that we remove for the new releae don't get removed from the POT if I keep the old POTs, but they do get removed if I empty the POTs before running So what I do now is every time before I run, I empty messages.pot and client.pot in the templates folder.

(Should I file another bug?)

ozten commented Feb 21, 2012

@mathjazz - please file a new bug. You basically want to make client.pot and messages.pot an empty file at the beginning of, right? I can do that ASAP.

@lloyd lloyd was assigned Mar 8, 2012
zaach commented Jun 20, 2012

I started a proof-of-concept here.

/cc @ozten


@zaach - you finished this work up, didn't you?

zaach commented Aug 6, 2012

@shane-tomlinson Yes, it's currently being used in the standalone i18n-abide. #1322 tracks when we'll pull that into browserid (post beta1).


Closing this in favor of #1322, thanks @zaach

jbonacci commented Aug 7, 2012

OK. Verifying as such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment