Langconv Laravel Package

Product Decisions This Supports

• Multilingual/multi-script feature scoping. LangConv is the engine behind MediaWiki's language variant conversion — the mechanism that renders one canonical article body as Simplified vs. Traditional Chinese (zh-hans, zh-hant, zh-hk, zh-tw, zh-cn, zh-sg, zh-my), or Serbian Cyrillic vs. Latin (sr-ec/sr-el), plus several smaller-script cases (Kazakh, Kurdish, Uzbek, Mongolian, Tachelhit). If your roadmap contains "one content body, many script renderings," this is the buy-side option to evaluate against building your own mapping layer.
• Build vs. buy on a genuinely hard problem. Chinese variant conversion is not a character table: it needs one-to-many character mappings, phrase- and context-level rules, locale-specific exception lists, and a rule syntax for editors to override conversion inline. Reimplementing that is a multi-quarter effort with ongoing native-speaker maintenance. Adopting a Wikimedia-maintained engine is the cheap path — if the licensing and integration costs clear.
• Architecture decision: engine vs. data. Critically, this package is the converter, not the dictionary. The bulk of production-grade conversion rules lives in MediaWiki core's language data, not in this library. So the real decision isn't "add a Composer dependency," it's "commit to curating and versioning conversion tables." Price that in before you put the feature on the roadmap.
• Content authoring and editorial workflow. Adoption implies a decision that authors write in one variant and the system derives the others, with an override syntax for exceptions. That changes CMS/editor requirements, review workflows, and who owns linguistic QA.
• Localization surface beyond UI strings. Laravel's i18n stack (translation files, __(), pluralization) solves UI copy; it does nothing for user-generated or long-form content in multiple scripts. LangConv fills a gap your existing tooling doesn't cover — worth naming explicitly so it isn't confused with "we already do i18n."
• SEO and discoverability decisions. Whether to serve distinct variant URLs (and hreflang) vs. converting on the fly is a product/SEO call that this engine enables but does not make for you.

When to Consider This Package

Adopt it when most of the following hold:

• You have a hard requirement for Chinese Simplified↔Traditional (or Serbian Cyrillic↔Latin) rendering of the same content, not separate authored locales.
• Your application is GPL-2.0-compatible, or you can isolate the library behind a process boundary / CLI so copyleft doesn't reach your proprietary code. GPL-2.0 is the single biggest gating item here — for a closed-source SaaS, treat this as a blocker until legal signs off.
• You are prepared to own the rule data: source, version, and test conversion tables independently of the package.
• You accept a non-idiomatic integration: no Laravel service provider, no config publishing, no facades. Expect to write a thin wrapper, manage rule-table loading/caching yourself (parsing rule tables is not free — plan a build/compile step or cache), and pin versions carefully since the canonical repo is Gerrit, not GitHub.
• You value provenance over ecosystem signals. The GitHub repo is a low-signal mirror (2 stars, 0 dependents); the actual consumers are MediaWiki itself. Judge it on upstream maintenance by Wikimedia, not on Composer popularity.

Look elsewhere when:

• License hygiene is non-negotiable — evaluate ICU/CLDR transliteration via PHP's intl extension, OpenCC (typically invoked as a CLI/binary, Apache-2.0), or commercial MT APIs.
• You need a drop-in Laravel package with config, Blade directives, middleware for locale negotiation, and cache integration. This gives you an engine and expects you to build the rest.
• Your conversion needs are per-string transliteration (names, addresses, search normalization) rather than whole-document variant rendering — ICU handles that with far less ceremony.
• You only need two or three locales with a small, stable vocabulary. A curated mapping table plus human review may be cheaper than a rule engine and its operational overhead.
• You cannot commit ongoing native-speaker QA. A converter that silently produces wrong-but-plausible text is worse than no converter, especially in Traditional Chinese where one-to-many mappings are common.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is Wikimedia's battle-tested engine for showing the same content in different writing scripts — most importantly Simplified and Traditional Chinese, a market of well over a billion readers where "translate once, render twice" materially cuts content cost and time-to-market. The engine itself is free and maintained upstream by the foundation behind Wikipedia, so we avoid rebuilding a linguistically subtle system from scratch. Two caveats drive the decision: it is GPL-2.0 licensed, which needs legal review before we ship it in a commercial product, and it provides the conversion engine but not the conversion dictionaries — we'd own curating and testing those. Recommendation: treat it as a scoped spike, not a default dependency, and gate adoption on license clearance plus an estimate for rule-data ownership.

For engineering (the practical framing): It's a PHP library, installable via Composer, that takes a rule set plus variant definitions and converts text between script variants. There is no Laravel integration — we build the service provider, config, and caching, and we should expect rule-table parsing to be the performance hot spot, so plan to precompile/cache rather than parse per request. Upstream lives on Gerrit (the GitHub repo is a read-only mirror), which affects our contribution path and how we track releases. The conversion data we need for real quality is not in this package; it comes from MediaWiki core's language data, so we'd vendor and version that separately. Give it a timeboxed evaluation: license check, a spike converting a representative content sample, and a measurement of cold/warm load cost. If it clears, it saves us from writing a converter; if it doesn't, ICU/CLDR or OpenCC are the fallbacks.