Ubiquity BabelZilla locale status / Best l10n & l18n practices

13 views
Skip to first unread message

Lech Deregowski

unread,
Sep 12, 2009, 10:13:58 PM9/12/09
to Ubiquity i18n
Hey everyone, it's come to my attention that we haven't really had any
l10n / l18n stuff to discuss in a while, and I figured some of you
could offer me some opinions and insight on which locales we should be
activating in future versions of Ubiquity based on their Babelzilla
status.

Also, I'm not familiar with how they do it for Firefox and other
Mozilla-based projects (if anyone knows and could quickly explain it
for me or provide me with links, I'd love to research it further) but
currently we've been learning and establishing routines as we go.
While we've been learning, we've had many questions and I'd like to
(with your help of course) get some questions answered and possibly
outline a localization policy/checklist of some sort which applies to
future Ubiquity releases and unstable beta pre-releases.

A little background: Up until now we've been pushing two slightly
different versions of Ubiquity between normal releases and those
Babelzilla. The difference between these two versions is very minor
and only affects the chrome.manifest files which tells Firefox which
localizations are available for Ubiquity at install time. Babelzilla
makes it pretty clear on what it requires when you update your
extension, and wants you to upload with existing localizations as
missing strings skipped. This is fine and we have no problem with
supplying Babelzilla a version of Ubiquity which meets this
requirement.

Not long ago after including Ubiquity on Babelzilla (during the
0.5.5pre-releases) we discussed and decided that it would be easier to
maintain all locales in Hg as missing strings skipped as well. The
reason behind that decision was based on a few factors, and rather
than maintaining multiple versions of Ubiquity or its locales we
decided it was easier to maintain one set of locales within Hg rather
than having to guess which type (replaced/empty/skipped) we loaded at
any given time. This allows us to push out two different versions,
with one going to the public and the other going right back to
Babelzilla for more localizing if necessary.

The only problem with that was that for each release we then had to
tweak the chrome manifest to produce different packages (one for
release, and one for Babelzilla respectively) which would reduce
normal end-users facing about: page XML parser errors (those are not
fun) when incomplete localizations were present. So a few weeks ago I
make it a little easier on us by maintaining two different
chrome.manifest files aptly titled chrome.manifest.release and
chrome.manifest.bz which allows us to swap the files in and out for
building each package.

Now the questions I currently have is: I know the status of a
localization has a purpose, but should there be a policy which
includes or excludes a localization based on this status? Until now, I
really didn't consider the status of a localization as being that
important and so long as the localization was 100% complete we
included it. But lately the question popped around in the back of my
head, and now I'm wondering whether or not I should follow a checklist
when activating localizations. I guess this is also me trying to
prevent someone else from accidentally inserting their own "modifier"
into a locale and having it appear in a final release.

So for now, Babelzilla releases will remain unchanged. But if there's
something I can do for the BZ community to activate and support more
languages easier when we upload the next version, let me know and I'll
update the manifest. But as far as pre-releases and releases go I
still want your insight. So far my reasoning has been 100% = include
localization, and that's about it. Now I'm pondering on whether or not
I should consider the status for when we want to include translations
in pre-releases or a final releases as well.

Meaning, if the localization is 100% but the status reads "in
progress", "review requested" or "testing/QA" should we exclude it in
that release and only include those which are green-lit 100% and
marked "released"? I ask because all of our Babelzilla translators
have been great so far, and because I want to include only the most
relevant localizations for future Ubiquity releases.

At the same time, I was possibly thinking we could also maintain a
chrome.manifest.pre-release to distinguish pre-releases from final
releases where 100% green-lit "released" localizations fall under
the .release manifest. And "in progress, "review requested" or
"testing/QA" localizations could always be included under the pre-
release manifest file respectively. But before I make any decision on
this, I could seriously use some feedback.

Sorry if that was a bit long,
-Lech

Leszek Życzkowski

unread,
Sep 13, 2009, 7:29:23 AM9/13/09
to ubiqui...@googlegroups.com
Lech,
As you know, I'm experienced translator to Polish. In my mind if I marked my translation "released" I take all responsibility that this translation is good grammatical, punctuation and all Polish language rules are correct, and my translation matching to extension layout. For fulfill these elements I have to make many tests, so I have to have fully working extension version. Terms "review requested" or "testing/QA" informed about status mywork. If you decide using translation with one of these stages, you will take responsibility.

Regards
Teo

2009/9/13 Lech Deregowski <unatt...@gmail.com>

Lech

unread,
Sep 14, 2009, 3:15:36 AM9/14/09
to ubiqui...@googlegroups.com
Thanks for the input, Teo. I figured that this is what status was
meant for but until now haven't really been relying on them as
heavily. So, I think it might be time for me to update and activate
localizations within Ubiquity based on the status instead of simply
relying on the fact of if it's 100% or not after this next
pre-release.

This will hopefully be a better way for me to perform quality control
and not a method of excluding translations. In fact, I'd love to see
more translations for Ubiquity so anyone who can provide them, keep
them coming. But I also want to figure out the best way to include
translations based on the type (complete vs incomplete) and when they
should appear based on the release we're doing (final vs pre-release).

After briefly discussing it with satyr, we rehashed how to approach
localizations in Hg. Ideally I would like to include only those
translations which are 100% complete and marked as "released"...
However I have been asked recently and have noticed a few that are
90-97% complete and are only missing some strings (anywhere from 4 to
40 total) but those missing strings are confined only on the developer
pages; meaning that they could be included.

What this means is that we could possibly switch from including
locales as strings skipped (where missing strings break stuff) to
strings replaced (skipped strings are back to English). And while I
can't at the moment think of any major negatives for switching, (other
than end-users possibly seeing mixed languages all over the place) the
only caveat would be having to perform a quick rebuild of
localizations we store in Hg. And the possible need to maintain
another chrome.manifest for pre-releases (which I don't mind
maintaining if it makes things easier).

So a quick breakdown for including and activating these locales would
go something like this:

For a beta pre-release, a localization would have to meet the
following criteria:
- the localization is 90% to 100% complete
- has 100% localizations for all aboutubiquity / coreubiquity files
- the status is either set to "released", "testing/QA" or "needs
review" (maybe needs tuning)
- devubiquity file localizations could be stored as string replaced
until the localization becomes complete.

And for a regular stable release, the above would still apply, the
only difference is that only those localizations with a status of
"released" at the time of commit (the small window between download,
review and actual release) would be activated for install.

Meanwhile releasing a strings skipped version back to Babelzilla would
remain the same but locales wouldn't be tracked in Hg. Instead myself
or someone else could swap the locale folder with the strings skipped
version before sending it back to Babelzilla. This would take all of 2
minutes, maximum.

Does this seem like too much or is it reasonable enough to work with?
And what could be made better? The end result would obviously mean
that there would be less broken about: pages, but at the same time we
might not have as many localizations available at any given release
unless they met the requirement.

-L
Reply all
Reply to author
Forward
0 new messages