Closed Bug 937654 Opened 11 years ago Closed 7 years ago

Refactor stringbundle.js to allow for brand bundle

Categories

(Core :: Internationalization: Localization, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mkaply, Assigned: BenB)

Details

It would be nice if services/common/stringbundle.js automatically allowed for a brand bundle and did automatic substitution. This might also help with bug 930737 My thoughts are: Pass a brand bundle to the along to the Stringbundle and have a set of strings that would get autoreplaced from the bundle (like %brandShortName% or %brandFullName%). It might be that we even process the brand file and detect that strings so we can autoreplace anything in the original string with %identifier%. Then we don't have to predefine anything..
I have an idea how to do this generically.
Assignee: nobody → ben.bucksch
Component: General → Localization
E.g. make a new function that says "loadPlaceholderStringbundle()". This would be loaded and kept in RAM and used for all subsequent loads of stringbundles. If words in stringbundle values are enclosed in % (e.g. "%brand%"), this placeholder would be looked up in all placeholder stringbundles loaded. The file would still have the name=value format, so you could have: productName=Firefox vendor=Mozilla in brand.placeholder.properties and regionName=German in region.placeholder.properties and call loadPlaceholderStringbundle("chrome://.../brand.placeholder.properties"); loadPlaceholderStringbundle("chrome://.../region.placeholder.properties"); and then have closeConfirmMsg=Are you sure you want to close %productName%? langConfirmMsg=You are currently using a %regionName% %productName%. Do you want to install the %regionName% dictionary for spellchecking, too? and when calling loadStringbundle("chrome://.../browser.properties"); it would be automatically expanded, on load time, to: closeConfirmMsg=Are you sure you want to close Firefox? langConfirmMsg=You are currently using a German Firefox. Do you want to install the German dictionary for spellchecking, too?
(In reply to Ben Bucksch (:BenB) from comment #2) > E.g. make a new function that says "loadPlaceholderStringbundle()". This > would be loaded and kept in RAM and used for all subsequent loads of > stringbundles. If words in stringbundle values are enclosed in % (e.g. > "%brand%"), this placeholder would be looked up in all placeholder > stringbundles loaded. > > The file would still have the name=value format, so you could have: > productName=Firefox > vendor=Mozilla > in brand.placeholder.properties and > regionName=German > in region.placeholder.properties and > > call > loadPlaceholderStringbundle("chrome://.../brand.placeholder.properties"); > loadPlaceholderStringbundle("chrome://.../region.placeholder.properties"); > > and then have > closeConfirmMsg=Are you sure you want to close %productName%? > langConfirmMsg=You are currently using a %regionName% %productName%. Do you > want to install the %regionName% dictionary for spellchecking, too? > and when calling loadStringbundle("chrome://.../browser.properties"); > it would be automatically expanded, on load time, to: > closeConfirmMsg=Are you sure you want to close Firefox? > langConfirmMsg=You are currently using a German Firefox. Do you want to > install the German dictionary for spellchecking, too? I'm not really following this bug or what it intends to do, but this solution will be fraught with so many l10n issues. Aside from requiring adjectival forms of the various regions/locales, such words will require a lot more inflectional flexibility than a simple product name. This is a very non-ideal solution, no matter what the problem is.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
We have new l10n systems for things like this.
Resolution: INACTIVE → WONTFIX
You need to log in before you can comment on or make changes to this bug.