Closed Bug 45704 Opened 25 years ago Closed 5 years ago

string bundles should not depend on chrome registry directly

Categories

(Core :: Internationalization, defect, P3)

All
Other
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: warrensomebody, Assigned: warrensomebody)

Details

(Keywords: arch)

Subject: Re: string bundles Date: Mon, 17 Jul 2000 15:39:51 -0700 From: tao@netscape.com (Tao Cheng) To: Warren Harris <warren@netscape.com> CC: hyatt@netscape.com, alecf@netscape.com References: 1 , 2 , 3 Warren Harris wrote: I think that were you get the string bundle should be completely arbitrary. Consider applications that just want to be small and do something simple. They don't want to load the chrome protocol and rdf. They might not even care about different locales. Let the chrome protocol do its own caching if it's inefficient. That makes sense. I assume you will just look at the filename extension to decide whether to cache or not? I assume this is how we cache XUL, RDF, DTD, CSS, etc..? Would you log a bug then? I assume this is not nsbeta2? -Tao Warren Tao Cheng wrote: Warren Harris wrote: Why do string bundles need to call ConvertChromeURL at all? I assume you're referring to 727 : 723 nsCOMPtr<nsIChromeRegistry> chromeRegistry = 724 do_GetService(kChromeRegistryCID, &ret); 725 if (NS_SUCCEEDED(ret)) { 726 727 ret = chromeRegistry->ConvertChromeURL(mScratchUri, getter_Copies(newSpec)); 728 if (NS_SUCCEEDED(ret)) { 729 if (NS_SUCCEEDED(ret)) urlSpec = newSpec; 730 } 731 } Why can't they just load the url directly (with NS_OpenURI) and let the chrome protocol handler kick in if necessary? Fixing this would allow us to use resource: urls for string bundles. This is because stringBundle is now cached and ConvertChromeURL() is called to convert the chrome urls to real url which is used as the key to the hash table. Why do you need to use resource URL to localizable resource in XUL world? In any case, this strres api can check the URL protocol before calling ConvertChromeURL(). -Tao Warren -- All my opinions are mine; not Netscape's -- All my opinions are mine; not Netscape's
Keywords: arch
very unlikely to fix this in this release!
Status: NEW → ASSIGNED
Target Milestone: --- → M22
If you don't fix it, I will.
In PR2?
No, we'll do it in pr3. Hyatt said what's needed here is to flush the string bundle cache after switching skins or locales. He's already flushing other caches at the same time. No one should be calling ConvertChromeURL directly.
I see. Reassign it to you. Alec was the original author of the code. You might want to work w/ him on this move. Thanks
BTW, why would string bundle have to do with skin switching? Does moving the code to libnet make it easier to flush the cache in switching locale? Or, you just want to flush all cache after switching providers?
Assignee: tao → warren
Status: ASSIGNED → NEW
warren - when you start to tackle this, let me know.. I'd like to work on a scheme where stringbundles are still cached in-memory.. you said "let the chrome protocol do it's own caching if it's inefficient" - string bundles (well, properties files) have different usage patterns than XUL, which is why it does it's own caching...
Changed QA contact to tao@netscape.com.
QA Contact: teruko → tao
QA Contact: tao → i18n

Current generation of l10n in Gecko - Fluent - uses ResourceProtocol, and does not rely on Chrome Registry.

The old systems are deprecated so I hope I can close this.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.