LEVIATHAN LOCALIZATION

One product.
Many languages, one workflow.

Language requests and translation issue reports are now tracked through Leviathan accounts. Actual product strings remain governed through one canonical translation workflow so launcher, client, website and support terminology do not drift apart.

TRANSLATION PIPELINE

From source string to release.

Community input belongs at the edges of the workflow. Approved product translations should still move through one reviewed, versioned source of truth before release.

1

Source strings

Version-controlled strings flow from the product into the translation workspace with stable keys and context.

2

Translate

Contributors work with screenshots, glossary terms, placeholders and product-specific context.

3

Review & QA

Reviewers check meaning, terminology, length, punctuation and placeholder safety before approval.

4

Release

Approved strings return through source control and CI so each product version receives the correct translations.

LANGUAGE REQUEST

Tell us what language is missing.

Language requests help measure demand and contributor interest. A request does not automatically create a release language until the translation workflow, maintainers and quality coverage are ready.

Checking your Leviathan account...

GOVERNANCE

Consistency across every surface.

Leviathan should translate concepts, not just individual strings. Shared terminology keeps the same feature understandable across launcher, client, website, support and documentation.

Glossary

Product terminology

Names for ranks, account states, error concepts, Minecraft linking, migration and launcher features stay consistent across products.

Context

Screenshots and usage notes

Translators should know whether text is a button, heading, tooltip, error or long-form explanation before choosing wording.

QA

Machine-checkable safety

Placeholder, line-length, punctuation and formatting checks catch avoidable problems before approved strings reach a release.