Hi Bert,
--- Bert Freudenberg bert@freudenbergs.de wrote:
On Sep 20, 2007, at 16:00 , korakurider@yahoo.co.jp wrote:
Hi. I am writing a simple MO reader. First cut is
attached: I
don't care performance for now. I tested it with japanese MOs bundled with
Ruby-gettext
package, as I don't have gettext runtime to
compile POs
for EToys right now.
I think we need to decide for some design issues
to go
forward:
a) How to package MO from those highly fragmented
POs: how
many MOs will we have? what is assigned to
textdomain ?
I am not certain whether current packaging scheme
for POs
will be also good for MO/textdomain.
In typical usage textdomain represents
"application" and
translation is provided for each app.
Also note that this decision will affect design
for good
performance and resource usage.
The idea was to have one MO per class category, because the best equivalent to "applications" in Squeak are class categories. This way an MO file corresponds roughly to a Monticello Package, for example.
One problem is that the classes in the etoys image are not very nicely categorized - I think that was done in 3.8.1 but not 3.8. For example, there is a stray OLPC category which would better be merged with the Sugar category.
b) how to decide textdomain on #translated?
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.
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).
-------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/