Internationalising a SaaS product sounds simple at first.
Translate the homepage. Add a language selector. Done.
That was roughly where we started.
What we discovered while expanding PaceWise, a PPC budget pacing and management platform, was that translation is probably the easiest part of localisation.
The difficult questions are things like:
- Should PPC terminology be translated or left in English?
- Does “PPC” even mean the same thing to marketers in every country?
- Should CTR, CPA and ROAS stay in English?
- Do local landing pages need local currencies if the SaaS subscription is billed in USD?
- Should every language get a complete copy of the website?
- How do you avoid creating 14 near-duplicate SEO pages?
- What happens when German text needs twice as much UI space as English?
- How should Chinese, Japanese and Korean be handled?
- How do you structure URLs and hreflang without creating a maintenance nightmare?
We recently built 14 additional localised landing experiences alongside our English site, while PaceWise already generated client reports in 15 languages.
Here are some of the things we learned.
1. Translation and Localisation Are Not the Same Thing
The first lesson was obvious once we started doing the work:
A translated page is not necessarily a localised page.
Consider an English headline such as:
PPC Budget Management Software for Agencies
A literal translation may be grammatically correct, but it might not match how paid-media professionals in that country actually search or talk about their work.
In Germany, for example, SEA is widely used in professional search-marketing terminology.
In France, SEA also matters.
In Spanish-speaking markets, SEM frequently appears alongside PPC terminology.
So the goal shouldn't be:
Translate the English keyword.
It should be:
Find the language a PPC professional in that market would naturally use to describe the same problem.
That changed how we approached our local landing pages.
Instead of treating English as the immutable source and translating every sentence literally, we started treating each page as a local marketing page built around the same product.
You can see that approach in the German PaceWise landing page, the French version, and the Spanish version.
2. We Chose One Strong Landing Page per Language First
A tempting approach would have been to translate the entire website immediately.
That would mean dozens of pages multiplied across more than a dozen languages.
It would also mean maintaining hundreds of URLs before we knew whether people in those markets actually wanted the product.
So we chose a simpler model:
one strong localised commercial landing page per priority language/market first.
Each page explains:
- the PPC budget-management problem;
- how budget pacing works;
- Google Ads, Meta Ads, Microsoft Advertising and TikTok support;
- forecasting;
- overspend and underspend detection;
- client reporting;
- local use cases;
- security and control;
- FAQs;
- and a clear signup path.
The pages all describe the same underlying SaaS product, but they aren't simply find-and-replace translations.
For example, the German version uses terminology appropriate to German search marketers, while the Japanese PaceWise page is written around Japanese PPC terminology and reading patterns.
This approach also gives us a useful experiment.
Instead of assuming which markets deserve deeper localisation, we can measure:
impressions → organic visits → signup intent → trials → customers
and let actual demand tell us where to invest next.
3. URL Architecture Is a Product Decision Too
International SEO quickly becomes an architecture problem.
We wanted URLs that were:
- predictable;
- easy to crawl;
- easy to maintain;
- easy to map with hreflang;
- and understandable to users.
So rather than creating separate domains for every market, we kept everything under the main PaceWise domain and created language/market paths.
That keeps domain authority consolidated and makes the localisation system easier to manage.
The important part isn't the exact naming convention.
It is consistency.
Once you choose a structure, changing it later across 15 languages becomes expensive.
4. Hreflang Is Easy to Understand and Easy to Get Wrong
Adding translated pages is only half of international SEO.
Search engines also need to understand the relationship between them.
That means thinking about:
- hreflang;
- self-referencing canonicals;
- reciprocal language references;
-
x-default; - XML sitemaps;
- language selectors;
- and crawlable internal links.
One mistake we wanted to avoid was canonicalising every translated page back to English.
If the German page is a genuine German version intended to rank independently, it needs to be treated as its own indexable page.
Likewise, every language version should clearly reference its alternatives.
International SEO becomes much easier when localisation is designed into the URL and template architecture rather than added later as a patch.
5. PPC Acronyms Are More Complicated Than Expected
One of the most interesting questions was what to do with metrics such as:
CTR
CPC
CPA
CPM
CVR
ROAS
Our initial instinct was:
PPC professionals everywhere understand these English acronyms, so leave them alone.
That is mostly true — but not universally.
In many markets, PPC practitioners routinely use CTR, CPC, CPA and ROAS even when the rest of the interface or article is entirely in the local language.
But there are exceptions.
Some platforms use locally established abbreviations in certain languages. In others, the translated metric name is more prominent than the English shorthand.
That led us towards a more robust pattern:
local-language metric name + familiar industry acronym
For example, conceptually:
French: local term (CTR)
German: local term (CTR)
Japanese: local term (CTR)
Korean: local term (CTR)
rather than assuming that either English-only or translation-only is always correct.
The lesson is simple:
don't translate marketing terminology with a dictionary.
Check how professionals and the major advertising platforms actually use it in that market.
6. Brand Names Should Usually Stay Brand Names
This one was much easier.
Google Ads is still Google Ads.
Meta remains Meta.
Microsoft remains Microsoft.
TikTok remains TikTok.
For Chinese versions, for example, it is usually clearer to retain the recognised platform brand and localise the generic descriptor around it rather than inventing a completely translated brand name.
The goal of localisation isn't to translate every possible word.
The goal is to reduce cognitive friction.
Sometimes the most familiar local-language experience includes English terminology.
7. Currency and Language Are Separate Problems
Another question we had was whether localisation meant introducing local subscription pricing.
We decided it didn't.
PaceWise currently operates globally with subscription pricing in USD.
That does not prevent a German page from discussing a €30,000 advertising budget or a Japanese page from demonstrating pacing using yen.
There are really two currencies involved:
the customer's advertising currency
and
the SaaS billing currency.
Those do not need to be the same.
A global SaaS company can bill in USD while still displaying and managing the advertising budgets customers actually use in their own markets.
This reduced a lot of unnecessary complexity.
Multi-currency SaaS billing can always be tested later if conversion data shows that it is commercially worthwhile.
8. Local Examples Make a Page Feel Much More Native
Changing language alone wasn't enough.
A page feels much more relevant when the examples make sense locally.
Instead of every version showing:
Monthly budget: $30,000
a European example can use euros.
A Japanese example can use yen.
The same principle applies beyond currency.
Local terminology, agency wording, FAQs and examples all make a page feel like it was written for the market rather than translated into the market.
This also creates more meaningful differentiation between international pages from an SEO perspective.
9. German Reminded Us That UI Space Is Not Universal
English is relatively compact.
German often isn't.
A button that comfortably says:
Start Free
may require substantially more horizontal space once translated.
Navigation labels expand.
Feature descriptions wrap.
Cards that looked balanced in English suddenly have one item occupying three lines.
This is one reason localisation should influence frontend architecture.
Avoid fixed-width assumptions where possible.
Design for:
- flexible containers;
- wrapping;
- different text lengths;
- larger mobile heights;
- dynamic buttons;
- and variable navigation widths.
If localisation is planned from the beginning, this is manageable.
If every UI component was designed around exact English character counts, it becomes painful.
10. Japanese, Chinese and Korean Need More Than Font Replacement
CJK languages introduced another set of considerations.
Line breaking works differently.
Text density feels different.
Some English technical terminology remains familiar, while other terms should be fully localised.
Traditional Chinese and Simplified Chinese also should not simply be treated as interchangeable character sets.
And localisation goes beyond language selection.
A user should not feel that they are looking at an English layout with foreign characters inserted into it.
Typography, spacing, hierarchy and terminology all contribute to whether software feels genuinely international.
For us, the Japanese version, Simplified Chinese version and Traditional Chinese version gave us useful examples of how different these markets can be from Western-language localisation.
11. We Already Had an Advantage: Multilingual Reporting
Before building the new landing pages, PaceWise already supported multilingual PPC reporting with white-label client reports in 15 languages.
That feature originally existed because agencies often operate differently from the clients they serve.
An agency team may work internally in English while producing reports for clients in:
- French;
- Spanish;
- German;
- Portuguese;
- Italian;
- Dutch;
- Polish;
- Turkish;
- Swedish;
- Simplified Chinese;
- Traditional Chinese;
- Indonesian;
- Japanese;
- Korean;
- or English.
The report language is selected per client.
That architecture taught us an important localisation principle:
language is often a property of the user or client, not of the entire account.
One agency may have a French client, a Japanese client and an English-speaking client simultaneously.
For international SaaS, assuming one account equals one language can be unnecessarily restrictive.
12. Campaign Language and Application Language Are Different
PPC software has another useful characteristic.
Budget pacing does not need to understand the meaning of an advertisement in order to understand:
- budget;
- spend;
- conversions;
- CPA;
- ROAS;
- pacing;
- and projected spend.
Those values come from advertising-platform data.
So a campaign named in Japanese can be monitored by the same budget-pacing logic as a campaign named in German or English.
That separation is useful:
campaign language ≠ reporting language ≠ application language
Thinking about those three layers independently makes internationalisation much cleaner.
13. We Didn't Translate Every Page — Deliberately
One lesson from this project was that localisation doesn't need to be all-or-nothing.
There is a sensible progression:
Stage 1: Localised acquisition
Create strong market-specific landing pages and see where organic search and conversion demand appears.
Stage 2: Localised customer experience
Translate onboarding, transactional communication, key help content and high-traffic product screens.
Stage 3: Full product localisation
Invest in complete UI localisation for markets that demonstrate meaningful usage and revenue.
This is especially useful for an early-stage SaaS company.
Instead of spending months translating every obscure setting before acquiring a single customer in a market, localisation investment follows commercial evidence.
14. AI Translation Helps — but Domain Knowledge Still Matters
Modern AI made this project dramatically faster.
But it did not eliminate QA.
AI can produce grammatically excellent language while still choosing terminology that a PPC professional would find strange.
Domain terminology is where generic translation often breaks down.
For paid media, terms such as:
- pacing;
- underpacing;
- overpacing;
- paid search;
- media spend;
- ad account;
- billing cycle;
- budget rollover;
- conversion value;
- and portfolio pacing
need contextual decisions.
The best workflow we found was closer to:
AI translation → PPC terminology review → local-market review → consistency check
rather than simply:
English → translate → publish
15. Localisation Creates an SEO Measurement Layer
One benefit we didn't fully appreciate initially is that local landing pages can function as market research.
Search Console can tell us:
- which countries generate impressions;
- which local keywords Google associates with each page;
- where rankings begin appearing;
- which pages get clicks;
- which markets produce trials;
- and eventually which markets produce paying customers.
That gives us evidence for product localisation.
If Japanese traffic begins generating disproportionately strong trial conversion, then Japanese UI localisation becomes easier to justify.
If another language produces almost no meaningful demand, we haven't spent months translating the entire application unnecessarily.
SEO becomes part of the product-market expansion process.
What We Would Do Differently Next Time
If we were designing a multilingual SaaS architecture from day one, we would formalise several things earlier.
Build a terminology glossary
Define the approved translation for every recurring concept:
budget
spend
remaining budget
pacing
forecast
overspend
underpacing
billing cycle
The glossary becomes the source of truth for website copy, reports, UI and help content.
Separate strings from product logic
Instead of:
"Budget remaining"
use something conceptually like:
budget.remaining
Then each locale supplies its own display text.
That sounds obvious, but retrofitting internationalisation is much harder than designing for it.
Test longer strings early
Use pseudo-localisation or intentionally long labels during frontend development.
If the UI survives those, German probably won't destroy it later.
Automate international SEO QA
We would also test automatically for:
- missing hreflang references;
- broken language links;
- incorrect canonicals;
- missing titles;
- duplicated metadata;
- unsupported locale codes;
- and pages missing from the sitemap.
Once you have more than a dozen variants, manual checking stops scaling quickly.
The Bigger Lesson
Internationalising software isn't really a translation project.
It touches:
product architecture
frontend design
SEO
terminology
billing
reporting
analytics
content strategy
customer experience
The most useful mindset change for us was this:
Don't ask, “How do we translate our English product?”
Ask:
“How would someone in this market expect this product to work and communicate?”
Those are very different questions.
We are still early in the process.
The localised landing pages are an experiment, not the endpoint. The next step is watching which markets actually respond and using that data to determine where deeper product localisation makes commercial sense.
For PaceWise, that could eventually mean a user searches for PPC budget-management software in their own language, lands on a local experience, manages international campaigns through the same platform and sends every client a report in the language they prefer.
That's the kind of internationalisation worth building.
About the Project
PaceWise is an AI-powered PPC budget pacing and management platform for agencies and performance teams. It monitors advertising budgets across Google Ads, Meta Ads, Microsoft Advertising and TikTok, with forecasting, pacing alerts, controlled automation and white-label client reporting in 15 languages.
If you're working on international SaaS, ad-tech or localisation architecture, I'd be interested to hear which parts of localisation created the biggest surprises for your own product.
Top comments (0)