GNOME.org
 

Re: Translation of program names

Дана петак, 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]