[etoys-dev] Re: Need for translation in DrGeo

Ricardo Moran richi.moran at gmail.com
Mon May 17 15:05:26 EDT 2010

Thanks! Now I understand a lot better why I wasn't able to translate the

I don't understand what you're saying about each string knowing its domain
by marking it #translatedNoop.
What is the usage of #translatedNoop currently? I see that it has an empty
implementation so I guess it's just used to mark strings but when are those
strings translated?


On Sun, May 16, 2010 at 11:21 PM, Korakurider <korakurider at gmail.com> wrote:

> Hi Ricardo.
> On Sun, May 16, 2010 at 9:30 AM, Ricardo Moran <richi.moran at gmail.com>
> wrote:
> >> This is known problem of current implementation.  Translation stuff is
> >> assuming all of tile strings belong to default domain.
> >
> > Hi, where is the code for translating the viewer tiles? I mean: where is
> > #translated called?
> Please review changesets in proto1.zip attached to SQ-139, especially
> senders of #translatedWithContext: in
> ex1VocaCore-KR/ex2Voca-KR/ex4Halo-KR.
> (context 'EtoysVoca for tile wordings and 'EtoysHelpString' for balloon
> helps)
> **This is snapshot of my experiment to implement msgctxt of gettext ;
> the goal was close to what you are trying.
> > Because I was thinking we may want to modify it to ask it's text domain
> to
> > the player. We can have something like
> > Player>>defaultTextDomain
> >     ^'Etoys-tiles'
> > and if I make a project with a different set of tiles I can subclass
> Player
> > and define my own text domain. I know this is not important for the DrGeo
> > case because it will be included in the image but for future tools we may
> > have to do something about it.
> Your idea is interesting, but it seems Etoys code will need **huge**
> overhaul
> to implement that, as currently translation is executed in very deep level
> of
> call stack.
> My crazy idea is that each string itself knows its domain by marking
> #translatedNoop,
> but unfortunately it doesn't work for symbols :-<
> /Korakurider
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100517/5d3b0075/attachment.html

More information about the etoys-dev mailing list