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

RESOLVED FIXED

Status

--
enhancement
RESOLVED FIXED
16 years ago
5 years ago

People

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

Tracking

Details

(Reporter)

Description

16 years ago
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

Updated

16 years ago
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
(Assignee)

Comment 2

12 years ago
Reassigning every MT bug to me.
Assignee: henrik → rpmdisguise-otros
(Assignee)

Comment 3

12 years ago
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
(Assignee)

Comment 4

12 years ago
(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
Last Resolved: 12 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.