Add dir/lang member on dictionaries whose content is displayed in browser UI

[marcoscaceres]

As we can't mark-up the labels in dictionaries (using HTML), we might need to add dir ("ltr" and "rtl") members on dictionaries that contain things that are displayed to the end-user (defaulting to "ltr" when missing). So:

[
  displayItems: [{
    label: "البند الخاص (للبيع!)",
    dir: "rtl",
    lang: "ar-AE",
    amount: { },
  }]
]

Have the i18n folks looked at this API? They will likely ask us to add that. We might also need lang.

cc @r12a.

[marcoscaceres]

heh, the above Arabic text already got screwed up 👍

[marcoscaceres]

I emailed public-i18n-core regarding this issue.

[marcoscaceres]

Blocked on i18n WG feedback.

[aphillips]

Thanks for the comment and email to our list. The I18N WG has scheduled discussing this in our next teleconference (2017-03-02). Generally speaking, we do look for dir and lang attributes to accompany any natural language text values, since these metadata values are frequently necessary to produce proper display, selection, and processing of text values. Transmission in non-markup (i.e. not in HTML) contexts is of increasing concern to us.

[marcoscaceres]

These will also apply to PaymentShippingOption.

[ianbjacobs]

@aphillips, @r12a,

The Web Payments Working Group would really appreciate being able to close this around the time of its FTF meeting 23-24 March. Were you able to discuss Marcos' sample code and does it look sufficient?

Ian

[marcoscaceres]

Related from Web Share: w3c/web-share#6

[aphillips]

We discussed this in teleconference today and I have an action item to reply... but don't have/haven't had time to reply just yet (other than this note to say it is forthcoming very shortly)

[ianbjacobs]

@aphillips, let me get out of your way...

[marcoscaceres]

Note to self - read: http://w3c.github.io/i18n-discuss/notes/json-bidi.html

Thanks @aphillips for the update!

[marcoscaceres]

@aphillips, I put together an initial proposal:
https://s3.amazonaws.com/pr-preview/w3c/browser-payment-api/f68ca73...00714be.html#localizable-dictionary

[marcoscaceres]

Minutes from i18nwg call:
https://lists.w3.org/Archives/Public/www-international/2017JanMar/0103.html

Note that it's not for JSON, it's for a JS Object (WebIDL dictionary).

[r12a]

I'm not the one who reviewed this (I believe Addison will get back to you very soon). I just have one thing i wanted to mention:

I think this should probably work fine for the example below.

[
  displayItems: [{
    label: "البند الخاص (للبيع!)",
    dir: "rtl",
    lang: "ar-AE",
    amount: { },
  }]
]

but you'd need to be careful any time the scope of the dir attribute covers more than one label or string. If the two strings need to have different directionality (such as if the amount was a mac address or telephone number in the example above) you'd need to at least be able to override the direction where necessary.

Note that the Web Annotation solution which you followed, @marcoscaceres only associates a dir attribute with a single string at a time, which is the safest way.

[marcoscaceres]

Postponing. We can eventually leverage whatever comes out of the WebIDL discussions.

[marcoscaceres]

Doesn't look like this one is going to happen, so closing for now.

[aphillips]

I18N will publish our document String-Meta as FPWD in the coming week. This work was partially sparked by this issue. You may wish to review, although I don't think there is anything actionable to grow out of it yet. I'm not re-opening.

(this is responding to an action item)

[rsolomakhin]

@aphillips : Really cool spec, thank you for the link! Would it make sense for your spec to define the IDL for a base structure that other specs can inherit? For example, if you define dictionary Internationalizable or interface Internationalizable, then the Payment Request spec can have interface PaymentAddress : Internationalizable. This would allow for code sharing inside of the user agent as well.

[rsolomakhin]

Found https://w3c.github.io/string-meta/#Localizable that may work.

[ianbjacobs]

@r12a, we have closed this issue. However, it is still marked as i18n-needs-resolution. Is it possible to remove that label? Thanks!

Ian

[r12a]

@ianbjacobs please don't remove the label. It will not be picked up by the tooling that looks for unresolved issues prior to a transition.

Prompted by this, i added a paragraph at https://w3c.github.io/documentreview/#working_with_horizontal_review_labels about what to do with such labels when closing an issue. Thanks.

If you close an issue with a *-tracker or *-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.)