Drupal Transliterator Bundle Laravel Package

Technical Evaluation

Verdict: Do not adopt this as a dependency in a Laravel stack. It is a Symfony 2 bundle that wraps one genuinely durable asset — Drupal's transliteration data tables and algorithm — in framework glue we cannot use. Treat it as a reference implementation and a behavior spec, not a library.

Architecture fit

• The package is a Symfony2 bundle (KhepinDrupalTransliteratorBundle, DependencyInjection/, Resources/config/services.yml, tagged services). Its only job is registering one service; Laravel's container cannot consume that without an adapter, and the adapter would be larger than the logic.
• What actually matters is twofold: (a) Drupal's drupal_transliterate-style function plus per-script mapping tables, and (b) a decorator into DoctrineExtensions Sluggable so text is transliterated before uniquification.
• Laravel uses Eloquent, not Doctrine ORM. The Sluggable integration is dead weight; the equivalent hook is cviebrock/eloquent-sluggable's custom method option, spatie/laravel-sluggable, or a model saving observer. That is a rewrite, not a config change.
• Net: roughly 10% of the package (tables + pure function) is portable; ~90% is framework glue we discard.

Integration feasibility

• Low as-is. Composer constraints will target Symfony 2.x / PHP 5.x-era packages and fail resolution against PHP 8.x / Laravel 10–12 before we reach code review.
• The transliteration logic is trivially extractable — a pure function over static arrays with no framework coupling — which is exactly why the bundle adds little.
• Maintained alternatives cover the same ground: symfony/string's AsciiSlugger / the slugger service, cocur/slugify (+ behat/transliteration), and spatie/laravel-sluggable. The only reason to look here is script coverage those lack, and that must be proven, not assumed.

Technical risk

• Abandonment: 3 stars, 0 dependents, composite score 0.015, no release cadence, no CVE feed coverage. Effectively unmaintained; no security-response path.
• Licensing: Drupal core is GPLv2+, and the transliteration data files derive from Drupal core. The bundle's own license may be permissive but the provenance of bundled data needs a legal read before it enters a proprietary product. This is the largest blocker and the cheapest to resolve early.
• Silent degradation: tables are per-script; a missing or incomplete table usually causes characters to pass through or be dropped, producing empty or non-ASCII slugs rather than an error. Invisible until SEO or routing breaks.
• Coverage assumptions: Drupal's core transliterator is Latin/Cyrillic/Greek-oriented and historically weak on CJK. If pinyin slugs are the driver, this package likely does not deliver what the name implies.

Key questions

1. Which scripts must we support, and is CJK in scope? Everything downstream depends on this.
2. What is the license provenance of the bundled tables, and does it survive our distribution model (SaaS vs. shipped artifact)?
3. Is there a concrete string where our maintained slugger produces wrong or empty output but Drupal's tables succeed? If not, this package has no reason to exist in our stack.
4. Do we need byte-for-byte parity with historical Drupal slugs? If yes, that alone can justify porting the tables — and converts a redirect-map project into a config change.

Integration Approach

Stack fit

• Assume Laravel + Eloquent. The integration surface is the transliteration function, not the bundle.
• Define our own seam: App\Support\Transliteration\Transliterator with a single transliterate(string): string method. Bind it in a ServiceProvider. Everything else depends on that interface, never on the vendor package.
• Pair it with a slug lifecycle package — cviebrock/eloquent-sluggable or spatie/laravel-sluggable — so slug generation stays a declared, testable step rather than an implicit side effect.

Migration path

• Do not composer require. Fork or vendor only the transliteration data and the pure function, behind our interface.
• Implement against cocur/slugify first, run the parity corpus, and fall back to ported Drupal tables only where coverage gaps are demonstrated. This keeps the abandoned code at arm's length and makes it swappable.
• Preserve the original ordering semantics: transliterate, then uniquify. Reversing it produces colliding suffixes and unstable URLs.

Compatibility

• If a fork is kept, modernize explicitly: PHP 8.1+ type declarations, a Laravel ServiceProvider replacing the bundle class, and no Doctrine references.
• Run composer why-not and a dependency-audit pass on any forked tree before it enters composer.lock; expect to strip the Symfony and Doctrine constraints wholesale.

Sequencing

1. Week 1 — Decide the requirement. Confirm target scripts, whether CJK is in scope, and confirm license position with legal. Both are gating and neither requires code.
2. Week 1–2 — Coverage spike (1–2 days). Build a golden corpus of ~500 representative strings per target script (diacritics, Cyrillic, CJK samples). Run it through the built-in slugger first, then cocur/slugify. This is the go/no-go on porting anything.
3. Week 2 — Parity harness. If gaps exist, port the tables and assert byte-for-byte parity against known-good Drupal output. This test suite is the real deliverable and survives any future library swap.
4. Week 3 — Integrate. Bind the interface, hook into the sluggable path, add a backfill/regeneration job if existing records need reslugging, and ship a redirect map for any URL that changes.
5. Defer indefinitely any Symfony or Doctrine compatibility work — it serves no one in our stack.

Operational Impact

Maintenance

• Ownership transfers to us on day one. There is no upstream to patch, so every PHP upgrade, encoding edge case, and script-coverage gap becomes ours. Scope this as a small but permanent carrying cost, not a one-time integration.
• Counterweight: the portable surface is a pure function over static arrays with no runtime dependencies. Once vendored inside our namespace it is among the lowest-churn code we can own. The risk sits in the decision to vendor, not in the code.
• Policy: treat any change to transliteration output as a breaking change requiring a redirect plan and a corpus regression run.

Support

• No maintainer response path, no issue activity, no community — escalation is internal-only. Acceptable for a pure, well-tested function; unacceptable for anything touching request handling, DI, or persistence, which is precisely the portion we discard.

Scaling

• Transliteration is CPU-bound and per-string; cost scales with slug volume, not traffic. At typical write rates it is negligible.
• The real concern is memory: Drupal's tables load per-script, and a naive port loads all of them per process. Load lazily by detected script and bound the working set to the scripts we actually encounter.
• Under PHP-FPM this is per-worker but bounded. Under long-running workers (Octane, queue consumers) confirm the resident set stays flat and that only immutable static arrays are cached — no per-request mutation.

Failure modes

• Missing table → silent passthrough or empty slug → duplicate slugs, 404s, and SEO damage that surfaces weeks later.
• Post-transliteration collisions raise the uniquifier churn (moskva-1, moskva-2), which is cosmetic early and an SEO liability at scale.
• Re-slugging historical content silently breaks inbound links; require an explicit redirect map as part of any slug change.
• Unicode normalization mismatch (NFC vs NFD input) can produce different output for visually identical strings; normalize at the boundary.
• License contamination if GPL-derived data ships in a proprietary distribution without review.

Ramp-up

• Half a day for any engineer to evaluate whether the framework's built-in slugger already matches Drupal output on a content sample.
• One to two days to build the corpus and parity harness if it does not.
• No Symfony internals knowledge required, because none of the Symfony code is retained. Record the decision and the corpus results in an ADР so the next engineer does not re-litigate it.