[Etoys] Fwd: MO reader

[Bert Freudenberg]

Yes that sounds good. Let's try.

- Bert -

On Sep 20, 2007, at 21:34 , Takashi Yamamiya wrote:

> Hi Korakurider, Bert,
>
> This is a great work! The source code helps a lot to understand the
> structure of mo file. I'm glad that it is so simple (I was
> questionable to support mo file before looking at the code).  I think
> it is greater if you upload it as a ticket for someone who are
> interested in mo file (or, I can do with your permission).
>
> Anyway, I have an idea about fragmentation of po files. We have
> divided translations because there are too many words in eToys. But if
> we sort words into reasonable way as Bert's idea, "Sorting in pot
> files" https://dev.laptop.org/ticket/3596, we don't need to divide
> translations, do we? A translator can work any reasonable fragment  
> in a
> big PO file sorted by class category, class, and method.
>
> My frustration of many PO files comes from:
>
> - Some words will be placed in two or more po files, and conflict if
>  those files have different translations. This will be solved by
>  using thisContext technically, but a translator have no idea which
>  textdomain is used for a word on the screen without looking into
>  Smalltalk code.
>
> - Now, there are 406 po and pot files. And it will increase. It is not
>  difficult to manage it, but hard to keep my attention to avoid a
>  small mistake. Honestly, boring...
>
> I totally agree to support textdomain for eToys application. So my
> proposal is only registered class categories are considered as other
> textdomains, rest are in a big po file. I'm sorry if it confuses the
> last agreed discussion.
>
> Cheers,
> - Takashi
>
>>> 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.
>