In our current embedding model, there are a bunch of places where Gecko-supplied strings can show up in the embedders UI; for instance, the prompt service. I think we need to allow embedders to be able to supply all their UI strings, and not use any strings from Gecko. This allows embedders to: 1. Do all their localization their own way, and not mess with gecko localization 2. Adapt the strings to their own application, including: i) showing the application name in strings ii) having strings refer to other parts of the UI iii) adjusting strings to fit available space Rather than supply display strings to the embedder, Gecko would therefore need to supply string keys to the embedder, which are documented somewhere. The embedder would use these keys to look strings up in their own string bundle.

this is a very cool idea. My initial thoughts (so I don't forget them by the time I write this) 1) provide some interface by which you can "override" bundles - i.e. lets say I register an object which overrides "chrome://necko/locale/necko.properties" - this might look something like (in IDL) void overrideBundle(in ACString chromeURL, in nsIStringHandler handler); (to be added to nsIStringBundleService) 1a) Another option is to use the category manager, to map URLs to ContractIds (as in mapping "chrome://navigator/locale/navigator.properties" -> "@mozilla.org/stringbundle/windows-resource-handler;1") - the advantage there is we don't have to rely on runtime registration, which means no dependence on which object gets instantiated first, and so forth. 2) provide some basic, platform-specific implementations of this new interface, which makes use of system resources to retrieve the strings - one for each platform. I'm imagining interface nsIStringHandler : public nsISupports { AString getStringFromName(in ACString bundleURL, in ACString stringID); AString getStringFromID(in ACString bundleURL, in long stringID); } the reason we pass bundleURL in is to allow a single object to implement nsIStringHandler to override multiple bundles - no sense in requiring seperate objects for each bundle. The string bundle service will still create the nsStringBundleImpl object, so that it can do stuff like formatStringFromName() and free the nsIStringHandler interface from dealing with it. The string bundle service will make sure that the newly create string bundles are aware of their "override" objects. If the override object throws any kind of error on a particular string, then the string bundle can fall back to a default .properties file. CC'ing chak. The more I think about this solution, I wonder if this would fit embeddors needs more than bug 160000, especially if we provided default implementations of these handlers.

mozilla 1.1alpha is more or less done, so I'm moving non-critical mozilla1.2beta bugs out to the next milestone to make room for the mozilla1.1alpha bugs that didn't make it.

Users are starting to poke fun at chimera's security-related dialog text: "This site is not who it says it is and has either stolen its identity or has created one itself that cannot be verified" and "This site appears to have a security certificate which is either invalid, expired or not registered with a trusted authority. View Certificate / Stop / Proceed" We really need to do something about this.

we will be providing a similar, simpler solution in bug 172004 (which is not to say that that bug precludes this, its just a simpler problem to solve.. though it is possible that the solution to bug 172004 result in an architecture that will make this bug very easy)

moving somewhat important bugs to 1.3beta for consideration - some of these may be bumped out to 1.4alpha after being evaluated.

This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".

This bug hasen't been touched for years and is clearly unowned. Moving back to default assignee/QA so that people, who are watching those can accurately triage this bug. Also resetting Priority, Target Milestone, Status Whiteboard and Status.

Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.