Unicode CLDR: the locale data repository behind most software localisation

What CLDR actually contains and who consumes it

The Unicode Common Locale Data Repository provides key building blocks for software to support the world's languages, and the README describes it as the largest and most extensive standard repository of locale data available. The data is used by a wide spectrum of companies for their software internationalisation and localisation, adapting software to the conventions of different languages for common software tasks.

That last part is the thing that is easy to underestimate. Locale data is not a list of language names. It is the accumulated set of conventions that differ between a locale and its neighbour, and each of them is a bug waiting to happen if you guess. How a number is written, with which separators and which grouping, how a date is ordered, which symbols are currency signs in which territory, how a name is abbreviated, which characters a language writes right to left, how a list is joined with and or or, and so on. Every one of those is a rule that a user in that locale will notice immediately if it is wrong.

The consumption model is important too. CLDR is not a library you call. It is a data set that other libraries read, which means your choice of runtime library determines which CLDR version you get and how faithfully it is applied. The data itself is published as files per release, along with the LDML specification that describes the format, and the release downloads page is where you find the data files for a given version.

The repository is the home of the project rather than the product, and the README says to see the site for current release information. It is also the place where the data is authored, with a seed/ directory that holds the source data, common/ for shared code, tools/ for the tooling, and specs/ for the specifications.

The main branch carries a version you should not ship

The Status section of the README is the most important thing on the page for anyone deciding when to adopt CLDR, and it is easy to skim past. The status update is dated 2026-09-01, and the note reads that this is a preliminary version of CLDR 49, intended for those wishing to do pre-release testing, and that it is not recommended for production use.

Look at the structure of the note and you see the release process laid out in the source itself. The lines for the in development version, the milestone 1 version, the pre-release candidate and the final release are all present in the file, commented out and with the active one uncommented. The current state is the preliminary one, and the commented lines show the two stages it will pass through, the pre-release candidate and then the final release. The final release line is still commented, so at this point in the cycle CLDR 49 is not final.

The tag list in the repository metadata backs that up. The newest tags are release-49-beta4 from 2026-10-12, release-49-beta3 from 2026-10-07, and a production dated tag, production/2026-09-29-1726z, from 2026-09-29. So there is a beta track and a production track, and they are tagged differently on purpose. A production tag carries a timestamp, which is the shape you want for a version you are going to pin, because it identifies a specific build rather than a release number that will get a final tag later.

The practical rule is simple and worth stating plainly. If you want the newest locale data, use the latest production release. If you want to help test, use the beta. Do not ship from main, and do not assume that the number 49 means final.

The repository holds data, tools and specifications together

The top level listing shows what the project actually is, and it is three things in one repository. The common/ directory holds shared code, tools/ holds the CLDR tooling, and seed/ holds the source data that the tooling transforms into the released files. The specs/ directory holds the specifications, and the README points to a Building and running CLDR Tools page for that side of the project. There are also docs/, exemplars/ and keyboards/ directories, plus a pom.xml, which tells you the Java tooling is a Maven project and explains why the primary language is listed as Java.

The build side is visible in the workflow badges. There is a cldr-mvn workflow badge, which is the Maven build of the tools, a Publish to gh-pages workflow, and a CodeQL analysis workflow. The presence of CodeQL in the mix is a small sign of the security posture the project has settled on for its own tooling.

The JavaScript side is present too, if smaller. There is a .node-version file, a vetur.config.js for the Vetur editor extension and a wrangler.jsonc, which is the configuration for Cloudflare Workers. So the documentation and the tooling around CLDR reach into the JavaScript ecosystem even though the tools themselves are Java.

The formatting setup is worth a mention because it is a change in how contributions work. The README says a source formatter is now used and points at the Spotless section in the tools README for details. Spotless is a Java code formatter, and requiring it means a contributor's diff is reformatted automatically rather than argued about in review, which is the right trade for a repository where the volume of contributions is large and the code is mostly generated or transformed.

Licensing is a terms of use plus per dependency terms

The copyright and licences section is short but has a detail that trips people up. Copyright is Unicode, Inc. from 2004 to 2026, and the Unicode and Unicode Logo are registered trademarks of Unicode, Inc. The contents of the repository are governed by the Unicode Terms of Use and are released under the LICENSE file, which is why GitHub cannot categorise the licence into a standard SPDX identifier. This is a custom terms document, not a familiar permissive licence, and if you are shipping a product that embeds CLDR data, reading that document rather than assuming a BSD or MIT equivalent is the sensible step.

Then there is the note that some CLDR tools depend on libraries managed via Maven, and that use of these libraries is governed by separate licence agreements. So the licence of the data and the licence of the tooling that produces it are two different questions. If you consume the released data files, the Terms of Use are what apply. If you build and run the Java tools yourself, you are also pulling in Maven dependencies under their own terms.

Contributing has its own condition. A CLA is required to contribute, and the README points at CONTRIBUTING.md for the details. For an organisation that has to clear legal review before anyone commits to an outside project, a CLA requirement is a real gate, and it is the kind of thing to raise with the legal team early rather than at the pull request stage.

Where CLDR is the wrong tool

Three cases argue against it. The first is a product with one language and one territory. CLDR is a large data set describing the differences between locales, and if you have one locale there is nothing to look up, so the size of the dependency is pure cost.

The second case is a team that wants the newest data immediately. That is a real tension in this project, because the main branch is the active development surface and the final release lags it. You get a choice between the stable version, which is behind the newest fixes, and the beta line, which is explicitly not recommended for production. For a locale data set, being behind means missing a locale fix or a data correction that a user will notice.

The third case is a project that needs more than CLDR provides. CLDR is locale data, and it is not a translation workflow, not a translation memory, not an internationalisation management system, and not a localisation platform. It tells you how to format a number in Swedish and how to name a month in Arabic. It does not tell you what your string should say, and it does not tell you which of your strings are ready to ship. Teams often reach for a localisation platform and then layer CLDR's data underneath it for the formatting half, which is the right division of labour, and the mistake is to expect CLDR to be the platform.

There is a fourth point about how the data is consumed. Your runtime library decides what you actually get, and a library that only implements part of the CLDR specification will quietly fall back to its own defaults for the parts it skipped. So the version of CLDR in your repository and the version your library implements are both worth checking, and neither is a strong guarantee that the data is being applied as CLDR intends.

Editorial conclusion

CLDR suits a team whose product speaks more than one language and needs the formatting conventions of each locale rather than its own guesses about them, and it is the right dependency for a Java, JavaScript or any other runtime that can consume the released JSON or XML data. It does not suit a project with one locale, and it does not suit a team that would track the main branch. Before you adopt it, pin a production release rather than the beta line, read the repository organization page so you know which data files you actually need, and note that the last push was on 2026-10-13 with the newest tag being release-49-beta4 from 2026-10-12.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. unicode-org/cldr on GitHub