Native UX engineering
Changing Language Without Restarting the Product
A language change should update what the player reads, not restart the sensor session or alter a billing decision. I separated display formatting from stable product state.
Senior AI Engineer · M.S. Computer Science, Tsinghua University · See the products I built
In this article · 5 sections
The engineering decisions
- Load the selected catalog before rendering and rerender without remounting the application.
- Keep machine keys, consent evidence and calculations independent of display locale.
- Give English speech its own formatter instead of parsing localized screen text.
Translation was a lifecycle change
The native implementation added ten languages alongside English. The language runtime was separated from the catalogs, and the app loaded its selected catalog before rendering to avoid an initial flash of English. Switching inside the app rerendered the root without remounting it.
That distinction protected sensor sessions, reserved booking state and open panels. The language preference also used its own device setting rather than rewriting unrelated preferences. Later web-localization work had its own acceptance and release scope, so the first native implementation did not imply that every web surface had changed too.
Localize presentation, not machine identity
A display date and a date key are different values. The implementation preserved machine-readable date labels, timezone validation and values used in comparisons. Formatting those values differently could otherwise change the result of a business equality check, including whether an existing consent checkbox remained selected.
Cached formatters needed locale-aware keys. Time ranges needed language-appropriate formatting instead of English-only AM/PM manipulation. Venue wall-clock opening hours could not be interpreted in the phone’s current timezone. Currency displays also had to distinguish non-U.S. dollars instead of reducing every currency to an ambiguous symbol.
Preserve the exact source of consent
The project’s chosen consent flow retained the English source text for the recorded agreement and its hash, with a separately labeled reference translation. The translated amount was for display. The amount inside the source agreement remained formatted by the explicit English path.
The reference translation was placed outside the checkbox label so assistive technology would not read the agreement twice as the control’s name. Designated English-only SMS consent blocks stayed outside the translated dictionaries. These were the product’s implementation rules, not a general legal conclusion about multilingual agreements.
Do not make speech parse a translated label
The native release review found that decimal commas, localized units and direction labels could break English shot readout. I added an explicit English formatting path for speech without changing the global interface language. The same measurement could then be displayed in the selected locale and spoken through the expected English vocabulary.
The release regression covered distance, speed and direction in German and Russian. The store copy kept the speech language explicit, and placement guidance stayed limited to supported sensors. A translated interface did not imply translated audio or universal device support.
Test state preservation as well as vocabulary
The useful checks included changing locale with active UI state, catalog completeness, native-message mapping, narrow-screen wrapping and language-panel focus behavior. They also checked that the language actually activated, since a failed catalog registration could otherwise leave a test accidentally exercising English.
The October 4 native release record reports automated and packaged-artifact checks and accepted submissions to both stores at that time. It explicitly records no new physical sensor-orientation or speech-listening test for that build. The separately verified Google Play listing establishes Android availability, while that submission record alone does not establish Apple availability or a new physical-device acceptance pass.
Project context and evidence
Written from my October 2026 Play localization implementation and native release records. Public links below support the product and attribution context. Internal project records are summarized, with customer records, credentials, and employer source code omitted.
- GolfJoy Play on Google Play ↗
Official Android listing. Store images contain sample values, not field-test evidence.
- GolfJoy engineering case study ↗
Public product interfaces and attribution for the delivered projects.
