Skip to content
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

Localizability of errors #951

Closed
aphillips opened this issue Mar 31, 2021 · 6 comments
Closed

Localizability of errors #951

aphillips opened this issue Mar 31, 2021 · 6 comments
Labels
Future Candidate Feature i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.

Comments

@aphillips
Copy link

6.3 PaymentDetailsUpdate dictionary
https://www.w3.org/TR/2020/CR-payment-request-20201203/#paymentdetailsupdate-dictionary

error member
A human-readable string that explains why goods cannot be shipped to the chosen shipping address, or any other reason why no shipping options are available. When the payment request is updated using updateWith(), the PaymentDetailsUpdate can contain a message in the error member that will be displayed to the user if the PaymentDetailsUpdate indicates that there are no valid shippingOptions (and the PaymentRequest was constructed with the requestShipping option set to true).

There appears to be no language/direction metadata associated with this error message, nor a way to localize the message.

(also found in various places in the spec wherever DOMString error appears, for example here)

This is a specific example of (and thus related to) #946 and #948

@aphillips aphillips added the i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. label Mar 31, 2021
@marcoscaceres
Copy link
Member

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? - and if so, remove the "i18n-needs-resolution" label.

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

@r12a
Copy link

r12a commented May 21, 2021

(Just a process point: We don't ever remove the -needs-resolution labels. The transition looks for tracker issues in the i18n WG repo that are still open and have -needs-resolution labels. So the normal process just involves closing the issue (both here and in the i18n tracking repo) when resolved. This btw enables us to easily see which issues were raised by the i18n WG, even after closure. We also apply labels to our tracker db (and not usually yours), as we close an item, to indicate that we need to ressurect the comment for the next version of the spec. hth )

@marcoscaceres
Copy link
Member

marcoscaceres commented May 21, 2021

Thanks @r12a for clarifying. We were a bit unsure.

@r12a
Copy link

r12a commented May 21, 2021

@marcoscaceres here's the place to find guidance on that: https://www.w3.org/Guide/documentreview/#working_with_horizontal_review_labels

That page is linked from The Guide under 'Wide Review', and is the place you should start when you want any information about how wide/horizontal reviews are done. We tried to consolidate all the WG-related guidance we could find into that one page, or link to it from that page.

@marcoscaceres
Copy link
Member

Thanks @r12a! I wasn't aware of that document. That's super helpful.

@ianbjacobs
Copy link
Collaborator

@aphillips, with the adoption of #971, do you remove the needs resolution label?

@r12a r12a closed this as completed Nov 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Future Candidate Feature i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.
Projects
None yet
Development

No branches or pull requests

4 participants