9

Are there any programming languages that are available and extendable in more than one natural language?

For instance, an english version with a do..while loop, a Spanish version with a hacer..mientas loop, a French version with a faire..pendant and a Dutch version with a doe..terwijl.

The only 'programming language' I can think of that sort of implements this is Microsoft VBA.

Bonus question: Why are there so few programming languages that come in multiple languages?

  • 12
    English is the Lingua Franca of most programming languages, for better or worse. – Robert Harvey Feb 8 '16 at 20:53
  • 13
    That's a reason why the languages are in English, not why there are no other languages, for example no "Java Indonesian" or "C++ Swahili" -- Because your Java Indonesian program would only be maintainable by Indonesian programmers. – Robert Harvey Feb 8 '16 at 21:05
  • 5
    @DavidArno this topic has been beaten to death in Do people in non-English-speaking countries code in English? and multiple questions linked to it – gnat Feb 8 '16 at 21:48
  • 8
    @MartijnBurger translating the keywords is the "minor issue", in comparison to translating the standard library, which is the "enormous task". And that is also what would cause interoperability issues. Java doesn't depend on the spelling of the keywords once compiled; but it does depend on the spelling of the package, class, and method names. – Dan Getz Feb 8 '16 at 22:45
  • 3
    @DanGetz there is still the issue in Java (and likely other languages) that keywords are reserved. I can't define a field as String for; in Java as that would be an exported symbol in the class. And that would that I couldn't name a field doe either because that's in the Dutch version and having public class Deer { String buck; String doe; } would not have the doe field be accessible. All the keywords are reserved words in Java. Bad things would happen to the fields that conflict with keywords in other langs. – user40980 Feb 8 '16 at 23:10
21
+100

The function names in Excel formulas are localized, where you can use either the English wording or the local equivalent.

This has led to countless occurrences of spreadsheets breaking as you move across regions and user languages. It also makes it hard to search for information on functionality, as the local documentation is localized and doesn't mention the English names of things, and conversely, asking on SO with your local names is essentially meaningless to most readers.

Keywords should be seen as opaque monikers, which just happen to kind of align with the meaning of the English words used to spell them. There are plenty of non-English-speaking programmers out there that don't know what half their keywords mean.

  • 5
    It is surprising that this answer is the only place where the word "Excel" appears, considered the epic failure of translated formulas. Both arguments are valid and very strong: spreadsheets break, and localized versions fragment the communities. This doesn't include the effort by the vendor to translate the docs and the programs (compilers) themselves. – Tibo Feb 11 '16 at 14:36
  • 1
    Why is it so hard to translate keywords in a script? Surely they should be relatively easy to parse since they're already treated specially. – SuperBiasedMan Feb 17 '16 at 12:51
  • Also, Excel isn't really a natural language programming system, since it doesn't translate English sentence structures into executable programs. – Anderson Green Sep 11 '16 at 21:02
16

In the previous century, notably in the 1960-1970s, they have been some non-English based programming languages. In France, we had PAF & LSE with French-looking keywords. WW2 Germany had Plankalküll by K.Zuze. In the Soviet Union, A.Ershov designed some languages (e.g. Rapira) with Russian keywords. IIRC PAF (designed & implemented by my late father when I was a baby - early 1960s) could also be sold with English-looking (or Russian-looking, or German-looking) keywords. And some languages, e.g. APL, didn't have any keywords at all. Other languages (PL/I) did not have reserved keywords. And you could redefine keywords with preprocessor techniques (e.g. today, in C, #define si if & #define sinon else for French students....; similar macro-based tricks are possible in PL/I or even Common Lisp).

But IT was mostly developed in an English-speaking country (the US). So programming languages and their implementations had English specification and documentation and English keywords. Hence, every developer needs to be able to read technical English, and there is no added value to "localize" programming language (and even, doing so makes using other software more difficult, as answered elsewhere). The current technical and economical dominance of English speaking countries requires all engineers to read English today (I'm sure that even North Korean, Chinese, or Iranian software engineers are able to read documentation in English and to read code with English keywords and identifiers). So there is no more enough added value to "localize" a programming language (except perhaps to teach elementary programming to high school kids).

Also, English has many short keywords (compare sinon in French to else in English, or mettre in French to put in English), so there is a tiny advantage in using keywords in English....

Perhaps in a century, China might become the dominant IT country and some Chinese-based programming language might flourish. We don't know what would happen then....

PS. The dominance of English is not specific to IT. Even if the UK leaves the European Union -the Brexit scenario-, the de-facto official E.C. language would remain English (which then won't be the language of any E.U. member countries) and H2020 ICT projects are written in English.

  • Don't forget Plankalküll! – Erik Eidt Feb 12 '16 at 2:07
  • Thanks. Not to be confused with the homophonic French Plan Calcul – Basile Starynkevitch Feb 12 '16 at 8:24
  • I don't know, but I upvoted it, so it is now (alas only) neutral. I found it to be a good answer. – Mawg Feb 12 '16 at 10:02
  • 5
    English is one of the two official languages of the Republic of Ireland, which is an E.U. member. – Matthew Flynn Feb 12 '16 at 16:04
9

There are very good reasons that professional programming languages are not translated.

1) Effort: It would be an enormous task to translate a modern language. Take Java - it would be a small task to translate the 50 or so keywords, but you would also need to translate the full standard library which consists of thousands of classes and methods and related documentation.

2) Compatibility: Even if the base language and standards library were translated, you still couldn't use third party libraries and code which wasn't translated. Third party libraries and code is a major part of what makes a language attractive and useful. With translated versions, each language would have to start the ecosystem for each translation from scratch. Everyone would be worse off.

