[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