21–30 of 52 posts
Wouldn't /f, /R, and /D also need i18n'd in this scenario?
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.
Earlier quoted context omitted.
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"?
With the proper support libraries, Da/Yes/Ha/Ja/etc/etc/etc it's trivial.
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…
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?
Earlier quoted context omitted.
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…
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…
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.
Earlier quoted context omitted.
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…
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…
Earlier quoted context omitted.
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 non-naive version sets the PowerShell culture/Bash locale before it runs anything.
Earlier quoted context omitted.
With the proper support libraries, Da/Yes/Ha/Ja/etc/etc/etc it's trivial.
There really should be a "Falsehoods programmers believe about languages". One entry would be: * All languages have the word "yes".
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).
Earlier quoted context omitted.
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…
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…
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).