Building a Multilingual, Source-Verified Release Tracker for an Unreleased Steam Game

How to model uncertain facts, monitor first-party sources, publish localized pages, and answer player questions without turning speculation into data

By Dear Passengers Crew Editorial Team

Disclosure: This article uses Dear Passengers Crew as a practical case study. It is an independent information project and is not affiliated with FLEXUS, Valve, or Steam.

Unreleased games create an unusual publishing problem.

Players want definitive answers:

• When does the game release?

• Is a demo available?

• How many players can join?

• Does it support local co-op?

• Will it launch on consoles?

• What hardware will it require?

The available evidence, however, is rarely definitive.

A Steam page may show only a release year. A trailer may depict several characters without stating the maximum lobby size. A developer may mention a planned demo in an interview without announcing a public release date. Store tags may suggest a feature or business model without confirming either one.

A conventional content site often handles these gaps badly. It repeats a rumor, converts a placeholder into a date, or answers an unknown question with an apparently confident sentence. Once published, that statement is translated, indexed, quoted, and copied into other databases.

A reliable release tracker must therefore do more than collect information. It must model uncertainty, preserve provenance, manage revisions, and keep every localized page synchronized with the same evidence.

This article explains how we approached that problem while building Dear Passengers Crew, an independent multilingual information hub for the unreleased Steam game Dear Passengers.

As of August 6, 2026, the official Steam listing identifies FLEXUS as both developer and publisher, gives the game a 2026 release window, lists Windows requirements, and confirms single-player and online co-op. It does not publish an exact release date or maximum crew size. The public listing also does not currently provide a downloadable demo. Those distinctions became the foundation of the system rather than gaps we tried to hide.

1. Treat Every Published Statement as a Claim

The first design decision was to stop treating a page as the primary unit of information.

The real unit is a claim.

A claim is one specific statement that a reader could reasonably interpret as factual:

• “The game is planned for release in 2026.”

• “Online co-op is supported.”

• “The game supports four players.”

• “A public demo is available.”

• “The game is coming to PlayStation 5.”

Each claim needs its own status, evidence, timestamp, and publication rules.

A basic claim record can look like this:

{
  "id": "release-window",
  "subject": "Dear Passengers",
  "predicate": "planned_release_window",
  "value": "2026",
  "status": "confirmed",
  "precision": "year",
  "sourceType": "primary",
  "sourceName": "Official Steam store page",
  "sourceUrl": "https://store.steampowered.com/app/4534960/Dear_Passengers/",
  "sourcePublishedAt": null,
  "lastVerifiedAt": "2026-08-06T00:00:00Z",
  "reviewedBy": "editorial",
  "notes": "No month, day, unlock time, or preload schedule is listed."
}

This structure is intentionally more verbose than a simple key-value pair such as:

{
  "releaseDate": "2026"
}

The smaller version loses several critical distinctions:

• Is 2026 an exact date or a broad window?

• Was it published by the developer or inferred by an editor?

• When was the source last checked?

• Did the value come from a storefront, interview, trailer, or database?

• What should happen if a later source provides a more precise date?

The richer model lets the publishing layer render an honest answer:

Dear Passengers is planned for release in 2026. An exact month and day have not been announced.

It also prevents a translation or front-end component from silently converting “2026” into something more precise than the evidence supports.

2. Use an Evidence Taxonomy

A binary true-or-false field is not sufficient for an unreleased game.

We use four principal evidence states:

Confirmed

The claim is directly stated in a first-party source.

Examples include:

• A release window shown on the official Steam page

• A platform listed in the store requirements

• A play mode included in the official feature list

• A date published in a developer announcement

Attributed

The statement comes from an identifiable developer, publisher representative, or other named source, but it has not yet been incorporated into the primary product listing.

For example:

A developer said in a dated interview that the team planned to show a build at an event and intended to release a public demo later.

This is useful evidence, but it should not be rewritten as:

The demo releases on a specific date.

Plans can change. Attribution must remain attached to the claim.

Observed

The feature is visible in official media but is not explicitly documented as a final specification.

A trailer might show:

• Several crew members in one scene

• A passenger being moved through the cabin

• Cargo reacting to turbulence

• A cockpit interface

• A particular emergency event

Observation supports statements such as:

The official trailer shows multiple crew characters operating in the aircraft.

It does not necessarily support:

The maximum lobby size is four.

The number of visible characters is visual evidence, not a networking specification.

