Improve documentation

[tooomm]

Expand on file documentation in the wiki (https://github.com/Cockatrice/Magic-Token/wiki#documentation) and create and curate a new page.
Also include info about structure, layout and sorting.

The example card comment is also probably better off in the wiki next to its explanation and further details, and only have a link to all doc resource in the token file instead:
https://github.com/Cockatrice/Magic-Token/blob/master/tokens.xml#L15-L32

Place a link in the readme.

Helpful infos and hints for potential guidelines:

• Sorting (a3838d9, 7a0f46f, 26ff452)
• related before reverse-related, sorting (67a2d6c (#108))
• count before exclude (543b96c (#108))
• spaces > tabs indentation (fb31047 (#108))
• related vs. reverse-related
  (AFR (and most of AFC) Tokens #108 (comment), Remove all <related> for <reverse-related> #119, --> 67b20ab)
• Should there be a separate entry for single token creation in an X range?
  If a card has several occurrences, there probably needs to be exclude tags?
  When (or after all) to use count="x=1"?
  (MIC and MID Tokens #114 (comment), CLB Tokens #147 (review))
• Use count="x=0" at all? (Trim token file down on not needed extra entries #102 + Remove x=0 values #101)
• Alphabetical sorting detail (VOW Tokens #125 (comment))
• Chronological sorting for pictures for one token (newest at the top, MTGSON has a SetList file with metadata)
• Allow token without art? How to list them? <set>SETCODE</set> vs. <set picURL="">SETCODE</set>?
  (Kamigawa Tokens #134 --> remove misspellings of picURL #150, CLB Tokens #147 (comment))
• How to use placeholder for missing art? (VOW Tokens #125 (comment)), Do not use placeholder elements at all?
• Make e.g. sorting and reordering stuff of unrelated elements their own PRs, generally place unrealted changes in seperate PRs as noted in AFR (and most of AFC) Tokens #108
• List helpful search queries to find new token creators and relations: CLB Tokens #147 (comment), Streets of New Capenna tokens #141 (comment)
• Special characters needs to be escaped, e.g. &, see CLB Tokens #147 (comment)
• Order and structure in file for human friendliness: Move cmc element for 2/2 shapeshifter #153 (comment)
• more sorting cfb9ba9
• various checks and clean ups remove unused token relations #160
• card and set sorting sort sets and cards #165 (first draft and test for setup in ci: https://github.com/Cockatrice/Magic-Token/tree/tooomm-ci_sorting)
• Do not use x=1 (but only x) Add J22 Tokens #207
• Excludes for double entries add missing excludes for double entries #203
• Add MOM Tokens #222 (comment)

[ebbit1q]

I suggested adding a github action that simply automates all of this simple formatting stuff, ordering things is something computers should do, not humans

[tooomm]

ordering things is something computers should do, not humans

I totally support that!
Mentioned some potential other ideas in the linked issue as well. Most noticeable the ability to check if the date/version got updated, which people easily forget. :)
Also something that could be applied automatically right away.

There should probably still be some docs about the rules being applied/wanted.

Would you rather have a checking GH Action that notifies about misalignments that the PR creator should take care of with a script we provide (like the Cockatrice lint action?), or one that actually applies the preferred sorting rules and commits the changes right to the pr/repo (or probably better: creates a PR so that we can check again)?

The last (commit to repo) could run e.g. on push to master, scheduled once every week or triggered manually...

[Psithief]

I don't really think the version should be changed except by the person merging a branch into master. It's not a useful request, because the author doesn't know when or if their pull request will be merged.

[tooomm]

the author doesn't know when or if their pull request will be merged.

True. That is a totally valid point!

I don't really think the version should be changed except by the person merging a branch into master.

I agree with you on the time when such an update should happen.

However, there are ways around enforcing a manual human action there and skipping the potential mistakes involved or forgetting it altogether.
As noted, the CI can run e.g. on every push event on master (direct commit, PR merged) and update the date automatically the minute after. Or check e.g. on a daily schedule if changes happened and update the date with the last commit date etc.

I agree with ebbit here and think the date update is also "something computers should do, not humans".

[ebbit1q]

actions can be triggered by merging