feat(i18n): full multilingual system for 27 languages

[piciolo]

Summary

This PR introduces a comprehensive multilingual system for OGameX, covering both the localization of existing in-game UI strings and the addition of full translation support for 27 languages.

All translations have been sourced directly from the official OGame game to ensure accuracy and consistency with the original game experience.

What changed

— 27-Language Translation Infrastructure

New languages: ar, br, cs, cz, da, de, dk, el, en_US, es, es_AR, es_MX, fi, fr, gr, hr, hu, it (extended), ja, jp, mx, nl (extended), pl, pt, pt_BR, ro, ru, se, si, sk, sl, sr, sv, tr, tw, us, yu, zh_TW

Each locale includes: t_buddies, t_external, t_facilities, t_galaxy, t_ingame, t_layout, t_merchant, t_messages, t_overview, t_resources, wreck_field

New infrastructure:

• app/Http/Middleware/Locale.php — per-request language detection, SUPPORTED_LOCALES constant
• app/Services/I18n/OGameLocale.php — locale resolution service
• app/Console/Commands/I18n/ — BuildDictionary, GenerateLocales, MapKeys Artisan commands
• public/img/flags/*.svg — 27 flag icons for the language switcher UI
• Language switcher dropdown in ingame and outgame layouts

Auth views migrated to i18n:

• outgame/layouts/main.blade.php — language switcher in login/register page
• outgame/forgot-password.blade.php, outgame/reset-password.blade.php
• outgame/mail/reset-password.blade.php, outgame/mail/retrieve-email.blade.php
• app/Providers/FortifyServiceProvider.php — registers localized auth views

— Localized Default Planet / Moon Names

CreateNewUser, PlanetServiceFactory, and a new PlanetNameLocalizationService ensure that the default names for a player's first planet ("Homeworld"), colonies ("Colony"), and moons ("Moon") are stored in the database already translated into the player's locale at creation time.

When a user changes their UI language (via /lang/{lang} or the in-game Preferences form), PlanetNameLocalizationService::retranslateDefaultNamesForUser() automatically renames any planet/moon whose current name still matches a default name in any supported language. Custom names chosen by the player are never touched.

Translation keys (t_ingame.overview.homeworld, .colony, .moon) have been added to all 39 language files, sourced from the official OGame game.

Notes for reviewers

• Branch history has been cleaned to 2 logical commits for clarity
• routes/web.php includes the language.switch route required by the language switcher
• Optional routes (e.g. password.email-lookup) are guarded with Route::has() for forward compatibility
• The Locale middleware is registered in bootstrap/app.php (already present on main)
• Existing accounts with custom planet names are unaffected. Only planets/moons whose stored name matches a known default (in any of the 27 languages) are ever retranslated. Accounts created before this PR will keep their English default names (Homeworld, Colony, Moon) unless the server admin runs the existing ogamex:admin:translate-planet-names Artisan command to perform a one-time batch migration.

[piciolo]

While working on the multi-language implementation, I noticed that several tests (specifically BuildQueueCancelTest, BuildQueueTest, ResearchQueueTest, and UnitQueueTest) are currently failing because they rely on hardcoded English strings.

In tests/AccountTestCase.php (around line 598), the assertion looks for the exact string:
str_contains($responseContent, 'do you really want to cancel ' . $object->title)

Since the application now supports different locales (like Italian), the $responseContent returns translated text, causing the test to fail.

@lanedirt

[Geda173]

Since the application now supports different locales (like Italian), the $responseContent returns translated text, causing the test to fail.

That means you have to update the test to accept the new, translated text.

[piciolo]

Since the application now supports different locales (like Italian), the $responseContent returns translated text, causing the test to fail.

That means you have to update the test to accept the new, translated text.

Thank you for the clarification. You're absolutely right: since the application now properly supports multiple locales, the test suite needed to be updated to handle translated response content instead of relying on hardcoded English strings.

I have refactored the affected tests to be fully localization-aware. Here is the technical breakdown of the updates:

1. tests/AccountTestCase.php (Localization Support & Isolation)

assertObjectInQueue: Now supports three matching conditions. It uses the __() helper to fetch translations dynamically. For complex strings like research cancellations (which include dynamic planet names and coordinates), I implemented a prefix-matching logic using rtrim to ensure stability across all languages.

assertObjectNotInQueue: Integrated a "sentinel placeholder" logic to extract localized prefixes, allowing the test to verify the absence of objects regardless of the active locale.

State Isolation: Added research_speed=1 to the setUp() method to ensure a clean state and prevent pollution between different test runs.

2. tests/Feature/ResearchQueueTest.php

Explicitly defined research_speed=2 in testResearchLabRequirement to eliminate fragile dependencies on the global state.

Results:
All related tests, including VacationModeTest, are now passing locally (25/25 for BuildQueue, 16/16 for ResearchQueue).

Authorization Request:
I have these test updates ready in my local branch. Should I include these fixes directly in this PR to restore the green light on the CI/CD pipeline?

[Geda173]

Authorization Request: I have these test updates ready in my local branch. Should I include these fixes directly in this PR to restore the green light on the CI/CD pipeline?

Yes, as you are introducing new elements, the tests are part of this PR and should be updated to reflect those changes. From the CONTRIBUTING.md:

Your PR should include feature or unit tests where possible to cover the changes you made.

[piciolo]

@lanedirt dont merge this i have other update in coming i have translate all

[piciolo]

and update Multi Language selection same on Ogame i have talk whit Gerda for use this PR

[Geda173]

If a PR isn't done yet or needs more time, you can always leave it as a draft or convert it to one.

[lanedirt]

Hi @piciolo, thanks for the work on this. I just briefly reviewed the changes but I see a lot of unrelated changes to the tests: many tests seem to have been removed and/or heavily refactored which is out of scope of this PR.

Please check all changes to the test files and make sure that any changes to the tests only reflect textual changes. Unrelated changes to tests such as general refactoring should be in its own PR.

[piciolo]

Hi @lanedirt, thank you for the feedback — you were right.

The branch history has been fully rewritten (force-pushed) to contain only i18n-related changes. The five test files that had unrelated modifications (FleetDispatchAcsAttackTest, FleetDispatchAttackTest, FleetDispatchMoonDestructionTest, MerchantTest, ResearchQueueTest) are now identical to main — verified with git diff origin/main.

The only test files that still differ from main are the four below, and every change in them is a direct consequence of views no longer emitting hardcoded English strings:

• AccountTestCase.php — assertCancelBuilding() now calls __() to match what the Blade views emit after i18n; assertEmptyBuildingQueue() / assertEmptyResearchQueue() switch from asserting hardcoded English text (which would fail in any non-English locale) to asserting the structural DOM marker class="idle" that is language-independent.
• AllianceDepotTest.php — updates 'There are no holding fleets!' to 'No allied fleets currently in orbit.', which is the English value of the new t_ingame.alliance_depot.no_fleets key.
• ChatTest.php — updates 'List of your chats' → 'Conversations' and 'Player list' → 'Players' to match the new t_ingame.chat keys.
• PhalanxTest.php — updates 'Own fleet' → 'Your fleet' to match what PhalanxService actually returns for the scanner's own fleets (the old assertion was incorrect regardless of this PR).

No logic, structure, or teardown of any test was changed.

[github-actions]

Preview deployment

Preview environment for this PR is ready for functional testing. Use one of the test accounts below to log in.

Status	URL	Commit	Last deployed
✅ Live	https://pr-1297.preview.ogamex.dev	bdd82a8	2026-04-17 15:23:05 UTC

Test accounts (click to expand)

Email (login)	Password	Role	Class	Planets	Description
test1@ogamex.dev	test	admin	Collector	2	Admin, high resources, mining focus
test2@ogamex.dev	test	player	General	1	Military focus, ships & fleet
test3@ogamex.dev	test	player	Discoverer	1	Exploration, probes & cargo ships
test4@ogamex.dev	test	player	None	1	New player, no class selected yet
test5@ogamex.dev	test	moderator	Collector	1	Moderator, balanced setup
test6@ogamex.dev	test	player	General	1	Vacation mode enabled
test7@ogamex.dev	test	player	General	3	Heavy defense across planets
test8@ogamex.dev	test	player	Discoverer	1	Fleet focus, inactive (i) 8 days
test9@ogamex.dev	test	player	Collector	1	Beginner, long inactive (I) 40 days
test10@ogamex.dev	test	player	General	5	Endgame, 90 unread messages

---

This preview will be automatically destroyed when the PR is closed.