Formtranslationchoice Bundle Laravel Package

Product Decisions This Supports

• Clarifies a real requirement: localized choice labels. The underlying need—rendering select/radio/checkbox options whose labels come from translation catalogs rather than hard-coded strings, while validating the submitted value against the allowed key set—is a genuine product requirement for any multi-locale form (country pickers, plan tiers, salutation fields, category filters).
• Build vs. buy: build. This is a Symfony 2 bundle; our stack is Laravel. There is no adoption path, so the decision it informs is "how do we implement translated choice fields in Laravel," and the answer is our own small abstraction (a validation rule backed by a translation-key whitelist, plus a helper/formatter for label rendering). The package is useful as a specification of the behavior, not as a dependency.
• Roadmap input for i18n work. If the roadmap includes locale expansion, treat "translated enum/choice fields" as a first-class, testable requirement rather than an afterthought—validate the key, not the translated label, so validation stays locale-independent and cannot be broken by a copy change.
• Risk triage / tech-debt review. Any pre-existing Symfony 2 code in the org that depends on this pattern is a liability (archived repo, Symfony 2 is long EOL, zero dependents). Flag it for migration rather than maintenance.
• Use cases worth cataloging: multi-language signup/checkout forms, admin-managed category pickers, regulatory dropdowns (e.g., country/region), and any field where marketing owns labels but engineering owns allowed values.

When to Consider This Package

Consider it only under narrow, mostly historical conditions:

• You maintain a Symfony 2.x application (unsupported since 2018) and are not yet able to migrate; even then, prefer vendoring or reimplementing over depending on an archived, 10-star, zero-dependent bundle.
• You want a reference implementation of the "translation-domain-backed choice + validation constraint" pattern to port into Laravel—read the source, don't install it.

Look elsewhere or build in-house when:

• You are on Laravel. This bundle provides no Laravel service provider, facade, or config integration; there is nothing to composer require into a Laravel app. Laravel's equivalent is straightforward: Rule::in(array_keys(config('choices.plans'))) plus __('choices.plans.basic') for labels, with translations in lang/{locale}/choices.php.
• You need maintained dependencies. Archived status means no security patches, no PHP 8.x/8.3/8.4 compatibility guarantees, and no support for modern Symfony. Stars and dependents (10 / 0) indicate effectively no community validation.
• You need anything beyond a static choice list—dynamic/DB-driven options, dependent/cascading selects, searchable selects, or per-locale option filtering. This package does not address those, and no maintained fork exists to extend.
• Your team can't absorb framework-mixing risk. Introducing Symfony components into a Laravel product to solve a problem Laravel solves natively is a net negative on onboarding and debugging.

How to Pitch It (Stakeholders)

Executive summary: do not adopt; use as a design reference.

This package solves a legitimate, if narrow, i18n problem—keeping form choice labels translatable while keeping submitted values stable and validated. That requirement is real for us, and it's worth capturing explicitly in our i18n backlog.

However, it is not a candidate for integration:

• It is a Symfony 2 bundle and we are a Laravel/PHP shop—there is no integration surface.
• It is archived, built on an end-of-life framework, and has 10 stars with zero dependents, meaning no maintenance, no security response, and no fallback support.
• The functionality is roughly a few dozen lines to reproduce idiomatically in Laravel (a translation-file-backed whitelist plus a validation rule), which we control, test, and can extend.

Recommendation: close the evaluation as "not applicable—framework mismatch." Spend no engineering time integrating. Instead, file a small backlog item to standardize translated choice handling in our own codebase using this bundle's behavior as the acceptance criteria: labels resolved from locale files, values validated against the key set independently of locale, and a test asserting that adding a new locale or editing a label cannot widen the accepted input set. Engineering cost is low; the payoff is consistent, safely validated multilingual forms as we expand locales.