Unknown

The available first-party material does not answer the question.

Unknown is not an editorial failure. It is a valid and often valuable result.

Examples include:

• Exact launch date

• Maximum lobby size

• Cross-platform play

• Local split-screen

• Matchmaking rules

• Console versions

• Price

• Preload timing

A reliable tracker should be able to say “not announced” without attempting to fill the space.

3. Define a Source Hierarchy Before Collecting Data

Not all sources should be allowed to update all fields.

We established a hierarchy before building the publishing workflow.

Tier 1: First-party product records

Examples:

• Official Steam store page

• Developer website

• Publisher website

• Official platform store listing

• Official patch notes or announcements

These sources can directly confirm product-level facts.

Tier 2: First-party media

Examples:

• Official trailers

• Developer livestreams

• Official screenshots

• Developer social posts

These sources are strong evidence, but the type of claim matters. A screenshot can confirm that an object or scene was shown; it may not confirm the final implementation or availability of a feature.

Tier 3: Attributed interviews

An interview is useful when it provides:

• A named speaker

• A publication date

• A stable source URL

• Sufficient context

• A direct or accurately translated statement

Interview claims should retain the speaker, publication, date, and level of commitment.

“Planning,” “testing,” “targeting,” and “confirming” must not be normalized into the same status.

Tier 4: Secondary reporting

News sites, databases, community posts, videos, and wikis are useful for discovering leads.

They should not automatically become the final authority.

A secondary page that says “the developer confirmed a demo” should trigger a search for the original developer statement. If that original statement cannot be located, the claim remains secondary and should be labeled accordingly.

Tier 5: Search snippets, user tags, and speculation

These can be monitored, but they should never update a confirmed field.

Search snippets may be stale or truncated. User-generated Steam tags are not product specifications. Countdown sites may use placeholder dates. Trailer comments and forum posts may repeat each other without adding evidence.

Our practical rule is:

Discovery can begin anywhere. Confirmation must end at the strongest available source.

4. Model Release Information by Precision

One of the most common release-tracking mistakes is storing every date in the same field.

Consider these four statements:

• Planned for 2026

• Planned for Q4 2026

• Planned for October 2026

• Releasing October 15, 2026

They do not have the same precision.

A useful model separates the value from its granularity:

type DatePrecision =
  | "year"
  | "quarter"
  | "month"
  | "day"
  | "time";

interface ReleaseClaim {
value: string;
precision: DatePrecision;
status: "confirmed" | "attributed" | "unknown";
timezone?: string;
sourceUrl: string;
lastVerifiedAt: string;
}


The renderer can then choose language that matches the evidence:

function formatReleaseClaim(claim: ReleaseClaim): string {
if (claim.status === "unknown") {
return "An exact release date has not been announced.";
}

switch (claim.precision) {
case "year":
return Planned for release in ${claim.value}.;

case "quarter":
  return `Currently planned for ${claim.value}.`;

case "month":
return Currently planned for ${claim.value}.;

case "day":
return Scheduled for ${claim.value}.;

case "time":
return Scheduled to unlock at ${claim.value} ${claim.timezone ?? ""}.;

default:
return "Release timing is not yet available.";

}
}


This prevents a year-only announcement from being presented as an exact launch date.

It also makes later updates straightforward. When a day is announced, the system does not overwrite history. It creates a more precise claim and records the previous state in the update log.

5. Preserve Both the Current State and the History

A release tracker is not only a database of current answers. It is also a record of how those answers changed.

For every monitored field, we store:

• Current value

• Previous value

• Source URL

• Source type

• Verification timestamp

• Reviewer

• Change reason

• Publication status

A simplified update record might look like this:

{
"claimId": "public-demo-status",
"previousValue": "not-available",
"newValue": "available",
"detectedAt": "2026-09-12T08:14:00Z",
"verifiedAt": "2026-09-12T09:02:00Z",
"sourceUrl": "https://store.steampowered.com/app/...",
"reviewResult": "approved",
"changedPages": [
"/demo/",
"/status/",
"/",
"/ja/demo/",
"/zh-cn/demo/"
]
}

This history serves several purposes.

First, it makes corrections auditable. If a field changes unexpectedly, an editor can inspect where the new value came from.

Second, it supports dated reporting:

On September 12, the Steam page added a public demo download.

Third, it prevents silent contradictions. A release page, homepage status panel, translated page, and FAQ should not display four different values because they were edited independently.

