Unfortunately I suspect there isn’t anyone that knows who is commenting anywhere any more. I don’t know of anything that happens if you have a taxonomy field, so I usually delete them, but there could be something happening I’m not aware of. It could also be part of the long term plan for future development (there are indications of that in the source in places.) The project appears to have been very well thought out, in terms of where it should go in the future, with the foundations for stuff not yet implements in place. The original developers have pretty much either all left or are not communicating, and as I said many of the folks that were here when development was still active (I only came upon Fritzing in 2016 after development had stopped) aren’t posting any more so we are losing expertise. There are few comments in the source, and it is complex. I usually find a message in the area I’m interested in and then search the source for the message (which is hard since many of them are created, so you have to search for boiler plate text that will be present in all messages and search for that) and then use gdb to trace the code to figure out what is going on.
When (and hopefully not if ) I manage to finish the update to the check part script. The intent is to have a check only version that will be in the part submit tool chain so new parts need to pass the script. However that means the false positives that I currently leave to human decision need to be dealt with in some manner suitable to automation. It is going slow. Next task on my list is documenting the part obsoleting code (needed when replacing parts in core parts which is going to need to be done to clean up core parts to pass the script), then cleaning up core parts (a big job!) Somewhere after that is figuring out what all the possible fzp tags mean and documenting them is on the list. If you would like to start that, more the power to you I expect that will take reading the source to figure out (if possible) what it is supposed to do. Sometimes just experimenting with parts may be enough (change the value, see what happens) and may be much easier!
Doesn’t to me either. I’m not aware of anything in Fritzing that cares about it, so it may be part of the svg standard (I’m not really svg aware either, only as much as Fritzing uses.) Setting it to the current file name while redundant, seemed the best choice. Deleting it entirely may be the better choice (reduces file size and increases performance by a tiny fraction), but I’d need to know more to do so, like so many things.
@KjellM who leads the development team would probably have the best answer to that. I usually use the tutorials and howtos section of the forums, but either place on the wiki should be fine, the existence somewhere of documentation is the important part rather than where it is as far as I am concerned .
I haven’t had occasion to look for Inspector, I’ve poked at the parts factory (which makes headers and ICs in various sizes) somewhat. A search for “Inspector” should turn up the code that writes the window which is likely in the window manager and not what you want, but may provide a pointer to the code you do want (the names are reasonably descriptive.) There may even be a separate directory for Inspector code if you are lucky.
That unfortunately is all too common. I suspect the original team asked the more experienced team members for help. There may be internal documentation somewhere, but if so I’ve never heard of it (although that doesn’t mean anything.) We don’t have that luxury and have to guess or trace the code to see what it does which I find extremely difficult.
Peter