DEV Community

Cover image for How We Built 14 Localised SaaS Landing Pages Without Localising the Entire Product
Jade Chen
Jade Chen

Posted on

How We Built 14 Localised SaaS Landing Pages Without Localising the Entire Product

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
Enter fullscreen mode Exit fullscreen mode

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:

Asia-Pacific markets

We also created:

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Each can evolve independently.


Campaign Language Does Not Need to Control the Product

Consider three campaign names:

Brand_Search_UK

Acquisition_Nouveaux_Clients

新規顧客獲得
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

may feel more natural on a French page.

A Japanese example might use:

¥5,000,000
Enter fullscreen mode Exit fullscreen mode

A Taiwan-focused Traditional Chinese example might use:

NT$1,000,000
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
pixel2tech profile image
Pixel2Tech •

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.