I had localisation on the roadmap. Italian first, since that's where I am and where a visible share of my traffic came from, then a couple of others.
I measured before building. 90.6% of the demand was in English. Including a large share of the demand coming from countries where English isn't the first language.
The project got cancelled. Here's the measurement, because the mistake I nearly made is built into the default shape of every analytics dashboard.
Country is not language
Every analytics tool leads with geography. Sessions by country, top countries, a map. It's the easiest dimension to collect — one IP lookup — so it's the one that's front and centre.
And it quietly answers a different question than the one you're asking.
"30% of my users are in Italy" is a fact about where people are sitting. "Should I translate?" is a question about what language people search, read and evaluate in. For a developer tool those two diverge hard, because the working language of the field is English almost everywhere. A developer in Milan searching for a technical answer types it in English, gets English results, and reads English documentation without noticing they've done anything.
Translate on the country number and you build for a population that was never asking.
Measure the query, not the visitor
Three sources, in ascending order of how much they cost to get.
Search queries. Search Console gives you the query string. Language-detect it and aggregate by detected language, not by country:
# pip install langdetect
from collections import Counter
from langdetect import detect, LangDetectException
def by_language(rows): # rows: [(query, clicks), ...]
out = Counter()
for query, clicks in rows:
if len(query.split()) < 2: # single words detect terribly
continue
try:
out[detect(query)] += clicks
except LangDetectException:
out["unknown"] += clicks
return out
The len(query.split()) < 2 guard matters more than it looks. Language detection on a single token is close to a coin flip — "monitoring", "schema", "audit" are the same string in five languages, and technical vocabulary is loaned wholesale. Include one-word queries and you'll get a confident, wrong distribution. I did, at first: my Italian share came out far higher on the first pass, entirely from single-word technical terms the detector assigned to Italian by orthography.
Accept-Language on the request. The browser's stated preference, which is closer to "what language does this person read" than the IP is. Compare it against detected query language — where they disagree, believe the query. Somebody with it-IT who searched in English wants the English page.
Your own inbound text. Signup form free-text, support emails, GitHub issues. Small sample, highest signal, because it's unprompted: nobody writes to you in a language they don't want to be answered in. Mine was overwhelmingly English from non-English countries.
What the numbers said
90.6% English. The remaining 9.4% split across everything else, no single language above a few points — including Italian, which the country dashboard had made look like a real segment.
That's not a close call, and it's the reason I want to be careful about the conclusion. This is a finding about my market, not a law. A developer tool with English as its field's working language is close to the maximum of this effect. A consumer product, anything regulated, anything with local competitors, anything involving money or health — different question, probably different answer, and you should run the measurement rather than borrow mine.
What transfers is the method, and the trap: the number that's easiest to collect is the one that will make the decision for you if you let it.
The other reason I stopped
There's a second cost I hadn't priced, and it's specific to writing for AI search.
A translated page competes with the original for the same entity. Two URLs, two languages, both describing the same product, and unless the hreflang reciprocity is exactly right, engines and models get to decide which one represents you. I had already spent a week on entity ambiguity from a three-letter acronym. Volunteering a second axis of ambiguity to serve 9.4% of demand, split across a dozen languages, was a bad trade at any level of execution quality.
Localisation isn't a translation task. It's a commitment to keeping N pages, N sitemaps, N sets of reciprocal hreflang and N versions of every future edit correct forever. Multiply by how often you ship.
The one-line version
Before you localise, aggregate demand by detected language of the query, not by country of the visitor. Drop single-word queries from the detection. If your field's working language is English, expect the two numbers to disagree, and expect the country one to be the flattering one.
I'd have shipped Italian on the country number. It would have been correct, well-translated, and aimed at nobody.
