In this topic, we will walk you through the Content Localization features and how to enable them. The features are split into two parts: What is available by default in Discourse; and Discourse AI for automatic translations.
For quick access to the relevant sections, use the wiki headings 
Localizing Your Community’s Content
An updated version of Discourse (3.5.0.beta7-dev) gives you access to several localization features available for configuration at:
<your-site-url>/admin/site_settings/category/content_localization
Getting information on your users
Firstly, it is good to get some information on your community. The following data explorer query can give you an idea of how many users may have set their locale in /my/preferences/interface.
SELECT locale, count(*) as count
FROM users
WHERE (locale IS NOT null AND locale <> '')
GROUP BY locale
ORDER BY count DESC
Setting locales that your community supports
With the information above, we are now more informed about which locales your community should support.
In <your-site-url>/admin/site_settings/category/content_localization, you can select locales to support.
Content localization enabled- turns on the feature that replaces original written user content with localized content. Read on for auto and manual modes of localizing.Content localization supported locales- the list of languages your site supportsContent localization language switcher- covered just below
Enabling the subsequent setting Content localization language switcher also allows you to make your community more accessible to non-logged-in users by showing the list of languages you’ve chosen in the list of supported locales:
Viewing localized content
For viewers of localized content (all site visitors), they may cursor over the indicator next to the post’s date to view the original language of the post. This indicator only shows up if the post is not in their language.
If a user wishes to only see original content, they may use the toggle above the topic timeline to disable localizations for the whole site.
Automatic translations with Discourse AI 
Discourse AI are the vitamins essential for the localization feature, and takes away the need to do manual translations.
As an admin, you’d want to head to our new AI features section for Translation.
To cover some important settings and recommendations:
AI translation backfill hourly rate- this setting defaults to0. Automatic translation will not begin if this value is 0. Assuming the rate is 50, your site will translate 50 posts, 50 topics, and 50 categories per hour, to the locales you have set in Content localization supported locales. Keep this to a low number when starting out.AI translation backfill max age days- defaults to5. This means topics and posts older than 5 days will not be translated. You may increase this to a large number to translate all topics and posts.AI translation backfill limit to public content- defaults totrue. This prevents PMs and content in private categories from being sent to the LLM. When set tofalse, group PMs, and private categories will be included in translations. PMs between individuals will not be translated.AI translation max post length- defaults to10000. This is a safeguard and prevents posts above a certain length from being translated.AI translation max tokens multiplier- defaults to1.0. We generally include a cap in the number of tokens used per translation. It is noted that when using Thinking / Reasoning LLMs like Gemini Pro 3 to translate, you will need to increase this multipler to about3.0.AI translation post raw translator persona(and other personas) - In more formal communities, admins may choose to create their own persona. This allows you to set a prompt that is more fine-tuned to the language or vocabulary you prefer.
You can refer to AI bot - Personas on how to configure suitable personas and fine-tune prompts for each function.
Translation Progress
You may find more information about how automatic translations are progressing in the Translation Progress chart on /admin/plugins/discourse-ai/ai-translations
This chart will show up if
- all translator personas have a valid LLM
discourse ai enabled
ai translation enabledcontent localization supported localesis filledai translation backfill max age daysis more than 0ai translation backfill hourly rateis more than 0
Manual localization
As localization is a core feature in Discourse, we provide the ability for you to fill in and edit localizations manually in the event automatic translations with Discourse AI is not available.
By default, admins and moderators are set up to edit localizations.
Currently, we have post content, topic title, and category name and category description localizations. Tags are not supported yet, but will be in the near future. Subsequent sections below will show you how they work.
Category localization
Localized categories are visible in the following areas, with both category name and description localized:
Places where categories are localized 📸
- Homepage, sidebar, and category dropdown
- Categories page
- A specific category with subcategories
As an admin, you should be able to access category settings as usual, and find the new “Localizations” nav item on the left.
Topic and Post localization
From the screenshots above in Category localization, you may have noticed topic titles and excerpts being localized.
There are some pre-requisite settings
- Ensure your user is in
content localization allowed groups - Add
addTranslationin site setting forpost menu. This allows the
to show up in the post menu for users in content localization allowed groups Content localization allow author localizationis enabled by default, and allows post authors to localize their own content using the same post menu as above.
Once again, the list of localizable languages is in the Content localization supported locales setting mentioned above.
Editing a localized post
In the event the user might be viewing a localized post, and wants to edit the post, a dialog will appear to ask which version they would prefer to edit:
The appropriate composer will appear after deciding.
Deleting a post’s translation for a certain locale
If you’ve followed instructions above regarding the post menu setting correctly, you should be able to do the following if you’re in the Content localization allowed groups:
FAQ
I’ve set things up, but automatic translation is still not working for me
Confirm if you’ve these set up
Content localization supported localeshas at least one languageContent localization enabledis
Allow user localeisSet locale from cookieis
Ai translation enabledisAi translation max age daysis not 0Ai translation backfill hourly rateis more than 12- You must have a working LLM set for each translation persona
If all else fails, you can enable SiteSetting.ai_translation_verbose_logs.
Is every post getting translated?
If AI translation backfill limit to public content is , all posts in public categories except for Bot (user id < 0) posts will be translated.
Are the automatic translations saved, or is it being sent to the LLM each time someone views a topic?
The translations are saved, each post is only sent once per language and the translations are reused.
If my forum supports English and Japanese (via Content localization supported locales), and someone writes in Spanish, will their post be translated?
Yes. All topics and posts will be translated to English and Japanese, regardless of the written language.
If the original post is edited, is it re-translated?
Yes – with a maximum of 2 times per day. When a post is edited, it gets sent to re-translation 5 minutes later (or the SiteSetting.editing_grace_period) to account for ninja edits. Authorized users in Content localization allowed groups have the option to send a post to re-translate immediately.
Will translations be deleted if I change the Persona or LLM?
No, translations will typically persist across settings changes unless explicitly deleted using the post menu item or the translation composer.
Feel free to DM me for this case if the content is not suitable in public. Also, were you logged in? Technically speaking these things are tracked by cookies so it’s a bit puzzling for me.
I temporarily switched to that one.