I was thinking that this would just be about parsing command output, or searching for error messages online (i.e. copy and paste an error message into Google) but this is beyond stupid.
No, it's not a bad idea, and these 4 lines of bash script
contain no solid reasoning, argument, or business logic as to why helping the other 80% of the world's population is a very bad idea.
Doing internationalization without support libraries is a very bad idea, as this sample code helps illustrate.
It's a terrible idea unless you can force the command to accept arguments in a specific language. Do you expect someone to iterate all the possible variants of "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.
It probably helps that dialogs usually use "ok"/"cancel" rather than "yes"/"no". Chinese, for example, doesn't really have a word for "yes", but it does have a word/phrase meaning basically "ok" ("好的"), which is what's used on windows for those dialogs.
Just wow. No. This couldn't be more wrong if you tried.
There is literally no way to know what languages are supported, this is impossible to enumerate, and what might pass for correct at one time might be adjusted later to better reflect conversational usage.
It's like insisting you could possibly know all the honorifics a personal name might have. If you think you can you're deluding yourself.
In any case, the script makes a cogent and concise argument. That argument is that command line options are not just a human interface, but also a machine interface, and localization of machine interfaces leads to pain and catastrophe.
You certainly don't have to agree with that argument, but it's there.
What does the non-naive implementation look like? You say "support libraries" but what sort of support do they provide for the machine-interface scenario? How do they avoid problems such as forgetting to put a switch through the libraries and ending up with code that only works in some localizations?
The great thing about shell scripting is that you use the same commands for interactive use and scripting. If interactive use is localized but scripting is not then that no longer applies.
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 commands to be available. Being as inexperienced as I am I see this as a fairly straight forward manner of allowing users to provide commands which seem intuitive to them making the learning curve for software easier. It would make online community trouble shooting and question asking / answering more difficult, but that could be handled by what would amount to using the same library to translate posts to the users local language.
It just seems like a text based user interface will unfortunately already confound enough people that making the commands seem foreign to any one that does not know the original language of the commands is a barrier you would want to avoid creating for potential users.
Anyway I am sure I missed your point, or that there is a painfully simple way to handle allowing users to give commands which seem intuitive in their local language, and would like to learn what it is. That way if I encounter this problem in the future I can handle it in an appropriate manner rather than a manner similar to the one which I described.
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 mean "yes", and where the command is localized accordingly.
If you can solve the problem of differentiating between direct human interaction and running a program, this would be a lot better. But then non-English speakers would have to learn everything twice.
So its bad because other people won't localize their programs which might run yours? I can see that being a sadly accurate answer. Thank you for your clarification, assuming I read that correctly.
Although I think a more ideal solution to this problem would be if they are going to run your software they should be using the same library to provide input to it so that they can just specify the machine command (as their software doesn't need to be coded to provide short easy to read commands, like are ideal for a human) to look up the local language command, and give your program the command that will map back to the machine command in their local language where ever it is run. If both a machine and a human will be using your software, wouldn't optimizing for the human be ideal, even if it involves another look up or function call for the machine?
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 interactively.
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 believe it or not everyone else the down votes don't actually accomplish).
I don't see any dumb questions on your part. Maybe some differences of opinion. Don't ask me about the downvotes. I personally only downvote stuff that's deeply counterproductive. But it seems other people are more twitchy with them.
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.
> If you can solve the problem of differentiating between direct human interaction and running a program, this would be a lot better.
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.
Scenario: I write a powershell script and use it for years. Then, I read a question from somebody in "the other 80%". I want to help the other 80%, so I send him my script, explaining that it will show what it does and ask for confirmation before it actually does something.
He runs it; the script starts deleting files/sending emails/downloading files over expensive gsm connection without asking for confirmation.
After some angry words, I discover that the command line flag '-d' for 'dry run' means 'do it now without asking for confirmation' in another locale.
From another reply, it seems one can guard against that by running under the invariant culture, but I don't think one should require everybody who writes a script to be that vigilant.
If you aren't convinced try googling for help on writing VBA macros in localized version of Excel or Word.
takeown.exe, which takes ownership of a file in some circumstances, will give a Y/N prompt when the contents of a directory cannot be listed. The parameters "/D Y" will default the answer to yes.
The script in the link is considering what the prompt might ask for, not what the parameters of the program are. If the full thing was internationalized, the script might as well have language specific versions as well, I think.
Ran into something similar before on Windows with the permission system - The name of the 'everyone' group is not fixed, and varies by locale. Unfortunately not all windows commands accept SIDs, and you'll need to know the localized name for the 'everyone' group to call them. Windows's troubled languagepack journey and backwards compatibility shackles do mean that design decisions on basic file-handling commands that were reasonable in 1995 look pretty dumb now.
PowerShell is making this better, but of course when you 'shell out' from PSH to a legacy command you're stuck with its crappy commandline parsing which is designed to be backwards compatible with batch files written 20 years ago. The powershell way to do this (assuming 'set-owner' isn't built in to PSH) is probably to end-run round takeown.exe and work with the shell win32 APIs directly (or google for a cmdlet someone else has written that does that for you).
The account has a history. https://news.ycombinator.com/item?id=6225716 and other comments from that account are consistent, and suggest a language other than Japanese. And bradbeattie's own link points to a table which shows that languages other than Japanese also have no direct translation for 'yes'.
That is horrible code, there is not just de-de but also de-at and de-ch and fr-fuck-it-I-will-not-look-it-up etc. And the program should treat all equally. ( I would suggest equally badly.)
This problem also applies to MediaWiki. They decided to internationalize pretty much everything, too. Not only functions are translated; the functionality of some URL parts also depends on the language - and you'll get a lot of duplicates when more languages are enabled.
Care to expand on that? The API is not i18ned (apart from the content, obviously), the only thing vaguely similar to what you wrote which I can see are the names of the special pages. But even though they are translated into the wiki content language, on input, every wiki accepts the English version as well. Also, the canonical identifier is present in the page for scripts to use.
Or, what problems do you have?
- 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.
51 comments
[ 3.1 ms ] story [ 127 ms ] threadNew-PSSessionOption -Culture=de-DE
Might be worthwhile looking up the PowerShell reference before making comments like that...
It was probably even in 1.0 but MSDN doesn't contain documentation for old software.
Doing internationalization without support libraries is a very bad idea, as this sample code helps illustrate.
There is literally no way to know what languages are supported, this is impossible to enumerate, and what might pass for correct at one time might be adjusted later to better reflect conversational usage.
It's like insisting you could possibly know all the honorifics a personal name might have. If you think you can you're deluding yourself.
In any case, the script makes a cogent and concise argument. That argument is that command line options are not just a human interface, but also a machine interface, and localization of machine interfaces leads to pain and catastrophe.
You certainly don't have to agree with that argument, but it's there.
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 commands to be available. Being as inexperienced as I am I see this as a fairly straight forward manner of allowing users to provide commands which seem intuitive to them making the learning curve for software easier. It would make online community trouble shooting and question asking / answering more difficult, but that could be handled by what would amount to using the same library to translate posts to the users local language.
It just seems like a text based user interface will unfortunately already confound enough people that making the commands seem foreign to any one that does not know the original language of the commands is a barrier you would want to avoid creating for potential users.
Anyway I am sure I missed your point, or that there is a painfully simple way to handle allowing users to give commands which seem intuitive in their local language, and would like to learn what it is. That way if I encounter this problem in the future I can handle it in an appropriate manner rather than a manner similar to the one which I described.
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 mean "yes", and where the command is localized accordingly.
If you can solve the problem of differentiating between direct human interaction and running a program, this would be a lot better. But then non-English speakers would have to learn everything twice.
Although I think a more ideal solution to this problem would be if they are going to run your software they should be using the same library to provide input to it so that they can just specify the machine command (as their software doesn't need to be coded to provide short easy to read commands, like are ideal for a human) to look up the local language command, and give your program the command that will map back to the machine command in their local language where ever it is run. If both a machine and a human will be using your software, wouldn't optimizing for the human be ideal, even if it involves another look up or function call for the machine?
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 interactively.
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 believe it or not everyone else the down votes don't actually accomplish).
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.
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.
He runs it; the script starts deleting files/sending emails/downloading files over expensive gsm connection without asking for confirmation.
After some angry words, I discover that the command line flag '-d' for 'dry run' means 'do it now without asking for confirmation' in another locale.
From another reply, it seems one can guard against that by running under the invariant culture, but I don't think one should require everybody who writes a script to be that vigilant.
If you aren't convinced try googling for help on writing VBA macros in localized version of Excel or Word.
The script in the link is considering what the prompt might ask for, not what the parameters of the program are. If the full thing was internationalized, the script might as well have language specific versions as well, I think.
PowerShell is making this better, but of course when you 'shell out' from PSH to a legacy command you're stuck with its crappy commandline parsing which is designed to be backwards compatible with batch files written 20 years ago. The powershell way to do this (assuming 'set-owner' isn't built in to PSH) is probably to end-run round takeown.exe and work with the shell win32 APIs directly (or google for a cmdlet someone else has written that does that for you).
http://www.japanese-language.aiyori.org/article6.html
- 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.