September 2010 - Pharo-users

Re: [Pharo-users] i18n tools

by Panu Suominen

2010/9/10 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Check with Philip Marchall, he did modification to use gettext code with > Seaside. Ok. Thanks to all for the help. Seaside and gettext are apparently the magic words that solves this problem. :) http://forum.world.st/Seaside-Gettext-sneak-peak-td2164600.html -- Panu

Sept. 10, 2010

Re: [Pharo-users] i18n tools

by Miguel Enrique CobÃ¡ MartÃnez

El jue, 09-09-2010 a las 22:12 +0300, Panu Suominen escribiÃ³: > I am researching wether out team could start using Pharo. I have tried to locate > some tools to do user interface translations but I did not find > anything in time so I had > to develop some rudimentary key-based translation tools my self. I would like > to know is this lack of translation tools reality and if others are having same > kind of problems? > There are effort to bring gettext infrastructure to Pharo and seaside. Search the archives for details. What I do in Seaside is to store create a base class for the default languan, lets say, english: MyLanguage with class methods for each string that I want localized, f.e. MyLanguage class>>greet ^ 'Hello User' MyLanguage class>>numItems: num ^ '{1} items' format: {num} This allows me to have parametrized messages. Now for each language you want to support you create a subclass: MyLanguage subclass: #MyLanguageESMX and override each method you want to translate: MyLanguageESMX class>>greet ^ 'Hola usuario' MyLanguageESMX class>>numItems: num ^ '{1} elementos' format: {num} If some method is missing in the subclass, it will take the value of the parent class. Now, to use it, store in each user session a inst var holding the prefered _class_ for the language the user wants. And create an accessor for this inst var: WASession subclass: #MySession instanceVariableNames: 'user announcer language' classVariableNames: '' poolDictionaries: '' category: 'MyPackage' MySession>>lang ^ self user preferences language Now when you want to emit a string do: MyLogin>>renderContentOn: html html div id: 'login'; with: [ self session lang greet; self renderLoginOn: html ] As the lang accessor returns the preferred lang class for the user, the message greet is understood (they are class methods) and returns the correct translated string for the given user. To create a new translation, you copy a existent subclass of MyLanguage and rewrite the strings for the new language. Of course this only takes care of the string translation, and does nothing about currency and left-to-right issues in distinct languages. For the currency issue you can add a format message that emits the correct representation of a number in the current locale but for the direction of text, you'll need to look for other options, like the gettext code I mentioned before. Hope this helps. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 10, 2010

Re: [Pharo-users] i18n tools

by Panu Suominen

2010/9/10 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > I don't understand what you want to do. > Have you read the localisation chapter I wrote in the Pharo Collaboactive > book? Ok. Now I managed to see the localisation page. Thank you for the tip. I try to integrate that to seaside. -- Panu

Sept. 10, 2010

Re: [Pharo-users] i18n tools

by Panu Suominen

2010/9/10 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > I don't understand what you want to do. I am researching a way to translate user interface in seaside application. I have tried to look for code to take care of translations but haven't found anything. > Have you read the localisation chapter I wrote in the Pharo Collaboactive > book? I did not know that there is such a chapter there. Is there a link to the book from pharo homepage? However, the book gives me an error: Seaside Walkback Error: subscript is out of bounds: 8218 -- Panu

Sept. 10, 2010

Re: [Pharo-users] i18n tools

by Mariano Martinez Peck

