Hi — I've opened #1937 adding Thai (th_TH) as a new locale, following the existing
ar_SA / he_IL / zh_CN pattern. It's deliberately font resources only: five
files, no firmware or tooling changes.
I have a few questions I couldn't answer from the repo alone.
1. Are new locales welcome right now?
If localization is paused or you'd rather not take community locales at this stage,
I'd rather hear that now than have the PR sit open.
2. Can th_TH be enabled as a Crowdin target, and how do I get translator access?
This is the main blocker. CONTRIBUTING.md is clear that translated text doesn't go
through pull requests, so #1937 ships strings.file: "" (fonts only, as ar_SA does)
and has no tintin.po. I can't add the Thai strings anywhere until th_TH exists on
Crowdin. crowdin.yml only references a project ID via env var, so I can't tell from
the repo whether Thai is already configured.
Worth noting the locale is already useful without translations: notification content
comes from the phone and is rendered by these fonts regardless of the UI string
catalog. I verified that a fonts-only pack renders and wraps Thai notifications
correctly. Only system UI labels stay English until translations land.
3. Guidance on combining-mark positioning.
On physical PT2, most sequences render cleanly — including tall-ascender cases like
ปิดเครื่อง and เปิดใช้ด่วน — but กี่ and สี่เหลี่ยม show tone-mark overlap.
As I understand it the renderer places glyphs purely by the font's advance metrics
with no OpenType mark positioning, so placement depends entirely on the font.
I prototyped runtime mark positioning but dropped it from the PR: it was ~400 lines
touching shared text rendering used by every locale, and it didn't actually fix those
two sequences. Before going further I'd rather ask — would you prefer this solved by
font choice, by adding mark-positioning support to the renderer, or is a small amount
of overlap on some sequences acceptable for now? Happy to do the work either way,
but this seems like your call rather than mine.
Testing so far: builds and renders in QEMU on qemu_emery, qemu_flint and
qemu_gabbro; glyphs fit within both the 256 B and 512 B MAX_FONT_GLYPH_SIZE
limits; word-wrap verified through the notification path (U+200B at word boundaries
gives clean breaks; without it the engine hyphenates mid-syllable but loses no text);
mixed Thai/Latin renders correctly; confirmed on physical PT2.
Separately, I hit a few dev-environment papercuts while setting this up — installing
a language pack onto ./pbl qemu needs pypkjs started manually as a bridge, the
pbl/pebble wrappers in tools/libs/pbl crash on startup, and the .po header
that ./pbl make_lang generates fails prv_get_metadata()'s numeric
Project-Id-Version check silently. Happy to file those as separate issues if
useful — I didn't want to clutter this one.
Hi — I've opened #1937 adding Thai (
th_TH) as a new locale, following the existingar_SA/he_IL/zh_CNpattern. It's deliberately font resources only: fivefiles, no firmware or tooling changes.
I have a few questions I couldn't answer from the repo alone.
1. Are new locales welcome right now?
If localization is paused or you'd rather not take community locales at this stage,
I'd rather hear that now than have the PR sit open.
2. Can
th_THbe enabled as a Crowdin target, and how do I get translator access?This is the main blocker.
CONTRIBUTING.mdis clear that translated text doesn't gothrough pull requests, so #1937 ships
strings.file: ""(fonts only, asar_SAdoes)and has no
tintin.po. I can't add the Thai strings anywhere untilth_THexists onCrowdin.
crowdin.ymlonly references a project ID via env var, so I can't tell fromthe repo whether Thai is already configured.
Worth noting the locale is already useful without translations: notification content
comes from the phone and is rendered by these fonts regardless of the UI string
catalog. I verified that a fonts-only pack renders and wraps Thai notifications
correctly. Only system UI labels stay English until translations land.
3. Guidance on combining-mark positioning.
On physical PT2, most sequences render cleanly — including tall-ascender cases like
ปิดเครื่องandเปิดใช้ด่วน— butกี่andสี่เหลี่ยมshow tone-mark overlap.As I understand it the renderer places glyphs purely by the font's advance metrics
with no OpenType mark positioning, so placement depends entirely on the font.
I prototyped runtime mark positioning but dropped it from the PR: it was ~400 lines
touching shared text rendering used by every locale, and it didn't actually fix those
two sequences. Before going further I'd rather ask — would you prefer this solved by
font choice, by adding mark-positioning support to the renderer, or is a small amount
of overlap on some sequences acceptable for now? Happy to do the work either way,
but this seems like your call rather than mine.
Testing so far: builds and renders in QEMU on
qemu_emery,qemu_flintandqemu_gabbro; glyphs fit within both the 256 B and 512 BMAX_FONT_GLYPH_SIZElimits; word-wrap verified through the notification path (U+200B at word boundaries
gives clean breaks; without it the engine hyphenates mid-syllable but loses no text);
mixed Thai/Latin renders correctly; confirmed on physical PT2.
Separately, I hit a few dev-environment papercuts while setting this up — installing
a language pack onto
./pbl qemuneedspypkjsstarted manually as a bridge, thepbl/pebblewrappers intools/libs/pblcrash on startup, and the.poheaderthat
./pbl make_langgenerates failsprv_get_metadata()'s numericProject-Id-Versioncheck silently. Happy to file those as separate issues ifuseful — I didn't want to clutter this one.