Category: Localization

A link to this post on  using Google Translate (or not) popped into my Twitter feed this morning and I was just talking to my wife (a Spanish Language tutor and occasional translator) about using Google Translate. Together, those two events hatched this post on how it Google Translate can work for you.

Is Google Translate good enough?

In Bill Swallow’s post, he answers that question with it “depends on three core content facets: audience, subject matter, and quality. ” A comment to that post included a link to the results of an evaluation of machine translations from international English to Spanish, Norwegian, Welsh, and Russian, which showed, “the machine translations of international English are usually satisfactory.” Having worked on content intended for translation, the use of  international English, should be emphasized.

Translating a web site with Google Translate

My wife has a client who is a sole proprietor with a simple website. Her client wants to expand and serve more Spanish-speaking clientele. As a small business, her client doesn’t have a lot of resources to support the web site–keeping it up-to-date in one language is more than enough work for her client, adding another language is basically a non-starter.

The content on her client’s site is somewhat technical, so running it through Google Translate produces marginal results. When my wife asked for some ideas, I suggested that rather than translate all the pages to create a Spanish version of the site (what her client originally asked for), she review and edit the site’s English text to improve the results that Google Translate produced. That way her client would need to maintain the website in only one language (English) while providing the required content for the Spanish-speaking clientele her client was hoping to add.

(Update: Feb. 2, 2018) After my wife showed her client a sample of how editing just the English text of the site could serve customers in two languages with a single site her client was thrilled that she could get the results she was after and not have to pay her web designer to duplicate the site in a new language.

Does this work for technical documents?

Very much so, if you:

Continue reading “Using Google Translate as your content strategy partner”

I’m working on a project for an international customer base, initially supporting the Spanish and English languages. Having worked on international projects before, I knew that I’d have to make some accommodations, but I was still, in the 21st century, surprised at how un-automatic the process still was to make it all work. The surprises I’m seeing are now less frequent, but I no longer trust that I won’t find another around the next corner.

The project

I’m developing a small patient automation system (the piClinic) for use in limited resource clinics in developing countries. While there is no shortage of Electronic Health Record (EHR) systems, they tend to work best in well-funded and well-supported clinics and hospitals. For everyone else (which is a rather large population) there are virtually no suitable systems, especially for small clinics in countries that do not (yet) need to support the comprehensive (and complex) data collection and reporting requirements for health information in the U.S.

The piClinic system is designed to fill the gap between zero automation and complete EHR systems until that gap can be closed or the clinic grows out of it and becomes able to install a more full-featured system. Given that much of the developing world speaks a language other than English, internationalization is something that needs to be built in from the start and not just bolted on as an afterthought.
Continue reading “Wrestling with UTF-8”

Just three days after I post about how I was going to consider the minority, I post how  software development documentation should be written and published in just English.

Three days.

Am I ignoring my theme of the year (or the week)?

I don’t think so.

I did consider the rest of the non-English-speaking world (which is actually the majority of the world), when I thought about that. Will anyone be harmed by a lack of API documentation written in Miskito, for example. I don’t think so. If it turns out that they might need it, however, I’ll revise my decision. But, what about in Spanish? Possibly. But, from the information I have available, probably not. Inconvenienced, might be the worst-case scenario.

So, while I won’t be writing any technical documentation for the Miskito people of Central America in the immediate future, they haven’t been ignored in the decision. As a side note, later this year, I will be helping to give them something they need much more than technical writing.

The point of this year’s theme was to consider the vast minority–include them in the design and thought process. So far, I think I’ve done that (for going on four days, now!). The point is to consider them. Include them in the design process. Ask the question, “Will not accommodating the minority hinder, or worse, harm them?” Sometimes it will, such as in the case of accessibility aspects of documentation. Sometimes it won’t, as in the case of translating or writing for people who have no use for the documentation in the first place (i.e. there are other problems to solve before that becomes an issue). In either outcome, they were included in the process.

Four days and counting…

I’m mixing a some of my favorite themes, music videos that feature dance numbers and technical writing with a dash of Latin culture.

(Bear with me… or skip to the technical part)

Latin pop star, Enrique Iglesias made this video of a song in Spanish. As I write this, it had over 648-million views since it was published April 11, 2014. About 65-million/month.

Released a few months later, on June 13, 2014, was this “localized” version in Spanglish (with mixed Spanish and English lyrics). It has had only 90-million views. About 13-million/month.

Now there are a lot of reasons that could explain such a difference (and 13-million a month isn’t shabby, by the way), but in listening to them both, I’m with the majority and prefer the original.  Both versions are good, but they are different and they each have a unique feel to them. To my ears, the all-Spanish version has more feeling and is a bit more romantic. In comparison, the Spanglish version doesn’t have the same sentiment, to my ears. You can compare the two sets of lyrics for yourself, if you’re interested: Spanish lyrics and Spanglish lyrics.

What’s this have to do with technical writing? (Thanks for hanging in there, by the way)

In code samples and technical documentation, like music (and many other fields), the original is almost always better than the translation. The best information about developing with a software library or API is going to be in the original language, which invariably is English.

So, as a technical writer of developer documentation for a software product with an international audience, should you write in English and/or localize the technical content? In the absence of evidence to the contrary, my default answer is, Yes you should write the documentation in English and No, you shouldn’t localize it. Localization is guaranteed to be costly and not guaranteed to be anything more than marginally beneficial.

Over the years, I’ve collected a lot of anecdotal information on this, but this is one of the things I’ve wanted to study more formally. Anecdotally, international developers believe that the translations aren’t as good as the original English version and tend to prefer the original English version over the same content translated into their language. One reason might be that software has a lot of keywords, class and method names, and the like in English which can’t really be translated. If you read the original, you know you won’t be tripping over inappropriately translated terms.

I have some info from my recent API documentation study, but it’s a bit tangential to this topic.

Yet another study to put on the list.