[ Bug/Support ]: Missing esEs strings on spells and locations
Current Behaviour
As titled: azerothcore aowow isn't displaying spells or locations/zones in spanish when locale is set to "eses". It just shows empty strings... I checked the deployed aowow (https://wowgaming.altervista.org/aowow/) and when spanish is selected, it keeps showing spells and locatiosn in english.. so it seems something wrong with locales at some point.
Use AzerothCore?
Yes
Steps to reproduce the problem
- Install azerothcore aowow using 'eses' locale
- aowow web site shows in spanish but wow locations/zones and spells aren't displayed, just empty strings.
Extra Notes
No response
Operating system
ubuntu server
PHP version
8.3
Browser
Chrome
Does aowow get these strings from acore_world *_dbc tables? if so... the locales other than enus in these tables are empty.
Edit: copied values from enus to eses in areatable_dbc and spell_dbc and still missing strings on aowow after reinstalling... I noticed the missing strings are spells, zones and races... in https://wowgaming.altervista.org/aowow the same sections aren't in spanish and seems to fallback to default english.. so, it might be a bug with locales handling as all other languages fallback to english in these sections.
the azerothcore/aowow project supports the translations, the problem is related more to the implementation in wowgaming/aowow, we should run again the setup extracting the language text properly for eses
the azerothcore/aowow project supports the translations, the problem is related more to the implementation in wowgaming/aowow, we should run again the setup extracting the language text properly for eses
Ok, thanks for replying.. how do I extract the text properly? I followed the instructions in the readme and ended up without spells,zones and races strings on aowow.
read the readme carefully and add esES files in the right path, if you are running Linux or MacOS you need to be sure about the name of the path in terms of case-sensitivity
read the readme carefully and add esES files in the right path, if you are running Linux or MacOS you need to be sure about the name of the path in terms of case-sensitivity
I did.. It seems extractor gets esMX or esES strings as enTW? (Wtf?!). Using that node dbc extractor tool realized it.. it explains why aowow has none esES strings at spells, zones, races, etc. at all.
maybe it's a bug of AoWoW, @Sarjuuk did you notice any similar issue?
never seen that before.
you are talking about this extractor? https://github.com/Sarjuuk/MPQExtractor (or Kanma/MPQExtractor)
never seen that before.
you are talking about this extractor? https://github.com/Sarjuuk/MPQExtractor (or Kanma/MPQExtractor)
Ok, let me explain... My 3.3.5 client is in esMX locale (tried with esES with same results). I extracted the dbc files from my client with Sarjuuk/MPQExtractor and setup aowow following the readme instructions. Aowow works in spanish but there are strings missings wich are: spells, races, zones and classes (probably other things I didn't notice yet). It recognizes the amount of spells, races and so on but the strings on the front aren't displaying... I found out https://github.com/wowgaming/node-dbc-reader to try to get the esMX strings from the dbc's extracted with your extractor to manually populate the aowow spell table but the dbc reader outsputs this:
{
"ID": 80864,
"Category": 1159,
other properties....
"SpellIconID": 1,
"ActiveIconID": 0,
"SpellPriority": 50,
"Name_Lang_enUS": "",
"Name_Lang_enGB": "",
"Name_Lang_koKR": "",
"Name_Lang_frFR": "",
"Name_Lang_deDE": "",
"Name_Lang_enCN": "",
"Name_Lang_zhCN": "",
"Name_Lang_enTW": "15 s tiempo de reutilización especial de criatura 2",
"Name_Lang_zhTW": "",
"Name_Lang_esES": "",
"Name_Lang_esMX": "",
"Name_Lang_ruRU": "",
"Name_Lang_ptPT": "",
"Name_Lang_ptBR": "",
"Name_Lang_itIT": "",
"Name_Lang_Unk": "",
more properties.....
}
Notice the spanish string on the enTW property?
I don't know if it's a bug on the dbc reader reading the dbc that your extractor created or it's your extractor that had set the spanish string on the enTW property... in any case I think this is why spanish locale strings aren't showing on my aowow.
i get that the spanish locale is on the wrong index (for some reason), but you are really unclear on the tools you used.
Did i get that right, that the mix up still occurs, even if you use the node-dbc-reader?
I used https://github.com/Sarjuuk/MPQExtractor to extract the esMX client dbc's, as readme instructs.
EDIT: I don't know any other tool to view the extracted dbc's to check if what node-dbc-reader reports is correct... I'm just trying to figure out why spanish strings aren't displayed on aowow in some sections, that's it.
try https://github.com/WowDevTools/WDBXEditor
but if both aowow and node-dbc-reader read the dbc like that it's likely an issue with your client files.
If you don't trust my changes the the MPQExtractor you can use Kanmas and extract the DBCs again, but i highly doubt that will change anything. I just forked it so it doesn't get lost with time.
try https://github.com/WowDevTools/WDBXEditor
but if both aowow and node-dbc-reader read the dbc like that it's likely an issue with your client files.
If you don't trust my changes the the MPQExtractor you can use Kanmas and extract the DBCs again, but i highly doubt that will change anything. I just forked it so it doesn't get lost with time.
It's not that I don't trust your changes, sorry if something I wrote made you think it. I'm just reporting something as a potential bug that may have went under radar... I'll try that editor and if it helps me to figure out the problem I'll be sharing it with you. Cheers.
EDIT: WDBXEditor verified that the extracted dbc's from esMX client went to enTW column: https://imgur.com/a/rs57xvU
this is the script I used to extract the client's dbc's:
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/common.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/common-2.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/expansion.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/lichking.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/patch.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/patch-2.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/patch-3.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/backup-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/base-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/expansion-locale-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/expansion-speech-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/lichking-locale-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/lichking-speech-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/locale-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/speech-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/patch-esMX.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/patch-esMX-2.MPQ" -e "*"
MPQExtractor -f -c -o E:/Escritorio/mpqdata "D:/Juegos/wow/Data/esMX/patch-esMX-3.MPQ" -e "*"
Downloaded esES lang pack for the client and extracted it again, spanish strings went to zhCN: https://imgur.com/a/8j1tqS4
Azerothcore locales id (worldserver.conf):
#
# DBC.Locale
# Description: DBC language settings.
# Default: 255 - (Auto Detect)
# 0 - (English)
# 1 - (Korean)
# 2 - (French)
# 3 - (German)
# 4 - (Chinese)
# 5 - (Taiwanese)
# 6 - (Spanish)
# 7 - (Spanish Mexico)
# 8 - (Russian)
Extractor seems to set different id's for locales and that might be the problem?
a couple of things before i mull this over overnight.
i found some esMX locales myself, loaded them in WDBX and saw the same thing (for ChrRaces.dbc). Thought it do be weird, used other dbc tools i have lying around for some reason and the locale string was on column 21 as expected
if we look at the output from wdbx and node-dbc-reader again it lists all locales besides each other, even those that are functionally on the same column (namely EN, CN, TW) So thats a bust.
The second part. The setup azerothcore uses assumes wrongly that esES and esMX are equivalent and on the same column index. They are not! Why did i never notice that? I guess i always had esES and esMX in tandem and since they were assumed to be equivalent esES got picked and it worked. I can't reproduce that today, because i rewrote the setup about a year ago (@Helias; merge already!) And if i use esMX DBCs instead of esES DBCs the result set is just empty
/e: i used ChrRaces.dbc just beause its smaller than Spell.dbc just to be totally sure we are on the same page, here are some checksums for the esMX ChrRaces.dbc i used MD5: 885170ac941dbb952f253e41bc6002fe SHA1: 5a5bcea803fd3225f8c0e5c334e6a5968bcc846e
/e: i used ChrRaces.dbc just beause its smaller than Spell.dbc just to be totally sure we are on the same page, here are some checksums for the esMX ChrRaces.dbc i used MD5: 885170ac941dbb952f253e41bc6002fe SHA1: 5a5bcea803fd3225f8c0e5c334e6a5968bcc846e
I confirm MD5 and SHA1: MD5 hash de chrraces.dbc: 885170ac941dbb952f253e41bc6002fe
SHA1 hash de chrraces.dbc: 5a5bcea803fd3225f8c0e5c334e6a5968bcc846e
I was exporting to a SQL file the enTW to copy its values to esMX/esES in the aowow_spell table to check if it works but it will take some serious time because the SQL that WDBXEditor generated has a lot a sintax errors... Maybe I'll wait for -fingers crossed- good news from you 😅
I've tried to set aowow using esES dbc's and it gave me empty strings too... that might be because I didn't empty the db tho...
I need to align azerothcore/aowow with sarjuu/aowow still, the new updated setup is still missing, I should take this PR back and complete it :S
I've tried to set aowow using esES dbc's and it gave me empty strings too... that might be because I didn't empty the db tho...
If you have access to an esES client this would be the easiest solution by far.
But yes, you need to drop the previously generated tables with a dbc_ prefix.
I've tried to set aowow using esES dbc's and it gave me empty strings too... that might be because I didn't empty the db tho...
If you have access to an esES client this would be the easiest solution by far. But yes, you need to drop the previously generated tables with a
dbc_prefix.
Well... I extracted esES client and spanish strings went to zhCN: https://imgur.com/a/8j1tqS4 Didn't try to deploy it tho because it seems wrong too.
Ignore wdbx. I didn't realize it displayed strings so poorly. :/
See how it displays enCN and zhCN as two separate cols? Thats nonsense. They are on the same column. Same for enTW/zhTW and enUS/enGB
Ignore wdbx. I didn't realize it displayed strings so poorly. :/
See how it displays enCN and zhCN as two separate cols? Thats nonsense. They are on the same column. Same for enTW/zhTW and enUS/enGB
Ok, will extract esES again and build aowow from scratch with it... will share results when done. Thanks!
Finally! after a clean install with esES locale db's aowow works at 100%... thank you! It might worth check the extraction of esMX locales tho...
Cheers!
It's unused, probably forever. Not even red-rocket-site has an esMX localization that i could reuse.