Install regional browser locale data

[tnsardesai]

summary

• install tzdata and locales in headful and headless browser images
• generate the US, UK, Canadian, Irish, and Singapore English POSIX locales
• add Chrome locale resource aliases for the English locales Chrome does not package separately

why

Browser VMs need timezone data for process-level TZ handling and generated locales for LANG/LC_ALL. Chrome also needs a matching locale resource pack or it falls back to a packaged locale.

tests

• built the complete headless Docker image
• verified all generated locales and Chrome locale packs inside the image
• launched headless Chrome with Asia/Singapore / en-SG and verified the JavaScript timezone, Intl locale, and navigator language

---

Note

Low Risk
Image-layer and test-only changes for locale/timezone fidelity; no runtime server logic or auth/data paths affected.

Overview
Headful and headless Chromium images now ship OS-level timezone data and several English POSIX locales, and Chrome gets locale resource packs for regions Chrome does not bundle separately.

Both Dockerfiles install locales and tzdata, run locale-gen for en_US, en_GB, en_CA, en_IE, and en_SG UTF-8, and during Chrome-for-Testing install copy en-GB.pak to en-CA, en-IE, and en-SG so --lang can match container LANG/TZ without falling back to a default pack.

A new e2e test (TestRegionalBrowserLocation) starts each image with Singapore timezone and en-SG env/flags, checks the container reports UTF-8 and +0800, and uses CDP to assert navigator.language, Intl locale, and timezone in the browser.

^{Reviewed by Cursor Bugbot for commit 6486e5b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Sayan-]

• p2 the en-GB.pak copies appear to have no observable effect. Against the pinned chrome-for-testing 152.0.7977.42: without them, LANGUAGE=en_CA / en_IE / en_SG already open locales/en-GB.pak; with them the opened filename changes but the file is md5-identical, and navigator.language reads en-GB either way, since it follows --accept-lang.
• p2 the tzdata install is not browser-visible. With TZ=America/New_York and no tzdata present, Intl.DateTimeFormat().resolvedOptions().timeZone already reports America/New_York, identical to the post-install result, because Chromium resolves TZ through bundled ICU. It does fix glibc-level time, which prints America as the zone abbreviation today.
• p2 no test or e2e assertion in this repo covers timezone or locale.
• p2 pre-existing and untouched here: server/cmd/wrapper/chromium.go:17 hardcodes --accept-lang=en-US,en on the default headless path, so local and e2e runs stay en-US regardless of the locales this adds.

[tnsardesai]

addressed in 6486e5b.

the .pak copies do have an observable effect beyond navigator.language on Chrome 152.0.7977.42. with --lang=en-SG --accept-lang=en-SG,en:

• without en-SG.pak: navigator.language is en-SG, but Intl.DateTimeFormat and Intl.NumberFormat resolve to en-GB
• with the en-SG.pak alias: both Intl APIs resolve to en-SG and use Singapore-specific formatting

the pack filename preserves the application locale while reusing the identical en-GB UI strings, so i kept the aliases and documented why.

also kept tzdata for guest-process/glibc coherence, and added a headful + headless e2e test that starts with production-shaped Singapore settings and asserts the OS UTF-8 locale/+0800 offset plus navigator.language, the Intl locale, and the Intl timezone. that test passes in CI.

i didn't change the wrapper default: production supplies non-empty CHROMIUM_FLAGS, so applyHeadlessDefaultFlags() is bypassed. the new e2e passes the regional flags explicitly.