Two completely different growth plays get called the same thing, and picking the wrong one costs a quarter. The first builds a page for every language pair and harvests search demand that exists whether or not your product does. The second translates the product and the writing you already have, and harvests the demand already arriving from people who found you in another language. globalize.now is AI-powered localization infrastructure, and it sits squarely on the second play, so this page is about telling them apart before you commit.

Four neighbouring questions already have their own pages, and this one repeats none of them. Whether translated pages help you in search at all, and what has to be true technically, is does localizing your app help SEO. What the tactic earned when a funded team ran it is the growth playbook then and now. Whether a tactic ends or becomes a standing job is the sorting test. How to decide what to spend is localization ROI without an enterprise budget. This page asks one thing only: whose demand does each play harvest, and how big is the one you are turning down.

What are the two plays?

They differ in where the demand already sits, which is the only distinction that matters when you have one pair of hands.

The matrix play. You generate a page for every pair in a set: this language to that language, this format to that format. The demand is already there, on queries that have nothing to do with you. Somebody needs a French to English conversion and types that. Your page exists, so they land on it. The product is almost incidental to the entry point.

The ownership play. You translate the thing you already built: the app, the docs, the blog, the emails. The demand is also already there, but it is yours. People are arriving at your product from places where English is their second language, and some fraction of them bounce off a screen they cannot read.

One is a publishing operation. The other is maintenance on something you own. The confusion between them is why so much advice in this category is useless to one person: it is written about the first and read by people who can only do the second.

How big is the matrix play, measured?

Big enough that the size is the argument against it, for one person.

One vendor inside our own category runs this play properly, and we measured it rather than estimating it. Crawling the Localazy sitemap on 28 August 2026 returned 757 pages for one conversion pattern, 1,705 pages for language pairs, and about 14,000 indexed URLs in total. A separate keyword pull on 23 September 2026 put the summed monthly United States search volume across the top 500 keywords that instrument detects for the domain at 4,859,220. Both figures sit in our proof tracker with their own observation dates, and both are quoted here as measurements of somebody else's operation.

Three limits travel with that volume figure, and dropping them would make it a lie:

  • It is summed keyword volume, not traffic. It is the size of a pile of queries. Nobody gets all of it, and a page ranking somewhere on a query gets a slice.
  • It is United States only. The instrument is per country with no worldwide roll up, so there is no global number here and we are not going to add markets together to invent one.
  • It is a detected footprint on a sampled page of keywords. What the tool has not detected is not proof of zero, and the sample is the top 500 by clicks rather than everything.

Even with all three caveats, the shape is unmistakable. The demand on language pair queries is enormous compared with anything a single product name attracts, and it is why this play keeps getting recommended. It is recorded here as something a well staffed vendor does, not as something we are suggesting you build.

Why can one founder not finish the matrix play?

Because the unit of work is pages, the quantity is thousands, and the bill arrives every month after that.

Fourteen thousand URLs is not a launch. It is a publishing operation: a generator, a quality bar, a way of noticing when a thousand pages go stale at once, and somebody who owns all of it. The payoff only starts when a large share of those pages is genuinely useful to the person who lands on it, which means the real cost is not generating them but defending them. Whether pages like that earn search traffic at all is the separate question answered in does localizing your app help SEO.

There is a second problem, and it is strategic rather than practical. In the matrix play the entry point has nothing to do with your product. Somebody converting a file is not shopping for your product, and turning that visit into a user is a whole second job. In the ownership play the person is already looking at your product. That is a shorter distance to walk.

So the honest version of this advice is: the matrix play is real, it is large, and it belongs to teams who can staff a publishing operation. If you are one person, you are choosing it against something you can actually finish, and you should know what you are turning down. Now the other side of the trade.

What does the ownership play actually earn?

Less than the matrix headline, unevenly, and from a standing start you already own.

The best documented case in this category is a vendor retelling, and we label it as one. As reported by the OneSky case study for Smallpdf, re-fetched on 22 October 2026, monthly users over search rose by 60%, going from 6 million in 2016 to over 9.5 million in 2017. The same case study says over 70% of users came from non-English speaking countries, and it reports Thai as the most lucrative of three languages added during that work, with an increase in user base of over 500% in traffic in one year. The product was offered in 17 languages at that point, and new features and site improvements were translated within "1-2 days" for all 17 languages through an outsourced vendor.

Read the caveats as carefully as the numbers. That is one vendor's account of one customer over one year, published by the supplier who did the work, about a funded company in 2017. The page also disagrees with itself: the banner says 20 languages and the body says 17. We use 17, because that is what the sentence carrying the operational detail says, and nobody here can resolve the difference without a source that does not exist. The case for picking it apart line by line is in the localization growth cases we verified.

