[Etoys] Fwd: MO reader

[korakurider]

--- 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:
> >>
> >> 	translated
> >> 		| classAndSelector category |
> >> 		classAndSelector := thisContext sender who.
> >> 		category := classAndSelector first category.
> >>
> >> This is rather inefficient, when loading an MO
> file
> >> we might want to
> >> create a cache for looking up the category from
> the
> >> CompiledMethod
> >> directly.
> >   I think it would be safe to implement like this
> if
> > receiver of #translated is literal.
> >   But how about #translatedNoop?  I am not sure if
> senders
> > of #translated and #translatedNoop have same
> category.
> 
> 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
to lookup) 
But when exporting receiver literal of #translatedNoop to
PO, that category is based on not #translated but
#translatedNoop. 
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
> regular
> >> etoys.
> >    I agree it is needed to tweak SecurityPlugin.
> But
> > SecurityPlugin doesn't differentiate access modes
> (read
> > only or read/write), just allow/disallow file
> access.  So
> > It would need major work on plugin/VM of each
> architecture
> > to support that exception.
> > (Just arrowing file access under imagePath should
> be
> > 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
multiple MOs.  
  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.

/Korakurider

--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/