Closed Bug 161886 Opened 22 years ago Closed 18 years ago

[Enh] remove 'version' field from 'export' dialogs

Categories

(Mozilla Localizations Graveyard :: MozillaTranslator, enhancement)

x86
All
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: T.C.Witte, Assigned: rpmdisguise-nave)

Details

Hello Henrik
MozillaTranslator does not really need the 'version' field in 'Export JAR' and
'Export XPI' anymore, because Mozilla has strings that state the version number
of the component (since at least 1.0).
It would be user friendly and reduce the risk of making mistakes, when that
would be removed, and MozillaTranslator would use the following field for its
version number:

regional: global-region/region.dtd:content.version
neutral: global/brand.dtd:lang.version

(platform specific doesn't seem to have it, but could use the version number
from 'neutral')

Of course, this doesn't need any priority.

With regards,
Taco
Summary: remove 'version' field from 'export' dialogs → [Enh] remove 'version' field from 'export' dialogs
The MozillaTranslator component is moving to the Mozilla Localisations product.
Product: Browser → Mozilla Localizations
Version: other → unspecified
Reassigning every MT bug to me.
Assignee: henrik → rpmdisguise-otros
Do we really want this? I mean, can we trust in those keys being always present with that name and having the right value for JARs and XPIs to work?

Instead hardcoding the key names, I'd rather add a field to each JAR definition inside the product management to let the user work it out. The user can set the wrong field, but he/she can also fix it by themselves.
Status: NEW → ASSIGNED
(In reply to comment #3)
> Do we really want this? I mean, can we trust in those keys being always present
> with that name and having the right value for JARs and XPIs to work?
> 
> Instead hardcoding the key names, I'd rather add a field to each JAR definition
> inside the product management to let the user work it out. The user can set the
> wrong field, but he/she can also fix it by themselves.
> 

Forget that. localeVersion field is still present, but disabled and pre-filled with values from global/brand.dtd:lang.version, like OP suggested. Another bug solved but not closed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Product: Mozilla Localizations → Mozilla Localizations Graveyard
You need to log in before you can comment on or make changes to this bug.