(In D877 it was discussed whether to rename those directories. Meh, a mess, whatever xd)

Condense to 1 line. List is not well defined (array), but that it's an array is self evident, no need to mention that, just consumes time to read when one could have read [ already.

s/Info/Tooltip

(g_TooltipTextFormats should be changed some day to only save the actual fonts)

The functions here should all do the same thing, return the entire string, not one to return the caption and the rest the rest of the previous function.

I suspect you might want 3 arrays, one for auras, one for techs and one for entities.

Not ideal, the callers should pass the thing they want to the functions ideally, but might not be so easy to fix, good enough for now.

(It's the tech requirements defining which civ can research it, but deriving it from the researcher is ok if that's shorter)

Should always or never pass the civ per parameter (single source of truth, minimization of possible code paths i.e. https://en.wikipedia.org/wiki/Cyclomatic_complexity).

If I recall correctly it was only about the palisade wallset? If so I will try to assassinate that.

Can also do throw new Error, but I guess this one is more comfortable for debugging

We have updateGUIObjects in session and gamesetup ? draw sounds more that paints pixels onTick. Fits also a bit to GetGUIObjectByName. Dunno about the draw.js filename, could be kept if we don't find anything else.

There is a revision that implements this: D844. If accepted and merged (along with its prerequisite) this "crude hack", as I describe it, could be replaced with something nicer.

In fact, one of the reasons why I've been dragging my heels on this revision is that I was hoping to get that revision in first.

We only have few fonts, expecting that it breaks under some circumstance. Font names should be hardcoded, remain exchangeable and findable with a string-search. But that can be done when dealing with the TODO

(Not a fan of one function parsing different formats)

As mentioned in the function comment, this is (or rather, was) a near-identical function to one elsewhere. I say "was" because it was a couple of years ago when this page was originally thrown together. The original function this was based on has been altered/rewritten/improved since then. This "copy" was not.

I've marked the remarks as "done" as I cannot mark them as "no longer valid" - I've removed this function override in favour of a different approach to what I want to achieve. And hopefully the new approach is a better one.

The internal property seems like a workaround. That property should be accessible to all places using the globalscripts parsing or none.

Could also be done by changing the structure to g_BuildList[civ][templateName], g_BuildList[civ] = { "templateName": ..., "template": ... } or g_BuildList[civ] = [templateName1, ...]` and parsing JIT.

But it seems legit that one might want to get the templateName from a parsed template, so why not add it to GetTemplateDataHelper? (Can be done afterwards, since it's present already).

At last, I don't know where the tech/ actually comes from, can't find it in templates files nor directories. I had assumed we might be able to use basename

We shouldn't figure out after the effect what kind of file we're dealing with, but it should be a choice by the template viewer to first load all aura templates into an aura variable, then all techs into a tech variable and then all entity templates into a templates or entitytemplates variable.

Whether an entity is a Unit or Structure should be derived from the template (https://en.wikipedia.org/wiki/Single_source_of_truth pattern).
This way by design there is no management of secondary data that needs to be kept in sync (and we don't even have to start philosophing about other/)

I suspect we don't need the Unit / Structure differentiation if the getBuilderTooltip and getResearcherTooltip functions just return emptystring in case.
(Also suspecting that this iteration of the code implies that units can't research techs?)

(Oddity to use a struct here and a switch above. Perhaps it could be merged in a global somehow. But not touching it unless there is a sensational idea works too)

(As long as we want that colon to have the same color/font as the rest of the caption, transifex people will have to live with not being able to change the formatting nicely. Still noone complained about this, so not relevant)

(Can't tell right now, but might be nicer as 3 functions too?)

(Perhaps we should make a function from that repeated string some day)

(I had added those a year ago too, but that template is an object is evident from the first line of the function, so not sure if its worth it. If completeness is a value, we might also add other things for completeness. idc)

Not a string. Again I think reading the first line of the function reveals much more than any description could achieve.

(D717 will provide that)

Oh I get it, we have some JSON files to throw at it again :-)