Re: Translation of program names
- From: Christian Rose <menthos gnome org>
- To: Danilo Segan <dsegan gmx net>
- Cc: GNOME I18N List <gnome-i18n gnome org>,GNOME Desktop Development List <desktop-devel-list gnome org>
- Subject: Re: Translation of program names
- Date: 31 Oct 2003 03:44:14 +0100
fre 2003-10-31 klockan 02.03 skrev Danilo Segan:
> > So how about translation? I think one important aspect to consider is
> > that technical translation (as we do in translating software) is very
> > much different from translating literature.
>
> This is where I think you're wrong, especially in case of Gnome
> software. Gnome is made for non-technical folks as well, and that's one
> of the guidelines I have in mind.
I think this is *especially* the case for GNOME software. More on that
below.
[...]
> And something being technical doesn't mean it must be "dull or boring".
I never said so... please read the below quote again.
> > While literature translators are given awards for being creative,
> > permissive and "free" in their translations, and also amuse or excite
> > people, technical translation is entirely the opposite.
> >
> > Technical translators do their job best by staying as close to the
> > original as possible in style, even when it means that the
> > translation will be dull or boring in some cases.
>
> No, I don't think the style of original is at all important for
> translation.
Again, software translation is not poetry...
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.
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).
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.
> 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.
> Yeah, even if passive is used
> originally, I might change it to active, if that's how it's usually
> done in my language. Again, I'll use imperative for buttons and menu
> items, but not for menu names. Style should reflect the language it is
> translated *to*, not the language it is translated from.
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.
> > Closeness to the original is key, as bringing the message through
> > with all its details is the most important thing. The information
> > must not be altered or skewed to mean something else or even have the
> > smallest danger of confusing users or being misinterpreted by users.
> > Any other goal is, and should be, far below that one.
>
> I don't see how this is related to the issue at hand. Are you claiming
> that a user unfamiliar with English will be more confused with
> 'Spoznaja' than with 'Epiphany'? I certainly doubt that :-)
No, obviously this doesn't pertain to a user entirely unfamiliar with
English.
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.
This is in fact one of the most common complaints I hear *against*
translations in Sweden from actual users. The number one complaint is
about unfamiliar terminology (when people are used to the English or the
close to English one, and not the proper localized one), but that one is
easy to dismiss as just a matter of preference and of getting used to.
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.
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.
> I think I see your point, but I think your arguments are flawed :-P
>
> 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.
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.
> > This style policy is very much applicable to the translation of
> > names, and the types of names explained above. Since the purpose of
> > the first category (descriptive names) is to be descriptive, and not
> > so much for identification, translating these should be encouraged,
> > since that improves the descriptiveness for users of the other
> > language.
> >
> > The primary purpose of the second category however isn't to describe
> > the function of an application, but instead be an unique identifier.
>
> Even if this was a primary purpose, I think a user shouldn't be exposed
> to it if she doesn't explicitely request it. As I already mentioned,
> names are "translated" all the time (Magyaroszag, Deutschland), and
> when you say any of Deutschland's names, you're still thinking of that
> one and the same country.
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.
> > Even though the name may originally be a result of developers (or
> > marketing people) hyping their application by introducing a "cool"
> > name for it, the name usually serves an important purpose later on as
> > being a reference keyword in related documentation and user forums,
> > and on the web in general for information about and support for this
> > application.
>
> This is a valid point, but from a users' stand, I don't think it's
> relevant. The tools should automate it, like the bugzilla fields in .
> desktop files, and it should all work behind the scenes.
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.
> > The documentation aspect is very relevant in GNOME, as we have far
> > less translations of our documentation than of the applications
> > themselves.
> >
> > Translating application names of the second category can thus be very
> > dangerous if the names in the docs aren't translated, and make the
> > docs much less useful or even useless.
>
> The same is true for country names. I don't know why you're not
> suggesting every language to use the same basic name for other
> countries. If it can work there, I don't see how it cannot work here.
> Once the concept of "name should not be translated" is abandoned, users
> will expect to have to translate the name of the program in order to
> read the documentation. Just like I'd have to translate Deutschland to
> Germany, if I was hoping to find out some information about it in
> English.
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.
Just my own opinion,
Christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]