Traducir es también verificar
Blupoli Puzzles already had Spanish and English as its base languages, while Italian, Portuguese, French and German had been prepared as candidates. The obvious temptation was to activate all four as soon as their translation structures looked complete. We deliberately chose not to.
The new languages first lived in a candidate state. They had interface dictionaries, taxonomy, SEO data, game content, dynamic controls and an initial editorial layer, but they were not treated as published versions until review and QA were complete.
Candidate status as a safety belt
Separating candidate locales from published locales let us build a complete version without exposing it too early. Public routes, hreflang, the sitemap and the language selector should only promise what is genuinely ready.
It also prevented a common form of localization debt: publishing a language at eighty percent, forgetting about the missing parts and living with mixed-language screens for months.
The historical catalogue made rules critical content
The original article recorded 73 games at that moment. That is a dated September 14, 2026 snapshot rather than a current catalogue count. At that scale, rules become a large and sensitive content surface.
In a store or blog, a slightly awkward phrase may be an editorial problem. In a puzzle, one wrong word can change the rule. We therefore distinguished domains: shell and taxonomy could accept assisted review, while rules, help and mechanic-sensitive onboarding required stricter semantic review.
The pipeline itself needed auditing
We found a paradox during this work: the translation checker only traversed already-published languages. That excluded exactly the candidates we needed to validate before publication. Strict mode had to be changed so it could audit Italian, Portuguese, French and German while they remained candidates.
We also found an editorial build issue. A later translation stage could overwrite a page after the language selector had been injected, producing translated content without the control required to switch language. The pipeline had to preserve that navigation contract.
Fallbacks have to be honest
Not every editorial article would be translated at the same time. Instead of manufacturing duplicate localized pages, indexes could point to the Spanish original and make the fallback explicit.
Partial coverage should not become fictional coverage. A localized URL should represent genuinely localized content.
Why Italian came first
The historical activation plan was sequential: Italian, then Portuguese, French and German. Releasing one at a time reduced blast radius and let us validate the entire process before repeating it.
If Italian exposed a routing, build or data problem, we could fix the pipeline once before multiplying the issue across three more locales.
What being ready actually meant
A page merely loading was not enough. The selector had to preserve context, internal links needed to stay in the active language, game surfaces could not mix Spanish labels, canonical and hreflang had to represent real versions, the sitemap had to match public state and mobile layouts had to survive longer copy.
Statistics added another important case: translating the heading was not enough if game names or categories still came from a Spanish-only generated catalogue. Dynamic data is part of localization too.
AI accelerates; the gate decides
AI made it possible to prepare substantial amounts of content, find missing keys and maintain structural parity faster. That speed did not remove semantic risk.
The workflow therefore preserved origin and review state. The faster generation became, the more important it was to know what had actually been validated.
What came next
The next step was deliberately unglamorous: compare rules and help against each game's source, correct semantic drift, run strict technical gates and perform real QA on Italian. Only then would it move from candidate to published, followed by the other candidates through the same path.
If that process worked, the valuable outcome would not simply be six languages. It would be a safe, repeatable way to add the seventh.
Publishing a locale changes a contract, not a directory
The candidate-versus-published distinction only works when every availability surface obeys the same state. The selector, generated routes, hreflang, sitemaps, indexes and catalogue should derive from one source of truth. If each layer maintains its own language list, one version will eventually appear in one place and disappear in another. Publishing Italian means asserting that navigation, rules, runtime data, SEO and accessibility are ready for a real journey.
The experience has to keep its language across the whole journey
A perfect Italian home page is not enough if a category sends the player back to Spanish, statistics use a base-language catalogue or the language selector always returns to the home page. Useful QA follows complete journeys: enter through a localized route, discover a game, open help, inspect statistics, switch language and navigate back. Every transition can lose context; localization belongs to the navigation graph.
Automatic detection should be an initial hint, not a permanent command
Browser language is useful when somebody has not expressed a preference. Once they explicitly choose another locale, that choice should usually win. Reapplying negotiation on every visit makes the selector feel cosmetic. Separating “suggested language” from “chosen language” also makes behaviour across Blupoli surfaces easier to understand while each application resolves its own localized paths.
A localized URL should remain reproducible when shared
If somebody copies an Italian page and another person opens it from a French-configured browser, the URL should still represent the requested Italian edition. Depending entirely on implicit negotiation makes language change when the link travels and complicates support, debugging and SEO. Localized paths expose the requested representation and make reports reproducible.
Caching can manufacture bugs that look linguistic
A multilingual deployment does not end when HTML is generated. If a cache serves new markup with older scripts or catalogue data, users may see a current selector running old routing logic or a French page reading Spanish names from the previous generation. Versioning, invalidation and predictable revalidation therefore belong to the i18n contract even though they never appear in a translation file.
Dynamic data forces us to follow text back to its source
Translating visible components can create a false sense of coverage. A statistics card may have correct labels while displaying a Spanish game title because the value comes from a catalogue generated only in the base language. Stable identity underneath and localized presentation above solve that problem. This architecture is explored in our internationalization deep dive.
Generated clues should exist as meaning before sentences
Puzzles that create text at runtime are especially demanding. If the engine emits a Spanish sentence directly, another layer has to reconstruct meaning before translating it. A safer design produces a structured relation first and lets each locale decide how to say it. The Einstein Riddle engine shows the distinction clearly.
Rules, consent and accessibility are high-risk content domains
Not every string deserves the same review threshold. An awkward promotional sentence is an editorial issue. An ambiguous rule can change the puzzle. A wrong aria-label can make a control inaccessible. Poorly localized consent text can prevent an informed privacy choice. A single coverage percentage hides those differences, so quality gates need to know which domains are critical.
Editorial fallbacks must be explicit and honest
Supporting a locale at product level does not mean the entire historical Blog must be translated immediately. Creating a German route that simply repeats Spanish copy only to complete a matrix produces fictional parity. It is better to link to the original, identify its actual language and publish a localized edition only when one genuinely exists.
Hreflang and sitemaps should describe reality
Hreflang is not a list of languages we hope to support; it describes real equivalents. The sitemap should not advertise incomplete localized pages merely because a directory exists. Both signals should derive from public locale state and actual content availability, so SEO expresses the same product truth as navigation rather than maintaining a parallel configuration.
Accessibility expands what the localization gate must remember
Alt text, aria-labels, screen-reader announcements and accessible control names can disappear from visual review while remaining essential language. A French page with Spanish assistive labels is only partially localized. Automated checks can catch missing values; human review still has to judge naturalness and meaning.
Observability needs locale context
An error that only happens on a Portuguese route can look intermittent if technical telemetry does not preserve locale. Recording that context alongside route and version can make the problem reproducible without collecting unnecessary personal information. Localization then becomes part of debugging as well as editorial work, allowing teams to distinguish global regressions from localized failures.
Rollback and publication should be reversible
A translation existing in the repository does not mean it must remain publicly announced if a serious issue appears. Separating existence from publication lets us withdraw a locale from selectors and public signals while keeping the work available for repair. Candidate and published are operational states that can change as evidence changes.
The suite should combine structural coverage with representative journeys
There is little value in running every test six times blindly. Structural checks can verify keys, routes and catalogues across all locales, while a smaller set of end-to-end journeys exercises areas where composition often fails: switching language, long copy, runtime data, fallbacks and contextual navigation. Historical bugs should become regression tests as well.
A glossary and documentation turn decisions into memory
Terms such as region, clue, edge, candidate, loop and adjacent appear in rules, onboarding and editorial content. Solving every occurrence independently creates drift. A shared glossary helps humans and agents, but it needs ownership and permission to evolve. Incidents discovered during candidate work should also become documented rules and checks.
Shared UI reduces the number of places policy can diverge
A common header, selector or preference control does not translate the product, but it prevents the same language policy from being reimplemented differently across surfaces. The shared UI system becomes more valuable when locale, navigation and persistence belong to component contracts. Real differences can be configured; accidental ones stop multiplying.
Onboarding needs semantic review, not just linguistic review
A tutorial can have every button translated and still teach the mechanic incorrectly. The example state, guided action and sentence have to agree. The profile-based onboarding system helps by separating shared behaviour from mechanic-specific, localizable content. The goal is the same rule taught naturally, not literal sentence parity.
The historical state of this article must remain correct
Updating the current brand to Blupoli should not erase that Italian, Portuguese, French and German were still candidates on September 14, 2026. Describing them as already public would flatten the sequence this article documents. The follow-up, From candidates to published, records the later transition.
The real goal was to make the seventh language a known problem
Preparing four candidates had immediate value, but the deeper result was a repeatable process. Another language would still require translation, review and QA. It should not require reinventing routing, SEO, catalogues, fallbacks and publication criteria. A mature multilingual platform can explain what ready means and prove it without lowering the standard.
Build order is part of the localization contract
The overwritten language selector exposed a broader lesson: several scripts can each be correct in isolation and still compose into the wrong result when they run in the wrong order. An editorial stage that rewrites HTML after navigation has been localized can silently remove controls, metadata or accessibility attributes. Every transformation therefore needs explicit ownership: what it may change, what it must preserve and which invariants later checks verify. The pipeline stops being an accidental sequence of scripts and becomes an auditable composition of responsibilities.
Regional formatting belongs close to presentation
Dates, numbers, percentages and plural forms can share the same meaning while appearing differently in each locale. Storing a date already formatted as Spanish text and transforming it later mixes domain and presentation and makes validators fragile. A safer model keeps a stable value and applies locale-aware formatting at render time. Then a visual improvement cannot alter identity or chronology. The same separation prevents punctuation or pluralization fixes from breaking tests that were actually intended to validate another property of the content.
Assets need a language strategy too
Not every visual resource should be duplicated for each locale. A semantic diagram with no embedded copy can be shared safely, while a screenshot containing instructions or an illustration with baked-in text may need a localized version. Duplicating everything creates weight and maintenance; sharing everything creates mixed-language pages. The useful question is whether the asset carries linguistic meaning. Whenever possible, text-free explanatory graphics combined with localized alt text and captions offer reuse, accessibility and editorial coherence without creating six visual pipelines for the same idea.
Document titles, notices and notifications count as language surfaces
A page can look perfectly localized while the browser tab title, a confirmation message or a notification remains in the base language. These are small surfaces, but they are highly visible because they appear as the user changes context. Locale readiness should include them whenever the product exposes them. A practical rule is simple: if the user can read it, it belongs to the localization system even when it is not inside the primary component or visible in a standard QA screenshot.
Localized search needs real vocabulary, not only official titles
Translating the canonical title of a puzzle does not guarantee that people can find it. Some games have alternate names, traditional terminology or descriptive phrases that vary by language. Search can index localized synonyms while resolving every result to one stable game ID. That lets search, saved sessions and statistics share identity while each locale supports natural discovery. Mature internationalization goes beyond replacing strings; it also understands how people in each language describe and look for the same concept.
Human review should focus on mistakes that look deceptively correct
Obvious failures are usually easy to spot. More dangerous are grammatically smooth translations that change a restriction, choose a plausible but mechanically wrong term or blur the difference between “exactly” and “at least.” Rules therefore deserve review against actual game behaviour rather than only against another text. Not every string needs identical scrutiny. The useful approach is risk-based: identify where a small wording shift can change the mechanic and spend more editorial attention there.
Sequential activation makes the first release cheaper to learn from
Italian was historically first because we needed one complete journey through the entire pipeline. If that release exposed a canonical, dynamic-catalogue, caching or contextual-navigation issue, fixing it before enabling Portuguese, French and German reduced blast radius. Sequential publication turns one large migration into a series of controlled releases with shared criteria. It does not rank languages. It creates a risk strategy that lets the team learn once before repeating the same operation across the remaining candidates.
The final checklist should measure the product, not the feeling of progress
“Almost everything is translated” is not a publication criterion. A useful checklist makes the complete contract visible: structure, semantic review, final build, routes, canonical, hreflang, sitemap, mobile layout, accessibility, dynamic data, selector behaviour, error states and fallbacks. Some checks are automated and some require judgement. What matters is that the decision can be explained and repeated. Publication then rests on evidence rather than optimism, memory or pressure to finish.
Candidate status gives the product a precise way to say “not yet”
The i18n architecture is not only a mechanism for releasing faster. It is also a mechanism for stopping a release with specificity. If a rule still needs review, a journey loses locale or an alternate points at content that does not exist, candidate state says the work is available for evaluation but not worthy of a public promise. That becomes especially valuable when AI accelerates production: generating much faster only helps if the system can block incomplete work just as decisively.
Documentation turns incidents into operational memory
The checker that ignored candidates, the overwritten selector and dynamic Spanish data should not remain anecdotes. Each useful incident should become a rule, test or architecture note that the next change can consult. That reduces dependence on personal memory and gives humans and agents the same context. A mature platform reuses not only code but also the decisions that explain why the code and its gates exist in the first place.
Locale-aware content ownership should be visible during feature work
When a new feature introduces public text, somebody needs to know whether that copy belongs in the shared dictionary, a game manifest, editorial content or a runtime formatter. Ambiguous ownership is how strings escape the localization system. Making the content domain explicit during implementation reduces later cleanup and gives reviewers a clear place to check coverage. Internationalization works best when responsibility is decided at creation time rather than discovered after the feature is already “done.”
Dynamic content QA needs examples that exercise the hard cases
It is not enough to verify a localized catalogue with the shortest title and simplest category. QA should include long game names, plural forms, generated clues, empty states and values that force line wrapping. These examples stress the places where runtime data and layout meet. A representative fixture library can make those cases reproducible across locales and prevent a comfortable default example from hiding problems that only appear with real content.
Product history improves when intermediate states remain visible
This article matters precisely because it documents the moment before six-language publication. Rewriting it as though everything had already been solved would erase the evidence for why candidate status and quality gates were necessary. Preserving chronology lets From candidates to published read as a consequence rather than a magical jump. Editorial history is more useful when it keeps the uncomfortable intermediate states that explain how the final result was reached.
The deeper goal was to make the seventh language a known problem
Preparing four candidates had immediate value, but the deeper outcome was a repeatable process. Another language would still require translation, review and QA. It should not require reinventing routing, SEO, catalogues, assets, fallbacks and publication criteria. A mature multilingual platform is not the one with the most locale folders. It is the one that can explain what ready means, prove it end to end and repeat the path without lowering the standard.