A translator’s view of localization

Via the Honyaku mailing list, I read an interesting article on localization from a developer's perspective. As both a translator and software developer, I'd like to comment on this article from a translator's perspective.

The author (Wil Shipley) recommends that you only send string files to your translators to localize:

To make our localizers’ jobs easier, what we’d like to do is give them ONLY .strings files, so all localization takes is any text editor – localizers don’t have to know how to use Interface Builder or any developer tools.

This is better than sending proprietary files that require special software to edit, but isolated strings tend to be cryptic. What's worse, the context could affect how the string needs to be translated. To give an example, I can think of at least three translations for the string "Files" into Japanese, depending on the context: "ファイル", "ファイル一覧", and "ファイル数" (lit. "files", "list of files", and "number of files").

You can get around this somewhat by avoiding ambiguous language in your strings. But although clear text is a good goal for software, it's also well known that every extra word you add to your on-screen text decreases the chance that your users will actually read it.

There's thus a tension between providing clear, unambiguous text and making your text as short as possible (and thus introducing ambiguities). The problem is exacerbated when you localize into multiple languages, because each one is going to find different ambiguities in your (to you quite straightforward) text.

Give your translators screen shots

One good compromise is to provide screen shots with your string list, so the translators can see the context of the strings they're translating. It'll also given them an idea of how much space they have to work with. (By the way: always lay out your text with plenty of space if you're going to be localized!)

When you get your strings back, you'll have to collate them back into your string resource. If you find the same string translated two different ways, first confirm with the translator that this difference is necessary, and if so, branch your string resource into two strings, corresponding to the same original string but different translations. This takes some extra work, but you can automate it so that it's done with every build.

One more piece of advice: don't split up your strings. For example, if you have range of dates with variables interposed ("From {1} to {2}"), don't send your translator the strings "From" and "to" to translate! Give the translator the entire string, or if it's a form with input widgets, give that context.

4 comments to A translator’s view of localization

  • Great minds think alike.. I wrote a response to that entry myself.

  • […] See also the response by Ryan Ginstrom, a real-live programmer and translator.   No comments yet—be the […]

  • Working into an inflected language, I would go even further: While screen shots help a great deal, they do not explain the underlying software functions. Like when the string says “None” – none of what? And I have to know what, to get number and gender right. The same with variables. If I don’t know the content variables can take on, how can I decide on the gender of the surrounding modifying words. Another lack-of-context problem: With English as the source, I often don’t know whether it is verb or noun. Is “Copy” a copy of something or the verb “to copy”? Is “order” an order or the verb “to order”? “Cancel Order Transfer” – is that canceling the order transfer or transferring the cancel order? For a good portion of strings, I would like to be able to check the manual and read what the program is actually doing before committing to a particular translation. Without manual, even looking at screen shots, it would be guessing at best. So it’s context, context, context – for correct grammar and for proper meaning.

  • @Michael

    Very good point. Ideally, the UI and manual should be done at the same time and by the same person, because the manual helps with context for translating the UI, and the manual usually contains quotes of on-screen text (select this menu item, click that button).

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>