Lightning 1.4b2 doesn't work in some Thunderbird 12 l10n builds because it contains a lot of broken localizations. Calendar tab and task tab remains mostly blank. A lot of missing entities errors are reported. For example the following strings are missing in 17 out of 41 localizations:
Localizations that look NOT OK:
bg, ca, de, en-GB, es-ES, et, eu, fy-NL, hu, id, it, ko, nl, nn-NO, pa-IN, pl, ru
Localizations that seems OK:
cs, da, en-US, es-AR, fi, fr, ga-IE, gd, gl, he, hr, is, ja, lt, nb-NO, pt-PT, sk, sl, sq, sv-SE, tr, uk, zh-CN, zh-TW
Compare-locales looks good to me, so obviously we're using an outdated changeset for 'de' - requested a new sign-off with the right one. I didn't remember that I have to care about this after every "merge day"...
How does l10n handling works in current days? For example it seems that some of the strings are visible in hg.mozilla.org/releases/l10n/mozilla-aurora/de/ but not in hg.mozilla.org/releases/l10n/mozilla-beta/de/ ?
I was surprised so many locales were green, so likely this is something with the dashboard.
shows 41 signed-off and accepted locales, on which I've based the b1/b2 release. Here is the milestone page:
Pike, any idea what went wrong here? Did I build b1 too early?
(In reply to Robert Brand from comment #1)
> I didn't
> remember that I have to care about this after every "merge day"...
You shouldn't have to :-)
I also see that the milestone page show a different green-state than the cal_beta dashboard.
I suspect that this is due to sign-offs not being current. We're working on elmo to make that more obvious, sadly our develop branch is suffering a few blocker regression.
I took the sign-offs from the l10n-changeset/shipped-locales of the beta milestone. Would whatever you are fixing also fix it for those generated files?
No, the work on elmo is just going to make it more obvious to localizers that their sign-offs are old.
What I think is likely the major problem here is whether lightning works with l10n merge or not. Cause all the migrations I do assume that old data is fine and l10n merge will handle missing strings.
Maybe that's not the case for lightning, and you'd be fine with having locales go in and out for each cycle?
Lightning does not have l10n merge set up. I don't know if localizers will expect strings to be merged from english, but right now I'd expect their locale to be red on beta if their files are not fully translated.
Signoffs don't work that way. They're producing a given revision, and in case of German, it was the same revision we used for 1.3. That was green at the time, and there's a status now that's green, but it's not signed off on. So compared to today's code, it'd be red, just that there's no decent way to figure that out. Which means that I tried and failed to set that up.
I suggest that you set up l10n merge.
You can also ask me to try to find a way to not have calendar fall back to previously shipped revisions, which it is doing right now, as that's what all the other apps on rapid do. But that's not necessarily going to come quickly, as it's a code change.
Mark, what do you think? Set up l10n-merge? Given we need a solution for now, l10n-merge would probably be best, but if this means that english strings will show up in production versions because localizers will assume that everything is good since the tree is green then I don't think its a good idea.
Again, we *ARE* changing the way old sign-offs are exposed. Please don't overrate over old UX.
What can we do now? Will there be a 1.4 beta3 release available without the broken localizations soon?
Is there someplace else to check if a localization is complete for current comm-beta branch if the l10n dashboard doesn't show reliable information as mentioned by Philipp?
Yes, I should push a beta 3 without those locales asap. I was hoping that I could slip in another fix for a bug, but nothing came up.
I definitely need some place to check this for future betas, it will be quite a hassle to pick out the right changesets and locales from l10n-changesets manually.
Mark is filling me in on how l10n-merge works, I hope to better know what to do afterwards.
ETA on beta 3?
beta 3 is on AMO now.
Axel, can you reference a bug# for the display changes?
How does l10n-merge work on releases? I doubt localizers will want English strings in their releases and since you say there will be no difference to l10n-changesets/shipped-locales I fear this might happen.
Given the release is coming closer, we really need a solution for this and I have the feeling there is no clear solution for this bug and/or I don't see how l10n-merge will help us for releases.
Why was beta3 released without pl locale?
l10n-merge inserts English strings, yes. That's the intended workflow. The idea is that it's usually better to have the main content localized with some English strings than the complete product in English.
We're trying to do some outreach around locales that are behind on Firefox, which helps in some cases. Reducing the outreach view https://l10n-stage-sj.mozilla.org/shipping/outreach/ to just lightning gives me https://l10n-stage-sj.mozilla.org/shipping/outreach/data?app=cal&branch=beta&betadate=2012-01-31&branch=aurora&auroradate=2012-03-13 right now. That helps in trying to reach folks via mail. That view has a few bugs still, and will work slightly different when we get the data bugs figured out, but it's helping a lot as it is.
(In reply to Stefan Plewako from comment #18)
> Why was beta3 released without pl locale?
Stefan, I took out pl based on the list in comment 0. I am aware some locales may have signed off in the meanwhile, I will try to find a solution for this for the next beta release.
(In reply to Axel Hecht [:Pike] from comment #19)
> l10n-merge inserts English strings, yes. That's the intended workflow. The
> idea is that it's usually better to have the main content localized with
> some English strings than the complete product in English.
Ok, I will communicate this to the localizers when I have the final list of affected locales. What needs to be done if a localizer doesn't want english strings and doesn't have time to translate and sign off again? I can take it out of shipped-locales manually, but is there something that can be done on the dashboard?
> We're trying to do some outreach around locales that are behind on Firefox,
Thanks for the outreach link. I've had a bit trouble understanding it in the past, therefore I left it ignored. Maybe you could explain:
IIUC, then the link you gave me tells me that these locales will end up with English strings in Lightning 1.4:
-- bg, en-GB, hu, ko, pa-IN, ru
What I do not understand is the first column. Will these locales also end up with English strings in Lightning 1.4?
-- eu, gd, he, id, lt, nb-NO, sv-SE, tr, uk, zh-CN
(In reply to Philipp Kewisch [:Fallen] from comment #20)
> Stefan, I took out pl based on the list in comment 0.
> I am aware some
> locales may have signed off in the meanwhile, I will try to find a solution
> for this for the next beta release.
pl was green with outdated signoff¹ after last migration² *but* on March 16 (before this bug was filled) Katarzyna Stawarz put new signoff request on dashboard and you accepted it on April 3 (don't know if before, after or in time building beta3) …
all in all maybe pl shouldn't be in b2 but should be in b3 for sure and the process of releasing lightning seems pretty buggy and error prone imo.
1. Rare situation and shouldn't happen again for pl after next migration.
2. Not sure/didn't check when b2 was builded and from what.
I know I've accepted signoffs, but this is the set of files I see when building a new beta:
Its not trivial to find out which of these changesets are correct and which are not. I'm sorry this situation has arisen and I'm doing my best to make things work for the next beta and the release. I agree the process is buggy and error prone at the moment, hence this bug.
The next beta should contain all locales with the correct changesets as signed off. Please bear with me, I'm having as much pain with this bug as you are :-)
(In reply to Philipp Kewisch [:Fallen] from comment #23)
> Its not trivial to find out which of these changesets are correct and which
> are not.
Not really human friendly but probably simple script on top of compare locales or silme should cover this.
Anything that has a link in 1.4 is having an old sign-off. The number you see is the currently missing strings. I.e., '0' means that it's just missing a sign-off, whereas '41' means that even if you took the latest revision, you had missing strings.
The aurora column is the same data for what will become 1.5, just that it's already complaining if you just have a sign-off from the 1.4 days.
There's no entry if there's no old aurora sign-off, though. That'll get fixed once the data piece moves over.
Any news on this? Is Lightning 1.4b3 (without the broken localizations) going to be releases as Lightning 1.4 tomorrow? Or will there be another build?
Yes, this bug can probably be marked fixed. I've emailed the localizers and most of them signed off a new changeset.
Then I did a local compare-locales run and manually removed the locales that were not working (including but not limited to pa-IN and bg) before starting the Lightning build.
The final, working build should be here: http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/1.4
I'm having some trouble uploading due to bug 747623, but IT is on it and will fix in 4-5 hours.
For the next release, I think we should invest some time to set up l10n-merge in bug 741727 and tell the localizers what will happen.