Citrine: Localized Programming Language
citrine-lang.org
citrine-lang.org
Programming languages should imo from the offset be steps ahead of this. They have simple rules that can be parsed despite understanding the subjectives. I could probably understand some rust code written in mandarin after studying it for a while. In our line of work it is important with clear communication. Spoken languages are not good ways of accomplishing that.
That is to say: language keywords, function and variable names, comments, documentation, and perhaps even multi-token structures might all require associated translation strings.
And as with translating an application (or any text, really), the source material might be written in one native language, and only later be translated into others based on demand and interest.
Software projects have the interesting property that partial translations might make sense under some circumstances. A commonly-used API function could be translated first, for example.
It'd be impressive to work on a project where multiple developers are each individually contributing to literally the same codebase, but each reading and writing it in their own native language(s).
(clearly a situation like that would require a lot of input from translators too - ideally with context for the software language and the project itself)
It's like whoever did the translations just took the English version and chose the first entry in the dictionary without even a second thought.
The translations are definitely machine translations and not done by native speakers. This results in hilarious constructs that are hard to decipher even when knowing the context.
As soon as I saw inconsistent grammar and even simple words being completely mistranslated, I dismissed the whole thing.
You’re confusing keyword/identifier localization for natural language. I agree with everyone who says NL is the wrong problem to solve, but that’s not what Citrine is attempting to do.
Look at it this way: Citrine code is NOT natural English either. At most, it is a sort of “pidgin English” where individual words can be readily understood but the grammar is wholly artificial.
For instance, a Chinese or Japanese dialect should continue to use whitespace to separate identifiers. It’s a programming language, not a natural one, and that difference is the point. Trying to “fake it” leads to dead-end mistakes like AppleScript. Trying to do it for real creates exactly the sort of ambiguities and imprecision that a programming language is meant to eliminate.
It’s about finding the right compromise between human accessibility and machine precision, and anything that breaks down barriers between the traditional US English-dominated programming world and the billions of humans who speak something else has got to be a step in the right direction.
Totally agree. TBH I don’t think the authors’ enthusiasm, while admirable, is quite matched by their knowledge and experience. A bit more up-front learning could probably save them disappearing down some obviously wrong paths.
As you say, they should focus on verbs and nouns, and getting those to machine-translate precisely. Nailing that would be a big deal just in itself. If they later want to experiment with adding prepositions to make code read “more naturally”, make the system add those on a per-language basis according to per-language rules laid down by native-language speakers.
Thus in English the method signature might present as `animate(from: source, to: target)`, because that’s what English readers expect and like. But that doesn’t mean that `from` and `to` should be translated to every other language, because that’s just an exercise in cutesy-clever nonsense, burying what is significant under what is not, and software already suffers from more than enough of that.
Almost nobody got that right.
https://en.wikipedia.org/wiki/Non-English-based_programming_... has a list of languages that do at least as well (I think AppleScript tried to do better, but can’t find examples)
Of course, switching language for the programming language itself won’t translate identifiers, so multi-language teams still will have to decide on the language(s) used for those.
Honestly, simple string replacement isn’t good enough to cover any languages. Homonyms and synonyms, anyone? I suspect machine translation will be harder with code simply because there’s a lot less contextual information around individual words compared to ordinary prose with which to make a best guess as to meaning.
“I think AppleScript tried to do better, but can’t find examples”
Dr Cook’s HOPL paper on AppleScript gives an example of French and Japanese dialects (p20; can’t it paste here as it’s an image):
www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
Not really the same thing as Citrine as it relied on manual localization of an application’s resources (custom keywords defined in AETE terminology, vs labels and tooltips on GUI controls). And, as you say, it did not do anything to localize user-defined words.
In any case, AppleScript is a really good example of how NOT to design an accessible language syntax. All the rigidity and tolerance of a machine language, with all the complexity and ambiguity of a natural one faked on top. (Plus all the fun that comes with arbitrary keyword injection—argh.)
This is why I say artificiality is good. Humans aren’t after Shakespeare, they’re after high-level understanding of program code.
I think, for this case, that’s mostly solvable by being careful to not make assumptions. For example, you should create separate translation strings for the ‘for’ in “for…in” and in “for…each”, and for the ‘define’ in “define function” and “define procedure”.
Also, when (not if; if your language is successful, it will happen) translators report problems, you should ‘simply’ not hesitate to introduce new ‘clones’ of to-be-translated words.
Even ignoring languages with different word order, that wouldn’t make things perfect. For example, there will be languages where the correct way to say “define” depends on the (perceived) plurality or gender of the function name.
I think the correct way to handle this is by letting the translator produce a grammar for your language that produces the same tokens as the ‘original’. That probably is beyond many would-be translators, though.
Unless you are working on an isolated system in an isolated setting that will be destroyed rather than merged, none of this helps. It's the same as localised programming some people do today where you simply can't work together because you lost the most important common denominator.
`Object` is translated to `宾语` which means the grammar component object in subject, verb, object, etc.
The `power` operator is translated to `功率` which means A measure of the effectiveness that a force producing a physical effect has over time.
`Ceil` is translated to `细胞` which means Cell ???
:-(
Sounds right (though OOP treats objects artificially as grammatical subjects, they are the things on which functions operate, and thus more like what would normally be grammatical objects; they are the patients rather than the agents of actions.)
Imagine translating a medical or legal textbook without knowing the proper professional medical/legal terminology. Those target audiences will tear it a new one, and quite right too.
+1 for authors need to do their homework better.
This concentration of asterixes had me laugh out loud. Anyhow, this reminds me of so-called “auxilliary”, constructed languages of communication, which are supposed to be easy to learn all over the world for as many people as possibe all over the world. In reality though, they’re almost without exception wholly eurocentric, built mostly on germanic and romance languages, which barely covers one of the main language families just in europe... likewise, this citrine promises grossly more than it delivers.
Though we shouldn’t stop at that; if we look away from what it claims to be, what it is seems pretty neat. For education, maybe this is great.
User feedback was interesting. Some non-native speakers of English objected to this, on the basis that it was a lot easier for them to distinguish language keywords (in English) from user symbols (typically in the user's language); language acted as a kind of syntax highlighter for them.
Also, they felt it disorienting to express in their own native language programming constructs that they'd learned in English. For example when one translates "a `while` loop", the keyword `while` is often left untranslated as there is no equivalent domain-appropriate word in the target language, and the generic translations don't "sound" right.
It’s not a coincidence that big search engine vendors are also busy on machine translation. It’s not a zero-sum game/catch-22. Rather than look at where we are in 2020, consider where we should be in 2030. As automatic on-the-fly translation of general search results improves, programming-specific search results will naturally improve too.
Trust me, going from natural-language English to programming-language English is just as discombobulating. (Been there, done that; made a deliberate point of remembering that experience.)
If you’re only testing it with existing programmers, you’re bound to skew your results because anything new and different to what they’re already used to is a disruption to their established flow. As in any scientific research, designing the right control for your trial is critical to avoiding GIGO.
A better test would be taking groups of English and non-English non-programmers, and teaching both of them entirely from scratch. (This assumes, of course, that each group’s teaching materials have been human-localized to the same standard, and all trainers follow the same script.) That way you avoid polluting your results with preconceptions and existing biases.
Out of interest, is there any more public information of your work here? iris-script[1], my own end-user-friendly language project and obvious anagram, has a way to go before I can begin to explore localizability, but it’s on the TODO list so I am collecting links to relevant material. Ta.
--
In a way, we already have this test today. Most of the world's programmers are non-native speakers and, by and large, they learn programming languages where keywords are based on English. I've heard people thinking that language localization would be a cool thing, but I haven't heard anyone complain about it not being available.
> Out of interest, is there any more public information of your work here?
No, my comment is all the public info there is about it. My $.02, localizability wouldn't be what I would worry about for a proof-of-concept language.
To answer some:
- Yes, we use machine translations, they serve as an example, they are far from perfect. Some language files are translated by native speakers. I think the website needs to be more clear about this.
- I use gendered language because coding is a men's job, women belong in the kitchen! ;-). No, just joking. Women are also welcome to become Citrine users. I just think the opening sentence is beautiful, it combines the concepts of male and female in a lovely, natural way ignoring today's PC-bullshit.
- No, Emoji-language is not allowed in the core. I only support natural languages. Endangered languages (EGIDS6 and higher) are also welcome. There is no limit.
I understand that there will be a lot of hate because of this language. I even received death threats over it. When a young developer I worked with brought up the idea I even laughed at him. However as I thought it over, the idea began to grow on me and I longed for a purely Dutch programming language (I had created one as a child for the C64 by just overriding the BASIC tokens). I figured that, if I longed for such a thing, maybe others do as well. I decided to share my code after some years just to give anyone interested some kind of basis or just discuss it.
It is important to realize that Citrine is trying to strike a balance. Programs will never read like a book. However, having a programming language using your own words and grammar just feels better and makes me more productive, I also tend to make fewer mistakes. The problem with just mixing Dutch with English programming languages is that is extremely ugly, also you never know when it's justified to use Dutch or English, especially when interacting with established English conventions, 3rd party software libraries or embedded languages in code (like shell or SQL). The other solution, translating everything into English is just horrible. I have encountered so many bugs that stemmed from miscommunication because of translation issues to English that I believe this will become a dead end eventually. One technique I am working on, that might help to improve the readability even further is simple macro processing, so you can say 'create a new Object' instead of 'Object new'.
Anyway, if you have any questions let me know, always happy to answer ;-)
Honestly, I am astonished that you can be so conscious of the effect of language on thinking in the context of programming, and yet so tone-deaf when writing your copy. This is not "today's PC bullshit", it is an effort to eradicate structural sexism going back at least half a century. It is not lovely and natural to use "man" as a default for "men and women" - it rings strangely to the modern ear, and you have attracted a number of comments about it. Maybe 40 years ago taking this position would have been forgivable, but in 2020 you are very much on the wrong side of this battle.
I commend this article by Douglas Hofstadter to you. It was written in 1982: http://leeclarke.com/courses/intro/readings/Hofstadter_Chang...
https://jaxenter.com/wp-content/uploads/2017/04/women-in-com...
This is unfriendly.
>If they feel offended by words they probably don't belong outside the house.
I'm afraid that with this you move from "tone-deaf" to "overtly sexist".
My biggest question is - why couple a new programming language and the translation system? Either system alone would be difficult to get a foothold. Wouldn't you be better off picking an existing programming language that you really like - one with good semantics and lots of libraries - and implementing the translation system on top of that? Some sort of Lisp would seem to be a natural fit. What does your language offer to someone who is already comfortable with English-based programming languages?
(sorry for double-commenting, but I didn't want to start a merged thread for two very different topics)
Dude, really. If you gave a crap about effective communication you would not just have said that.
Hell, you would not even have thought of saying that; never mind typing it, reading it back to yourself, and then hitting Post cos you still think it’s a good idea. SMH
Your enthusiasm is admirable but your limited expertise is clearly showing. Instead of saying that you’re here to answer our questions, you should be the one who’s listening to our criticisms and then asking searching questions of us. A bit more humility and a lot less hubris. You and your product will be a lot better for it.
Programmers like you are the reason I finally taught myself how to code, so I would never have to depend on your sort for anything. You’re a smug, condescending martinet with a grossly inflated sense of your own specialness, and the sooner you grow up/the world kicks you to the curb, the better.
So here’s me expressing my freedom of thought and expression by having nothing more to do with you.
Sadly the site is dead (503).
Spoiler alert: it doesn't work at all in practise.
Grammar is one thing, but the "translation" even fails with single words.
It's basically complete garbage.
Also I've seen business ERP languages, completely localized. Those who program on them usually laugh on it, they say it's not hard at all to get used to English keywords, business logic is what's hard. Even better, the fact it's English means it's built-in.
That way, anyone could check out a version of the code that's localized to their native language, including language primitives, standard library calls, variable names, comments, etc. without fracturing the whole library ecosystem by language boundaries.
Ouch. Naming things is, famously, one of the two Hard Problems of computer science. How much harder if you have to name everything, down to the last loop iterator, thousands of times - once for each language that humans speak?
I have wondered if non-English-speaking universities have to teach their CS courses in 25-50% English, just due to the syntax of the programming languages generally being in English
Besides, the example in my first language is unreadable.
What's odd to me is the page is internationalized. Their explanation: "As a developer, you have to know some English. Nobody is going to change that anytime soon."
"Designed to allow every man to write code in his mother tongue" could easily be written as "designed to allow every person write code in the language they are most comfortable with."
One day that audience might extend to women.
Of course this also implies that the translations should be done by professional translators, instead of the authors themselves.
> The Citrine community is working hard to provide translation files. We use machine translations if we can't find a translator yet. We appreciate any help to improve language support!
I can't think of a Dutch version of the same sentence that wouldn't make the subject explicitly male (well, there are some archaic versions that would use 'alleman' but I can't think of one that wouldn't sound weird).
Not the first time I’ve seen a “let’s make coding more accessible” project make this mistake, alas.