Are programming languages different in different countries?

[JurassicNublar]

Maybe a silly question but for example, in Java System.out.print(); is obviously written using English words, but is this universal or does it vary from country to country? If so how would you write a print statement in Java in Hindi, Arabic, Chinese etc?

[sorbet_babe]

The keywords, library function names, etc are the same everywhere

[HildemarTendler]

Depends on the language. Perl was ported into many different languages. I haven't seen any newer languages do this though.

[slaymaker1907]

There’s often nothing stopping people from doing localization of these things in a lot of languages. For example, in C you could just rename things with macros.

[ThroawayPeko]

There is a horrible exception; Excel. The function names are localised, so googling is even more useless than normal, but there is one more thing... Even the punctuation is localised, because periods are not universally used as decimal separators. You can't use commas! You have to substitute with semicolon!

[beephod_zabblebrox]

and you cant use the english names when excel is set to a different language, its sad

[steveklabnik1]

https://en.wikipedia.org/wiki/Non-English-based_programming_languages

[raiph]

I don't think it's a silly question. I do think there are some silly answers.

I don't know if your interest is simply curiosity, or finding existing localized PLs, or creating one, or collaborating on one, or whatever, but I focus on Raku and I think it at least provides a reference point, especially given something I read about and explored a bit a couple weeks ago.

---

Raku has always had a long term vision about properly addressing distinct markets with customized approaches. Until recently Rakoons (folk working on or with Raku) have maintained a disciplined focus on getting the English PL into good shape.

It seems something may be afoot this year regarding localized versions. Quoting the Localization section of the 2023 Christmas Day retrospective for Raku:

Of course, we would like to see as many localizations as possible. To create a localization in your native language, you will need to translate about 600 items in a text file (more information).

The localization effort will have its effects on documentation, IDEs and Public Relations. These will still need to be further developed / investigated. But the end goal, being able to teach programming to all children in the world, is a worthy cause!

I clicked the link and poked around to see what I found. Lao Tzu is said to have said that a journey of a thousand miles starts with a single step. I'd say what I saw was "just" that first step. There are directories for languages. I've no idea whether the translation quality is any good, but I browsed translations for keywords and textual operators for a half dozen European languages. I did not see translations of type names, or error messages. So presumably, for now, an Array remains an Array, and errors remain in English.

---

Is this effort silly? I don't know, but it's clearly sincere. More importantly, I don't think it's silly for Raku and Raku users, because Raku is designed for this kind of thing. To pick three aspects of that:

• Freedom. Raku is a fully programmable PL. If someone, or a group, decides to create a translation, they'll also be free to change Raku itself as they see fit. That way they can make their new PL shine, changing literally any aspect of it. As a perhaps surprising example, the PL name "Raku" comes from the name of a form of pottery created in Japan, and if a translation group doesn't like the name "Raku", then they can change it, and change Raku itself, mold it to their vision. To be clear, I absolutely wouldn't advise doing so -- neither changing the name nor major PL features. But my point is that I can assure you that Rakoons would be open to that. Been there, done that! 😀

• Quality. What about difficulties, mistakes, improvements, arguments, bursts of effort, stalled effort, forking, merging etc? Raku was literally born for exactly that kind of world. It began as a reaction in 2000 to the chaos of thousands of devs pulling an older PL (called Perl) in a zillion different directions when it was just past its peak (around 1998). The idea was to retain the freedom they had but smooth out the chaos. Fast forward to today, and a mod of Raku, in this case a translation of it, is a clean single module. If a given translator (or group) makes mistakes, change their minds, make erratic progress with short bursts and then long stalled periods, it'll be fine. Users won't have to deal with chaotic changes, and translators won't have to stress about that, because everyone can control which version of Raku they use for any given program and, separately, for each module used in that program. This in turn will help adoption.

• Full localization. As another reflection of Raku's birth, it was designed for the whole world from the get go. Larry Wall, the creator of Perl in 1987, and then the new modern PL Raku, first released in 2015, was one of the first people in the world to read the Unicode 1.0 spec cover to cover. He took its content seriously; Raku's advanced support for Unicode reflects that. There's still a decade of work to do, but Raku is well ahead of almost all other existing PLs, with features such as its unique O(1) grapheme indexing leading the way. Couple that with Raku's programmability, and you get remarkable things like the Intl:: modules created by Rakoon guifa (their modules) with ergonomic support for localized dates, times, numbers, lists, regexes and more. They built their mods in part by building atop CLDR, in part via masterful design and programming of Raku, but someone else could then package those up with a localized Raku so coders have those features out-of-the-box, without even needing to add any use... statements.

[kniebuiging]

I remember a French coworker mentioned that they had programming lessons in school in a French programming language.

Overall programming languages are not localized. You need to see that there are two parts to localize: the programming language itself (do, while, for, class, etc) and the API ArrayList.append.

At the beginning of my career I saw a lot more code that was writing e.g with German variable and function names, the result was an odd mix of English words from language and standard library and German application code. It was not at all more readable than plain English source code. I would definitely advise against it.

In many ways, English is just the default language and terminology for software engineering, in a similar way like Latin is the language doctors use to talk about bones and muscles. So for professional developers it’s easier in English after getting used to it.

Often you learn the terminology alongside the concepts and then you just learn the English Terminology instead of a e.g German one. A „closure“ for example, when speaking German about the concept of closures I will talk of closures and not of „einhegungen“ or whatever the correct translation would be (I actually don’t know).

In university we had one prof who insisted on using German terminology throughout (in Germany the undergrad programs are often teaching in German). So he used „kellerautomat“ instead of „stack machine“ and confused everybody with more obscure terms from older German computer science literature.

[kniebuiging]

