* gui: the ZCode plugin's claim line is translated — its name is a sentence magpie knows, its count and plan name are data
The ZCode plugin's card gets a line when the app holds a gift plan the
account hasn't been granted yet. It was a window named after the plan and
displaying "1 to claim · claim it in the ZCode app", which stayed English
on a Chinese interface: a window's display is shown as it came
(quotaCount returns w.display for a window with no limit, app.js) and only
its name goes through t() — on the card, in the tips and in the chart. The
plugin cannot know the interface's language (host.js and provider.Provider
hand it no locale) and magpie's translation is keyed by the string, so the
sentence has to be the name. The plugin's own change is
magpie-community/plugins#43: the window is named "Gift plans to claim in
the ZCode app" and the display carries "1 · ZCode Trust Build" — one name
for any count, and the plan's name as the vendor gave it.
zh, zh-TW, ja and de each get that name: 有赠送额度待领取 · 请在 ZCode
客户端领取, 有贈送額度待領取 · 請在 ZCode 用戶端領取, 受け取り待ちのギフト
枠があります · ZCode クライアントで受け取ってください, Geschenk-Kontingente
zum Abholen in der ZCode-App (yetone/magpie#1001).
quota-name-translated.test.cjs is new and holds the rule itself, not just
this line: a window whose name is a sentence magpie knows and whose
display is the plugin's own, in English and Chinese, Chromium and WebKit —
the name reads in the language, the display does not. It fails on the two
Chinese runs without the zh entry. gui-de/gui-ja/gui-zh-tw keep every zh
string covered, and i18n-keys.test.cjs passes.
* gui: the claim line's translations fit the card at 560px, and the test checks every language at 440 and 560
The names added for "Gift plans to claim in the ZCode app" were too long for
the card: .quota-labels > span is nowrap with no ellipsis and no tooltip, so
anything wider than its .quota is cut off mid-word with nothing saying so
(yetone on #1001, measured in en/zh/zh-TW/ja/de at 360–1000px in both
engines). ja was the worst — cut by 79px at the default 660px window and
129px at 560 — with de cut at 560 and zh/zh-TW at 440.
Every language is now a shorter sentence, checked in the real page at 440
and 560px in Chromium and WebKit: nothing overflows and nothing is clipped.
en is unchanged (it is the key, and it fits at 440). zh/zh-TW drop the
"· 请在…领取" clause for a leading "待在…领取的"; ja uses the wording
suggested in review; de likewise.
quota-name-translated.test.cjs now covers every language magpie has, not
only en and zh, and renders each at 440, 560 and 1000px rather than 1000
alone — the width that could never catch this — asserting the name's right
edge stays inside its .quota and that it isn't clipped. Red/green: with the
previous long wording restored, the fit assertion fails with the measured
overflow (zh and zh-TW by 14px at 440, ja by 189px, de by 68px); with the
new wording all ten pass. i18n-keys, gui-de, gui-ja and gui-zh-tw pass.
* gui: the claim-line test's README says what it covers, and its fit check measures the box
Two things from review (#1001): the README paragraph still said "in
English and Chinese" and said nothing about the widths, though the test
now covers every language magpie has at 440, 560 and 1000px — a
translated name is a sentence and .quota-labels > span is nowrap with no
ellipsis, so the width is the point of the test, and 1000 alone could
never catch a name that is too wide.
And the fit check read `s.scrollWidth > s.clientWidth + 1`, which is
always false on an inline span: the dead half is gone and the name's own
box is compared with its .quota instead, which is what actually catches a
cut name (the `over` value beside it was doing the work). Red/green, with
the long wording restored: "the name is cut off at 440px: 14px past its
quota, wider=true" (zh, zh-TW), 189px (ja), 68px (de).