gettext package

> Philippe Marschall a écrit :
>
>>>> 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
>
> Yes, it makes sense. So in some way you need to specify the locale to
> use for translation, and it was not how was intended String>>translated,
> so definitely not your friend.
>
>> automatically which is why I need some layer over gettext. But I also
>
> Right.
>
>> need a way to make the gettext exporter aware of this, basically looking
>> for more selectors.
>
> Yes, we should adapt the protocol to the need. I would like to clean it
> a and remove some classes as the NaturalLanguageEditor and
> InternalTranslator so we can simplify the whole package.
>
>
>>
>>>> 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.
>
> Yes, it makes sense.
>
>>
>>> 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?
>
> Yes, execute:
>
> TextDomainManager registerCategoryPrefix: 'Seaside-MyShop' domain:
> 'MyShop'.

> Then  a new domain is created, at startup, the relevant .mo file are
> loaded (I guess, not sure how it is handled in detail).
>
> Is it what you were asking?
>
>>> 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?