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
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
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
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,