Fix: GulfOfStLawrence map name not being translated

[Aotumuri]

Description:

The map name was not translated because it contained a . character, which caused the translation key to break.

To prevent this issue, the map name handling now strips . characters when generating translation keys.
With this change, maps that include . in their names will no longer cause translation issues in the future.

Before fix:

After fix:

Please complete the following:

• I have added screenshots for all UI updates
• I process any text displayed to the user through translateText() and I've added it to the en.json file
• I have added relevant tests to the test directory
• I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced

Please put your Discord username so you can be contacted if a bug or regression is found:

aotumuri

[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]

Walkthrough

The map name translation key construction in PublicLobby.ts is updated to sanitize both whitespace and periods instead of whitespace only. The regex pattern changes from removing spaces to removing both spaces and periods when building translation keys for map names.

Changes

Cohort / File(s)	Summary
Map translation key sanitization src/client/PublicLobby.ts	Updated regex pattern in map name translation key lookup to remove both whitespace and periods (/[\s.]+/g) instead of only whitespace

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Single file with a straightforward regex pattern update
• No new logic or error handling changes
• Minimal scope and risk

Possibly related PRs

• fixed giantworldmap key #1188 — Also modifies map translation key resolution; this PR adjusts key sanitization while the related PR renames specific map keys/enums

Suggested labels

Bug Fix

Suggested reviewers

• evanpelle
• scottanderson

Poem

🗺️ A dot walks into translation,
"Why wasn't I removed?" it asks with frustration.
Now spaces and periods bid their farewell,
The map names render perfect—oh, what a swell! 🎯

Pre-merge checks

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: fixing a map name translation issue for GulfOfStLawrence by handling period characters in map names.
Description check	✅ Passed	The description is directly related to the changeset, explaining the problem (period character breaking translation keys), the solution (stripping periods), and providing before/after screenshots as evidence.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 099337d and 7068cf2.

📒 Files selected for processing (1)

• src/client/PublicLobby.ts (1 hunks)

🧰 Additional context used

🧠 Learnings (5)

📓 Common learnings

