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)
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
very unlikely to fix this in this release!
Status: NEW → ASSIGNED
Target Milestone: --- → M22
Assignee | ||
Comment 2•24 years ago
|
||
If you don't fix it, I will.
Assignee | ||
Comment 4•24 years ago
|
||
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
Comment 7•24 years ago
|
||
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...
Updated•15 years ago
|
QA Contact: tao → i18n
Comment 9•5 years ago
|
||
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.
Description
•