PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

Description

@os-warren

Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

The gap

PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

Why this reads as a missed key rather than a decision

The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

What an application does today

The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

Suggested shape

Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


Triage — two corrections, and they move the card's centre of gravity

Measured at origin/mainb8562ff262.

(a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

(b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

Why it is still a decision, and not simply closed

Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

<!-- os-decision-facets -->

推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

Generated by Claude Code

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
       blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
      }
      } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
      })();
      (function(){
      try {
      var __m = "github.com";
      var __re = new RegExp('^' + "github\\.com" + '
      
      Skip to content

      PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

      Description

      @os-warren

      Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

      The gap

      PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

      element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

      Why this reads as a missed key rather than a decision

      The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

      What an application does today

      The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

      Suggested shape

      Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

      Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


      Triage — two corrections, and they move the card's centre of gravity

      Measured at origin/mainb8562ff262.

      (a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

      (b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

      packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

      I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

      And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

      the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

      element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

      ⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

      Why it is still a decision, and not simply closed

      Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

      <!-- os-decision-facets -->

      推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
      ⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
      回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
      置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

      Generated by Claude Code

      Metadata

      Metadata

      Assignees

      No one assigned

        Type

        No type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
          Skip to content

          PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

          Description

          @os-warren

          Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

          The gap

          PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

          element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

          Why this reads as a missed key rather than a decision

          The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

          What an application does today

          The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

          Suggested shape

          Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

          Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


          Triage — two corrections, and they move the card's centre of gravity

          Measured at origin/mainb8562ff262.

          (a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

          (b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

          packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

          I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

          And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

          the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

          element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

          ⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

          Why it is still a decision, and not simply closed

          Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

          <!-- os-decision-facets -->

          推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
          ⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
          回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
          置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

          Generated by Claude Code

          Metadata

          Metadata

          Assignees

          No one assigned

            Type

            No type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

              Description

              @os-warren

              Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

              The gap

              PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

              element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

              Why this reads as a missed key rather than a decision

              The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

              What an application does today

              The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

              Suggested shape

              Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

              Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


              Triage — two corrections, and they move the card's centre of gravity

              Measured at origin/mainb8562ff262.

              (a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

              (b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

              packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

              I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

              And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

              the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

              element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

              ⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

              Why it is still a decision, and not simply closed

              Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

              <!-- os-decision-facets -->

              推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
              ⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
              回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
              置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

              Generated by Claude Code

              Metadata

              Metadata

              Assignees

              No one assigned

                Type

                No type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions

                  , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
                  Skip to content

                  PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

                  Description

                  @os-warren

                  Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

                  The gap

                  PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

                  element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

                  Why this reads as a missed key rather than a decision

                  The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

                  What an application does today

                  The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

                  Suggested shape

                  Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

                  Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


                  Triage — two corrections, and they move the card's centre of gravity

                  Measured at origin/mainb8562ff262.

                  (a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

                  (b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

                  packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

                  I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

                  And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

                  the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

                  element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

                  ⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

                  Why it is still a decision, and not simply closed

                  Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

                  <!-- os-decision-facets -->

                  推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
                  ⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
                  回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
                  置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

                  Generated by Claude Code

                  Metadata

                  Metadata

                  Assignees

                  No one assigned

                    Type

                    No type

                    Projects

                    No projects

                      Milestone

                      No milestone

                      Relationships

                      None yet

                      Development

                      No branches or pull requests

                      Issue actions

                      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                      Skip to content

                      PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

                      Description

                      @os-warren

                      Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

                      The gap

                      PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

                      element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

                      Why this reads as a missed key rather than a decision

                      The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

                      What an application does today

                      The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

                      Suggested shape

                      Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

                      Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


                      Triage — two corrections, and they move the card's centre of gravity

                      Measured at origin/mainb8562ff262.

                      (a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

                      (b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

                      packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

                      I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

                      And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

                      the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

                      element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

                      ⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

                      Why it is still a decision, and not simply closed

                      Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

                      <!-- os-decision-facets -->

                      推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
                      ⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
                      回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
                      置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

                      Generated by Claude Code

                      Metadata

                      Metadata

                      Assignees

                      No one assigned

                        Type

                        No type

                        Projects

                        No projects

                          Milestone

                          No milestone

                          Relationships

                          None yet

                          Development

                          No branches or pull requests

                          Issue actions

                          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                          Skip to content

                          PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

                          Description

                          @os-warren

                          Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

                          The gap

                          PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

                          element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

                          Why this reads as a missed key rather than a decision

                          The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

                          What an application does today

                          The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

                          Suggested shape

                          Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

                          Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


                          Triage — two corrections, and they move the card's centre of gravity

                          Measured at origin/mainb8562ff262.

                          (a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

                          (b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

                          packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

                          I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

                          And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

                          the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

                          element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

                          ⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

                          Why it is still a decision, and not simply closed

                          Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

                          <!-- os-decision-facets -->

                          推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
                          ⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
                          回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
                          置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

                          Generated by Claude Code

                          Metadata

                          Metadata

                          Assignees

                          No one assigned

                            Type

                            No type

                            Projects

                            No projects

                              Milestone

                              No milestone

                              Relationships

                              None yet

                              Development

                              No branches or pull requests

                              Issue actions

                              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                              Skip to content

                              PageTranslation.components has no key for element:text's content — the one string that element renders cannot be addressed by a bundle #14412

                              Description

                              @os-warren

                              Found while authoring a read-only record page in an application (objectstack-ai/duly#13) with a complete zh-CN bundle, on @objectstack/spec 17.2.0.

                              The gap

                              PageTranslation.components (packages/spec/src/system/translation.zod.ts) declares the per-component key face as title | description | label | placeholder | emptyText | submitLabel.

                              element:text renders exactly one authored string, content, and it is not in that list. So a page that puts a sentence on screen through the element the platform provides for putting a sentence on screen has no bundle address for it.

                              Why this reads as a missed key rather than a decision

                              The schema's own comment says the face was derived from the copy props components declare, and it names its two deliberate exclusions — help and subtitle — with reasons. content is neither named nor excluded; it is simply absent. Every other authored string on the same page has a key.

                              What an application does today

                              The blessed alternative works: an inline I18nLabel map ({ en, 'zh-CN' }) on content, which is what the platform's own sys-user.page.ts does. The reporting app uses it, and its coverage walk records those strings under an untranslatable ledger with this reason, pinned by count (16 strings on one page). That is a workaround with a cost: those strings are invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle, and each one is an inline map in a page definition instead of a row in the locale file.

                              Suggested shape

                              Add content to PageTranslation.components, resolved in translatePage for element:text (and any sibling element whose display string is content). If it is deliberately out — because inline maps are the intended route for page prose — the schema comment should say so beside help and subtitle, so the next author finds a decision instead of an absence.

                              Related: #14253 (three other authored display surfaces with no key; merged as #14381), #14376 (extractor coverage of new key families).


                              Triage — two corrections, and they move the card's centre of gravity

                              Measured at origin/mainb8562ff262.

                              (a) The face no longer carries submitLabel. It left in @objectstack/spec 17 (#10926, ADR-0049) and the current shape is five keys: titledescriptionlabelplaceholderemptyText (translation.zod.ts:927-931). Minor, but the card's premise is a census, so the census should be right.

                              (b) ⭐ The inline map is not a workaround — it is the ruled route, and this exact question was decided twice.

                              packages/spec/src/ui/component.zod.ts:1784 declares content: I18nLabelSchema, and the docblock above it (:1773-1783) records why:

                              I18nLabelSchema rather than a bare z.string() (#5728, named explicitly in the maintainer's ruling because the label-wide widening could not reach it): sys-user.page.ts authors eight element:text nodes whose content is an inline { en, 'zh-CN', 'ja-JP', 'es-ES' } map… The bare string was the declaration disagreeing with the delivered shape.

                              And the submitLabel retirement one file over (translation.zod.ts:867-876) is the same shape, decided the same way:

                              the live form surface's submit copy is object-form's submitText (I18nLabelSchema), localizable at its own authoring site, and adding it here would be a face widening.

                              element:text.content is an I18nLabelSchema localizable at its own authoring site. By the precedent, adding it to the bundle face is a face widening — the thing #10926 declined to do for the identical shape.

                              ⇒ The card's framing ("a missed key… neither named nor excluded") does not survive. What is genuinely missing is the sentence, not the key: content's absence is a decision that was made elsewhere and never written down beside help and subtitle. That is the card's own second option, and the precedent points at it.

                              Why it is still a decision, and not simply closed

                              Because the card raises something the two rulings did not weigh. #5728 and #10926 both answered "can this string be localized?" — yes, at its authoring site. This card asks "can it be extracted and counted?" — and the answer is no. Sixteen strings on one page, invisible to os i18n extract, to check:i18n-coverage, and to a translator working from the bundle. That is a new argument against a settled route, measured outside this repo, and it is the maintainer's to weigh rather than the seat's to wave through on precedent.

                              <!-- os-decision-facets -->

                              推荐:A(卡面的第二个选项)—— 不加键,把排除理由写进 schema 注释,与 helpsubtitle 并列,引 #10926 的原话作依据。 ①④同向,③被它满足。
                              ⚠️但 A 不解决 ②,必须说清楚:那 16 条字符串仍然对抽取器和覆盖率门禁不可见。所以荐 A 的同时建议另开一张卡问「内联 I18nLabel 映射该不该被 os i18n extractcheck:i18n-coverage 看见」—— 那才是 ② 真正要的东西,而且它对所有用内联映射的字段都成立,不止 element:text,因此比给一个组件补键更能关掉这一类。⛔ 本席不代开那张卡,那是拿到方向之后的事。
                              回退:B(卡面的第一个选项) —— 把 content 加进面并在 translatePage 里解析。若维护者认为 bundle 面才是页面散文的正路、内联映射只是过渡形态,走这条。代价:同一字符串两条路径,并且必须一并裁定两者同时存在时谁赢。
                              置信缺口(本分析看不见什么): 没有量 objectui 侧 pickLocalized 与 bundle overlay 的优先级。若走 B,一个 content 同时带内联映射和 bundle 条目时谁赢,是 B 上线前必须先答的问题 —— 本轮没量,而它决定 B 的真实代价是「加一个键」还是「加一个键 + 一条冲突规则」。

                              Generated by Claude Code

                              Metadata

                              Metadata

                              Assignees

                              No one assigned

                                Type

                                No type

                                Projects

                                No projects

                                  Milestone

                                  No milestone

                                  Relationships

                                  None yet

                                  Development

                                  No branches or pull requests

                                  Issue actions