[Chandler-dev] Localization loading discussion

Wed Jun 7 18:18:32 PDT 2006

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

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