[Top][All Lists]
[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