"I am a developer, and happen to speak english as a second language. As much as I find it's helpful to my users to have the program's text information presented to the user in their native tongue, I really hate it if the tools I use speak to me in my native language.
Some vital parts of exceptions tend to get mangled when being translated, and you can't search for relevant information regarding whatever obscure failure you're experiencing unless you translate it back. And Google Translate doesn't do very well with technical terms.
It is especially unhelpful when the exception has been re-thrown from somewhere deep down, and is being presented with some parts translated, some parts not (I'm looking at YOU Microsoft; "Was this exception text helpful to you?" ( ) No ( ) No (x) Hell No!)"
Reader tlambert recommends such a tool only if it doesn't have end-user exposure:
Google translate will do the job well enough for non-English speakers, and almost every programmer is an English speaker in any case - or used to Google translations of CS technical papers, in any case.
If there's actually UI being exposed to an end user rather than a program, then of course there should be some way to localize the end user exposed content, although you should expect that most users won't end up using it, and will opt for English instead, unless it's for data input for text data for storage and retrieval.
For better or for worse, the primary language for IT is English. I generally think it's for the better, since there are concepts that the English language is better suited to representing, either natively, or with coined words/terms/phrases and/or "borrow words". For the last, French is probably the worst language, since they have "language police" whose sole reason for existing is to prevent "borrow words" entering the French language and "contaminating" it. The next most comparable language for "purity" is Japanese, which was represented by Matsumata Ohta when he attempted to prevent the C-J-K unification of the Unicode standard, and eventually got his way by pushing another Unicode code page so that you could, for example, grep -v the Chinese text out of a Chinese textbook on Japanese poetry. Double the storage size for a wchar_t, just so that they could keep the languages distinct in both encoding and rendering, rather than just in rendering.
Reader dejanc responds with an analogy:
"Being a programmer and not understanding English is like being a historian writing papers on the Roman Empire and not knowing Latin. There is a lot of programmers out there who don't understand English or are not comfortable with it, but as a rule, they are not that good.
You have to learn our profession somehow. Yeah, you can learn C or Java from a book written in your native language, but most APIs out there are documented only in English. If you don't speak English, then your resources are severely limited.
That being said, if you can do localization, do it. Localization is usually very easy and doesn't require much bloat. You can have volunteers do the actual translation, you just need to get the strings ready, so it shouldn't be more than a couple of hours of your time.
Some talented programmers are just not talented for learning languages, or prefer to have UI in their own language. They are the ones who Google Translate documentation online, so you'll be doing them a favor."