Re: Translation of program names

[Danilo Segan <dsegan gmx net>]

Дана петак, 31. октобар 2003. 03:44:14 CET, Christian Rose написа:
> > No, I don't think the style of original is at all important for
> > translation.
> 
> Again, software translation is not poetry...

I think that we have misunderstood each other when it comes to "style".  
I considered that a "lingustic style", and it's simply impossible to  
follow English lingustic style in Serbian texts. I don't doubt that's  
also the case for Swedish.

> 
> Also, in GNOME I feel that the general philosphy of "fix the root of
> the problem instead of doing workarounds" has won a tremendous amount  
> of terrain among developers. And I think that's a good and healthy
> philosophy. I think that we as translators definately should follow  
> that too, and that's why I was worried above that you might be of an  
> entirely different opinion.
>

I don't neccessarily consider different styles "bugs" for one simple  
reason: I expect those to be variations in language, that would make  
user experience more interesting. I don't think any user will have a  
problem understanding if she sees messages like:
"Please update your software"
"Your software needs updating"

These are lingustically different sentenses, but any user would  
understand them the same: suggestion to update the software she's  
using. So, I don't consider those bugs. Though, I haven't read the user  
interface guidelines very carefully, so I wonder if I am wrong?

> If you feel that a certain application uses the wrong style or an
> inconsistent style in its messages (and there are many cases of  
> this), just report that problem. Doing workarounds for that in your
> translation by using a different style just means that you will have  
> to do the work twice (once for the workaround and once when the  
> original is actually fixed).

I wasn't doing "workarounds" for my translation. I was translating it  
so it looks more like Serbian language. That means that I might  
actually use passive for the first sentense, and active for the second  
(this is just an example, in this particular case I probably would  
follow the original). And yes, using different linguistic style makes  
no difference to the "technical detail" you mentioned in one of  
previous mails. Actually, even sentenses "You need to update your  
software", "Software of yours would love to be updated", ... are all  
passing in the same meaning to the user. And yes, as a translator, I  
might choose any of the styles Serbian language allows me to use. I'll  
be consistent in translation, sometimes following the consistency of  
the original, and sometimes not (again, Serbian language is often nicer  
in one style, and English in other).

> 
> In addition as a bug reporter I am sometimes wrong, or there might be
> other good reasons for the style differences that I have overlooked.
> If I stayed close in style in my translation I'm safe, but not so if  
> I introduced a "workaround" on my own. Then I might have instead  
> created a problem where none existed before.
>

Yes, you *might* have. But why wouldn't you allow for a translator to  
be really careful, and to more often than not, create a good  
translation without creating any problems? There certainly will be  
problems, but we have them anyhow.

Along the same lines, we might dismiss programming itself, because if  
you code and you're not careful, you'll create bugs -- bugs that smash  
your data. So, better not program at all? (Again, I know you're not  
saying this, but logic you use can lead to this conclusion)

> 
> > Perhaps every sentence in English starts with "Please, ...", but
> > that form is unneccessary in Serbian. So, I'm definitely not going  
> > to keep the "style".
> 
> I count that as a lingustic difference out of necessity, not
> necessarily as a change in style. And we have the same situation in  
> Swedish btw.
> 
> What I call a "change in style" is for example when changing messages
> from being very straight-forward and technical in the original to
> being overly descriptive in the translation, or the other way around,  
> or using an entirely different set of terminology that doesn't really  
> match the choice of terminology used in the original, and so on.

As I said above, we might have talked about different "styles" :-)

