258274 - localeVersion field in contents.rdf files is empty

Status: RESOLVED FIXED

(Mozilla Localizations Graveyard :: MozillaTranslator, defect)

Description

[Tsahi Asher]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:1.7.2) Gecko/20040803
Build Identifier: 5.03

if you export just the jar file, the contents.rdf files don't include the
LocaleVersion info. it writes

chrome:localeVersion=""

in both places in the file.

it's possible that this happenes when you export an XPI too, i didn't check.

Reproducible: Always
Steps to Reproduce:
1.select export > jar file from the top menu
2.select location and other details
3.click OK
Actual Results:  
the contents.rdf files in the exported jar have no localeVersion info

Expected Results:  
localeVersion should have the correct product version

Comment 1

[Henrik Lynggaard Hansen]

A few questions:

* Suite or Firefox ?
* Original strings read from standard jar or the new CVS import ?

Comment 2

[Tsahi Asher]

(In reply to comment #1)
> A few questions:
> 
> * Suite or Firefox ?

suite

> * Original strings read from standard jar or the new CVS import ?
> 
actually, i just put the glossary.zip of mt5.02 and the mt5.03 executable in a
folder, and started mt. in the xpi export window the version is present and correct.

Comment 3

[RickieES aka Ricardo Palomares]

Reassigning every MT bug to me.

Comment 4

[RickieES aka Ricardo Palomares]

I'm fairly ignorant about contents.rdf files. Does this really matter? I've searched a bit on MDC and I can't find anything really definitive (it seems that contents.rdf info has been dropped or not added in favour of manifest files).

It seems that current situation isn't really harmful, and I'm a bit afraid that adding the value to localeVersion could instead raise any problem. That's why I'd like to gather more opinions.

Comment 5

[Robert Kaiser]

localeVersion matching with the original value is very important for xpfe-based applications (Mozilla 1.x, SeaMonkey 1.x) - contents.rdf is completely unneeded though for toolkit-based apps (Firefox, Thunderbird, Sunbird, suiterunner)

Comment 6

[RickieES aka Ricardo Palomares]

(In reply to comment #4)
> 
> It seems that current situation isn't really harmful, and I'm a bit afraid
> that adding the value to localeVersion could instead raise any problem.
> That's why I'd like to gather more opinions.
> 

Well, I guess I already know why the current situation isn't harmful. :-) localeVersion _is_ filled. It seems that this is another bug solved by Henrik and/or Serhiy but not closed.


(In reply to comment #5)
> localeVersion matching with the original value is very important for
> xpfe-based applications (Mozilla 1.x, SeaMonkey 1.x) - contents.rdf is
> completely unneeded though for toolkit-based apps (Firefox, Thunderbird,
> Sunbird, suiterunner)


Even if localeVersion is not empty anymore, I would like to know where a contents.rdf should exist. For instance, inside en-US.jar there is a contents.rdf at "/locale/en-US/communicator/" but not at "/locale/en-US/communicator/bookmarks" (JARs made by MT follow this convention). Is there a rule that can be safely applied to know where to put a contents.rdf?

Comment 7

[Tsahi Asher]

(In reply to comment #6)
> (In reply to comment #4)
> > 
> > It seems that current situation isn't really harmful, and I'm a bit afraid
> > that adding the value to localeVersion could instead raise any problem.
> > That's why I'd like to gather more opinions.
> > 
> 
> Well, I guess I already know why the current situation isn't harmful. :-)
> localeVersion _is_ filled. It seems that this is another bug solved by Henrik
> and/or Serhiy but not closed.
> 
> 
have you checked *export JAR*?


> (In reply to comment #5)
> > localeVersion matching with the original value is very important for
> > xpfe-based applications (Mozilla 1.x, SeaMonkey 1.x) - contents.rdf is
> > completely unneeded though for toolkit-based apps (Firefox, Thunderbird,
> > Sunbird, suiterunner)
> 
> 
> Even if localeVersion is not empty anymore, I would like to know where a
> contents.rdf should exist. For instance, inside en-US.jar there is a
> contents.rdf at "/locale/en-US/communicator/" but not at
> "/locale/en-US/communicator/bookmarks" (JARs made by MT follow this
> convention). Is there a rule that can be safely applied to know where to put a
> contents.rdf?
> 

from expirience, i know contents.rdf should be only in top level folders of the components, i.e. in communicator, help, but not communicator/bookmarks or help/images.

Comment 8

[RickieES aka Ricardo Palomares]

(In reply to comment #7)
> > Well, I guess I already know why the current situation isn't harmful. :-)
> > localeVersion _is_ filled. It seems that this is another bug solved by
> > Henrik and/or Serhiy but not closed.
> > 
> have you checked *export JAR*?


Yes, both the JAR exported by Export -> JAR and the JARs inside the XPI created by Export -> XPI.


> > Even if localeVersion is not empty anymore, I would like to know where a
> > contents.rdf should exist. For instance, inside en-US.jar there is a
> > contents.rdf at "/locale/en-US/communicator/" but not at
> > "/locale/en-US/communicator/bookmarks" (JARs made by MT follow this
> > convention). Is there a rule that can be safely applied to know where to
> > put a contents.rdf?
> > 
> 
> from expirience, i know contents.rdf should be only in top level folders of
> the components, i.e. in communicator, help, but not communicator/bookmarks or
> help/images.


Yes, this is what is being done, but I was looking for something like an "official" reference.

So, I'll keep this bug open for a couple of days and then I'll close it.

Comment 9

[Robert Kaiser]

(In reply to comment #6)
> Well, I guess I already know why the current situation isn't harmful. :-)
> localeVersion _is_ filled. It seems that this is another bug solved by Henrik
> and/or Serhiy but not closed.

It's just not always the correct one, it's a randomly guessed one (esp. in my install where I have two branches in the same glossary), and unfortunately one can't set/change it manually any more.
 
> Even if localeVersion is not empty anymore, I would like to know where a
> contents.rdf should exist. For instance, inside en-US.jar there is a
> contents.rdf at "/locale/en-US/communicator/" but not at
> "/locale/en-US/communicator/bookmarks" (JARs made by MT follow this
> convention). Is there a rule that can be safely applied to know where to put a
> contents.rdf?

The safest rule is "where the original version puts one" (as that would also take into account those pieces of software that doesn't need it any more), a good guess is though "in every |/locale/en-US/<package>/| unless <package> end in |-platform|, where it's one level below (inside mac/unix/win dir)"

Comment 10

[RickieES aka Ricardo Palomares]

(In reply to comment #9)
> (In reply to comment #6)
> > Well, I guess I already know why the current situation isn't harmful. :-)
> > localeVersion _is_ filled. It seems that this is another bug solved by
> > Henrik and/or Serhiy but not closed.
> 
> It's just not always the correct one, it's a randomly guessed one (esp. in my
> install where I have two branches in the same glossary), and unfortunately one
> can't set/change it manually any more.


While I was working in the ZIP permissions bug, I've seen that the version is taken from the first product in the product table of the Write XPI dialog.

This makes me wonder: what if you have several products in the Glossary.zip and you select all of them to create an XPI but one of them has a different version than the others? I think I could gather the version values from every product with any checkbox ticked complain if any of the values diverge from the others. For example:

Product  Version  Neutral  Win    Unix     Mac   Region  Custom
---------------------------------------------------------------
SM 1.1   1.8.1      [ ]    [ ]     [ ]     [ ]     [ ]     [ ]
CZ 1.1   1.8.1      [ ]    [ ]     [ ]     [ ]     [ ]     [ ]
SM 1.5   1.9.a1     [ ]    [ ]     [ ]     [ ]     [ ]     [ ]
CZ 1.5   1.9.a1     [ ]    [ ]     [ ]     [ ]     [ ]     [ ]
CZ 0.9.8 0.9.8      [ ]    [ ]     [ ]     [ ]     [ ]     [ ]

In the previous table you could mix SM 1.1 only with CZ 1.1; SM 1.5 only with CZ 1.5; and CZ 0.9.8 would have to be selected always alone. Would this work for you?


> 
> > Even if localeVersion is not empty anymore, I would like to know where a
> > contents.rdf should exist. For instance, inside en-US.jar there is a
> > contents.rdf at "/locale/en-US/communicator/" but not at
> > "/locale/en-US/communicator/bookmarks" (JARs made by MT follow this
> > convention). Is there a rule that can be safely applied to know where to
> > put a contents.rdf?
> 
> The safest rule is "where the original version puts one" (as that would also
> take into account those pieces of software that doesn't need it any more)


Thank you for the info. This should be easy to get done.


> a
> good guess is though "in every |/locale/en-US/<package>/| unless <package> end
> in |-platform|, where it's one level below (inside mac/unix/win dir)"


Hum... this doesn't match current (SM 1.1beta) en-mac.jar, en-unix.jar and en-win.jar, as they don't have mac/unix/win dirs inside, and have contents.rdf following the general rule |/locale/en-US/<package>/|. en-US.jar doesn't have any |-platform| directory. Maybe you are thinking in SM 1.5 unified JAR structure? This probably shouldn't worry us too much, as SM 1.5 is expected to use source L10n, isn't it?

Comment 11

[Robert Kaiser]

(In reply to comment #10)

> In the previous table you could mix SM 1.1 only with CZ 1.1; SM 1.5 only with
> CZ 1.5; and CZ 0.9.8 would have to be selected always alone. Would this work
> for you?

I personally am only using the "Export JAR" dialog since MT XPIs were too broken for me a long time ago and then I just got used to exporting JARs and applying my conversion scripts :)

> Maybe you are thinking in SM 1.5 unified JAR
> structure? This probably shouldn't worry us too much, as SM 1.5 is expected to
> use source L10n, isn't it?

Gah, yes, right, I was thinking xpfe-based trunk, which will never see a release anyways...
The "where the original has one" approach is better anyways though.

Comment 12

[RickieES aka Ricardo Palomares]

(In reply to comment #11)
> (In reply to comment #10)
> 
> > In the previous table you could mix SM 1.1 only with CZ 1.1; SM 1.5 only
> > with CZ 1.5; and CZ 0.9.8 would have to be selected always alone. Would
> > this work for you?
> 
> I personally am only using the "Export JAR" dialog since MT XPIs were too
> broken for me a long time ago and then I just got used to exporting JARs and
> applying my conversion scripts :)


You know MT is using now your install.js and install.properties script, don't you? :-)

BTW, nice reminder, I was considering the Write XPI dialog only.

Comment 13

[RickieES aka Ricardo Palomares]

(In reply to comment #11)
> 
> Gah, yes, right, I was thinking xpfe-based trunk, which will never see a
> release anyways...
> The "where the original has one" approach is better anyways though.
 

Since current code is working right and we will stop using contents.rdf for SM 1.5, do you think it is worthy to change the current code? It's not actually a matter of complexity (I think), but of memory consumption. I would have to add another property to Component class to flag components (directories) with a contents.rdf inside them and save this info on Glossary.zip.

As I plan to implement other features more memory-demanding, wasting memory space (even if it is a small amount) on info not currently needed is something I'd rather avoid if possible.

Comment 14

[Tsahi Asher]

i must note that i never had a problem with exporting XPIs. if you have several products with differnt versions, you can click the line of the product you want to export, and MT will use that product's version. i don't think MT is built to create a single XPI with more than one product in them.

Comment 15

[Robert Kaiser]

Ricardo:
SeaMonkey 1.0.x will still be with us for a few months, 1.1.x for a year or a bit more, so contents.rdf isn't dead yet - but I think current behaviour is known well enough by current MT users so leaving the code that currently determines where to write contents.rdf files should be enough for those. Maybe there should be some either automatic (fit to read jar files) or manual way to turn on/off contents.rdf completely in exported XPI/JAR files (for XPIs that can be coupled with writing install.js or install.rdf).
Making the field writable that displays the written localeVersion in the JAR export dialog (does XPI export have this as well?) would help those who have different versions in their glossary though.

Comment 16

[RickieES aka Ricardo Palomares]

Changes have been committed to CVS now. The code compiles, but not all bugs in
which I'm working are completely covered by current code status, and no serious
testing has been done yet.

The solution I've finally gone with is to keep localeVersion field disabled, but update it so it matches the lang.version. For JAR files it is an easy solution; for XPIs, it is a bit more complex, and it basically reduces to prevent the user from choosing elements from two products with different version numbers.

I hope to stabilize the code enough to provide preliminar JAR files for you to see it working.

Comment 17

[RickieES aka Ricardo Palomares]

We have finished the new features and bug fixing process for forthcoming
MozillaTranslator version, so I'm closing this bug with the current solution committed to CVS.