Localization and string metadata for descriptions

[aphillips]

2.2 Describing what is being paid for
https://www.w3.org/TR/2020/CR-payment-request-20201203/#describing-what-is-being-paid-for

Example 2 contains this:

const details = {
  id: "super-store-order-123-12312",
  displayItems: [
    {
      label: "Sub-total",
      amount: { currency: "USD", value: "55.00" },
    },
    {
      label: "Sales Tax",
      amount: { currency: "USD", value: "5.00" },
      type: "tax"
    },
  ],
  total: {
    label: "Total due",
    // The total is USD$65.00 here because we need to
    // add shipping (below). The selected shipping
    // costs USD$5.00.
    amount: { currency: "USD", value: "65.00" },
  },
};

The value label contains natural language text with no language metadata or base direction information. The same usage is found in other example sections that follow. I18N recommends that there be a means of providing this metadata so that the document's processor can display the value correctly.

This comment is probably a duplicate of #327. It is also related to #946

[aphillips]

I'm going to add w3c/i18n-activity#1359 and w3c/i18n-activity#1357 as additional examples to this issue instead of cluttering your repo with additional specific issues. I've replicated the text of these issues in this comment.

---

14.1.2 PayerErrors dictionary
https://www.w3.org/TR/2020/CR-payment-request-20201203/#payererrors-dictionary

 const payer = {
  email: "The domain is invalid.",
  phone: "Unknown country code.",
  name: "Not in database.",
};

Example 13 shows the payer errors dictionary being used to convey unlabeled natural language string values. As noted in other comments, there is no language negotiation scheme in place. There is also no metadata here to help with display.

---

PaymentShippingOption dictionary
https://www.w3.org/TR/2020/CR-payment-request-20201203/#paymentshippingoption-dictionary

label member
A human-readable string description of the item. The user agent SHOULD use this string to display the shipping option to the user.

The label member has no language or direction metadata. Further, it cannot be localized by providing reference to a multilingual construct of some sort. There doesn't appear to be a language negotiation mechanism so that a language can be requested.

The SHOULD might be problematic vs. allowing the user agent to wrap the provided display string with a localized value, i.e. it could say something approximately like:

The user agent SHOULD use this string (or a localized version available to the user agent locally) to display the shipping option to the user.

[marcoscaceres]

Based on #956, leaving this open to address in a future version of the spec.

@aphillips, for our records, could you please indicate if i18n is satisfied with this course of action?

Please add any other labels the i18n WG needs to track this going forward.

[xfq]

Note that we don't remove the -needs-resolution label even if the WG issue is closed or deferred to the next version, because it is easier to see which issues were raised by the i18n WG.

See https://www.w3.org/Guide/documentreview/#working_with_horizontal_review_labels for more information.

[marcoscaceres]

Thanks @xfq. I've updated my comment above.

[rsolomakhin]

WebAuthn spec encodes the language code and text direction into the string itself using unicode. Is that a common practice that we could use here?

[marcoscaceres]

WebAuthn spec encodes the language code and text direction into the string itself using unicode. Is that a common practice that we could use here?

wait! what?!?!?! no 🤦‍♀️.

[r12a]

The i18n WG will be looking into that section in the WebAuthn spec, which seems to have been added without our review. On first sight it appears to contain many issues. Please don't copy the approach until we have had time to look more closely.

[aphillips]

We are continuing to work with webAuthn on correcting their metadata encoding mechanism--a mechanism we do not recommend be used anywhere else. In reviewing these issues as part of your pending CR request, I think this has to be regarded as a duplicate of #327. Since these issues remain unaddressed in the pending CR (@marcoscaceres's changes were backed out or not included in the spec), I can't say that we're satisfied yet.

[ianbjacobs]

Hi @aphillips,

Following our previous discussion we added this note to the spec:
#956

That note is in the current draft for which we've requested advancement to Proposed Rec.

It was my understanding from previous conversations that this note was sufficient for v1,
and we'd return to the question post v1. I recall that there was shared agreement that
we would not be adding dir/lang information to the displayItems dictionary in v1.

(@marcoscaceres, please also weigh in.)