feat(DB/*_dbc): Update loc column names to reflect blizzlike assignments.

[heyitsbench]

Changes Proposed:

• Changes ordering and names of localized column names in *_dbc tables. Original order: enUS, enGB, koKR, frFR, deDE, enCN, zhCN, enTW, zhTW, esES, esMX, ruRU, ptPT, ptBR, itIT, Unk Proposed order: enUS/enGB, koKR, frFR, deDE, enCN/zhCN, zhTW, esES, esMX, ruRU, Unk, Unk, Unk, Unk, Unk, Unk, Unk Note that for the first and fifth column in the PR, only the first locale is in the column name. E.g. Name_Lang_enCN.

Issues Addressed:

• Closes unreported issue.

SOURCE:

DBCs from various localized clients.

Tests Performed:

• Tested that the server would not crash on loading the unfilled tables.

How to Test the Changes:

1. Run the query.
2. Run the worldserver and make sure it runs as you'd expect. Filling the tables shouldn't be necessary, since I don't know of any situation where the localized fields get sent to the client or are used for anything visible to the client.

Known Issues and TODO List:

• [ ] enTW locale is nowhere to be found. It's very likely it's a part of that sixth column, but not known for certain.

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.

[ZhengPeiRu21]

Are we sure this is correct? It is strange to have zhCN and zhTW as a single column because they are very different localizations with different race, class, and spell names, which would all be in the DBC. WoWDev lists them as separate columns: https://wowdev.wiki/Localization

[heyitsbench]

Are we sure this is correct? It is strange to have zhCN and zhTW as a single column because they are very different localizations with different race, class, and spell names, which would all be in the DBC.

These are the name columns taken from the enCN, zhCN, and zhTW ChrRaces DBCs. They all exist in the same column, (deDE according to WDBX) and they all have the same contents. Maybe that's not the case for something like the Spell.DBC, but from my quick glance (as there are well over 40000 lines in that file), they appear to all be the same there as well.

[ZhengPeiRu21]

Are we sure this is correct? It is strange to have zhCN and zhTW as a single column because they are very different localizations with different race, class, and spell names, which would all be in the DBC.

These are the name columns taken from the enCN, zhCN, and zhTW ChrRaces DBCs. They all exist in the same column, (deDE according to WDBX) and they all have the same contents. Maybe that's not the case for something like the Spell.DBC, but from my quick glance (as there are well over 40000 lines in that file), they appear to all be the same there as well.

This data is incorrect. It is the zhCN data; the zhTW data is different and should be use traditional and not simplified Chinese.

[acidmanifesto]

with 334 we have these recognize in a clean client

        //LOCALE_enUS = 0, Americanese
        //LOCALE_koKR = 1, Korean
        //LOCALE_frFR = 2, French
        //LOCALE_deDE = 3, German
        //LOCALE_zhCN = 4, Chinese
        //LOCALE_zhTW = 5, Chinese
        //LOCALE_esES = 6, Spanish
        //LOCALE_esMX = 7, Spainsh (mexico)
        //LOCALE_ruRU = 8, Russia

Additional locales out side of that for 334 were custom client and server edits. Additional Localizations did not come until MOP where they added

italian - loc9,
brasilian portuguese - loc10,
portuguese - loc11

However in current shadowlands\classic clients we have these in the client, although some are just placeholders (Classic Clients) and defaults to what ever region the language and the server setting:

        //LOCALE_enUS = 0, Americanese
        //LOCALE_koKR = 1, Korean
        //LOCALE_frFR = 2, French
        //LOCALE_deDE = 3, German
        //LOCALE_zhCN = 4, Chinese
        //LOCALE_zhTW = 5, Chinese
        //LOCALE_esES = 6, Spanish
        //LOCALE_esMX = 7, Spainsh (mexico)
        //LOCALE_ruRU = 8, Russia
        //LOCALE_none = 9, Defaults to English 
        //LOCALE_ptBR = 10, Brasilian Portuguese 
        //LOCALE_itIT = 11, Italian

[heyitsbench]

This data is incorrect. It is the zhCN data; the zhTW data is different and should be use traditional and not simplified Chinese.

Ah, my apologies. You are correct, the zhTW data I was using wasn't actually zhTW data. I will replace the sixth column (Unk) to zhTW.

I'll also change enCN to zhCN for consistency.

[heyitsbench]

@ZhengPeiRu21 Thank you for making me double check that. <3

[heyitsbench]

@acidmanifesto Done.

[heyitsbench]

This is going to be superseded by a much better and cooler and more handsome PR within the next few days.

[heyitsbench]

This is open again. Just in time for the squeesh. :)

[Kitzunu]

Too late for that my man

[heyitsbench]

Well I tried. Guess it gives me time to throw in the TC columns as well. 🤷‍♀️

[pangolp]

I'm going to try the script, but I think it might be what I'm talking about within the issue.