Learnt from: TheGiraffe3
Repo: openfrontio/OpenFrontIO PR: 884
File: resources/lang/en.json:456-461
Timestamp: 2025-08-16T10:52:08.292Z
Learning: In OpenFrontIO, translation files in resources/lang/*.json (except en.json) should not be updated in regular PRs. Only dedicated translation PRs titled "mls" and made by Aotumori should update non-English locale files. Regular PRs should only update en.json when adding or modifying translation keys.

Learnt from: andrewNiziolek
Repo: openfrontio/OpenFrontIO PR: 1007
File: resources/lang/de.json:115-115
Timestamp: 2025-06-02T14:27:37.609Z
Learning: For OpenFrontIO project: When localization keys are renamed in language JSON files, the maintainers separate technical changes from translation content updates. They wait for community translators to update the actual translation values rather than attempting to translate in the same PR. This allows technical changes to proceed while ensuring accurate translations from native speakers.

Learnt from: Aotumuri
Repo: openfrontio/OpenFrontIO PR: 1357
File: resources/lang/ja.json:0-0
Timestamp: 2025-07-12T06:35:10.457Z
Learning: In OpenFrontIO project, "giantworldmap" is the correct localization key name for the giant world map, used consistently across all language files and TypeScript code. Do not suggest renaming this key.

Learnt from: andrewNiziolek
Repo: openfrontio/OpenFrontIO PR: 1007
File: resources/lang/he.json:138-138
Timestamp: 2025-06-02T14:27:23.893Z
Learning: andrewNiziolek's project uses community translation for internationalization. When updating map names or other user-facing text, they update the keys programmatically but wait for community translators to provide accurate translations in each language rather than using machine translations.

Learnt from: TheGiraffe3
Repo: openfrontio/OpenFrontIO PR: 1864
File: resources/maps/arabianpeninsula/manifest.json:13-170
Timestamp: 2025-08-19T11:00:55.422Z
Learning: In OpenFrontIO, nation names in map manifests are displayed directly in the UI without translation. They do not need to be added to resources/lang/en.json or processed through translateText(). This is the established pattern across all existing maps including Europe, World, Asia, Africa, and others.

Learnt from: mokizzz
Repo: openfrontio/OpenFrontIO PR: 1940
File: resources/lang/en.json:763-766
Timestamp: 2025-08-27T08:12:19.610Z
Learning: In OpenFrontIO, some country entries in src/client/data/countries.json may have similar names but different codes (e.g., "Empire of Japan" vs "Empire of Japan1"). Each unique code requires its own translation key in resources/lang/en.json after normalization. Always verify against countries.json before suggesting removal of translation keys.

Learnt from: VariableVince
Repo: openfrontio/OpenFrontIO PR: 959
File: resources/maps/Japan.json:31-35
Timestamp: 2025-05-30T18:11:20.372Z
Learning: Nation names on maps in OpenFrontIO are not localized/translated. They are displayed directly without using the translateText() function or requiring entries in localization files like resources/lang/en.json.

Learnt from: Aotumuri
Repo: openfrontio/OpenFrontIO PR: 1534
File: src/client/LangSelector.ts:97-106
Timestamp: 2025-07-23T12:36:35.354Z
Learning: In OpenFrontIO's LangSelector.ts, the getClosestSupportedLang method always joins language code parts with underscores ("_") because all keys in the languageMap use underscore format (e.g., pt_BR, sv_SE, zh_CN). This normalization ensures consistency regardless of whether the input language code uses hyphens or underscores as delimiters.

📚 Learning: 2025-06-09T02:20:43.637Z

Learnt from: VariableVince
Repo: openfrontio/OpenFrontIO PR: 1110
File: src/client/Main.ts:293-295
Timestamp: 2025-06-09T02:20:43.637Z
Learning: In src/client/Main.ts, during game start in the handleJoinLobby callback, UI elements are hidden using direct DOM manipulation with classList.add("hidden") for consistency. This includes modals, buttons, and error divs. The codebase follows this pattern rather than using component APIs for hiding elements during game transitions.

Applied to files:

• src/client/PublicLobby.ts

📚 Learning: 2025-07-12T06:35:10.457Z

Learnt from: Aotumuri
Repo: openfrontio/OpenFrontIO PR: 1357
File: resources/lang/ja.json:0-0
Timestamp: 2025-07-12T06:35:10.457Z
Learning: In OpenFrontIO project, "giantworldmap" is the correct localization key name for the giant world map, used consistently across all language files and TypeScript code. Do not suggest renaming this key.

Applied to files:

• src/client/PublicLobby.ts

📚 Learning: 2025-10-21T20:06:04.823Z

Learnt from: Saphereye
Repo: openfrontio/OpenFrontIO PR: 2233
File: src/client/HostLobbyModal.ts:891-891
Timestamp: 2025-10-21T20:06:04.823Z
Learning: For the HumansVsNations game mode in `src/client/HostLobbyModal.ts` and related files, the implementation strategy is to generate all nations and adjust their strength for balancing, rather than limiting lobby size based on the number of available nations on the map.

Applied to files:

• src/client/PublicLobby.ts

📚 Learning: 2025-08-19T11:00:55.422Z

Learnt from: TheGiraffe3
Repo: openfrontio/OpenFrontIO PR: 1864
File: resources/maps/arabianpeninsula/manifest.json:13-170
Timestamp: 2025-08-19T11:00:55.422Z
Learning: In OpenFrontIO, nation names in map manifests are displayed directly in the UI without translation. They do not need to be added to resources/lang/en.json or processed through translateText(). This is the established pattern across all existing maps including Europe, World, Asia, Africa, and others.

Applied to files:

• src/client/PublicLobby.ts

🔇 Additional comments (1)

src/client/PublicLobby.ts (1)

193-195: Remove the collision risk concern—verified no conflicts with real map keys

The fix is correct. The regex change from /\s+/g to /[\s.]+/g adds dot removal to handle map names like "Gulf.Of.St.Lawrence". All map keys in resources/lang/en.json are already lowercase and normalized (e.g., "gulfofstlawrence", "grandcanyon"), so the sanitized lookup will always find a match. No collision risk exists with the actual data.

The optional refactor to extract the normalization into a helper method is fine but not critical since this is the only place where map keys are built.

---

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.}