Now the same play at the size you probably are. Ken Imoto published GA4 figures for his own blog, re-fetched on 22 October 2026, covering 2026-04-30 to 2026-05-21, which is 22 daily snapshots. Portuguese took 748 pageviews and 709 sessions. English took 195 pageviews and 176 sessions. Japanese took 27 pageviews and 29 sessions. Spanish took 7 pageviews and 7 sessions. His own summary of it is Portuguese pulling roughly 3.8 times English, 28 times Japanese and 107 times Spanish on the same blog. At the time, English had 26 articles, Japanese 25, Portuguese 17 and Spanish 10.

He also wrote the caveats himself, which is why the case is usable. In his words it is not a clean comparative experiment. It is a snapshot comparing languages against each other at one moment, not a before and after on the same content, and there is no pre-translation baseline published. The article counts differ per language and he gives no per-article normalisation, so do not derive one. And Spanish, with 10 translated articles live, is a loss by any reading. Four locales, one clear winner, one clear failure, measured on his own property.

How do you tell which play your demand is in?

Look at who is already arriving, not at what could theoretically be ranked for.

The matrix play harvests demand on queries your product does not answer yet. The ownership play harvests demand that already reached you and then hit a language wall. Those two leave different fingerprints in instruments you already have, and the second one is readable this afternoon:

  1. Sessions by country and by browser language in your own analytics. If a meaningful share is already not English, the ownership play has a starting population and the matrix play does not need to be invented to find one.
  2. Signups, trials and support messages written in another language. This is the strongest signal on the list, because it is demand that survived a screen the person could not read.
  3. The pages those sessions land on. Docs, pricing and onboarding beat your blog, because that is where the language wall actually loses you money.

What we will not hand you is an estimate of what a particular language is worth to your product. The instruments available to us measure a competitor's detected footprint in one country, which is a real and dated number about them and tells you nothing honest about your missing demand. Pretending otherwise is the single most common move in this category and we are not making it.

What does the second play cost to keep?

A quality check you can defend, repeated per locale, indefinitely. That is the part nobody prices.

A solo developer writing as Field Notes #3, re-fetched on 22 October 2026, cut his site from 21 locales to 6 on 24 September 2026. His reason is the useful part: the daily pipeline could prove native quality across six languages and it could not prove it across 21. He calls it an owner verdict rather than a traffic call. The kept set is English, French, Spanish, Russian, Chinese and Arabic.

He also published the traffic reading, and it points the wrong way for his own headline. In Search Console trailing 28 days, the kept locales drew 493 impressions and 6 clicks, while the deleted set, counting the twelve his report shows, drew roughly 850 impressions and 7 clicks. So the locales he removed out-impressioned the ones he kept in that window. He flags himself that the window straddles the cut, and the absolute numbers, 6 clicks and 7 clicks, are far too small to argue anything in either direction. His article also says five kept locales while naming six, and we are not going to resolve that for him.

What survives all that is not a traffic lesson. It is a cost lesson: the recurring bill on the ownership play is proof of quality, not translation, and it scales with the number of locales you are willing to defend. How to think about spending on it at all is localization ROI without an enterprise budget, and whether the work ever ends is the sorting test.

What we cannot tell you yet

We do not have our own numbers on this, and we are not going to imply otherwise.

Two customer case studies are being measured. Until they are finished and dated, every figure on this page belongs to somebody else and carries whose it is and when it was last checked. When ours land, they will appear with a window, an instrument and the caveats attached, exactly like everybody else's figures here.

Where does the product sit in all this?

On the ownership play, and nowhere near the other one.

globalize.now converts a codebase once, in the in-app connect flow, and after that push jobs translate new catalog units as they appear. Output is JSON or PO files that live in your repo. That removes the part of the ownership play people actually stall on, which is the first conversion and then the drip of new strings afterwards. It does not generate pages, and it will not run a matrix for you. If you want to see the mechanics before anything else, the developer pages and the vibe coder walkthrough are the shortest route, and the pricing page carries the current terms, which we are not going to paraphrase here.

So which one is yours?

If you are a team with a publishing function, the matrix play is the larger prize and the measurement above is the reason. If you are one or two people, it is not a near miss, it is a different business, and the honest move is to run the play whose demand already has your name on it. Translate the product, the docs and the onboarding for the two or three languages your own analytics already shows arriving, keep the quality bar where you can defend it, and let the matrix stay somebody else's operation. Connect a repo in the app at globalize.now and the first conversion happens there, once.

globalize.now turns hardcoded app copy into translation-ready locale files and keeps them updated as you ship.

Try globalize.now free