6. Automate Detection, Not Editorial Judgment

Automation is useful for monitoring stable fields:

• Release-date text

• Demo button availability

• Supported platforms

• System requirements

• Supported languages

• Store features

• New announcements

However, automatically detected text should not immediately become published truth.

Store pages change for reasons unrelated to the product. Markup can be redesigned. A localization can differ from the English listing. A temporary response can omit sections. A tag can be added by users rather than the developer.

Our preferred workflow is:

1. Fetch the official source.

2. Extract a small set of monitored fields.

3. Normalize whitespace and formatting.

4. Compare the result with the last verified snapshot.

5. Create a review item if a meaningful field changed.

6. Require editorial approval.

7. Rebuild affected pages.

8. Record the update.

A simplified monitoring function could look like this:

interface Snapshot {
releaseText: string | null;
demoAvailable: boolean;
platforms: string[];
features: string[];
requirementsHash: string | null;
checkedAt: string;
}

async function inspectSteamPage(url: string): Promise<Snapshot> {
const html = await fetch(url, {
headers: {
"User-Agent": "ReleaseTracker/1.0 (+https://example.com/methodology)"
}
}).then((response) => {
if (!response.ok) {
throw new Error(Steam request failed: ${response.status});
}

return response.text();

});

return {
releaseText: extractReleaseText(html),
demoAvailable: detectOfficialDemoControl(html),
platforms: extractPlatforms(html),
features: extractOfficialFeatures(html),
requirementsHash: hashRequirements(html),
checkedAt: new Date().toISOString()
};
}


The comparison layer should distinguish between a meaningful change and a parsing failure:

function compareSnapshots(
previous: Snapshot,
current: Snapshot
): string[] {
const changes: string[] = [];

if (current.releaseText !== previous.releaseText) {
changes.push("release-text");
}

if (current.demoAvailable !== previous.demoAvailable) {
changes.push("demo-status");
}

if (!sameStringSet(current.platforms, previous.platforms)) {
changes.push("platforms");
}

if (!sameStringSet(current.features, previous.features)) {
changes.push("features");
}

if (
current.requirementsHash &&
current.requirementsHash !== previous.requirementsHash
) {
changes.push("system-requirements");
}

return changes;
}


A detected change should enter a queue rather than directly updating the public site:

if (changes.length > 0) {
await createEditorialReview({
source: "official-steam-page",
detectedChanges: changes,
previousSnapshot,
currentSnapshot,
status: "pending"
});
}

The goal is not to remove editors. It is to make sure editors review the right source at the right time.

7. Build Answers From Claims, Not From Handwritten Duplicates

The same fact often appears in many places:

• Homepage

• Release-date page

• Demo page

• Multiplayer page

• FAQ

• Status dashboard

• Wiki

• News report

• Structured data

• Six or more language versions

If every sentence is edited manually, contradictions are inevitable.

Instead, we use one claim registry and let components request the claims they need.

Conceptually:

const facts = {
releaseWindow: getApprovedClaim("release-window"),
publicDemo: getApprovedClaim("public-demo-status"),
playerCount: getApprovedClaim("maximum-player-count"),
platforms: getApprovedClaim("confirmed-platforms"),
multiplayer: getApprovedClaim("multiplayer-mode")
};

The homepage may render a short answer:

Release window: 2026

The release page can render a fuller answer:

Steam lists a 2026 release window. FLEXUS has not announced a month, day, unlock time, or preload schedule.

The FAQ can answer the user’s exact question:

When does Dear Passengers release?
The official Steam page currently says 2026. An exact date has not been announced.

These sentences differ in length, but they depend on the same approved claim.

When the source changes, all affected pages can be rebuilt from the updated record.

8. Answer Negative and Unknown Questions Explicitly

Some of the most valuable tracker pages answer questions for which there is no positive announcement.

For example:

• Is a demo available now?

• Is the game free to play?

• How many people can play?

• Is there a console version?

• Does it support crossplay?

Weak content systems often avoid these questions or fabricate a convenient answer.

A better response contains four parts:

1. The current answer

2. The evidence

3. The boundary of that evidence

4. The condition that would change the answer

For a public demo:

No public Steam demo is currently available. The official store page does not provide a demo download control. This does not prove that no private, event, press, or development build exists. The public status will change only when FLEXUS or an official platform publishes a downloadable build.

For player count:

