16 Feb
2007
16 Feb
'07
3:46 p.m.
Hi Pavel,
I used it in ShoreComponents and there were no problem with VW port
(even Michel didn't tell anything against it). On the other hand it
then uses only dummy implementation without translation.
How do you scope the language? I don't see that in the implementation
in Squeak of System-Localization. To make it even works I have to say
that we have even Web application that can have different parts of
the same session in different languages ;-)
Ok. There's the next very strange bug in Magritte.
When you try to run
tests, one fails
(MAToManyScalarRelationDescription>>testCopyReference). String
descriptions have different uuids but only for first time. If I try to
evaluate this comparison again, it returns true (Sqeuak 3.9).
yes I noticed as well. Maybe Philippe knows more about it, he
implemented MAToManyScalarRelationDescription.
If you'll agree, I would like to prepare Magritte
and Pier for
translation into other languages. That means mostly simple
adding the
#translated messages to string literals but in
some cases it
will be
more complicated.
I don't think that is a good idea for two reasons:
1. The #translated mechanism is specific to Squeak and wouldn't work
with the ports to other dialects.
2. The #translated mechanism is global to an image. We have several
web applications using Magritte where the language (german, french,
italien, english) is defined per session and can be even switched on
the fly. I don't see how that would work with #translated?
Please correct me if I misunderstood your proposal. Per session translation can be done similarly to
WADynamicVariable
mechanism. How do you solve translations now? The sending of some
message to string literals is quite general solution. We may name it
for example magritteTranslated but that it will mean that this message
will be part of the Magritte package.
At netstyle.ch we use a special object that represent a translated
string. This object can be used anywhere as a replacement for a
string, as it supports the same protocol. When a string is rendered
(#renderOn:) it does the lookup and displays the right translation
lazily. The language context is defined using a dynamic variable.
So I think that the standard
#translated message will be the best solution and the final
translation mechanism will be then dependent only on user's choice
(for example user-modified implementation of #translated message).
What do you think?
I don't see, but if you change #translated to use a dynamic variable
you break all the Squeak tools that use #translated. No?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch