Learn: GTK and NativeScript targets do not share a catalog

[JumpLink]

Summary

The GNOME and Android targets are generated from the same MDX source but do not share their translatable strings, so most of the Android tutorial has no catalog entry at all and is shown in English regardless of the user's language.

The two targets are localised through the same catalog:

• app-gnome: xgettext extracts <property name="label" translatable="yes"> from packages/learn/dist/*.ui into the POT, and Gtk.Label picks up the translation via gettext.
• app-android: po2json converts the same .po files into packages/app-android/app/i18n/*.json, and MdxView.localizeHtmlViews() (packages/app-android/app/mdx/mdx-view.ts) looks up the whole HTML string as the key: localize(htmlView.html).

So an Android string is translatable only if it is byte-identical to a GTK label that reached the POT. Most are not.

Measurement

Built from main (gjsify workspace @learn6502/learn build), comparing the translatable label texts of dist/tutorial.ui with the html="…" attributes of dist/tutorial.ns.xml, both XML-unescaped:

	unique strings
GTK (translatable="yes" labels)	144
NativeScript (html= attributes)	139
identical in both	56

quick-help is worse in proportion: 80 vs 24 unique, 12 shared.

Cause

Of the 83 NativeScript strings with no GTK counterpart:

• 81 contain a <w:SourceView …> element. Inline code becomes <tt>x</tt> on the GTK target but a whole SourceView element — carrying a generated id, editable, lineNumbers, selectable, lineNumberStart — on the NativeScript one. Rewriting each <w:SourceView … code="x" …></w:SourceView> back to <tt>x</tt> makes 78 of them match a GTK label exactly, which is the measure of how much of the gap is purely this encoding difference.
• 2 differ structurally for other reasons: the document title (Tutorial <small>by <a …>Nick Morgan</a>…</small>, where GTK uses <sub>), and lists — GTK's GtkTextList splits a list into one label per item, while NativeScript renders the entire <ol>/<ul> as a single html string.

The generated id attribute is also per-render (nsSourceView216, …), so even if the catalogs were extracted from the NativeScript output instead, the msgids would churn on every renderer run.

Reproduce

gjsify workspace @learn6502/learn build

node -e '
const { readFileSync } = require("node:fs");
const un = (s) => s.replace(/&(amp|lt|gt|quot|apos);/g, (m, e) =>
  ({ amp: "&", lt: "<", gt: ">", quot: `"`, apos: "\x27" })[e]);
const src = (f) => readFileSync(`packages/learn/dist/${f}`, "utf8");
const gtk = new Set([...src("tutorial.ui")
  .matchAll(/<property name="label" translatable="yes"[^>]*>([\s\S]*?)<\/property>/g)].map((m) => un(m[1])));
const ns = new Set([...src("tutorial.ns.xml").matchAll(/\bhtml="([^"]*)"/g)].map((m) => un(m[1])));
console.log("gtk", gtk.size, "ns", ns.size, "common", [...gtk].filter((s) => ns.has(s)).length);
'
# gtk 144 ns 139 common 56

Not a bug fix

How the two targets should share a catalog is a design decision, not something to patch: the options (extract from a target-neutral intermediate; render inline code identically on both; key Android lookups on something other than the full HTML string; teach MdxView to reassemble a translated GTK label) differ in what they cost the Android renderer, the existing 16 catalogs and Weblate. Filing the measurement rather than inventing an answer.

Related: the emitter now has a structural check (gjsify workspace @learn6502/learn check) that compares code literals across all three targets, but deliberately says nothing about which strings are translatable in each — that is this issue.

[JumpLink]

Measured while reviewing #178, since it bears on how this gets fixed.

The new artifact check in #178 asserts paragraph parity between dist/*.ui and dist/*.html — they match exactly (tutorial 146/146, quick-help 80/80 on plain-text normalization), so the .html works as a witness that a paragraph still reaches the .ui, which is what xgettext reads.

The .ns.xml cannot serve in that role, and the reason is this issue. Two obstacles, both measured:

1. No per-paragraph structure. Consecutive list items are folded into a single HtmlView, so tutorial has 146 .ui labels against 141 html= attributes.
2. Inline code is a sibling element, not text. The .ui puts it inline as <tt>$0000</tt>; the .ns.xml puts it in a <w:SourceView code="$0000"> element, so the surrounding prose is split into fragments with the literal missing from the text. Comparing plain text, 94 of 146 tutorial paragraphs and 49 of 80 quick-help paragraphs do not appear in the .ns.xml text at all — e.g. Zero Page : $0000 - $00FF in the .ui against Zero Page : + $0000 + - + $00FF in the Android target.

Consequence today: a renderer change that drops paragraphs from the Android target only passes the check. Verified by mutation — dropping every seventh HtmlView with no code in it leaves gjsify workspace @learn6502/learn check green.

Whatever shape the shared catalog takes, it has to make the Android target's prose comparable to the .ui's; that is the same normalization the check needs, so the two land together.