gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gorm Localisation Support


From: Gregory John Casamento
Subject: Re: Gorm Localisation Support
Date: Tue, 28 Oct 2003 17:04:51 -0800 (PST)

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.

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

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. :)

--- 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.
-- bheron on #gnustep, #linuxstep, & #gormtalk ---------------- 
Please sign the petition against software patents at: 
http://www.petitiononline.com/pasp01/petition.html 
--- Main Developer of Gorm (featured in April Linux Journal) ---

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]