From 54 Topics to Six Languages: Engineering a Verifiable WARDOGS Wiki

This article reviews the real engineering work behind the independent player reference WARDOGS Wiki. It is neither an official game website nor a T Salon community product. We use it as a practical case study in collecting, translating, verifying and publishing facts that keep changing.

A game wiki initially looks like a content project: document weapons, vehicles, maps, system requirements and mechanics, then make those pages discoverable. When the source material comes from an evolving Early Access game, the difficult work is not publishing more articles. It is answering four questions: Where did this statement come from? Which build does it describe? Is it still usable? Do the other languages preserve the same conclusion?

WARDOGS Wiki currently maintains 54 topics in English, Russian, German, Brazilian Portuguese, Japanese and Simplified Chinese, producing 324 localized guides. The site also contains a structured item catalogue, videos, news, interactive maps and tools for weapon comparison, ammunition matching, budgeting and route planning.

Once the page count grew, editors could no longer keep every boundary in memory. The practical solution was to turn editorial rules into data structures, build rules and release checks.

Define what can be claimed before chasing keywords

The project also began with a keyword list. Keywords reveal what players ask; they do not prove an answer.

A player may search for a weapon's damage, a vehicle's price or an upcoming test window. The demand is real, but the information may be unpublished or visible only in footage from an older build. Filling the gap with a confident number may make a page look complete while turning an unknown into misinformation.

The content system therefore defines source boundaries first:

Structured records also carry confidence labels: confirmed, observed, corroborated or unverified. Fields without evidence remain unknown instead of being completed through inference. The public editorial policy makes the same separation between official facts, footage, community observations and unresolved claims.

The result is not a site that pretends to know everything. It is a site that tells readers which information is safe for a current decision and which information is only a historical build record.

Fifty-four topics times six locales require a manifest

The most common multilingual failure is simple: the English page changes while another locale preserves an old date, old value or even the opposite conclusion.

WARDOGS Wiki does not treat each locale as an unrelated article collection. A shared manifest controls slugs, categories, order and target queries, and all six locale directories must contain the same topics. Every MDX file has schema-validated titles, descriptions, update dates, FAQs and sources. Sources must use HTTPS and belong to approved official, creator or community hosts.

Automation cannot guarantee a correct translation, but it can remove several avoidable failures:

• one locale missing an entire topic;
• a slug diverging from the manifest;
• a source missing its verification date or using a forbidden host;
• required fields or search metadata breaking the content contract;
• MDX introducing components the renderer does not allow.

Translation still requires editorial judgment. If “observed,” “historical” or “unknown” becomes a stronger statement in another language, identical fields do not help. Localization parity means preserving the same evidence boundary, not merely producing six similar-looking texts.

Keep current facts separate from historical snapshots

An Early Access game can change prices, unlock levels, item behavior and available systems repeatedly. Old footage can still be useful evidence, but it should not masquerade as current data.

Catalogue records therefore store more than names and values. They include the observed build, verification date, source class, confidence level and change history. Current official updates can replace decision fields, while Alpha and Beta evidence remains available as a historical snapshot. The page tells the reader whether a value is safe for a current-season decision.

The same design applies beyond games. API versions, model prices, browser compatibility and platform policy all change. A system that stores only the latest answer cannot explain why a conclusion changed. A page that mixes every old answer into one narrative makes it difficult to know which one applies.

Versioned content works when every changing fact has a time boundary.

Design indexable pages and interactive tools separately

The site includes weapon comparison, ammunition matching, loadout budgeting, progression routing, system checking and logistics planning. Several tools encode a comparison or plan in the URL so another reader can open the same state.

During one static-export cycle, App Router pages consumed server-side searchParams, preventing Next.js from generating static output. Removing query support would have made the build pass while breaking existing shared URLs.

The final design renders a deterministic default state on the server, then restores query state in the browser after the page loads. Crawlers receive stable HTML, while users opening a shared link recover the intended comparison or plan. Verification goes beyond a successful build command: the exported pages are opened in a browser to confirm query restoration and catch same-origin asset failures.

Indexability and interactivity are compatible, but they usually need separate state boundaries.

Sometimes the page is waiting, not broken

The interactive map once appeared empty after opening. Logic checks and browser regression tests showed that all three basemaps loaded, their image hashes differed and switching sources worked. The actual problem was delivery: each basemap was roughly 1.9–2.1 MB, so a slow first request looked like a broken interface.

Rewriting map logic immediately would have added risk without addressing the cause. A better diagnostic order was:

1. confirm whether image requests start, their status and transferred size;
2. verify that different maps resolve to different assets;
3. check that switching a map resets position and zoom as intended;
4. then decide whether to compress, preload or add more explicit loading feedback.

“Code never ran,” “the resource failed” and “the resource arrived slowly” can look similar to a user. They require different fixes.

A release is complete only when production proves it

The site maintains canonical URLs, hreflang, sitemaps, structured data and IndexNow notifications. Their existence does not prove that a release worked.

The current release path snapshots the live sitemap, deploys, verifies the production revision, critical pages, canonical URLs, redirects and clean 404 behavior, then compares the old and new sitemaps before submitting changed URLs. An accepted IndexNow request proves only that the notification was received. It does not prove crawling, indexing or ranking.

The same distinction applies to content. A finished file, a Git commit, a successful deployment, a readable production page and a refreshed webmaster report are five different states. Reading the production response is the only way to confirm what the user actually received.

What the project actually produced

The durable result of WARDOGS Wiki is not 324 localized guides or a larger set of indexable URLs. It is a system that can continue rejecting bad information:

• search demand cannot replace a factual source;
• localization must preserve evidence scope, not just words;
• changing data needs a build and verification date;
• a passing build cannot replace browser and production checks;
• sitemap or IndexNow submission cannot be reported as indexing;
• when evidence is missing, “unknown” is the correct answer.

That is the difference between content engineering and producing pages in bulk. The first makes a claim testable across its source, version, language and release path. The second only increases the page count.

Explore the live project at WARDOGS Wiki. Its implementation and content contract are available in the GitHub repository.