[LibX] prefs panel translation

Brian Nicholson brn at vt.edu
Sat May 5 12:49:53 PDT 2012

> Ok - Brian - I was rereading 5.2.3 in your thesis, but could you please
> remind me why we decided on the embedding for the user layout files vs. the
> external files for builtin.tmpl?  It seems embedding is harded to maintain,
> e.g., we can't use something like
> http://libx.org/libx2/libx2-git/src/base/translate.php?locale=fr
I think we made this decision before we implemented the templateScope. We
wanted to allow templates to be created/hosted by other developers, so we
needed a way to figure out the localization URLs. We originally tried to
determine them based on the URL template being processed, but this didn't
work well because of the hierarchical nature of templates (where a
template's ancestor may contain its localization data). Having the
templateScope enables templates to perform their own custom processing.
builtin.tmpl is an additional layer specifically designed for localizing
its children, who get their localization messages with the custom
"templateScope.data.getMessage()" instead of the existing "{L L}" syntax.
We could probably do this everywhere if we wanted to, which would allow
third-party developers to create their own i18n template layer, like
builtin.tmpl, that specifies the localization URL.

Another problem we noticed was with our layered i18n implementation. Given
some locale, say jp, we would first look for jp/tmpl.json, then
en_US/tmpl.json. We don't cache 404s, so this resulted in a lot of requests
for invalid resources. I think this was part of the reason we decided to
also embed localizations in LibApp feeds.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mozdev.org/pipermail/libx/attachments/20120505/9881b3ae/attachment.html>

More information about the Libx mailing list