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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
