Backend/i18n: Localize region & spoken language names - #9173
Conversation
MobileInstall the Dev Tool (iOS via TestFlight, iOS Simulator, or Android .apk) here. Scan the QR with your phone camera, or tap Open in Dev Tool on the device, to open this branch in the installed Dev Tool dev client.
Deep linksiOS Android Web (Vercel)View the Vercel web preview for this branch. Backend
Other
|
|
@tristanlabelle Looks like some web tests are failing! |
d34d0c6 to
aa5b468
Compare
|
@nabramow , the failures were a fluke / unrelated flakiness. I rebased and tests passed. Ready for ✅
|
aapeliv
left a comment
There was a problem hiding this comment.
Babel claims to support RFC3066, which claims to support also the three character codes https://datatracker.ietf.org/doc/html/rfc3066.html#section-2.2
This appears to work for me:
$ uv run --with babel python
Python 3.14.2 (main, Dec 5 2025, 21:11:58) [Clang 21.1.4 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import babel
>>> babel.Locale.parse("fin").get_language_name("swe")
'finska'
>>>
do we then not need modification to the languages source of truth file?
|
@aapeliv Thanks for catching the support for 3-letter language codes. I'll remove the extra complexity. We do need the 2-letter code for regions though. |
10f9eff to
f5ebb4d
Compare
|
@aapeliv 2-letter language codes are out. Ready for ✅ |
aapeliv
left a comment
There was a problem hiding this comment.
sorry one more thing on the backend side!
|
@aapeliv , should be good now! |
📝 Release NotesThis PR should be included in the release notes. Suggested release note: 🤖 Bot Debug InformationModel: |
Since Couchers-org#9173, GetLanguages localized all ~300 language names on every request via babel.Locale.parse, costing ~38ms of CPU per call. The responses are static per locale, so cache the built protos. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>


Updates the
GetLanguagesandGetRegionsAPIs to return names localized in the current user's locale, at least where the Unicode CLDR defines those translations, which should hold for all regions and most common languages.In both cases, our database stores 3-char codes, but the Unicode CLDR lookup is by 2-char codes. I had to add a mapping from 3-char codes to 2-char codes (where it exists) as to be able to leverage the CLDR without changing our database tables. In the case of languages, I updated
languages.jsonto add 2-char codes for languages that have one.In the end this fix is independent from #9169, but that frontend change is still an improvement.
Fixes #8424
Testing
Ran local backend + frontend, added tests.
Backend checklist
developif necessary for linear migration historyFor maintainers