31–40 of 52 posts
just export LANG=C... oh, right, microsoft...
In PowerShell you do the following: New-PSSessionOption -Culture=de-DE Might be worthwhile looking up the PowerShell reference before making comments like that...
In my language, there isn't No, there is only "YES" and "MAYBE".
Earlier quoted context omitted.
In PowerShell you do the following: New-PSSessionOption -Culture=de-DE Might be worthwhile looking up the PowerShell reference before making comments like that...
Sure, but how long is this solution available and in how many years do you think it will be deprecated? Getting a bit offtopic though.
It was probably even in 1.0 but MSDN doesn't contain documentation for old software.
And soon also properly gendered
Earlier quoted context omitted.
There really should be a "Falsehoods programmers believe about languages". One entry would be: * All languages have the word "yes".
That's actually an interesting point. Indeed, how works internalization for Irish, for example? I mean some big international app, like Windows or something. I don't think it's trivial to customize some internal "yes/no" dialog in Windows to use different words for every question, but only for some languages.
Earlier quoted context omitted.
Could you explain the argument to me a bit more? Because the way I am reading your comment and the code is that doing this localization is a pain in the ass (therefore also extremely easy to screw up and not notice), and therefore 'a very bad idea.' However it seems like you would write a library that was basically a collection of user command/language/machine command triplets, expanding the library as you needed new…
The problem is that sometimes the command is being run directly by a human at the keyboard, and sometimes it's being run as part of a program. And it doesn't really have a way to know which. Localizing the former is fine, but the latter is bad. In short, if you write a script that uses /Y to indicate "yes" as an option to a command, then that script will fail on computers which are set to a language where /Y doesn't…
This is already solved to an extent in the Unix world by providing the ability for a program to detect whether its standard input/output is wired to an interactive terminal. This is how, for example, many Unix programs detect whether they're being piped into another program and to therefore be more strict about their output.
- keyboard shortcuts in Windows also sometimes differ depending on locale (for instance, in Spanish version of Notepad shortcut for "save" is CTRL-G, from "guardar", instead of CTRL-S like "save")
- output of some command-line utilities is inconsistent between versions of Windows (XP, 7 etc): sometimes it delimits stuff by tabs, sometimes by whitespaces etc.
Earlier quoted context omitted.
That's one potential problem, yes. For your solution of running through the same mapping library on both ends, that works, but it transforms the scripting language into something dramatically different from writing commands on the command line. The beauty of shell scripting (and, I would argue, the only thing that even makes it worth doing at all) is that you write the same commands in the script that you would write…
So another dumb question, how do we get from it being a very bad thing in shell scripting to it being a very bad thing in general as the post states? By the way thank you again for taking the time to answer my questions, I do appreciate it as these are honestly things I am wondering. I seem to be getting down voted because I am so stupid, but at least you are helping me learn to be less stupid on this subject (which…
Anyway, I take the post as just saying that internationalization is bad for shell commands, not necessarily for other things.
Shell commands are unusual in that they are both a programming interface and a human interface. That puts strange constraints on them that don't show up elsewhere. For things that are clearly just a human interface (for example, a GUI app) you definitely want to localize. For things that are clearly just a computer interface (for example, a REST API) you definitely don't want to. But how do you deal with something like this where it's half and half? Trying to optimize for one use case can hurt the other, which is what this post is trying to show.