Error in the order of the langs of the _dbc.sql files

[pangolp]

Current Behaviour

Currently, we have the possibility of working with the content of several of the dbcs, in SQL format. However, when extracting the data, and wanting to add it to the DBC, in the case of the Spanish client (either esES and esMX), according to the emulator, they should go in position 6 and 7 respectively. But checking the tables, in these positions, we have Name_Lang_zhCN and Name_Lang_enTW. It is a bug, more than anything virtual, and could confuse people who work with said DBCs. However, I have made a change, but I don't know if it is really correct, that is why I created the issue, so that we can debate and correct it.

This is the result I am getting today. Beyond making the change in the editor, you also have to make changes to the position of the attributes of the DBC tables, so that when you export said data, it matches the corresponding client.

Expected Blizzlike Behaviour

We should have the esES in position 6 and the esMX in position 7, so that the positions indicated by the emulator coincide. However, as in DBC, there are more languages ​​available than the ones we handle in the emulator, I don't know if it is the correct change.

This is the result I would expect to obtain when extracting the data with the clients mentioned above. And although the date is in the problem that I use to edit them, it is also present today in the emulator in the aforementioned tables, where the order is also incorrect and could cause confusion.

If we make this change, and corroborate the rest of the clients, we could work on the DBCs, to be able to export the data of all the clients, and upload them later, for all languages ​​(at least, the blizzlike ones available so far)

Source

enum LocaleConstant
{
    LOCALE_enUS = 0,
    LOCALE_koKR = 1,
    LOCALE_frFR = 2,
    LOCALE_deDE = 3,
    LOCALE_zhCN = 4,
    LOCALE_zhTW = 5,
    LOCALE_esES = 6,
    LOCALE_esMX = 7,
    LOCALE_ruRU = 8,

    TOTAL_LOCALES
};

Steps to reproduce the problem

1. If the extractors are used, with a client in esES or esMX, both values ​​will be positioned in column 6 and 7 respectively, but in these columns, we do not have those prefixes, we have: zhCN and enTW. Possibly, with other languages, the same thing happens, but since I don't have all the clients, it is difficult to verify this. I only have enUS, esES and esMX

Extra Notes

No response

AC rev. hash/commit

https://github.com/azerothcore/azerothcore-wotlk/commit/688d7e2fdf4d0e9e2a5297ed03127a4f49b631be

Operating system

Windows 10

Custom changes or Modules

None

[pangolp]

In the program, to edit the DBC, I found the error, and it would be easy to modify. But before doing so, I would also need to know if this problem occurs in other clients. It is possible that the same thing is happening with the Russian language. With the rest, I don't know.

[heyitsbench]

https://github.com/azerothcore/azerothcore-wotlk/pull/13058

[pangolp]

13058

I'll read it, thank you.

[pangolp]

We would definitely need something like that. We would have to see if we should add to the script the possibility of preserving the data, just in case someone has worked on it, or if we should make the decision to change the columns and start working on them. But, we could fill in the values, and when we finish, create a new version of the DBC, with all the blizzlike data of the clients. That way, we would have a single DBC, covering all languages.

[pangolp]

I could work with the DBCs of enUS, esES and esMX, because they are the 3 clients I have.