Hacker News Reader

Comment by Iv | Hacker News Reader

French here, that's my experience as well. I want to emphasize that the huge majority of the non-english native programmers I know are pretty opposed to translating programming languages.

However, my experience teaching Japaneses has been that what is crucial if you want to make a programming language accessible to different nationalities is to translate error messages correctly. Learning IF, FOR, RETURN is not hard. There are 20 words max to learn. You could learn that many kanjis in one day if you needed. However, when you are not good at English, understanding "Access error: Array index is out of bounds" requires another level of understanding and vocabulary.

View on HN

Cannot agree on error messages, had opposite experience with them. I always require all team members to install English versions of runtimes because it is easy to search non-trivial errors on the internet. Many translations are automatic or done by not very technical people and they sound weird in local language, e.g. many terms in Russian, even such simple as "heap allocation", are really weird. An English error that you see for the first time is usually solved via quick search with the first result usually linking to StackOverflow with the correct fix, but with the local language it's often difficult to understand where to start. (But basic English knowledge is assumed)

Maybe error messages should just point to pre-prepared StackOverflow questions*

(* which would probably get closed by s.o. mods)

> But basic English knowledge is assumed

Let's be clear: it is my opinion that today, basic english is a pre-requisite to any programmer.

What I am saying is that people making "native" programming language seem to want to change that and that they are misguided if they think the language is the crucial part. The crucial part are the error messages, which indeed are often very poorly translated.

Yes, heap/stack would look weird in french as well, but as weird as they look in english the first time you encounter them. However if you translate the error message correctly, a novice programmer will understand that it is a memory problem and may try to hunt the error more efficiently.

I learnt my basic English while programming. Definitely not a prerequisite !

I guess this is where error codes come in handy.

Not actually unless it's a native OS exception with a well-defined hex code. I was talking in .NET context, and when you get e.g. some SocketException related to setting up UDP multicast parameters only textual description helps for highly relevant search with double quotes. Often there are just no results at all in local language for highly specific complex conditions.

I speak English natively and Japanese fluently, and in my experience error messages (and other messages) that were translated into Japanese are often of rather questionable quality.

But you're right, people who don't speak English very well (and aren't too experienced) often don't even notice non-fatal errors.

I still think that showing translated error messages isn't very good. 1) Messages are often translated poorly (I won't go into detail here) and sometimes don't even make sense 2) Googling for a translated message won't turn up (m)any results 3) Poor translations might eventually be fixed, but IMO error messages should be considered part of the API

I think the best recourse it to display the original message _and_ a translated message, or _maybe_ an (international) error code and a translated message.

The great thing about the Japanese language is that with kanji you can make messages extremely concise, e.g.:

"Access error: Array index is out of bounds" --> "エラー: 境界外読取/書込"

which would make it acceptable IMO to display messages side-by-side. (It's unfortunate that "error" became "エラー" in Japanese)

I don't quite get the reasoning where you talk about the quality of Japanese error messages, then talk about making it even harder to decipher. Sure you can compress meaning into short strings of kanji, but readability definitely takes a hit when you do that, even to a native speaker. It's not like we're displaying this on paper; there could be better ways to show errors to non-English speakers, eg. more descriptive messages like "エラー: 配列の範囲外へアクセスしています" can be shown by default and perhaps the original error message can show up when you mouseover on it or whatever.

The "searchability on Stack Overflow" argument may vary depending on language, by the way - Japanese is one of the languages where technical information written in the language is fairly abundant (considering JP natives tend to avoid writing in English themselves and rather stick to writing Japanese), but this may not be true for other languages. Another factor is how likely the speaker of the language is to be English-bilingual.

> Japanese is one of the languages where technical information written in the language is fairly abundant

At least with respect to error messages, that has not been my experience. I've almost never had success googling Japanese error messages. That (and the insanity with remembering how to get java to display English error messages, since it doesn't respect LANG/LC_ALL) is 100% the reason why I gave up on using Japanese on my development system.

No way. I hate localized error messages. At least in modern times as software vendors stopped putting error numbers into the message.

It's very hard to find solutions online when you only get a localized error message.

That's a great point. And that combined with the cryptic nature of many error messages could easily make debugging a nightmare for people who don't speak English...

> Learning IF, FOR, RETURN is not hard. There are 20 words max to learn.

That was true in the old days with C or Pascal, but it's not much the case any more. Modern C++ has about 100 keywords [1]. Even Swift (Apple: "easy to learn") has about 100 reserved words.

[1]: https://en.cppreference.com/w/cpp/keyword [2]: https://www.quora.com/What-are-the-reserved-Swift-keywords

Reply on news.ycombinator.com