The property that makes the count assertable is slug stability. English slugs stay unchanged behind the `/id/`, `/it/` and `/pt-br/` prefixes, so every locale carries the identical 169 routes and the total is a multiplication rather than a discovery [4][5]. A crawler-built static export cannot state its target before it runs. It enumerates whatever the navigation happens to link, so a link lost in a refactor removes a page from the build without an error [6].
The fail-the-build rule has a seam in it. Each non-English locale supplies 165 documents: 153 games, eight categories, four site/legal pages [9]. That is four short of the 169 routes that locale serves [20]. The four without documents are home, popular, new and search, which are assembled from card data rather than Markdown [20]. Across the three non-English locales that leaves twelve indexable routes the missing-content check cannot reach [22]. What covers them is a different assertion in the post-build verifier, which checks all 676 files for unresolved message keys alongside `html lang`, canonical, the four hreflang entries plus `x-default`, Open Graph locale, Schema language, and known English section headings on non-English pages [12]. Two failure modes, two guards, and only one of them is visible if you reason from the document count.
The cost lands on scheduling. All 495 localized Markdown files have to be complete before anything ships, because a missing Italian objectives field is a build error rather than an English fallback [9][8][10]. The English pages fail with it, which is one way to keep everyone interested in the translation queue. The author's stated reason for accepting that is narrow and worth quoting on its own terms: a visible fallback is useful in application chrome and dangerous when it produces a page advertised to search engines as a different language [8].
Two preconditions decide whether the arithmetic transfers. Slugs must not be localized [4]; translate them and the route list is still derivable from the catalog, but each locale needs its own slug table and the expected count has to be computed per locale instead of multiplied. Second, facts have to sit outside the translation surface. Titles, iframe URLs, developers, dates, embed types and slugs are treated as product facts, while descriptions, objectives, controls, tips, category copy and legal text are the localized fields [11], and fact drift, missing keys, extra slugs or duplicates fail the build [10].
The payload half of the design is argued from mechanism, not measurement. Importing the full game object into a shared composable can put the entire catalog into a client chunk, so a build step projects a card record limited to the fields grids and search use, while the detail route receives one game during prerendering [15][16]. The post gives no build duration for 676 routes and no measured bundle size for the slim record against the full one [24]. The leak test that would demonstrate the projection holds is described only as far as "Add a leak test with a known" before the text ends [23].
Where the route set is enumerable from a database, deriving it costs one build step and buys a number the build can fail on when the verifier sees 675 [13]. For a catalog whose pages exist whether or not a nav component currently links them, that is worth more than the crawler's convenience.
