Manual translations

Probably the most frequently asked question to the docs team at MySQL from the public is “I want to translate the manual into [insert language]”. That language can be anything from one we already have, through to some comparatively obscure suggestions.

We never summarily turn down an offer, but we do point out how big a job the process is. At over 1900 pages, the manual is no longer a small project, and where we have had translations completed, sometimes by professional translation outfits the process has taken months, and in one case over a year, to complete by a full time translation team. Even the dedicated MySQL enthusiast is going to struggle with achieving the same level of output.

Even if you could commit to a translation time of 6 months using a dedicated team, you have to keep in mind that any manual translated in this manner is not going to be up to date, for the simple reason that we make changes to the manual on a daily basis—there have been 127 changes in the last week, and some of those include more or less completely reintroduction or manipulation of the content for a chapter. It would be almost impossible to start complete translation unless the process was conducted on a very specific revision of the manual.

If the process is so difficult, why do we do it?

Well, cast your minds back a few weeks to a post I made a couple of weeks ago on translation (Foreign languages and documentation).

Reader stenone asked “Why bother translating at all?”

As an Englishman (albeit with an interest in other languages), I felt completely unable to answer that question, so instead I asked other members of MySQL to comment. The majority of staff at MySQL are not English, American or Australian, and those of us who would count English as our first language are in a minority, rather than a majority, so the question and audience were well matched.

I got a lot of good responses (thanks team!), and many of them resolved down to “we want to provide the documentation in a format that makes it readable for our customers”. That sort of answers the question—we are customer focused, and if the customers say they want a German version of the manual, we should be willing to offer that, but I still don’t think it addresses the original query.

Other suggestions were along the lines of “for our customers to use our products, they need to be able to understand how to use them”. This response is closer to the answer I was expecting. We cannot expect our users to learn English just so that they can read the manual and in turn use our product. System requirements are one thing, but having user requirements of this magnitude is hardly the way to encourage good customer relations!

We Brits have a bad track record on languages as a rule, and it’s a running joke that our attempts to speak a foreign language generally simplify down to speaking L-O-U-D-L-Y A-N-D S-L-O-W-L-Y on the basis that “Johnny Foreigner” will understand what we are saying. Apply that to a manual and we’d be approaching 5000 pages :)

In the end I think it comes down to a simple case of understanding. Imagine if MySQL, as a Swedish company, only provided their manual in Swedish?

Would it be as popular as it is now? Would MySQL have led to a massive effort around the world as people strive to learn the Swedish language, just so that we could all use MySQL in our projects?

I doubt it.

Instead, we’d all be walking around saying “Jag kan inte tala svenska”. Or we’d spend most of our time muttering “Jag förstår inte” under our collective breath while reading the manual, and probably not because of the technical content.

If you don’t understand those two phrases, then imagine how it would feel to read an entire manual!

Translations are, and will continue to be, the best way to reach the large numbers of MySQL users who do not speak English and either are unable or do not want to learn.


Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice is preserved.

With thanks to Perth Counselling to keep FSM editors sane.