[etoys-dev] Translation support

[Bert Freudenberg]

On 02.05.2010, at 00:16, Bert Freudenberg wrote:
> There is a slight problem with extension methods (methods defined in *categories), #translated currently would look for those in the wrong package:
> 
> We need to make #translated deal with this. I can think of a simple but inefficient way to do it - maybe it wouldn't hurt that much?

I wonder if method properties could come to the rescue here. We could simply store the translation domain as property of the compiled method itself. We have about 1500 methods that send #translated, so that seems not to be bad at all space-wise, and should perform very well.

Btw, I think in the current implementation there is even a problem without extension methods. It only looks at the class of the sender of #translated. But the method could actually be defined in a superclass, which might be in a different package. That's simple to fix though, instead of "context receiver class" use "context mclass". This looks up the actual class where the method is defined.

Also, I wonder if we should use PackageInfo instead of lists of categories in TextDomainManager. The extension method categories often differ in upper/lower case from the class categories. In fact, it is possible to define packages that do not rely on category names at all.

And Ted: was Text>>translated only meant for translating Quickguides? Can we remove that now, since we are not using the gettext translations for the guides?

In any case, the properties idea is growing on me. The only problem seems to be to keep the property up-to-date. Could be part of the release process, though something automatic would be nicer for development. But the runtime benefits might be worth it.

- Bert -