Online co-op is confirmed, but the maximum crew size has not been announced. The number of characters visible in a trailer is not treated as a lobby specification.

For price:

The price has not been announced. A user-generated store tag is not considered confirmation of a free-to-play business model.

This structure is concise enough for players but precise enough to survive later updates.

9. Separate Official Facts From Editorial Interpretation

A useful guide must do more than repeat a store page. It should explain what the available material means.

That introduces interpretation.

Interpretation is acceptable as long as it is labeled.

For example:

Based on the confirmed gameplay loop, the game is likely to appeal to groups that enjoy communication under pressure, role specialization, physics-driven comedy, and recovering from failed plans.

That is a reasonable editorial analysis, but it is not an official promise from the developer.

The presentation should distinguish:

• Officially confirmed

• Visible in official media

• Developer-attributed

• Editorial interpretation

• Unknown

This distinction is especially important when describing trailers.

An official trailer may show a crew member serving food, another operating the aircraft, and loose cargo moving during turbulence. It supports a discussion of visible roles and physical interactions.

It may not confirm:

• Formal character classes

• The number of simultaneous players

• The final progression system

• Matchmaking behavior

• The complete event pool

• The final user interface

Words such as “shows,” “appears,” “suggests,” and “has not yet been explained” are not evasive language. They are precision tools.

10. Give Every Language Its Own URL

A multilingual tracker should not rely exclusively on browser-language detection or dynamically replace the text at one URL.

We use distinct URLs for language versions:

/
/release-date/
/demo/
/multiplayer/

/ja/
/ja/release-date/
/ja/demo/
/ja/multiplayer/

/zh-cn/
/zh-cn/release-date/
/zh-cn/demo/
/zh-cn/multiplayer/


Google recommends separate URLs for different language versions and supports hreflang annotations to connect those alternatives.

A typical English page can include:

<link
rel="alternate"
hreflang="en"
href="https://dearpassengerscrew.com/release-date/"
>

<link
rel="alternate"
hreflang="ja"
href="https://dearpassengerscrew.com/ja/release-date/"
>

<link
rel="alternate"
hreflang="zh-CN"
href="https://dearpassengerscrew.com/zh-cn/release-date/"
>

<link
rel="alternate"
hreflang="x-default"
href="https://dearpassengerscrew.com/release-date/"
>


The annotations must be reciprocal. If the English page points to Japanese, the Japanese page should point back to English.

The localized page also needs a self-referencing canonical:

<link
rel="canonical"
href="https://dearpassengerscrew.com/ja/release-date/"
>

Do not canonicalize every translation to the English page. Properly translated pages are distinct language resources, not disposable duplicates.

11. Translate Claims, Not Just Paragraphs

A multilingual site introduces a second consistency problem.

Even if the English page is correct, a translation can accidentally change the strength of a statement.

Consider:

A public demo is planned.

A careless translation might become:

The public demo will be released soon.

That introduces both certainty and timing that did not exist in the source.

We therefore separate translation into two layers.

Layer 1: Shared claim data

Values such as the following remain centralized:

{
"release_window": "2026",
"release_precision": "year",
"demo_status": "not_publicly_available",
"maximum_players": null,
"maximum_players_status": "not_announced"
}

Layer 2: Locale-specific rendering

Each language defines phrasing for those states:

{
"en": {
"release_year_only": "Planned for release in {year}.",
"demo_unavailable": "No public demo is currently available.",
"players_unknown": "The maximum player count has not been announced."
},
"ja": {
"release_year_only": "{year}年に発売予定です。",
"demo_unavailable": "現在、一般公開されたデモ版はありません。",
"players_unknown": "最大プレイヤー人数は発表されていません。"
},
"zh-CN": {
"release_year_only": "计划于{year}年发行。",
"demo_unavailable": "目前尚未提供公开试玩版。",
"players_unknown": "最大联机人数尚未公布。"
}
}

Long-form editorial content still requires human translation and localization. However, the key status answers should be generated from a constrained vocabulary so that their evidentiary meaning remains stable.

12. Do Not Publish Thin Translations

A page is not meaningfully localized just because the navigation, title, and status labels were translated.

Google’s documentation notes that pages whose primary content remains in the same language may still be treated as duplicates even if secondary interface elements are translated.

Each localized page should contain:

• A translated title

• A translated meta description

• Translated headings

• Fully translated main content

• Locale-appropriate date formatting

• Localized source explanations

• Translated image alternative text

• Translated disclaimers

