Re: [geolocation-api] Change text for description of GeolocationPositionError.message attribute (#50)

(I drew an [action ](https://www.w3.org/International/track/actions/1013)from I18N to respond to this thread)

We have an on-going discussion/debate about the problem of error messages in protocols. I'm going to summarize here the gist of our debate, which is partially mirrored by the above. Apologies for what promises to be a longer note. 

In general, I18N has a strong preference that any natural language text conveying human readable messages or human readable content be associated with language and direction metadata. Where this metadata is missing, the processing or display of the text might be compromised. 

We also (separately) prefer that anywhere that customer experience (CX) messages appear that there be mechanisms for negotiating the language/locale or for localizing the resulting display. These are both fairly fundamental tenets of I18N and I don't think they're controversial on their face.

Error messages fall into an interesting gap. Usually the intention of an error or exception message is that it convey debugging information to a software developer. And it is fairly common in different niches of the industry *not* to provide localization of exception messages (most JVMs for example). A few users cite practical reasons why localization of error messages can turn out to be a barrier--generally when the message is insufficiently good to explain the problem and where being able to search the text of it produces results in the developer's preferred language is more helpful. Protocol and API designs are often similar to what geolocation has done (and indeed the inclusion of `.code` is a step above just having a string for the error). But...

Error messages *are* messages and they are intended for humans (the existence of `.code` would otherwise be sufficient). In many cases, the error message encompasses all of the additional information about what went wrong and, in some cases, the caller is obliged to show the message to the actual end user because there is no other way to convey to the customer how to fix the problem ("Your credit card has expired"; "The latitude value 10484977 is too large" [oops, forgot the decimal point]; etc.). Localization of these types of messages is actually a good thing and may even be obligatory in some applications. There are also places where implementers build and run their system entirely in e.g. Russian (so one can't assume that the message is always in English, eh?)

The statement that "we don't want developers writing messages" is flawed in a couple of ways: (1) we often have developers writing resource files containing human CX messages and (2) messages that matter to end users are more likely to be written by the CX designer and only implemented by the developer. When the error message *is* the CX it will be handled with greater care perhaps. The existence of poorly written/implemented messages (which includes English ones!) is not a reason to disallow a localized experience where one is possible or desirable.

Ultimately the problem here is that the geolocation API (or other APIs) cannot know at design time how a given error or message will be consumed and displayed to the customer. The assertion that the message never contains information of value to the end user is probably false: if the message never conveyed additional information, the geolocation client could just look it up from the `.code` or the developer from the spec. 

There are counterarguments and the discussion in the I18N WG has been about whether and to what degree making the above recommendations is helpful vs. including a note such as @marcoscaceres quoted just above. I know from recent experience raising the bar on writing localizable exceptions in my day job that breaking "years of tradition" from developers is extra work.

-- 
GitHub Notification of comment by aphillips
Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/50#issuecomment-815207570 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 7 April 2021 20:04:43 UTC