fix: translate unit names in event panel messages

[slegarraga]

Fixes #3071

Problem

Unit names in event panel messages show raw English type strings (e.g., Port) instead of translated names (e.g., Dutch Haven).

Solution

In EventsDisplay.ts, before interpolating event message params, the unit param is now translated via translateText("unit_type.<key>") — converting the raw unit type string (e.g., Port) to its translation key (e.g., unit_type.port).

This affects all three event messages that include unit names:

• unit_captured_by_enemy
• captured_enemy_unit
• unit_destroyed

Changes

• src/client/graphics/layers/EventsDisplay.ts: Translate the unit param before passing to translateText()

Happy to iterate on feedback!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

Walkthrough

When handling events_display messages the code now clones event.params, and if unit is a string it maps it to a normalized unit_type key, translates that key, and uses the translated value for message interpolation instead of the raw unit string.

Changes

Cohort / File(s)	Summary
Unit Translation in Events Display src/client/graphics/layers/EventsDisplay.ts	Adjusted event message handling: copy event.params, normalize string unit to a unit_type key (lowercased, spaces → underscores), translate that key, and pass the translated unit into the message translation instead of the original string.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

⚔️ A Port now wears a local name,
Words switch tongues and claims the fame,
Small change, bright voice — messages sing,
Units speak in the language of the king,
Localized lines make the game take wing.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: translating unit names in event panel messages, which is the primary objective of the pull request.
Description check	✅ Passed	The description is well-structured, explaining the problem (untranslated unit names), the solution (translating unit params before interpolation), affected messages, and implementation details.
Linked Issues check	✅ Passed	The PR fully addresses #3071 by implementing generic translation of string params as unit_type keys with safe fallback, ensuring all unit names in event messages are properly localized.
Out of Scope Changes check	✅ Passed	All changes in EventsDisplay.ts are directly scoped to translating unit parameters in event messages; the Prettier formatting fix is a minor, related adjustment without introducing unrelated functionality.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/client/graphics/layers/EventsDisplay.ts`:
- Around line 387-391: In EventsDisplay.ts, avoid assigning the raw i18n key
string back into params.unit when translateText fails: capture the original unit
string before transforming (e.g., const raw = params.unit), call
translateText(unitKey), then if the returned value is the same as the key or
otherwise falsy, keep params.unit = raw (or a capitalized/raw fallback) instead
of the translation; update the block that computes unitKey/params.unit to
perform this guarded assignment so missing translations show the original unit
instead of "unit_type.xxx".

[VariableVince]

@slegarraga What if a developer (not knowing about the need for translation) just puts "building: unit.type()"? They'll test using English and it will work. We can't be sure they'll use "unit" as a key name. And also, how can we be sure they'll send a unit translation key string, and not just untranslatable unit.type()?

I think what we can do is:

• prevent them from using UnitType as a value for the params, so that unit.type() will lead to a TS error.
• but we cannot really confine the naming of the keys for the params. We could only allow a number of key names, but because there are many possible options for what will be in the params, you still don't know which of the allowed keys would hold a unit translation key as value once you recieve them in EventsDisplay. In other words, a developer may use "conquered" if that is an allowed key to send a player name, but he uses it to send a unit translation key because it is about a conquered unit. If you wouldn't have foreseen that, it can still bypass the key filter in EventsDisplay.
• So, imo, because of the above, better just and leave EventsDisplay agnostic to how the key is named. If a param value is a string, check if the key exists in en.json first or directly pass it to translateText to see if there's a translation for it. The number of params per in-game displayMessage won't be more than 3-4 probably so it shouldn't hurt performance too much.

[slegarraga]

Thanks for the feedback @VariableVince! Great point — I've updated the approach in my latest commits to do exactly that: iterate over all string params generically (regardless of key name), attempt to translate each as a unit_type.* key, and only replace the value if a real translation exists (i.e., translateText returns something different from the key). This way it's fully agnostic to param naming and gracefully falls back to the original value for non-unit strings.

Also fixed the Prettier formatting issue.

[evanpelle]

maybe this should go in translateText() instead? that way we'll automatically translate units if we render unit names somewhere else in the UI.