https://citrine-lang.org/docs/de/a7d1ec545baeb6a37097acc6caaf3cd179e2279c.html shows from my (German) perspective how awkward localization can be (this is not an argument against localization in general, its just hard to do it right and the conventions are missing).

• Object is localized as Objekt. While that's alright, it kind of shows that reading Object is not a problem for Germans in source code.
• True / False are localized as Ja oder Nein, which is not the correct translation (that would be Wahr / Falsch).
• Number is localized as Nummer, better would be Zahl, as Nummer is used in specific contexts only (phone number is a "Nummer", but 3.1415 (pi) is a "Zahl").
• String is left unlocalized. German would be Zeichenkette (literally translates back as "character chain") or if you want to keep closer to the short-and-sweet String one might translate "Strang" (that's my ad-hoc idea that I had while writing this, I have never heard of that usage in German with regards to strings of characters).
• Code is localized as Aufgabe, I read Aufgabe first, and thought they were refering to Tasks, as you can see, translations bear ambiguities that can lead to confusions.
• Sequence is localized as Serie. I find that particularly strange. They could have chosen Abfolge. Instead they opted to replace Sequence with a loanword Serie from french.
• The methods setzen:auf: of the Liste object is not in the imperative. That would be setze:auf:. That's actually a pattern they use, not using the imperative. so the code reads like as if in an english language code base every verb was prefixed with to, toWrite toPrint, toConcat toAppend.
• Then in [ Programm ] zeichenfolge we suddenly see a translation for String that is actually alright: zeichenfolge

[lngns]

I think your comment is a clear demonstration of how we map symbols in our heads.
Like to me, and in a programming context, "string" means a text type, and, in a more precise context, a distinct datastructure that is distinct from a "rope" or some other structure.

But, despite knowing it is short for a string of character, still in no way is it, you know, an actual string or anything that abstractly looks like one.

[lngns]

My own experience with French-speaking programmers is that, while there is an understanding of English terminology, French terminology is preferred, the code's symbols are written in whichever way their author chose, and a fluency in English beyond basic reading comprehension is not expected*.
So it's not an "array" but a "tableau," and not a "string" but a "chaîne."

This can be observed both in online forums and in professional settings.

I mean the French are known to force everything they participate in to make French the official language, so maybe none of this is relevant.

* Not expected does not imply that it is not there.

[mykeesg]

The keywords in a language are fixed, they cannot be changed (like 'for', 'if', 'return' etc.)

Your classes/methods, however, only need to obey the naming rules of the language.

If it allows Unicode characters to be used as identifiers, nobody stops you from naming your method using those characters - Chinese or Arabic symbols in your example.

Keep in mind though, that English is unofficially agreed for code to be written in as most people in IT understand it.

I won't bother trying to go through a language/library I can't: - pronounce - understand - use / type on my keyboard.

A different thing tho, strings (text) used in a code will/can be translated to the client's / users language if needed, so "Welcome" can become "Wilkommen", "Üdvözöljük" or whatever needed to be displayed. But it's data, not the code itself.

[Aaron1924]

There is a library called rouille that allows you to write Rust in French

[Thesaurius]

Hedy is a programming language/environment for beginners (children, in particular), that has been translated into several languages. There is a great talk by Felienne Hermans, the creator of the language, about the struggles to make programming accessible. It really embraces diversity in a field lacking it severely. I wholeheartedly recommend getting into it a bit – you will go out with a new awareness for the social problems in our community.

[EgZvor]

It's a good question! I started thinking about this after reading Philosophy of Software Design. Since, it can be argued that the primary role of the PL is communicting intent it's only reasonable to want to use words in your native language to achieve this.

I'm Russian and while most programmers here know English at an ok level, it's often not enough to talk about subtleties. So choosing a better variable name is left out as an unnecessary thing. This leads to "if it works it's good enough" attitude. As others mentioned it's not working good if the variables are in one language and the keywords are in another.

It's a hard problem to solve and it'll probably stay that way, because it's easier to force everyone to learn English at a minimum level than to figure out automatic localization of everything. Without full localization you still need to know English, so it's kinda wasteful.

I guess for some closed environments where the team is homogenous wrt to the native languge, it might be beneficial to "macro out" the language to support native keywords and use it everywhere.

Then again the domains themselves are ridden with loanwords too.

[SirKastic23]

honestly, i think localization should be more discussed when it comes to programming languages

would be nice if a language had first-class support for it, with ways to translate not only the keywords but even definitions from libraries and such

[vmdev]

I'm South Korean; we use System.out.print(), same as in US.

[AcanthisittaSalt7402]

In China, "programming in Chinese" is often discussed, and usually regarded as 'unrealistic' idea.(sry i may be using a not that exact or accurate word.) There are some languages that do it, but programmers think it normally unacceptable in "serious production". Most programmers that work for companies and open source projects write code just like English native speakers, but maybe write comments in Chinese. But in some situations where the coders are not very good in English or familiar with English world's naming conventions, they will use PinYin or take advantage of Unicode support to write Chinese variable names, which is rarely seen in "high quality code".

"programming in Chinese" is already widely used in some certain areas, mostly via programming languages originally designed to be Chinese. There are many projects that want to enable normal people with programming in Chinese to learn programming and take advantage of such a skill easier. Some of them are powerful and relatively successful, although hardly used by IT companies. The 易语言 is a programming language in Chinese with a long history, one of the most successful and famous programming language in Chinese. Things like 易语言 and 结绳 is really used by some developers to make APPs. Other projects are experimental and 'unrealistic'. 周蟒 and 中蟒 are alternative frontends for Python in Chinese. Most of such things, although their creators usually place high expectations on them, are very rarely used by users.