Matcha Flavoured Wiki:Contributing

From Matcha Flavoured Wiki
Jump to navigation Jump to search

The Matcha Flavoured Wiki mostly looks after itself. Its articles are generated by a large language model from the pack's own files, and it updates itself when the pack does (see How it is written). It lives in a public git repository on GitHub, and the website is built from it, so there are no accounts and nothing to edit in the browser. Help is still welcome, in two ways.

Reporting a problem

The Talk tab at the top of every page opens a short form on GitHub about that page, with the page already filled in. Say what is wrong or missing and, if you can, where the pack shows it: a file in the pack, a release note or one of the developer's videos. The wiki uses only those sources, so pointing to one is what makes a fix possible. You need a GitHub account.

The daily update reads new reports. If the pack's files settle it and the fix is small, it's made in the next update and the report closes. Anything else is marked for a person to look at.

Suggesting a change

If you'd rather make the fix yourself, send a pull request:

  • Edit opens the page's source file in GitHub's editor. Make your change and choose Propose changes. GitHub forks the repository for you and opens a pull request.
  • View source shows the file as it is now.
  • View history lists every change to the page, with the reason for each.

The footer of every page also names its source file, for example wiki/pages/Main/Oven.wiki.

Some pages are generated from the pack's code, such as short pages for vanilla items and the data behind recipe tables, infoboxes and loot tables. On those pages the tab reads Write this page. It creates a hand-written file at the right path, which replaces the generated page and can still include the generated tables (see Writing). Generated files themselves are never edited by hand: the scripts regenerate them whenever the pack changes.

If you'd like to help run the wiki, not just fix a page, open an issue and say so.

Writing

Follow the style guide (wiki/STYLE.md in the repository). In short:

  • The wiki follows the Minecraft Wiki's tone and layout: encyclopedic, third person, American English, item names exactly as they appear in game, lowercase in running text.
  • Every fact must be checkable against the pack's code, its official release notes, the developer's videos or the Modrinth project description, in that order. Cite the file you used with <ref>{{Source|MF_datapack/data/...}}</ref>. Information from other wikis, forks or third-party videos is not accepted.
  • Don't copy numbers that the pack's data already provides. Use the generated templates, which update themselves when the pack changes:
    • {{Infobox auto}}: the item infobox;
    • {{Recipes}}, {{Uses}}, {{Sources}}: how an item is made, used and found;
    • {{Data/Trades/Farmer}}, {{Data/Loot/minecraft/chests/simple_dungeon}}, {{Data/Food table}} and similar.
  • Mark secrets with {{Spoiler}}, and content that is only in the development version with {{Upcoming}} or {{Planned}}.

Previewing locally

To see a change before proposing it, clone the repository and follow its README.md. tools/fetch_sources.sh, docker compose up -d and tools/build.sh start a local copy of the wiki at localhost:8080. tools/watch.sh keeps it updated as you save files, and python3 tools/preview.py "Page title" reports template errors and broken links.

How the wiki is built

  • Hand-written pages live in wiki/pages/<Namespace>/<Title>.wiki. A / in a title is written as %2F in the file name.
  • Generated pages in wiki/generated/ are produced by tools/generate.py from the pack's source at the commit pinned in tools/source.lock. A hand-written page with the same title takes precedence.
  • MediaWiki renders every page once at build time, and the result is published as a static site with full-text search. A daily check follows the pack's repository, release notes and the developer's channel. When something changes, the generated pages are regenerated and the written pages the change touches are revised and checked against the new code (the procedure is in AUTOPILOT.md).

See also