Hi! Thanks for shipping the update and for including my Chinese translations.

My client locale is zhCN (/dump GetLocale() returns "zhCN").

About the earlier string-concat error

I was still seeing a crash in Frames/Stats.lua even with translations present. The root cause on my side was that some files used L["..."] without first retrieving L in that file’s scope, so L was nil and string concatenation failed (and the AceLocale English fallback didn’t kick in because L itself wasn’t set).

Fix that worked for me: add this at the top of every Lua file that uses L[...]:

local L = LibStub("AceLocale-3.0"):GetLocale("MurlokExport", true) or {}

This makes English fallback work even if a zhCN key is missing.

Current issue (functionality)

After applying the above (and with no more errors), Talents and Traits pages are still not working for me. To verify it’s not locale-specific, I also tested on PTR with the client switched to English (enUS) and saw the same result. Stats/etc. load, but Talents/Traits show no usable data (see attached screenshots).

Is this expected in the current build (temporarily disabled/not yet implemented), or is there another dependency or load-order requirement for those pages? I’m happy to provide additional logs, /dump output, or enable any debug flags you suggest.

Thanks a lot for your work—I’m looking forward to using the full functionality!

Hi @noskins,

the fix with L[] was actually not a problem with AceLocale or that the dictionary wasn't filled up (default will always be enEN though). The problem was with the export data itself.
At line 44 in Stats.lua null values from the object v was concatenated - which throw the exception. I have added 2 lines to convert them to 0 in that case as a fix.

Currently there is an API issue on Blizzard side and unfortunately they are not taking care of it since last week:
https://us.forums.blizzard.com/en/blizzard/t/wow-112-character-specializations-api-talents-missing/55656/25

As you can read the official APIs are not returning anymore talents/loadouts for characters.
All depending AddOns (including mine) are at the moment affected by that.

As soon as data is available again you will see that in MurlokExport.
Until then you can use stats/equipment tabs...

Thanks for your feedback and supporting debug information...

BR
--Alex

Hi, thanks for the quick response and for confirming the Blizzard API issue.
Regarding Talents / Traits: understood—I'll wait until Blizzard restores the data.

Separately, I’d like to report a zhCN client issue that still reproduces on v20250823.011447:

On a zhCN client (/dump GetLocale() → "zhCN"), the addon does not display the labels for Secondary (MURLOKEXPORT_STATS_SECONDARY) and Minor (MURLOKEXPORT_STATS_MINOR) stats, and I still see the same string-concatenation error as before.

After adding the following line at the top of Frames/Stats.lua:

local L = LibStub("AceLocale-3.0"):GetLocale("MurlokExport", true) or {}

the error goes away and both labels render correctly in Chinese.
(Screenshots attached: before and after this change.)

This suggests that, in this file’s scope, L wasn’t initialized—so the AceLocale fallback couldn’t kick in and L[...] evaluated to nil, causing the concatenation error. Fetching L locally in the file resolves it on my side. If other files reference L[...], you may want to fetch L in those files as well.

Thanks again for your work and for looking into this. Screenshots attached for reference.

Dear @noskins,

thanks again for providing debug information.
The localization module works likes this:
In MurlokExport.toc XML file for localization is loaded: Locales\Localization.xml.
Within this XML file scripts are included by order

<Ui ... >
  <Script file="zhCN.lua"/>
  <Script file="Localization.lua"/>
</Ui>

In Localization.lua I have same code as you have suggested:

L = LibStub("AceLocale-3.0"):GetLocale("MurlokExport")

Here I declare L as global variable. But somehow L is nil in Chinese client case and we need to add the line you provided as fix.
I have found another solution without loading the locale again.
Global variables can be accessed in lua code with _G["name_of_global_variable"].
I will publish a new version soon.
Let me now if that works for you.

Thanks
-- Alex

The new version has been tested and is now working properly on the Chinese client. Thank you very much.

Glad to hear that the fix worked for you too. Thanks for reporting and all...