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

So (to try to fulfill the TAG action from https://github.com/w3ctag/design-reviews/issues/178#issuecomment-317771124) here's an attempt to write the list of things that won't work:

1. **adding new string syntax to JSON.**  JSON is a widely deployed format with a large number of implementations.  Adding new syntax to strings in JSON would not work in many of these implementations, and would thus lose many of the advantages of using JSON in the first place.  (I'd give one caveat, though:  if we limit the conversation to Web APIs that use WebIDL dictionaries, I think we have a bit more flexibility, since dictionaries can have members that are JS objects but not valid JSON.  So a solution that was limited to Javascript and not JSON could have something *like* what you propose, although done using new types with constructors rather than new low-level syntax.)

I'd also add a list of things that have serious potential risks/downsides, although not necessarily ones that completely rule out these options:

2. **optionally being able to replace strings with JSON objects.**  If we add the ability to write either `name: "David"` or to write `name: { string: "David", lang: "en", dir: "ltr" }` then I see two risks:
    a. Implementations will end up supporting this syntax in only some of the places where it's supposed to be allowed, since most testing will end up not testing this variant, and then developers will be frustrated when it doesn't work.
    b. Developers will use this syntax in places where it isn't formally allowed by the spec, leading to the same frustration.
In these cases, not working will mean the string being dropped (or maybe replaced with `[object Object]` or similar), since the implementation was looking for a string but found an object, so the failure mode is pretty bad.  If we were to use this option, I'd want to see a clear strategy for how we get the platform as a whole into a consistent state in the long term.

3. **requiring that strings be replaced with JSON objects.**  This is like the previous option, but requires the additional object.  Removing the ability to write `name: "David"` from the previous version reduces the risk of (a), but increases the risk of (b), and also probably increases developer frustration from developers who think they don't need to care about this (which may or may not be true).  It probably also increases the cost of inconsistency within the platform.

4. **being able to add lang/dir properties to objects that contain strings.**  Going instead with the solution that adds lang and dir as siblings of the string, potentially applying to multiple strings (e.g., `{ name: "David", role: "TAG Member", lang: "en", dir: "ltr" }`) does address the issues with the previous two options, but instead makes it harder to work with the underlying data.   This option would mean that copying the name property elsewhere (e.g., to a different object) loses information that was supposed to be associated with the name property, unless substantial care is taken.  And since it's not even clear how to resolve conflicts (e.g., to take the name from `{name: "Sangwhan", lang: "ko" }` and the role from `{role: "TAG Member", lang: "en" }` and put them on the same object), I suspect many developers wouldn't even try to do better since there fundamentally isn't a good way to do it.

I'm sure I've forgotten something I meant to include, though...

-- 
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-323609400