[Babel] Looking for more translatorsDaniel Vainsencher danielv at netvision.net.ilSat Sep 27 11:23:37 UTC 2003
I like this general approach of reducing the number of calls by making the frameworks translation aware, so the applications don't have to be. It seems that most of the interface text is in the menus, and a little in SystemWindow titles, and the rest in contents of application specific text panes. I say we play with this a little more and after we've more or less minimized the changes to application code, we roll it in for 3.7. Going for a translatable 3.7 release sounds great to me :-) Daniel Scott Wallace <scott.wallace at squeakland.org> wrote: > > --Boundary_(ID_7cNuH4vSI9PcB13Qj0o8vA) > Content-type: multipart/alternative; > boundary="Boundary_(ID_PcHzox2bVQDs5Ff4/Xo7jg)" > > > --Boundary_(ID_PcHzox2bVQDs5Ff4/Xo7jg) > Content-type: text/plain; charset=us-ascii; format=flowed > Content-transfer-encoding: 7BIT > > Generic Translation > ------- ----------- > > While still retaining Diego's basic mechanisms and approach, we could > reduce the existing Babel corpus from its current 500 methods to a > much smaller number. > > Instead of requiring hundreds of modifications all over the image -- > all those insertions of calls to #translated -- why not push the > #translated calls up into a handful of generic methods commonly > invoked by clients? > > An obvious area that would benefit from this approach is the wording > of menu items, and that's all I'll discuss below. Another area that > could similarly benefit is Commands (a one-word change to one Command > method would make all 16 methods currently in the Babel change-set > that deals with Command translation unnecessary,) and my sense is > that the same generic approach to textual-UI translation should work > just about anywhere that there is textual UI to translate. > > > Menus > ----- > > If we are rendering the Squeak UI in a different language, then, by > and large, every piece of textual UI that we present ought to be > rendered in that language, whenever there is a translation available. > > This suggests that the most commonly-used generic Menu mechanisms > should *assume* that translation is wanted, and should act > accordingly. (Of course we would also provide variant protocols to > avoid translation where it is not wanted, such as in a menu of > file-names, or of window titles, or of names of people. More on this > below.) > > The Babel change-set "0045morphMenusTranslation-dgd" has 160 methods > in it -- comprising roughly a third of all the Babel code thus far. > If we were to push the #translated call up into a single generic > menu-creation method, few of those 160 changes would be needed. > > What I'm suggesting is changing the deepest MenuMorph construction > method, #add:target:selector:argumentList:, which is ultimately > called by the other constructors, from its current implementation: > > add: aString target: target selector: aSymbol argumentList: argList > "Append a menu item with the given label..." > | item | > item _ MenuItemMorph new > contents: aString; > target: target; > selector: aSymbol; > arguments: argList asArray. > self addMorphBack: item. > > > to include its own call to #translated -- thus: > > add: aString target: target selector: aSymbol argumentList: argList > "Append a menu item whose label is the given string > translated into the current natural language..." > | item | > item _ MenuItemMorph new > contents: aString translated; > target: target; > selector: aSymbol; > arguments: argList asArray. > self addMorphBack: item. > > > "Do-Not-Translate" variants > -- --- --------- -------- > > Of course, some cases are not so simple, such as where the wording is > constructed by concatenation (though the updating-menu-item case has > its own generic solution -- see below,) and generally anywhere that > the translation needs to kick in at a level other than on the full > item wording. > > If we establish generic translation as the default, thus dealing > seamlessly with most cases, we would want to offer "do-not-translate" > variants of the standard menu constructors for use in cases where the > generic menu translation does not serve our purposes; junctures that > require the do-not-translate variants would have to be changed > manually, but this amounts to writing special-case code only for the > special-cases, which seems fair. > > For this, we would provide methods of the following form in MenuMorph: > > addWithoutTranslation:target:selector:argument: > addWithoutTranslation:action: > addWithoutTranslation:selector:argument: > addWithoutTranslation:selector:argumentList: > addWithoutTranslation:subMenu: > addWithoutTranslation:subMenu:target:selector:argumentList: > > > Dynamically-updating menu items > ----------- -------- ---- ----- > > Here, most cases can be transparently handled by changing the line in > MenuMorph method #contents:withMarkers:inverse: that currently reads > > super contents: indent, (aString copyFrom: markerIndex+1 to: > aString size). > > so that instead it reads > > super contents: indent, (aString copyFrom: markerIndex+1 to: > aString size) translated. > > ------------------------------------------------------------- > > ... or has this generic approach to textual-UI translation already > been discussed and rejected? Perhaps there are fears that the > potential gotchas will outweigh the potential gains? > > > Cheers, > > -- Scott > > > At 3:55 PM -0500 9/25/03, <diegogomezdeck at consultar.com> wrote: > >Hi Stef, > > > >> I'm evaluating the effort and we are discussing about it with serge and > >> others. > >> The idea is that we would like to have a Squeak in french. But I would > >> like to know > >> if this effort will not be thrown away when new balloon help and other > >> new english text > >> will be included. I guess not but could you explain us how you see that > >> situation. > > > >The biggest risk in my eyes is if Babel get not included in Squeak. Babel > >is an almost trivial piece of code but it impacts all over Squeak. > >Basically each "visible" string has to received the #translated message and, > >as you can imagine, it means changes all over the image. > > > >The translations are hold in each language instance in a dictionary and we > >have support for merging dictionaries, etc. so the risk is not at this part. > > > >One time Babel got included in Squeak every package maintainer can make the > >package "translatable" just sending #translated to the gui's strings. > > > >I'd like to know which type of opportunity (if any) Babel has to be included > >for 3.7. What the guides think about? What the other potential translators > >do? > > > >> Stef > > > >As you can see I have more questions than answers. > > > >Cheers, > > > >Diego > >http://www.small-land.org > > --Boundary_(ID_PcHzox2bVQDs5Ff4/Xo7jg) > Content-type: text/html; charset=us-ascii > Content-transfer-encoding: 7BIT > > <!doctype html public "-//W3C//DTD W3 HTML//EN"> > <html><head><style type="text/css"><!-- > blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } > --></style><title>Re: [Babel] Looking for more > translators</title></head><body> > <div>Generic Translation</div> > <div>------- -----------</div> > <div><br></div> > <div>While still retaining Diego's basic mechanisms and approach, we > could reduce the existing Babel corpus from its current 500 methods to > a much smaller number.</div> > <div><br></div> > <div>Instead of requiring hundreds of modifications all over the image > -- all those insertions of calls to #translated -- why not push the > #translated calls up into a handful of generic methods commonly > invoked by clients?</div> > <div><br></div> > <div>An obvious area that would benefit from this approach is the > wording of menu items, and that's all I'll discuss below. > Another area that could similarly benefit is Commands (a one-word > change to one Command method would make all 16 methods currently in > the Babel change-set that deals with Command translation unnecessary,) > and my sense is that the same generic approach to textual-UI > translation should work just about anywhere that there is textual UI > to translate.</div> > <div><br></div> > <div><br></div> > <div>Menus</div> > <div>-----</div> > <div><br></div> > <div>If we are rendering the Squeak UI in a different language, then, > by and large, every piece of textual UI that we present ought to be > rendered in that language, whenever there is a translation > available.</div> > <div><br></div> > <div>This suggests that the most commonly-used generic Menu mechanisms > should *assume* that translation is wanted, and should act > accordingly. (Of course we would also provide variant protocols > to avoid translation where it is not wanted, such as in a menu of > file-names, or of window titles, or of names of people. More on > this below.)</div> > <div><br></div> > <div>The Babel change-set "0045morphMenusTranslation-dgd" > has 160 methods in it -- comprising roughly a third of all the Babel > code thus far. If we were to push the #translated call up into a > single generic menu-creation method, few of those 160 changes would be > needed.</div> > <div><br></div> > <div>What I'm suggesting is changing the deepest MenuMorph > construction method, #add:target:selector:argumentList:, which is > ultimately called by the other constructors, from its current > implementation:</div> > <div><br></div> > <div><b>add: aString target: target selector: aSymbol argumentList: > argList</b></div> > <div><x-tab> > </x-tab>"Append a menu item with the given label..."<br> > <x-tab> </x-tab>| item |<br> > <x-tab> </x-tab>item _ > MenuItemMorph new<br> > <x-tab> > </x-tab><x-tab> > </x-tab>contents: aString;<br> > <x-tab> > </x-tab><x-tab> > </x-tab>target: target;<br> > <x-tab> </x-tab><x-tab> > </x-tab>selector: aSymbol;<br> > <x-tab> > </x-tab><x-tab> > </x-tab>arguments: argList asArray.</div> > <div><x-tab> </x-tab>self > addMorphBack: item.</div> > <div><br></div> > <div><br></div> > <div>to include its own call to #translated -- thus:</div> > <div><br></div> > <div><b>add: aString target: target selector: aSymbol argumentList: > argList</b></div> > <div><x-tab> > </x-tab>"Append a menu item whose label is the given string > translated into the current natural language..."</div> > <div><x-tab> </x-tab>| item > |<br> > <x-tab> </x-tab>item _ > MenuItemMorph new</div> > <div><x-tab> > </x-tab><x-tab> > </x-tab>contents: aString<font color="#FF0000"> > translated</font>;</div> > <div><x-tab> > </x-tab><x-tab> > </x-tab>target: target;<br> > <x-tab> </x-tab><x-tab> > </x-tab>selector: aSymbol;<br> > <x-tab> > </x-tab><x-tab> > </x-tab>arguments: argList asArray.</div> > <div><x-tab> </x-tab>self > addMorphBack: item.</div> > <div><br></div> > <div><br></div> > <div>"Do-Not-Translate" variants</div> > <div> -- --- --------- --------</div> > <div><br></div> > <div>Of course, some cases are not so simple, such as where the > wording is constructed by concatenation (though the updating-menu-item > case has its own generic solution -- see below,) and generally > anywhere that the translation needs to kick in at a level other than > on the full item wording.</div> > <div><br></div> > <div>If we establish generic translation as the default, thus dealing > seamlessly with most cases, we would want to offer > "do-not-translate" variants of the standard menu > constructors for use in cases where the generic menu translation does > not serve our purposes; junctures that require the do-not-translate > variants would have to be changed manually, but this amounts to > writing special-case code only for the special-cases, which seems > fair.</div> > <div><br></div> > <div>For this, we would provide methods of the following form in > MenuMorph:</div> > <div><br></div> > <div>addWithoutTranslation:target:selector:argument:</div> > <div>addWithoutTranslation:action:</div> > <div>addWithoutTranslation:selector:argument:</div> > <div>addWithoutTranslation:selector:argumentList:</div> > <div>addWithoutTranslation:subMenu:</div> > <div>addWithoutTranslation:subMenu:target:selector:argumentList:</div> > <div><br></div> > <div><br></div> > <div>Dynamically-updating menu items</div> > <div>----------- -------- ---- -----</div> > <div><br></div> > <div>Here, most cases can be transparently handled by changing the > line in MenuMorph method #contents:withMarkers:inverse: that > currently reads</div> > <div><br></div> > <div><x-tab> </x-tab>super > contents: indent, (aString copyFrom: markerIndex+1 to: aString > size).</div> > <div><br></div> > <div>so that instead it reads</div> > <div><br></div> > <div><x-tab> </x-tab>super > contents: indent, (aString copyFrom: markerIndex+1 to: aString size) > translated.</div> > <div><br></div> > <div>-------------------------------------------------------------</div > > > <div><br></div> > <div>... or has this generic approach to textual-UI translation > already been discussed and rejected? Perhaps there are fears > that the potential gotchas will outweigh the potential gains?</div> > <div><br></div> > <div><br></div> > <div>Cheers,</div> > <div><br></div> > <div> -- Scott</div> > <div><br></div> > <div><br></div> > <div>At 3:55 PM -0500 9/25/03, <diegogomezdeck at consultar.com> > wrote:</div> > <blockquote type="cite" cite>Hi Stef,<br> > <br> > > I'm evaluating the effort and we are discussing about it with > serge and<br> > > others.<br> > > The idea is that we would like to have a Squeak in french. But I > would<br> > > like to know<br> > > if this effort will not be thrown away when new balloon help and > other<br> > > new english text<br> > > will be included. I guess not but could you explain us how you > see that<br> > > situation.<br> > <br> > The biggest risk in my eyes is if Babel get not included in > Squeak. Babel<br> > is an almost trivial piece of code but it impacts all over Squeak.<br> > Basically each "visible" string has to received the > #translated message and,<br> > as you can imagine, it means changes all over the image.<br> > <br> > The translations are hold in each language instance in a dictionary > and we<br> > have support for merging dictionaries, etc. so the risk is not at this > part.<br> > <br> > One time Babel got included in Squeak every package maintainer can > make the<br> > package "translatable" just sending #translated to the gui's > strings.<br> > <br> > I'd like to know which type of opportunity (if any) Babel has to be > included<br> > for 3.7. What the guides think about? What the other potential > translators<br> > do?<br> > <br> > > Stef</blockquote> > <blockquote type="cite" cite><br></blockquote> > <blockquote type="cite" cite>As you can see I have more questions than > answers.</blockquote> > <blockquote type="cite" cite><br></blockquote> > <blockquote type="cite" cite>Cheers,</blockquote> > <blockquote type="cite" cite><br></blockquote> > <blockquote type="cite" cite>Diego</blockquote> > <blockquote type="cite" cite>http://www.small-land.org</blockquote> > <div><br></div> > </body> > </html> > > --Boundary_(ID_PcHzox2bVQDs5Ff4/Xo7jg)-- > > --Boundary_(ID_7cNuH4vSI9PcB13Qj0o8vA) > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > Content-transfer-encoding: 7BIT > > > > --Boundary_(ID_7cNuH4vSI9PcB13Qj0o8vA)--
More information about the Squeak-dev mailing list |