Horizontal Review - i18n

[hlflanagan]

This short review is for the following spec: Federated Credential Management API.

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.

   Comments_go_here.

   • Not applicable
     - FedCM consumes the browser settings when it comes to language preference. There is nothing in the spec itself to change browser behavior beyond those defaults.

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.

   • [X ] Not applicable (because we don’t support any CSS in the dialog; the user agent is fully responsible for the style of the text. There is no customization provided by the developer.)

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.

   • [X ] Not applicable (The script cannot access the text itself.)

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

   • [X ] Not applicable (FedCM does not allow text searching or matching.)

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.

   • [X ] Not applicable (The only text that can be considered “sorted” will be the account list presented to the user. The list will be sorted on the developer-specified IdP ordered, whether the accounts are returning or not, or the order by which the account are returned by the IdP.)

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 (FedCM only has buttons; we do not capture other keyboard events.)

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 (The FedCM Chrome implementation captures last-used time, but that’s a relative time (e.g., “one week ago”))

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 (Spec uses UTF-8)

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 (We do not define markup)

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

• We have a field called name (name and givenname (optional)). Any type of name would be supported.

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 (Images such as logos for accounts are displayed but they are not stored. We also do not store names, just account IDs. These don’t require localization.)

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.

    • [X ] Not applicable (We aren’t aware of any norms; there are just buttons to click.)

Short i18n review checklist is here

[aphillips]

I started a cursory review, in preparation for a full review. I can't seem to find where this is located in the spec:

Not applicable (The FedCM Chrome implementation captures last-used time, but that’s a relative time (e.g., “one week ago”))

Can you let us know where the last-used time is?

[npm1]

Can you let us know where the last-used time is?

I was hesitant to include that in the text but the question did ask about implementations as well. This is something that is not in the spec since it is only used as part of the Chrome UI, and we do not specify the UI that is shown to the user in this level of detail.

[aphillips]

Thanks. Is the last used time stored locally or is otherwise implementation specific, e.g. not part of FedCM's data format, then?

[npm1]

Yep, in Chrome it is stored locally in the user storage. Since it is only used by Chrome to sometimes enhance its UI when offering the user the accounts they are logged in to, it is not part of the spec. You are correct that it is not part of FedCM's data formats (eg not in any JS or HTTP requests or such)