Since it probably looks like my favorite hobby is whining without a reason, let’s check what happened so far (always an optimist…) in this cycle.
Broken strings in Mozilla Beta
- Bug 797036 – Update updater strings and icon
- Bug 803344 – poor discoverability of the enable/disable menu item for Social API
Landing strings in Beta means that we did something wrong before (haste of moving forward features that weren’t probably ready, “we need this in ESR”, etc.).
Broken strings in Mozilla Aurora
Obviously the two changesets landed on beta, plus:
- Bug 795691 – b2g fixes for the web console actors
- Bug 800373 – Change marketplace strings to ‘Firefox Marketplace’
Consider several adding/removing strings both in beta and aurora (e.g. Bug 803630 or Bug 760951) and you’ll get the picture.
Bug 797036 is a good example of how bad we are working on the l10n side lately:
- changes land on central on Oct 02 16:34:08 (end of cycle is only 6 days ahead)
- the day after I wrote a comment in the bug about the bad review (that’s pure luck, I don’t work on localization every day, and there are very few localizers doing this kind of checks on central)
- nobody reacts, bad strings move to aurora and we need to break string freeze
For a starter a better review process could have avoided all this.
6 responses to “Once upon a time there was a string freeze… pt.2”
I generally think it’s a bad thing to break our string freeze. But I don’t think the string freeze process is something we should value in itself – it’s only valuable insofar as it helps us ship good quality, fully localized software. If the string freeze gets in the way of doing that, then the right thing to do is to break it. Sometimes these decisions can be difficult: we’re faced with two hard choices, and we need to pick one. Maintaining string freeze shouldn’t be treated as an absolute. Of course, once you recognize that, it becomes a matter of tradeoffs – and it’s natural that people in different positions would have different estimations of what’s most important 🙂
Rather than focus on why we keep breaking the string freeze, I think it’s more valuable to focus on how can we make breaking the string freeze less of a problem (or not a problem at all). We will continue to occasionally need to have more flexibility to move faster than our 6 week cycles allow, and we will continue to make mistakes (that’s just the nature of software development). Figuring out ways to deal with those situations that cause the least amount of localizer pain is what we should all be focused on, in my opinion.
Hi Gavin, the problem is that string freeze is there to ensure exactly that, using your own words, we “ship good quality, fully localized software”. And for this very reason I believe that it’s valuable for itself.
Shipping a product (release) with unlocalized strings is far from being good quality, and that’s what you risk breaking string freeze on beta (which, for those who don’t know, it’s just 5 weeks long for localizers).
I think you’re wrong on this. Instead of making string breaks less painful (which is obviously a good thing), we should focus on why we’re breaking rules every single time. Focus on the cause, not the effect.
Why are we breaking string freeze so often? Let’s start with looking at how we do reviews (e.g. string changes landing without changing keys), fix poor quality of English strings, and maybe understanding why we are unable to catch problems earlier (see social APIs).
To your first point: I don’t believe that a 12 week complete string freeze is the *only* way in the world to ship high quality, fully-localized releases. It serves us well in general, but in a lot of cases, there are external factors that make it sub-optimal. It may be one of the only ways given our current tools and processes, but we shouldn’t assume that changing those is impossible – even if it may be hard.
To your second point: you’re right – it’s important to look at both problems. It’s not one or the other. Definitely, we should continue to try to improve l10n-awareness amongst code reviewers, and plan ahead to avoid problems before they occur. But at the same time, I don’t think we’ll ever be able to be perfect here, given the realities of software development, and so it’s also valuable to look into making those inevitable mistakes less costly.
Talking about hurting less, I realized that bug 795691 has been managed pretty good: a fix without UI changes was committed to Aurora, new strings only in Central (what I saw was originally pushed to Aurora by mistake).
There’s something between
1211 weeks and less than 2, and don’t forget that, ignoring l10n drivers, localization in Mozilla is based only on volunteers’ work.
Of course – I’m not proposing what happened with that Social bug as the ideal model. It was a tough call made in unusual circumstances, and we should try to avoid it ever happening again. I think my original points still stand, though.
I am well aware of who makes up our localization community, and the value and quality of their work, for which they get not nearly enough thanks and recognition. It offends me a little that you would imply otherwise 🙂
That wasn’t really my point, sorry if it came out this way 😉
I read your “world” as “outside Mozilla”, maybe misreading, and I simply meant that I don’t know how other OS projects work (i.e. how much l10n work is based on volunteers), having experience only with Mozilla and WordPress, so I have no idea if there are better ways to do what we’re doing.
What I know for sure is that using localized OS software is often a painful experience: low quality, mixture of English and localized strings, sometimes the entire localization is dropped from one version to another because incomplete. So, from my small experience, grass is not really greener on the other side of the fence.