Latin To Cyrillic Laravel Package

Technical Evaluation

Architecture fit. This is a stateless, pure-PHP string-transliteration library — no persistence, no I/O, no external services. That is the lowest-risk architectural shape a Laravel app can absorb: it can sit behind a single injected service class or facade and be called from form requests, import jobs, model mutators, and search-index builders without touching infrastructure. The open question is packaging: the release notes describe algorithm and test changes but say nothing about a Laravel service provider, config publishing, or container bindings. If it remains framework-agnostic, integration is a one-line composer require plus a thin wrapper we own; if a provider exists, we should confirm it does not auto-register global helpers that collide with ours.

Integration feasibility. Straightforward. The PHP >=7.0 floor is permissive enough to install on any current Laravel release (Laravel 10/11's own PHP 8.1+ floor is the binding constraint, not this package). The public surface appears small: the existing conversion entry points plus the new fromNewLatin(). A developer can wire it up in under a day. What is not feasible in a day is validating that the changed mappings are correct for our corpus — see risk below.

Technical risk. Three items dominate:

1. Output-changing release shipped as a minor (1.3.0). The alphabet remap (Oʻ→Ö, Gʻ→Ğ, Sh→Ş, Ch→Ç) alters every string containing those digraphs. This is a behavioral breaking change regardless of the version number. Anything we persist, cache, index, slug, or export will diverge from what the package now produces.
2. Regulatory deadline. The mapping is driven by the 21 October 2026 law, which converts a "nice to have" into a dated compliance obligation with no ability to defer indefinitely.
3. Previously untested behavior. PHPUnit and CI were only switched on in this release, meaning all pre-1.3.0 output — including the apostrophe and "e" conversion bugs now fixed — was unverified. Data produced by earlier versions is suspect and should be treated as non-conforming rather than merely "old."

Unicode apostrophe handling is a specific hazard: ʻ (U+02BB), ' (U+2018/2019), and ASCII ' are visually similar and commonly mixed in real data. The notes say apostrophe errors were fixed but do not state which codepoints are normalized.

Key questions.

• Is fromNewLatin() paired with a toNewLatin()/old-Latin path, or is old→new conversion implicit in the existing methods?
• Is the alphabet mapping configurable, or hardcoded in 1.3.0?
• Is the pre-1.3.0 behavior retained behind a flag, or is 1.3.0 a hard cutover?
• Does the package ship a Laravel service provider and publishable config?
• What is PHPUnit coverage, and are the new tests golden-file/table-driven against the statutory alphabet?
• How is mixed-script and idempotency (converting twice) handled?
• Is the mapping table versioned and documented separately from the changelog?

Integration Approach

Stack fit. Composer-installable and framework-agnostic in practice; usable from Laravel 5.x through 11.x given the PHP floor. Natural call sites are request normalization, bulk content migration, search analyzers, PDF/report rendering, and any place we currently hand-roll Uzbek transliteration. No queue, no DB migration, no service mesh impact.

Migration path.

1. Pin v1.3.0 on a branch; do not float the constraint during evaluation.
2. Assemble a golden corpus of real strings — person names, addresses, official document titles, product copy, existing slugs — and snapshot outputs from the current pinned version and from 1.3.0.
3. Diff the two and classify every change as intended (the four remaps, apostrophe fix, "e" fix) or unexpected. Anything in the second bucket blocks rollout until explained.
4. Introduce the new alphabet behind a config flag or adapter so old and new outputs can coexist during transition.
5. Backfill and reindex, then cut over before the statutory date.

Compatibility. Treat 1.3.0 as a breaking change for our purposes. Downstream surfaces needing recompute or deliberate freezing: database columns holding transliterated text, search indexes and analyzers, cached rendered fragments, exported files, and — most dangerous — URL slugs and unique keys. Sh → Ş will change slugs, which can break inbound links and produce uniqueness collisions. Plan a redirect map and a collision check before backfill.

Sequencing. Package upgrade → golden-corpus diff and sign-off → flag/adapter in place → backfill + reindex + slug redirects → cutover → retain legacy path for historical records with documented mapping. Do not collapse the diff step; it is the only cheap opportunity to catch a mapping error before it is written to production data.

Operational Impact

Maintenance. Code churn is low, but regulatory churn is not. The alphabet is now law-driven, so budget for follow-up releases as the regulator clarifies edge cases, and confirm the upstream maintainer is responsive now that CI exists. Pin the version and review each release's mapping table rather than its semver number.

Support. The failure mode here is silent incorrect text — no exception, no 500, just the wrong letter. That shifts support burden from infrastructure to correctness: we need sampled output monitoring, a diff alert on reindex, and a domain reviewer. First-line support will not catch a bad Ğ; only a validation harness or a native speaker will.

Scaling. Effectively free. Pure CPU string operations at microsecond cost, horizontally trivial, no shared state. The only real scaling concern is bulk backfill — chunk imports and avoid per-row service resolution inside tight loops.

Failure modes.

• Mixed old/new output across a dataset after partial backfill.
• Slug and unique-key collisions from Sh→Ş and Ch→Ç.
• Unicode apostrophe variants slipping through normalization.
• Silent regressions in "e" handling that the new tests may not cover.
• Assuming the >=7.0 floor means old runtimes are supported — they are EOL and untested; run production on a supported PHP.

Ramp-up. Hours for a PHP developer to integrate and call the API; two to three days for the team to build corpus-based confidence, reindex, and fix slugs; plus a language/legal reviewer to sign off the mapping table. The engineering cost is small — the correctness and content-migration cost is where the estimate actually lives.