Languages and internationalization in SGEN

Run a multi-language site on SGEN with separate pages, a hand-built language switcher, and per-page meta — set up by you, not by a machine.

Internationalization in SGEN is a manual, content-first practice, not a switch you flip. SGEN is a content management system, not a translation engine. It does not translate your words for you, and it does not ship a language pack you turn on. What it gives you is everything you need to build and organize a multi-language site by hand: one published page per language, a language switcher you wire up in the Menu Builder, page hierarchy to keep each locale tidy, and per-page meta so search engines index each language version correctly.

This guide is honest about the boundary. It shows the real features you stand on, the order to build them in, and the mistakes that cost you traffic — and it states plainly the things SGEN does not do, so you never wait for a feature that is not coming.

The work splits into two kinds of effort. The translation itself — turning English words into Spanish or French — happens outside SGEN, in your own hands or a translator's. The build — hosting, organizing, linking, and serving each language — happens inside SGEN with features you already use every day.

The honest reality — read this first. SGEN has no built-in translation, no multi-language mode, no auto-translate, and no downloadable language packs. There is no setting that turns one English page into Spanish. There is no per-string translation table, no locale-detection redirect, and no automatic "alternate language" wiring. Translating the words is your job (or your translator's). SGEN's job is to host, organize, and serve each language version you create. Everything below is a manual workaround built on features that genuinely exist today — Pages, page hierarchy, the Menu Builder, and per-page SEO.

What is this for?

This page is for anyone who needs the same site available in more than one language and wants to know exactly what SGEN supports. The short version: you build each language as its own set of pages, then connect them with a switcher your visitors click. There is no shortcut where SGEN writes the second language for you — the translated text comes from you, a translator, or a translation service outside SGEN, and you paste the finished copy into a new page.

Use this guide when you are planning a bilingual or multilingual site, when a stakeholder asks "does SGEN auto-translate?", or when you have translated copy in hand and need to know where to put it. It covers the per-language page model, how to organize locales with parent pages, how to build the language switcher in the Menu Builder, and how to set per-page meta so each language is found correctly in search.

Most of the people who reach for this are content owners and site admins, not engineers. You do not write code to run a multi-language SGEN site. You create pages, paste in translated copy, and add menu items — the same actions you already use for a single-language site.

What SGEN does not provide

Be clear-eyed about the boundary before you plan the work. The table below separates what is real and supported from what is not built — so your plan never depends on a capability that does not exist.

The pattern is consistent: SGEN does not generate or manage translations for you, but it gives you sturdy, normal building blocks to assemble a multi-language site by hand and keep it organized. Read the "Yes" rows as your toolkit and the "No" rows as your responsibility. Nothing in the "No" column is on a roadmap you should wait for — plan around the tools you have.

Planning your URL structure

Decide your URL pattern before you build, because changing it later means a redirect on every page. You have three sound options, from lightest to heaviest.

Language-prefix folders on one site. You keep one SGEN site and put each language under a prefix, such as /es/ for Spanish. You build this with parent pages: a section page at /es becomes the parent of /es/inicio, /es/servicios, and the rest. This is the most common choice for a bilingual brochure site, and it keeps everything in one admin.

A language subdomain. You run the second language as its own SGEN site on a subdomain, reached from a header link. This suits teams who want the second language fully separate without registering a new top-level domain. The two sites do not share pages, so each one stays small and easy to manage.

A separate domain per language. You give each language its own domain and its own SGEN site. This is the heaviest option and the right one when the languages serve different markets with different content. The switcher becomes a single cross-domain link in each site's header.

The table below sums up the trade-off so you can pick with eyes open.

There is no built-in rule that maps one pattern to another, and no automatic locale routing. Pick the pattern that matches how separate your languages truly are, and build it with the pages and menus you already know. When in doubt, start with language-prefix folders on one site — it is the least to set up and the easiest to grow.

Good use cases

Reach for the manual multi-language pattern in these situations.

• A bilingual brochure site. You have an About, Services, and Contact page, and you want each one available in English and Spanish. Build six pages total, group each language under a parent, and add a two-item switcher.
• A primary market plus one secondary language. Most of your traffic is in one language, but you want a small set of key pages — homepage, pricing, contact — mirrored in a second language for an important audience.
• A campaign that runs in two regions. A landing page goes out to two email lists in two languages. Build one landing page per language and point each email at its own version.
• A documentation or support section in more than one language. Group each language's articles under its own parent page so the URLs stay readable and the nav stays clean.
• Separate sites per language. When two languages have different content, different teams, or different domains, run two SGEN sites instead of one. Each site stays simple; the switcher becomes a plain link between domains.

In every case, the unit of work is a page you create and a menu item you add. There is no separate "translation project" object in SGEN, because translation is content you author, not a feature you configure. Start small — mirror your three or four most important pages first, prove the switcher works, then widen from there.

What NOT to use this for

Set expectations so nobody on your team waits for behavior that will not happen.

• Do not expect SGEN to translate anything. There is no auto-translate, no machine translation, and no language pack. If your plan assumes the second language appears on its own, the plan is wrong — the words must be written and pasted in by a person.
• Do not build one page and try to "switch" its language in place. A page holds one language's content. There is no language toggle inside a single page. Two languages means two pages.
• Do not rely on the browser to pick a language automatically. SGEN does not detect a visitor's language and redirect them. Visitors choose their language from the switcher you build, so make that switcher visible.
• Do not rename a published page's slug to add a language prefix without a redirect. Changing a live page's URL breaks every inbound link to it. If you restructure existing pages into language folders, add a redirect for each old URL so visitors and search engines land on the new one.
• Do not duplicate a page and forget the per-page meta. A copied page inherits the original's SEO Title, Description, and Canonical. Left unchanged, two language versions can compete in search or point at the wrong canonical. Update the meta on every language version.
• Do not assume a new translated page joins the switcher on its own. Menu items are added by hand. When you publish a new language version that deserves a top-level link, add its item to the Language Switcher menu yourself, or visitors will not find it.

How this connects to other features

A multi-language site is assembled from four features you already have.

• Pages — every language version is a normal published page. Create, edit, nest, and publish them exactly as you would any page. See Create and manage pages for the full page lifecycle, including the Parent-page field that builds your locale hierarchy.
• Menu Builder (Appearance → Menu) — your language switcher is a small menu of links, one per language, assigned to a menu location. See Build a navigation menu to create the switcher and place it.
• Mobile menu (Appearance → Mobile Menu) — the switcher should also appear on phones. Mirror the switcher items into the mobile menu so small-screen visitors can change language too. See Configure the mobile menu.
• Homepage — if your default language has its own homepage, you decide which page answers your bare domain. See Set a page as homepage. The second language usually lives at a prefixed home such as /es/inicio, reached through the switcher.
• Per-page SEO — each language version carries its own SEO Title, Description, and Canonical URL on its Edit screen, so search engines treat each language as its own indexable page.

None of these features know they are being used for languages. You are reusing ordinary pages, menus, and SEO fields in a deliberate pattern, which is exactly why the approach is durable: there is no special mode to break.

Keeping your languages in sync

This is the honest maintenance cost of a manual setup, and it is worth planning for. SGEN does not link a page to its translation. When you edit the English page, the Spanish page does not change, and SGEN will not tell you it has drifted. Keeping versions aligned is a habit your team owns, not a process the platform runs.

A short routine keeps you out of trouble.

• When you change content in one language, open the matching page in every other language and apply the same change.
• When you add a new page in your main language, decide at that moment whether it needs a translated twin, and create it while the context is fresh.
• When you retire a page in one language, retire its twins too, and add a redirect for each so no language is left pointing at a dead URL.

A simple tracking table, kept in your own notes, tells you at a glance what is translated and what is pending.

The table is yours to maintain; SGEN does not generate or track it. It exists so a missing translation is visible to you before it is visible to a visitor.

Factor this upkeep into your decision about how many languages to support. Two languages is roughly double the maintenance of one; three is triple. The platform does not reduce that cost for you, so choose a number your team can keep current. A language that drifts out of date serves your visitors worse than no translation at all.

Before you start

Have these in hand before you build, so the work moves in one pass.

• You are signed in to SGEN as an admin with access to Pages and Appearance.
• You have the translated copy ready for each page you plan to localize. SGEN will not produce it — bring the finished text.
• You have decided your URL pattern for the second language. The common, readable choice is a language prefix, such as /es/ for Spanish or /fr/ for French, built with parent pages.
• You have decided scope: which pages get a second language. Mirroring three or four key pages is a sensible start; you do not have to translate the entire site at once.
• You have decided whether one site with two languages is right, or whether two separate sites suit your content and teams better.

Where to find it

Everything in this guide lives in two places in the admin.

• Pages — left navigation → Pages → All Pages. This is where you create each language version, set its Parent page, and fill its per-page SEO meta on the Edit screen.
• Menu Builder — left navigation → Appearance → Menu. This is where you build the language switcher and assign it to the header (primary) and footer locations. The companion Appearance → Mobile Menu holds the small-screen version.

There is no "Languages", "Translations", "Locales", or "Internationalization" screen anywhere in the admin, because no such feature exists. If you go looking for one, you will not find it — and that is expected, not a fault in your setup.

Steps

The build has a clear order: create each language version, group it under a parent, build the switcher, set per-page meta, then verify on the public site. Follow it once and the pattern repeats for every page you localize.

1. Create the translated page

Open Pages → All Pages and click Add New. Choose Start from scratch, give the page a Title in the target language, and let the Permalink fill in — then edit the slug to sit under your language prefix, for example /es/servicios. Paste your translated copy into the Content box. This is where the human translation lands; SGEN does not fill it for you. Set Status to Publish when the copy is final, or keep it as a Draft while a translator reviews it. A Draft is reachable only through the admin preview, so you can check the layout before anyone else sees it.

2. Group the locale under a parent page

To keep each language tidy, create one section page per language — for example a page titled "Espanol" at /es — and set it as the Parent page for every page in that language. On each translated page's Edit screen, open the right sidebar and pick your language section in the Parent page dropdown. This nests the URLs cleanly (/es/inicio, /es/servicios, /es/contacto) and keeps your Pages list readable as the site grows. Parent pages are a normal SGEN feature; nothing here is language-specific behind the scenes — you are reusing hierarchy to organize locales. If you later add a third language, repeat the same move: one section page per language, set as the parent of that language's pages. The pattern scales without any special setup.

3. Build the language switcher in the Menu Builder

Open Appearance → Menu and create a menu titled Language Switcher (or add items to an existing header menu). Add one item per language: Label English pointing at your English home, and Label Espanol pointing at /es/inicio. Each menu item takes a Label and a URL or page reference, with an optional target. Drag the items into the order you want, then assign the menu to the primary location so it appears in the header, and save. A single menu can be assigned to more than one location, so you can reuse the same switcher in the footer without rebuilding it.

4. Set per-page meta on each language version

Open each translated page's Edit screen and expand the SEO card. Set a SEO Title and SEO Description in the target language so search results read correctly for that audience. Leave Canonical URL blank to let SGEN set each page's own canonical — do not point a Spanish page's canonical at the English page, or search engines will treat the Spanish version as a duplicate and may drop it. If you want to declare alternate-language relationships explicitly, you can paste alternate-language link tags by hand into the page's Advanced → Header Scripts box. SGEN does not generate these for you; they are optional and entirely manual.

5. Verify on the public site

Open your public site in a private or incognito window. Confirm the switcher shows both languages in the header, that clicking Espanol loads the Spanish home at /es/inicio, and that each translated page reads correctly in its language. Switch to a phone-width window and confirm the switcher is reachable from the mobile menu. Check that a localized page's browser-tab title and search preview show the target-language SEO Title you set. Run this check after every translation you publish, so a broken switcher link is caught before a visitor finds it.

A note on search and duplicate content

Multiple languages of the same page are not duplicate content when each is handled correctly, so set the meta with care.

• Give each language version its own SEO Title and SEO Description, written in that language. A Spanish page carrying an English title reads as a mistake in search results.
• Leave each page's Canonical URL blank so the page canonicalizes to itself. Pointing a translated page's canonical at the original tells search engines to ignore the translation.
• If you want to state the relationship between language versions explicitly, paste alternate-language link tags into each page's Advanced → Header Scripts box. This is a manual step you control; SGEN does not add these tags for you.
• Add every language version to your navigation or switcher so visitors and search crawlers can find each one. A page with no link into it is hard to discover.

Handled this way, each language earns its own place in search, and no version competes with another.

Dates, currency, and right-to-left text

Translation is more than words, and SGEN leaves the rest of it in your hands too.

• Dates and numbers. SGEN does not reformat dates, times, or numbers per locale. If a Spanish page should show a date in day-month-year order, you write it that way in the content yourself.
• Currency. There is no automatic currency conversion or locale-aware money formatting in page content. Show prices in the form your audience expects by writing them into the page.
• Right-to-left languages. SGEN does not flip the page direction for languages that read right to left. If you need a right-to-left layout, set the text direction yourself in the page's Advanced scripts or your theme styling, and test it on the public site.
• Images with text. A graphic with English words baked in stays English on every language version. Swap in a localized image on the translated page where it matters.

None of this is automatic, and none of it is hidden — every locale detail is content you set on the page, which means you keep full control over how each language reads.

What success looks like

You know the multi-language setup is working when all of the following are true.

• Every language version is its own Published page and loads at its own URL, such as /services and /es/servicios.
• The language switcher appears in your site header, and on mobile, with one item per language.
• Clicking a switcher item takes the visitor to the matching page in the chosen language.
• Each localized page's browser tab and search preview show the SEO Title you wrote in that language.
• Your Pages list stays readable because each locale's pages are nested under a clear parent section.
• Your own tracking notes show every key page accounted for in each language, with nothing left half-translated.

What to do if it does not work

• The translated page is empty or still in the first language. The page content comes from you. SGEN does not translate it. Open the page's Edit screen, paste the finished translated copy into the Content box, and save.
• There is no "Languages" or "Translations" screen. There is not one, and there will not be — no such feature exists in SGEN. Build each language as separate pages and connect them with a Menu Builder switcher instead.
• The switcher does not appear on the public site. Confirm the menu is assigned to the primary location and saved, then reload the public page in a private window to clear any cache.
• The switcher is missing on phones. The mobile menu is a separate menu. Mirror the switcher items into Appearance → Mobile Menu so small-screen visitors can change language too.
• A second-language page is not showing up in search, or shows the wrong language. Check the page's per-page SEO card. Confirm its Canonical URL is blank (so it canonicalizes to itself) and that its SEO Title and Description are written in the page's own language.
• Old links to a page broke after you added a language prefix. Renaming a live page's slug breaks inbound links. Add a redirect from each old URL to the new one so visitors and search engines are forwarded to the right page.
• One language fell behind after an edit. This is the manual-sync cost, not a malfunction. Open the matching page in each language and apply the same change by hand, then update your tracking notes.

Frequently asked questions

Does SGEN translate my site automatically? No. There is no auto-translation anywhere in SGEN. You write or commission each translation and paste it into a page.

Is there a language pack I can install? No. SGEN has no language packs. Each language is built from real pages you create.

Can SGEN detect a visitor's language and switch for them? No. There is no automatic language detection or redirect. Visitors choose their language from the switcher you build.

Can I keep both languages on one page and toggle between them? No. One page holds one language. Two languages means two pages, connected by a switcher.

Will two language versions hurt my search ranking as duplicates? No — provided each version has its own self-referencing canonical and its own language-appropriate meta. See the note on search and duplicate content above.

How many languages can I support this way? As many as you are willing to build and maintain by hand. The pattern is the same for two languages or five: one set of pages per language, one switcher item per language.

Does the blog support multiple languages? The blog follows the same rule as pages: there is no language mode. Publish a separate post per language and link them the same way you link pages.

Can I translate menus, buttons, and labels automatically? No. Menu labels and button text are content you type. Build a switcher item or menu in each language with the labels written in that language.

Where this fits in your build order

Build a multi-language site in the order below, and each step has everything it needs from the one before.

1. Build and publish your main-language pages first, so you have a finished site to mirror.
2. Decide your URL pattern and create one section page per additional language.
3. Translate and publish each page under its language section, one locale at a time.
4. Build the language switcher in the Menu Builder and assign it to the header and footer.
5. Mirror the switcher into the mobile menu so phone visitors can change language.
6. Set per-page meta on every translated page, then verify the whole flow on the public site.

Working in this order means you never build a switcher that points at pages you have not created yet, and you never publish a translated page that visitors cannot reach.

Quick checklist before you publish

Run through this list before you call a language live.

• Each translated page is its own Published page at its own URL.
• Every translated page is nested under its language's parent section.
• The language switcher has one item per language and is assigned to the header.
• The switcher is mirrored into the mobile menu.
• Each translated page has a SEO Title and Description written in its own language.
• Each translated page's Canonical URL is left blank so it canonicalizes to itself.
• You opened the public site and confirmed every switcher link lands on the right language.
• Your tracking notes show no key page left half-translated.

If every item holds, your multi-language site is ready for visitors.

Examples

Three concrete setups, from smallest to largest.

Example 1 — A two-page bilingual landing set. Your business runs a campaign in English and Spanish. You create /promo in English and /es/promo in Spanish, each as its own published page with the landing-page option on so the header and footer are stripped. You point the English email at /promo and the Spanish email at /es/promo. No switcher is needed here, because each email sends its audience straight to the right language. SGEN translated nothing — you brought both versions of the copy and pasted each into its page.

Example 2 — A bilingual brochure site with a header switcher. You mirror Home, Services, and Contact into Spanish: /es/inicio, /es/servicios, /es/contacto, each nested under an "Espanol" parent page. You build a Language Switcher menu with two items — English and Espanol — and assign it to the primary location and the footer. Visitors land on the English site by default and click Espanol to move to the Spanish home, then navigate within Spanish from there. You set a Spanish SEO Title and Description on each of the three Spanish pages. As you add more pages later, follow the same shape: create the Spanish twin, nest it under the Espanol parent, and add it to the switcher if it deserves a top-level link.

Example 3 — Two separate sites, one per language. Your English and French operations have different teams and largely different content. Instead of one site, you run two SGEN sites, each on its own domain. The "switcher" becomes a single header link on each site pointing at the other domain. Each site stays small and self-contained, and neither one carries the other language's pages. This is the cleanest choice when the two languages diverge in content rather than mirror each other.

Example 4 — Adding a third language to a bilingual site. Your site already runs English and Spanish, and you want to add French. You create a "Francais" section page at /fr, then build /fr/accueil, /fr/services, and /fr/contact nested under it. You translate and publish each one, then add a third item — Francais — to your existing Language Switcher menu. Nothing about the first two languages changes, because each language is independent. The same pattern that carried two languages carries three, with no new feature to learn.

Related reading

• Create and manage pages — the full page lifecycle, including the Parent-page field used to group each locale.
• Build a navigation menu — how to create the language switcher and assign it to a location.
• Configure the mobile menu — mirror the switcher so phone visitors can change language.
• Set a page as homepage — choose which page answers your bare domain when your default language has its own home.