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.