On 2/13/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-12, at 21:24, Colin Putney colin@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
How should the translation registry class be named?
--Hannes
On 2013-02-13, at 16:30, "H. Hirzel" hannes.hirzel@gmail.com wrote:
On 2/13/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-12, at 21:24, Colin Putney colin@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 -
Bert,
You write the that InternalTranslator (one of the subclasses of the abstract class NaturalLanguageTranslator) is obsolete, what was it used for? Should we remove it?
The other subclass, GetTextTranslator is the one which is used, I assume?
What do others think about moving the class TextDomainManager from GetText-Localization to System-Localization , as well as the #translated* methods that use it?
For #translated I only see String translated {*getText} and ElementCategory translated
(Implementors)
There are 900 senders of #translated all over the place.
--Hannes
On 2/13/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-13, at 16:30, "H. Hirzel" hannes.hirzel@gmail.com wrote:
On 2/13/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-12, at 21:24, Colin Putney colin@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 -
On 2013-02-15, at 10:04, H. Hirzel hannes.hirzel@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.
- Bert -
--Hannes
On 2/13/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-13, at 16:30, "H. Hirzel" hannes.hirzel@gmail.com wrote:
On 2/13/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-12, at 21:24, Colin Putney colin@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 -
On 15 February 2013 13:36, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-15, at 10:04, H. Hirzel hannes.hirzel@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@freudenbergs.de wrote:
On 2013-02-13, at 16:30, "H. Hirzel" hannes.hirzel@gmail.com wrote:
On 2/13/13, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-02-12, at 21:24, Colin Putney colin@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 -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Frank Shearar -
H. Hirzel