Drupal Transliterator Bundle Laravel Package

Product Decisions This Supports

• Multilingual SEO URL and slug strategy. The single product decision this package informs is how non-Latin content becomes a URL. For a marketplace, CMS, directory, or content platform with Cyrillic, Greek, Arabic, Hebrew, Vietnamese, or CJK titles, naive ASCII slugging (via iconv or a basic ASCII-only slugger) produces empty, truncated, or garbage slugs — post-1, -, or raw percent-encoded strings. Drupal's transliteration table is a large, human-curated, decade-tested character map (Łódź→lodz, Москва→moskva, 北京→bei-jing). The decision this supports is: adopt a curated transliteration dataset rather than hand-rolling one.
• Build vs. buy vs. borrow. The package itself is thin glue — a Symfony service definition plus a Composer dependency on Drupal's transliteration code. The durable asset is the data, not the integration. The real product decision is whether to (a) depend on this package at runtime, (b) vendor the transliteration map and write ~50 lines of glue, or (c) use a maintained modern equivalent like cocur/slugify or Symfony's AsciiSlugger. With 3 stars and 0 dependents, (b) or (c) almost always wins — this package is most valuable as a reference implementation and a behaviour spec, not a dependency.
• Content migration parity (Drupal → new stack). If you are migrating off a Drupal site, existing slugs are indexed, linked, and shared. Re-slugging with a different transliterator silently breaks thousands of URLs (/moskva becomes /moscow). This bundle exists precisely to make the new stack produce byte-identical slugs to the old one — converting a redirect-map project into a configuration change. That is a genuine, quantifiable roadmap saving.
• Sizing an i18n launch. A "launch in six new locales" epic has a hidden dependency: slug generation. This package demonstrates that the work is (or was) roughly a day, not a sprint — useful for sizing, and for killing a "we need a custom transliteration service" estimate.
• Correcting a false match. This is a Symfony 2 bundle, not a Laravel package: it registers a DI service and hooks Gedmo/Doctrine Sluggable. For a Laravel codebase the equivalent decision is cocur/slugify (or spatie/laravel-sluggable) behind cviebrock/eloquent-sluggable. Do not let the "PHP package" label create a false match in the backlog.

When to Consider This Package

Consider it only when all of the following hold:

• The application is on Symfony 2.x — both the bundle's service format and the Gedmo Sluggable 2.x TransliteratorInterface are long obsolete.
• Gedmo/Doctrine Extensions Sluggable is already the slugging mechanism; this bundle is worthless without it.
• Slugs must be ASCII and must match Drupal's output exactly, typically because of an in-flight Drupal migration or a shared-content / dual-run arrangement.
• You cannot upgrade the platform first, and you accept pinning and vendoring the dependency.

Look elsewhere — and plan to — in every other case:

• New builds (Symfony 3.4+/5/6/7, Laravel, any modern PHP): use cocur/slugify or Symfony's AsciiSlugger / slugger service. Both are maintained, PHP 8-compatible, and cover the same languages with equivalent or better coverage.
• Gedmo 3.x: the transliterator interface moved; this bundle will not wire up.
• Native-script URLs required (e.g., /ru/москва): this package transliterates away from the native script — it is the wrong tool, not a weak one.
• Any security or legal review: 3 stars, 0 dependents, no release cadence, no CVE coverage. Also check the license provenance of the Drupal-derived tables (Drupal core is GPLv2+), which is a gating question for a proprietary SaaS or shipped binary.
• You need the capability, not the parity. If you just want good slugs in many languages, the ecosystem solved this years ago; you do not need Drupal specifically.

How to Pitch It (Stakeholders)

To executives (one line): This is a small, unmaintained Symfony 2 adapter that lets us reuse Drupal's proven transliteration tables so multilingual URLs stay readable and existing Drupal links keep working after migration — it is cheap to replicate and should be copied, not depended on.

The business case. URLs are SEO surface area and, in a migration, a redirect liability. Bad transliteration shows up as either unreadable slugs (%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0, node-1234) or as thousands of 404s when a Drupal slug like /moskva becomes /moscow. Drupal's transliteration data is a de-facto reference, refined across a decade of non-English sites; matching it is a solved problem we should not re-solve. The value is the dataset and a parity guarantee, not the library.

To engineering. Do not add this as a dependency. It targets Symfony 2 and Gedmo Sluggable 2.x (both EOL), has no maintainer, no dependents, and no upgrade path; roughly 90% of it is framework glue we would discard. What we want is the character map and the behaviour. Recommended path: (1) on a modern stack, use the framework's built-in slugger — a one-line service change; (2) if we genuinely need Drupal-identical output for migration parity, vendor the transliteration table into a small, tested, in-house service behind our own Transliterator interface, with a golden-file test suite asserting old-slug == new-slug for a representative content sample; (3) never let slug generation be an implicit side effect — pin it, test it, and treat any change as a breaking change with a redirect plan.

Recommendation. Opportunity is low (solved problem, maintained alternatives) but the migration-parity use case is real and time-boxed. Score it as a one-off spike, not a platform choice: half a day to test whether built-in slugging already matches Drupal output on a content sample; only if it does not do we invest in porting the table. Sequence it as: confirm target scripts (is CJK actually in scope?) and clear the license question first — both are gating and neither requires code — then run the coverage spike, then build the parity harness, then integrate behind an interface so the decision is reversible. Ownership of any vendored code transfers to us on day one; scope it as a small but permanent carrying cost, offset by the fact that a pure function over static arrays is the lowest-churn code we can own.