Feature (Core): Allow localized motd

[Exitare]

Changes Proposed:

This PR proposes changes to:

• Core (units, players, creatures, game systems).
• Scripts (bosses, spell scripts, creature scripts).
• Database (SAI, creatures, etc).

Issues Addressed:

• Closes Feature: Allow localized MOTD #17911

SOURCE:

The changes have been validated through:

• Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
• Sniffs (remember to share them with the open source community!)
• Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
• The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

Tests Performed:

This PR has been:

• Tested in-game by the author.
• Tested in-game by other community members/someone else other than the author/has been live on production servers.
• This pull request requires further testing and may have edge cases to be tested.

How to Test the Changes:

• This pull request can be tested by following the reproduction steps provided in the linked issue
• This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

1. Apply the sql that adjusts the motd table
2. Prefill table with new localized motds and check motd by either logging in / reloading the table / running the ingame command .server motd

Known Issues and TODO List:

• Default server command is currently only updating enUS locale
• Questions remain about how to handle missing locale data. Fallback to just enUS. What if there is no enUS locale available?
• Additionally, how should OnMotdChange be handled? Technically the updated motd can be propagated, but without any further knowledge that could be any locale. I´d argue that the OnMotdChange function should be adjusted to also provide the locale.

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.

[Nyeriah]

New table implementations need to be designed in order to comply with database normalization rules https://www.w3schools.in/dbms/database-normalization

[Nyeriah]

Quick copilot review:

The provided SQL script modifies the motd table by adding several language-specific columns and migrating the existing text column data to the enUS column. Let's analyze this for database normalization compliance:

1. Adding Columns: The script adds columns for various languages (enUS, koKR, frFR, deDE, zhCN, zhTW, esES, esMX, ruRU).

2. Data Migration: It moves data from the text column to the enUS column.

3. Dropping Column: The text column is then dropped.

To ensure compliance with database normalization rules, especially the Third Normal Form (3NF), the following considerations should be made:

• 1NF (First Normal Form): Each table should have atomic columns. Adding multiple language-specific columns may violate this as it introduces redundancy.
• 2NF (Second Normal Form): All non-key attributes must be fully functional dependent on the primary key. The current structure may lead to partial dependencies if the table's primary key is not composite.
• 3NF (Third Normal Form): Non-key attributes should not have transitive dependencies. Adding multiple language columns can lead to transitive dependencies.

Recommendations

• Normalization: Consider creating a separate table for localized messages to avoid redundancy and ensure proper normalization. For example:

  CREATE TABLE `motd` (
    `id` INT PRIMARY KEY,
    `default_text` LONGTEXT
  );
  
  CREATE TABLE `motd_localized` (
    `motd_id` INT,
    `locale` VARCHAR(5),
    `localized_text` LONGTEXT,
    PRIMARY KEY (`motd_id`, `locale`),
    FOREIGN KEY (`motd_id`) REFERENCES `motd`(`id`)
  );

This structure will ensure that the database is normalized and follows best practices for managing localized content.

[Exitare]

@Nyeriah , any suggestions regarding the commands affected by this PR or the OnMotdChange() script

[Nyeriah]

Yes, they will crash if used from console. Handler in the command context is not guaranteed to be a player or have a valid session, so this needs to be checked

[Exitare]

Thank you for this insight.
I meant to ask about to the command .server set motd [optional realm id] [message].
and the sScriptMgr->OnMotdChange(motdMessage);

My thoughts would be:

1. The command should be adjusted to also include the locale as an optional
2. The OnMotdChange() should also include the locale that got changed. As a results the function call would use 2 params instead of one.

[Nyeriah]

Sure, it can be added as an optional, and it should default to english