Skip to content

Considerations for the I18N review

Jump to bottom
Cyril Concolato edited this page Sep 13, 2023 · 24 revisions

Requirements for Internationalisation review:

Checklist

This short review is for the following spec: DAPT.

  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.
  • DAPT is based off TTML and inherits all the internationalization features
  • Language indication is core to DAPT. Multiple languages can be indicated when text is in different languages (e.g. containing original text and after translation). There are additional discussions regarding indicating the original language even when the original text is no longer present, see https://github.com/w3c/dapt/issues/148.
  • Text direction is being considered in issue https://github.com/w3c/dapt/issues/163.
  1. 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.
  • The focus of DAPT is the interchange of documents and not their visual rendering. However, if one wants to render a script with styles, the vocabulary and semantics of TTML can be used. This is includes text decoration, vertical text, font, positioning, ...

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

    • Not applicable. DAPT, just like TTML, uses markup to separate/identify text content.

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

    • Not applicable

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

    • Not applicable

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

    • DAPT does not specifiy an input method but a DAPT document represents the output of a capture by a user of what happens in an audio/video program. DAPT provides syntax and semantics for users to add metadata about the capture, such as the language, text-direction, and various annotations. We are discussing how to make these annotations clear about directionality https://github.com/w3c/dapt/issues/164.

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

    • Not applicable. DAPT does not use wall-clock times.

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

    • Not applicable. DAPT requires UTF-8.

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

    • DAPT uses the vocabulary from TTML. Some elements like ttm:desc only allow plain-text but all other elements used in DAPT support inner markup.

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

    • DAPT does not deal with addresses, or date formats. Names can be specified for actors or characters and are free-form text, which should support wide variations. All times are media times, and no time zones are involved.

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

    • The design of DAPT is effectively to accommodate effective storage, labelling of, and access to localised script events in the context of dubbing and audio description.

  10. 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).

    • Not applicable
Clone this wiki locally