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

Complete W3C Internationalization (i18n) review checklist #404

Closed
12 of 24 tasks
wilaw opened this issue Jun 29, 2022 · 1 comment
Closed
12 of 24 tasks

Complete W3C Internationalization (i18n) review checklist #404

wilaw opened this issue Jun 29, 2022 · 1 comment
Assignees

Comments

@wilaw
Copy link
Contributor

wilaw commented Jun 29, 2022

This short review is for the following spec: WebTransport.

  1. If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc), ensure that there’s metadata about and support for basic things such as language and text direction. Also check the detailed guidance for Language and Text direction.

    The spec contains no DOM components. We do specify an Error interface defined by https://w3c.github.io/webtransport/#web-transport-error-interface, which introduces a new WebTransportError subclass. This error class includes a JS standard error code, message and a custom enum attribute 'source'. The message is an implementation-defined string. We feel that this architecture of fixed error codes and messages should facilitate localization. We also define a WebTransportCloseInfo Dictionary https://w3c.github.io/webtransport/#dictdef-webtransportcloseinfo which specifies a code and a reason string which defaults to "" for JS-provided values, but which may contain server-generated values.

    • Not applicable
  2. If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics. take into account the different typographic styles used around the world (for things such as line-breaking, text justification, emphasis or other text decorations, text selection and units, etc.) Also check the detailed guidance for Typographic support.

    Comments_go_here.

    • Not applicable
  3. If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc. make allowances for the ways different scripts handle units of text. Also check the detailed guidance for Text-processing.

    Comments_go_here.

    • Not applicable
  4. If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers understand the implications of normalisation, case folding, etc. Also check the detailed guidance for Text-processing.

    Comments_go_here

    • Not applicable
  5. If the spec (or its implementation) sorts text ensure that it does so in locally relevant ways. Also check the detailed guidance for Text-processing.

    Comments go here.

    • Not applicable
  6. If the spec (or its implementation) captures user input ensure that it also captures metadata about language and text direction, and that it accommodates locale-specific input methods.

    Comments go here.

    • Not applicable
  7. If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries ensure that it will represent time as expected in locales around the world, and manage the relationship between local and global/absolute time. Also check the detailed guidance for Local dates, times and formats.

    Comments go here.

    • Not applicable
  8. If the spec (or its implementation) allows any character encoding other than UTF-8. make sure you have a convincing argument as to why, and then ensure that the character encoding model is correct. Also check the detailed guidance for Characters.

    Comments go here.

    • Not applicable
  9. If the spec (or its implementation) defines markup ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements. Also check the detailed guidance for Markup & syntax.

    Comments go here.

    • Not applicable
  10. If the spec (or its implementation) deals with names, addresses, time & date formats, etc ensure that the model is flexible enough to cope with wide variations in format, levels of data, etc. Also check the detailed guidance for Local dates, times and formats.

    Comments go here.

    • Not applicable
  11. If the spec (or its implementation) describes a format or data that is likely to need localization. ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc.

    Comments go here.

    • Not applicable
  12. If the spec (or its implementation) makes any reference to or relies on any cultural norms ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc).

    Comments go here.

    • Not applicable

Short i18n review checklist is here

@wilaw
Copy link
Contributor Author

wilaw commented Jan 25, 2023

#414 addresses the sole applicable issue raised in this review.

@wilaw wilaw closed this as completed Jan 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant