[w3c/manifest] [DRAFT] Check against i18n Review Checklist (Issue #1223) from Christian Liebel on 2026-07-02 (public-webapps-github@w3.org from July 2026)

From: Christian Liebel <notifications@github.com>
Date: Thu, 02 Jul 2026 12:52:44 -0700
To: w3c/manifest <manifest@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <w3c/manifest/issues/1223@github.com>
christianliebel created an issue (w3c/manifest#1223)

Created with Claude; review pending.

---

This short review is for the following spec: [Web App Manifest](https://www.w3.org/TR/appmanifest/).

1. [x] _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](https://www.w3.org/TR/international-specs/#resource) and [Text direction](https://www.w3.org/TR/international-specs/#text_direction).

    The manifest contains human-readable JSON strings (`name`, `short_name`, and the shortcut items’ `name`, `short_name`, and `description`). The spec provides document-level metadata via the [`lang`](https://www.w3.org/TR/appmanifest/#lang-member) member (a BCP47 language tag, validated and canonicalized per ECMA-402) and the [`dir`](https://www.w3.org/TR/appmanifest/#dir-member) member (`ltr`/`rtl`/`auto`, default `auto`). In addition, every localizable member has a corresponding [`*_localized`](https://www.w3.org/TR/appmanifest/#localized-members) member whose localized text objects can carry their own `lang` and `dir`, so language and direction can be overridden per string (e.g., for brand names in a different language than the surrounding locale). The spec also requires that security-sensitive members be displayed in a bidirectionally isolated way per UTS #55, regardless of their direction.

    Checked against the detailed Language and Text direction checklists: the spec references BCP 47 directly (not its constituent RFCs), provides a resource-level default (`lang`/`dir`) with per-string override, treats absent language as unknown, defaults direction to `auto`, and explicitly names the UAX #9 first-strong algorithm as the heuristic for `auto`. Known gaps: the spec does not reference BCP 47 (RFC 4647) for matching language-map keys to the user's preference, does not address inline direction changes within a string (Unicode bidi controls / isolating RLI-LRI-FSI…PDI support), and the prose says "well-formed" while the algorithms enforce the stricter ECMA-402 structural validity.
    - [ ] 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](https://www.w3.org/TR/international-specs/#typography).

    The manifest only carries short plain-text identification strings (application/shortcut names); it offers no typographic control. Rendering of these strings (fonts, line-breaking, truncation) is left to the user agent and the underlying platform.
    - [x] 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](https://www.w3.org/TR/international-specs/#operations).

    The spec does not define pointing into, segmenting, concatenating, or stepping through text; manifest strings are atomic values (only leading/trailing ASCII whitespace is stripped during processing). Note: the Privacy & Security section advises implementations to impose their own length limits on member values; any user agent that truncates strings for display should follow the guidance in [Truncating or limiting the length of strings](https://www.w3.org/TR/international-specs/#x6-5-truncating-or-limiting-the-length-of-strings) (truncate on grapheme-cluster boundaries, indicate truncation), but this is left to implementations.
    - [x] Not applicable

4. [x] _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](https://www.w3.org/TR/international-specs/#operations).

    The only matching the spec performs is on language tags. Language tags are explicitly defined as case-insensitive; the `lang` member is validated with ECMA-402 `IsStructurallyValidLanguageTag` and canonicalized with `CanonicalizeUnicodeLocaleId`, and the keys of `*_localized` language maps are validated with `IsStructurallyValidLanguageTag`. Enumerated keyword values (e.g., `dir`, `display`) are matched after ASCII-lowercasing over ASCII-only vocabularies, which is one of the three matching forms permitted by the detailed guidance. The spec imposes no Unicode normalization on content (as recommended), and its security considerations reference UNICODE-SECURITY and UTS #55 for confusable/spoofing concerns. Gap: the keys of `*_localized` language maps are structurally validated but neither canonicalized nor case-normalized, and the matching form used to compare them against the user's locale is not defined — the guidance requires the matching form to be specified.
    - [ ] 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](https://www.w3.org/TR/international-specs/#operations).

    The spec does not sort text. (Sorting of installed application names in launchers or app lists is a platform/user-agent concern outside the scope of this spec.)
    - [x] 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**. 

    The manifest is a static, developer-authored resource; the spec does not capture user input.
    - [x] 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](https://www.w3.org/TR/international-specs/#locale).

    The spec does not deal with dates or times.
    - [x] 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](https://www.w3.org/TR/international-specs/#characters).

    The manifest is JSON (`application/manifest+json`, with encoding considerations identical to `application/json`) and is processed via Infra’s “parse JSON bytes to an Infra value”, which decodes as UTF-8. No other encoding is permitted. Verified against the Characters checklist: whitespace handling uses Infra's defined "ASCII whitespace", strings are JSON/Infra strings, and no code-point ranges are arbitrarily excluded. (Editorial: the MIME registration cites RFC 7159; the current JSON RFC is 8259.)
    - [x] 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](https://www.w3.org/TR/international-specs/#markup).

    The spec defines a JSON format, not markup. The detailed section's guidance on syntax and identifiers (§8.3) is nonetheless satisfied: enumerated keyword values are locale-neutral ASCII application-internal identifiers matched ASCII-case-insensitively, and all human-readable fields are natural-language values that are localizable and carry language/direction metadata (see item 1).
    - [x] 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](https://www.w3.org/TR/international-specs/#locale).

    The spec does not deal with personal names, postal addresses, or locale-specific data formats. Application names are opaque strings with no imposed structure.
    - [x] Not applicable

11. [x] _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**.  

    Yes — this is a core feature of the format. Each localizable member (`name`, `short_name`, `icons`, and the shortcut items’ `name`, `short_name`, `description`, and `icons`) has a corresponding [`*_localized`](https://www.w3.org/TR/appmanifest/#localized-members) member containing a language map keyed by BCP47 language tags. Localized values for text members can be plain strings or localized text objects with per-value `value`, `lang`, and `dir`; image members (e.g., `icons_localized`) accept localized lists of image resources. The user agent SHOULD select the value best matching the user’s localization settings, falling back to the default representation, and MAY update displayed values when the user changes localization settings. One gap against the detailed Localization checklist (§10.8): the spec does not define how the user's locale is determined for selecting among language-map keys (language negotiation) — selection is delegated to the user agent's "localization settings" without referencing BCP 47 matching.
    - [ ] 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)**.

    The spec does not rely on cultural norms. Where developer-provided imagery (icons, shortcut icons) might need cultural adaptation, the `*_localized` mechanism (e.g., `icons_localized`) allows locale-specific alternatives.
    - [x] Not applicable

Short i18n review checklist is [here](https://www.w3.org/International/i18n-drafts/techniques/shortchecklist.html)


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1223
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1223@github.com>
Received on Thursday, 2 July 2026 19:52:49 UTC