One of the fall-outs could be a glossary tool, i.e., which terms in Firefox, Thunderbird, etc should localizers bother to get consistently translated.

Which raises an interesting question, where do you draw the line? What’s a good metric to use to define a glossary? Are there glossary-based applications that don’t need a cut-off at all?

Insights welcome.

• Comments for Orion
• Comments for Cloud9 / Ace
• Comments for etherpad-lite

A bit of context: Localization is editing code by people that don’t (necessarily) code. An editor needs to take an extra step to make breaking things hard, and editing the right pieces easy. There’s also a host of content assist available to suggest translations, spell checking, glossaries, etc. Which opens two paths: You offer forms, and your localizer will never learn what’s happening in real life, or you drive a code editor beyond what the programmer of that code editor ever needed herself. I would love to try the latter again, this time on the web.

So, if you have some experience with tweaking, wrestling, extending, stripping any of these, or with one I missed, I’d be thankful for your input.

pip install -U compare-locales

Changes since 0.9.3 are:

• Catch % as error. Sadly, there’s not much more the parser reports than Invalid Token, but at least it says something. You need to escape that as %.
• Stability fix, there was a crash on <!ENTITY "reference to &ƞǿŧ;-known entity">. Unicode is hard.

The only change is that it applies the android quote tests to the files in mobile/android/base.

As always, update your local installs by

pip install -U compare-locales

Changes since the last released version:

• Support for nested l10n.inis, notably, browser/branding.
• Errors on CSS specs, notably, if en-US is a length or min-width etc, the translation also needs to be one.
• Warn if CSS specs don’t match in property or unit. Say, en-US gives min-width:14ex and the localization has width:120px, warn. Thanks to Rimas for the request.
• Warn if en-US is just a number, and the localization is not.

See also the pushes on hg.m.o.

You can install/update with

pip install -U compare-locales

Next up is to use the new version on the dashboard.

It’s not part of our release automation, though. Bug 650465 met some resistance in release-drivers, IIRC, as we’d need to change what we’re shipping in 3.6. More errors means failure unless l10n-merge is on on existing builds, which effectively changes all 20 locales that have errors on 3.6.

At the EU MozCamp in Berlin we shared plans for further focusing and expanding Mozilla efforts in Europe – and we thought you might be interested to know what we said.

Mozilla has been widely successful in Europe. The Mozilla Mission resonates especially well with Europeans. The user base of Firefox and Thunderbird is very high, and Firefox is a well understood part of mainstream life.

What many of us don’t realize is that we have achieved this success in Europe with a very complex organizational structure — in fact, we had three different organizations, with separate and overlapping online presences (i.e. mozilla.org , mozilla.com and mozilla-europe.org ). We’ve been asking our communities and users to interact with all three, and we’ve been trying to keep content updated and synced among the three.

Then we started the “One Mozilla” program giving the world the experience of “Mozilla” – the mission and Mozilla programs – not our organizational structure. We have merged our various websites back into mozilla.org – www.mozilla.com is no more. Similarly, www.mozilla-europe.org pages are or will be merged into mozilla.org. Going forward, we are also looking at integrating innovation work across Labs and Drumbeat into the mozilla.org structure.

At the same time, we’ve paved the way for our various communities to operate as an integrated whole by building out a holistic contributor engagement program. European localizers, localizers from other geographies, our international engagement efforts, ReMo, SiGs are all working together. Along these lines, we’ve also been looking at our organizational structure in Europe.

As a result, the Board of Mozilla Europe has come to feel that the Mozilla Europe association as a separate independent entity is no longer needed. We discussed this with Mitchell, who was part of forming Mozilla Europe in the first place (though never a board member) and she agreed this is the best path forward. It became clear in this process that over the years, many of the innovations pioneered by the Mozilla Europe association have been adopted as part of our global efforts. For example, mozilla-europe.org hosted our first multi-lingual Mozilla website and created our first structured system for doing so. Today the model of localized content is woven into everything we do. And MozCamps themselves are another great example of European innovations going global.

Streamlining the global Mozilla organization by transferring initiatives from a regional entity to global team, means that the ideas incubated in Europe can now be more easily expanded on a global scale. Integrating Mozilla Europe efforts under the umbrella of the broader Mozilla organization will allow us to spend less time on bureaucracy and will give us more time to make awesome things happen. We will have clear processes around the globe to continue and expand our presence at local events, to ensure reimbursements and swag orders are easy and timely. We will have fewer web sites to keep updated – and thus more time to create compelling content. We will not do less in Europe, we can do more!

Mozilla Europe did not have paid staff for a number of years. Thus no staff is affected by the changes that will go into effect between now and the end of the year.

It is clear that Europe is an integral part of Mozilla. It’s not a regional part or a regional hub, it’s part of the core of Mozilla. To keep the momentum, we are investing in more Mozilla Spaces across Europe: Paris will be joined by spaces in London and Berlin in 2012. This means we have more room for volunteer participation as well as for paid staff. Thus as we work to significantly scale in Europe and around the world, we will continue to grow this core going forward.

Thus, the session is gonna be titled “Ask Pike”, and I’m fielding questions on google moderator. Of course, I’ll also take questions live.

See you in KL.

Everytime
I change my mind
I wonder why a little

Sung to the tune of that song that Simply Red covered and bug 650816.

Also known as ux-jargon and completely useless.

As many folks wonder why I’m still talking about how the l10n dashboard needs more work, I’ll put some details out there.

The Milestone object is the thing we use to keep track of which version of a localization was shipped in which release-style build. It’s backing up views like Fennec 6 Beta 3 milestone info page, and says “we’re adding pl, and updating nl, ru, zh-TW”. That could be used for QA and verification etc.

The AppVersion object is tracking a particular release. Say, Firefox 3.6 or Firefox 6. It’s containing a series of milestones. The AppVersion objects are tied to an Application object.

The actual compare-locales builds are hooked up to a Tree object, which represents the repositories to compare for a particular application.

The trick is how all these objects are tied together. Gandalf and I designed this back in the days of the Firefox 3.6 release. Back in those days, we had loooong release cycles, with lengthy cycles even for individual milestones, and string freezes for each milestone. At that point, we’d open up sign-offs. Remember, back in the days we wouldn’t have l10n-merge on for release builds, so we could only start reviewing the localizations after string freeze. Also, we did the hg branches for a release early in the cycle, and then we would ship most of our betas from that branch, while development on central progressed merrily.

Thus, our design decisions back then were:

There’s one static repository setup for a version of an application. Umpf. Can you see how bad that is today, where we switch our repo setup every six weeks?

Whether a localizer can sign-off or not depends on whether the upcoming milestone is string frozen or not. In other words, we need to have the upcoming milestone early to begin with, which is such a hassle now that we’re doing them weekly, instead of bi-monthly. Also, with l10n-merge and string-frozen branches, all that logic just … face palm.

Localizers sign off on a version of the application, with a push to its l10n repository. Pushes are per repo, appversions are spanning repos today. I.e., I push on aurora, sign off, it’s good, the appversion migrates to beta, but the push is still on aurora.

Review actions on sign-offs are forever. Say, I r+ a sign-off on aurora, that goes to beta, but there’s a lack of traction that makes that revision really bad to ship for the next cycle. I can’t make that sign-off bad for Firefox 12 and good for Firefox 11.

Lessons learned:

• appversions hop from tree to tree, over time
• sign-offs are per tree, this localization at this point is good, source-wise
• actions on sign-offs can be per appversion
• milestones aren’t required before we actually ship something

Or, as we say in German, we have to put the design “vom Kopf auf die Füße”.