[Pharo-project] gettext package
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. Hilaire
Thanks to the virtual hacking session yesterday on IRC (irc.freenode.org #pharo-project) and the help of hackers Marcus, Henrik and Korakurider we have moved the gettext package in a workable state. So far .po files can be exported as domain (class category) for translation and .mo (compiled translated message) are imported at Pharo startup. Still there are thing to do and discuss: - I have moved all the modified and added classes in the gettext package. Modified classes were moved out of their original category, for example LocaleID, NaturalLanguageTranslator. If we want to group translation tool it mean recatgorisation in the core Pharo. - If we want the gettext package to be loadable, the method String>>translated in core could be changed to return self, then the gettext packaged provided the translated version to effectively handle the translation. - regarding translation, we could end with a pharo.po file to group the translated message of the core. It will be located in a folder locale along the image. There are still cleaning to do in the internal, and I hope simplifications in the code. Hilaire Hilaire Fernandes a écrit :
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.
Hilaire
On May 1, 2010, at 9:24 AM, Hilaire Fernandes wrote:
Thanks to the virtual hacking session yesterday on IRC (irc.freenode.org #pharo-project) and the help of hackers Marcus, Henrik and Korakurider we have moved the gettext package in a workable state. Excellent
So far .po files can be exported as domain (class category) for translation and .mo (compiled translated message) are imported at Pharo startup.
Still there are thing to do and discuss:
- I have moved all the modified and added classes in the gettext package. Modified classes were moved out of their original category, for example LocaleID, NaturalLanguageTranslator. If we want to group translation tool it mean recatgorisation in the core Pharo.
I would love to have as much as possible as internationalisation in a identifiable package.
- If we want the gettext package to be loadable, the method String>>translated in core could be changed to return self, then the gettext packaged provided the translated version to effectively handle the translation.
but this would be an override.
- regarding translation, we could end with a pharo.po file to group the translated message of the core. It will be located in a folder locale along the image.
sounds good. Clearly in the future this should a package metadata.
There are still cleaning to do in the internal, and I hope simplifications in the code.
Excellent
Hilaire
Hilaire Fernandes a écrit :
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. Hilaire
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse a écrit :
- If we want the gettext package to be loadable, the method String>>translated in core could be changed to return self, then the gettext packaged provided the translated version to effectively handle the translation.
but this would be an override.
Yes, is it a problem?
- regarding translation, we could end with a pharo.po file to group the translated message of the core. It will be located in a folder locale along the image.
sounds good. Clearly in the future this should a package metadata.
??
On 5/1/10 2:05 PM, Hilaire Fernandes wrote:
Stéphane Ducasse a écrit :
- If we want the gettext package to be loadable, the method String>>translated in core could be changed to return self, then the gettext packaged provided the translated version to effectively handle the translation.
but this would be an override.
Yes, is it a problem?
Yes, overrides in a core class are always a problem. Another way to solve this would be to dispatch translated through NaturalLanguageTranslator which I guess would be completely replaced by the gettext package? Maybe we should turn the translation related classes all into stubs that then can be replaced by either the current version (made loadable as a package) or the gettext one. Michael
On May 2, 2010, at 5:52 PM, Michael Rueger wrote:
On 5/1/10 2:05 PM, Hilaire Fernandes wrote:
Stéphane Ducasse a écrit :
- If we want the gettext package to be loadable, the method String>>translated in core could be changed to return self, then the gettext packaged provided the translated version to effectively handle the translation.
but this would be an override.
Yes, is it a problem?
Yes, overrides in a core class are always a problem.
Another way to solve this would be to dispatch translated through NaturalLanguageTranslator which I guess would be completely replaced by the gettext package?
can you give a sketch example so that I the it? instaed of 'lkjhlk' translated NaturalLanguageTranslator translated: 'lkjhlk' ?
Maybe we should turn the translation related classes all into stubs that then can be replaced by either the current version (made loadable as a package) or the gettext one.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
can you give a sketch example so that I the it?
instaed of 'lkjhlk' translated NaturalLanguageTranslator translated: 'lkjhlk'
No, you keep the 'lkjhlk' translated :-) Apologies, the current implementation does already what I meant String>>translated ^ NaturalLanguageTranslator current translate: self All you would need to do is to exchange the implementation of NaturalLanguageTranslator depending on whether you want to use the current implementation or gettext. Michael
Ok I understand now. Stef On May 2, 2010, at 6:13 PM, Michael Rueger wrote:
can you give a sketch example so that I the it?
instaed of 'lkjhlk' translated NaturalLanguageTranslator translated: 'lkjhlk'
No, you keep the 'lkjhlk' translated :-)
Apologies, the current implementation does already what I meant
String>>translated ^ NaturalLanguageTranslator current translate: self
All you would need to do is to exchange the implementation of NaturalLanguageTranslator depending on whether you want to use the current implementation or gettext.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Michael Rueger a écrit :
can you give a sketch example so that I the it?
instaed of 'lkjhlk' translated NaturalLanguageTranslator translated: 'lkjhlk'
No, you keep the 'lkjhlk' translated :-)
Apologies, the current implementation does already what I meant
String>>translated ^ NaturalLanguageTranslator current translate: self
The message current has changed, it seems to have a different meaning in recent reimplementation of NaturalLanguageTranslator. I rewrote it like bellow: String>>translated "answer the receiver translated to the default language" ^NaturalLanguageTranslator translate: self
All you would need to do is to exchange the implementation of NaturalLanguageTranslator depending on whether you want to use the current implementation or gettext.
Do we want to have two implemenations or do we just want a dummy NaturalLanguageTranslator class, and the gettext support as an external package? Hilaire
So far .po files can be exported as domain (class category) for translation and .mo (compiled translated message) are imported at Pharo startup.
What are .po and .mo files ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
.mo = Gettext Machine Object File .po = Gettext Portable Object File http://translate.sourceforge.net/wiki/guide/glossary Cheers, Hernán 2010/5/2 Alexandre Bergel <alexandre@bergel.eu>:
So far .po files can be exported as domain (class category) for translation and .mo (compiled translated message) are imported at Pharo startup.
What are .po and .mo files ?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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? - Do we really need GetTextExporter2 if you don't have a GetTextExporter1? - Why is there a #translate:in: if it's empty? The protocol I have in mind for Seaside is something like: html translate: html translate:to: What would the way to hook into GetTextExporter(2) to make it pick that up? Cheers Philippe
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."
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. 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'. 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
On May 5, 2010, at 9:39 PM, Hilaire Fernandes wrote:
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 do you mean with your last sentence? Stef
Stéphane Ducasse a écrit :
On May 5, 2010, at 9:39 PM, Hilaire Fernandes wrote:
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 do you mean with your last sentence?
http://lists.squeakland.org/pipermail/etoys-dev/2010-May/004615.html
missing too much context to understand. Sorry I'm too stupid. On May 5, 2010, at 9:58 PM, Hilaire Fernandes wrote:
Stéphane Ducasse a écrit :
On May 5, 2010, at 9:39 PM, Hilaire Fernandes wrote:
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 do you mean with your last sentence?
http://lists.squeakland.org/pipermail/etoys-dev/2010-May/004615.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I don't understand much as well, this stuff is all new for me. Hilaire Stéphane Ducasse a écrit :
missing too much context to understand. Sorry I'm too stupid.
On May 5, 2010, at 9:58 PM, Hilaire Fernandes wrote:
Stéphane Ducasse a écrit :
On May 5, 2010, at 9:39 PM, Hilaire Fernandes wrote:
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 do you mean with your last sentence? http://lists.squeakland.org/pipermail/etoys-dev/2010-May/004615.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
On 05/06/2010 04:55 PM, Hilaire Fernandes wrote:
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'.
That's exactly what I need.
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?
I have two train rides this weekend. I'll see if I can hack something up. Cheers Philippe
participants (7)
-
Alexandre Bergel -
Hernán Morales Durand -
Hilaire Fernandes -
Michael Rueger -
Philippe Marschall -
Philippe Marschall -
Stéphane Ducasse