On Sep 26, 2017, at 1:37 PM, Jens Alfke <j...@mooseyard.com> wrote: >> On Sep 26, 2017, at 1:17 PM, Guy Harris <g...@alum.mit.edu> wrote: >> >> A user wouldn't know what to do with "you've exceeded your stored data >> quota”? > > A Turkish or Chinese user likely wouldn’t. (SQLite’s error messages are not > localized.)
Which means "for stuff that would be shown to the user, for the user to read, either localize your error messages, or make sure your API returns error codes that the application can turn into localized error messages". And none of this argues against presenting to the user, in their native language, a message saying "you've exceeded your file system quota", if that is, in fact, what happened. > And there are plenty of messages that are much less understandable to a lay > user than the one you picked out. "I got a permission error trying to write to the journal" isn't something you'd directly say to the lay user, but *don't* tell the user anything that might convince them that their disk is failing if you didn't get EIO or the equivalent on some other OS - and don't tell them something that, when relayed to tech support, would lead the support person to believe that, either. I.e., Richard Krekel is 100% correct when he says that "disk I/O error" is an inappropriate message for a permission error - the *disk* had no problem, the *OS* had a problem when the disk returned file system data that, among other things, indicated that the user didn't have permission to do something. Replacing the disk and restoring from a backup probably won't fix that problem (unless the user had that permission when the backup was done). >> The *number* might annoy the support staff; right off the top of your head, >> what's the error number for "file system quota exceeded" or "I/O error"? >> (No cheating by looking it up in a man page or include file!) > > On the contrary, error numbers are a lot easier for support. They’re > independent of locale, But the error reported by sqlite3_system_errno() isn't independent of the OS on which the user is running, so *that* error wouldn't be easy for support. You'd need a platform-independent error code, meaning, in this case, one supplied by SQLite, not by the OS. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