Btw, I still even do some of that. For example, even as a long term  
computer user, I don't see a difference in names like "Host", "Server",  
"Address", "Location" or similar if you need to input your proxy  
settings (there's difference in some other contexts, like "Apache  
Server" or "Sound Server", "File Location", "Email Address"). And yet,  
developers use them interchangeably. So sometimes, I even change the  
terminology. I asked before for this to be standardized, but it seemed  
hard to achieve (not that I'm running away from it). Just like in this  
example, I think at least some translators are equipped with common  
sense to know what is different, and what is not.


> I'm not really sure what you're trying to say by this example. Is
> there a lingustic difference in Serbian between menus and buttons? To  
> me, identical messages placed on different widgets like menus and  
> buttons is still just identical strings with the same function and  
> meaning, and I'm havinga hard time believing that any language does  
> actually linguistically distinguish between menus and buttons this  
> way.

Actually, it's not between menus and buttons, but items on a menubar,  
and other items. Common practice in translating software in Serbia is  
to have menubar items translated as 'noun-ed verbs' (I don't know the  
English name for it, so I'm using rule from that fortune cookie: 'every  
word can be verbed' :-). So, instead of using translation for  
imperative verb 'Edit', we use translation for 'Editting'. On buttons  
and similar, we're using the verb that corresponds to 'Edit'.

The main background of this is *probably* (I don't know for sure) that  
clicking on items in a menu or on a button is different from clicking  
on a item on *menubar*. When you click item on a menubar, you get a  
list of actions you can perform. When you click a menu item or a  
button, you perform the action.

And yes, what is used in English is already established practice, so it  
cannot be "fixed". There are nouns ("File") and verbs ("Edit", "View"?)  
in the main menubar which makes it inconsistent. It doesn't have to be  
that way in a translation, but I cannot file a bug against it since  
it's that way for 20 years in English :-)

There's also established practice for Serbian (it's even used that way  
in recently translated Windows software, or so I heard). So, here I  
don't follow the original style -- I actually don't care about it,  
because there's a style to follow.

> I'm merely just recognizing that there *are* often users that have at
> least *some* knowledge of English, and altering names inbetween the  
> UI and docs and support forums in English indeed makes things  
> confusing.

Yes, it does. But again, this might be a price many users are willing  
to pay.

> It's not so easy to dismiss when translators have translated *names*
> of applications, inventing a translation of a name out of thin air  
> that noone else (possibly not even other translators) used, and  
> utterly confused users that as a consequence weren't able to use the  
> docs or get help from anyone else that wasn't running that particular  
> version of the application because of the confusing name.

As I said numerous times before, when I translate a sentense to some  
other language, I wouldn't mind having to translate name either.  
Especially so if we do put the original name in the About dialog, so we  
can tell the user: "hey you, check out About dialog, and there you'll  
find the original project name if you need it". It seems really sane to  
have that data accessible like that, and this would solve all (well,  
most) problems of name translation.

> 
> There are many examples of such name translations gone bad, and often
> very frightening ones at that because they clearly show that the
> translator either didn't think about what he or she was translating,
> or that he or she ignored on purpose that he or she would cause  
> serious trouble for users.
>

And there are many examples of such name translations gone well. So, is  
the safe way out just to go for "easier" solution, and not translate  
them at all? I'm not convinced that's a good thing.

> > If "closeness to the original is key", we might as well not
> > translate at all, right? That would make that goal easily achieved.
> 
> Again, I never said that, and you know I would never do.
>

You did say what's in quotes, so I'm just offering one solution that  
would satisfy that. Of course I know you'd never suggest that, but  
that's what can be deduced using your reasoning. As above, not  
translating names is a safe way, but it *is* possible to achieve good  
results with translation. I see you worry about bad translations, but  
it applies as much to terminology.

> I'm just saying that we should first and foremost help users, and
> watch out for the cases when we don't actually do that anymore and  
> instead just translate for the sake of translations.

Of course, and I've already pointed out many places where translation  
of names helps users.

> 
> Those names are teached ones. We spend a lot of time learning names
> for various things in different languages.
> But we don't want users to have to learn a specific "GNOME language"
> before they can get help with using GNOME.

My experience is that users *do* have to learn a specific "GNOME  
language" if they even try to use it. I don't think "panels",  
"widgets", "applets" and similar are intuitive to any user that comes  
to Gnome. And translating app names only adds a tiny fraction of new  
words to the vocabulary.

> 
> Well we don't live in that dream world, do we? If anyone would
> actually create a system where it would be possible to have instant  
> access to all of the docs and all other references in the world using  
> localized names, I would be the first to cheer.
> But that's clearly not the situation, and not likely to happen  
> anytime soon.

Bug buddy is a big step towards it. So is integrating web into the  
desktop. I think we should aim for that dream world, not simply dismiss  
it as something what's never going to happen.

If I did that, I could have said a few months ago: "Serbian language  
translation for Gnome is just a 'dream'", and we'd never have it (and  
yet, many have said recently that it's really well done; only those who  
decided never to use a translation have complained about terminology,  
but as you said, this is easily dismissed). We reach our dreams only if  
we act toward them.

> Again, GNOME is not a language, and we don't want users to have to
> learn a seperate set of terminology to use it either.

We might not want that, but they still must. Whether they'll have to  
learn what's GNOME, what's Epiphany, what's File Roller, or learn  
what's Gnom, what's Spoznaja, what's "Strudla datoteka" (this is not  
real translation, just something from top of my head) is what I'm  
talking about. They'll certainly learn names in their own language more  
easily.

OTOH, if they don't have to learn any of these names (as was suggested  
in previous threads, like RedHat not having 'Gnome' written in the  
splash screen) because of usability, than they shouldn't see them at  
all (unless they ask for it, through eg. About dialog). That would  
satisfy me too, because there would be no user visible strings which  
she cannot understand. And that's the whole point.

> Just my own opinion,

Thanks for sharing it. But noone still answered my real _implicit_  
question: can I submit bug reports for program names which are not  
marked as translatable (whether I'll just keep them, transliterate  
them, or translate them is a different thing: I think we have brought  
valid points for any of the choices, so it's not developers who should  
decide on it).

Would developers accept that these *might* need translation at all? I  
noticed that some would, but others wouldn't. That's why we need a  
policy just like 'English is used for GUI, comments, code,  
documentation' in Gnome, which practically insists on software names  
being in English.

I suggest: 'All user visible strings should be marked for translation,  
including program names'.

Cheers,
Danilo