243167 - Platform-specific en-mac/unix/win.jar localization files not all included for each distribution

Status: VERIFIED FIXED

(Thunderbird :: Build Config, defect)

Description

[Mark Tyndall]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.6) Gecko/20040113
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/0.6/

The TB 0.6 release for windows only contains the en-win.jar, but not en-mac and
en-unix.  Similarly, the linux release contains only en-unix.jar.  I presume the
Mac release is the same, but I cannot extract files from the .dmg archive.

I saw bug 214663 but that seems to be a meta-bug for general localisation
problems. (Perhaps this should depend on it.)

Without easy access to all three files, localisers are unable to release
language packs that will work on all platforms.


Reproducible: Always
Steps to Reproduce:
1. Download ThunderbirdSetup-0.6.exe (7.9 MB). Find only en-win.jar
2. Download thunderbird-0.6-i686-linux-gtk2+xft.tar.gz (9.7 MB). Find only
en-unix.jar
3. Download thunderbird-0.6-macosx.dmg.gz (10.6 MB). Find lack of software
available to access dmg archives.

Actual Results:  
Find I am unable to produce a language pack which is cross-platform.


Expected Results:  
en-mac/unix/win.jar should all be contained in each distribution; or,
a separate, platform-neutral langenus.xpi, containing all three
platform-specific files plus everything else required to run Thunderbird in US
English should be produced and offered separately for download.


Do localizers count as Mozilla developers?  If you think not, then you'll also
think my rating of the severity is OTT.

Comment 1

[Carlos Rodrigues]

It seems that localizing is getting more difficult instead of easier. If these
files are not to be included in for all platforms, at least there could be a
package somewhere where we could get all that is needed to localize
Mozilla/Firefox/Thunderbird.

Comment 2

[Tim Maks van den Broek [:mad_maks]]

Attachment: the needed .jar files

this isnot a solution to the problem but it helps :-)

Comment 3

[Tim Maks van den Broek [:mad_maks]]

Attachment: the needed .jar files

Comment 4

[Tim Maks van den Broek [:mad_maks]]

Attachment: the needed .jar files

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Is this still a valid blocker bug for TB? There has been no indication of any
progress for almost 3 months.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

oops just saw the status whiteboard. sorry!

Comment 7

[chris hofmann]

this has to happen after PR

Comment 8

[David Fraser]

Surely the change to the Makefiles / build scripts could be made before PR? Does
this need to wait till then?

Comment 9

[Benjamin Smedberg]

*** Bug 252899 has been marked as a duplicate of this bug. ***

Comment 10

[Benjamin Smedberg]

The platform-specific files are no more, good riddance.

Comment 11

[Scott MacGregor]

Benjamin, if this is true then don't we need to fix up the installed-chrome.txt
file used by the re-packaged installer bits to not look for en-win.jar,
en-unix.jar, etc?

http://lxr.mozilla.org/aviarybranch/source/mail/config/installed-chrome.txt#54

Otherwise tomorrow's branch release builds are going to have problems because
they'll be looking for these platform files. I"m also seeing weird problems with
my debug build where the non packaged bits are also still looking for en-win.jar
as the build process is still registering that chrome package in the auto
generated installed-chrome.txt file. 

Also, is this true for the trunk as well? We should leave this bug open if it's
not true on the trunk for now. 

Comment 12

[Scott MacGregor]

ooops lxr just wasn't updated to show that the static installed-chrome.txt file
no longer refers to en-win.jar, en-unix.jar, etc. My tree doesn't have those.
Sorry for the false question. 

Comment 13

[sairuh (rarely reading bugmail)]

rs vrfy backend fix.