Internationalization Checklist

[anssiko]

This issue is a record of the Devices and Sensors Working Group's response to the Internationalization Checklist for the Compute Pressure API. Completed Checklist is required for the submission of the Internationalization review, one of the wide reviews tracked in #177.

• 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),

The API specification contains two enums whose values are English strings:

enum PressureState { "nominal", "fair", "serious", "critical" };

enum PressureFactor { "thermal", "power-supply" };

The semantics of these strings are defined in the specification:
https://www.w3.org/TR/compute-pressure/#dom-pressurestate
https://www.w3.org/TR/compute-pressure/#dom-pressurefactor

These strings are only read by web developers and are not meant to be surfaces to the end user as is. In rare use cases where the state or pressure factor information is essential to be exposed to the end user (e.g. to aid debugging), web apps are expected to map these strings to language-aware strings as appropriate.

• If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics.

N/A

• 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.

N/A

• If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers

N/A

• If the spec (or its implementation) sorts text

N/A

• If the spec (or its implementation) captures user input

N/A

• If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries

N/A

• If the spec (or its implementation) allows any character encoding other than UTF-8.

N/A

• If the spec (or its implementation) defines markup.

N/A

• If the spec (or its implementation) deals with names, addresses, time & date formats, etc

N/A

• If the spec (or its implementation) describes a format or data that is likely to need localization.

N/A

• If the spec (or its implementation) makes any reference to or relies on any cultural norms

N/A

Summary

Only consideration that applies is "If the spec (or its implementation) contains any natural language". This is an implementation detail in mainstream use cases.

[anssiko]

@kenchris please review together with relevant parties and suggest changes as appropriate. We will refer to this issue when we submit the i18n review request.

This is tracked as part of the wide review #177 for this API.

[kenchris]

This looks correct to me. Who else should review this?

[himorin]

Just personal impression, but first bullet should target DOMString like values but enum. and I agree that checklist is not clear on that point...

[anssiko]

@kenchris @himorin thank you for your review and comments. Anyone interested in i18n should feel free to chime in here.

[aphillips]

The API specification contains two enums whose values are English strings:

Enum values should not be considered "natural language strings". Yes, they generally use English language words as identifiers, but they are not intended for end-users to view nor are they free-form text values. Developers are expected to read the definition backing the keywords in enumerated values (the description of which can be localized). In fact, it is a best practice to define values in a locale-neutral way and wrap that with display strings (exactly as you go on to suggest).

[anssiko]

Wide review has been completed as documented in #177. Thank you for your review and contributions.