[w3ctag/design-reviews] I18N String-Meta and WebIDL (Issue #716)

صباح الخير TAG!

I'm requesting the TAG express an opinion on a "dispute" related to:

  - Name: String-Meta (language and direction metadata)
  - Specification URL: [String-Meta](https://w3c.github.io/string-meta)
  - Explainer (containing user needs and example code)¹: [here](https://github.com/w3c/i18n-discuss/blob/gh-pages/explainers/string-meta-explainer.md)
  - User research: N/A
  - GitHub issues (if you prefer feedback filed there): [i18n-discuss#23](https://github.com/w3c/i18n-discuss/issues/23)
  - Primary contacts (and their relationship to the specification): @aphillips @r12a @xfq
  - The group where the work on this specification is: I18N
  - Links to major pieces of multi-stakeholder review or discussion of this specification: 
  - Links to major unresolved issues or opposition with this specification:
  - Relevant time constraints or deadlines: "soon" (we want to approach ECMA-402 and ECMA TC39 and/or discuss with WebIDL)

Explanation of the issue that we'd like the TAG's opinion on:

This isn't quite a "normal" technical dispute, but we do seek a conversation with TAG about the technical approach we are taking. We believe that interoperability of natural language strings between different Web APIs is strongly desirable

Quoting our explainer:

> We would like TAG to review our approach to this problem and discuss what the right long term approach should be in the Web platform. We believe that this is an important gap for natural language support on the Web; but we are concerned that our current approach and comments generates churn or is distracting to Working Groups attempting to complete work on specifications.
>
> Our immediate request has to do with [webidl#1025](https://github.com/w3c/i18n-discuss/blob/gh-pages/explainers/whatwg/webidl#1025) wherein we requested that WebIDL add a Localizable type to IDL. This would allow specifications to reference this string type and save them creating a local dictionary representation. The WebIDL folks do not want to do this because it is at odds with their normal practice of providing only JavaScript primitives and types. They also don't want to become a registry of random dictionary entries.
>
> One way to solve this would be if W3C and ECMA-402 proposed a natural language string type with these attributes to ECMA TC39. If that proposal were ultimately successful (and it will take at least one complete JavaScript release cycle to be accepted and reach the specification), then WebIDL could encode the type in their specification. This would be the most durable and platform-wide solution. On the down side, this would require probably 1-3 years before specifications would have a ready reference and it is unclear if such a type would be accepted or implemented by TC39.
>
> Another alternative, possibly acting as a shim for eventual standardization by ECMA TC39, would be for I18N to define a dictionary and ask specifications to adopt it generally for natural language string values.

Links to the positions of each side in the dispute (e.g., specific github comments):

[webidl#1025](https://github.com/w3c/i18n-discuss/blob/gh-pages/explainers/whatwg/webidl#1025)

What steps have already been taken to come to an agreement:

We don't actually disagree with WebIDL. Some working groups have pushed back on our comments asking for direction metadata because of the lack of a standardized representation on the Web, such as Webauthn and Web Payments. 

We'd prefer the TAG provide feedback as (please select one):

  - [X] leave a comment in the following GitHub issue: [i18n-discuss#23](https://github.com/w3c/i18n-discuss/issues/23)
  - [ ] leave review feedback as a comment in this issue and @-notify [github usernames]
  - [ ] open a new issue in our GitHub repo with the feedback

  - [X] we would like to have a joint call with representatives of the TAG if appropriate

For our own housekeeping:
[\[I18N-ACTION-1103\]](https://www.w3.org/International/track/actions/1103)
--------------------------

_Please preview the issue and check that the links work before submitting._ In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our [explanation of how to write a good explainer](https://tag.w3.org/explainers/).


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/716

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/716@github.com>