Fixing around GetText

On 28.03.2012, at 11:12, Edgar J. De Cleene wrote:

> On 3/27/12 10:07 PM, "Chris Muller" <[hidden email]> wrote:
>
>> which now blows up our image build
>
> Not doing update from 11925.image.
> Just now I reach  11959 and have yours GetText-cmm.19
>
> Still have Undeclared and still none answers to my questions about which of
> Etoys we want in trunk.

Hi Edgar,

I didn't know you were waiting on someone. Well, time for a longer message then.

We want to abandon the Etoys code fork. At some point in the future, we want to build an Etoys release from a Trunk image.

So "which of Etoys"? All that is needed to load and use current Etoys projects nicely. A trunk-based Etoys release would need to work at least as well as the previous versions (and will hopefully be better).

It doesn't have to work exactly the same, though. It should be cleaner and faster :)

As for GetText, maybe the best would be to not have this in a separate package. At the very least we need to move Locale etc. back into the "System" package. In Etoys, GetText had 7 classes, in Trunk you made it 15. The idea was to have NaturalLanguageTranslator as abstract superclass for translation services, and have the old InternalTranslator and the new GetTextTranslator as concrete subclasses.

We need to decide if keeping the old InternalTranslator around is necessary. I don't know anyone who is using it, so my suggestion would be to discard it.

Here is my break-down of the classes currently in your GetText package:

System
       Locale - move back to System pkg
       LocaleID - move back to System pkg
       ISOLanguageDefinition - move back to System pkg

Translation core (needed at runtime)
       NaturalLanguageTranslator - abstract superclass
       NaturalLanguageFormTranslator - for translatable bitmaps
       GetTextTranslator - looks up translation in MO file
       MOFile - parses MO files
       TextDomainManager - needed at runtime

Utilities (not needed at runtime)
       GetTextExporter: collects strings from image and writes out POT files
       TranslatedReceiverFinder - needed by exporter
       GetTextInterchange - superclass for importer
       GetTextImporter - loads PO files, only used by exporter and editor
       LanguageEditor - interface for editing translations (not currently used, but may be useful)
       GetTextExporter2 - delete (I wonder why is this back?)

Here's the current sizes:

{NaturalLanguageTranslator. NaturalLanguageFormTranslator. GetTextTranslator. MOFile. TextDomainManager} collect: #linesOfCode
==> #(418 49 135 223 60)

{GetTextExporter. TranslatedReceiverFinder. GetTextInterchange. GetTextImporter. LanguageEditor} collect: #linesOfCode
==> #(408 190 8 163 1073)

The Locale classes need to move back to the System package. My suggestion would be to move the "Translation core" classes into the System package as well, and keep only the "Utilities" in the GetText package, which then can easily be unloaded.

And please clean up the GetTextExporter/GetTextExporter2 mess. I have no idea how that happened. You should have started from the latest Etoys package, not from some old package. I have a hunch you used Hilaire's GetText package for Pharo? This is apparently based on old Etoys code.

Here is a diff between your GetText-edc.15 and Etoys' GetText-Richo.14 (you can see it in Monticello's history tool). Please remove the unneeded methods in GetTextExporter and TranslatedReceiverFinder, and delete the GetTextExporter2 class.

GetTextExporter>>createHeaders (changed and recategorized)
GetTextExporter>>export:
GetTextExporter>>exportHeader
GetTextExporter>>exportTranslations
GetTextExporter>>exportUntranslated
GetTextExporter2 (added class)
ISOLanguageDefinition  (added class)
InternalTranslator  (added class)
LanguageEditor (added class)
Locale (added class)
LocaleID  (added class)
NaturalLanguageFormTranslator  (added class)
NaturalLanguageTranslator  (added class)
String>>translatedInAnyDomain
TextDomainManager class>>initialize (changed)
TranslatedReceiverFinder class>>makeJapaneseTranslationFile
TranslatedReceiverFinder>>searchBlockNode:addTo:
TranslatedReceiverFinder>>searchMessageNode:addTo:
TranslatedReceiverFinder>>searchMethodNode:addTo:
TranslatedReceiverFinder>>searchReturnNode:addTo:
TranslatedReceiverFinder>>senders

> And the proposal of have a directory on the ftp with all needed files for
> loading if user wish.

I previously wrote "put it in the 4.4alpha directory".

So ... is this enough to unblock you? Thanks for doing it :)

- Bert -