3) Programmers need to know English anyway. Lots of standards like HTTP, CSS, HTML use the English language anyway for identifiers. These cannot be translated since the words are baked into the standard.

Since programmers need to know English anyway, there would be only drawbacks and no benefits to create translated versions of programming languages.

That said, for languages intended for casual programmers as opposed to professional programmers, it might make sense to create translated versions. This is the case for VBA and I believe AppleScript also existed in translated versions.

5

I don't know of any other languages except possibly some really old esoteric version of BASIC, which tended to come in a lot of strange favors, so I'll stick to the bonus question: why there are so few translated programming languages:

I believe that it's simply an added complexity which compiler and library implementors don't see a great need for. Here are some reasons that contribute in my opinion.

  • You'll limit the audience of your code if you don't stick with a "universal" language. Sure, not everyone knows English, but the same is true for every language.
  • Single word keywords are not necessarily single word in all languages which complicates parsing. I've never checked but I can imagine there being a fair amount of special casing to deal with c++'s single multi-word type "long long".
  • If you begin translating keywords, will you also consider locales, and how numbers are formatted? Comma versus period as a decimal separator for instance. Or require that German nouns are capitalized?
  • The vast majority of the text in a given program are variables, methods, and class names, not to mention comments. While there are certainly libraries written in other languages, having to maintain source code translations of all libraries to serve all users would be a great burden to most developers, not to mention the additional complexity in discussions around such code.
  • Compilers would have to understand all implemented languages. Perhaps even multiple languages in the same file. A small feat for a computer surely, but extra work nevertheless. Perhaps you'll end up having to deal with the same keyword meaning different things in different languages, or terms simply being too ambiguous to read well.
  • (ok, opinionated) Surely most people who have had to deal with MS Office documents programmed and formatted in different languages will dismiss the idea as not worth the trouble.

Personally I'd love it if we were able to work with code in a more structured way, in an editor that actually understood the code as what it is, statements, instructions, etc. that would allow us to do a lot of interesting things, perhaps even support automatic translation. For anyone wondering what I'm blabbing about, check out Smalltalk's image and refactoring browser, and imagine what it could become if it had gotten more traction.

3

If you have a language that is defined in terms of "symbolic tags" on one level and "surface tag designators" on the other, with well-defined mappings between them, it would certainly be possible.

Imagine a language where you have your if, while ... do, switch and all other keywords defined (somehow) in the standard, you could ship system libraries in "tokenized format", with local code written in the non-tokenized form. Then the actual compiler works on the tokenized layer and may things are good.

However, this isn't the whole story. You would still end up in situations where you have libraries gotten from somewhere that isn't "the standard library", interfaced by function names. And those would not have a canonical mapping between languages and would either requiring translation into a local language to be nicely usable, or you end up with a mishmash of languages in your source code.

2

All answers given are great answers, but I will give my two cents anyway.

In the beginning of computing the technical, cultural and economical dominance of the USA and the UK made it only logical what the most successful languages were created using english words.

Later, as software became an industry, it also became a global endeavour. It's not a secret that there are less programmers than needed, so software companies, and specially industry-defining companies like IBM, began to hire programmers from all parts of the world: Russia, Pakistan, India, France, Germany, Israel, etc. mostly to program in already existing globally successful languages which were already english-based and also creating new languages, and for that disparate source of programmers the already existing common language was a better go than any other language.

Most recently the open source and free software movement made the creation of software an endeavour which is even more global than before. Some open software projects, including some programming platforms, languages and frameworks are huge projects involving hundreds of collaborators.

What language would a person from Israel use to collaborate with a person from Sri Lanka? Most probably they don't speak or even read each other's native tongue. So english comes to the rescue.

Like it or not, english is the language of global endeavours. And not because America is pushing it but because the world is pulling it.

Paraphrasing Jay Walker:

Your native tongue is the one you most use everyday, and will always be at the center of your heart and your brain, but with english you are part of a wider conversation.

See video, "English Mania".

Bottom-line:

Programming languages that use different languages will continue to exist and will continue to be invented (like graphical-token-based Scratch), but at least in the foreseeable future te hey will be comparatively few.

-2

English is also an "accent free" language, also you have no strange character that need an encoding different from ASCII. I'm italian and sometimes I face encoding errors if I use an italian keyboard layout or accented characters like àèéìòù. Moreover "else" is translated in "altrimenti", "in" is "dentro"... that would be frustrating.

  • 9
    This is circular reasoning though - ASCII became the standard charset because English is the lingua franca of computing. – JacquesB Feb 11 '16 at 14:29

protected by gnat May 13 '16 at 0:18

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.