| |||||||||||||
log why the permission is deniedlog why the permission is deniedPosted Jan 20, 2013 23:09 UTC (Sun) by skissane (subscriber, #38675)In reply to: log why the permission is denied by epa Parent article: Making EPERM friendlier Returning an error string has a problem - it doesn't internationalize well. I think it is better to define a catalog of error numbers; each error number has attached the number and types of allowed parameters and the English text. Additional files can contain translations to other languages. The kernel then just makes available to user-space a buffer containing the error code and its parameters - it is up to user space to do the message formatting. You'd need to make sure user space is using the same message catalog as the kernel - but that should not be too hard.
(Log in to post comments)
log why the permission is denied Posted Jan 21, 2013 0:10 UTC (Mon) by ebiederm (subscriber, #35028) [Link]
If you are giving the English text you might as well use the English text as your key in your map for your lookups. People have been doing that successfully for 20+ years.
log why the permission is denied Posted Jan 25, 2013 4:17 UTC (Fri) by skissane (subscriber, #38675) [Link] Well, you can't just use the English text as-is. You actually have to use the English text with substitution variables, e.g. "File %s not found", and then pass the substitution variables separately - so passing a single string variable from user-space doesn't work very well, you'd need to do something like pass a structure containing the format string and the arguments to go with it...And, while this approach is popular with e.g. the gettext API, I see a couple of drawbacks:
log why the permission is denied Posted Jan 25, 2013 4:25 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
actually google does amazingly well with just pasting in the full error text. I used to carefully modify the messages when searching for them, then I saw a co-worker just pasting in the full error and it sure saves time :-)
log why the permission is denied Posted Jan 21, 2013 10:44 UTC (Mon) by micka (subscriber, #38720) [Link]
Internationalized error messages are a terrible thing when trying to debuag by searching on the web.
I don't think english speaking people can really see what the problem is here : when the error message is by default internationalized, you can't "google" it, it will only return a handful of results, all of them by someone asking about the same problem you have, with no answers.
When you got this sort of error message and you must perform a search, you know you must reproduce the problem with i18n disabled. Sometimes it's as simple as
LANG=C <myprogram> <myparams>
but sometimes (I mostly have the problem when on windows, I don't know this system much and have no clue how i18n works there), that doesn't work.
The worst I have seen is the oracle database server (a really bad software anyway) giving you i18n'ed error messages ; you can't change the language on the client, you must do it on the server (if you are allowed to do so) !
log why the permission is denied Posted Jan 21, 2013 11:06 UTC (Mon) by epa (subscriber, #39769) [Link]
I think the error string returned by the OS should be understandable by a programmer, but not necessarily shown to the user unchanged; it can be looked up in a translations table in a similar way to how errno is looked up. (There needs to be an agreed way to escape filenames, etc, so you don't get pathological cases when somebody creates a filename which looks like a fragment of error message.)
Any translated or 'friendly' message should be accompanied by a 'more details' button which gives the original string you can Google for.
log why the permission is denied Posted Jan 25, 2013 4:07 UTC (Fri) by skissane (subscriber, #38675) [Link]
About Oracle RDBMS error messages, they all have numeric error codes, so even if the message text is non-English, you can just Google the code.
Your comment "you can't change the language on the client, you must do it on the server (if you are allowed to do so)" doesn't appear to be true:
SQL> select * from fred;
SQL> alter session set nls_language = german;
Session altered.
SQL> select * from fred;
(Disclosure: I work for Oracle; these are my personal opinions, not my employer's.)
|
|||||||||||||