Closed Bug 160165 Opened 22 years ago Closed 8 years ago

Need to provide a way for embedders to supply all their own UI strings

Categories

(Core Graveyard :: Embedding: APIs, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

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.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta
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.
Target Milestone: mozilla1.2beta → mozilla1.3alpha
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)
Depends on: 172004
moving somewhat important bugs to 1.3beta for consideration - some of these may
be bumped out to 1.4alpha after being evaluated.
Target Milestone: mozilla1.3alpha → mozilla1.3beta
Blocks: 189371
Target Milestone: mozilla1.3beta → mozilla1.4beta
Target Milestone: mozilla1.4beta → mozilla1.5alpha
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".
OS: Mac System 9.x → All
Hardware: Macintosh → All
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.
Assignee: alecf → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: dunn5557 → apis
Target Milestone: mozilla1.5alpha → ---
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.