Your game is already being translated without you knowing — and what to do about it

There is a high chance your game is already being read in another language right now, by people you do not know you have, in a translation you never reviewed.

That is not a hypothesis: it is how the platform works by default. This guide explains the mechanism, what it does without asking permission, and what is worth doing about it.

The problem

The documentation's premise is the business fact: Roblox players come from varied cultures and speak different languages. Using the localization tools well ensures everyone understands and enjoys the game as it was intended.

What almost nobody knows is that the translation is already happening. Every player has an Automatic Translation option in their account settings — and with it on, the game name, the description and the in-game text are translated for them even if you never enabled any translation at all.

Read that sentence slowly, because it flips the question. The question is not "should I translate my game?". Part of your audience is already reading a machine-translated, unreviewed version of the text you wrote. The question is who controls that translation.

And then comes the second sentence that changes everything: manual translation added to the game is always shown to players. Roblox only generates automatic translation where it is missing.

The two together describe the whole mechanism. There is no choosing between "translated" and "not translated" — there is choosing between the translation you made and the one the machine made by default. And what you fill in wins.

Step by step

1. Get to the settings. In the dashboard, hover over the game, click manage, and in the left-hand navigation go to Audience and then Localization. From the experiences tab, the alternative route is the three-dot menu and the Configure Localization option.

The localization page is the starting point for everything: besides enabling translation, it brings tools to translate, add collaborators and download translation analytics.

2. Set the source language. You have to set the source language and the supported languages before starting any localization.

The source language is the main language the game was written in. Two things matter here. Roblox supports only one source language at a time — you cannot have a bilingual game at the source. And the default is your Roblox account's language, which means that if you never touched this, the source is already set by accident.

That accident is common and worth checking: a Brazilian creator who wrote the game in English, with a Portuguese account, has the source marked as Portuguese — and the platform will treat the game's English as if it were a translation.

3. Set the supported languages. They are the languages you intend to provide translation for, and you can have several in the same game. They are added in the Supported Languages section, through the Add Language button.

4. Start with automatic translation. The automatic translation tool is available in any game, and the official recommendation is pragmatic: in many cases you can get a long way with it before moving to manual translation or working with translators.

That makes sense, given the mechanism. Automatic translation is already being applied to anyone who switched the option on in their account; enabling it explicitly makes nothing worse and widens the reach.

5. Fix by hand what matters. You, or a designated translator, can add and modify translations in the game's table. And since manual translation always wins, every corrected line is a line the machine stops guessing at.

The order that works is by impact: the text every player reads — the main button, the home screen, the tutorial, the shop item names — before the text that appears once.

It is worth a paragraph on what automatic translation gets wrong most often, because that decides what to review first. It gets short, context-free text wrong, which is exactly interface text. A button that just says "Run" can turn into a noun instead of a verb; "Exit" can become leaving the game when it meant leaving the room. And it gets wrong anything depending on a gender or a number only your code knows.

The practical rule: the shorter and more isolated the text, the higher the chance the machine gets it wrong — and the higher the return on reviewing it. A paragraph of story has enough context for the machine to do a reasonable job; a single word on a button has none.

6. Bring in a translator when it is worth it. The collaborators tool exists for that, and it gives access to the translation without giving access to the game. For a language with a large audience, a native speaker running their eyes over the home screen is worth more than any automatic adjustment.

The artifact

The artifact has two parts, and the first gives an immediate return.

Part 1 is a Studio script that switches AutoLocalize off on everything marked with a tag. It exists because doing that by clicking object by object does not survive the next person who creates a TextLabel — with a tag, the rule lives on the object.

Part 2 solves what the translation table cannot reach: an image with text drawn inside it. A poster, a logo, an illustrated tutorial. The documentation says the table is accessible from code precisely to allow swapping an image or an asset by language, and the code shows the pattern, including the fallback to the language family and the mandatory default.

Common mistakes

The most visible mistake is letting things be translated that should not be. The documentation names the problem: there is text that should never be translated, and the examples it gives are an NPC name and a street sign.

The result of not handling that is the kind of thing that breaks immersion in a way that is hard to trace. The NPC called "Rocky" becomes "Rochoso". The sign that said "Main Street" becomes "Rua Principal" — and the player who heard "go to Main Street" in a video cannot find the street. Proper nouns, brands, codes and invented words from your world are all candidates.

