Last Comment Bug 736717 - Lightning 1.4b2 not working due to many broken localizations
: Lightning 1.4b2 not working due to many broken localizations
Status: RESOLVED FIXED
:
Product: Calendar
Classification: Client Software
Component: General (show other bugs)
: Lightning 1.4
: All All
: -- blocker (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 741727
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-17 03:45 PDT by Stefan Sitter
Modified: 2012-05-07 07:20 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Stefan Sitter 2012-03-17 03:45:55 PDT
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:

  calendar.context.postpone.label
  calendar.context.postpone.accesskey
  lightning.toolbar.gototoday.label
  calender.events.filter.currentview.label

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
Comment 1 Robert Brand 2012-03-17 04:12:27 PDT
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"...
Comment 2 Stefan Sitter 2012-03-17 04:17:45 PDT
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/ ?
Comment 3 Philipp Kewisch [:Fallen] 2012-03-17 11:56:25 PDT
I was surprised so many locales were green, so likely this is something with the dashboard.

https://l10n-stage-sj.mozilla.org/shipping/dashboard?tree=cal_beta

shows 41 signed-off and accepted locales, on which I've based the b1/b2 release. Here is the milestone page:

https://l10n-stage-sj.mozilla.org/shipping/about-milestone/calendar1.4_beta_b1

Pike, any idea what went wrong here? Did I build b1 too early?
Comment 4 Philipp Kewisch [:Fallen] 2012-03-17 11:57:33 PDT
(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 :-)
Comment 5 Philipp Kewisch [:Fallen] 2012-03-17 12:02:15 PDT
I also see that the milestone page show a different green-state than the cal_beta dashboard.
Comment 6 Axel Hecht [:Pike] 2012-03-19 04:07:34 PDT
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.
Comment 7 Philipp Kewisch [:Fallen] 2012-03-19 17:18:08 PDT
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?
Comment 8 Axel Hecht [:Pike] 2012-03-21 16:50:25 PDT
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?
Comment 9 Philipp Kewisch [:Fallen] 2012-03-21 17:13:04 PDT
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.
Comment 10 Axel Hecht [:Pike] 2012-03-21 17:21:50 PDT
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.
Comment 11 Philipp Kewisch [:Fallen] 2012-03-24 04:57:26 PDT
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.
Comment 12 Axel Hecht [:Pike] 2012-03-25 09:16:28 PDT
Again, we *ARE* changing the way old sign-offs are exposed. Please don't overrate over old UX.
Comment 13 Stefan Sitter 2012-03-27 10:24:20 PDT
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?
Comment 14 Philipp Kewisch [:Fallen] 2012-03-27 12:17:24 PDT
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.
Comment 15 Geoff Lankow (:darktrojan) 2012-04-02 19:30:27 PDT
ETA on beta 3?
Comment 16 Philipp Kewisch [:Fallen] 2012-04-03 03:42:36 PDT
Currently building
Comment 17 Philipp Kewisch [:Fallen] 2012-04-09 01:53:09 PDT
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.
Comment 18 Stefan Plewako [:stef] 2012-04-10 04:02:28 PDT
Why was beta3 released without pl locale?
Comment 19 Axel Hecht [:Pike] 2012-04-10 04:32:51 PDT
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.
Comment 20 Philipp Kewisch [:Fallen] 2012-04-10 05:20:48 PDT
(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.
Comment 21 Philipp Kewisch [:Fallen] 2012-04-10 05:49:37 PDT
(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
Comment 22 Stefan Plewako [:stef] 2012-04-10 05:52:23 PDT
(In reply to Philipp Kewisch [:Fallen] from comment #20)
> Stefan, I took out pl based on the list in comment 0.

Wow…

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

meanwhile?

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.
Comment 23 Philipp Kewisch [:Fallen] 2012-04-10 09:16:19 PDT
I know I've accepted signoffs, but this is the set of files I see when building a new beta:

https://l10n-stage-sj.mozilla.org/shipping/l10n-changesets?ms=calendar1.4_beta_b2

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 :-)
Comment 24 Stefan Plewako [:stef] 2012-04-11 01:13:04 PDT
(In reply to Philipp Kewisch [:Fallen] from comment #23)
> https://l10n-stage-sj.mozilla.org/shipping/l10n-changesets?ms=calendar1.
> 4_beta_b2
> 
> 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.
Comment 25 Axel Hecht [:Pike] 2012-04-11 05:49:58 PDT
Re outreach:

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.
Comment 26 Stefan Sitter 2012-04-23 04:41:18 PDT
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?
Comment 27 Philipp Kewisch [:Fallen] 2012-04-23 04:54:31 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.