Backend/i18n: Localize date/times with Babel

[tristanlabelle]

Localizes dates, times, datetimes and timezone names using the Babel library, which bundles a serialized Unicode CLDR. Also removes the manual implementation of Unicode plural rules in favor of Babel's. This will be visible in dates in push notifications, and emails once they are localized.

⚠️ This changes some date formats because we can't yet specify short/long formats (hence test changes). I don't think it's a big deal but I'll follow-up with supporting that: #7885.

⚠️ This adds 33MB to our app size, because of the size of the Unicode CLDR. If this is a huge problem, we could implement a hack and selectively delete most locales (the CLDR defines over 1100 locales) to bring this way down.

.venv/lib/site-packages
33M     babel
124K    babel-2.18.0.dist-info

Fixes #7590

Testing

Added tests and ran existing ones.

Emails are not yet localized but we can see the timezone is now nice text:

Compare with previously:

Backend checklist

• Added tests for any new code or added a regression test if fixing a bug
• Run the backend locally and it works
• Added migrations if there are any database changes, rebased onto develop if necessary for linear migration history

For maintainers

• Maintainers can push commits to my branch
• Maintainers can merge this PR for me

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
couchers	Ready	Preview	Feb 12, 2026 4:06am

[aapeliv]

Very happy to have plural rules from CLDR, and very supportive of this in general!

A few other comments:

1. We will now need to start implementing full locales, not just language in what the user can specify somehow on the settings page; as e.g. en_US is different from en_AU. I guess this can wait though and is no worse than hardcoding it the way we have it now. (I have a personal pet peeve on some of the date and time formatting stuff etc; but that's not important.)
2. I'm weary of the time zone names. I'm worried the time zone names in babel make sense to someone in a locale in their own local (pun intended) environment, but not as much sense in a global context. I kind of feel like our travel-centric community is on average much more comfortable with timezones and would for instance prefer to have the UTC offset in the email compared to just "United Kingdom Time" or the super vague "Eastern Time" (in Australia we have "Eastern Time" which is very different from US ET, though often we'll call it "Australian Easter Time" which is its full name).
3. [Extra Random thought]: we could actually have separate en_AU/en_US/en_GB/etc translations pretty easily with LLMs, though that's probably overkill.

[tristanlabelle]

@aapeliv Cool, any of these are blockers?

1. Yes full locales would be better, and the problem is not aggravated by this PR so we can look into it separately. The tricky part will be figuring out a UX for that.
2. I believe the CLDR also has city-name based timezones like "Asia/Shanghai" that might be clearer than both UTC offsets and timezone names. The frontend seems to use these. I could switch to it in this PR or as follow-up. Right now I think backend timezones are only in emails and it's your timezone so the surprise factor is low.
3. That'd be interesting to play with!

[tristanlabelle]

@aapeliv It turns out it we can't really state that all times in the email are in a timezone as an UTC offset because the email could reference dates in the past or the future that cross the daylight savings boundary. To make the timezone more readable, we can add the example city in parens (this is provided by the CLDR), so for example we could display United Kingdom Time (London). WDYT?

        name = get_timezone_name(timezone, locale=locale)
        location = get_timezone_location(timezone, locale=locale, return_city=True)
        return f"{name} ({location})" if location != name else name

[aapeliv]

@aapeliv It turns out it we can't really state that all times in the email are in a timezone as an UTC offset because the email could reference dates in the past or the future that cross the daylight savings boundary. To make the timezone more readable, we can add the example city in parens (this is provided by the CLDR), so for example we could display United Kingdom Time (London). WDYT?

I think better to leave it as the localized timezone name. I suppose that is the best option here.

On the UTC offset: that's fair but also I don't think it's that big a correctness issue.

[aapeliv]

lgtm, let's think about the locale input further as we go