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

[chafar]

Hello.

El mié, jul 21, a las 15:55:53 Reinhard Mueller escribía:
> Am Mit, den 21.07.2004 schrieb kilo um 14:40:
> 
> > 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.
> 
> ...
> 
> Seriously - I don't think we want to have manually generated forms in
> the long run for most of our purposes. Runtime generated form
> definitions can solve many problems, starting with translations over
> access restrictions to adding individual fields into a existing form.

This is nearly an OT here, because I don't talk about runtime generated
(that seems a big issue to me), but I already had in mind served
forms for various reasons. Mainly (but not fully;) security (at least,
while a stronger auth scheme is developed), availability (if you have
access to server, you have to the form too) and coherence (users using
deprecated forms will be a headache;).

> 
> > Anyway, it should be the responsibility of the standard form developers to
> > try to provide enough space on the standard forms.
> 
> That is not possible. I have no idea how long the translation of "item"
> in Hungarian is. And having a reserve of 100% for all labels would make
> the forms look quite ugly, IMHO.

This will be a problem in whatever solution. And I see related with
runtime generated forms, because I think that an acceptable quality form
needs to be, at least, human 'finished' and this is one of the reasons
for me to think so.

> 
> > > 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.
> 
> In the application I will be replacing with GNUe in the long run, I have
> 350 forms of which about 50% contain the word "item". It might still
> make a difference if I have to translate that once or 180 times.

IMHO, what you need is a good system to help you (as much as programs
could) with that, but the final translation responsability will be
yours. Is there anyway a good system for automatic translating of
something?

And I think that this is the big deal. Whatever kind of runtime
translation will produce irregular results, sometimes inacceptable, so
you will have to leave a open door for static translations in such
cases. People wanting a verified forms quality, will use it most of the
time, while others, layzy accept the machine work.

I propose whatever mechanism of automatic translation should be able of
use for static translations by developers so that they can, after that,
make desired changes and let gnue-forms/appserver choose the right
version in a similar way as Apache choose the appropiate lang version
for a document. If it can't find it, then it can try with an appropiate
translation spec for on-the-fly translation.

In name of truth, I like static translations for still another reason:
performance ;).

And about the translation machine, we are fortunate, use xml, a highly
auto-descriptive syntax that should let us specify the term we are
translating in a wide number of ways. We just have to choose with the
compromise of flexibility and ease of use: between the power of XPath
and the simplicity of Kilo's proposal(then @name of an element) or
Reinhard's one (the original value of the term) should be the right
way.

After all, thinking in me, I don't worry very much about this: with XML,
I'll always be able to use XSL for my translations. The only feature I
need for that is that said about appserver/forms choosing a variant in
attention to a filename segment(an xml:lang attribute would have a high
performance cost). But the goal is, as also said, the compromise about
flexibility and ease of use; the answer should be found based in XML
syntax.

greetings
-- 
José Esteban
Granada - Spain
http://alcances.net