How We Built 14 Localised SaaS Landing Pages Without Localising the Entire Product
Internationalising a SaaS product does not have to mean translating the entire application.
That was one of the most useful lessons we learned while expanding PaceWise, a PPC budget pacing and management platform, beyond an English-only marketing site.
We wanted international users to be able to:
- discover the product in their own language
- understand what it does
- see locally relevant examples
- evaluate whether it fits their workflow
- generate client reports in their preferred language
But we did not want to immediately translate every dashboard, navigation item, settings screen and product workflow.
So instead of treating internationalisation as one enormous project, we separated it into layers.
Our first major step was launching 14 additional localised marketing pages.
This article explains how we structured them, what we deliberately did not localise, and why separating marketing language from application language made the project much more manageable.
The Architecture Started With One Important Decision
The first decision was:
Do we localise the website, or do we localise the entire product?
Those are very different projects.
A full application localisation could involve:
Navigation
Dashboard labels
Settings
Alerts
Error messages
Billing
Onboarding
Reports
Help documentation
Emails
Tooltips
Form validation
Multiply that by 14 languages and the maintenance burden becomes significant very quickly.
Instead, we started with the acquisition layer.
The PaceWise application UI currently remains English.
But our international users can now discover the platform through localised marketing pages, run campaigns regardless of campaign language, and generate client-facing reports in multiple languages.
That separation gave us a much more practical internationalisation roadmap.
The 14 Localised Entry Pages
We currently have dedicated marketing experiences for 14 additional languages and markets.
European markets
Our German-language experience is available through the German PPC budget pacing page.
Spanish-speaking agencies can discover the product through our PPC budget pacing tool Spanish page.
French marketers have a dedicated PPC budget pacing tool French experience.
We also created:
- PPC budget pacing in Italian
- PPC budget pacing in Dutch
- PPC budget pacing in Polish
- PPC budget pacing in Portuguese
- PPC budget pacing in Swedish
- PPC budget pacing in Turkish
Asia-Pacific markets
We also created:
- PPC budget pacing in Japanese
- PPC budget pacing in Korean
- PPC budget pacing in Simplified Chinese
- PPC budget pacing in Traditional Chinese for Taiwan
- PPC budget pacing in Indonesian
These are not 14 separate versions of the SaaS application.
They are localised entry points into the same product.
That distinction is important.
We Treated Language and Product Logic Separately
Budget pacing itself is not language-dependent.
At the core, the system still works with concepts such as:
budget
spend to date
remaining budget
billing period
projected spend
pacing status
Those concepts exist whether the user speaks English, French, Spanish, Japanese or Korean.
So the application logic does not need to know that:
Projected Spend
might eventually appear as a different string in another locale.
The underlying concept should remain stable.
A simplified model might look like:
{
"budget": 50000,
"spend": 31200,
"currency": "EUR",
"projected_spend": 48700,
"pacing_status": "on_track"
}
The business logic remains unchanged.
Localisation belongs mostly in the presentation layer.
Marketing Language Is Not Application Language
This was one of the most useful architectural distinctions.
A user can currently experience:
French marketing page
English application UI
French client report
French campaign names
EUR advertising account
Those things can coexist perfectly well.
The marketing page needs to help the user understand the product.
The application needs to manage structured advertising data.
The client report needs to communicate results to the client's audience.
They are separate layers.
For us, the model became:
Marketing language
Application language
Campaign language
Reporting language
Documentation language
Each can evolve independently.
Campaign Language Does Not Need to Control the Product
Consider three campaign names:
Brand_Search_UK
Acquisition_Nouveaux_Clients
新規顧客獲得
A PPC budget platform does not necessarily need to understand the semantic meaning of those strings.
It needs structured values such as:
campaign ID
platform
budget
spend
currency
conversions
billing period
That means campaigns can use different languages without requiring the entire PaceWise interface to use those languages.
This is one reason internationalisation becomes much easier when product logic is built around structured data rather than display text.
Language and Currency Must Be Independent
Another implementation lesson was not to couple language and currency.
A French-language user may manage accounts in:
EUR
GBP
USD
CAD
CHF
A Spanish-speaking agency may run campaigns across Spain, Mexico and the United States.
So a configuration such as:
{
"language": "fr",
"market": "FR",
"currency": "EUR"
}
may work for a marketing example.
But the real advertising account currency should still come from the account itself.
For our localised pages, we use locally familiar budget examples where useful.
For example:
€30,000
may feel more natural on a French page.
A Japanese example might use:
¥5,000,000
A Taiwan-focused Traditional Chinese example might use:
NT$1,000,000
But PaceWise subscription pricing can remain in USD.
Those are different concerns.
Search Intent Also Needs Localisation
One of the easiest mistakes is to translate an English SEO keyword literally.
That does not guarantee users in another market actually search that way.
For example, the English
Top comments (1)
Separating marketing language from application language is a very practical decision. Letting a French marketing page and a French client report exist while the dashboard stays in English avoids a huge translation project, while still giving local users a clear way in.