Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Improve string extraction for JavaScript and EJS #1132

Closed
ozten opened this Issue · 7 comments

6 participants

@ozten
Collaborator

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/extract_po.sh is okay, but lacks the following features:

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

If you read extract_po.sh 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.

@mathjazz
Collaborator

When I extract new strings using extract_po.sh, 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 extract_po.sh. So what I do now is every time before I run extract_po.sh, I empty messages.pot and client.pot in the templates folder.

(Should I file another bug?)

@ozten
Collaborator

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

@lloyd lloyd was assigned
@zaach
Owner

I started a proof-of-concept here.

/cc @ozten

@shane-tomlinson
Collaborator

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

@zaach
Owner

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

@shane-tomlinson
Collaborator

Closing this in favor of #1322, thanks @zaach

@jbonacci
Collaborator

OK. Verifying as such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.