This needs to be done as long as there is a change in en-US.jar, US.jar, or en-{win,mac,unix}.jar.

run "flipLocale.sh oldstr newstr" at the parent directory of ns/ & mozilla/.

place in the same directory at flipLocaleVer.sh

If Mozilla has newer release after 1.0.1rc1 and there is string change, then we need to flip the localeVersion.

removing keyword. there are not going to be multiple releases (from mozilla) with different localeversion strings; we'll only need to update for 1.0.2, so this bug is not relevant until after the 1.0.1 source release is done (tao already landed sufficient changes for 1.0.1) I'm changing the summary to reflect what i will actually be working on.

from 154840: leaf: would it be possible to duplicate what we did with the buildId? During the build process, we create a separate build.dtd which contains a single buildId.label entity and has a makefile dependency upon $(DEPTH)/config/build_number. Then the chrome files that need the buildId just reference &buildId.label. I'll start on this; version.dtd is my target name.

My taking is not to introduce new file or even resource id. IMHO, why not using the language.version in global/brand.dtd? How about the rev. number in the u-a string?

tao, leaf: what's the status on this? We often saw problems with localeVersion updates in the last builds, we had no update for 1.3a, and I had to do another patch for 1.3b (see bug 185698). It would be really great if we could set this at build time, ideally based on brand.dtd/region.dtd (in xpfe/global), which already have those versions (for language and content pack)

My L10n problems list in http://eu.mozdev.org/Brussels2003/talks/kairo/l10ntalk_10.html mentions this as an important problem, and I just filed bug 194441 for the 1.3 final update. Please get this fixed soon! The sooner the better!

Hi leaf, I had to leave Netscape before the reorg and I'm not sure how much time I will have to work on this issue. Have you been in touch with Tao? Is he still working on L10n issues?

Leaf, what is the prospect of having this done before the next milestone (in ns tree as well)? Thanks.

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

leaf is busy, reassigning to kysmith.

Hi, Kyle: Our locale files, langenus.xpi, etc., and XUL chrome files both contain version information and they need to match so Mozilla/Netscape client know how to handle chrome versioning properly. Most of those version numbers are stored contents.rdf; with a few of them in *.dtd. properties, etc. The scripts I attached there will auto scan those files and replace the version number with proper version numbers. You can run them on top of mozilla/ and ns/ to replace the version numbers. After that, produce a patch and then attach them to the bug reports for future reference. You need to borwse through the patch to ensure the script run properly.

Are we going with buildid or milestone.txt version? I tried autoversioning these earlier, and broke my test builds, probably because something was depending on these files before I autoversioned them, or they were being built in the wrong place (objdir instead of srcdir). If you want to autoversion them like I did with other .tmpl files, then we need to find what is dependent on these files. Not quite sure what leaf was planning on though; replace the version number with buildid?

P3P's localeversion is still 1.3b on nightly latest(25-Mar-2003 01:53 ). Is this correct ? Please check it !!

matsuba: Thanks, filed as bug 199121

Thanks, Mr. Kaiser. It's another bug. P3P's contents.rdf is not beginnig of <?xml version="1.0"?> Is this correct, too ?

engineer gone, wontfix. if you want it, reopen the bug and reassign it to yourself.

This _IS_ an existing bug which which involves a hell of contents.rdf updates for every release build we do. I'll reopen this one or open new ones for fixing it as long as I'm working on any Mozilla l10n-related project and the real bug is unfixed.

You may want to adopt the makefile-based approach used in bug 150900 to fix this. Gerv

Gerv: Thanks for that, I hope to come around to look into this. It look like a promising approach to that problem!

I have a working patch for this in my tree, and it looks like it just built OK here. I just have to use my cvs write account now to do lots of cvs remove and cvs add locally, so that I can perform a correct cvs diff here... Man, I'd love to be able to create a patch without performing commands that need cvs write access...

OK, I'll attach two diffs here: Number One is the part of the patch that has the real work I'm doing: Adding the files containing localeVersion strings to allmakefiles.sh and mailnews/makefiles and changing mailnews/mapi/resources/content/jar.mn so that it doesn't fail compiling (it complained about the now missing contents.rdf file). Number Two will also have all the moving of the files to .in version, with the localeVersion replaced with @MOZILLA_VERSION@ - this full patch will follow soon.

And here's Number Two, the full patch with all added and removed files

--> me

Comment on attachment 132938 [details] [diff] [review] patch v1: full patch > venkman ) MAKEFILES_extensions="$MAKEFILES_extensions > extensions/venkman/Makefile > extensions/venkman/resources/Makefile" >+ extensions/venkman/resources/content/contents.rdf >+ extensions/venkman/resources/locale/en-US/contents.rdf You need to put the " after the last .rdf file listing, or MAKEFILES_extensions will not include those two rdf files, which busts the build in venkman. Otherwise, nicely done.

Hrm. There seems to be some issue with dependencies (updating milestone.txt doesn't re-create the generated files).

Comment on attachment 132938 [details] [diff] [review] patch v1: full patch my last comment shouldn't be taken as a rejection, this should go in as is, and we can fix the dependency problem after the fact. This will fix the bulk of the issues (release build and candidates not having their localeVersion correct).

Comment on attachment 132938 [details] [diff] [review] patch v1: full patch leaf, thanks. I already had noticed that there was a problem with venkman but didn't relalize that simple wrong " :) Fixed in my local tree. I'll provide patches for firebird and thunderbird in separate bugs as soon as this patch is in the tree. I have a list of contents.rdf files in toolkit/, browser/ and mail/ which may profit from this way of doing things as well.

Comment on attachment 132938 [details] [diff] [review] patch v1: full patch sr=bzbarsky

OK, I just did the checkin for this patch... The following files still have hardcoded localeVersion strings currently: mail/base/content/contents.rdf mail/extensions/offline/content/contents.rdf mail/extensions/offline/locale/contents.rdf toolkit/content/contents-region.rdf toolkit/content/contents-platform.rdf toolkit/content/contents.rdf toolkit/components/passwordmgr/resources/content/contents.rdf toolkit/components/passwordmgr/resources/locale/contents.rdf toolkit/mozapps/contents-content.rdf toolkit/mozapps/contents-locale.rdf toolkit/locale/contents-region.rdf toolkit/locale/contents-platform.rdf toolkit/locale/contents.rdf extensions/editor/cascades/resources/locale/en-US/contents.rdf browser/base/content/contents.rdf browser/base/locale/win/contents-platform.rdf browser/base/locale/unix/contents-platform.rdf browser/base/locale/contents-region.rdf browser/base/locale/contents.rdf browser/components/security/content/contents.rdf browser/components/security/locale/contents.rdf We probably should handle that in a seperate bug (or seperate bugs).

Robert, I checked in this for mozilla/mail already (see Bug #) and I just attached a patch for mozilla/toolkit to bug #224514. Now we just need someone to do mozilla/browser.

mscott: Thanks, browser/ is up to FB people, but I'll point them to your patches to see how it works. And I'll probably do another conversion of Seamonkey to use that approach as well, as it's much nicer and cleaner than the other one ;-)

we also need to do mozilla/calendar, see bug #227694

Bug 232011 is about the right way to do this with the XUL preprocessor, as I already stated here in comment #33.