User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 SeaMonkey/2.42 Build ID: 20160130134426 Steps to reproduce: I downloaded the lates German Seamonkey from https://archive.mozilla.org/pub/seamonkey/releases/2.39/win32/de/ and installed it. Then I created a fresh profile and tried Chatzilla. Actual results: The Chatzilla dialogs were all in English instead of German. In the addon manager and on disk the Chatzilla de language pack was missing under Sprachen and needed to be downloaded from AMO. This also happens with the 2.40 release candidate from here: https://archive.mozilla.org/pub/seamonkey/candidates/2.40-candidates/build4/unsigned/win32/de/ Expected results: The Chatzilla language pack should have been available right after installation.

Reproducible! 1. Download German SeaMonkey from <http://www.seamonkey-project.org/releases/>: <https://download.mozilla.org/?product=seamonkey-2.39&os=win&lang=de 2. Quit SeaMonkey 3. Unzip saved installer 4. Launch seamonkey.exe in unzipped folder core with parameter "-ProfileManager" (console or batch file) » Profile Manager will launch 5. Create new profile and use it for launch » Browser will open, German UI 6. Open ChatZilla from Status bar » CZ will open, English UI

Some more test showed: a) visible root of the problem seems to be that proceeding as per steps 1 and following creates a folder <....\core\distribution\extensions\> what does NOT contain a "langpack-<language>@chatzilla.mozilla.org.xpi" a1) DE SeaMonkey 2.26.1 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 Build 20140612174402 (Classic Theme) on German WIN7 64bit does NOT contain such a language pack, and CZ has English UI :-( a2) DE SeaMonkey 2.16 CONTAINS such a language pack, and CZ has German UI :-) So the core of the problem might have appeared somewhere between 2.5 and 2.26 b) This missing "langpack-<language>@chatzilla.mozilla.org.xpi" problem also is reproducible for es-ES, so probably this is a general problem of localized builds c) Strange: 2.16 es-ES does contain the chatzilla language pack, but that will not work, CZ shows up in English. Probably different bug, I will check that later. I will test Linux later

Might have something to do with Bug 1231349 but this one is reported against 2.42. The language pack not working might be because of the too low version numbers I reported in Bug 1240304.

I simply downloaded CZ German Language Pack "chatzilla_deutsch_de_language_pack-0.9.92-sm+fx.xpi", renamed it to "langpack-de@chatzilla.mozilla.org.xpi" and added file to \core\distribution\extensions\, but that does not work for profile created in step 5.

IMHO, that bug is mainly because the whole concept of shipped add-ons doesn't work right, and add-on language packs aren't something the platform devs care about at all, AFAIK.

It might be interesting to see, if this also applies to 2.41 - builds from the c-r branch can be found here: https://l10n.mozilla-community.org/~akalla/unofficial/seamonkey/nightly/ Unfortunately, because of Bug 1231349, localized builds are busted with 2.42+, so no way to test there...

