-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Localization and string metadata for descriptions #948
Comments
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
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
The 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:
|
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. |
Note that we don't remove the See https://www.w3.org/Guide/documentreview/#working_with_horizontal_review_labels for more information. |
Thanks @xfq. I've updated my comment above. |
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 🤦♀️. |
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. |
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. |
Hi @aphillips, Following our previous discussion we added this note to the spec: 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, (@marcoscaceres, please also weigh in.) |
There are really two problems here. One is the lack of a language negotiation mechanism (which is what PR#956 seems to be about??), which we all agree it out of scope for v1. In your email about "Preparing to advance PR API 1.0 to Candidate Rec" you reviewed all of the open issues (thanks for that!) you called out:
(Notice that my response focuses on the localization mechanism) The other is lack of language/direction metadata. All of those threads appear to be dangling, at least in github. It's possible that we discussed this via email somewhere that I haven't spotted yet. But my review this morning seems to suggest that a pull request might be waiting on our String-Meta doc to provide the necessary reference or that some other mechanism would be agreed. I thought at one point that Marcos had addressed with a pull request, but that seems to have been pulled back. The recent discovery of webAuthn's problematic encoding (see above) fell out of that too. Probably this is too late to do anything about and possibly you're right we agreed to it, but it seems like we all overlooked that lack of a localization mechanism != lack of metadata fields? Hence today's comments... |
That's correct. I was banking on us solving this at the platform level, via WebIDL (or Infra). We have this same problem everywhere we use dictionaries like this, so I'd like us to solve this for the whole platform.
That would be issue: And something we take to WebIDL. |
The note after bullet point 18 at https://www.w3.org/TR/payment-request/#show-method is a step in the right direction (thank you), but it munges these two things together in a way that is unclear. Here is a proposal for 2 separate notes, that describe the 2 issues. Since you appear to be in a hurry, i am posting some suggested text now, before the i18n WG has a chance to review it, but i will ask the group to follow up after our telecon later this afternoon. Note: Metadata for international text display Note: Localization of the payments user interface |
Hi @r12a, First, thank you. We published the proposed recs today. I am very supportive of integrating helpful notes (with support from the Director) in the Recommendation. Thus, there is some time for the I18N WG to review the proposal. Please let us know here if there is support from the WG, and I'll work with the editors to incorporate after Proposed Rec reviews. |
@aphillips, with the adoption of #971, do you remove the needs resolution label? |
@ianbjacobs i just closed our tracker issue, so that should fix it. |
From the commit in #971:
May be determined how? For the direction, I'd suggest taking it from the principal writing mode of the document. The language could probably also be taken from the language on the root element, likely with the usual HTML rules for taking the combination of the lang attribute, information from meta elements, and also the protocol (e.g. from HTTP headers) into account. If additional mechanisms are later introduced to provide more flexibility, they could always override this default, but it seems preferable to make the default unambiguous. Accidental incorrect detection of the language or direction (and related interoperability problems) can potentially make text somewhat confusing, or even downright unreadable. Using a Chinese font for Japanese content (or vice versa) may present the user with some unfamiliar characters, and going ltr where rtl is expected (or vice versa) can scramble the content. |
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:
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
The text was updated successfully, but these errors were encountered: