Yezur Wiki:Dictionary structure

How the Dictionary namespace should be structured, modelled on Earth's Wiktionary (specifically the English Wiktionary, whose "Entry layout" policy is the most developed). This page is the out-of-frame blueprint; the Dictionary entries themselves are in-character. Nothing below is built yet — it documents the target so that words can be added in a structured, precise way from the very first entry.

How Wiktionary structures an entry

One page per written form. The page title is the exact spelling, case-sensitive (polish and Polish are different pages). Every language that uses that spelling shares the single page; a {{also|…}} hatnote at the very top cross-links near-identical spellings (case or diacritic variants).

One level-2 heading per language (==English==, ==Finnish==), in alphabetical order. Everything about the word in that language nests inside its section; languages never mix below level 2. A word's entry can be a two-line stub or a monograph, but it always sits in the same skeleton.

A fixed heading order inside each language section — only the headings that apply, but always in this order and nesting:

==Language==
===Alternative forms===
===Etymology===
===Pronunciation===        (IPA, audio, rhymes, hyphenation)
===Noun===                 (or Verb, Adjective, … — the part-of-speech heading)
Headword line
# Meaning 1
#* Quotations
====Usage notes====
====Synonyms==== / ====Antonyms==== / …
====Derived terms====
====Related terms====
====Descendants====
====Translations====       (English entries only)
===References===
===Anagrams===

Where one spelling covers several unrelated origins, ===Etymology 1===, ===Etymology 2===, … each carry their own part-of-speech sections, pushed one level deeper (====Noun====). Nesting is the key principle: a heading owns everything after it until a heading of the same level.

The headword line. Directly under each part-of-speech heading, a headword template renders the word in bold with its key grammar — language-specific where one exists ({{en-noun}}, which knows English plurals), the generic {{head|<code>|<pos>}} otherwise. It also auto-categorizes the page (Category:English nouns) — editors almost never hand-categorize.

Definitions are numbered wikitext list items (#), one sense per line. Context labels — {{lb|en|nautical|slang}} — prefix a sense and categorize it too. Example sentences ({{ux|…}}) and dated quotations (#*) nest under the sense they illustrate.

Everything is language-coded. The first argument of nearly every template is a language code (en, ang, gem-pro), resolved by one central registry module (their Module:languages) that knows each language's canonical name, script, and family. That single registry is what lets templates link, label, transliterate, and categorize automatically — it is the engine of the whole system.

Linking vs. mentioning. {{l|de|Hund}} links a term in a list (synonyms, derived terms); {{m|de|Hund}} mentions it in running prose (italicized, as in etymologies). Both target the right language's section of the right page.

Etymology templates display text and categorize in one stroke:

• {{inh|en|ang|hund}} — inherited from an ancestor stage
• {{bor|en|fr|hôtel}} — borrowed
• {{der|…}} — derived, when the path is less direct
• {{cog|de|Hund}} — a cognate in a sister language (display only)
• {{doublet|en|canine}} — same-source pairs within the language

Non-English entries are glossed, not defined: a Finnish word gets a one-line English translation as its definition, and no Translations section. Translation tables ({{trans-top|gloss}} … {{t|de|Hund|m}} … {{trans-bottom}}, one collapsible table per sense) live only on English entries. English is the hub language — every pair of languages meets through it, which keeps the many-to-many translation problem linear.

Reconstructed terms are not mainspace. Proto-language words live in a dedicated Reconstruction: namespace (Reconstruction:Proto-Germanic/hundaz) and are always cited with a leading asterisk (*hundaz), the historical-linguistics convention for unattested forms.

Inflected forms get thin satellite pages ("hounds — plural of hound"), usually bot-created; the lemma page carries all real content.

What the Yezur Dictionary adopts

The same skeleton, sized for a dictionary starting from zero on a Cargo-first wiki:

• Adopt as-is: one page per written form; one L2 section per Yezuri language; the fixed heading order and nesting; numbered senses; glosses in the wiki's prose language (the same stand-in convention as article prose).
• Registry first. Before the first entry, build the language registry — a Lua module mapping each language code (YAQ-HE for Hertic, …) to its canonical name, family, and script. Every dictionary template takes the code as its first argument, exactly as on Wiktionary. This is the foundation piece; everything else leans on it.
• A minimal starter kit of general-purpose templates (per-language headword templates can come later, once grammar exists to encode):
  • {{head|code|pos}} — headword line + auto-categorization
  • {{l|code|word}} and {{m|code|word}} — link and mention
  • {{IPA|code|/…/}} — pronunciation
  • {{lb|code|label…}} — sense labels
  • {{inh}} / {{bor}} / {{cog}} — the etymology trio
  • {{ux|code|example}} — usage examples
• Cargo from the first word. Where Wiktionary only categorizes, our Dictionary structure should also file each entry into a Lexemes Cargo table (word, language, part of speech, gloss, …). That is the interlingual payoff the Dictionary exists for: cognate sets, borrowing chains, "every Hertic noun", "all words inherited from Proto-A" — one query each, self-maintaining.
• Reconstructions as Dictionary:Reconstruction/Proto-A/… subpages for now (a dedicated namespace can come when volume justifies it), always cited with the leading *.
• No translation tables yet. With six languages and no lexicon, glosses carry the load; revisit the hub-language mechanism once entries exist in several languages for the same concepts.

Open decisions (operator)

• Page titles: native script or romanization? Wiktionary titles entries in the native script. Our endonyms currently render in borrowed real-world glyphs (see the pending flag on the routine report), so this decision is upstream of the first entry.
• The in-world frame of the Dictionary itself: in-universe, what language is the Dictionary written in? (Same stand-in question as article prose, but a dictionary makes it visible on every page.)
• Homographs: adopt the Etymology 1 / Etymology 2 pattern from the start, or defer until the first real homograph appears?
• Inflected-form satellite pages: create them at all in the early phase, or let them wait for a bot?