(In reply to Adrian Kalla [:adriank] from comment #6) REPRODUCIBLE with German SeaMonkey 2.41a1 Mozilla/5.0 ( Windows NT 6.1; WOW64; rv:44.0 from akalla download area) Gecko/20100101 Firefox/ 44.0 Build 20160201082047, (Classic Theme) on German WIN7 64bit: - Chatzilla is in English in any newly created user profile - No German Chatzilla Language Pack in program installation folder

Doesn't really surprise me. Until at least Bug 1210791 is fixed I doubt that the locale language pack will build. FRG

Adrian, do you have by chance a recent log of an l10n build including the make installer step available and can send it to me. This works for me doing a local l10n de build and I do not see where the error could be.

(In reply to Frank-Rainer Grahl from comment #10) > Adrian, > > do you have by chance a recent log of an l10n build including the make > installer step available and can send it to me. This works for me doing a > local l10n de build and I do not see where the error could be. Posting it here. This is the full build log (including L10n steps) of what can be found here: https://l10n.mozilla-community.org/~akalla/unofficial/seamonkey/nightly/latest-comm-aurora-linux32/

(In reply to Rainer Bielefeld from comment #2) > Some more test showed: > > a) visible root of the problem seems to be that proceeding as per steps 1 and > following creates a folder <....\core\distribution\extensions\> what does > NOT contain a "langpack-<language>@chatzilla.mozilla.org.xpi" langpack-<language>@chatzilla.mozilla.org.xpi is in extensions\ as well as modern@themes.mozilla.org.xpi and {972ce4c6-72e08-4474-a285-3208198ce6fd}.xpi Just wanna mention this while figuring out bug 1231394. Just not asking anyone in particular, but why is there a 'distribution/extensions' AND 'extensions/'? Just way more ways to confuse the heck out of localizations.

(In reply to Edmund Wong (:ewong) from comment #12) > langpack-<language>@chatzilla.mozilla.org.xpi is in extensions\ as well > as modern@themes.mozilla.org.xpi and > {972ce4c6-72e08-4474-a285-3208198ce6fd}.xpi > > Just wanna mention this while figuring out bug 1231394. Yes, exactly - this bug is a packaging-bug, as that XPI should land in the package at the end, but does not... > Just not asking anyone in particular, but why is there a > 'distribution/extensions' AND 'extensions/'? Just way more ways to > confuse the heck out of localizations. The extensions from one of the directories get updated just by updating SeaMonkey. The extensions from the other will not get updated this way and will search only AMO for updates. Not sure anymore which directory is which, though...

Ian posted a likely solution here: https://bugzilla.mozilla.org/show_bug.cgi?id=1231349#c26

(In reply to Adrian Kalla [:adriank] from comment #14) > Ian posted a likely solution here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1231349#c26 Can I just say it was frg that inspired that (I think), more testing to be done though.

[Approval Request Comment] Regression caused by (bug #): User impact if declined: No langpacks for CZ in supported locales Testing completed (on m-c, etc.): locally Risk to taking this patch (and alternatives if risky): None String changes made by this patch: None

Comment on attachment 8802592 [details] [diff] [review] Add MOZ_PKG_EXTRAL10N entry for CZ langpacks This is inside the ifdef MOZ_CALENDAR block and needs to be moved out or it would fail in case Lightning is disabled. Not that relevant for SeaMonkey release build but... The cz langugage pack is only made for the locales in the file \irc\locales\all-locales. As you pointed out in bug 1244467: 'Not sure happens when we build for a locale that isn't localised for Chatzilla...' Me neither. Might need a check if the patch exists like in: > ifneq ("$(wildcard $(PATH_TO_FILE))","") > FILE_EXISTS = 1 > else > FILE_EXISTS = 0 > endif

MOZ_PKG_EXTRAL10N does not seem to care if the add directory does not exist. [Approval Request Comment] Regression caused by (bug #): User impact if declined: CZ langpack doesn't get added if it exists Testing completed (on m-c, etc.): locally on locales with CZ langpacks and without langpacks Risk to taking this patch (and alternatives if risky): None String changes made by this patch: None

(In reply to Edmund Wong (:ewong) from comment #12) > (In reply to Rainer Bielefeld from comment #2) > > Some more test showed: > > > > a) visible root of the problem seems to be that proceeding as per steps 1 and > > following creates a folder <....\core\distribution\extensions\> what does > > NOT contain a "langpack-<language>@chatzilla.mozilla.org.xpi" > > langpack-<language>@chatzilla.mozilla.org.xpi is in extensions\ as well > as modern@themes.mozilla.org.xpi and > {972ce4c6-72e08-4474-a285-3208198ce6fd}.xpi > > Just wanna mention this while figuring out bug 1231394. > > Just not asking anyone in particular, but why is there a > 'distribution/extensions' AND 'extensions/'? Just way more ways to > confuse the heck out of localizations. Everything used to be in INSTALLDIR/extensions/, with no INSTALLDIR/distribution/extensions, and they were run from the installdir without being copied to your profile; but then, if you manually updated the extension, the update got installed in PROFILE/extensions and that version took precedence over the one under the installdir. If later you updated SeaMonkey to a version constaining a newer ChatZilla, the stale one in your profile still took precedence. Later, all built-in extensions were moved to INSTALLDIR/distribution/extensions, leaving only the themes (and now Lightning but that was not distributed with SeaMonkey then) in INSTALLDIR/extensions. With this newer system, SeaMonkey compares the extensions' versions in distribution/extensions with that in your profile whenever the SeaMonkey version differs from the one used on the previous run with the same profile. If the version in distribution/extensions is newer (or if there is no extension with the same id in the profile), it is copied to PROFILE/extensions, but (IIUC) always in xpi format so this method doesn't work for Lightning which needs to be unzipped to be used.

Comment on attachment 8802679 [details] [diff] [review] Add MOZ_PKG_EXTRAL10N entry for CZ langpackssm_cz_extra.diff v0.2 Looks good to me now. f+

(In reply to Tony Mechelynck [:tonymec] from comment #19) > (In reply to Edmund Wong (:ewong) from comment #12) > > (In reply to Rainer Bielefeld from comment #2) > > > Some more test showed: > > > > > > a) visible root of the problem seems to be that proceeding as per steps 1 and > > > following creates a folder <....\core\distribution\extensions\> what does > > > NOT contain a "langpack-<language>@chatzilla.mozilla.org.xpi" > > > > langpack-<language>@chatzilla.mozilla.org.xpi is in extensions\ as well > > as modern@themes.mozilla.org.xpi and > > {972ce4c6-72e08-4474-a285-3208198ce6fd}.xpi > > > > Just wanna mention this while figuring out bug 1231394. > > > > Just not asking anyone in particular, but why is there a > > 'distribution/extensions' AND 'extensions/'? Just way more ways to > > confuse the heck out of localizations. > > Everything used to be in INSTALLDIR/extensions/, with no > INSTALLDIR/distribution/extensions, and they were run from the installdir > without being copied to your profile; but then, if you manually updated the > extension, the update got installed in PROFILE/extensions and that version > took precedence over the one under the installdir. If later you updated > SeaMonkey to a version constaining a newer ChatZilla, the stale one in your > profile still took precedence. > > Later, all built-in extensions were moved to > INSTALLDIR/distribution/extensions, leaving only the themes (and now > Lightning but that was not distributed with SeaMonkey then) in > INSTALLDIR/extensions. With this newer system, SeaMonkey compares the > extensions' versions in distribution/extensions with that in your profile > whenever the SeaMonkey version differs from the one used on the previous run > with the same profile. If the version in distribution/extensions is newer > (or if there is no extension with the same id in the profile), it is copied > to PROFILE/extensions, but (IIUC) always in xpi format so this method > doesn't work for Lightning which needs to be unzipped to be used. This whole add-on situation is nuts, and with the added localization issues, it's *crazy* to say the least. What/who determines which add-on/extension/whateverit'scallednow should be zipped up and which should be flat?

https://hg.mozilla.org/comm-central/rev/67de54418efbb0929b25c68525c8a67ed621bda2 https://hg.mozilla.org/releases/comm-aurora/rev/3007f6dbd2a120bda1f8a4a1c9b1c531fa96f39e https://hg.mozilla.org/releases/comm-beta/rev/19ca4c84607f8a4b7343c5c6a06b762d9ab2d60c c-r SEA_COMM490_20160927_RELBRANCH https://hg.mozilla.org/releases/comm-release/rev/ed282105babbd19b1d899d5a27500d8ade5680e4 c-r tip https://hg.mozilla.org/releases/comm-release/rev/6db021caa108b57839c6f163cfa0de38f5eaaf0f