PUBG: localizing a battle royale that never stops updating
New seasons, events, weapons and maps arrive in PUBG all the time. The localization has to keep pace with every update, stay consistent with years of existing text, and still sound like the way players really talk.
- Game
- PUBG
- Genre
- Battle royale shooter
- Developer
- KRAFTON
- Platforms
- PC, consoles and mobile
- Focus
- Live updates, terminology, dynamic text
The battle royale that made the genre
In PUBG, up to 100 players drop onto a map, loot weapons and gear, and fight to be the last one standing while the play zone keeps shrinking. The last survivor is greeted with the game's famous line: Winner Winner Chicken Dinner.
Around that core runs a constant stream of new content: maps, weapons, vehicles, events, seasonal passes and cosmetics. For localization, that means two jobs at once: keeping a huge existing vocabulary consistent, and turning around new content on the release schedule.
A game that changes every season
PUBG is a live-service game: new content lands on a fixed release schedule, and every patch brings item names, event texts, store offers, notifications and patch notes. If the translation is late, the feature ships untranslated.
At the same time, every new line has to match the thousands of terms players already know, and speak the language of a very demanding community.
- Fixed release windows, no room for delays
- Years of existing terminology
- Dynamic text built at runtime
- Short text for small screens
In a live game, a late translation is a missing feature.Cube Localization games team
What made it hard
Update after update
Batches of new strings arrive with every patch, often close to the release date, and must be ready on time.
The players' language
Gamers have their own words for loot, drops and squads. Too formal and the game feels foreign; everything left in English and it feels lazy.
Consistency across seasons
Every new weapon, attachment, vehicle and mode must match names players already know from earlier seasons.
Text with moving parts
Kill feeds, rewards and timers are assembled from variables such as a player name, a weapon or a number, and every combination has to read correctly.
Tight screens
HUD messages, buttons and notifications have strict character limits, especially on small screens.
One line, six grammars
A line like '{count} enemies eliminated' is assembled by the game at runtime. The translator has to know what every variable can contain, and write a line that works for all of its values.
Arabic shows why this matters: a counted noun can take six different forms depending on the number, for zero, one, two, three to ten, eleven to ninety-nine and a hundred or more. So one English line needs a set of Arabic variants, or a wording that stays correct for every value.
How we solved it
A team, a termbase and a workflow built around the release calendar.
- 01
A living termbase
Weapons, vehicles, items and modes each have one approved form and a clear rule: translate, transliterate or keep in English.
- 02
Linguists who play
The team is made up of linguists who play battle royale games, so the tone matches the community.
- 03
A fast lane for patches
A standing team and a fast-track workflow turn update batches around inside the release window.
- 04
Variables documented
Every placeholder gets a note on what it can contain, and plural forms are handled wherever the game supports them.
- 05
Automated checks
Scripts verify tags, variables and character limits before anything is delivered.
- 06
Queries, not guesses
Unclear strings are raised with the developer instead of guessed, and the answers go straight into the glossary.
- 07
Review in context
Where builds or screenshots are available, text is reviewed on screen, not only in a spreadsheet.
Every term has a rule
Consistency in a game this size is not luck. Before translation, every category of term gets a rule that all linguists follow, and the termbase grows with every patch.
Some lines are never translated literally at all. A catchphrase like Winner Winner Chicken Dinner is a celebration, not a menu: what matters is the rhythm and the feeling of victory players recognize.
Key decisions
The choices behind a consistent, fast localization.
| Our decision | Why | |
|---|---|---|
| Weapon names | Keep the model names | Players search, trade and talk using them |
| Game terms | Translate, keep the English in the glossary | Clear for new players, traceable for the team |
| Slang | Follow the community | A formal word nobody uses breaks immersion |
| Variables | Variants or wordings that fit every value | The same line shows 1, 2 or 25 |
| Deadlines | A standing team and a fast lane | Patches do not wait |
The outcome
Built for the release calendar
A workflow that keeps localization moving at the speed of the game.
One voice across seasons
Terminology that stays consistent from one update to the next.
Language that sounds like players
Text that feels native to the community, not like a translated menu.
What we learned
The lessons we now apply to every project of this kind.
Terminology is part of the product
Players learn names once; changing them later costs trust.
Speed comes from preparation
A ready team and a living termbase are what make fast patches possible.
Every variable is a grammar question
Knowing what a placeholder can contain prevents a whole class of in-game errors.
Services behind this project
More case studies
All case studiesLocalization engineering
Custom tools for formats no translation software can open, automated quality checks, subtitle and audio engineering, and Arabic that works in software and games. The technical side of Cube, with a real example.
Read the case study
Grounded
Real insects with game names, a crafting system where one wrong word breaks a recipe, four heroes with their own voices, and humour for all ages. How we kept it accurate, consistent and fun.
Read the case study
Cyberpunk 2077
Invented slang, a hero who can be male or female, factions with their own voices, and dialogue that branches with every choice. How we kept Night City's voice and grammar right.
Read the case studySend the file. A project manager replies in thirty minutes.
A first reply within 30 minutes in office hours. On time, or refunded. A free review if you are not satisfied.