The l10n.ini files for the applications using toolkit from releases/mozilla-1.9.1 need to say so in the l10n.ini files. That's kinda ugh, but I don't see a way to not ugh that. Hacking it up in each and every build config around would just suck as bad.
Hmm, I suppose there isn't a way we could ifdef this? Thunderbird will (and maybe SM/SB) be capable of doing builds off mozilla-central at some stage soon, and I see no reason to limit "trunk" testers to en-US builds.
I don't see how that would work with ifdef's. One thing we can do is to move the information out of l10n.ini back into the buildconfig. That's somewhat yucky, too, as you then need to bug me to get changes live, but I guess that that'd be the only way to deal with fennec, too.
When we branch comm-central, this effectively won't be an issue. So the question would be what do we do until then. gozer is just starting to think about setting up builds with comm-central and mozilla-central for Thunderbird. I can see us being in a non-branch state for a couple of months, maybe a few more. So given that FF 3.2 effectively covers mozilla-central strings, and comm-central strings are covered by TB 3/SM 2 etc then I think the solution would be to take your patch to change the repo, and not care about TB.next (etc) builds showing on the dashboard until after we do branch comm-central. We can either not produce mozilla-central l10n builds or just let the localisers know that there won't be a dashboard for those for a while, as the focus is TB 3 etc.
I have been looking at my attempts to put that info into the buildbot system, and it turns out to be a sad and brittle duplication of a lot of information. I'd prefer to keep the info about l10n builds within the source, and update the 1l0n.ini builds to pick up the 1.9.1 branch.
Ok, let's do that, 1.9.1 will be the main focus of development/locales for the next few months at least until we branch, and we should be pushing any development that way anyway.
Comment on attachment 351569 [details] [diff] [review] patch for mail Not sure what we need to get this moving, but based on our previous comments r=me for this patch if you want it.
Attachment #351569 - Flags: review+
This bug would need a comm-central owner to land similar changes for all the comm-central apps.
Which really means it needs two more patches (or bugs?) for Sunbird and SeaMonkey, and that these patches would all need to land at the same time, right?
Assignee: nobody → bugzilla
Component: Build Config → Build Config
Product: Toolkit → MailNews Core
QA Contact: build-config → build-config
Created attachment 354718 [details] [diff] [review] patch for calendar and suite Here's the patch for calendar and suite.
Attachment #354718 - Flags: review?(kairo)
(In reply to comment #9) > Which really means it needs two more patches (or bugs?) for Sunbird and > SeaMonkey, and that these patches would all need to land at the same time, > right? This could be one patch, it's easy stuff, and it doesn't matter if it lands all at the same time or not, AFAIK.
Comment on attachment 354718 [details] [diff] [review] patch for calendar and suite I haven't tested this (how would i?), but it's logical enough :)
Attachment #354718 - Flags: review?(kairo) → review+
Both patches pushed: http://hg.mozilla.org/comm-central/rev/2c97f3a14679 http://hg.mozilla.org/comm-central/rev/01f42ea14147
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b2
Patches for Calendar should always have the review of a calendar developer. However, since the patch is obviously right, r=sipaq retroactively.
(In reply to comment #14) > Patches for Calendar should always have the review of a calendar developer. Sorry Simon - I took this as a build config patch which from how I understood falls under the realm of the comm-central build config team.
You need to log in before you can comment on or make changes to this bug.