Re: [w3ctag/design-reviews] Serialization of natural language in data formats such as JSON [I18N] (#178)

So let me present what I'm concerned about here in a little more detail.  My basic concern is that there really don't seem to be any good options:
* the new data type seems to be a non-starter in terms of compatibility (e.g., parsing, etc.)
* the use of dictionaries makes things harder for both developers using the API, for implementors of the API, and for specification authors (increasing both the amount of work and the risk of errors) and:
  * if the use of a dictionary rather than a string is option, the handling of dictionaries is frequently going to be wrong in both specs and implementations.
  * if the use of a dictionary is not optional, it adds a good bit of extra overhead for developers in the common case where they're not going to be interested in adding language or direction information.

One of the pieces of advice from i18n in the past was that text that should be presented to users should be markup rather than attribute values, so that when needed it could allow elements within it (for things like language and direction, ruby, etc.).  I also wonder whether this sort of advice could be extended here, i.e., whether we should be encouraging the use of HTML rather than text.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/178#issuecomment-311125376

Received on Monday, 26 June 2017 17:23:26 UTC