• Correct internal links for that locale

• A language switcher that preserves the current page intent

A user reading the Japanese demo page should be sent to the Japanese multiplayer page, not back to the English site whenever an internal link is selected.

This can be enforced through locale-aware routing:

function localizedPath(locale: string, slug: string): string {
if (locale === "en") {
return /${slug}/;
}

return /${locale}/${slug}/;
}


The language switcher should map equivalent pages:

const alternates = {
en: "/release-date/",
ja: "/ja/release-date/",
"zh-cn": "/zh-cn/release-date/",
tr: "/tr/release-date/",
uk: "/uk/release-date/",
ar: "/ar/release-date/"
};

Switching languages should not send every user to the homepage.

13. Use Intent Pages Instead of One Oversized Article

Players search for distinct questions.

A single homepage cannot answer every intent clearly, particularly across multiple languages.

Our structure separates the most important topics:

• Release date

• Demo availability

• Multiplayer

• Maximum player count

• Platforms

• Gameplay

• Trailer

• Characters and crew roles

• System requirements

• News

• Wiki

• Source methodology

• Corrections policy

Each page has one principal job.

The release page explains:

• What date is confirmed

• What level of precision is available

• Which dates are placeholders or speculation

• What source would confirm a change

The demo page explains:

• Whether a public build is available

• Where a legitimate build would appear

• The difference between public, event, press, and development builds

• The risks of third-party downloads

The multiplayer page explains:

• Which modes are confirmed

• Which networking details remain unknown

• Why trailer headcounts are not treated as specifications

The pages can link to one another because player questions overlap, but each page maintains a clear evidentiary boundary.

14. Make the Source Visible to the Reader

“According to official sources” is not enough.

Readers should be able to identify:

• Which source was used

• What that source supports

• When it was checked

• Whether the source is first-party

• Which details remain unsupported

A compact source record can be displayed like this:

Source: Official Steam store page
Supports: Release window, Windows platform, play modes,
interface languages, minimum system requirements
Last verified: August 6, 2026
Does not confirm: Exact release date, price, maximum crew size,
console editions, crossplay

This is more useful than a generic list of links at the bottom of the page.

It tells the reader why the source matters and what it cannot prove.

15. Publish a Methodology and Correction Policy

A tracker asking readers to trust its verification process should explain that process publicly.

The methodology page should answer:

• Which sources qualify as first-party?

• How are interviews classified?

• How often are monitored pages checked?

• How are trailer observations labeled?

• How are translations reviewed?

• What happens when sources conflict?

• How can a reader report an error?

• Are corrections documented?

• Is the site affiliated with the developer?

A correction should not simply replace the old sentence without explanation when the previous information was materially wrong.

A minimal correction record can include:

{
"page": "/multiplayer/",
"correctedAt": "2026-08-06T12:00:00Z",
"previousStatement": "Supports up to four players.",
"replacementStatement": "The maximum player count has not been announced.",
"reason": "The previous statement inferred lobby size from trailer footage.",
"source": "Official Steam listing and trailer review"
}

Public corrections increase credibility because they show that the site is designed to improve rather than defend every earlier statement.

16. Be Conservative With Structured Data

Structured data should describe what the page and source actually support.

Schema.org provides a VideoGame type, but the presence of a field in a vocabulary is not permission to invent its value.

A conservative implementation might include:

<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "VideoGame",
"name": "Dear Passengers",
"url": "https://dearpassengerscrew.com/",
"gamePlatform": "Windows PC",
"operatingSystem": "Windows 10 (64-bit)",
"publisher": {
"@type": "Organization",
"name": "FLEXUS"
},
"author": {
"@type": "Organization",
"name": "FLEXUS"
},
"inLanguage": [
"en",
"ar",
"zh-CN",
"tr",
"uk",
"ja"
],
"sameAs": [
"https://store.steampowered.com/app/4534960/Dear_Passengers/"
]
}
</script>

Fields that are not confirmed should be omitted.

Do not create:

• An exact datePublished from a year-only window

• An offers price before a price is announced

• A console platform based on community requests

• An aggregate rating before reviews exist

• A maximum player count inferred from promotional artwork

Structured data is still a factual publication surface. It should follow the same claim rules as visible text.

17. Test for Contradictions, Not Only Broken Pages

A traditional site audit looks for:

• 404 errors

• Missing titles

• Invalid markup

• Broken images

• Slow pages

A release tracker also needs semantic tests.

