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

[Sini Ruohomaa <ruohomaa+gnome cc helsinki fi>]

Hi,

I would throw in my two cents' worth, working with an agglutenative
language (Finnish) which is basically impossible to translate fluently
in many circumstances. I still believe in using the %s in their natural
positions in sentences for those languages which can manage it. 

That is, even though I have to do black magic to translate something
like ("A %s %s has attacked your %s", nationality-adjective,
attacker-unit, attackee-unit), I think that there is no point in making
the sentence clunky in *every* language. It sounds fine in English,
can't be translated directly in Finnish. (Eg. the last %s is an object
of the sentence, it must be a subject for me to be able to use the
translated unit names in their basic forms.) However, since there is no
general solution to this, I'll just make a clunky translation in Finnish
which gives the same information and ignore trying to translate
word-for-word. Which means taking some creative liberties, like "%s %s
attacks! %s defends mightily." Still, the same information is given.
(Making different translatee sentences for every combination is almost
always out of the question.)

On Sat, 2004-06-19 at 21:56, Christian Rose wrote:
> Thus, it's better to avoid such situations altogether, and remember the
> golden rule:
> 
>         Sentences can only be properly translated in their entirety.

Yet sentences cannot be always coded in their entirety, if we want to
avoid machine-like language everywhere. 

[A suggestion to use the latter instead of the former]
> _("Run the application every %s minute of every hour."), _("3rd")
vs.
> _("Run the application at this minute every hour: %s"), 3

This is exactly what we sometimes have to do, but I don't think it's
good practice for the original to be already clunkily structured; if
it's in a natural-sounding sentence, the user will have a nicer time
reading it, and it doesn't stop us from translating the sentence in the
latter format in languages where putting the %s in the middle would not
work. I'm for always striving for "human" instead of "programming"
language in messages given to users. The more we can do it, the better,
but when we can't, we'll just work around it somehow. Plural support is
good, some other most common specialities might be nice to consider as
well once someone figures out a way. 

--Sini