jump to navigation

The pros and cons of community translations January 1, 2007

Posted by globalizer in Danish, Language, Localization, QA, Translation.
trackback

I just found Netvibes over the Christmas holidays (I know, I know – hopelessly behind the cutting edge…). That prompted me to dig out this draft on community translation that I have had sitting around for a while. And I want to say up front that while I use Netvibes as an example of not quite successful localization into Danish, the site and its services seem very useful at first glance.

Alongside the increasing popularity of open source projects has come an increase in community translation projects – software translation performed not by paid translation professionals, but by volunteers. And this process has been used not just by open source software projects, but also by “regular” closed source projects and by well-known companies such as Google.

This raises an interesting question: why don’t all software companies take advantage of such “free translations”?

There are probably a number of answers, but the first hurdle is surely that if you want a closed source project translated, you need to have a highly visible, geeky and/or sexy web application which provides a free service – otherwise you are not going to be able to find the requisite volunteers. Who would want to volunteer to translate a huge, boring database application which sells for thousands of $$ for a corporate giant like Oracle or IBM, for instance?

Even if you do have just such an application, a number of other considerations come into play, however:

  • The quality of translations – will users give up using the application, and will they jump to the conclusion that the entire product is of poor quality if the translations are subpar? Will this reflect poorly on the entire company behind the application?1
  • The difficulty of maintaining consistent terminology and style.
  • The project management and file handling required to coordinate such a process, plus the need to develop of a number of special-purpose tools, templates etc. to make the translation interface as foolproof as possible . This may significantly reduce the savings from “free translations”.
  • The issue of scale. It is probably doable for very simple and small-scale user interfaces – small enough that terminology coordination can be done without use of extensive databases and simple enough to not require extensive testing to verify that localization has not impacted function – but a lot more difficult to handle for larger and more complex products.

Some of the advantages would be:

  • The ability to provide localized interfaces in many more languages than a standard localization model would normally support (assuming the same level of funding and paid manpower) – with the potential of reaching users who would otherwise not be able (or willing) to use the software. Users with no English-speaking ability at all may be willing to put up with quite a few bloopers in their native language, as long as it gets them access to a nifty tool.
  • The creation of a sense of community among users – the feeling that this is “their” application

The rest of this post focuses on the question of translation quality, since that is what an outside observer can evaluate. And before I proceed, let me acknowledge that poor translations are not confined to community translation projects (and that community efforts can indeed produce high quality in the right circumstances); I have seen plenty of horrendous examples from commercial software that are just as bad as (or worse than) the examples below. Unfortunately, many commercial projects skimp on the translation budget and offer ridiculous word rates. They mostly get what they pay for.

Since everybody in Denmark learns English as their second language from around the fifth grade, many Danes will say “Of course I can translate from English to Danish”. Unfortunately, they often don’t learn to speak English nearly as well as they think they do, and they also often don’t know how to write Danish nearly as well as they maybe should. And definitely not well enough to produce good, consistent software user interfaces in Danish.

The Danish version of the Netvibes site illustrates some of the typical errors committed by people who are not particularly aware of linguistic details or the art of translation:

  • inconsistent and incorrect use of compound nouns and capitalization in Danish

compound2

In the example above we have 6 different compound nouns, all using combinations of the noun “søgning” (search), but written in a wildly inconsistent fashion: with and without spaces between the nouns making up the compound noun (“Blog søgning” vs. “Billedsøgning”,) with and without capitalization of the non-initial word (“Blog søgning” vs. “Video Søgning”). Rules governing these questions are established by an official research body in Denmark and are thus easy to find in their official publications. If those rules had been followed by the Netvibes translators, the strings above would have become:

Blogsøgning, Websøgning, Billedsøgning, Videosøgning, Podcast-søgning, Klassisk websøgning

Possibly even Podcastsøgning – without the hyphen – since the hyphen is only used for proper names, abbreviations and words that are considered foreign words in Danish. The words “blog”, “web” and “video”, although originally loan words from English, would by now all be considered sufficiently Danish to be written without the hyphen.
This way of writing compound nouns, with words separated by spaces, is becoming increasingly common in Danish, probably influenced by English, where strings of words separated by spaces is the standard way of creating compound nouns. Not only is this non-standard in Danish, however, it also frequently creates constructions that literally mean something completely different. For a few amusing examples see this (unfortunately, these don’t make sense to anybody but Danish-speakers). By the way, I noticed that in another section of the Netvibes site the word “web” had been correctly joined with the word “note” to form the compound “webnote”:webnote

I was ready to praise the translator responsible for this, but then I saw that this is actually how the term is written on the English version of the site – so this is just an example of “direct translation”, for once with a correct result.

Another example of incorrect compound creation is from the site footer, shown below. The circled term is the Danish translation of “Terms of service”, and once again, the two nouns making up the Danish term are incorrectly separated by a space. But that is not all – the word “brug” has had a so-called fuge-s (“joining s”) added, and that would be the right thing to do if the term had been correctly written as “Brugsbetingelser”. It is, however, completely misplaced when the two words are split by a space.

