Re: Translation of numeric values (application gnome-schedule)

[Philip Van Hoof <spamfrommailing freax org>]

On Sun, 2004-06-20 at 15:46 +0200, Christian Rose wrote:

> I agree; and there's no need to explain the basic principles of
> usability to me¹. :-)

My apologises if I offended you here :). It was not my intention to make
you look as somebody who knows little about usability :-). 

> I just wanted to point out that sentence surgery in code is almost
> always bound to be a disaster for translation. Every language has its
> own grammar, and hence sentence surgery in code is conceptually bound to
> be incompatible with many of the world's languages, except for perhaps
> the original language. Also, sentence surgery confuses translators since
> it becomes difficult for them to see how the sentences will finally look
> like when presented to the user, and hence the danger of mistranslation
> is very high, even with appropriate comments.

I agree

> You can look at this from this POV aswell: Sometimes a really bad and
> confusing translation is worse to the user than no translation at all
> would have been. Really bad and confusing translations are very often
> caused by bad and confusing original strings and sentences. Hence, not
> causing trouble for the translation process is directly benefitting the
> end user usability for many users.

Again I agree, and therefor I ask the translators not to try translating
it if it's nearly impossible in your language.

> And sentence surgery *is* one of the worst offenders in this area.

Yes, indeed
 
> > I can find more peace in maintaining lots of translation-specific code
> > than I am when I have to cripple the format of the frequency.
> 
> Then I suggest you expand the sentence fragments a bit so that you don't
> just mark "3rd" and so on for translation. I.e.:
> 
>         /* Translators: This gets put into the "Run this application..."
>            sentence. */
>         N_("every first minute")
>         /* Translators: This gets put into the "Run this application..."
>            sentence. */
>         N_("every second minute")
>         /* Translators: This gets put into the "Run this application..."
>            sentence. */
>         N_("every third minute")
>         
>      [ CUT ]

> If you need to reorder the arguments to suit your language, you can
>           do it with the printf parameter reordering syntax.
>           Example: "Run this application %2$s %1$s %3$s."
>           In this example, the hour string will be placed before the
> minute
>           string.
>        */
>        _("Run this application %s %s %s.",
>           _(minutestring), _(hourstring), _(monthdaystring))

Okay, with that example I can agree more.

Well the (temporary -I don't know-) solution will be the following:

I have declared the "lang.py"-file as owned by the translation teams.
Because as a Dutch/English/French speaking programmer I will probably
never understand all possible issues with this type of translation-bound
code. This is the reason why I am throwing the "lang.py"-file to the
translation teams for further investigation.

You people are free to adapt/adjust the strings to more easy
translatable instances. I have teared out all of them and I've put them
in that lang.py file. Other such strings for the 'at' support are coming
towards you once Gaute Hope has finished this support (he is getting
there very soon, I noticed from the CVS-logs). We are not planning to
support other scheduling systems (actually, we are totally unaware of
the existence of other scheduling mechanisms on Unix).

I am not trying to force the translators to code. I am just saying:

Well, IF you people want all this to get translated correctly, it's your
responsibility because honestly I am not smart enough to know all the
translation issues of this multilingual world. You people are by far
better at this type of support and coding. I'd manage to get it
completely right.

So

I provided "a" implementation. I kindly invite translators to provide
another, more suitable, implementation. Perhaps specifically for their
language or maybe even generally for all languages. Using only the
"lang.py"-file you can do all that.

Both me and Gaute Hope are prepared and will provide assistance to any
(non-)coder who is going to start correcting this file. We will act as
your slaves if necessary :D (only if you contact us at the right time or
use E-mail. We do have a professional and private life, hehe).

We are committed to getting this issue done 'right'. If thats indeed
impossible, we are committed to getting this issue ' as right as
possible '.

However, in the other news I've just read that it's now possible to copy
atoms from one place to another (tele-transportation like star trek)
using quantum physics. So to be honest I can hardly belief that we
humans can get that working but can't get written nth numerics
translated programmatically :-).

> Note the translator comments²: They're absolutely essential here so that
> the translator will know how the sentence fragments are used.

Okay

> Also note that in almost all cases it's better to expand to full
> sentences marked for translation instead of doing something like this,
> even if it means many more strings marked for translation -- this is
> just an exception because otherwise the total number of strings would
> grow absurdly in this case, since the number of possible combinations is
> so huge.

Yes

> [ CUT ]


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
work: Philip dot VanHoof at cronos dot be
http://www.freax.be, http://www.freax.eu.org