The fix is the AutoLocalize property, switched off on the objects, inside Studio. It is one property per object, and that is why the artifact does it by tag: the number of objects with text in an average game passes a hundred, and the list grows every week.

The second mistake is the wrong source language, mentioned above. It raises no error — it just makes the whole translation machine work from a false premise.

The third is thinking that having configured nothing means not being translated. It means the opposite: it means being translated without review, precisely in the parts you did not look at.

And the fourth is treating localization as an end-of-development project. Since automatic translation is already running, the translated version of your game has existed since day one — and the text you write today thinking "I will review it later" is already being read in another language tomorrow.

Next step

The highest-return exercise today costs ten minutes: open the audience dashboard and see where your players come from. The number decides whether localization is a priority or a curiosity, and it usually surprises upwards.

After that, make the list of what should never be translated. NPC names, place names, the game's branding, codes. Tag them and run the script. It is the only part of this subject with an immediate effect that does not depend on deciding anything.

A final note on expectations: localizing is not translating everything. It is translating what decides whether the person stays. The home screen, the item names, the button that starts the game and the instructions for the first few minutes cover most of the effect; the rest can live with automatic translation for a long time with no harm at all.

And it is worth writing with the translator in mind. A short sentence, with no slang and no wordplay, survives automatic translation well; text assembled by concatenation — joining pieces at run time to form a sentence — survives badly, because each piece reaches the translator without the rest. Writing the whole sentence, with the value going into a marked slot, costs the same and survives the translation.

With that done, the localization page has two tools worth knowing: collaborators, which lets you give a translator access to the translation without access to the game, and translation analytics, which shows what is being read in which language — and it is that one that tells you which lines deserve human review first.

-- PART 1 — Studio script (run it once in the command bar).
--
-- Switches AutoLocalize off on whatever should NEVER be translated. The
-- documentation gives the examples: an NPC name and a street sign. Add to
-- that anything that is branding, code, or a proper noun of your world.
--
-- Why by TAG and not by hand: a game has hundreds of TextLabels, and
-- whoever does this by clicking forgets the next one somebody creates.
-- With a tag, the rule lives on the object and survives the next person
-- who joins the project.

local CollectionService = game:GetService("CollectionService")

local TAG = "DoNotTranslate"
local howMany = 0

for _, object in CollectionService:GetTagged(TAG) do
	-- AutoLocalize exists on GuiObject and on BasePart with surface text;
	-- walking the descendants catches the whole set.
	for _, d in object:GetDescendants() do
		if d:IsA("TextLabel") or d:IsA("TextButton") or d:IsA("TextBox") then
			d.AutoLocalize = false
			howMany += 1
		end
	end
	if object:IsA("TextLabel") or object:IsA("TextButton") or object:IsA("TextBox") then
		object.AutoLocalize = false
		howMany += 1
	end
end

print(howMany .. " object(s) marked NOT to translate")

--[[
═══════════════════════════════════════════════════════════════════════
PART 2 — LocalScript: swapping an ASSET according to the player's language.

The translation table handles TEXT. An image with text drawn inside it
(a poster, a logo, an illustrated tutorial) is out of its reach -- and the
documentation says the table can be accessed from code precisely so you
can swap an image or an asset by language.
═══════════════════════════════════════════════════════════════════════

local Players = game:GetService("Players")
local player = Players.LocalPlayer

-- One asset per language, with a mandatory default.
local POSTER = {
    default  = "rbxassetid://0",
    ["pt-br"] = "rbxassetid://0",
    ["es-es"] = "rbxassetid://0",
}

-- LocaleId arrives as "pt-br", "en-us", "es-es". Normalising to lowercase
-- avoids the classic bug of comparing "pt-BR" with "pt-br".
local function assetForLanguage(map)
    local id = string.lower(player.LocaleId or "")
    if map[id] then
        return map[id]
    end
    -- falls back to the language family: "pt-pt" uses the "pt-br" one if present
    local family = string.match(id, "^(%a+)")
    for key, value in map do
        if type(key) == "string" and string.match(key, "^(%a+)") == family then
            return value
        end
    end
    return map.default
end

local image = script.Parent:WaitForChild("Poster")
image.Image = assetForLanguage(POSTER)
]]