[squeak-dev] Translations (was: Towards SqueakCore (adjusting the GetText package))

Frank Shearar frank.shearar at gmail.com
Sun May 12 14:59:13 UTC 2013


On 15 February 2013 13:36, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 2013-02-15, at 10:04, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
>> Bert,
>>
>> You write the that InternalTranslator (one of the subclasses of the
>> abstract class NaturalLanguageTranslator) is obsolete, what was it
>> used for?
>
> The old Etoys translation system, which stored translations in the image.
>
>> Should we remove it?
>
> It's very simple so may not be worth the trouble. In the Etoys image I see that it is used by some SqueakMap installer code, maybe there are packages out there that ship with these old translation files?
>
> If we're reasonably sure it's not used, then by all means remove it.
>
>> The other subclass, GetTextTranslator is the one which is used, I assume?
>
> Right now, in squeak.org images, none is used, because we don't ship translations. But almost all of the Smalltalk tools have GetText translations already:
>
>         http://translate.sugarlabs.org/projects/etoys_new/
>
> That is, virtually all menus and labels (not just Etoys tiles) are available in more than 10 languages.
>
>> What do others think about moving the class
>>   TextDomainManager from GetText-Localization to System-Localization
>>   , as well as the #translated* methods that use it?
>
> Why *wouldn't* we want to do that? #translated was only moved into *gettext recently. The system package seems like the right place (unless we want to put the translation support stuff into Collections, which doesn't seem right).
>
>> For #translated I only see
>>   String translated    {*getText}
>
> There are quite a few more translation methods in String's *gettext protocol. They should all be moved to *system-localization.
>
>> and
>>   ElementCategory translated
>>
>> (Implementors)
>>
>> There are 900 senders of #translated all over the place.
>
> In Etoys we have more than 1500. In trunk, many strings are still missing the #translated send.

Right, so we ought to actually do this! If noone takes it up, I'll
take a stab at it tonight or tomorrow.

frank

> - Bert -
>
>> --Hannes
>>
>> On 2/13/13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>> On 2013-02-13, at 16:30, "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>>
>>>> On 2/13/13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>> On 2013-02-12, at 21:24, Colin Putney <colin at wiresong.com> wrote:
>>>>>
>>>>>> We should especially look at System->GetText
>>>>>
>>>>> IMHO #translated and co. should be part of the System package, because
>>>>> senders are necessarily sprinkled all over the place. There should be a
>>>>> translator registry and if no translator were registered it would return
>>>>> the
>>>>> string untranslated. GetText would hook into that.
>>>>>
>>>>> - Bert -
>>>>
>>>> At the moment the class TextDomainManager is in a specialezed GetText
>>>> package. There is
>>>> GetText-Editor and
>>>> GetText-Localization
>>>>
>>>> There is in addition a package
>>>> System-Localization
>>>>
>>>> which contains classes like ISOLanguageDefinition, InternalTranslator,
>>>> Locale, NaturalLanguageTranslator
>>>>
>>>> Bert, is what you mean done by exchanging
>>>>
>>>> GetText-Editor --> System-GetTextEditor
>>>>
>>>> GetText-Localization --> System-GetTextLocalization
>>>
>>> No, we want to keep GetText as a separate package.
>>>
>>>> How should the translation registry class be named?
>>>
>>>
>>> NaturalLanguageTranslator is fine, and it might even do the job (it has the
>>> registry), we just haven't tested that. Btw, InternalTranslator is pretty
>>> much obsolete, as well as LanguageEditor.
>>>
>>> Perhaps it is enough to move just TextDomainManager from
>>> GetText-Localization to System-Localization, as well as the #translated*
>>> methods that use it.
>>>
>>> The goal is to remove the direct dependency on GetText from the rest of the
>>> system.
>>>
>>> - Bert -
>>>
>>>
>>>
>>
>
>


More information about the Squeak-dev mailing list