Product Decisions This Supports
- Regulatory deadline planning. The 21 October 2026 law mandating the new Uzbek Latin alphabet (Oʻ→Ö, Gʻ→Ğ, Sh→Ş, Ch→Ç) turns script handling from a "nice to have" into a dated compliance requirement. This release gives you a concrete, versioned dependency to anchor a roadmap milestone against, rather than an open-ended localization epic.
- Build vs. buy. Transliteration/normalization is a small surface area with a lot of edge cases (apostrophe variants, the "e" conversion bug fixed here). Adopting a maintained package is almost always cheaper than owning a bespoke mapping table — the v1.3.0 fix list is exactly the kind of long-tail work you do not want on your own backlog.
- Bidirectional conversion is now feature-viable.
fromNewLatin() means you can round-trip: legacy Cyrillic → new Latin → back. That unlocks user-facing features you previously couldn't ship confidently: reversible display toggles, side-by-side comparison views, and validation of user-supplied text.
- Content and data migration decisions. Any product with historical Uzbek content (Cyrillic-era archives, old-alphabet Latin) needs a migration strategy. This package lets you prototype the transform before committing to a data-migration budget line.
- Search, matching, and deduplication. Normalizing apostrophe variants and script differences directly improves search recall and reduces duplicate records — a measurable product metric rather than a pure infrastructure cost.
- Use cases to scope: localized UI copy and legal text, user-generated content input (names, addresses), SEO/slug generation, directory and catalog data, form validation of Uzbek-language fields, and cross-script analytics reconciliation.
When to Consider This Package
Adopt it when:
- You ship a product to an Uzbek-speaking audience and have any user-visible or stored Uzbek text.
- You have a hard date — the October 2026 alphabet change — and no in-house transliteration owner.
- You need round-trip conversion, not just one-way output;
fromNewLatin() is the deciding capability.
- You want a low-ceremony dependency: PHP
>=7.0 means it drops into older Laravel estates without a runtime upgrade project.
- You value the new test suite and CI. The addition of PHPUnit coverage and CI is the single biggest de-risking item in this release — it converts the package from "trust the author" to "verifiable behaviour," which matters if this sits in a compliance path.
Look elsewhere when:
- You need transliteration for languages other than Uzbek, or multi-script support beyond Cyrillic/Latin pairs — this is a focused tool, not a general i18n library.
- You require ICU/intl-backed collation, locale-aware sorting, or Unicode normalization guarantees; a thin mapping package will not give you that.
- You need active SLA-backed support or vendor indemnity — this reads as a small maintainer project, so treat it as community-supported and plan an internal fork/escape hatch accordingly.
- You are on a PHP 8-only codebase and want modern typing, enums, and static analysis —
>=7.0 support implies a conservative code style that may not meet strict modern standards.
- The new alphabet itself is still legally or editorially unsettled in your market; verify the mapping against the official published standard before you let it drive data migration.
Also flag: this is a breaking-change-shaped release for output. If you previously rendered Oʻ, Gʻ, Sh, Ch and now render Ö, Ğ, Ş, Ç, stored strings, fixtures, snapshots, and search indexes will diverge. Treat it as a migration, not a patch bump, even though the version number says minor.
How to Pitch It (Stakeholders)
To executives: A regulatory change lands in October 2026 requiring Uzbek text to be written in a new Latin alphabet. Rather than fund an internal project to rebuild our text handling, we can adopt a small, focused, now-tested open-source package that performs the conversion in both directions. The cost is a dependency and a scoped migration; the alternative is a bespoke build with an ongoing maintenance tail. The recent release is the moment this became safe to adopt: it adds automated tests and CI, which is what we'd want before putting anything in a compliance path.
To engineering: Low-risk integration — PHP 7.0+ with no runtime upgrade required. It handles the fiddly parts we'd otherwise get wrong (apostrophe variants, the "e" conversion edge case) and now offers fromNewLatin() for round-tripping. Two caveats to plan for: the output format changes with this release, so existing fixtures, snapshots, stored records, and search indexes need a deliberate migration rather than a version bump; and the project is community-maintained, so we should isolate it behind a thin internal adapter so we can swap or fork it without touching product code. The new test suite gives us a baseline to extend with our own conformance cases against the official standard.