[etoys-dev] Re: Need for translation in DrGeo
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
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>
> >> 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
> (context 'EtoysVoca for tile wordings and 'EtoysHelpString' for balloon
> **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
> > 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
> > 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**
> to implement that, as currently translation is executed in very deep level
> call stack.
> My crazy idea is that each string itself knows its domain by marking
> but unfortunately it doesn't work for symbols :-<
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the etoys-dev