45704 - string bundles should not depend on chrome registry directly

Status: RESOLVED FIXED

(Core :: Internationalization, defect, P3)

Description

[Warren Harris]

Subject: 
             Re: string bundles
       Date: 
             Mon, 17 Jul 2000 15:39:51 -0700
       From: 
             [e-mail] (Tao Cheng)
          To: 
             Warren Harris <[e-mail]>
         CC: 
             [e-mail], [e-mail]
 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

Comment 1

[tao]

very unlikely to fix this in this release!

Comment 2

[Warren Harris]

If you don't fix it, I will.

Comment 3

[tao]

In PR2?

Comment 4

[Warren Harris]

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.

Comment 5

[tao]

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

Comment 6

[tao]

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?

Comment 7

[Alec Flett]

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... 

Comment 8

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

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.