[Etoys] Fwd: MO reader
korakurider at yahoo.co.jp
Fri Sep 21 04:51:59 EDT 2007
--- Bert Freudenberg <bert at freudenbergs.de> wrote:
> On Sep 21, 2007, at 6:19 , korakurider wrote:
> > Hi Bert,
> > --- Bert Freudenberg <bert at freudenbergs.de> wrote:
> >> Based on the category of the sender of
> >> translated
> >> | classAndSelector category |
> >> classAndSelector := thisContext sender who.
> >> category := classAndSelector first category.
> >> This is rather inefficient, when loading an MO
> >> we might want to
> >> create a cache for looking up the category from
> >> CompiledMethod
> >> directly.
> > I think it would be safe to implement like this
> > receiver of #translated is literal.
> > But how about #translatedNoop? I am not sure if
> > of #translated and #translatedNoop have same
> You misunderstood - the lookup is independent of the
> *receiver* it
> only looks at the *sender*, that is, the method in
> which the
> #translated or #translatedNoop send happens.
> Or did I misunderstood your question?
I think I understood correctly. The lookup decides
translation context (i.e. textdomain) by class category
of sender of #translated. (#translatedNoop is just for
extraction of original phrase, and isn't directly related
But when exporting receiver literal of #translatedNoop to
PO, that category is based on not #translated but
Then what if senders of #translated and #translatedNoop
are diffrent class with different class category?
> >>> c) Where will MO reside in runtime environment?
> >> In a subdirectory of "Smalltalk imagePath".
> >>> I am thinking about squeakland-OLPC with
> >> SecurityPlugin
> >>> enabled.
> >>> (Is security plugin enabled on XO ?)
> >> We might need to add an exception to the
> >> SecurityPlugin allowing to
> >> read from the po path. On the XO we don't really
> >> have to enable it,
> >> but the same translations should work on the
> >> etoys.
> > I agree it is needed to tweak SecurityPlugin.
> > SecurityPlugin doesn't differentiate access modes
> > only or read/write), just allow/disallow file
> access. So
> > It would need major work on plugin/VM of each
> > to support that exception.
> > (Just arrowing file access under imagePath should
> > dangerous).
> That is true unfortunately.
> Maybe building a gettext plugin linking to libintl.a
> is indeed the
> best solution. Other ideas?
I think original GNU gettext implementation assumes
that application doesn't use multiple textdomains (i.e.
MOs) simultanaously. If multiple textdomains are need,
application must switch dynamically. I imagine frequet
switching will cause performance degration. So I am not
sure using libintl.a would be appropriate if we will have
Ruby-gettext package that I reviewed during writing my
sample code is not binding to libintl.a, but gettext
compliant implementation written in Ruby. And the
implementation can handle multiple MOs simultanaously. I
would ike to go similar way if possible.
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
More information about the Etoys