[Chandler-dev] Localization loading discussion

Thu Jun 8 08:43:38 PDT 2006

I have a new, more evolved, version of the prototype and I will post it 
for review today. I will post it to Bugzilla page Bug 5970 so everyone 
who is interested may take a look.

Cheers,
    Markku

> >> Just as an FYI, the prototype that Markku has been working on is a 
> demonstration of something similar to my original proposal for this.  
> >> That is, an API that can find all the egg-supplied resources at 
> startup with only a single scan.  It doesn't need the repository or 
> any >> >> special install steps.  So I'd suggest looking at his 
> prototype to decide where to go next.
>
> Yes!
> This is more along the lines of the approach I am looking for. I will 
> review the prototype.
>
> --Brian
>
>
> Brian Kirsch -  Cosmo Developer / Chandler Internationalization Engineer
> Open Source Applications Foundation
> 543 Howard St. 5th Floor
> San Francisco, CA 94105
> http://www.osafoundation.org
>
>
>
> Phillip J. Eby wrote:
>
>> Just as an FYI, the prototype that Mikku has been working on is a 
>> demonstration of something similar to my original proposal for this.  
>> That is, an API that can find all the egg-supplied resources at 
>> startup with only a single scan.  It doesn't need the repository or 
>> any special install steps.  So I'd suggest looking at his prototype 
>> to decide where to go next.
>>
>> At 02:09 PM 6/7/2006 -1000, Brian Kirsch wrote:
>>
>>> Hello,
>>> There is an ongoing discussion regarding bug 6007 "Need to localize 
>>> code that is run before repository is up".
>>>
>>>
>>> <http://bugzilla.osafoundation.org/show_bug.cgi?id=6007>http://bugzilla.osafoundation.org/show_bug.cgi?id=6007 
>>>
>>>
>>> Since others may have thoughts and opinions on the subject I am 
>>> forwarding to the list.
>>>
>>> Basically it comes down to the issue that Chandler needs access to 
>>> certain localized strings and resources
>>> before the Repository is created.
>>>
>>>
>>>
>>> ------- Comment #5 >From <mailto:bkirsch at osafoundation.org>Brian 
>>> Kirsch 2006-06-07 17:07 PST 
>>> [<https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>reply] 
>>> -------
>>> Yes Markku is correct,
>>> We are *not* storing translations in the repository.
>>>
>>> There was discussion of storing the paths to translation files in 
>>> the repo and
>>> registering translations at installParcel time. But frankly, I am 
>>> not conviced
>>> this is the right approach at least for the Chandler level 
>>> translations since
>>> that still leaves a large edge case where we need translation 
>>> strings before
>>> the repo is created.
>>>
>>> I am leaning at this point to just having a know directory structure 
>>> for
>>> Chandler level translations and resources and using scripts to install
>>> localizations in to that structure.
>>>
>>> Third party devs could use the installParcel mechanism since the 
>>> repo will be
>>> present at that point.
>>>
>>> An alternate approach is to have a registration file that lives 
>>> outside of the
>>> repo and contains the locations of Chandler level translations and 
>>> resources.
>>> That was a developer could add a translation for Chandler outside 
>>> the Chandler
>>> directory structure and just append the location to the file.
>>>
>>> I think we should avoid the repo at all costs for Chandler level 
>>> translations
>>> as using the repo implies that we have to have another mechanism for 
>>> loading
>>> pre-repo strings and images.
>>>
>>> There is nothing wrong with an item /block storing its translations 
>>> in the repo
>>> however.
>>>
>>> As long as we have a means to refresh the data if the locale or 
>>> schema version
>>> changes.
>>>
>>>
>>>
>>>
>>>
>>> ------- Comment #4 >From <mailto:mmmm at osafoundation.org>Markku 
>>> Mielityinen 2006-06-07 14:50 PST 
>>> [<https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>reply] 
>>> -------
>>> Do you see some benefit in this approach? Items that are stored to 
>>> repo use _()
>>> when they are created. Obviously these items work only when repo is 
>>> up. Items
>>> that are not stored in the repo can/and should use _() each time 
>>> they are
>>> created (that is each time that you run the app at least). And _() 
>>> service is
>>> up all the time. I don't see a translation case when you would like to
>>> store/load to/from repo when it is not up; obviously one exists but 
>>> I just
>>> cannot see it. In my eyes repo and translations (and other 
>>> resources) are more
>>> or less orthogonal. The fact that we have translated string in repo 
>>> is more an
>>> effect than cause (causality). I don't see a reason to put all 
>>> translations to
>>> repo. Maybe you want a CPIA style splashscreen or something like 
>>> that but to me
>>> this seems more or less secondary. So an example please :)
>>>
>>>
>>>
>>> ------- Comment #3 >From <mailto:heikki at osafoundation.org>Heikki 
>>> Toivonen 2006-06-07 14:24 PST 
>>> [<https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>reply] 
>>> -------
>>> The problem is that we intend to store the translations in the 
>>> repository. This
>>> means the boostrap code has no access to translations since we don't 
>>> have a
>>> repository yet. So we need a different way of translating the 
>>> bootstrap code.
>>>
>>> ------- Comment #2 >From <mailto:mmmm at osafoundation.org>Markku 
>>> Mielityinen 2006-06-07 14:17 PST 
>>> [<https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>reply] 
>>> -------
>>> I am not sure I that I understand the problem. _() translation macro 
>>> should
>>> work right from the start, right? At least mine does and it loads 
>>> translations
>>> from an egg according to the locale setting. And all resources work 
>>> the same
>>> way. I think that you can even have localized XRC based dialogs if 
>>> you want to
>>> :) Please give a more detailed description of the problem. This 
>>> questions
>>> relates to 
>>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=4656>bug 4656 as 
>>> well.
>>>
>>>
>>>
>>> ------- Comment #1 >From <mailto:bkirsch at osafoundation.org>Brian 
>>> Kirsch 2006-06-07 13:31 PST 
>>> [<https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>reply] 
>>> -------
>>> yes this is a known issue which I am currently thinking about how 
>>> best to solve
>>> from an architectual standpoint.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> Brian Kirsch -  Cosmo Developer / Chandler Internationalization 
>>> Engineer
>>> Open Source Applications Foundation
>>> 543 Howard St. 5th Floor
>>> San Francisco, CA 94105
>>> <http://www.osafoundation.org>http://www.osafoundation.org
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "chandler-dev" mailing 
>>> listhttp://lists.osafoundation.org/mailman/listinfo/chandler-dev
>>
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev