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?
This I really don't know.
Hilaire
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
