[Chandler-dev] Localization loading discussion

Wed Jun 7 17:51:00 PDT 2006

One of the proposals we were considering was storing a dictionary of 
paths to mo's in the repository. This would make it easy to file the 
translation files at lookup time. The dictionary would be initialized at 
parcel install time, like all other items in the initial repository.

John

Bryan Stearns wrote:
> +1 to NOT storing translations in the repository. (What would storing 
> them in the repository get us, anyway?)
>
> ...Bryan
>
> 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
>>
>> 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 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#c5> >From 
>> Brian Kirsch <mailto:bkirsch at osafoundation.org> 2006-06-07 17:07 PST 
>> / [reply 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>] 
>> -------
>> 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 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#c4> >From 
>> Markku Mielityinen <mailto:mmmm at osafoundation.org> 2006-06-07 14:50 
>> PST / [reply 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>] 
>> -------
>> 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 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#c3> >From 
>> Heikki Toivonen <mailto:heikki at osafoundation.org> 2006-06-07 14:24 
>> PST / [reply 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>] 
>> -------
>> 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 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#c2> >From 
>> Markku Mielityinen <mailto:mmmm at osafoundation.org> 2006-06-07 14:17 
>> PST / [reply 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>] 
>> -------
>> 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 bug 4656 <https://bugzilla.osafoundation.org/show_bug.cgi?id=4656> as well.
>>   
>>
>>
>> ------- /Comment #1 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#c1> >From 
>> Brian Kirsch <mailto:bkirsch at osafoundation.org> 2006-06-07 13:31 PST 
>> / [reply 
>> <https://bugzilla.osafoundation.org/show_bug.cgi?id=6007#add_comment>] 
>> -------
>> 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
>>   
>> ------------------------------------------------------------------------
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>>   
>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060607/5ef1dd92/attachment.html