3 ms·
I've written once an internationalized parser for another (more established) language. As long as you can output an AST, this works. User feedback was interest
by ridaj 6y ago
I've written once an internationalized parser for another (more established) language. As long as you can output an AST, this works.
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.
- Someone 6y agoIt also is bad for googling. Imagine using a version for a not so popular human language. Chances are you would need to know the English and/or Mandarin versions of language constructs anyways. If so, how much does writing in your native language add?
- hhas01 6y agoBut isn’t that true when googling for ANY information? 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.
- Someone 6y agoThat’s true for any information, but why would you introduce that problem for your (certainly initially) fringe programming language?
- hhas01 6y ago“they felt it disorienting to express in their own native language programming constructs that they'd learned in English” 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. -- [1] https://github.com/hhas/iris-script https://github.com/hhas/iris-script
- ridaj 6y ago> A better test would be taking groups of English and non-English non-programmers, and teaching both of them entirely from scratch. 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.