Panu, maybe you may want to cc seaside mailing list too ;) On Fri, Sep 10, 2010 at 2:41 PM, Panu Suominen <panu.j.m.suominen(a)gmail.com>wrote: > 2010/9/10 Stanislav Paskalev <kshorg(a)gmail.com>: > > Seaside had none the last time I asked. Please do so. > > I am in a bit hurry, but I hope you can still make sense out of this. > > The whole seaside and translation thing is based on the fact that > Seaside render: method is dispatched to objects renderOn: method where > we can access session. On the other hand > we can store language to session. If we implement object that is able > to answer correctly to translate: -message with language as a > parameter we have a simple translation framework. > > I created a simple translation framework which is able to return > translation for certain key. Keys are looked from properly named > subclass. Names are form of LanguagePackOfProgramX_fi, > LanguagePackOfProgramX_en. Each containing translations for the given > language. K3LanguagePack and tests should give better idea. > > Notice that examples below need language -method in session.... > > Example to use with seaside: > > renderContentOn: html > html render: (LanguegPackOfMyProgram translationFor: #greetingMessge) > > > Example with magritte: > descriptionEmail > ^MAStringDescription new > accessor: #email; > label: (K3CoreLanguagePack translationFor: #email); > addCondition: [:value | value includes: $@] labelled: > (LanguegPackOfMyProgram translationFor: #emailNotValid); > beRequired; requiredErrorMessage: > (LanguegPackOfMyProgram translationFor: #emailIsRequired); > priority: 10; > yourself. > > > The magritte part was builded on top of 2.0.5 magritte-seaside. > > This code enabled me to build seaside application demo that could > change its user interface on the fly. Meaning that anything else stays > as it is, only the language changes. > But I don't know how useful this is for other people. > > Currently the major flaw is that there is no way to set the arguments > for the translation ('Hello user, your name is {1}'). It is not a big > addition but haven't needed it in this proof of concept. However it > should not be very hard to implement. > > Other thing that should be discussed is the way translations are > stored. I chose to use symbols that points to methods and thus > translations can be encapsulated in classes. However there seems to be > NaturalLanguageTranslator and string translate already in existence > and I am wondering should I change the implementation to use them > instead. > > I am very open to suggestions. > > -- > Panu > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

Sept. 10, 2010

Re: [Pharo-users] i18n tools

by Panu Suominen

2010/9/10 Stanislav Paskalev <kshorg(a)gmail.com>: > Seaside had none the last time I asked. Please do so. I am in a bit hurry, but I hope you can still make sense out of this. The whole seaside and translation thing is based on the fact that Seaside render: method is dispatched to objects renderOn: method where we can access session. On the other hand we can store language to session. If we implement object that is able to answer correctly to translate: -message with language as a parameter we have a simple translation framework. I created a simple translation framework which is able to return translation for certain key. Keys are looked from properly named subclass. Names are form of LanguagePackOfProgramX_fi, LanguagePackOfProgramX_en. Each containing translations for the given language. K3LanguagePack and tests should give better idea. Notice that examples below need language -method in session.... Example to use with seaside: renderContentOn: html html render: (LanguegPackOfMyProgram translationFor: #greetingMessge) Example with magritte: descriptionEmail ^MAStringDescription new accessor: #email; label: (K3CoreLanguagePack translationFor: #email); addCondition: [:value | value includes: $@] labelled: (LanguegPackOfMyProgram translationFor: #emailNotValid); beRequired; requiredErrorMessage: (LanguegPackOfMyProgram translationFor: #emailIsRequired); priority: 10; yourself. The magritte part was builded on top of 2.0.5 magritte-seaside. This code enabled me to build seaside application demo that could change its user interface on the fly. Meaning that anything else stays as it is, only the language changes. But I don't know how useful this is for other people. Currently the major flaw is that there is no way to set the arguments for the translation ('Hello user, your name is {1}'). It is not a big addition but haven't needed it in this proof of concept. However it should not be very hard to implement. Other thing that should be discussed is the way translations are stored. I chose to use symbols that points to methods and thus translations can be encapsulated in classes. However there seems to be NaturalLanguageTranslator and string translate already in existence and I am wondering should I change the implementation to use them instead. I am very open to suggestions. -- Panu

Sept. 10, 2010

Re: [Pharo-users] i18n tools

by Stanislav Paskalev

Seaside had none the last time I asked. Please do so. Stanislav Paskalev On Fri, Sep 10, 2010 at 2:14 PM, Panu Suominen <panu.j.m.suominen(a)gmail.com> wrote: > To stimulate little more.. I have done rudimentary translation support > for magritte and seaside. > Should I publish them or are there already working options? > > -- > Panu > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Sept. 10, 2010

Re: [Pharo-users] i18n tools

by Panu Suominen

To stimulate little more.. I have done rudimentary translation support for magritte and seaside. Should I publish them or are there already working options? -- Panu

Sept. 10, 2010

Re: [Pharo-users] [ANN] OPAL Digest

by NicolÃ¡s Paez

Cool!!!!! ("copado" in spanish!!!) Saludos! Nico. blog: nicopaez.wordpress.com On Thu, Sep 9, 2010 at 10:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > hi guys > > Since Opalers are working hard in the shadow, I thought that I can do a > little digest for them. > Each time I will delete ten entries I will do a small digest. > Thanks marcus, Jorge and JB for their time and energy. > > Stef > > PS: OPAL is the new compiler framework we will have in 1.3. > Really cool. OPAL comes from the Opal coast near to lille with cool dunes > and birds. > > ==================== Summary ==================== > > Name: OpalCompiler-Core-MarcusDenker.33 > Author: MarcusDenker > Time: 9 September 2010, 8:12:20 pm > UUID: beb4fce5-38ef-4ff1-ba41-924245ff6456 > Ancestors: OpalCompiler-Core-MarcusDenker.32 > > - cleanups (unsent methods) > - make sure to hand over array of copiedTemos to IRBuilder, > not Set. > > final one for today... things start to work. Failing tests down to 24 (from > 40). TestCoverage 81% > > ==================== Summary ==================== > > Name: OpalCompiler-Tests-MarcusDenker.29 > Author: MarcusDenker > Time: 9 September 2010, 7:47:08 pm > UUID: aa19bd88-0895-4ab8-b55c-3f62f1698e33 > Ancestors: OpalCompiler-Tests-MarcusDenker.28 > > - ASTChecker tests does not use verifyin, but just the ASTChecker > - misc changes > > ==================== Summary ==================== > > Name: OpalCompiler-Core-MarcusDenker.32 > Author: MarcusDenker > Time: 9 September 2010, 7:46:21 pm > UUID: 845092d2-e58f-441a-9304-43106311e5a1 > Ancestors: OpalCompiler-Core-MarcusDenker.31 > > -> ASTTraslator now requests a tempVector from IRBuilder if needed > -> simplified ASTClosureAnalyzer --> moved code to block/method scope > -> tempVector now is not a temp anymore, just a copying one if needed > -> verifyIn: now calls both visitors. > > ==================== Summary ==================== > > Name: OpalCompiler-Core-MarcusDenker.31 > Author: MarcusDenker > Time: 9 September 2010, 5:49:20 pm > UUID: ab2dc77f-71b4-4f82-9cb4-4a2c1261e3fe > Ancestors: OpalCompiler-Core-MarcusDenker.30 > > - simplify a bit re-lookup of variables in OCASTClosureAnalyzer > - scopes now have a unique name after ASTChecker pass > (this is then used as the name of the vector) > > > ==================== Summary ==================== > > Name: OpalCompiler-Tests-MarcusDenker.28 > Author: MarcusDenker > Time: 9 September 2010, 5:49:34 pm > UUID: 4821aa22-5ca5-4973-9c18-df0b1bb0297f > Ancestors: OpalCompiler-Tests-MarcusDenker.27 > > more tests... > > ==================== Summary ==================== > > Name: OpalCompiler-Tests-MarcusDenker.27 > Author: MarcusDenker > Time: 9 September 2010, 5:09:43 pm > UUID: 49dfe8ab-d8af-4b61-9bcc-066fcf7e5aa0 > Ancestors: OpalCompiler-Tests-JorgeRessia.26 > > fix tests... > > ==================== Summary ==================== > > Name: OpalCompiler-Core-MarcusDenker.30 > Author: MarcusDenker > Time: 9 September 2010, 5:09:27 pm > UUID: 2485ef0c-25fe-4863-bd49-fad1aaa0f8bc > Ancestors: OpalCompiler-Core-jb.29, OpalCompiler-Core-JorgeRessia.29 > > more work for scope analysis... > -> after variables are re-looked up, add copying temps to outer scop > -> Fixes > > ==================== Summary ==================== > > Name: OpalCompiler-Tests-JorgeRessia.26 > Author: JorgeRessia > Time: 7 September 2010, 9:29:08 pm > UUID: 4def3fb1-2057-45fe-b7f7-62f057c999fb > Ancestors: OpalCompiler-Tests-MarcusDenker.25 > > - Introduction of optimized block scopes. > - the closure analysis is been moved out of the astchecker > > ==================== Summary ==================== > > Name: OpalCompiler-Core-JorgeRessia.29 > Author: JorgeRessia > Time: 7 September 2010, 9:28:46 pm > UUID: 02e0a230-43fb-4c08-97f2-a767968faaf8 > Ancestors: OpalCompiler-Core-MarcusDenker.28 > > - Introduction of optimized block scopes. > - the closure analysis is been moved out of the astchecker > > ==================== Summary ==================== > > Name: OpalCompiler-Core-jb.29 > Author: jb > Time: 7 September 2010, 11:31:01 am > UUID: 06331cc1-732f-4e49-8327-1d6eef92bf26 > Ancestors: OpalCompiler-Core-MarcusDenker.28 > > Fix some bug about Jump in decompiler and clean a bit the code. > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Sept. 9, 2010

[ANN] OPAL Digest

by StÃ©phane Ducasse

hi guys Since Opalers are working hard in the shadow, I thought that I can do a little digest for them. Each time I will delete ten entries I will do a small digest. Thanks marcus, Jorge and JB for their time and energy. Stef PS: OPAL is the new compiler framework we will have in 1.3. Really cool. OPAL comes from the Opal coast near to lille with cool dunes and birds. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.33 Author: MarcusDenker Time: 9 September 2010, 8:12:20 pm UUID: beb4fce5-38ef-4ff1-ba41-924245ff6456 Ancestors: OpalCompiler-Core-MarcusDenker.32 - cleanups (unsent methods) - make sure to hand over array of copiedTemos to IRBuilder, not Set. final one for today... things start to work. Failing tests down to 24 (from 40). TestCoverage 81% ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.29 Author: MarcusDenker Time: 9 September 2010, 7:47:08 pm UUID: aa19bd88-0895-4ab8-b55c-3f62f1698e33 Ancestors: OpalCompiler-Tests-MarcusDenker.28 - ASTChecker tests does not use verifyin, but just the ASTChecker - misc changes ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.32 Author: MarcusDenker Time: 9 September 2010, 7:46:21 pm UUID: 845092d2-e58f-441a-9304-43106311e5a1 Ancestors: OpalCompiler-Core-MarcusDenker.31 -> ASTTraslator now requests a tempVector from IRBuilder if needed -> simplified ASTClosureAnalyzer --> moved code to block/method scope -> tempVector now is not a temp anymore, just a copying one if needed -> verifyIn: now calls both visitors. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.31 Author: MarcusDenker Time: 9 September 2010, 5:49:20 pm UUID: ab2dc77f-71b4-4f82-9cb4-4a2c1261e3fe Ancestors: OpalCompiler-Core-MarcusDenker.30 - simplify a bit re-lookup of variables in OCASTClosureAnalyzer - scopes now have a unique name after ASTChecker pass (this is then used as the name of the vector) ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.28 Author: MarcusDenker Time: 9 September 2010, 5:49:34 pm UUID: 4821aa22-5ca5-4973-9c18-df0b1bb0297f Ancestors: OpalCompiler-Tests-MarcusDenker.27 more tests... ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.27 Author: MarcusDenker Time: 9 September 2010, 5:09:43 pm UUID: 49dfe8ab-d8af-4b61-9bcc-066fcf7e5aa0 Ancestors: OpalCompiler-Tests-JorgeRessia.26 fix tests... ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.30 Author: MarcusDenker Time: 9 September 2010, 5:09:27 pm UUID: 2485ef0c-25fe-4863-bd49-fad1aaa0f8bc Ancestors: OpalCompiler-Core-jb.29, OpalCompiler-Core-JorgeRessia.29 more work for scope analysis... -> after variables are re-looked up, add copying temps to outer scop -> Fixes ==================== Summary ==================== Name: OpalCompiler-Tests-JorgeRessia.26 Author: JorgeRessia Time: 7 September 2010, 9:29:08 pm UUID: 4def3fb1-2057-45fe-b7f7-62f057c999fb Ancestors: OpalCompiler-Tests-MarcusDenker.25 - Introduction of optimized block scopes. - the closure analysis is been moved out of the astchecker ==================== Summary ==================== Name: OpalCompiler-Core-JorgeRessia.29 Author: JorgeRessia Time: 7 September 2010, 9:28:46 pm UUID: 02e0a230-43fb-4c08-97f2-a767968faaf8 Ancestors: OpalCompiler-Core-MarcusDenker.28 - Introduction of optimized block scopes. - the closure analysis is been moved out of the astchecker ==================== Summary ==================== Name: OpalCompiler-Core-jb.29 Author: jb Time: 7 September 2010, 11:31:01 am UUID: 06331cc1-732f-4e49-8327-1d6eef92bf26 Ancestors: OpalCompiler-Core-MarcusDenker.28 Fix some bug about Jump in decompiler and clean a bit the code.

Sept. 9, 2010