Despite I'm not a native English speaker and I meant almost all the programs I ever wrote to be capable of processing any given language (and also have localized UIs in some cases), I see no reason for non-English strings to be allowed in source code and code files except some ad-hoc scripts in which hard-coding some text can be an optimal solution.
We probably just need a git switch which would make it throw an error if it encounters Bidi or any weirdness like that except in resource files.
Since most progamming languages are based on english, non-english text in string literals is almost always user-facing and should be put in resource files to make translation into additional languages easier.
Identifiers and comments are a serious problem though. Many application domains use terms that are tricky to translate into english. The translations could be misleading, inappropriate or not unique. Sometimes they are just plain wrong or there is no english word that fits. All of these could cause misconceptions, confusion and bugs, and make reading and working with the code and the running system harder.
another common usage is to standardize error/success/etc messages. you always want one type of error to say the same thing, and a language file is a better place to put things than using a define.
having said that, its all about maximizing efficiency. if you don't think you'll actually save that much time in the future by putting things in the language file, maybe because you'll "never" internationalize, then its probably a process worth skipping for you. you can always just go back and make the changes later. it'll just be harder and take longer to do it later, as opposed to doing it now.
The thing is, if you want to stay up to date with programming you cant afford to wait for Information in your native language anyway. Unless youre a complete beginner.
So whats the point in having the menus, debugger etc translated, except for extra confusion?
Would you like the build config files translated too?
This is a very incorrect assumption. Everybody wants to be able to use native language for program output and input, view and edit texts in native language using less, sed, vim.
There is also the problem of getting the original content, I speak 3 langages, I intend to read the original source if it's one of those language. I don't want unpaid-intern translation.
MS C# documentation deserve a special kind of hell, because they detected I reverted the language to english ; and now they present me a special translation mode of their freaking doc where there are huge tooltip texts everywhere.
Mostly because it has an "ignore comments" mode. A lot of non-English speaking programmers write code using English keywords and identifiers but use their native language in the comments.
With some work, it could be made language-agnostic, but that's more than I have time for right now. If comments aren't an issue, you can just grep through all your source files for the offending characters, which shouldn't take more than a simple bash script.
> If you'd rather build software in English than in a programming language, then you don't really want to build software at all.
Every software build I've been a part of is conceived first and fleshed out in English. The programming language then used is an intermediary annoyance to most parties involved.
Ultimately, the end result is all that most people care about.
You don't get it. I don't want translations. I don't want to contribute because I don't think it is possible to translate programming code and documentation satisfactorily and I don't think it is worth trying.
If there are people who think it is, they can do it, but I just want to read everything in English when it comes to programming.
Something about non-English comments in source code is really off-putting. That, and if you generally do want people to understand, then you should use English. If that does not matter to you, or someone else, then do not.
We used static file analysis to extract default (English) strings into files.
reply