Yezur Wiki:Conventions
This page collects the editorial and structural conventions of the Yezur Wiki — a working reference for new editors, human and AI alike. The wiki is the single source of truth for the world of Yezur; these are the habits that keep it consistent.
The cardinal rule
A fact is canon only once it is written onto a wiki page. Conversation, agreement, and brainstorming are not canon until they land here.
Editorial voice
Articles in the main namespace are written as an encyclopedia by Yezuri, for Yezuri readers. Two requirements, always together:
- Encyclopedic register. Neutral and third-person, definition-first, like any good reference work. No storytelling, no chatty asides, no first- or second-person address to the reader, no marketing or how-to tone.
- In-world (Watsonian) frame. Written from inside Yezur. Never break frame: no comparisons to the real world, no asides to the real reader, no mention of the design process or the tools used to build the wiki.
No real-world references
Yezur is not Earth. Do not invoke real civilizations, cultures, religions, writing systems, landmarks, or figures by their real-world names — no "Latin script", no "Romanized", no real place or people names. Analogy is welcome: monarchies, pottery, navigation, cathedrals and countless familiar concepts exist here in recognizable forms — but each should feel grown from Yezur's own history, not lifted from a specific real culture.
The Earth test
Write about Yezur the way Wikipedia writes about Earth: as the world, not a world. Wherever "Yezur" or "Yezuri" appears, the sentence should still read as a natural Wikipedia sentence with "Earth" in its place. Wikipedia's article on Basque does not say the language has "no clear cognates in any other Earth language" — so ours must not say "in any other Yezuri language". Qualify by planet only where Wikipedia would: "loanwords drawn from languages across Yezur" passes the test ("languages across Earth"); a reflexive "Yezuri" in front of every other noun does not.
No magic
No supernatural forces or spellcraft act on the physical world. In-world myths and folk beliefs may exist without being literally true.
Plausible mechanics
Biology, geology, and climate behave as in reality, and the cosmos is the real one; only the specifics — species, peoples, surface geography — are Yezuri.
Familiar to the second level
Much of Yezur matches Earth up to the second-most specific level. The broad kinds are shared: there are zebras, though not Earth's zebra species; crops, instruments, institutions and dress all have close counterparts. Some things transfer essentially whole — many sports exist just as on Earth, at worst under mildly different rules or disciplines. What never transfers is the Earth-specific pedigree: the exact species, the founding story, the name that honours an Earth place or person. However familiar the thing itself, its origin and history are Yezur's own. This is the constructive side of no real-world references: take the familiar kind, and give Yezur its own instance of it.
Where out-of-frame content goes
Real-world commentary — design rationale, comparisons, notes on tooling, unresolved questions — never appears in article text. It belongs on Talk pages, in the Meta: namespace, or in this Yezur Wiki: namespace.
Namespaces
| Namespace | Frame | Purpose |
|---|---|---|
| (Main), Dictionary:, Map: | In-character | Encyclopedia articles, the dictionary, and the map wiki |
| Yezur Wiki: | Out-of-frame | Policy, style, and conventions (this page) |
| Meta: | Out-of-frame | Design notes and rationale |
| Talk: (all) | Out-of-frame | Discussion and open threads |
Rule of thumb: everything a reader or editor sees is in-character, except the Meta:, Talk:, and Yezur Wiki: namespaces. That includes template, module, and category names — see Naming.
Who edits as whom
Every editor has a distinct account, so authorship is clear at a glance in page history:
- Yezur — the human editor, working in the browser.
- Khurouan and Thiorosan — interactive AI authors, the same role from different workstations; separate accounts so an edit can be traced to the agent that made it.
- Alompan — the automated daily-maintenance routine (see Yezur Wiki:Daily routine).
(The bot accounts share their names with the ancient cities of Hertia.)
Keep edit summaries in-character where you reasonably can — describe the change to the article ("Start an article on the Hertic language"), not the process behind it.
Naming
- Language articles use the "X language" form (e.g. Gaillean language). Native names and other aliases become redirects.
- Language families currently carry placeholder labels ("Family A", and so on) until their in-world names are derived; use them sparingly.
- Categories follow real-encyclopedia habits but drop the global "of Yezur" — we would not write "Rivers of Earth", so we write Continents, not "Continents of Yezur". Keep narrower place qualifiers, such as "Polities of Andusia".
- Templates, modules, and categories are in-character too. Avoid real-world terms in their names; encyclopedia-furniture words (Infobox, Cite, Stub, Navbox) are fine, since the in-world encyclopedia uses them about itself.
Text formatting
Wikipedia's Manual of Style on text formatting applies here, overwhelmingly. In particular:
- Boldface marks the article's subject — and its significant alternative names and redirect targets — at first mention, and almost nothing else. Do not bold terms for emphasis.
- Italics carry their usual duties: words as words, native-language forms, titles of works — and only sparing emphasis.
Categories
Categories form a nested hierarchy — and, being a directed graph, a category may have more than one parent. Broad topics branch into specific sub-categories; a page joins the most specific categories that apply, not a flat top-level bucket. Entity-type categories nest inside topic branches: a country in Andusia sits in a "Polities of Andusia" category that is a child of both "Andusia" and "Polities".
Intersection categories are welcome wherever they aid navigation — "Former countries in Andusia" or "2002 deaths" are perfectly valid. Only hyper-specific slices no reader would browse — "polities in Andusia founded before a given year" — are better answered by a Cargo query than by a category.
Infoboxes and structured data
- Each entity type has its own infobox, kept granular: Template:Infobox former country is separate from the living-state Template:Infobox polity, so each carries only the fields that matter to it.
- Prefer the more specific infobox when the subject warrants one — an orchestra is a valid case for a new infobox even where a broader musical-artist infobox already exists — but ask the operator before creating a new infobox, as with categories.
- Infoboxes render through the shared Lua module Module:Infobox and one stylesheet, Template:Infobox/styles.css.
- Each infobox also files its facts into a Cargo table, so lists, member rosters, and cross-references build and maintain themselves from the articles.
- Store plain values in any field you will display in a Cargo query table: Cargo prints raw
[[wikilinks]]in query cells. Link entities in the prose or infobox instead. - Adding a field to a Cargo table changes its schema, which needs a one-time administrative rebuild ("recreate data") on the template.
Open threads
Unresolved questions, placeholder names, and deliberate dangling references are recorded as plain text on the article's Talk page, under an == Open threads == heading — never as hidden markers inside the article.
Maintenance
- Flagging for deletion. The editing bots hold no delete right, so pages awaiting removal are tagged, not deleted. Put
{{delete|reason}}(Template:Delete) on a page to show a deletion banner and file it into Category:Pages flagged for deletion — the queue an administrator (Yezur) works through. Remove the tag to keep the page. - Auphen errors. Dictionary pages whose
{{auphen}}pronunciation cannot be resolved collect in Category:Auphen errors for review.
Maps
Link to the Yezur map with {{Node}}, {{Way}}, and {{Relation}} (by object id), or {{Coords}} / {{Coordslink}} (by coordinates).
Sourcing
Cite sources with <ref>...</ref>, collected by a <references /> tag in a references section.
Notes for AI agents
Agents run locally, each editing through its own account — Khurouan and Thiorosan for the interactive workstations, Alompan for the daily routine. The agent accounts are gathered in Category:Agent accounts. Additional operating context — the project setup, the who-edits-as-whom rule, and this convention set — lives in each workstation's CLAUDE.md. Always read the relevant page(s) before asserting canon, and surface every write you make.