compare-locales 0.9.5

Busy times for compare-locales, there’s another release out the door.

New in this release are a significant rewrite of the Properties parser. A lot less regular expressions, a lot more performance in bad situations. Thanks to glandium for poking me hard with a patch. That patch didn’t work, but at least it got my butt to it. Comparing bn-IN is now down to 23 secs for 3 minutes+.
The next big thing is that I now run checks on entities that are keys, too. That doesn’t seem to have caused any regressions, but look out for new false positives. On the plus side, if you use ‘&’ as accesskey, you’ll get an error report instead of a ysod.
Finally, I added support for mpl2 license headers, so we’re all set there.

As usual, update with pip install -U compare-locales.

What’s a glossary term?

I’m hacking on some tool that indexes the localizable strings in our apps.

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.

Web-based IDEs for Localization

There isn’t much news on the localization tool front that I started at MozCamp in Berlin, but I’ve got some more questions for the web tool guys among you. As any good project, a localization editor should stand on the shoulders of giants, so I’ve been looking at Orion, Cloud9/Ace, and etherpad-lite. All of them got parts right, and I try to gather some input what it’d take to bring home the rest. I’ve set up an etherpad each for you to type to,

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.

compare-locales 0.9.4 released

There’s yet another update to compare-locales, we’re now at 0.9.4. Please update your local installs with

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.

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 …

Everytime
I redesign
I cry a little

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