[Etoys] Fwd: MO reader

[Takashi Yamamiya]

Thanks Bert,

To translators:

Before I change the structure of gettext files (maybe nothing happens
for a while though,) I will notice about it to this email list,
then merge all translation files in launchpad and trac, and export
them again. I think we don't lose any translation,
so please continue to translate whatever this discussion goes.

Cheers,
- Takashi

Bert Freudenberg wrote:
> 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.