On 05.05.2010 21:39, Hilaire Fernandes wrote:
> Philippe Marschall a écrit :
>> On 04/29/2010 10:55 PM, Hilaire Fernandes wrote:
>>> I have move in a Gettext package in PharoInbox classes for gettext
>>> support. Do not expect it to work. Some of the classes there, are just
>>> moved from former categories in pharo System-Localization and
>>> Multilingual other are coming from Etoys.
>>>
>>> I have not yet test to load it in a fresh image.
>>
>> I'm interested in this for Seaside. I have a couple of notes:
>> - Why do you move LocaleID from System-Localization to Gettext?
>
> This class was modified. It is a temporary action to study this set of
> classes.
>
>> - Do we really need GetTextExporter2 if you don't have a
>> GetTextExporter1?
>> - Why is there a #translate:in: if it's empty?
>
> Yes, cleaning is needed and I need to figure out several aspect of the
> framework, as do we need InternalTranslator and the LanguageEditor? I am
> tempted to think no.
>
>
>
>> The protocol I have in mind for Seaside is something like:
>>
>> html translate:
>
> aString translated "return the translating in the current locale."
Nope sorry, in a server the current locale in the one of the request or
session, not a global variable. Seaside can figure this out
automatically which is why I need some layer over gettext. But I also
need a way to make the gettext exporter aware of this, basically looking
for more selectors.
>> html translate:to:
>
>
> NaturalLanguageTranslator
> translate: 'This point %1'
> toLocaleID: (LocaleID isoLanguage: 'fr')
> inDomain: 'DrGeoII'
> -> 'Ce point %1'
> 'DrGeoII' is the name of the catalog to look for the translation.
Which would be the Seaside application name. This can be looked up
automatically without a need to repeat yourself every time you want to
have a string translated.
> Wth this message you also avoid some overhead as your directly specify
> the translation catalog. The system does not need to figure out the
> catalog to search the translation (done by figuring out from which class
> - then class category - the String>>translated message was sent).
>
>
> Your register a domain from classes prefix:
> TextDomainManager registerCategoryPrefix: 'DrGeoII' domain: 'DrGeoII'.
I would need to hock into that. So that a domain has a "scope" of only
several class categories and has a given value there. Is there a way to
do this?
> Then you export the .po file for translation:
> GetTextExporter2 exportTemplate.
>
> Then you compile your .po translation as .mo and move it in
> locale/fr/LC_MESSAGES/DrGeo.mo
>
>
> Some documentation in the PBE2 could be written once stuff is stabilized.
> In the Etoys ml, Bert proposed to move the domain in the method
> properties to get a more efficient translation look-up
>
>> What would the way to hook into GetTextExporter(2) to make it pick
>> that up?
Cheers
Philippe
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
