Skip to content

Localize generated variable and SpriteKind labels without changing identity - #11615

Open
Christian BR (ChrisesDK) wants to merge 2 commits into
microsoft:masterfrom
ChrisesDK:complete-rendered-label-localization
Open

Christian BR (ChrisesDK) wants to merge 2 commits into
microsoft:masterfrom
ChrisesDK:complete-rendered-label-localization

Conversation

@ChrisesDK

@ChrisesDK Christian BR (ChrisesDK) commented Sep 21, 2026 •

Copy link
Copy Markdown

PXT upstream pull request

Title

Localize generated variable and SpriteKind labels without changing identity

Base and head

  • Base: microsoft/pxt:master
  • Head: ChrisesDK:complete-rendered-label-localization
  • Local branch and commit: complete-rendered-label-localization at
    95be24b3dffb214754245672cad28722397e7d40

Description

Summary

Some pupil-visible generated/default Blockly variable labels and built-in
SpriteKind labels currently render raw identifiers, so they cannot be
localized through the normal MakeCode localization pipeline. This change
separates localized display text from stored and compiler-facing identity.

It adds opt-in, display-only localization for generated/default variable labels
and localized display labels for built-in SpriteKind dropdown members.
When MakeCode automatically uniquifies a generated default variable name,
numbered variants reuse the localized display of the base concept. For example,
generated mySprite2 and mySprite3 display as the localized form of
mySprite followed by the raw suffixes 2 and 3, without creating separate
localization keys.

Compatibility

  • Raw variable model names, variable IDs, and Blockly XML remain unchanged.
  • Generated TypeScript and Python identifiers remain unchanged.
  • Built-in SpriteKind dropdown values remain raw (Player, Projectile,
    Food, and Enemy).
  • Ordinary user-created variables and custom SpriteKinds retain their existing
    behavior; a matching standalone user variable is not globally aliased.
  • The implementation is locale-independent and introduces no locale-specific
    production hardcoding.

Localization surface

This exposes 14 localization concepts:

  • {id:var}anim
  • {id:var}location
  • {id:var}myTile
  • {id:var}tile list
  • {id:var}projectile
  • {id:var}otherSprite
  • {id:var}myEnemy
  • {id:var}picture
  • {id:var}mySprite
  • {id:var}list
  • SpriteKind.Player
  • SpriteKind.Projectile
  • SpriteKind.Food
  • SpriteKind.Enemy

The localization gaps addressed by this change were validated against the
rendered block-label mechanisms observed during a Danish Arcade localization
review. This is implementation-validation context, not formal exhaustive QA.

Validation

  • TypeScript/typecheck passed on the refreshed-base work.
  • Python identity round trip passed: 27/27.
  • A previous focused Blockly/Karma localization run passed: 152/152 on the
    original verified implementation.
  • 611 applicable component tests passed across completed earlier runs.
  • The PXT production build passed on the earlier verified implementation.
  • The Arcade target build passed.

The final branch does not have a fresh complete Karma run: Puppeteer's cached
Chrome executable is unavailable locally. This is an environment block, not an
observed implementation test failure. A final combined rerun stopped after 427
passing tests at that browser-launch step and was not a complete combined run.
No implementation failure has been observed; normal upstream CI is still
expected.

Follow-up

pxt-common-packages has a dependent follow-up that opts the relevant Arcade
library surfaces into this generic PXT capability. PXT must land and be
synchronized before that follow-up is merged.

Out of scope

This source PR deliberately does not include ordinary Crowdin wording fixes,
Crowdin-to-Arcade publication lag, Danish terminology decisions, or enabling
the da locale. Those are separate localization-content and deployment work.

@ChrisesDK

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant