Jetpack localization - Common Pool feedback round
Zbigniew Braniecki
I recently published two blog posts on the approach we're taking toward
making Jetpacks (or, rather new Addons) localizable.
The first blog post is an introduction to the concept, the latter is
more of a tutorial.
1)
http://diary.braniecki.net/2011/01/12/jetpack-localization-common-pool-approach/
2) http://diary.braniecki.net/2011/01/12/using-common-pool-tutorial/
Since you're the target audience in terms of localization, and many of
you also posses the magical coding skills that allow you to be the brave
extension authors you constitute the perfect group to evaluate if the
concept makes sense, and should be promoted as an official solution for
Addon SDK.
I'd like to ask you all to take a look at this stuff, and let us know
what you think. :)
Thanks!
g.
--
Mozilla (http://www.mozilla.org)
dynamis
# CCing to jetpack leader, myk
Sorry for long post but let me write some concern about common-pool (or
get-text, 1-to-1 translation) type l10n system.
Common pool system is simple and work enough for some case. It's good for start.
But if we don't care enough, the system will have really limited one.
Even if you cannot solve these problems soon, please keep in mind and design
system which is extensible to support these features.
My first concern about get-text type common pool is always, as already written
in the blog, we cannot define different translated entity (words or phrase) for
one English (or any other original lang) entity.
Ideally localizer should be able to translate differently depending on:
Word Class:
ex. "open" is sometimes verb, sometimes adjective etc. Translation of them
will be different.
Platform:
In some language, we use different translation for the same word depending on
the OS. In Japanense, we need translate really basic words like "cut",
"paste", "window" or "print" differently on Windows/Linux or Mac.
Applications should use same translations as OSs.
Type of Widget:
Where the words are used. In menu? in text label? Some localizer need to
translate differently if the label is command name (in menu or button) or
description text (for checkbox label etc).
Context:
As you know, need to translate depending on the context.
Firefox or Thunderbird solve this problem by defining ids for each entity and
avoiding to use same entity in the different context.
# though sometimes used in different context and we have headache
One trivial workaround is to define entity id with optional parameter like:
var _ = require("localization").get;
_("Open") // use default translation for "Open"
_("Open", "verb") // use verb translation for "Open"
_("Open", "adjective")
_("Cut")
_("Cut", "Win")
_("Cut", "Mac")
But this have 2 problems:
- translated correctly only when Add-on auther use second param
- no standard way to know which phrase should use second param (add-on auther
should notice easily if there are 2 or more translations)
# add-on sdk can output warning if second param is not specified for the
# phrase having multiple translations?
Even when add-on auther don't specify the context by id (or any other way),
localizer want to use different translation for different add-on etc.
We can help this if localizer can specify different translation for
- platform (win, max, unix)
- application (firefox, thunderbird, fennec...)
- add-on author
- add-on ID
- specific file (by filename, resource id etc)
# These attributes can be automatically handled without API change I believe.
Thought this may be out of goal of common-pool, second typical problem is, word
and UI item order (multiple entity as a group). We sometimes insert textbox etc
within the sentence like:
Limit cache to [ 1024] MB of space
http://gyazo.com/0ba752ffd139b58fac25956449319db2.png
In this case, add-on auther should define 2 entity "Limit cache to" and "MB of
space" for one sentence. Localizer need to know which labels are used in one
sentence. In some language, word order is different and we want to set text only
for "before" (or "after") label and make blank for another.
If English have only one-side, say "before" label, we cannot add "after" label.
Minefield will: [Remember history]
http://gyazo.com/1e5481a1f89473d654ee69ae96dcca43.png
Most of Add-on or web developer (including sumo, mdc too) don't care about this
and we sometimes difficult to translate naturally. To solve this, localizer need
to change the UI item order (like ltr/rtl) or define pseudeo-entity like:
en-US: "Minefield will:", KEEP_POSITION
xx-XX: "xxxxxxxxxxxxxx.", AFTER_NEXT_TEXTBOX
# But this is maybe really difficult to do and need other way?
Third concern is, equality of languages. In Firefox or web site, one language is
always original (English for Firefox). But as for add-ons, original language is
not always same. We should define any language as original. Translation is not
1-to-1 (as I wrote first). Localizer should be able to define translation for
any other locale, not only for English.
In other words, add-on auther should be able to use any language as ID like:
var _ = require("localization").get;
_("日本語") // japanese text label as ID
This is important to keep l10n quality of non-English add-ons.
Thanks.
Axel Hecht
thanks for your input.
As you noted, some of your concerns are out of scope for commonpool.
The one that I'd like to see us take is the one about non-English
original language, that sounds like a good bug to file.
A bit more detail on the scope:
For jetpack, we want to approach l10n from two directions, commonpool
and l20n. L20n is what I and gandalf are hacking on, with a strong
emphasis on getting linguistic and functional correctness. Commonpool
targets the "I want a button or menu item for my pagemod", and possibly
a bit more complex jetpacks.
In that sense, the examples you mentioned all fall into the bucket of
l20n, and you raised some tricky edgecases like UI control placement, or
platform nuances in particular languages. Not all of them are in good
shape with l20n so far, but we have at least most of them on the table.
Which leads to a slightly different question:
Do we plan to integrate commonpool and l20n?
No, we don't have any plans to integrate commonpool and l20n. Neither is
mature enough to actually have a solid foundation for plans, and it
could very well be that one would break the other. At this point, we're
designing both with integration being a non-goal.
Yes, the jump for jetpack authors from one to the other will be
recognizable, but that's a problem we attack if we get there.
Axel