Awesome stuff as usual, we’re rocking Localize in production and it has been a very, very good experience. Localize.Inputs.Date.Components.DatePickerLive got me thinking. We’re used to splitting locale into language, timezone and formatting conventions. We have a lot of customers who want to see e.g. the UI in English, in Amsterdam timezone, with Swedish datetime format. I feel like most people (and libraries) assume locale should implicitly determine both language and formatting preferences. Just out of curiosity, how do you, or anyone here, feel about this?
odd
0
kip
ex_cldr Core Team
Just out of curiosity, how do you, or anyone here, feel about this?
As a library writer I try to be aggressively ambivalent about it. By which I mean, use Localize.default_locale/0 if not specified, but take a :locale option on all functions so you can achieve what you’re after - at least in Localize.
I broadly agree that users see value in being more explicit about their choices if they want to. But should also get a reasonable response if they don’t have firm preferences. The UI to make all of that straight forward is not something I’m skilled at at all!
PS: Really glad you’re finding Localize up to the job, thanks for saying so.
1
kip
ex_cldr Core Team
I’ve published localize version 0.45.0 which has a primary focus on conformance, robustness and code quality. A lot of bugs have been squashed.
In combination with this release as well as 0.44.0, 0.43.0, 0.42.0 and 0.41.0, I consider Localize now to be a solid 1.0 candidate release. This means that you can expect a period of stability after a flurry or work and you can expect a 1.0 candidate release by the end of July.
Changelogs
Deprecations
While it’s not yet at 1.0, I have tried to keep the public API stable. However in the interests of consistency in function naming and stability for the long term, I have made a few changes in 0.43.0.
The existing function names will continue to operate but will issue a depreciation message. The deprecated functions will be removed when I publish Localize 1.0.
Deprecated functions (and their replacements)
The naming rule is now uniform: known_* is the locale-independent CLDR universe, supported_* reflects configuration, and *_for is data localized into a display locale. The renamed functions are:
-
Language.available_languages/1→Language.languages_for/1. -
Language.known_languages/1→Language.language_names_for/1. -
Script.available_scripts/1→Script.scripts_for/1. -
Script.known_scripts/1→Script.script_names_for/1. -
Subdivision.available_subdivisions/1→Subdivision.subdivisions_for/1. -
Subdivision.known_subdivisions/1→Subdivision.subdivision_names_for/1. -
Territory.available_styles/0→Territory.known_styles/0.
Renamed options
Two option names are also swapped for consistency; the deprecated keys remain accepted until 1.0:
-
The
:styleoption ofLocalize.Duration.to_string/2and ofLocalize.quote/2is deprecated in favour of:format. -
The
:formatoption ofLocalize.Unit.display_name/2is deprecated in favour of:style.
4
kip
ex_cldr Core Team
One of the biggest complaints about ex_cldr has always been the compile time cost. Localize improved on that out-of-the-box, but not in a material way. But with today’s Localize version 0.46.0, you can expect significant improvement in compile time.
On my Mac M1 Max, a cold compile has reduced from 66s → 3.5s, a 19x improvement. In addition, the generated BEAM files are 1.7Mb smaller.
Now you can expect Localize to be more robust, more conformant and faster at compiling.
9
kip
ex_cldr Core Team
Localize — the road to 1.0
Localize consolidates the ex_cldr_* family into a single package — CLDR-based formatting for numbers, currencies, dates/times, units, lists, messages (MessageFormat 2) and locale-aware collation, with no compile-time backend modules.
It has been through an intensive quality cycle over the last weeks (releases 0.42 through 0.46: TR35 conformance fixes, the MessageFormat 2 working-group test suite, test coverage from 70% to 91%, and a compile-time reduction from ~66s to ~3.5s). The API has been stable since 0.43. It is time to talk about 1.0.
End of July 2026 — Localize 1.0
The API that exists today in 0.46 is the 1.0 API. The only removals are the delegates and option keys deprecated since 0.43, per the notices they have carried (“removed by Localize 1.0”):
- The inventory functions renamed to the uniform scheme —
known_*(the CLDR universe),supported_*(your configuration),*_for(localized into a display locale). The deprecated names areLanguage.available_languages/1,Language.known_languages/1,Script.available_scripts/1,Script.known_scripts/1,Subdivision.available_subdivisions/1,Subdivision.known_subdivisions/1andTerritory.available_styles/0.
- The
:styleoption ofLocalize.Duration.to_string/2andLocalize.quote/2(use:format), and the:formatoption ofLocalize.Unit.display_name/2(use:style).
If your app compiles today without deprecation warnings, Localize 1.0 is a drop-in upgrade.
Localize 1.0 does not drop support for OTP 26
I announced that OTP 26 support ends on December 31st 2026, and that date stands. Localize 1.0 runs on OTP 26 exactly as 0.46 does (with json_polyfill in your deps). The only change is that applications starting on OTP 26 will log a one-time warning pointing at the December date.
October 2026 — CLDR 49
This is the regular annual data update, probably shipped as a Localize 1.1 release when Unicode publishes CLDR 49. Data changes only from your perspective; any output changes that come from Unicode’s own data revisions will be listed in the changelog as usual.
Early January 2027 — Localize 1.2
OTP 26 support is removed, honouring the December 31st end-of-support date. This is the release where json_polyfill stops being needed and stops being supported.
What to do now to prepare for 1.0
- Upgrade to Localize 0.46 and fix any deprecation warnings — that is the entire 1.0 migration.
- If you are on OTP 26, plan your OTP upgrade for before the end of the year.
- If you are migrating from
ex_cldr_*, the migration guide covers the mapping.
Documentation
- Docs are at hexdocs.pm/localize,
- Full changelog at hexdocs.pm/localize/changelog.html,
- Issues at github.com/elixir-localize/localize.
Feedback on the plan is welcome — particularly if the OTP 26 timeline creates a problem for your deployment that I have not considered.
7