i've always given the advice "program in english, comments, variables, function names, everything", and "always use a uk/us keyboard unless you absolutely have to enter localised strings, and even better get someone else to do that"
I've been working with a codebase for a very specific domain where hardly anyone even knew the English terms for the domain-specific things (and some of them probably didn't even exist - highly localized customs etc.). No point in using English then.
I’ve seen before that this is not followed in certain cases, such as the entire development team being in a specific country where some or many team members don’t know English (well enough). As an anecdote, I’ve seen a team in a large multinational company (US origin) in Spain that used function names, variable names, database table names (and column names), log message text and many other things in Spanish. English was only for the language keywords because that’s what the compiler would accept.
The smart projects that are going for L10N will collect all the UI strings into a file or set of files, separate from the code, and indexed so that the app can just switch language and then begin using a new set of localized strings. This also makes for easy translation where you don't need to rebuild the app, just expand the data files that it's using. Is this not the only way to build apps today, or are "localized strings" still being hardcoded??
Draig is built on L10N and code can be passed to/from Welsh <=> Other (eg English) … the keywords are translated back and forth, but comments and identifiers are whatever the coder writes.
As someone who's spoken English since 5, I'm perplexed by this question. I'm genuinely unfamiliar with any perceived downsides and I would love to hear more of your thoughts
for (int i = 0; while i < fruitbasket.Count; i++)
fruitbasket[i].Eat();
Even as a low-level programmer, I truly loathe C-style for loops. It takes several seconds to parse them, while the C#-style foreach is instantly grokkable with zero mental overhead. When you're scanning over thousands of lines of codes, the speed and ease of reading constructs like these adds up and makes a huge difference. The desire to apply human-friendly syntax to low-level programming is among the greatest motivating factors for the language I'm working on. All of that being said, I think there is a huge advantage in having code that reads like natural language you understand, rather than having keywords that are foreign and meaningless to you.
It's already been linked in comments here but there's been a bit of exploration in that area with Hedy. There's some good references to prior work and comments of relevance in this paper https://hedy.org/research/A_Framework_for_the_Localization_o....
i've always given the advice "program in english, comments, variables, function names, everything", and "always use a uk/us keyboard unless you absolutely have to enter localised strings, and even better get someone else to do that"
I've been working with a codebase for a very specific domain where hardly anyone even knew the English terms for the domain-specific things (and some of them probably didn't even exist - highly localized customs etc.). No point in using English then.
I’ve seen before that this is not followed in certain cases, such as the entire development team being in a specific country where some or many team members don’t know English (well enough). As an anecdote, I’ve seen a team in a large multinational company (US origin) in Spain that used function names, variable names, database table names (and column names), log message text and many other things in Spanish. English was only for the language keywords because that’s what the compiler would accept.
The smart projects that are going for L10N will collect all the UI strings into a file or set of files, separate from the code, and indexed so that the app can just switch language and then begin using a new set of localized strings. This also makes for easy translation where you don't need to rebuild the app, just expand the data files that it's using. Is this not the only way to build apps today, or are "localized strings" still being hardcoded??
Draig is built on L10N and code can be passed to/from Welsh <=> Other (eg English) … the keywords are translated back and forth, but comments and identifiers are whatever the coder writes.
China disregards that and there is an absolutely massive ecosystem of Free and Open Source Software out there if you can read and write their code.
I know little about china (except i like the food and art) but do they actually write code in their native language(s)?!
6 replies →
As someone who's spoken English since 5, I'm perplexed by this question. I'm genuinely unfamiliar with any perceived downsides and I would love to hear more of your thoughts
No. You want 'for' to be a looping construct with no other meanings.
Seeing code in my native language makes me laugh, I can't take it seriously.
I strongly disagree. Take, for example...
vs.
Even as a low-level programmer, I truly loathe C-style for loops. It takes several seconds to parse them, while the C#-style foreach is instantly grokkable with zero mental overhead. When you're scanning over thousands of lines of codes, the speed and ease of reading constructs like these adds up and makes a huge difference. The desire to apply human-friendly syntax to low-level programming is among the greatest motivating factors for the language I'm working on. All of that being said, I think there is a huge advantage in having code that reads like natural language you understand, rather than having keywords that are foreign and meaningless to you.
Coming soon to a programming ecosystem near you:
LLM(eat apples in fruitbasket)
vs
foreach (apple in fruitbasket) apple.Eat()
Your comment can be repeated almost word for word here.
13 replies →