Translation Editor Bundle Laravel Package

Product Decisions This Supports

• Framework fit remains the first-order finding: this is still a Symfony bundle, not a Laravel package. v1.0.0 moves persistence from MongoDB to Doctrine ORM, which reinforces the point — Doctrine is Symfony's ORM, not Eloquent. Adoption is still a "port or don't" decision, and the port cost lands on engineering, not on a composer require.
• The maintenance signal changed, but not the recommendation: the project shipped its first release since November 2013. That is a revival, not a track record. A single 1.0.0 after a 13-year gap tells you someone cares again; it does not tell you the project will be patched next quarter, that it supports modern PHP, or that anyone else depends on it. Treat "maintained" as a hypothesis to verify, not a fact the version number confers.
• Build vs. buy on localization tooling: the underlying need — letting non-engineers edit translations without touching YAML in Git — is a real recurring cost. v1.0.0 makes this package a marginally better reference design (import/dump across arbitrary translation file formats is exactly the write-back layer an internal editor needs, and is the least trivial part to get right). It is still not a viable buy for a Laravel shop, and only a moderate build reference.
• Roadmap prioritization for i18n: if localization is on the roadmap, the decision this package informs is whether translation workflow is a product problem or a tooling problem. Answer: tooling — buy it (Crowdin, Lokalise, Phrase, or self-hosted Weblate) rather than grow it in-house.
• Feature scoping: it clarifies what an MVP translation editor actually requires — a key/locale matrix, per-locale editing, and write-back to resource files. The new "support for new keys" and multi-format import/dump confirm the shape of that MVP. Anything beyond it (pluralization, ICU messages, translator roles, review states, XLIFF round-tripping) is why teams end up on a TMS instead.
• Risk/support decisions: MIT license, still zero dependents, and a history that is 13 years of silence followed by one breaking release. v1.0.0 is explicitly breaking ("heavy changes on original code", MongoDB support dropped, Doctrine ORM added) — so the project has now demonstrated it will make breaking changes without a migration path. Adopting it creates a long-term maintenance liability on a component that is not core to your product.

When to Consider This Package

Consider it only in narrow, mostly historical circumstances:

• You maintain a legacy Symfony 2.x/3.x application that is already on Doctrine ORM and has no appetite to migrate, and you want a self-hosted editor with no external service. v1.0.0's Doctrine support is aimed squarely at you — and only you.
• You need air-gapped or offline translation editing (regulated data, no SaaS vendor approval) and cannot run Weblate or a comparable self-hosted TMS.
• You want a small, readable codebase to fork as the seed for an internal editor, and you accept owning that fork indefinitely. The multi-format import/dump logic is the one piece worth reading even if you never install it.
• A very small team (1–3 locales, one or two contributors) where the full TMS workflow is overkill.

Look elsewhere if any of the following apply — which, for a Laravel shop, is effectively always:

• You are on Laravel or modern PHP (7.4/8.x). v1.0.0 did not change the framework coupling, and nothing in the release notes claims PHP 8 support, a test suite, or CI. This is a rewrite, not an install.
• You were on the MongoDB-backed version. The upgrade is breaking with no stated migration path — a concrete preview of how this project will treat your fork.
• You need security updates or vendor support. A single revival release is not a support commitment.
• You need real translation workflow: translator assignments, review/approval states, pluralization and ICU message handling, context screenshots, XLIFF import/export, or CI integration to catch missing keys.
• Translation is on the critical path to a market launch. A recently revived, single-release project is not where you want that dependency.
• For Laravel specifically: use a maintained in-app alternative (e.g. barryvdh/laravel-translation-manager) for a quick internal tool, or a SaaS/self-hosted TMS once you have more than a couple of locales or external translators.

How to Pitch It (Stakeholders)

To executives: translation bottlenecks delay localization launches and quietly consume engineering time — engineers become the bottleneck for every copy change in every language. The right response is to buy a translation management system or adopt a maintained open-source one, not to build an editor or adopt this package. This candidate shipped its first release since 2013 — so the "abandoned" label is now out of date — but a single 1.0.0 is a restart, not a track record, and it remains a Symfony bundle incompatible with our stack with no dependents to validate it. Recommendation is unchanged: do not adopt; treat the capability as a buy/standardize decision and budget accordingly.

To engineering: v1.0.0 is a substantial internal rework — MongoDB dropped for Doctrine ORM, UI fixes, arbitrary translation-file import/dump — but it is still a Symfony bundle, still Doctrine-coupled, and still unproven on PHP 8 with no stated test or CI story. The release itself is breaking with no migration path, which is the clearest signal yet about how this project treats downstream users. Reading the import/dump code as a design reference is cheap and reasonable; adopting it means porting Symfony DI and config conventions and owning the result permanently. If we want an in-app editor, use a maintained Laravel translation manager for the interim; if localization becomes a real workstream — multiple locales, external translators, review cycles — move to a TMS with XLIFF support and CI key-coverage checks. Effort to make this usable here: weeks, with no upstream support commitment, versus days for a maintained alternative and near-zero for a SaaS integration.