compound1

  • keeping the sentence ordering and syntax of the source language, even though this is contrary to normal usage in the target language; or awkward, incorrect and non-idiomatic choice of words, using word-by-word translations rather than conveying meaning (in a Danish pun: “undersættelse”)

In the example below, the sentence “Hvis du vil oprette eller forbedre dit lands sektion, kontakt os straks” uses the exact same sentence order and structure as the English source: “If you want to create or improve your country selection, please contact us” even though the construction of having the imperative after the conditional sentence is very unusual in Danish and in fact sounds distinctly “un-Danish”. The idiomatic way of stating this would be to start with the imperative, like this: “Please contact us if you want to…”.

Non-idiomatic

  • misunderstanding/target translation conveys incorrect meaning

The picture below contains a whole slew of different error types (typo in “farvoritikon”, using alternately the English and the Danish word for the same term as in icon/ikon, using English terms (e.g., “keyboard navigation”) instead of well-established Danish terms, etc. – I could go on for a while here :-)).

But the one example that illustrates this particular error is the one that is circled, and the problem here is that the Danish translation actually says “Only load modules for current tab – Reduces the speed for slow connections”. Reducing the speed would probably be just about the opposite of what you want to do for slow connections, and the English source in fact says “Reduces the load for slow connections”.
Misunderstandings

  • Incorrect Danish grammar

The picture in the previous bullet contains a good example of this: “Giver dig mere plads hvis du ikke ønsker og bruge den”. The “og” should be “at” here – a not uncommon mistake influenced by spoken language, since these two small words are actually pronounced identically. The rule is to use “at” before an infinite verb form, which is what we have in “bruge” (identical in function to the English “to”), however. Another problem is that the pronoun “den” should be “det”, as it refers back to “søgefelt”, which in Danish is a neutrum.

  • spelling mistakes

I am usually fairly forgiving about typos, since they can be devilishly difficult to spot no matter how diligently you proofread – but only if they could not have been found via a simple spell check. So the “Traffik” in the example below could and should have been found (there is only one “f” in the Danish word), as should the “indataste” I found in a message. Note, btw., that here “Blogmærker” is correctly written in one word – again because the English version uses this convention (not common usage for English, I would say).
Typo

  • inconsistent terminology

Consistent terminology usage is difficult to maintain even on professional translation projects, especially large ones involving many translators, of course. For a small interface like Netvibes it should not be impossible to ensure that the core terms are used consistently, but I’ve found both the English word “password” and the Danish term “kodeord” used, however.

These examples are only a partial list of the errors/inconsistencies/awkward constructions that a quick perusal of the Danish version revealed. For a language professional like me they convey an image of sloppiness, since most of them could have been avoided by the creation of just a basic style guide and minimal proofreading. There are plenty of good references (other than the official dictionary) readily available, such as the Danish it terminology reference (although it does not seem to have been updated recently – I don’t see “blog” or “podcast”, for instance). Open source projects like Open Office have published good, brief translation and style guidelines, showing that it does not take much to provide good, basic guidance.

The interesting question is how many of the issues that jump out at me as a language professional are actually

  1. Even noticed by the average user of sites and services such as these
  2. Considered important/an annoyance by the people who do notice
  3. Impact the overall perception of the company behind the site

My (totally off-the-cuff) guess would be that most of the issues would probably be noticed by less than 50% of users? However, I do believe that for the people who do notice, these matters are important, and that they do influence how they view the site and the company in general. Unfortunately, there are very few actual surveys in this area, and the ones I have seen (e.g., from LISA) are based on a very small sample base.
Note 1: Here’s an example from Google’s Picasa that I just stumbled across today. I have never used Picasa and don’t know if Google uses volunteer translators for this product for certain languages. It does highlight the pitfalls of poor translations, whether they be paid for or free, but it is of course worth noting that the critique comes from somebody who is comfortable enough with English to have a blog in that language.

Update: Should I have used crowd-localization instead of community translation?

Advertisements

Comments»

1. Crowd-translations (or community translations) revisited « Musings on software globalization - January 7, 2007

[…] 7, 2007 Posted by globalizer in Language, Translation, QA, Localization, Danish. trackback Back here I posted about the advantages and drawbacks of using volunteer translators for your projects. I […]

2. A least one case where Danish is easier to disambiguate than English « Musings on software globalization - January 13, 2007

[…] by globalizer in Language, Translation, Localization, Danish. trackback In connection with my review of the Danish version of Netvibes I mentioned how noun phrases consisting of more than one noun are constructed by concatenating the […]

3. Translation quality in the crosshairs « Musings on software globalization - July 3, 2007

[…] those translations on their own web pages (with all the potential issues that entails, as discussed here), but I find it very disappointing that they would dump them into the CLDR. CLDR has become a very […]

4. Globaloffensive hack - September 8, 2013

whoah this blog is magnificent i love reading your articles.
Stay up the good work! You understand, many individuals are hunting around for
this info, you could aid them greatly.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: