Closed Bug 1173973 Opened 9 years ago Closed 9 years ago

Langpacks for Thunderbird do not include Lightning strings

Categories

(Thunderbird :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: evangelos, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150602115007

Steps to reproduce:

In Arch Linux we provide localization packages for Thunderbird. Each supported language has its own package that contains an .xpi file downloaded from the FTP server. [1]

Now that the Lightning calendar add-on is bundled with Thunderbird, I need to provide langpacks for it as well.

[1] https://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/38.0.1/linux-i686/xpi/


Actual results:

I can only find localized Lightning builds and extracting the locales from these isn't straightforward. [2]

[2] https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/candidates/4.0.0.1-candidates/build1/linux-i686/


Expected results:

It would be nice if localization for the Lightning extension was provided as part of the Thunderbird langpacks or in separate Lightning langpacks.
Not sure where this belongs, moving it to Thunderbird for the time being.
Component: Infrastructure → Build Config
Product: Mozilla Localizations → Thunderbird
Afaik there is no such thing as a language pack for an extension, I'm not sure how we should generate that. Its also not right to include the strings in the Thunderbird langpack, so that is not an option either. Also not quite sure what to do here.
Creating an extension with a langpack type, thunderbird target, and calendar strings/chrome.manifest would work.
I downloaded lightning-4.0b6-sm+tb-linux.xpi from AMO and it includes all available locales.

With the above in mind, would it be possible to ship all locales in the Thunderbird source tarball and include them in the resulting add-on that gets installed when --enable-calendar is passed in mozconfig?
I have a few manual script to do that, and I do this for the builds I upload to AMO. If with the "source tarball" you mean the bundle from [1], it has not been common to include locales in this bundle.

If you pass --enable-calendar, then the Lightning in /path/to/thunderbird/distribution/extensions/ will contain only the locale that Thunderbird is built with (and also only the .so file for that ABI), this is what we do for the localized Thunderbirds in [2]. This is due to the way the packager works, and the fact that its not easy for us to introduce extra build steps into the release process that are not common to all Mozilla products.

I don't exactly know how your users install localized Thunderbird versions, but if you want to create a multi-locale Lightning package, you could either download the Lightning packages from [3] and run my scripts, or get all the Thunderbird packages from [4] and run a modified version of my scripts that repacks those. What the script is doing is (simplified) unzipping all Lightning packages into the same directory, then unzipping en-US last, removing lightning-l10n.js, and merging the chrome.manifest with the new localized entries. Its slightly different for the distribution-installed Lightning where there is a chrome.jar for packaging reasons.

The other thing you could do is run repacks just like the Mozilla infrastructure does to produce the localized packages yourself. Example logs for a set of repacks is at [5]. This doesn't get you a multi-locale package, but it does get you repacks from source instead of downloading files. To do that you need to have the set of l10n changesets and pull all the localization repositories. It may be more work than its worth.


[1] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/38.0.1/source/
[2] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/38.0.1/linux-i686/
[3] http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/4.0.0.1-candidates/
[4] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/38.0.1/
[5] http://ftp.mozilla.org/pub/mozilla.org/thunderbird/candidates/38.0.1-candidates/build1/logs/release-comm-esr38-linux_repack_7-bm72-build1-build1.txt.gz
Yes, I was referring to thunderbird-38.0.1.source.tar.bz2.

We use the above to build a main "thunderbird" package and then also have several "thunderbird-i18n-<locale>" packages, each providing the respective langpack from [1]. (Basically repackaging those .xpi files.)

Based on what you wrote, it sounds like my best bet would be to extract the locales from the localized Lightning xpis. If that is the case, it might be preferable to rely on AMO for Lightning instead of trying to ship it as part of our thunderbird package in Arch.

Thank you for the follow up and the detailed information.

[1] https://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/38.0.1/linux-i686/xpi/
Sure thing, any time. If you ever have questions you can also email me or reach me on irc.mozilla.org #calendar under my nickname Fallen. Let me know what you decide, if you still think its worth uploading specific language pack xpis for Lightning I can see if its possible to integrate into the build process. If you want to go with Lightning on AMO then I'd suggest closing this bug.
Language pack xpis for Lightning would certainly be nice to have. I'm not sure how easy it is to implement on your side though. (If it is too complicated we can go with AMO instead.)
Never mind my last comment; I no longer intend to include Lightning in the Arch package for Thunderbird.

That said, I'm a bit worried about future Thunderbird releases where, I believe, Lightning is installed as a global extension instead of a distribution extension. If Lightning is to be tied to Thunderbird as its main distribution method (as opposed to AMO), then I feel Linux distros should try to package it as well. In such case, having language packs for Lightning would be great (matched to the version included with Thunderbird).
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Lightning will remain installed as a distribution extension, I don't think this will change any time soon. Globally installed extensions have a few con points that are a no-go for us, see https://calendar.etherpad.mozilla.org/thunderbird-integration for details on the decision process.

We are using AMO to support the process, and for other apps like Seamonkey that do not have Lightning bundled (yet). We would like Lightning to be bundled with Thunderbird on all platforms and distros, but in the end it's up to you.
You need to log in before you can comment on or make changes to this bug.