Minor update to compare-locales for mobile/android/base

I’ve just pushed a minor update to compare-locales to pypi and the dashboard.

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

compare-locales 0.9.2 released

I just uploaded a new release of compare-locales to pypi, hg.m.o and github.

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.

Mozilla Europe and Mozilla in Europe

The message below has been communicated to MozCamp Berlin attendees and Mozilla employees via email, signed by Mitchell Baker and Tristan Nitot, but this should be public, so it has been posted to mozilla.governance. We also wanted to put it on a blog so that it ends on planet.mozilla.org, but Tristan’s server is in trouble. Being a Mozilla Europe board member, with approval of Tristan and Mitchell, I’m posting it here. Feedback and discussions should happen on mozilla.governance.

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.

Ask Pike at MozCamp Asia 2011

I’ll be at MozCamp Asia 2011, and as I haven’t been to Asia outside of India, I figured I should talk about the things you want me to talk about, and not about what’s on my head.

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.

… sung to the tune of …

I redesign
I cry a little

I change my mind
I wonder why a little

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

Why I hate git

wokbok:django-durationRel axelhecht$ git push -f
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 560 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /Users/axelhecht/src/django-durationRel
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/Users/axelhecht/src/django-durationRel'

Also known as ux-jargon and completely useless.

Data models and “vom Kopf auf die Füße”

As you all know we’re having a new release scheme. That’s all good and great for localization, but there’s one tiny little peppermint: It exposed each and every design problem in the l10n dashboard, code-named elmo these days.

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”.

Coming soon: cross-repository network graphs for hg.m.o

Did you miss the ability to look at our source code and figure out who’s working on what where? Thought that only github can do that?

Let me give you a sneak peek at what I’ve been hacking on over the weekend.

What’s the big picture of our mainline code development?

branched repos of mozilla-central

You can see the blue line of development along mozilla-central, and then branch points for the release branches, and now for beta (miramar), and aurora. That’s pretty broad, and intentionally so. If you’re interested in the back and forth on a changeset level, this is how the branch point of fx5 beta looks:

changesets around the fx5 beta branch point

Why does it say aurora? Because hg doesn’t know what you’re looking for. I determine what was branched off of what by looking at pushes, wherever a particular changeset was pushed first, wins. As beta branched off of aurora later, you see that this was the branch of aurora at the time.

Sadly, you don’t see the more interesting detail, that after that branch, the developer tools branch merged. If the database in the backend was tracking our project repos, you’d see that.

Of course, there’s also an l10n side to this. I get many questions on what to merge and where and so, and it’s hard to see what ended up in which repo, and if things are different. Let’s follow one of the l10n repos at large:

branched repositories of Japanese

There’s even more details on the rapid branches for this one, like so:

changesets around the Japanese fx5 beta branch

Many of the same landings, but with different hg changesets, and then a merge. That merge didn’t make it to miramar, though. Which is OK, that’s a one-off anyway.

Now that I wetted your appetite, bad news: Nothing of this is live yet. I’ll actually need to make a patch at least for the API in bug 659260, get review and get it live. Also, this is currently code that’s run as part of the l10n dashboard, which isn’t really intended to cover all our sources. If we want this at large, it’ll need liberation, and the resources that comes with that. The actual code is pretty easy to liberate, though.

And, graphs are made with protovis, including a custom Network-based layout to do DAGs.

Reviewing sign-offs, slightly different

Opening the magic box of l10n admin stuff:

We’re doing sign-offs, y’know? Localizers hit the l10n dashboard and click a button to say “this revision is good to ship”. Which is cool, because then they don’t need approval for every patch for release branch fixes.

And I’m reviewing the signoffs. Sounds all good, and well proven.

Enter the new release cycle. What’s new? This is a small update, on a quick turnaround. So I can’t do what I did for previous releases, and just not review the first sign-off. That was just an early beta (for most locales) and had a 1000 new strings. Sounded fair. Anyway, now we’re just doing 30 strings, so doing an incremental review against what’s on 4.0.1 is in order. So what does that mean?

  1. I need to get the revision that we’re shipping on 4.0.1. For sign-offs that update one branch, that’s all hooked up in the UI, but not for 4.0.x to 5. That’s bug 655943.
  2. The revision on 4.0.1 is on l10n-mozilla-2.0, the signoff on 5 is on a revision of l10n/mozilla-aurora. Neither need to exist in the other repo, so you can’t just use plain hg commands on a repo. That’s bug 655942.

Now, I wouldn’t be me if I wouldn’t script myself out of it, here’s the gist of it. And yes, this blog post is as much code comments as there are for that one.

Back home, a good deal lighter

Next time you see me, I’ll look a tad different. That bump on my head got removed, surgery yesterday went fine, got home today. I’ll be taking it slow today, but should be up to speed tomorrow.

Thanks to all the good wishes.