Ben said in bug 260058 comment 17: > Also, it looks like you're packaging your locale files into help.jar, not > en-US.jar, which makes it more difficult to localize, and difficult to update > the language pack a browser is running with or the help engine independently of > each other - ideally help.jar would contain just the UI/engine and thus the jar > file would be the same for *all* languages.

Will do. I'm currently working on bug 260058, so merging the changes together shouldn't be difficult. For en-US I'm sure I can handle it. For the other languages, I'll take a look, but I might need to push that part over to bsmedberg, depending on how opaque the l10n build process is.

Scuttlebutt is that localizers would like this...never hurts to have them on our good side. I've tested on Linux (both running from build location and from installer), and everything seems hunky-dory. -->blocking-aviary1.0?

This is WONTFIX for 1.0, we have decided that all localizations of firefox will contain the en-US help files as a backup. On trunk, I'm open to suggestions, ccing the localizers for input.

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

Now that l10n is stable on trunk, this is probably worth doing for 1.1.

1.5 or later

Fixed in bug 289555. Locale files are now in AB_CD.jar, and the viewer itself is packaged in toolkit.jar.