Re: Gorm Localisation Support

[Stefan Urbanek]

On 2003-10-29 02:04:51 +0100 Gregory John Casamento <address@hidden> wrote:

> Guys,
>
> I'm glad we got both ideas out for open discussion.
>
> Translating all strings is a little dangerous since there are strings stored
> inside of dictionaries withing some of the objects in the archive.   A policy
> of blanket translation might corrupt data unintentionally.

Not all strings, just those which user specifies as strings to be translated or those 
that are known that they have to be translated (button labels, for example). This is the 
reason for "string outlets".

> What might work slightly better is to use a subclass of NSTextView or other
> text  objects which will translate themselves and resize the font inside the
> gadget to fit if the word becomes too long (the last bit is optional).  This
> way the user designates which fields are to be translated by setting a switch
> in the inspector and the rest is taken care of for him/her automatically. :D

No, using any kind of special view is not appropriate. What about custom views 
that contain strings for translation? There should be some generic 
mechanism/API for:

- developer to specify which parts of view are translateable strings (this can 
be GNUstep-specific, no problems with compatibility, because gorms are gnustep 
specific also)
- Gorm to be able to extract and change those strings (string outlets and/or 
key-value coding?)

> There are various things which can be done during the archiving / unarchiving
> process to make the existence of the subclass compeltely transparent to the
> user as the object would unarchive into a NSTextView or whatever custom
> subclass they have specified in Gorm. :)

Hm, is this really needed for translation?

Stefan

> --- Adam Fedor <address@hidden> wrote:
> > On Tuesday, October 28, 2003, at 12:51 PM, Stefan Urbanek wrote:
> >
> > > On 2003-10-28 20:19:50 +0100 Adam Fedor <address@hidden> wrote:
> > >
> > > > On Monday, October 27, 2003, at 07:04 AM, Jeff Teunissen wrote:
> > > > > What I suggest is a non-public subclass of NSString, called perhaps
> > > > > "GSLocalizedString", which when decoded will return NSStrings.
> > > > I like this idea - it sounds simple enough to do. It could eventually >> 
> > > > lead to one of Stephan's ideas, although his still requires multiple >> 
> > > > gorm files (although it adds some utilities to make updating them >> 
> > > > easier).
> > >
> > > We allways need multiple .gorm files if we do not have autolayout > 
> > > mechanism. However, if we have well designed way translation, then all > 
> > > is needed is to do minor tweaks manually.
> > >
> > > The idea is that you create a .gorm file, specify translateable > strings. 
> > > Then you just make copies of it and do translations. When you > modify any 
> > > of those translations (add buddon for example), again, just > copy it 
> > > replacing other translations and do minor fixups. Not very > elegant, but 
> > > sufficient to the gorm approach of UI building (free > positioned views 
> > > without autolayout).
> >
> > Sure. I think you both propose about the same approach for storage of the 
> > translation (some kind of strings file). You just add a utility (integrated 
> > or not) that would help keep the various localized versions up-to-date. It 
> > would be easier, in fact, if all the localizations were kept together in 
> > the same .gorm dir - but that doesn't really fit in well with how resources 
> > are organized.
>
> Later, GJC
>
> =====
> Gregory John Casamento -- CEO/President Open Logic Corp.

--
First they ignore you, then they laugh at you, then they fight you, then you 
win.
- Mahatma Gandhi