Translating javascript
Michael C. Harris
gettext functions, thanks mostly to Massimiliano. However, one issue
that should be raised is how we should deal with text in javascript
files. For example, see admin/js/admin.js lines 166-170, the
"selected" bits. Obviously this can't get translated by the PHP
functions.
Does anyone have any idea how we should proceed? It seems a bit like
overkill to run all the js through PHP for translation ...
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Michael Heilemann
Does anyone have any idea how we should proceed? It seems a bit like
overkill to run all the js through PHP for translation ...
Well, for the 'selected' stuff, we could put the select items in the PHP files instead, and simply hide the ones we aren't using at any given point.
--
Michael Heilemann
http://binarybonsai.com
Matthias Bauer
> We're making good progress on making sure all text is run through the
> gettext functions, thanks mostly to Massimiliano. However, one issue
> that should be raised is how we should deal with text in javascript
> files. For example, see admin/js/admin.js lines 166-170, the
> "selected" bits. Obviously this can't get translated by the PHP
> functions.
>
> Does anyone have any idea how we should proceed? It seems a bit like
> overkill to run all the js through PHP for translation ...
Have a file with all JS strings, run that through gettext (in PHP) and
include it.
-Matt
Chris Meller
Having a single file that should contain all the JS strings required for the entire project doesn't seem realistic (what about plugins or themes?). We also probably don't want to translate every string every single time either (for performance reasons). That means we have to take a sort of lazy-loader / queuer approach, like WordPress' enqueue_script() so that we know which scripts are currently required to be loaded, where they are, what strings they need, and a method to print out those <script> tags, along with the Javascript containing the translated strings.
The WordPress implementation is, like much of its other code, messy. Still, it's the most straight-forward implementation I'm aware of and is worth a look for ideas on how we'd like to handle it.
Essentially, the WP approach comes down to:
1 - Register the JS file in PHP so WP knows where it's located.
2 - Tell WP which strings to translate in PHP.
3 - Tell WP which scripts to load in PHP.
4 - Using the plugin hook in the <head> tag, essentially WP automatically outputs all the stuff needed.
// step 1
register_script( 'handle_name', 'location/of/script.js' );
// step 2
localize_script( 'handle_name', 'destination_JS_global_object_name', array( 'stringName' => __( 'This is the text to translate' ), 'anotherName' => __( 'Some more to translate' ) ) );
// step 3
enqueue_script( 'handle_name' );
// step 4
<script type="text/javascript" src="location/of/script.js"></script>
<script type="text/javascript">
destination_JS_global_object_name.stringName = 'This is the text that got translated';
destination_JS_global_object_name.anotherName = 'Some more that got translated';
</script>
Additionally, they allow for scripts to designate dependencies and provide a method for different versions of a single Javascript library to co-exist and be used, rather than always using the latest version. I've yet to see anything that works properly and doesn't use the latest version, so I imagine that'd be overkill. The dependencies structure would be valuable though (ie: this plugin requires jQuery be loaded, so it will make sure jQuery exists on the page before loading your dependent script). Also, it prevents your blog from having 10 different copies of Prototype loaded by 10 different plugins, since every plugin enqueue_script()'s Prototype, but WP only loads it once (rather than each plugin directly hooking in and printing out its own <script> tag in <head>).
Anyway, that's the only input I have on it... Perhaps it could serve as a starting point for further ideas.
Owen Winkler
>
> Anyway, that's the only input I have on it... Perhaps it could serve as
> a starting point for further ideas.
I only found 9 obvious instances of text being set directly via
javascript so far that would need to be localized, so I'm feeling much
less concerned about this than I was when I first considered it.
The Stack class addresses concerns about script duplication. If an
enqueue_script()-like function is written, it should be added there,
perhaps like:
// register a script:
Stack::register('scriptname', '/path/to/script');
// add a registered script to a stack:
Stack::add('stackname', 'scriptname', Stack::REGISTERED);
// Output a stack through a javascript pre-cache:
Stack::out('stackname', array('Stack', 'js_precache'));
It has always been a thought of mine to provide some kind of server-side
caching and compression capabilities via the stack class for both
javascript and CSS output. The end result could be cached under a
hashed key of concatenated script names and times, and then served as a
single compressed javascript include file.
Regarding the javascript output itself, maybe we should consider using
something like this (MIT license):
http://code.google.com/p/gettext-js/source/browse
This seems as though it could load the gettext translation files
directly. All you'd need to do is add a line of javascript to tell the
browser to load (and hopefully cache) the translation file.
Owen
Chris Meller
I only found 9 obvious instances of text being set directly via
javascript so far that would need to be localized, so I'm feeling much
less concerned about this than I was when I first considered it.
It's still something we should work on and keep in the backs of our minds. I would definitely say before anything considered a "public" ready-to-go release (generally 1.0) we should have this functionality. Ideally it would be nice to have well before that so that things could actually use it so we don't have multiple copies of JS libraries on every page...
The Stack class addresses concerns about script duplication. If an
enqueue_script()-like function is written, it should be added there,
perhaps like:
// register a script:
Stack::register('scriptname', '/path/to/script');
// add a registered script to a stack:
Stack::add('stackname', 'scriptname', Stack::REGISTERED);
// Output a stack through a javascript pre-cache:
Stack::out('stackname', array('Stack', 'js_precache'));
It has always been a thought of mine to provide some kind of server-side
caching and compression capabilities via the stack class for both
javascript and CSS output. The end result could be cached under a
hashed key of concatenated script names and times, and then served as a
single compressed javascript include file.
Compression and combination of both JS and CSS would be great, and would conveniently fit right into this queuing and translating functionality.
Regarding the javascript output itself, maybe we should consider using
something like this (MIT license):
http://code.google.com/p/gettext-js/source/browse
This seems as though it could load the gettext translation files
directly. All you'd need to do is add a line of javascript to tell the
browser to load (and hopefully cache) the translation file.
There's actually an open ticket on the WP trac [1] which provides a patch to implement something very similar to this, instead of relying upon their existing structure. It actually wraps everything back through PHP as well, so I'm still not sure exactly what it buys you, at least at this point.
I would be hesitant to use a JS-based implementation for several reasons. First, it gives us yet another gettext engine we need to make sure is functioning. I'm also slightly paranoid about JS load, particularly in some slightly older browsers. Having the browser parse out more than a handful of strings per-page could potentially kill you, especially if you're using an already AJAX-heavy site. It would also eliminate the possibility for us to do any type of queuing, compressing, or combining.
I'd say sticking to a PHP implementation is probably the way to go. Who knows, I may even give it a look sometime this week...
[1] WP JS-based gettext: http://trac.wordpress.org/ticket/4559