Lithuanian Names Declension Laravel Package

Technical Evaluation

Architecture fit The package addresses a narrow, well-defined domain problem: grammatically declining Lithuanian proper names across the seven cases (nominative, genitive, dative, accusative, instrumental, locative, vocative), including rules for foreign-origin names. This is genuinely hard to get right and is a recurring requirement anywhere a lt-LT locale personalizes text — greeting lines, invoice/contract party fields, e-mail salutations, CRM records, notification templates.

The critical finding is a naming mismatch: despite being scoped here as a Laravel/PHP package, the repository is a Symfony bundle (*Bundle namespace, DI extension, service definition). Its usefulness to a Laravel codebase therefore depends entirely on whether the declension logic lives in a framework-agnostic class that the bundle merely wires up. That is the single most important thing to verify in a spike — and the answer determines whether we have a reusable domain service or a piece of dead framework scaffolding wrapped around the real algorithm.

Integration feasibility Feasible but not drop-in. The likely path is: extract the underlying service class, bypass the bundle's Extension/CompilerPass, and bind it into Laravel's container behind our own interface. That is a small, well-bounded piece of glue work. The blocker to watch is Composer: a 2015-era bundle will almost certainly constrain symfony/* to ~2.x, which will conflict with the Symfony components Laravel already ships. Installing it as-is is likely to fail resolution outright — reinforcing the vendor-and-extract approach over composer require.

Technical risk High, and concentrated in three places:

• Abandonment. Last release 2015-10-05, ~10 years ago. Three stars, zero dependents, single author. There is no upstream to patch a defect; we become the maintainer the moment we adopt it.
• Runtime compatibility. Code from that era frequently breaks on PHP 8.x: removed functions, dynamic properties, curly-brace string offsets, and untyped signatures against modern interfaces. Minimum-version-only platform constraints mean composer install may succeed and the failure surfaces at runtime instead.
• Correctness risk, not security risk. The attack surface is small (pure string manipulation, no I/O, no network), so this is not a CVE-grade dependency. The real exposure is linguistic: a wrong case ending on a customer's name in a contract or e-mail is a visible, credibility-damaging defect that no test suite currently guards against. UTF-8 handling of Lithuanian diacritics (ą, č, ę, ė, į, š, ų, ū, ž) through mbstring also needs explicit verification.

Key questions

1. Does the declension algorithm have any Symfony coupling, or can the core class be lifted cleanly?
2. What PHP versions and symfony/* constraints does composer.json declare, and does the code run clean on our target runtime (8.2/8.3) under E_ALL?
3. Is there any test suite, and what is its coverage of edge cases — foreign surnames, single-syllable names, hyphenated names, unisex names?
4. Do we have a Lithuanian-speaking reviewer available to validate output against a golden corpus?
5. Is there a maintained alternative (another library, a linguistic API, or a rules table we license) that removes the maintenance burden?
6. Is lt-LT name declension an actual roadmap requirement, or a speculative nice-to-have? The low opportunity score (25.98) suggests limited strategic pull.

Integration Approach

Stack fit Conditional. Viable only as a vendored, extracted component — not as a Composer dependency on the published bundle. The target shape is an internal adapter: a NameDecliner interface in our domain layer, one implementation delegating to the extracted algorithm, registered as a singleton in Laravel's container. This keeps the third-party code at arm's length and makes it swappable if we later replace it with an in-house rules table or a paid API.

Migration path

1. Spike (1–2 days): clone, read composer.json and the service class, attempt extraction into a standalone file outside Symfony, run against a hand-built corpus of ~50 real names across all seven cases.
2. Fork: vendor the extracted source into a private repository (or app/Support/ with a license header retained — MIT permits this, but attribution must be preserved and the MIT notice shipped). Pin to a reviewed commit SHA; do not track upstream, since there is none.
3. Harden: PHP 8.x compatibility pass, declare(strict_types=1), explicit UTF-8 assumptions, input length caps, and a PHPUnit suite built from the validated corpus.
4. Wrap: publish internally as a small first-party package via Satis or a VCS repository so multiple services can consume it without copy-paste drift.
5. Cut over behind a feature flag, with locale-gated invocation so non-lt-LT paths are untouched.

Compatibility Do not attempt to install the bundle alongside Laravel. Treat the Symfony wiring as documentation of intent rather than a component to run. Confirm autoloading standard (PSR-0 vs PSR-4) and normalize to PSR-4 during extraction. Verify mbstring is present in all target environments; add it to the platform requirements explicitly.

Sequencing Spike and linguistic validation must complete before any integration work is scheduled. If the corpus review fails — or if no reviewer can be secured — the correct decision is to stop and evaluate build-vs-buy, because shipping a declension engine we cannot validate is worse than shipping none.

Operational Impact

Maintenance We inherit full ownership. Realistically this is low-effort but non-zero: the algorithm is stable (Lithuanian grammar does not change), so expect near-zero churn punctuated by occasional PHP-version upgrades and bug reports from native speakers. Budget roughly 1–2 engineer-days per year for stewardship, plus the initial hardening. The MIT license is permissive and unproblematic; the compliance obligation is simply retaining the copyright notice.

Support None available. No upstream maintainer response, no issue tracker activity, no security advisories. All defects become internal tickets. Mitigate by designating a named owner on the team and documenting the fork's provenance and deviation history in the repository README so a future maintainer is not archaeology-bound.

Scaling Effectively a non-issue. Declension is a pure, stateless, CPU-bound string transformation with microsecond-scale execution. It is trivially cacheable by (name, case) key — a small Redis or in-process array cache will absorb any realistic volume, since the cardinality of distinct personal names per tenant is low. No external calls, no connection pools, no contention.

Failure modes

• Wrong output — the dominant risk. Silent, plausible-looking, grammatically incorrect text reaching customers. Detect via corpus regression tests and, ideally, an occasional native-speaker spot check.
• Unhandled input — exceptions or malformed output on unexpected characters, emoji, empty strings, or very long inputs. Guard with input validation, a length cap, and a safe fallback to the nominative form on any failure rather than propagating an exception into a user-facing render path.
• Regex backtracking — possible on pathological inputs given the vintage; the length cap and a pcre.backtrack_limit sanity check close this.
• Runtime breakage on PHP upgrade — caught by CI matrix, not by users.
• Supply chain — negligible if vendored; a real consideration if pulled from Packagist with a floating constraint, which we should not do.

Ramp-up Low technical ramp-up (small, readable codebase — well under a day for a mid-level engineer), but a non-trivial domain ramp-up: correctly judging Lithuanian declension requires native or near-native fluency. If the team lacks that, secure a reviewer before adoption, budget ~3–5 engineer-days for the full spike-through-production path, and treat the linguistic validation milestone as a hard gate rather than a checkbox.