Authors CurseForge

I have the following lines in my localization file:

if (locale == "deDE") then  -- German
--@localization(locale="deDE", format="lua_additive_table", namespace="Tabs", handle-subnamespaces="subtable")@

elseif (locale == "frFR") then  -- French
--@localization(locale="frFR", format="lua_additive_table", namespace="Tabs", handle-subnamespaces="subtable")@

Etc.

 

I've used this same code for years without any changes and it has been fine. But now, my latest commit is outputting something like this:

 

if (locale == "deDE") then  -- German
L["Tabs"] = {
	["EVENTNOTICE_ENDED_TODAY"] = "|cffff2020Dieses Ereignis endete|r heute frühzeitig."
	["EVENTNOTICE_ENDS_DATETIME"] = "Es endet am %1$02d.%2$02d um %3$s (Serverzeit)."
	["EVENTNOTICE_ENDS_DAYS"] = "Es endet in|cffff2020 %s |4Tag:Tagen;|r."
	["EVENTNOTICE_ENDS_HOURS"] = "Es endet in|cffff2020 %s |4Stunde:Stunden;|r."
	["EVENTNOTICE_ENDS_MINUTES"] = "Es endet in|cffff2020 %s |4Minute:Minuten;|r."

-- snip

}

elseif (locale == "frFR") then  -- French
L["Tabs"] = {

-- snip

 

Clearly, this is not going to work. Not only is there no comma separating the different elements of the table (resulting in a syntax error), but I wasn't expecting you to try to stuff it all into the "Tabs" key to begin with. The handle-subnamespaces="subtable" bit is there to handle SUB-namespaces, namespaces within Tabs, not the Tabs namespace (which is a namespace, not a SUB-namespace).

 

I'm expecting something more like this:

 

if (locale == "deDE") then  -- German
L["EVENTNOTICE_ENDED_TODAY"] = "|cffff2020Dieses Ereignis endete|r heute frühzeitig."
L["EVENTNOTICE_ENDS_DATETIME"] = "Es endet am %1$02d.%2$02d um %3$s (Serverzeit)."
L["EVENTNOTICE_ENDS_DAYS"] = "Es endet in|cffff2020 %s |4Tag:Tagen;|r."

... with subnamespaces handled as part of that, maybe something like:

 

L["SUBZONES"] = {
	["key"] = "value",
}

 

This is a huge problem for me. It means I either cannot release my addon or I have to release an alpha version, manually correct the issue, and then release a new file which doesn't use your localization substitution.

This is even worse than I thought. I looked over another of my localization files from the commit, this one from the main addon folder (not one of the load-on-demand components that use a special namespace like "Tabs"). This line:

--@localization(locale="deDE", format="lua_additive_table", handle-subnamespaces="none")@

... gives, through CurseForge's localization substitution, things like this:

 

-- snip
L["WILDPET"] = "Wildtier"
L["YOURPROGRESS"] = "Dein Fortschritt"

-- Tabs
L["EVENTNOTICE_ENDED_TODAY"] = "|cffff2020Dieses Ereignis endete|r heute frühzeitig."
L["EVENTNOTICE_ENDS_DATETIME"] = "Es endet am %1$02d.%2$02d um %3$s (Serverzeit)."
L["EVENTNOTICE_ENDS_DAYS"] = "Es endet in|cffff2020 %s |4Tag:Tagen;|r."
-- snip

 

It's not supposed to include the Tabs namespace. Isn't the whole point of handle-subnamespaces="none" that it won't output anything from other namespaces contained within this, the main one? And the funny thing is, here it DOES insert sub-namespaces of Tabs as a sub-table, like I gave an example for above ("SUBZONES"). But it doesn't even get that right, sticking a comma on the end of the table, causing a syntax error:

 

L["WATCH_TAB"] = "Suivi"
	L["SUBZONES"] = {
		["Argent Pavilion"] = "Pavillon d'Argent",
		["Argent Tournament Grounds"] = "Enceinte du tournoi d'Argent",
	},

 So, where it shouldn't output sub-namespaces, it does, and worse, it does so improperly which creates an error that grinds the whole addon to a halt. Where it should do it, not only does it fail to do so but it creates another addon-breaking syntax error as outlined in my first post.

I had to completely redo my localization code in my addon to compensate for this. It was a major hassle. Now when you fix it, I will have to undo it. As for now, I cant update other addons with localizations, because I would have to re-engineer them too.

 

What happened?

Bump

Has this been looked into at all, yet? The only way I have to test whether it's working properly again is a time-consuming process which results in a release file being put up on the site that, if it didn't work, isn't something I want my users to see in the first place, let alone download (and so start seeing errors again).

I made another alpha release yesterday with my proper localization files to test whether the problem still persists, and it does. For the "real" release, I had to again use my manually-adjusted localization strings. This issue has made the localization system useless for me.

 

I'm trying to not get worked up about this or blame anyone personally (hey, I'm a coder, too, and I don't just mean of addons; I know bugs happen), but it's very frustrating. I reported this months ago and haven't had so much as a word of acknowledgement that the issue is being investigated.

 

Someone might think that this is just how it is now and I should adapt, but "how it is" is a buggy mess. As I've outlined above, the system outputs things I expressly told it not to, it fails to output things it's supposed to, and what it outputs causes errors. Imagine there's a system which gives you apples when you ask for oranges and oranges when you ask for apples. One might try to "compensate" for the problem by asking for oranges when you really want apples, but it doesn't end there: What you get back aren't some nice apples; they're useless rotten apples. My point is, if I use some trick to get, say, subnamespaces only where I want them, those subnamespaces will still have syntax errors.

 

(Throwing that comma on the end like that... I can't compensate for this. I don't even know in what context that would be useful. It's not like I asked for one format and it outputted the other unexpectedly. It gave me a sort of mix of formats that will never work together.)

 

At least, I can't compensate without a time-consuming reorganization of many keys and a rewrite of much of my localization code. I'd end up removing those subtables entirely, most likely, which is not only tedious but makes it feel much less organized. Reorganizing something into a version of itself that's less organized is just silly.

Is this being looked at? Or am I going to be required to rework my localization groupings -- and actually not even use certain features since they're just not going to work properly? What's going on?