Your Chinese looks perfect here.
On a player's PC it's a row of boxes.

What the engine actually guarantees

Godot's built-in UI font is Open Sans SemiBold, and it is a subset. Asking the engine itself — ThemeDB.fallback_font.has_char(cp) for every codepoint in the BMP, the emoji planes and CJK Extension B — gives an exact number: 1010 codepoints, in 92 ranges (G1, Y1). That enumeration is the table this page scans against; it is generated by the verification script, not typed by hand.

Two of those rows are the reason this page exists. This is not a "non-Latin languages" problem. A project with no translation at all, whose entire UI is English, ships a hex box the moment a designer writes Continue → Next or OK ✓ (G16, G18). And the em dash, the ellipsis, the curly quotes and the euro sign are in the font (G17) — so "avoid non-ASCII" is not the rule, and guessing does not work. That is why the set is measured.

Then why does it look fine on your machine?

Because Godot borrows. Shaping 你好 with the built-in font still produces two real glyphs (S1) — and they carry a font_rid that is not the built-in font's (S2). OS.get_system_font_path_for_text() names where they came from (S3):

OS.get_system_font_path_for_text("Sans", "你好")
["/usr/share/fonts/truetype/wqy/wqy-zenhei.ttc",
 "/usr/share/fonts/opentype/unifont/unifont.otf"]

An absolute OS path, not a res:// path. Same for an emoji in a UI string (Y2). None of it travels inside your .pck. Your development machine — a full desktop with a font package installed — is the single worst place to test whether your player can read your game.

What the player without that font sees

FontFile.allow_system_fallback = false reproduces it, and it is the closest thing to a player's machine you can run in CI:

• the same two-character string becomes 2 undrawable glyphs (S4), while an ASCII string is untouched (S5);
• one arrow inside an otherwise ASCII line is 1 undrawable glyph (S6);
• the correct, properly translated 开始 that came back from tr() is 2 undrawable glyphs (T3). The data is right and the pixels are not.

The marker is not glyph index 0

If you go looking for this in code, do not test for a zero glyph index — you will find nothing. Godot marks an undrawable codepoint by putting the codepoint itself in index and leaving font_rid invalid (S4b):

你好 | index=20320 (U+4F60)  font_rid=RID(0)  valid=false

That pair is the hex box on screen, and it is the only reliable way to detect this from inside the running game.

Why nothing warns you

• get_string_size() returns a non-zero width for text the font cannot draw (S8) — layout does not collapse, so nothing upstream trips.
• Nothing is printed to the console.
• has_char() answers false for U+4F60 while shaping is drawing it from a borrowed font (S7). The project-side check and the screen disagree, and both are telling the truth about different things.
• tr() returns the translated string, not the key (T2) — so every "Godot prints the raw key" checklist, including ours, sends you looking in the wrong place.

The fix, and the shape of it

var body := FontFile.new()
body.load_dynamic_font("res://fonts/NotoSansSC-Regular.ttf")

var ui := ThemeDB.fallback_font.duplicate()
ui.allow_system_fallback = false   # fail loudly here, not on a player's PC
ui.fallbacks = [body]

Measured: with system fallback off, a Font in fallbacks takes the arrow's undrawable glyph to zero (S10). Measured just as carefully: the same fallback does not fix Chinese, because DejaVu Sans has no CJK either (S11). A fallback only covers what it actually owns — so "add a fallback font" is not advice until you know which codepoints you are shipping. Which is what the tool at the top answers.

Reproducing all 35 claims

git clone https://github.com/leobaray/locguard
docs/verify_font_glyphs.sh /path/to/Godot_v4.7-stable_linux.x86_64 dump.json

Every claim id on this page is printed by that script. The optional second argument re-dumps the coverage ranges as JSON — that file is the source of the table this page scans against, so a Godot upgrade is a re-run and a diff, not a rewrite. Last run: 35 passed / 0 failed against 4.7.stable.official.5b4e0cb0f. The full write-up is docs/font-glyphs-missing-in-translations.md, and the scanner this page runs is docs/glyph-scan-core.js — byte for byte the file the command line uses.

Measured the same way

• Godot prints the raw key instead of the translation — 32 claims
• The player changes language and half the UI does not — 13 claims
• Generate POT reported success and left strings out — 61 claims
• It translates in the editor and the exported build ships in English — 26 claims