Short i18n review checklist

Create a report

If you would like to create a report against this list in a GitHub repository (like this), copy the text in this box to the comment field of your issue, and then annotate it.

Useful links

The primary purpose for this page is educational. It helps you to learn about internationalization features that may affect the design of your spec. You should read it and Internationalization Best Practices for Spec Developers as early as possible, so that you are aware of what your spec will need to address. Then, to ensure that you haven't missed anything, you can also use this page as a checklist prior to publishing the spec as a FPWD.

You should raise an issue in your own repository to show the answers to these questions, and attach the i18n-tracker label so that we are notified. Under 'Create a Report' you'll find a way to create a report.

If the spec or its implementation... ... then: links to detailed checklists
... 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

Language

Text direction
... 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.)

Typographic support
... 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 Text-processing
... allows searching or matching of text, including syntax and identifiers ... understand the implications of normalisation, case folding, etc Text-processing
... sorts text ... ensure that it does so in locally relevant ways Text-processing
... captures user input ... ensure that it also captures metadata about language and text direction, and that it accommodates locale-specific input methods  
... 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. Local dates, times and formats
... 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

Characters
... defines markup ... ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements

Markup & syntax
... 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

Local dates, times and formats
... describes a format or data that is likely to need localisation ... 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  
... 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).  

The text of this page will change from time to time. If you want to comment on this page (only), raise a GitHub isse here.