This has nothing to do with oral hygiene. I honestly clicked through expecting to find some breakthrough study on the effects of oral hygiene on second language acquisition, either individually or sociologically.
There could be automated linguistic diversity in the code itself, rather than just the docs.
Say, you must pick identifier names from a subset dictionary of language concepts (pruned of synonyms and multiple senses), for which we have translations into X other languages. E.g. WidgetFactory is a valid name, since we can translate that, but FoznozzleBodega raises an error. So the resulting code can be trivially output in any language in the master dictionary.
There could also be multilingual literary programming by making the output syntax conform to the target language as well, in terms of conjugation, part of speech order, etc.
Code is a relatively low hanging fruit for debabelization.
Current output l10n tends to translate whole strings in context. It sounds like your preference is to make automatic translation part of every binary? Maybe I'm misunderstanding you, but I don't think that is the best way to go about achieving localization, given the massive overhead and lackluster results.
I like this idea. It seems like it's related to another idea that I've always liked but never seen in practice: assuming that the code checked in always parses, you can re-lay-out code style (indentation, tabs/spaces, line length) according to the individual developer's preferences upon checkout, and transform them back to some (arbitrary) standard upon checkin.
Git can handle this sort of thing with smudge/clean filters.
Word-by-word translation doesn't really work, unfortunately, even in the limited context of variable names. You'd have to translate for example MoveTime into MoverTiempo, which is awkward in general and the wrong translation entirely if the variable refers to a time that someone's moving house.
GUI translation works like this, usually. You have a list of strings/phrases occuring in the GUI and a translation table for each language that assigns the english string to its translated equivalent. With the help of a dictionary (general and domain specific parts) you can even do automatic translations.
But the devil is in the details:
Most english speakers don't know foreign languages, so they are unaware of lots of problems that occur from just a word list. E.g. there is a difference between "end" as a noun and "end" as a verb. In German, one would translate the former as "Ende", the latter as "beenden". So for the string table, the programmer would need two different annotated entries "end (n)" and "end (v)" for the translation to be correct. But usually, the translation team only gets "end" without context, annotations or anything, and of course all occurences of "end" will be conflated into one line in the translation table. There are other frequent problems, like sentences containing numbers that require logic to get right and distinguish between Singular/Plural, nothing and maybe even Dual cases. Or the problem that designers got their fingers into a GUI, leaving just enough room for English language strings, but the translations will be cut off or awkwardly skew the layout because they are too short/overflowing/unaligned.
This frequently leads to the situation where as a German, I have to translate to English and back to understand the meaning. Which is why I nowadays avoid translated software and do everything in English. I think translation without lots of effort is pointless. And nobody will invest any significant effort into "small overseas markets".
In FOSS it may be easier to get good translations because of the feedback from real users. They are often more proficient in the target language (than paid translators) and can recognize awkward phrasings and misleading situations. Translation is also an opportunity for small incremental improvements by tons of otherwise non-technical volunteers.
But for the aforementioned reasons, automatic translation makes things worse, not better. I have yet to find a useful translation of technical content, i.e. anything that goes beyond just understanding the general topic of a newspaper article.
> Most english speakers don't know foreign languages, so they are unaware of lots of problems that occur from just a word list
Facebook's approach to this in their translation crowdsourcing interface is to provide extra context like an example sentence with the phrase, or a definition.
> This frequently leads to the situation where as a German, I have to translate to English and back to understand the meaning. Which is why I nowadays avoid translated software and do everything in English.
I've tried to use only English language settings for decades. Otherwise, you just get an ugly (and often illogical or downright factually wrong) mish-mash.
Like when your locked-down work machine's OS is set to use your local language, but the software you use is only available in English. Lots of dialogs in English, but then the buttons at the bottom jarringly ask "Yes / No / Cancel?" in whatever language HR and IT thought was all your little mind could handle... Utterly infuriating.
This is a hard problem to solve. The amount of work required is huge. I understand the problem. I work on Italian CNC machines. Half my time debugging is in Google translate trying to figure out comments, variable names and error messages. I don't think it's impossible to translate all of the material to English but it would cost hundreds of thousands. I Know FOSS doesn't have the same economic model but it does have opportunity costs. If someone wants to advocate for this great, I'd be cautious to ever disparage a project for not doing this. Simply because it is a tremendous amount of work.
Unfortunately it is not like that. We experienced various difficulties translating only few sections in the Django documentation because, also for technical text, mechanical translation is not effective, but you have to adapt the text.
For good translation you need some one who is fluent in both languages and fluent in the technical domain you want translated and is skilled at translation. You're asking for skilled labor at the intersection of 2-4 different skills (depending on how you count it) and depending on the domain one of those skills might already be pretty rare.
Bunch of short UI strings in a spreadsheet don't work well. You need screenshots or English builds if possible, and the shorter sentences become, more context explanation become necessary, unless you actually want:
- "Kill them, they're Russians"
in place of "Remember - [say]No Russian[words]"[1]
- "Province"
in place of "State[as in status]"[2]
- "Scheduled installation time:"
in place of "Installation start in[at following directory]:"[3]
- "Preparing Phacochoerus africanus"
instead of ... "Loading Warthog"?[4]
- "An error report has been created. Would you like to send it?"
when it should say "[x] Send error reports automatically"(IIRC this one was in DisplayLink Windows driver)
Human language relies a lot on contexts, and without it there could be multiple technically valid candidates of interpretation that make no sense. Translators need the picture of the situation the text is used to narrow down the valid ones, and the easiest way is convey the situation is to just give them bunch of pictures.
Even something simple as "Back" could mean:
- "[show] Back [side]"
- "[go] Back [one step]"
- "[on] Back [of body]"
and there's no way for translators to know from "English: "Back", Translated: _____" form. And only one of them is correct.
Machine translations are hilariously worse by the way[5][6]:
English: "DO give methods names that are verbs or verb phrases."
MT Japanese: "Do-not-verb or verb phrases specify name of a Method."
Hi, thanks for your feedback.
My suggestion in the article was more to take care of all people in the community than to translate everything. Starting to use a better/simpler English would be a great starting point.
I'm not sure if more linguistic diversity will help FLOSS. For a lot of floss software, there isn't even enough documentation in English and looking at communities that tend to have resources in their own languages (Chinese and Japanese seem for me to be the main ones), there's usually a large divide to the rest of the English speaking floss community, which hurts both sides. For countries with more English speakers (e.g. most European countries) I don't think translations provided to developers will prove beneficial.
For example, here in Germany a lot of mcu-related german-language resources are written in the mikrocontroller.net wiki. It has some good content, but it's often very apparent that not much has been updated in the last ~10 years, in many cases misdirecting potential beginners to less-that-optimal progression paths.
You can also see a lot of people with programming experience switching their system to English, to easily find resources in case of e.g. obscure errors.
The language-mastery issue is real, especially for very young people, but I'm not sure if "forcing" people isn't the better call. At least in my peer group it seems like most interested people became pretty adept at English and I'm not aware of any that gave up because of language issues (although I'm sure there are many examples).
The suggestions for more simplified English in the article seem like good ideas to me. Often times the subject matter is complicated enough, even for people who don't have issues understanding the language.
> For a lot of floss software, there isn't even enough documentation in English and looking at communities that tend to have resources in their own languages ...
I agree; many projects (both FOSS and non-FOSS) lack sufficient documentation. However, this is the case whether or not it is English; it is another issue.
More simplified English might be a good idea. There is what is called Simplified Technical English, but that seems to be for aerospace, and perhaps it could be adapted for computer documentation, too.
I am willing to accept contributions of documentation in any language whether English or otherwise for my projects, although I am only writing in English myself, others can write in other languages if they want to do. (However, I generally have no intention to support commands and status messages etc in languages other than English, nor in character encodings other than ASCII.)
For names of stuff (and comments) in the source code of the program itself, I do not consider it too important to write in other languages, although people can try to do that if they want to do. At least for my own projects though, I intend to limit the source code to ASCII.
> More simplified English might be a good idea. There is what is called Simplified Technical English, but that seems to be for aerospace, and perhaps it could be adapted for computer documentation, too.
I'm happy that you think that the idea in the article is good.
I didn't know about the "Simplified Technical English" it seems interesting.
Thanks a lot for you feedback and point of view it's very useful for me.
I reply below to some points but only to share better my point of view I tried to wrote in the article.
> I'm not sure if more linguistic diversity will help FLOSS.
I think linguistic diversity in FLOSS means a more accessible FLOSS world to people that not speak English.
> For countries with more English speakers (e.g. most European countries) I don't think translations provided to developers will prove beneficial.
But here in Europe (I'm from Italy) not all country have the same level English skills. I also wrote the article thinking to the whole World with so meny country with a low level of instruction.
> The language-mastery issue is real, especially for very young people, but I'm not sure if "forcing" people isn't the better call.
I don't think in the article I wrote about forcing people.
> The suggestions for more simplified English in the article seem like good ideas to me.
> I don't think in the article I wrote about forcing people.
Not explicitly, but it's essentially the consequence of not increasing language diversity in FLOSS. If you want to get involved, learn English. That's the "forcing" they were talking about.
it is a pain but force to learn once then done. if we are use the every language then many times a person must deal with this in many language. i learn english enough for to read and some write and no more. language diversity fine for culture but is suck for tech things.
Seriously. American kids can start to learn to program at age 6. Non-English-speaking kids can do so once they're old enough to know English.
Who do you think will have the edge?
Plus, there's a ton of coding in all fields. Learning english to be a programmer is perhaps fine, but to be able to analyze data in seemingly EVERY field of endeavor? Or automate basic routine tasks?
The language issue is an issue, and one worth solving.
So you are call it better to make some worse, to make the American childern start later also? Either we are having every translation for every thing or here we have the choice.
I think we should solve this problem. It's a big lift, but so was moving ASCII to Unicode, or supporting screenreaders. Making things accessible is the right thing to do, and once the right infrastructure is in place, it's not overly expensive to sustain.
Yes, I do think we should have translations for everything.
We should have infrastructure to view code in multiple languages. Blockly games, Hour-of-Code, and parts of Microsoft MakeCode do this already. You flip a button and "on start" becomes "nar programmet starter" or "all'avvio."
Programming is easy, since code is structured, and it's easy to parse what's a variable and what's a function call. The translation problem, outside of comments and documentation, is a lot easier than natural language.
Furthermore, a lot of this stuff generalizes since the same words are used so often. Once there's a translation for "page_loaded," you can use that across many platforms.
I should be able to select a drop-down, and have the same for any program I can find on github or gitlab, and edit code in my native language.
It's a (huge) one-time investment. But once that investment is made, sustaining is cheap. A lot of translation works well enough automated (through Google or Amazon translate), and what doesn't translate well can be cleaned up by crowdsourcing. Google Translated comments are usually actually good enough.
> Seriously. American kids can start to learn to program at age 6. Non-English-speaking kids can do so once they're old enough to know English.
I don't think that follows at all. Non-English-speaking kids can also start to learn programming at any arbitrary age. What they need to learn for that is a programming language, not English.
Sure, most programming languages are subsets of English -- but extremely limited subsets. And the meanings of the words in them are (often radically) different from the original meaning of the same word in English; I suspect English-speaking learners have only a tiny initial advantage of the words being similar, but in effect have to learn them as if they were from a foreign language anyway.
> Non-English-speaking kids can also start to learn programming at any arbitrary age. What they need to learn for that is a programming language, not English.
I agree with that, but what I've explained in the article is that if you don't know English is harder to access English-only documentation, resources, etc...
This can be changed by the community to be more inclusive, especially for newcomers, kids, ...
I think the opposite. More linguistic diversity in FLOSS means less accessibility. having a universal standard here means that if you want to contribute, you learn exactly ONE language, which also happens to be the so-called global language.
Conversely, in the linguistically fragmented scenario, you're SOL, as it's pretty unreasonable to learn N different languages.
Actually in the article I proposed only to think to people that don't know English but want to be part of the community. I think accessibility increase if more people can contribute.
Yeah, and what people are telling you -- which you seem not to quite want to understand? -- is that the best way for these people to become part of the community is for them to learn English.
I'm totally aware that the only way to become part of the community is to learn English, because it's exactly what I've done and I've written in the article, but I wrote also that this is not inclusive and the community can change this status quo.
I'd argue multilingualism is a bad thing in most repects. There are hardly any problem domains where having multiple equivalent yet incompatible communication protocols is helpful. I'd much rather we all simply switch to English wherever possible, even though it's not my native language.
This is such a non-argument I'm tempted to call it disingenuous. People speaking different languages is a historical accident, just because it's the situation right now doesn't mean it is anything to strive for. A single shared language allows everybody to participate in the process and not depend on someone having translated this or that particular bit of information from language X to language Y. There's a reason the scientific and business communities have always gravitated toward having a lingua franca.
Multilingualism is a barrier in human development that should be overcome, not something to celebrate or protect.
In the 80s I worked pretty hard to support multiple languages with the Zortech C/C++ compiler. Error messages were switchable between English, German, French and Japanese. Translated versions of the manual were made.
The trouble was, I had to hire translators. They weren't programmers, so the translations were (so I've been told) peculiar. When I'd modify the compiler, trying to keep the translated text in sync was a nightmare.
The last straw was when I found out that essentially none of our customers used the messages in their native language. They preferred the English versions.
So I just gave up on that with D. (Although the D language itself has excellent Unicode support, the user interface is all in English.)
Some members of the D community have taken the initiative to create documentation in their native languages, which is great.
There were some fun moments in this. In attempting to translate "destructor" to Japanese, we'd get "death tractor". Now, personally I felt that "deathTractor" was a far more apropos term than "destructor" (sorry Bjarne). For years my circle of colleagues called them deathTractors.
I'm consistently impressed by Microsoft's approach to translation - their online database of annotated translations - is an invaluable source for translating and just talking about computer/software stuff in non-english languages. ( https://www.microsoft.com/en-us/language they made their entire translation database available online).
I do some work on a compiler and as much as I'd like to enable people to use it to teach young schoolkids in their native language (with localizable keywords + error messages), the implementation/maintenance burden would be massive and then people wouldn't be able to share source code so easily globally.
It's hard to balance - I like languages, and usually my code isn't in English, but...yeah, I can only go so far in practice.
While Microsoft still is the best in this regard, they too are not perfect. I routinely see very strange thing when working on devices that aren't in English. Things like translating the word "manual" in the camera app (as in "manual settings") into the equivalent of "manual" as in "instruction manual".
Strangely enough, open source projects tend to actually have better translations, since they are more often than not done by developers and users of the software, who have far more context than the random translator with the lowest hourly rate that most companies go for.
> open source projects tend to actually have better translations, since they are more often than not done by developers and users of the software, who have far more context than the random translator with the lowest hourly rate that most companies go for.
Thanks for sharing this. I totally agree with you.
I've had the idea of making a fully localizable programming language for quite a while too, but like you, I've never actually done it due to the amount of maintenance a project like that would require.
My idea was to make it possible to transpile between all the language variants and allow machine translation of variable names and comments. That way, after a new language variant were implemented, users (primarily teachers) could take any compatible code in any language they even remotely understood and translate it, then do just a bit of cleanup and be able to contribute it back and use it when teaching.
Then I'd build a repository of these small programs, each with a set teaching goal in mind, translated into as many language variants as possible.
But now this is starting to sound like months and months of work, and since I can't focus on a single side-project for even a few weeks, is unfortunately never getting done...
It’s much worse now - anyone who uses any program that supports localized error messages should know by now to switch to English to have a hope of googling the problem.
Together with bad translations it means that there are error messages that make zero sense and you can't find help online. Indeed, the most important localization feature is turning this off.
I had an idea for some time that could help with that: start with basic english [1], and have all of your terms either described directly in basic english, or with terms that you can follow the descriptions to end up with basic english. You could then build a linter for documentation to "resolve the dependencies" of your terms and assure that every term is defined, import librairies of terms, work to reduce the complexity of definitions.
I think that would help everyone, but especially those for which English isn't their mother tongue.
Basic english can be replaced by anything that has the same idea/concept here, as I think there are alternatives.
I'm a Québecois from Canada and a native French speaker, and I wasn't fluent in English before my early 20s because I grew up in far away from big centers in a rural area. For those who don't know in Québec the preservation of the French language is a very big issue and a lot of resources are spent to keep French the official language. It's also a big quite popular political issue, it's not for nothing all of the Canadians PMs learn French, they need those seats. So I think I'm in the right place to talk about this subject.
> One type of diversity that is rarely talked about, in my opinion, is linguistic diversity. Unfortunately, in an area such as computer science where English has been the lingua franca from the very beginning
> Many developers, mostly native English speakers, will tell you, in good faith, that the language problem is secondary, that you just need to contribute the code.
No quite the contrary, thank God for having a tech lingua franca from the very beginning of the industry that is relatively easy to learn and parse with a computer. I say that as someone who also dabbled a little bit in German, Mandarin and Japanese.
Seriously diversity has become a meme at this point.
I've seen and worked with both sides of the medal. Code and documentation with French, French with English terms allowed, English code but French comments... it always ends up in a Frenglish creole language that only a small fraction of people can easily read. Plain English, please. For the love of clarity and common sense.
In Québec we have the infamous "language police", called the "French Language Office" or "French Language Orifice" as all my native French colleagues used to call it. They force companies to have French software everywhere, and then it's up to the employees to undo this mess. Usually this is fine if you're not doing programming or other non-tech related stuff such as HR, but for the rest of us please please please just don't.
Thanks a lot for sharing this Canadian point of view, it's something that I didn't know., and I really appreciate the time you dedicate to send a feedback about this subject.
I think it's also important to think to other billions of people that don't know English at all, don't live in a bilingual country where learning English is easy and maybe they don't use the same alphabet. I think start using a simpler English in every text and encourage translation of documentation, website, etc ... will improve language diversity in the whole world and not only in few countries.
Readability formulas should not be used as a guide for editing as doing so results in only gaming the metric rather than actual improvement in readability which requires the text to be rewritten rather than simply edited.
59 comments
[ 3.4 ms ] story [ 136 ms ] threadThis has nothing to do with oral hygiene. I honestly clicked through expecting to find some breakthrough study on the effects of oral hygiene on second language acquisition, either individually or sociologically.
Say, you must pick identifier names from a subset dictionary of language concepts (pruned of synonyms and multiple senses), for which we have translations into X other languages. E.g. WidgetFactory is a valid name, since we can translate that, but FoznozzleBodega raises an error. So the resulting code can be trivially output in any language in the master dictionary.
There could also be multilingual literary programming by making the output syntax conform to the target language as well, in terms of conjugation, part of speech order, etc.
Code is a relatively low hanging fruit for debabelization.
Git can handle this sort of thing with smudge/clean filters.
But the devil is in the details: Most english speakers don't know foreign languages, so they are unaware of lots of problems that occur from just a word list. E.g. there is a difference between "end" as a noun and "end" as a verb. In German, one would translate the former as "Ende", the latter as "beenden". So for the string table, the programmer would need two different annotated entries "end (n)" and "end (v)" for the translation to be correct. But usually, the translation team only gets "end" without context, annotations or anything, and of course all occurences of "end" will be conflated into one line in the translation table. There are other frequent problems, like sentences containing numbers that require logic to get right and distinguish between Singular/Plural, nothing and maybe even Dual cases. Or the problem that designers got their fingers into a GUI, leaving just enough room for English language strings, but the translations will be cut off or awkwardly skew the layout because they are too short/overflowing/unaligned.
This frequently leads to the situation where as a German, I have to translate to English and back to understand the meaning. Which is why I nowadays avoid translated software and do everything in English. I think translation without lots of effort is pointless. And nobody will invest any significant effort into "small overseas markets".
In FOSS it may be easier to get good translations because of the feedback from real users. They are often more proficient in the target language (than paid translators) and can recognize awkward phrasings and misleading situations. Translation is also an opportunity for small incremental improvements by tons of otherwise non-technical volunteers.
But for the aforementioned reasons, automatic translation makes things worse, not better. I have yet to find a useful translation of technical content, i.e. anything that goes beyond just understanding the general topic of a newspaper article.
Facebook's approach to this in their translation crowdsourcing interface is to provide extra context like an example sentence with the phrase, or a definition.
I've tried to use only English language settings for decades. Otherwise, you just get an ugly (and often illogical or downright factually wrong) mish-mash.
Like when your locked-down work machine's OS is set to use your local language, but the software you use is only available in English. Lots of dialogs in English, but then the buttons at the bottom jarringly ask "Yes / No / Cancel?" in whatever language HR and IT thought was all your little mind could handle... Utterly infuriating.
- "Kill them, they're Russians"
in place of "Remember - [say]No Russian[words]"[1]
- "Province"
in place of "State[as in status]"[2]
- "Scheduled installation time:"
in place of "Installation start in[at following directory]:"[3]
- "Preparing Phacochoerus africanus"
instead of ... "Loading Warthog"?[4]
- "An error report has been created. Would you like to send it?"
when it should say "[x] Send error reports automatically"(IIRC this one was in DisplayLink Windows driver)
Human language relies a lot on contexts, and without it there could be multiple technically valid candidates of interpretation that make no sense. Translators need the picture of the situation the text is used to narrow down the valid ones, and the easiest way is convey the situation is to just give them bunch of pictures.
Even something simple as "Back" could mean:
- "[show] Back [side]"
- "[go] Back [one step]"
- "[on] Back [of body]"
and there's no way for translators to know from "English: "Back", Translated: _____" form. And only one of them is correct.
Machine translations are hilariously worse by the way[5][6]:
Ref., (most is in Japanese, sorry):1: https://news.denfaminicogamer.jp/gamenewsplus/200402i
2: https://blog.netandfield.com/shar/2020/07/sql-server-3.html
3: https://sccm.jp/2020/12/06/post-2871/
4: https://twitter.com/skb_apos/status/1338001444138467329/phot...
5: https://github.com/dotnet/docs.ja-jp/issues/118
6: https://cpplover.blogspot.com/2018/07/blog-post.html
For example, here in Germany a lot of mcu-related german-language resources are written in the mikrocontroller.net wiki. It has some good content, but it's often very apparent that not much has been updated in the last ~10 years, in many cases misdirecting potential beginners to less-that-optimal progression paths.
You can also see a lot of people with programming experience switching their system to English, to easily find resources in case of e.g. obscure errors.
The language-mastery issue is real, especially for very young people, but I'm not sure if "forcing" people isn't the better call. At least in my peer group it seems like most interested people became pretty adept at English and I'm not aware of any that gave up because of language issues (although I'm sure there are many examples).
The suggestions for more simplified English in the article seem like good ideas to me. Often times the subject matter is complicated enough, even for people who don't have issues understanding the language.
I agree; many projects (both FOSS and non-FOSS) lack sufficient documentation. However, this is the case whether or not it is English; it is another issue.
More simplified English might be a good idea. There is what is called Simplified Technical English, but that seems to be for aerospace, and perhaps it could be adapted for computer documentation, too.
I am willing to accept contributions of documentation in any language whether English or otherwise for my projects, although I am only writing in English myself, others can write in other languages if they want to do. (However, I generally have no intention to support commands and status messages etc in languages other than English, nor in character encodings other than ASCII.)
For names of stuff (and comments) in the source code of the program itself, I do not consider it too important to write in other languages, although people can try to do that if they want to do. At least for my own projects though, I intend to limit the source code to ASCII.
> More simplified English might be a good idea. There is what is called Simplified Technical English, but that seems to be for aerospace, and perhaps it could be adapted for computer documentation, too.
I'm happy that you think that the idea in the article is good.
I didn't know about the "Simplified Technical English" it seems interesting.
I reply below to some points but only to share better my point of view I tried to wrote in the article.
> I'm not sure if more linguistic diversity will help FLOSS.
I think linguistic diversity in FLOSS means a more accessible FLOSS world to people that not speak English.
> For countries with more English speakers (e.g. most European countries) I don't think translations provided to developers will prove beneficial.
But here in Europe (I'm from Italy) not all country have the same level English skills. I also wrote the article thinking to the whole World with so meny country with a low level of instruction.
> The language-mastery issue is real, especially for very young people, but I'm not sure if "forcing" people isn't the better call.
I don't think in the article I wrote about forcing people.
> The suggestions for more simplified English in the article seem like good ideas to me.
Thanks, I'm happy you found the idea good.
Not explicitly, but it's essentially the consequence of not increasing language diversity in FLOSS. If you want to get involved, learn English. That's the "forcing" they were talking about.
Seriously. American kids can start to learn to program at age 6. Non-English-speaking kids can do so once they're old enough to know English.
Who do you think will have the edge?
Plus, there's a ton of coding in all fields. Learning english to be a programmer is perhaps fine, but to be able to analyze data in seemingly EVERY field of endeavor? Or automate basic routine tasks?
The language issue is an issue, and one worth solving.
Yes, I do think we should have translations for everything.
We should have infrastructure to view code in multiple languages. Blockly games, Hour-of-Code, and parts of Microsoft MakeCode do this already. You flip a button and "on start" becomes "nar programmet starter" or "all'avvio."
Programming is easy, since code is structured, and it's easy to parse what's a variable and what's a function call. The translation problem, outside of comments and documentation, is a lot easier than natural language.
Furthermore, a lot of this stuff generalizes since the same words are used so often. Once there's a translation for "page_loaded," you can use that across many platforms.
I should be able to select a drop-down, and have the same for any program I can find on github or gitlab, and edit code in my native language.
It's a (huge) one-time investment. But once that investment is made, sustaining is cheap. A lot of translation works well enough automated (through Google or Amazon translate), and what doesn't translate well can be cleaned up by crowdsourcing. Google Translated comments are usually actually good enough.
> Seriously. American kids can start to learn to program at age 6. Non-English-speaking kids can do so once they're old enough to know English.
I don't think that follows at all. Non-English-speaking kids can also start to learn programming at any arbitrary age. What they need to learn for that is a programming language, not English.
Sure, most programming languages are subsets of English -- but extremely limited subsets. And the meanings of the words in them are (often radically) different from the original meaning of the same word in English; I suspect English-speaking learners have only a tiny initial advantage of the words being similar, but in effect have to learn them as if they were from a foreign language anyway.
I agree with that, but what I've explained in the article is that if you don't know English is harder to access English-only documentation, resources, etc...
This can be changed by the community to be more inclusive, especially for newcomers, kids, ...
Thanks for summarizing this concept. It's sad but it's true.
Conversely, in the linguistically fragmented scenario, you're SOL, as it's pretty unreasonable to learn N different languages.
Multilingualism is a barrier in human development that should be overcome, not something to celebrate or protect.
The trouble was, I had to hire translators. They weren't programmers, so the translations were (so I've been told) peculiar. When I'd modify the compiler, trying to keep the translated text in sync was a nightmare.
The last straw was when I found out that essentially none of our customers used the messages in their native language. They preferred the English versions.
So I just gave up on that with D. (Although the D language itself has excellent Unicode support, the user interface is all in English.)
Some members of the D community have taken the initiative to create documentation in their native languages, which is great.
I'm consistently impressed by Microsoft's approach to translation - their online database of annotated translations - is an invaluable source for translating and just talking about computer/software stuff in non-english languages. ( https://www.microsoft.com/en-us/language they made their entire translation database available online).
I do some work on a compiler and as much as I'd like to enable people to use it to teach young schoolkids in their native language (with localizable keywords + error messages), the implementation/maintenance burden would be massive and then people wouldn't be able to share source code so easily globally.
It's hard to balance - I like languages, and usually my code isn't in English, but...yeah, I can only go so far in practice.
Strangely enough, open source projects tend to actually have better translations, since they are more often than not done by developers and users of the software, who have far more context than the random translator with the lowest hourly rate that most companies go for.
Thanks for sharing this. I totally agree with you.
My idea was to make it possible to transpile between all the language variants and allow machine translation of variable names and comments. That way, after a new language variant were implemented, users (primarily teachers) could take any compatible code in any language they even remotely understood and translate it, then do just a bit of cleanup and be able to contribute it back and use it when teaching.
Then I'd build a repository of these small programs, each with a set teaching goal in mind, translated into as many language variants as possible.
But now this is starting to sound like months and months of work, and since I can't focus on a single side-project for even a few weeks, is unfortunately never getting done...
I suppose unique error codes could help here.
Today those are not necessary. With how good search is these days, what works great are crafting the message strings so they are search friendly.
I think that would help everyone, but especially those for which English isn't their mother tongue.
Basic english can be replaced by anything that has the same idea/concept here, as I think there are alternatives.
[1]: https://simple.m.wikipedia.org/wiki/Basic_English
> One type of diversity that is rarely talked about, in my opinion, is linguistic diversity. Unfortunately, in an area such as computer science where English has been the lingua franca from the very beginning
> Many developers, mostly native English speakers, will tell you, in good faith, that the language problem is secondary, that you just need to contribute the code.
No quite the contrary, thank God for having a tech lingua franca from the very beginning of the industry that is relatively easy to learn and parse with a computer. I say that as someone who also dabbled a little bit in German, Mandarin and Japanese. Seriously diversity has become a meme at this point.
I've seen and worked with both sides of the medal. Code and documentation with French, French with English terms allowed, English code but French comments... it always ends up in a Frenglish creole language that only a small fraction of people can easily read. Plain English, please. For the love of clarity and common sense.
In Québec we have the infamous "language police", called the "French Language Office" or "French Language Orifice" as all my native French colleagues used to call it. They force companies to have French software everywhere, and then it's up to the employees to undo this mess. Usually this is fine if you're not doing programming or other non-tech related stuff such as HR, but for the rest of us please please please just don't.
See Limitations of readability formulas in guiding adaptations of texts https://www.ideals.illinois.edu/handle/2142/18026