Zendesk Guide Localization

Zendesk Guide localization handles many languages properly. The hard part isn't the feature, it's deciding what you'll keep translated forever.

Start free trial All guides

How Zendesk Guide localization fits together

Guide localisation has three separate layers and confusing them causes most of the trouble.

Article translations. One article holds many translations. It's a single object with a version per language, not separate articles, which is what makes updates survivable.

Theme and interface text. Buttons, labels, headings baked into your theme. Guide translates its own standard strings, but anything you hardcoded in a template is yours to handle, usually through dynamic content.

Structure. Category and section names carry translations too, and a half-translated navigation is more disorienting than an English one.

You enable languages in Guide settings, choosing a default and the additional ones you support. Only enabled languages appear, and the URL carries the locale, so a French visitor sits on a path containing fr rather than en-us.

Language detection and switching

Guide picks a language from the visitor: browser settings, the locale in the URL, and for signed-in users the language on their profile. Signed-in customers get their profile language, which is usually correct and occasionally very wrong if it was set once during signup and never revisited.

Give people a visible switcher regardless. Copenhagen includes one when you have several languages enabled. Automatic detection is right most of the time, and the times it is wrong are exactly the times somebody needs help.

One behaviour to test: what a visitor sees when an article has no translation into their language. Depending on configuration they may land on the default language version or fail to find it in search at all. Neither is inherently wrong, but you should know which one your customers get.

Dynamic content isn't for articles

Dynamic content is Zendesk's variable system: one placeholder with a version per language, used in macros, triggers, automations, email notifications and theme text.

It is excellent for short strings that must exist in every language, and completely wrong for article bodies. Articles have their own translation model. Trying to assemble article content from dynamic content placeholders produces something nobody can edit and nobody can translate.

The good use is the surrounding furniture: the notification email that tells a customer their ticket was received, the macro your agents send fifty times a day, the custom heading in your theme. Those need to be right in every language and they change rarely.

What to translate, and what not to

This is the actual decision. Translating everything is a commitment your future self may not honour, and a stale translation is worse than an English article, because customers act on it and it's wrong.

A practical order.

The top twenty articles by view count, per market. That covers most traffic.

Anything legally or financially consequential in that market: refunds, cancellations, data handling.

The request form and its notifications, since submitting a ticket in a language you do not read is genuinely hostile.

Navigation, categories and sections, always. A translated article inside an English category looks broken.

Leave niche troubleshooting in your default language and say so plainly. Customers accept "this article is available in English only" far better than a bad machine translation from 2023.

Keeping translations from drifting

Every edit to a source article silently invalidates its translations. Nothing stops you publishing an English update while five other languages describe the old behaviour, and that is how localisation programmes actually fail.

So build the process, not just the feature. Decide which articles are in the translated set, keep that list short, and treat translation as part of publishing rather than as a separate project that happens quarterly.

The Guide API and the various translation integrations can automate export and import at scale, which is worth it above a few hundred articles. Below that, a spreadsheet and a named owner works fine and fails less often.

Add a date or a version note to translated articles so a customer can see how current the page is. It's a small honesty that costs nothing and buys you patience when a translation is a month behind.

Search is language-scoped by default, which is why translated navigation matters so much: if the article exists but the category around it does not, people browse into a dead end. The search guide covers the rest of that behaviour.

FAQ

Frequently asked questions

How many Zendesk help center languages can you run?

Dozens. A Zendesk multilingual help center publishes a translation per article per language, and Zendesk multi language support extends to the interface strings automatically, which is the half you don't have to write.

How many languages does Zendesk Guide localization support?

A long list, and the number you can enable can depend on your plan. Check the current Zendesk docs for both the supported locales and your account limits.

Are translations separate articles?

No. One article holds a translation per language, which is what lets you update the source and see which translations are behind.

Can I use dynamic content inside articles?

You should not. Dynamic content is for macros, triggers, notifications and theme strings. Articles have their own translation system.

How does Zendesk decide which language to show?

From the URL locale, the browser settings, and for signed-in users their profile language. Always offer a visible switcher as well.

What happens if an article is not translated?

Behaviour depends on your configuration: the visitor may see the default language version or may not find it in search. Test it deliberately rather than assuming.