Hi, I've been playing with the translation framework and I did the simplest thing I could think of: splitting the translations based on the package of each class. I'm sure you already know all of this but in the latest etoys-dev image I get the following info (package name - number of translations):

Morphic 984
MorphicExtras 397
Etoys 358
Connectors 174
System 130
Tools 105
WS 80
Sound 70
Movies 60
Sugar 56
GStreamer 43
Multilingual 42
VideoForSqueak 41
Nebraska 29
Protocols 26
Flash 20
Network 18
Kernel 17
ST80 17
Graphics 15
Compression 8
Collections 7
Files 6
Monticello 4
BroomMorphs 3
Balloon 3
UserObjects 1
DAVServerDirectory 1
TrueType 1
SMLoader 1
FSM 1

One possible (and easy) division could be something like this:
Morphic 984
MorphicExtras 397
Etoys 358
Connectors 174
System 130
Tools 105
others 570

I know this is not the best criteria but IMHO this is better than nothing. Maybe we should keep splitting the Morphic package, I don't know. I have some questions though: what would be an appropriate size for each po file and how many files are desirable?

Cheers
Richo

P.s.: I attached the script I used to get the above mentioned data (I may have made a mistake).

On Wed, Apr 28, 2010 at 9:21 PM, Ricardo Moran <richi.moran@gmail.com> wrote:
Great! Thanks for the explanation and the pointers, I'll look into it. I see that a lot of code is already there, that's a huge relief for me :)

Best regards
Richo


On Wed, Apr 28, 2010 at 3:34 AM, Korakurider <korakurider@gmail.com> wrote:
Hi Ricardo.
I haven't noticed this requirement is covered in the GSoC project.
Here are starting point.

1. Background
    In Etoys image translation support based on gettext emulation has
been implemented.
    (You need to know basic concept of gettext; see
http://www.gnu.org/software/gettext/)

    + POT Extraction:    see class comment of GetTextExporter2
    + Translation Engine:  see #translated
                                            and
NaturalLanguageTranslator/GetTextTranslator

2. Problem
    Current implementation is that all strings belong to the
textdomain "etoys".
    By this huge number of strings (>4000) are included in one big PO/POT and
    translators have difficulty to translate it.   We need to divide
it to a few text domains with appropriate size and inclusion
criteria/packaging scheme.

    Actually the translation framework have feature to mark class
category for some text domain. (review class side of
TextDomainManager)
But this has not been used because:
  + We haven't got agreement on what division would be good
  + There is risk that the framework cannot decide correct textdomain
in some case.
     (see #translated)
  + So we couldn't implement the division in timeline of the past project.

3. Related problem
  SQ-139 in etoys bug tracker.

/Korakurider


On Wed, Apr 28, 2010 at 11:27 AM, Ricardo Moran <richi.moran@gmail.com> wrote:
> Hi guys,
> I'm starting to work on the translation support for GSoC and since I know
> nothing of how it is implemented and I'm already delayed in the timeline I
> wanted to ask you if you have any pointers on what/where should I look.
> Thanks in advance!
> Richo
> _______________________________________________
> etoys-dev mailing list
> etoys-dev@squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>