gnustep-dev
[Top][All Lists]
Advanced

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

Re: Gorm Localisation Support


From: Stefan Urbanek
Subject: Re: Gorm Localisation Support
Date: Tue, 28 Oct 2003 20:51:20 +0100

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

I suggestnot to translate strings on loading, but in Gorm, for faster 
application launching. To achieve this a translation table is needed. The table 
should consist of some unique string id, string translation and an outlet to 
the view where string is going to be replaced. It's not as complicated as it 
looks :-)

Why unique id and not just original string? For various reasons: what if 
original string changes? Or what if I want just to do a rewording of a string 
and in other languages it stays the same? And ... unique id will allow us to be 
able to modify ANY translation we like and we do not have to have kind of 
'master' .gorm file.

Scenario(s):

1. user adds a button to a window. Unique id is created for the buttons 'string 
outlets'. User types a label of the buton and stores .gorm file. Strings table 
is saved in two ways: one in the object archive using outlets, and the other in 
to shared (among all same .gorm files in different languages) table. Let's call 
it English.gorm

2. Copy English.gorm to Slovak.gorm. Translate and save.

3. In a new version of the application with our .gorm file we want to add 
another button into the English.gorm. We add it and save it. To propagate the 
change, we just copy .gorm file to all other localisations, like Slovak.gorm

4. Some slovak developer want to do few changes into the application. Adds 
another button, saves and copies to other languages.

5. Shared translation table can be edited by hand/a tool/application by some 
translator without need of opening .gorm files. When UI designer wants to apply 
changes, then he opens all gorm files and fits views to strings. Strings are 
correctly set, because there is string_id-view_outlet-string_value table for 
each language.

The string_id can be thought as a global identification in the scope of all 
corresponding .gorm files in different languages.

This will requre some better management of .gorm files and perhaps explicitly 
mentioned specification of .gorm files storage in Resources directory.

UI relayot will me minimal compared to the effort of translating .gorgm files 
again and again. Perhaps later, when there will be some autolauout mechanism in 
gorm, this can be elimined. All is needed is: translate-copy-fit.

Please, feel free to refine this specification.

I think, with proper tools user actions can be minimised.

Stefan

p.s.: Yes, I know, that this kind of problems does not exist in Renaissance, 
but that is different point of view on UI editing. Gorm uses free-form layout 
and gives more freedom to the UI designer, so this is just a small tax.



_______________________________________________
Gnustep-dev mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnustep-dev




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






reply via email to

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