Closed Bug 157806 Opened 22 years ago Closed 20 years ago

Consolidate contents.rdf files into one

Categories

(SeaMonkey :: UI Design, defect, P1)

Tracking

(Not tracked)

RESOLVED WONTFIX
mozilla1.3alpha

People

(Reporter: rchen, Assigned: ftang)

References

Details

(Whiteboard: [browser])

In en-Us.jar and US.jar, there is one content.rdf in each folder. Can we
consolidate them into one global file for each jar? 

Or can we move out the locale info into one global locale file?  Since the
locale info is the same in the jar files, we can consolidate them into one file.
It will  save time and reduce the cost for localization.
Severity: normal → major
Target Milestone: --- → mozilla1.1beta
Blocks: 157673
At a glance, I'm going to say: it's possible but we don't want to do that as we
don't support ifdefs in jar files.  For embedding and other custom builds, we do
not want to pull in *every* contents.rdf file or every locale file.  However, I
don't play with chrome files on a daily basis so I'm bouncing this over to
XPApps for their opinion.
Assignee: seawood → sgehani
Component: Build Config → XP Apps
QA Contact: granrose → paw
Target Milestone: mozilla1.1beta → ---
no, that's now how this works. we need a contents.rdf for each chrome package.
the fact that there are multiple packages per JAR is irrelevant... sorry!

it does seem like we could combine en-US.jar and US.jar into one .jar though..
I'm not sure how that would affect l10n though. cc'ing tao for advice.
This chrome registry manifest changed back and forth from release to release  :-)
It was centralized once and then localized...

Anyway, IMHO, what we should explore here is how to consolidate all chrome
registry files for all chrome providers instead of just locale's. We can even
consolidate all chrome providers into a single one per jar like the bug suggested.

It should be feasible since chrome registry is nothing more than a RDF
datasource which can be aggregated. We can also take this opportunity to
simplify how chrome registry work to speed up the chrome registration process.

We should get input from David Hyatt, though. Don't know his new bugzilla 
account, though. (I hesitate to create one for him since he might have other
prefernece...)
Blocks: 62177
If we can't consolidate contents.rdf files into one, can we at least centralize
the locale info into one place?  The locale info is the same across the language
jar.  It doesn't make sense to spread it out to each chrome package, right? Do
we have a language pack with English navigator, Japanese messenger and France
composer? 

Spreading it out increases the cost for localization.  There are 20 content.rdf
 in en-us.jar and 7 in us.jar. It is no longer a one time job as we did in
Netscape 6 because currently chrome:localeVersion is changing and it needs to be
updated.  

Summary: Consolidate content.rdf files into one → Consolidate contents.rdf files into one
the original theory allowed for end users to mix and match locales and skins on 
a per package basis. as such the flexibility is required.

you could redesign the build system so that the rdf files are generated 
(by merging a header and body) instead of staticly containing lots of duplicated 
information.
Hyatt, any thoughts?
Well, two months have passed.  We need to have progress on this.

leaf,

Can you help out consolidating these duplicated "locale, localeVersion" in
contents.rdf?  Please provide your input. Thanks.
Keywords: nsbeta1
Marking nsbeta1- per the navigator triage team
Keywords: nsbeta1nsbeta1-
Samir, what's the status on this? It's on L10n's top wish list - it would be
great to get this into Buffy. Please feel free to reassign this to me, if you
want me to drive it...
Taking this per discussion with leaf, raising priority to P1. 
Assignee: sgehani → jbetak
Keywords: nsbeta1-
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.3alpha
Does P1 mean it will get a nsbeta1+ on it? Thanks for raising the priority. If
yes, it needs to go into the keywords. It means a lot to the l10n team to get
this fixed. thanks
adding nsbeta1 keyword per mcarlson, I'll try to have this ready to go within a
week or two :-)
Status: NEW → ASSIGNED
Keywords: nsbeta1
adding nsbeta1+
Keywords: nsbeta1nsbeta1+
QA Contact: paw → marina
Whiteboard: [browser]
i18n triage team: nsbeta1- for original bug.

Leaf, is there work being done on the release end to automate localeVersion updates?
Keywords: nsbeta1+nsbeta1-
Frank, can you take over this bug? and renominate it? ->ftang.
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.