The methodology
We built an automated audit pipeline that scans public GitHub repositories for i18n readiness. Each repo is scanned for three things: hardcoded UI strings in JSX/TSX/Vue/Svelte files, missing locale infrastructure (no i18n library wired up, no locale files present), and coverage gaps (where i18n is partially set up but strings are still bypassing it).
The score (0–100) is calculated from the ratio of hardcoded strings to total detected UI strings, weighted by whether any i18n infrastructure exists at all. A score of 100 means every detectable string is already going through a translation layer. A score of 0 means the repo has no i18n setup and is entirely hardcoded.
We seeded the scanner with 100 widely-used open-source repos — popular UI component libraries, SaaS starters, AI tools, analytics platforms, and developer infrastructure. The scanner runs twice daily and publishes scores to the public leaderboard, which anyone can browse or filter by framework.
You can also scan your own repo and see where you land. The audit runs in under 60 seconds.
Key findings
The average score of 61 looks passable until you realize it's skewed upward by two repos that score near-perfect. Remove those outliers and the remaining four repos average 42/100 — below the threshold we'd consider "i18n aware."
More telling: 83% of scanned repos have no i18n infrastructure at all. No i18n library imported, no locale files present, no translation function wrapping strings. These are projects used by millions of developers. Their UI strings are simply hardcoded in English.
The full leaderboard (current results)
Here are the repos currently on the leaderboard, ranked by score. The full table — with all 100 repos as they're scanned — lives at /audit/leaderboard.
The leaderboard grows as the scanner processes more repos from the seed list. Check back at /audit/leaderboard for the full picture — we'll have scores for all 100 repos within the next few weeks.
Framework breakdown: which ecosystem is worst?
Based on what's scanned so far, Next.js repos score lower than plain React repos on average:
| Framework | Repos scanned | Avg score | Avg hardcoded strings | i18n set up? |
|---|---|---|---|---|
| React | 4 | 64 / 100 | 54 | 1 of 4 |
| Next.js | 2 | 55 / 100 | 67 | 0 of 2 |
Next.js repos average more hardcoded strings (67 vs. 54) and neither of the two Next.js repos scanned has any i18n library configured. This isn't surprising — Next.js's built-in i18n routing handles URL-level locale detection but does nothing to help with string-level translation. A Next.js app can have /en/dashboard and /fr/dashboard routes while every string in the UI is still hardcoded English.
More framework data will land as Svelte, Vue, Astro, Angular, and Node.js repos finish scanning.
Top 3: the best-scoring repos
1. aidenybai/million — Score: 100
Million is a React optimizer that makes React components significantly faster. It scores a perfect 100 because it has no UI strings to translate — it's a runtime library, not an application. Every string it surfaces to developers is either a variable or a technical identifier. This is an important baseline: tools that output no user-facing strings are trivially i18n-ready.
2. vercel/swr — Score: 94
SWR is Vercel's React data-fetching library, and it's the only repo in the current scan with an i18n setup actually configured. It scores 94 — not perfect because a small number of hardcoded strings still exist in its documentation examples and error messages. As a widely-used library from a team that cares about the developer experience, SWR's attention to this detail is worth crediting.
3. t3-oss/create-t3-app — Score: 80
create-t3-app is the popular full-stack TypeScript starter from the T3 stack community. It scores 80 — decent, but with 30 hardcoded strings across 7 affected files. Given that it's a starter template used to bootstrap new projects, those hardcoded strings get copied into every generated codebase. Every developer who runs npx create-t3-app@latest inherits a project that needs i18n work.
Top 3 biggest opportunities
We're framing these as opportunities, not shame. Every repo here is maintained by talented engineers shipping fast. i18n is genuinely hard to retrofit — these scores reflect where the ecosystem is, not the quality of the code.
1. shadcn-ui/ui — Score: 0
shadcn/ui is one of the most cloned UI component libraries in the React ecosystem. Our scanner found 194 hardcoded strings across 27 affected files, with zero i18n infrastructure in place. The impact here is significant: every developer who copies a shadcn component into their app gets hardcoded English strings that will need to be extracted and translated manually. At the scale shadcn/ui is used, this represents tens of thousands of downstream apps shipping English-only interfaces.
shadcn/ui's score of 0 doesn't mean it's broken — it means there's a clean opportunity. 194 strings is a single Lokali run. A scan, an automated PR with extracted strings, and the library becomes trivially internationalizable for every downstream project.
2. langfuse/langfuse — Score: 29
Langfuse is an open-source LLM observability platform seeing rapid growth alongside the AI tooling ecosystem. With 103 hardcoded strings across 9 files and no i18n setup, it scores 29. Given that Langfuse is used by AI teams globally — including in markets where English is not the primary language — the gap here represents real friction for non-English users of the platform.
3. remix-run/remix — Score: 60
Remix scores 60, which puts it in the "warn" band — not catastrophic, but 20 hardcoded strings across 6 files with no i18n library configured. As a full-stack web framework used to build production apps, Remix's hardcoded strings propagate into applications built on top of it. The framework itself doesn't force internationalization, which is a reasonable design choice — but the score shows where the gaps are.
The most common i18n antipattern: inlined strings in JSX
Across every repo scanned, the most universal antipattern is the same: UI text written directly in JSX/TSX as string literals. Not extracted to a constants file. Not wrapped in a translation function. Just raw English text inside the return statement.
This pattern is invisible when you're shipping to English-speaking users and catastrophically obvious the moment you try to localize. Every string has to be found, extracted, keyed, and replaced — by hand, file by file.
The fix is detection first. Run an audit, see exactly which files and which lines have hardcoded strings, then automate the extraction. That's what the Lokali audit is for — it surfaces the exact strings, with file paths and line numbers, so nothing is manual.
The "80% of the internet" problem
There are roughly 5.5 billion internet users. About 1.5 billion speak English natively or fluently. That means 4 billion people are using software built primarily for the other 1.5 billion.
Open-source tools sit at the foundation of that software. When a popular component library like shadcn/ui ships with 194 hardcoded English strings, every project built on it inherits that debt. When a starter template like create-t3-app defaults to unhardcoded strings, every developer who uses it starts their project already behind.
The OSS ecosystem shapes how the commercial web is built. If the ecosystem defaults to English-only, the commercial apps built on top of it default to English-only too. The i18n readiness scores we're publishing aren't just about the repos themselves — they're a proxy for how accessible the tooling ecosystem is for the 4 billion users who don't primarily read English.
Most OSS maintainers aren't ignoring this problem — they just haven't had a way to measure it. That's what this leaderboard is. A public, continuously updated measure of where the ecosystem stands.
What happens next
The leaderboard is live and growing. We're scanning the full list of 100 repos and publishing scores in real time at /audit/leaderboard. As more repos get processed, we'll have framework breakdowns across React, Next.js, Svelte, Vue, Astro, and Angular — and we'll update this article with the complete findings.
If your project is on the list and you want to fix your score, Lokali can do it automatically. Connect your repo, run an audit, and we'll open a pull request that extracts your hardcoded strings and wires up i18n — without you writing the boilerplate.
If your project isn't on the list, you can still scan it and see where you stand.
See where your repo ranks
Run an instant i18n audit on any public GitHub repo. No account required. Results in 60 seconds.