[Babel] Looking for more translators
Scott Wallace
scott.wallace at squeakland.org
Sat Sep 27 01:15:35 UTC 2003
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030926/315ebd24/attachment.htm
More information about the Squeak-dev
mailing list
|