Closed
Bug 161886
Opened 22 years ago
Closed 18 years ago
[Enh] remove 'version' field from 'export' dialogs
Categories
(Mozilla Localizations Graveyard :: MozillaTranslator, enhancement)
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
Comment 1•22 years ago
|
||
The MozillaTranslator component is moving to the Mozilla Localisations product.
Product: Browser → Mozilla Localizations
Version: other → unspecified
Assignee | ||
Comment 2•18 years ago
|
||
Reassigning every MT bug to me.
Assignee: henrik → rpmdisguise-otros
Assignee | ||
Comment 3•18 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•18 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
Closed: 18 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: Mozilla Localizations → Mozilla Localizations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•