Re: gnome-doc-utils strings (was Re: New module : GNOME Power Manager)

[Clytie Siddall <clytie riverland net au>]

On 13/07/2005, at 4:21 PM, Shaun McCance wrote:

> If we just had to worry about masculine/feminine/mixed, this
> would be an easily solvable problem.  But this Vietnamese
> social status stuff could make things interesting.  But hey,
> interesting problems are fun problems.

What my language really needs is more background on the string (and I  
don't think any other language's translators would mind that,  
either ;) ).

As long as we had that, we could probably come up with the  
appropriate translation in each case.

Our social position issue is crucial to communication between  
different people, but it's possible to "denature" the communication  
to something fairly neuter, in official documents, and in this sort  
of situation, where you don't know in advance with whom you are  
speaking, or even from whom you are speaking.

One thing that removes a lot of the difficulty for us is NOT having  
the computer/program talk to the user. This is extremely  
inappropriate in our culture, and, I gather, in others. I always have  
to find some way of rephrasing such strings. I think there have been  
several recommendations on this list alone, that developers stop  
using such communication in their programs, so I would recommend here  
that this be a guideline for Gnome docs of every kind. If the  
computer-as-person thing were translated directly in my language, it  
would alienate users. We don't want that.

Some (too few) Gnome l10n files have too-scarce helpful comments such  
as:

.po:480
auto:    â    TRANSLATOR: This is the default unit to use for  
visibility distance.
auto:    â    Valid values are: "m" (meters), "km" (kilometers) and  
"mi" (miles)
reference:    â    ../gweather/gweather-pref.c:524 ../gweather/ 
gweather-pref.c:533
Original:    â0    DEFAULT_DISTANCE_UNIT
ViÃÌt:        km

.po:337
auto:    â    Translators: Please replace (C) with the proper  
copyright character.
reference:    â    ../gswitchit/gswitchit-applet.c:589
Original:    â0    Copyright (c) Sergey V. Udaltsov 1999-2004
ViÃÌt:        Bán quyán Sergey V. Udaltsov  nÄm 1999-2004

.po:61
auto:    â    TRANSLATORS: this is a list, it is left as a single  
string
auto:    â    * to allow you to make it appear like a list would in  
your
auto:    â    * locale.
reference:    â    ../battstat/battstat_applet.c:544
Original:    â0   (long, snipped)

We need more of this. The shorter the string, the more background we  
need. I am sure we are already translating some strings incorrectly,  
because we have no cues, or the wrong cues. As has been explained in  
emails from other translators, some words that have only one meaning  
in English can have multiple meanings in other languages, and the  
inverse as well. We need an explanation of the purpose of the string.  
This makes it possible for us not only to translate the string text,  
but to translate the intent of the developer, which is a much more  
effective kind of translation.

This has all probably been said over and over here, and in any other  
i18n forum, but if there is some chance of achieving change here, I  
think it's worth saying it again.

With more detail (and we can supply models for this, if required), we  
can make better translations.

For my language, we can get by without extra fields, as long as we  
have the background information. In order to create a true human  
communication between the developer and the user, we would need to  
know in each case who was talking to whom, and I really don't think  
that's realistic yet. <fantasizes about software that adapts to the  
user...>

It is essential to know the purpose of the string. Background like:
_______________
Type: menu item
Function: brings up a dialogue which allows the user to modify  
currently-highlighted text
Original: Edit
_______________
is much better than just "Edit" on its own. The less information in  
the string, the more explanation we need.

I would also like to see developer comments to each other, or to  
themselves, removed from our files:

po:140
auto:    â    If there is no cpufreq support it shows only the cpu  
frequency,
auto:    â    * I thi nk is better than do nothing. I have to notify  
it to the user, because
auto:    â    * he could think   that cpufreq is supported but it  
doesn't work succesfully
auto:    â
reference:    â    ../cpufreq/src/cpufreq-monitor-factory.c:45
Original:    â0    CPU frequency scaling unsupported
ViÃÌt:        KhÃng há trá tá lá tán sá CPU

They are just confusing for the translator. :(

I hope this is useful.

from Clytie (vi-VN, Vietnamese free-software translation team / nhÃm  
Viát hÃa phán mám tá do)
http://groups-beta.google.com/group/vi-VN