Language Field Type Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. This field type gives content editors a language/locale selector inside the Streams/PyroCMS admin UI. It supports the narrow but real decision of how editors tag content with a language — a prerequisite for any multi-language content model, URL strategy, or hreflang implementation downstream.
• Build vs. buy for small admin primitives. At ~0 stars, 0 dependents, and a single-vendor origin, the honest framing is "buy" = a trivial dependency, "build" = a few hours of engineering. This package is a data point for the decision not to build bespoke field types when the platform already exposes an extension point.
• Extensibility posture on the Streams Platform. Adopting it signals a commitment to the field-type addon architecture rather than forking core or hardcoding locale lists into templates. That informs whether the team invests in addon governance (version pinning, private registry, upgrade runbooks).
• Content operations use cases it unlocks: assigning a locale to a page/entry for editorial routing, driving language-switcher menus, scoping sitemaps, and validating that every locale has coverage before launch.
• Vendor concentration risk. With zero external dependents and low activity signal, this should trigger a "who maintains this if AnomalyLabs stops?" decision — likely resolved by vendoring the source into the repo rather than requiring it from Packagist.

When to Consider This Package

Consider it when all of the following hold:

• You are already running PyroCMS 3.x / the Anomaly Streams Platform — this is a field type addon, not a standalone library, and has no value outside that host.
• You need a locale/language selection control bound to an entry field, and you want it to behave like every other field type (assignment, validation, migration, API output) rather than a one-off select.
• Your i18n requirement is "tag content with a language", not "translate content." It stores a language reference; it is not a translation workflow, fallback resolver, or content-localization store.
• You are comfortable pinning to a commit and auditing the source — MIT license makes vendoring clean, and the low activity means you should assume you own the code once adopted.

Look elsewhere when:

• You are not on PyroCMS/Streams. There is no standalone use; use symfony/intl, a laravel-validation in: rule, or a plain enum-backed select instead.
• You need per-field translation, fallback chains, or translation memory — that is a different product category (e.g., dedicated translation management, or Laravel's own spatie/laravel-translatable style approach).
• You need vendor support, SLAs, or a demonstrated maintenance cadence. Zero dependents and near-zero community signal means no ecosystem safety net.
• You are on a modern Laravel/PHP target and haven't verified compatibility — the addon ecosystem around PyroCMS 3 is version-sensitive; validate against your framework version before committing to it in a roadmap.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed UI component from the PyroCMS vendor that lets editors tag content with a language. It is not a translation system and not a strategic dependency — it is a convenience addon with effectively no adoption outside its own ecosystem. Treat it as low-cost, low-risk, and low-leverage: approve it only as part of an existing PyroCMS footprint, and plan to vendor the source rather than rely on upstream maintenance.

For engineering: It's a Streams Platform field type that surfaces a language selector for entry fields, plugging into the standard field-type contract so it gets assignment, storage, and API output for free. The trade-off is maintenance: zero external dependents and minimal activity means we own upgrades. Recommendation is to fork/vendor under our control, pin the version, and add a smoke test around locale persistence. If the i18n requirement grows past "tag with a language," we should stop extending this and evaluate a proper translation layer instead.