Is the article written neutrally
Again, I have written articles on debugging, where I recommend FpDebug. Recommendation is not neutral.
Recommendations are not necessarily non-neutral. For example I often recommend against using GTK2 but I do so because it is EOL, does not receive any security updates anymore, and the usage of which may be liable under laws such as EU Regulation 2019/770. It is a recommendation, but it is based on objective criteria.
But what if not?
Half the IDE help pages are outdated. But better than none. So removing is not an option.
At the very least, it should be marked as such. Either with a note/warning on top of the page, or a fixed div in a corner like with the platform specific articles.
Then for a later step it can be added to a list (forum post, wiki page, wiki category), so someone who has the time and knowledge can update it eventually.
Knowing what you don't know is always the first step.
Though several articles on a subject may exist, if they refer to each other. And briefly explain why both exist.
And if the don't, the solution may be to add this.
E.g.: https://wiki.freepascal.org/SVN_to_GIT_Cheatsheet#Alternative_to_this_Page
When I added these two points, I had this in mind:
https://wiki.freepascal.org/unicode_use_casesThis page basically just states "sqlite and firebird require UTF-8 for their file paths", this information can be fully incorporated in one of the "Unicode Support" pages.
Note that there is also quite an overlap between FPC Unicode Support and LCL Unicode Support, so this can be either reduced (e.g. by not having language and FPC specifics in the LCL article), or have a common Unicode Support article and just an FPC and LCL specific article for the specific functions provided by the RTL or LCL.
Is there an english version of the article
What if not?
One could check the article (google translate should allow getting a general overview what it tries to be) and if it seems valuable, create an english version, if it is covered by other articles, integrated into another article, and if it seems to be of little value, maybe mark it as "deprectaed" or so.
Needs some form of easy to add marker (some template)
Maybe a category so that e.g. a german speaker who wants to help can just go to the category "outdated german" and check where it could be helped.
For third party packages and tools: Is it clearly marked as such
ok
For packages and third party tools: Is the License noted
For third party packages and tools: Is an Author named/linked
For third party packages and tools: Is there a link for further information
For third party packages and tools: Is it still actively maintained
if not, the info may still be of interest
Sure, but it should be clearly visible as such. What would maybe be possible, to have a template for third party components, a table or something like that, which shows the basic information. Like Wikipedia has in:
https://en.wikipedia.org/wiki/GTK- Original author(s)
- Developer(s)
- Initial release
- Stable release
- Preview release
- Repository
- Written in
- Operating system
- Type
- License
- Website
Btw, "subjective" doesn't mean it can't be a criteria, at least at some point, eventually.
But, before that it should be refined, and reviewed by a group of different people. Using a good amount of samples from the wiki to write detailed guidelines....
First, the criterias I've put up there was what came to my mind and not fully thought through. That said, I had a few articles in mind that I have found with such problems to base this on. But of course this needs more work than just one guy comming up with them on the spot.
I think this can really benefit, because yeah it's a bit of effort at first, but once it is done, it will archive at least a base level of harmonization.
About the subjectiveness, this is always a spectrum, like there are things which are obviously not adding much value, e.g.
https://wiki.lazarus.freepascal.org/$A is completely unessecary because
https://lazarus-ccr.sourceforge.io/fpcdoc/prog/progsu1.html#x8-70001.2.1 exists, and is more thourough and as official documentation also normative (unlike the wiki which is just informative on a best effort basis).
For less obvious cases a peer review may be the best option
Recent
