Hello people,
I am still looking for a way to mark, in image 3.8, string for translation? Does the procedure described at http://minnow.cc.gatech.edu/squeak/402 became obselete? At worst I will have to use directly local language string. Hilaire Fernandes |
Hilaire,
> I am still looking for a way to mark, in image 3.8, string for translation? > > Does the procedure described at http://minnow.cc.gatech.edu/squeak/402 > became obselete? > > At worst I will have to use directly local language string. I'm not exactly sure by "marking", but the closest thing would be: NaturalLanguageTranslator registeredPhraseFor: phrase. and then use the LanguageEditor. -- Yoshiki |
Yoshiki Ohshima a écrit : > Hilaire, > > >>I am still looking for a way to mark, in image 3.8, string for translation? >> >>Does the procedure described at http://minnow.cc.gatech.edu/squeak/402 >>became obselete? >> >>At worst I will have to use directly local language string. > > > I'm not exactly sure by "marking", but the closest thing would be: The only localisation system I know is gettext, in this system the string to translate are marked directly in the source code (with a special function as _()). Next, such marked strings can be grouped in the translation file for the translator. I was thinking about something to get the same effect (i.e. get the string ready to be translated) > > NaturalLanguageTranslator registeredPhraseFor: phrase. > > and then use the LanguageEditor. Ok. Will it be possible to group strings in one independant package (I don't know in which form), so it can be moved allong the application classes. Otherwise I am afraid the marked string for translation could be very esily loose as I guess they may be dependant on the image. Hilaire Fernandes > > -- Yoshiki > > |
Am 19.02.2006 um 20:50 schrieb Hilaire Fernandes:
>>> http://minnow.cc.gatech.edu/squeak/402 > The only localisation system I know is gettext, in this system the > string to translate are marked directly in the source code (with a > special function as _()). Next, such marked strings can be grouped in > the translation file for the translator. > > I was thinking about something to get the same effect (i.e. get the > string ready to be translated) Just send #translated, as mentioned on the wiki page above. - Bert - |
Bert Freudenberg a écrit :
> Am 19.02.2006 um 20:50 schrieb Hilaire Fernandes: > >>>> http://minnow.cc.gatech.edu/squeak/402 > > >> The only localisation system I know is gettext, in this system the >> string to translate are marked directly in the source code (with a >> special function as _()). Next, such marked strings can be grouped in >> the translation file for the translator. >> >> I was thinking about something to get the same effect (i.e. get the >> string ready to be translated) > > > Just send #translated, as mentioned on the wiki page above. Yes, this I already know but it is not sufficient. As Yoshiki suggested I also need to add each string in the translation dictionnary. What would be helpfull is to have a separate translation dictionnary for each package. As far as I can understand, there is for now one big dictionnary to record the string for translation (NaturalLanguageTranslator allKnownPhrases). Hilaire > > - Bert - > > -- ADD R0,R1,R2,LSL #2 |
hilaire
you are right. A dictionary per package is needed. This is also an indication that having first class package would help to attach to them resources. (argh I do not have the time to look at that). I will try to dig into what alex did to introduce first class packages and see how far he was. Stef On 20 févr. 06, at 09:52, Hilaire Fernandes wrote: > Bert Freudenberg a écrit : >> Am 19.02.2006 um 20:50 schrieb Hilaire Fernandes: >>>>> http://minnow.cc.gatech.edu/squeak/402 >>> The only localisation system I know is gettext, in this system the >>> string to translate are marked directly in the source code (with a >>> special function as _()). Next, such marked strings can be >>> grouped in >>> the translation file for the translator. >>> >>> I was thinking about something to get the same effect (i.e. get the >>> string ready to be translated) >> Just send #translated, as mentioned on the wiki page above. > > Yes, this I already know but it is not sufficient. As Yoshiki > suggested I also need to add each string in the translation > dictionnary. > > What would be helpfull is to have a separate translation > dictionnary for each package. > > As far as I can understand, there is for now one big dictionnary to > record the string for translation (NaturalLanguageTranslator > allKnownPhrases). > > Hilaire > > >> - Bert - > > > -- > ADD R0,R1,R2,LSL #2 > |
What is first class package?
Hilaire stéphane ducasse a écrit : > hilaire > > you are right. A dictionary per package is needed. > This is also an indication that having first class package would help > to attach to them resources. > (argh I do not have the time to look at that). I will try to dig into > what alex did to introduce > first class packages and see how far he was. > > Stef > > > On 20 févr. 06, at 09:52, Hilaire Fernandes wrote: > >> Bert Freudenberg a écrit : >> >>> Am 19.02.2006 um 20:50 schrieb Hilaire Fernandes: >>> >>>>>> http://minnow.cc.gatech.edu/squeak/402 >>>> >>>> The only localisation system I know is gettext, in this system the >>>> string to translate are marked directly in the source code (with a >>>> special function as _()). Next, such marked strings can be grouped in >>>> the translation file for the translator. >>>> >>>> I was thinking about something to get the same effect (i.e. get the >>>> string ready to be translated) >>> >>> Just send #translated, as mentioned on the wiki page above. >> >> >> Yes, this I already know but it is not sufficient. As Yoshiki >> suggested I also need to add each string in the translation dictionnary. >> >> What would be helpfull is to have a separate translation dictionnary >> for each package. >> >> As far as I can understand, there is for now one big dictionnary to >> record the string for translation (NaturalLanguageTranslator >> allKnownPhrases). >> >> Hilaire >> >> >>> - Bert - >> >> >> >> -- >> ADD R0,R1,R2,LSL #2 >> > > -- ADD R0,R1,R2,LSL #2 |
If you look how package are right now implemented they are a facade
on the class category (the way Smalltalk sort classes). But they are not real object. For example, we cannot have package level comment to attach description. I do not know how postload actions are specified but this would make sense to me to edit a package method and get sure that once all the classes are loaded the package method is executed. Having package as real entity would help. We could put resources there too. RIght now you can do the same but in a none organized manner everybody can decide to have one class in the package having an initialize method or having class methods to handle resources but this is not consistent. Stef On 20 févr. 06, at 17:38, Hilaire Fernandes wrote: > What is first class package? > > Hilaire > > > stéphane ducasse a écrit : >> hilaire >> you are right. A dictionary per package is needed. >> This is also an indication that having first class package would >> help to attach to them resources. >> (argh I do not have the time to look at that). I will try to dig >> into what alex did to introduce >> first class packages and see how far he was. >> Stef >> On 20 févr. 06, at 09:52, Hilaire Fernandes wrote: >>> Bert Freudenberg a écrit : >>> >>>> Am 19.02.2006 um 20:50 schrieb Hilaire Fernandes: >>>> >>>>>>> http://minnow.cc.gatech.edu/squeak/402 >>>>> >>>>> The only localisation system I know is gettext, in this system the >>>>> string to translate are marked directly in the source code (with a >>>>> special function as _()). Next, such marked strings can be >>>>> grouped in >>>>> the translation file for the translator. >>>>> >>>>> I was thinking about something to get the same effect (i.e. get >>>>> the >>>>> string ready to be translated) >>>> >>>> Just send #translated, as mentioned on the wiki page above. >>> >>> >>> Yes, this I already know but it is not sufficient. As Yoshiki >>> suggested I also need to add each string in the translation >>> dictionnary. >>> >>> What would be helpfull is to have a separate translation >>> dictionnary for each package. >>> >>> As far as I can understand, there is for now one big dictionnary >>> to record the string for translation (NaturalLanguageTranslator >>> allKnownPhrases). >>> >>> Hilaire >>> >>> >>>> - Bert - >>> >>> >>> >>> -- >>> ADD R0,R1,R2,LSL #2 >>> > > > -- > ADD R0,R1,R2,LSL #2 > |
In reply to this post by Hilaire Fernandes-5
Hilaire,
There is an extension of LanguageEditor that lets you save the selected entries in the LanguageEditor into a do-it expression. If you copy the do-it to a postscript of a change set or such, you can make a single package with the code and translations. (Again, the extension is only in Squeakland... Sorry.) -- Yoshiki |
I am afraid I don't understand the feature you described for the
LanguageEditor. So now, I start to realize that Squeak != Squeakland, is it that? At least, is there any common code repository or not? Also if Squeak != Squeakland, I think I understand more or less how is developped Squeak, but what about Squeakland. After all, most email exchange in this list is related to Squeak, and in the Squeakland list it is more end-user, but I think I never see email exchange about how Squeakland is developped. Looks like there are many things I don't understand in development model of Squeak and Squeakland. Worst I am confused, I am developping a dynamic geometry framework. To do so I just use a basic Squeak 3.8 image, but I also want it to be useable in Squeakland. Hilaire Fernandes Yoshiki Ohshima a écrit : > Hilaire, > > There is an extension of LanguageEditor that lets you save the > selected entries in the LanguageEditor into a do-it expression. If > you copy the do-it to a postscript of a change set or such, you can > make a single package with the code and translations. > > (Again, the extension is only in Squeakland... Sorry.) > > -- Yoshiki > > -- ADD R0,R1,R2,LSL #2 |
In reply to this post by stéphane ducasse-2
Il giorno lun, 20/02/2006 alle 10.18 +0100, stéphane ducasse ha scritto:
> hilaire > > you are right. A dictionary per package is needed. > This is also an indication that having first class package would help > to attach to them resources. > (argh I do not have the time to look at that). I will try to dig into > what alex did to introduce > first class packages and see how far he was. > An Application abstraction would be good, too. Giovanni |
Free forum by Nabble | Edit this page |