Current build system can provide incomplete locale jars

RESOLVED FIXED in Future

Status

()

P4
minor
RESOLVED FIXED
17 years ago
16 years ago

People

(Reporter: kairo, Assigned: jbetak)

Tracking

({intl})

Trunk
Future
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
As bug 118140 shows, we currently can fail badly building up locale .jar files
in the build system. Depending on the platform, or on configure switches, we
might add different files to en-US.jar, en-[platform].jar, and US.jar - what is
IMHO quite bad.

I think that _always_ when we build one of those files, it should look the same,
i.e. it should contain exactly the same directories with the same files.

We really should tweak the build system in a way that we get this. In that case,
a locale .jar from the same source will always have exactly the same contents,
regardless of the platform or the used configure switches. (e.g. en-win.jar will
always include mapi files, even if someone might turn mapi off in his build)

Perhaps we can add a configure switch to this tweaked build system to turn of
unneeded locale .jar files (like en-unix.jar and en-mac.jar on a windows build)
and let this turned on by default (so the nightlies and milestone builds will
deliver the files to our L10n people in the spirit of bug 72496).

This might be too big for a 1.0 change, but I think it should happen quite soon
afterwards as L10n will become much easier with that...

Updated

17 years ago
Keywords: intl
QA Contact: ruixu → jimmyu

Comment 1

17 years ago
Build issue. -> granrose.
Assignee: rchen → granrose
(Reporter)

Comment 2

17 years ago
In n.p.m.l10n, I was asked for examples of the current problems, here those I
found on a fast look through my files:

1) As bug 118140 states, platformCommunicatorOverlay.dtd is missing from
en-unix.jar and en-mac.jar on Windows, from en-win.jar an en-mac.jar on Unix,
and from en-win.jar and en-unix.jar on Mac.

2) mozldap directory is missing from en-US.jar if you do a build without LDAP
support, accessible.properties is missing from en-win.jar if you build without
enabling accessible (even on a linux build).

3) a view of en-win.jar in 0.9.9 win32/Linux binary builds from mozilla.org
shows the following:
messenger-mapi dierectory is missing in en-win.jar on Linux
nsWindowsHooks.properties is missing in en-win.jar on Linux
platformCommunicatorOverlay.dtd -- see 1)

Those are a few examples, I'm sure you will find more when you're looking at all
files on all platforms.

I don't have to explain that this can result in untranslated strings and/or XML
errors for users of "incomplete" packs (e.g. from localisation packs) in their
build. We don't see any errors if users get additional files they don't use, though.

Updated

17 years ago
Severity: normal → minor
Priority: -- → P4
Target Milestone: --- → Future

Comment 3

17 years ago
Actually this bug falls under my "jurisdiction".  Reassigning to dbragg
Assignee: granrose → dbragg

Comment 4

17 years ago
new owner ->tao
Assignee: dbragg → tao
taking this...
Assignee: tao → jbetak
this should now be resolved, see bug 144551.

Although we still build all platform-specific jar files, they should now be
identically, regardless of the platform they were built on. I've tweaked the
build scripts in bug 144551 to prevent foreign platform files to be registered
as chrome providers. Toady's verification builds look good.

Please protest if you think this still needs some attention.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.