Re: [GNUe-dev] Proposal for i18n handling of .gfd files

[kilo]

On Wed, 21 Jul 2004 13:09:21 +0200
Reinhard Mueller <address@hidden> wrote:

> Am Mit, den 21.07.2004 schrieb kilo um 12:42:
> > In the layout section of a .gfd file each entry has unique names. Based
> > on this unique name, a simple runtime translation can happen.
> > Prerequisites:
> >     -a gnue.conf setting in the [forms] section, specifying the needed
> > translation language's ISO 639-1 or 639-2 code, eg. "translateForms=hu".
> 
> This should be the language of the user. Different users on the same
> system might want to use different languages, and we wouldn't want to
> have multiple gnue.conf's just for different languages.
> 

IMHO this can be solved by instralling GNUe locally, so gnue.conf would exist
in each user's home dir.
There are users who set a language for their software, but would like to see
a form in an other - i know of one for sure, myself. I use Gnome in Gaelic,
but would like to see forms in Hungarian...

> Apart from that, for consistency, we might want the forms translated to
> the same language than the other stuff like menus or error messages.
> 

Ah, OK, so the aims are right.


> >     -a translation file in the same directory where the original .gfd
> > file resides, with the extension of the language ISO code, eg. "intro.hu"
> >      -This translation file holds string pairs, following the format:
> > layoutEntryName=translatedString, eg "Label_5=Neved:"
> 
> This might be a good system for 2-tier applications. For 3-tier
> applications, the name of a field (property) in different languages
> could be stored in the database, and appserver could provide forms with
> the correct label for the entry.
> 

I don't think we should put it in appserver. The .gfd files has to exist
somewhere, there is no intention afaik to move them to appserver.
So putting another file next to the .gfd file will not hurt at all.
If forms were stored in a database, then translations also should.


> > It is the translator's responsibility to match the length of translated
> > strings to the original ones.
> 
> That is impossible. There is no 4-letter German translation for the word
> "item". Thus, translation of forms will only work if we have a layout
> manager.
> 

Joke: all standard forms must be developed in German, so 80-letter words
can be handled then easily 8-))

Anyway, it should be the responsibility of the standard form developers to
try to provide enough space on the standard forms.


> > This way we can achieve that standard, pre-developped forms can be
> > localised easily, so that code reuse can be easier (think of
> > GNUe-Packages). They can also be used in multi-language environments,
> > where different translations can exist beside each other, and it would
> > be only a matter of changing a configuration setting to use the form in
> > an other language.
> 
> The problem here is that you have to translate each form seperately.
> This might work for small 2-tier applications.
> 

I don't intend to build a common language repository and translate using that.
Imho standard forms won't change much in their word/phrase usage, so
maintaining translations will not be that hard.


> Thanks,
> -- 
> Reinhard Mueller
> GNU Enterprise project
> http://www.gnue.org
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> No army can stop an idea whose time has come.
>         -- Victor Hugo, 1802-1885
> 


Thanks for you comments. Anyone else?

kilo
Gabor Kmetyko