This short review is for the following spec: Mathematical Markup Language (MathML) Version 4.0.

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.

   MathML 4 does not introduce any new displayed natural language text. MathML 3 and MathML Core both support LTR and RTL, along with the lang attribute. MathML 4 introduces an intent attribute which screen readers can use to improve the speech of mathematical expressions. Because they can make use of the lang attribute, they can switch their current language if desired.

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

   MathML 4 does not introduce any new typographical features. MathML is designed to produce appropriate math typography, both in LTR and RTL languages. Vertical layout is very rare and mostly rotated LTR layout and is supported (sort of) via CSS.

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

   It is possible in some browsers and screen readers to select meaningful subexpressions. The WG is unaware of any internationalization issues with selection (both LTR and RTL are supported).

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

   Search is possible, but the spec does not discuss this and is left to the implementation. Part of the issue is that mathematical expressions are not strictly linear, so either it must be linearized (there are multiple ways of doing this such as ASCIIMath and LaTeX) or a math editor would be used.

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

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

   MathML does not directly support input, although HTML elements can be inside of MathML leaf elements, and this includes the input and textarea elements .

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

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

   MathML is part of HTML. As such an encoding allowed by HTML is allowed by MathML. These include the legacy non-UTF-8 encodings.

   • Not applicable

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

   MathML 4 does not introduce any new elements. The existing (but not supported in MathML Core) mfenced element allows specification of the the "fences" (typically bracketing chars such as ( and }).

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

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

    The new intent attribute allows authors to add information about how a subexpression should be spoken. The Math WG has defined a set of "core" concept names and properties that all screen should be aware of and so use of those predefined concepts and properties should be localized. See the spec or intent explainer for more information.

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

    • Not applicable

Short i18n review checklist is here