The stub installer would have to pass in locale info to the JARs to maintain "locale consistency." In such a situation, LoadResources() may potentially display the wrong locale since it uses OS-exported info which may differ from the user's selection in the stub country picker. A modification must be made to LoadResources() to take two params if the country picker feature does happen: Object LoadResources( String aBaseName, String aLocaleID ); where aLocaleID is optional. This way one of the arguments to the install script could be the locale ID passed in from the stub, reflecting the user's country picker selection. Dependency: ----------- This is contingent upon commitment to the "country picker" in the Install Wizards.
setting target milestone to M11
Removing target milestone since we have not yet committed to the country picker and without that feature in the Install Wizards this feature will probably not be very useful. We will us ethis bug merely for tracking purposes for now. It is also contingent upon locale-specific file name deductions that are not yet in the codebase.
This doesn't need to work until after the beta because we're not going to be translating anything then. Might be nice to pull in, but only if everything else is working.
Summary: LoadResources() should take optional locale ID param → RFE: LoadResources() should take optional locale ID param
Target Milestone: M14
See previous comment about using this as a placeholder: not committed yet, hence resetting target milestone to "empty."
This is a useful feature apart from any "country picker" UI in the wizards. A script could attempt to use navigator.language to load appropriate resources, such as a code-only security patch served from NetCenter.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → INVALID
One feature of LoadResources is the locale "fallbacks" whereby the browser's locale info is appended to the basename provided (unimplemented). Once this feature goes in I don't see that the optional localeID param will be useful. If an install script writer wants to load by explicitly specifying the localeID then he she can include this in the basename in the original API that just accepts the basename. Given the above and the fact that the install wizard will not be implementing the country picker I'm closing this out as invalid. Feel free to reopen if there is a counter argument to the thoughts presented above.
Going once... Going twice... Marking Verified.
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine
You need to log in before you can comment on or make changes to this bug.