Hi guys

why do not you start with something really simple. Having a class per  
package which has a protocol
to collect/contain the translation and then a way to initialize the  
image.
Package allSubclasses collectTranslations
MyPackage  removeTranslations.

And see. It should not be that complex. Do it and aks for feedback.

Stef

On 17 mai 06, at 14:13, Hilaire Fernandes wrote:

> The message catalogues -- for translation -- as handled right now  
> come in the form of an unique dictionary per language in the Image.  
> When developing a specific application where you want the interface  
> to be translated in several languages it is a very big problem.
> Indeed there are *no standard* way in message catalogues  
> transportation related to your package. Right now the application  
> source code and the translation are located in different places.  
> The first one in a Monticelly package and the other in the Image.  
> Therefore it could be very easy mix up or even worst lose part of  
> an application translation.
>
> I read here and there about possible hacks to do it, but could we  
> try to define once *a standard way* to define such message  
> catalogue transportation.
>
> From my point of view -- application developer -- I will need:
>
> - for one specific application, the message catalogues  should come  
> with the source code (as it is done with the GNU Gettext system).
> - the message catalogues should be transportable with the source  
> code. For example I read it could be integrated in the Monticello  
> package and SqueakMap package
> - it should be easy for translators to translate one specific  
> application, then commit back in the application repository the  
> translated messages.
>
> I don't think I can define such a framework alone, but if other  
> people are interested for such a solution I am willing to help.
>
> Hilaire
>
>
> -- 
> ADD R0,R1,R2,LSL #2
>