- 06 Dec, 2025 *
I originally posted this on LinkedIn (ugh) and it was mildly successful for someone who isn’t trying to game the algorithm or play that network’s game, so I figured I should also post it on my blog. This is slightly edited, but the core is the same.
This week, I was proofreading some menu translations for a game, and that made me think about ability descriptions in larger projects. In a couple of titles we worked together, a colleague and I developed a "semantic formula" to make the translation a bit easier when multiple translators are involved. There are two reasons for this:
- It makes it easier to translate in case the source is inconsistent with its own format, especially if the team is somewhat big and many people end up working on those lines. St…
- 06 Dec, 2025 *
I originally posted this on LinkedIn (ugh) and it was mildly successful for someone who isn’t trying to game the algorithm or play that network’s game, so I figured I should also post it on my blog. This is slightly edited, but the core is the same.
This week, I was proofreading some menu translations for a game, and that made me think about ability descriptions in larger projects. In a couple of titles we worked together, a colleague and I developed a "semantic formula" to make the translation a bit easier when multiple translators are involved. There are two reasons for this:
- It makes it easier to translate in case the source is inconsistent with its own format, especially if the team is somewhat big and many people end up working on those lines. Style should be consistent even in menus.
- As the keywords weren’t highlighted in any way, keeping a consistent format can help the player quickly scan the line and focus on the words that matter the most, as they will always be in the same spot.
Obviously, this doesn’t work for every project, and it’s far from a "hard rule", but here’s the "formula" we used for these titles:
requirement → verb → adverb → modifier → effect → rest of the sentence
It’s mostly self-explanatory, I believe. "Requirement" is a prerequisite for the ability to activate, like "If the enemy does this, then...", and "modifier" is your usual "+15% DEF" and such.
Putting that in context, we end up with (in Brazilian Portuguese):
- [no requirement] → Fortalece → automaticamente → em 75% → a resistência contra Fogo → por 5 turnos. "Fortalece automaticamente em 75% a resistência contra Fogo."
- [no requirement] → Causa → [no adverb] → [no modifier] → dano de Contusão elevado aos inimigos → [no rest of the sentence]. "Causa dano de Contusão elevado aos inimigos."
- Se estiver sofrendo aflição, → fortalece → [no adverb] → em 75% → a resistência contra Veneno → por 3 turnos. "Se estiver sofrendo aflição, fortalece em 75% a resistência contra Veneno por 3 turnos."
This is, in a way, an oversimplified approach to parsing/syntax analysis in a gaming context. By splitting the basic elements, we can keep them fixed in a sequence that makes sense for Portuguese grammar, while allowing us to swap terminology as needed. If we didn’t do this, every translator would use their own style for each sentence — like someone putting the effect before the modifier, while others don’t, for example — making the player read whole descriptions repeatedly when jumping between abilities, instead of focusing on the part that’s most helpful to them at the moment.
And remember: these are not "hard rules", they are just a formal approach to stylistic choices to help with consistency.