Skip to content

appchangelog-gen.py should emit a localized Android What's New title — a raw literal fails i18n on every release and red-checks all open PRs #878

Closed

Description

@pipiche38

The issue makes three points precisely, grounded in what I verified in the repo:

  1. Root cause — appchangelog-gen.py writes the Kotlin title as a raw literal (title = "{title}"), but the i18n gate requires uiString(R.string.l10n_app_changelog_…). Compose has no auto-extraction, so it needs hand-localizing every release. Apple is unaffected (SwiftUI auto-extracts).
  2. Why it keeps hurting everyone — detection already exists (the push: [main] trigger i18n: localize the 9.0.1 What's New title (unblock the coverage gate) #514 added), but it only detects; the fix is still manual, so the raw title lands on main and the whole-tree --ci gate red-checks every open PR on a line none touched. Confirmed with the 9.2.0 evidence + audit output.
  3. The fix — make the generator emit the localized reference itself: key = 6-word slug + sha1(title)[:8] (I verified this scheme reproduces existing keys), auto-add the string to values/ + the four focus locales, keep Apple as a raw baseline-tracked title. Plus an optional release.sh preflight.

It also includes the immediate 9.2.0 unblock one-liner (the exact key + strings.xml change) so ryanbr can clear the current red checks the same way as #514, and flags it as a maintainer/tooling issue with the #514 precedent linked.

Activity

  1. pipiche38 commented on Jul 27, 2026

    @pipiche38
    Author

    fixed with #885

  2. added a commit that references this issue on Jul 28, 2026
  3. reopened this on Jul 28, 2026
  4. ryanbr commented on Jul 28, 2026

    @ryanbr
    Owner

    Reopening: this was closed but the generator was never changed, and 9.2.1 hit it again.

    Tools/appchangelog-gen.py:60 still writes the Android title as a raw Kotlin literal:

    f'            title = "{esc_kt(wn["title"])}",\n'

    9.2.0's title was localised by hand in #886 and this closed on the strength of that; 9.2.1's was localised by hand in #916. Two consecutive releases patched manually is the recurrence the issue predicted.

    Two things made 9.2.1 worse than a visible red check, both worth recording:

    • The release push triggers no CI at all. fork-release.yml pushes with GITHUB_TOKEN, and GitHub does not run workflows on those pushes — there is no run on 7054aef8 or 21e36a2b. main was red with nothing reporting it.
    • The audit is a whole-tree gate, not a diff, so it then fails every open PR on a line none of them touched. docs(protocol): document the COMMAND_RESPONSE body (#894, #891) #915 hit it first, which is the only reason it surfaced.

    Scope for the actual fix: emit uiString(R.string.<key>) plus the English resource in values/strings.xml, using the existing key convention (first six slug words + sha1(value)[:8] — verified to reproduce 9.2.0's key). The generator cannot supply translations, so it should exit non-zero or warn loudly naming the focus locales still missing the title, turning a silent red into an explicit step in the release checklist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions