[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-08-04 17:02:39
Message-ID: 200508041902.39571.nicolasg () snafu ! de
[Download RAW message or body]

On Thursday 04 August 2005 17:15, Michal Rudolf wrote:
> Nicolas Goutte,  czwartek, 4 sierpnia 2005 16:51:
> >> You are having a little too much expectation of the Gettext :) Consider
> >> that even the plural handling is not without dispute, as the KDE still
> >> doesn't use the default Gettext's way of handling plurals. Also, current
> >> plural handling (Gettext's or KDE's, whichever) will not allow you to
> >> have more than one plural argument per message.
> >
> >Sorry, what do you mean by "more than one plural argument per message"?
>
> "%1 bytes in %2 files"

Ah, yes, this is indeed a problem.

>
> >> Second, from the point of view of translator who does not need to use
> >> such scripting system, nothing changes at all. And for those who do need
> >> to use it but are unsure exactly how, there is this list to talk it over
> >> :)
> >
> >That is what I do not understand. If you have a scripting language instead
> > of having a simple translation then even the British English team would
> > have changes.
>
> I assume that using script languages was suggested for some special (f. e.
> highly inflective) languages only. But I don't think it is a good idea.
>

> Of course, multiplying messages is not a good solution either.

However it seems to be the only exact solution without a script that is run at 
runtime.

Perhaps a middle way is to have a (non-runtime) script to fill the 
translation. However the script must be adapted to the application. (We had 
already that problem with the "fuzzy clock"; I do not know how this problem 
has evolved.)

>
> I think the best we can do is to avoid such construction if it is possible,
> and if it is not, trying to formulate the sentence and arguments in a way
> that will cause as little problems as possible.
>

I suppose that this will always have limits, either in what the developer 
wants to implement or of what a translator needs to translate to his 
language.

> I think we may need some way to query various translators about their
> languages. Some problematic sentences will be posted on some page and will
> be "accepted" or "rejected" by native-speakers of some KDE languages as
> possible/impossible to translate into their language.
> Otherwise it is hard for programmer to decide what is and what isn't
> acceptable. Of course, one can use this list for that purpose, but checking
> answers here requires more effort.

The problem that I see here is that we have already "forbidden" constructs and 
that they are still used. (And in the past I was at least two times "flamed" 
for reminding a developer about them with a bug report.)

Have a nice day!

[prev in list] [next in list] [prev in thread] [next in thread]