Examples:

describe("release information consistency", () => {
it("does not display an exact date when precision is year-only", () => {
const claim = getApprovedClaim("release-window");

if (claim.precision === "year") {
expect(renderedSiteText()).not.toMatch(
/\bJanuary|February|March|April|May|June|July|August|September|October|November|December\b/
);
}

});

it("does not state that a public demo exists without an approved source", () => {
const demo = getApprovedClaim("public-demo-status");

if (demo.value !== "available") {
expect(renderedSiteText()).not.toContain(
"Download the demo now"
);
}

});

it("does not publish a maximum player count when the value is null", () => {
const count = getApprovedClaim("maximum-player-count");

if (count.value === null) {
expect(renderedSiteText()).not.toMatch(
/supports up to \d+ players/i
);
}

});
});


Additional multilingual checks should verify:

• Every localized page has a self-canonical

• Every hreflang relationship is reciprocal

• Each alternate URL returns a successful response

• The page language matches its locale

• Internal links remain inside the selected language

• Key claim statuses match across every locale

• Dates are formatted correctly for each language

• Right-to-left layout works for Arabic

These tests catch errors that a normal crawler will not recognize.

18. Case Study: Dear Passengers

The official Dear Passengers Steam listing currently provides a useful example of partial but meaningful information.

It confirms:

• A 2026 release window

• Windows PC requirements

• Single-player

• Online co-op

• FLEXUS as developer and publisher

• A minimum specification including Windows 10 64-bit, 8 GB RAM, and 4 GB of available storage

• Six listed interface languages

It does not currently confirm:

• Exact release month or day

• Unlock time

• Price

• Maximum crew size

• Crossplay

• Local split-screen

• Matchmaking details

• Console editions

• A public demo download

The official description also explains a clear gameplay premise: one player may pilot the aircraft while other crew members manage passengers, service, cargo, and escalating cabin problems. Weather, turbulence, air pockets, loose objects, and risky cargo create a connected cockpit-and-cabin loop.

This is enough evidence to produce a useful guide.

It is not enough evidence to answer every player question with a number or date.

The most important product decision was therefore not adding more words. It was making the boundary between known and unknown visible.

19. What We Learned

Several principles from this project are applicable to any unreleased game tracker.

Unknown is a publishable result

Readers benefit from knowing that a feature has not been announced, especially when other pages present guesses as facts.

Precision should be stored, not implied

A year, quarter, month, day, and unlock time are different data types from an editorial perspective, even if they all describe release timing.

Monitoring should create review work, not bypass it

Automated comparison is excellent at detecting change. It is poor at determining whether a change is authoritative, temporary, localized, or user-generated.

Every translated page is another factual surface

A claim corrected in English but left unchanged in Japanese or Chinese is still incorrect.

Official media supports observation, not every specification

A visible feature can be described as visible. It should not automatically become a promise about final scope or technical limits.

A correction policy is part of the product

Trust is not created by never making mistakes. It is created by making the evidence visible and correcting errors transparently.

The source model matters more than the page design

A polished page built on unstructured claims will eventually contradict itself. A strong evidence model can support many designs, languages, and tools without losing factual control.

Conclusion

Building a release tracker for an unreleased game is not primarily a scraping task or an SEO task.

It is a provenance problem.

The system must know:

• What is being claimed

• Who originally said it

• What type of evidence supports it

• How precise the information is

• When it was last checked

• Which pages and languages depend on it

• What should happen when the source changes

Once those rules are represented in the data model, the rest of the site becomes easier to manage.

Release pages can distinguish a year from a date. Demo pages can distinguish a public build from a development plan. Multiplayer pages can distinguish visible characters from an announced lobby limit. Translations can preserve the same level of certainty instead of introducing stronger claims.

The result is not a site that always has every answer.

It is a site that can show exactly which answers are available, where they came from, and where the evidence ends.

That is a more durable foundation for covering any game before release.

References

1. Official Dear Passengers Steam Store Page
   https://store.steampowered.com/app/4534960/Dear_Passengers/

2. Dear Passengers Crew — Independent Source-Verified Guide
   https://dearpassengerscrew.com/

3. Google Search Central — Managing Multi-Regional and Multilingual Sites
   https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites

4. Google Search Central — Canonicalization
   https://developers.google.com/search/docs/crawling-indexing/canonicalization

5. Schema.org — VideoGame
   https://schema.org/VideoGame