<!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@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>