just export LANG=C... oh, right, microsoft...
Could write a function to execute a command in the InvariantCulture: http://stackoverflow.com/questions/4105224/how-to-set-cultur...
Why internationalization of commands is a very bad idea
11–20 of 52 posts
Re: Why internationalization of commands is a very bad idea
#12Earlier quoted context omitted.
I'm pretty sure that's not bash. 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.
Sure, any naive implementation will lead to pain and catastrophe. But I don't buy that this is a cogent and concise argument to NOT do it.
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?
Re: Why internationalization of commands is a very bad idea
#13Earlier 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.
What support libraries would you recommend?
Re: Why internationalization of commands is a very bad idea
#14just 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...
Re: Why internationalization of commands is a very bad idea
#15Wouldn't /f, /R, and /D also need i18n'd in this scenario?
Re: Why internationalization of commands is a very bad idea
#16Earlier quoted context omitted.
Sure, any naive implementation will lead to pain and catastrophe. But I don't buy that this is a cogent and concise argument to NOT do it.
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.
Re: Why internationalization of commands is a very bad idea
#17No, 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 is PowerShell.
Re: Why internationalization of commands is a very bad idea
#18No, 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.
I'm pretty sure that's not bash. 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.
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.
Re: Why internationalization of commands is a very bad idea
#19No, 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.
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.
Re: Why internationalization of commands is a very bad idea
#20Earlier quoted context omitted.
I'm pretty sure that's not bash. 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.
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 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.