Bcp 47 Code Laravel Package

Product Decisions This Supports

• Localization feature scoping. If the roadmap includes multilingual content, per-user locale preferences, translated routes, or hreflang emission, this package supplies the primitives: an immutable BCP 47 value object, canonical case normalization (language lowercase, script titlecase, region uppercase), and semantic equality checks instead of brittle string comparison at every call site.
• Build vs. buy on a deceptively fiddly problem. Canonicalization and comparison of language tags looks like a five-line helper and isn't — casing rules, deprecated tags, and MediaWiki's non-standard codes (simple, be-tarask, zh-hant) are where homegrown helpers rot. This is a small buy: one class plus one interface, no transitive dependency weight.
• MediaWiki/Wikimedia integration decisions. This is the package's genuinely differentiated capability: converting between MediaWiki-internal language codes and standards-compliant BCP 47. If a feature touches Wikidata labels, Wikipedia language editions, or a MediaWiki API, this removes a whole category of mapping bugs. If it doesn't, most of the value evaporates.
• Incremental migration strategy. Because the library exposes an interface (Bcp47Code) alongside a concrete value object, it can be introduced behind existing string-typed language fields and widened call-site by call-site, rather than as a flagged rewrite. That's a cheap architectural bet to approve.
• Dependency posture as a decision. Adoption signal is essentially zero (1 star, 0 dependents, mirror-only), and the license is GPL-2.0. That makes this an "evaluate and possibly vendor" input, not a "standardize on it" input. A PM should expect to fund a short spike, not a mandate.
• Use cases worth naming: SEO hreflang generation, locale-preference storage with canonical values, translation workflow keys, content-negotiation downstream of an Accept-Language parser (note: parsing is not in scope here), and any code path that currently compares 'en-US', 'en-us', and 'en_US' inconsistently.

When to Consider This Package

Adopt (or, more realistically, pilot) when:

• You are already in or adjacent to the MediaWiki ecosystem and need MediaWiki-code ↔ BCP 47 conversion.
• You want a zero-configuration, framework-agnostic value object with an interface suitable for DI and test doubles in a Laravel service container.
• Your team would otherwise hand-roll language-tag normalization, and you'd rather not own that correctness burden.
• Your legal posture tolerates GPL-2.0, and you accept that issues and PRs flow through Gerrit, not GitHub — the GitHub repo is an explicit mirror.
• The blast radius is small and containable: if the package stalls, you can vendor the class or replace it in an afternoon.

Look elsewhere when:

• You need actual language negotiation or Accept-Language parsing — use Symfony's HTTP foundation or a dedicated negotiation library.
• You need CLDR-grade data: display names, likely subtags, language matching, fallback chains — reach for symfony/intl, ICU, or a locale-data package.
• You need Laravel-shaped ergonomics — service provider, validation rule, config publishing, Eloquent cast. None of that ships here; you'd build and maintain it yourself.
• You are shipping closed-source or commercially licensed software and GPL-2.0 is a non-starter for your legal team.
• You need community support, security response SLAs, or an issue tracker you can rely on. One star and zero dependents is a meaningful signal about the support surface, regardless of the maintainer's pedigree.
• You don't need MediaWiki interop at all — in which case the remaining value is small enough that a first-party value object with tests may be the more honest build decision.

How to Pitch It (Stakeholders)

To executives: This is a micro-dependency that prevents a recurring class of internationalization defects — mismatched language tags silently breaking translations, redirects, and SEO metadata. Cost is trivial; strategic weight is also trivial. Recommend a bounded spike, not a platform commitment.

To engineering: It gives you an interface plus an immutable, canonically-normalized language-code value object, which lets us stop passing raw strings that mean subtly different things. Integration is manual — no Laravel service provider, no validation rule, minimal docs — so we'd own the wiring and the Eloquent cast. Two caveats to weigh: the license is GPL-2.0, and the GitHub repo is a mirror of Wikimedia's Gerrit, so upstream contributions and issue triage follow MediaWiki process. Treat it as vendor-able code with a small surface, not as an unowned dependency to add casually.

Framing the risk honestly: The package's utility is real and its ecosystem traction is not. That combination argues for a time-boxed evaluation with a vendoring escape hatch written into the plan, rather than either dismissal or adoption at scale.