326956 - Standarize XPI/JAR files internal structure and whatever is necessary for enhancing good localization

Status: RESOLVED WONTFIX

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Oscar Manuel Gómez Senovilla]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.11) Gecko/20050729
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.11) Gecko/20050729

Long time ago, I filed bug 224230 just for calendar, but it extends to many extensions today. Though the toolkit (or whatever the component is) allows any file structure as long as it matches the defined in the install.* file, extensions doing their own will without a respected standard (like there used to be before mozilla 1.7) make translators' life (like me) difficult, because at least I have some automated scripts that get broken when I find any of these extensions not following the traditional standard tree structure. This breaks in the contents of the language jar file in the chrome directory.

My suggestion is to try to "force" developers (mainly by encouraging them) to use the locale/en-US/<name>/ structure for the files instead of the growing "fashion" of using just locale/en-US/ instead.

Another way I can think of getting close to this is having something like a "strict" check mode that extension developers can use to check the "consistency" of their installers. This shouldn't prevent installation in case of errors, unless explicitily indicated.

Another issue (related) is that some extensions don't have a chrome/file.jar file, just the plain and uncompressed translations, apparently thinking (no matter if right or wrong) that it's "easier" to have them that way. I think the best (at least from an organization point of view) having every language under locale/ tree in an specific jar file in the chrome directory, *including* en-US, that might be "embedded" with code files (i.e. all language files have identical structure). The target (not sure if needs something else) is to allow the installation process to isolate the wanted language without installing any of the unwanted included languages.

May this bug be a placeholder for all issues related to extension localization?

Reproducible: Always

Comment 1

[Philip Chee]

BabelZilla has a Web Translation System that automates the unpacking of extension locales.

<http://www.babelzilla.org/index.php?option=com_wts&Itemid=88>
"WTS (Web Translation System) is the system used on BabelZilla to allow online translation and manage upload/download of extensions & languages files."

"This system is based on a script elaborated by WizKid!"

You might like to look at this script.

Comment 2

[Nickolay_Ponomarev]

(You're started discussion in two newsgroups and bugzilla without setting a followup-to; I suggest that the discussion continues in mozilla.dev.l10n - see URL)

Comment 3

[Rod Whiteley]

It looks like this is a request for Mozilla to fix the reporter's broken scripts.

A script can either read chrome.manifest or go looking for contents.rdf files to determine where to find locale files, regardless of the structure.

Comment 4

[Benjamin Smedberg]

I don't think it is possible or reasonable to enforce these arbitrary standards on extension authors, or even on the tree.