Laravel Unique Translation Laravel Package

Product Decisions This Supports

• Multi-locale launch readiness. Approving a roadmap item like "localized storefront URLs" or "per-market product catalog" hinges on whether translation fields can be made authoritative. This package enforces uniqueness per locale inside a JSON column, which is the missing guardrail for localized slugs, product names, category titles, and coupon codes — i.e., the fields that users actually see.
• Build vs. buy on validation plumbing. The alternative is a custom Rule object plus driver-specific JSON query logic plus an ignore-on-update path. That is roughly 1–3 engineering days and ongoing ownership. This is a composer require and a rule string. The decision is cheap to make and cheap to reverse.
• Data-model direction: JSON column vs. translation table. Adopting this signals you're committing to the Spatie-style JSON-column translation pattern rather than a normalized translations table. That's a real architectural fork — JSON columns simplify model code and querying for one locale, but they can't be enforced with a plain composite unique index. This package is the compensating control that makes the JSON approach defensible in a review.
• Supporting an "ignore self on update" requirement. Any edit screen for a localized slug needs uniqueness checks that exclude the current record. Confirming that's handled out of the box removes a recurring bug class from the backlog (users unable to save an unchanged form).
• Scoping a larger i18n investment. If the localized-slug initiative depends on hand-rolled validation, that is a signal to budget for a broader i18n workstream. If this covers it, the initiative stays small.

When to Consider This Package

Adopt when all of the following hold:

• Translations are already stored in JSON columns (typically spatie/laravel-translatable) and you are not migrating to a dedicated translations table.
• You need uniqueness scoped to a single locale — not global uniqueness across all languages, which is a different and harder requirement this does not address.
• The database is MySQL/MariaDB or PostgreSQL. Verify your driver explicitly; SQLite-based local or CI environments are a common gotcha that can make tests diverge from production.
• Your uniqueness needs are exact-match. Case-insensitive, accent-normalized, or slug-collision semantics require additional normalization you will own.

Look elsewhere when:

• You control the schema and can use a normalized translations table with a composite unique index — that is a stronger, database-enforced guarantee and should win the build-vs-buy argument.
• You require uniqueness across all locales simultaneously, or fuzzy/similarity checks.
• Supply-chain risk is a blocker. Low star count, zero dependents, a single maintainer, and a last release in April 2024 mean you should treat this as effectively unmaintained. It is small and MIT-licensed, so the real mitigation is vendoring or accepting that you may fork it. If your org requires active maintenance or a security review for new dependencies, expect friction — and get ahead of it by proposing it as a pinned, low-blast-radius dependency rather than a strategic one.
• You are on a database driver outside MySQL/Postgres/SQLite coverage.

How to Pitch It (Stakeholders)

For executives: We can ship localized, SEO-friendly URLs and per-market product naming without a schema migration or a custom validation project. This is a small, MIT-licensed open-source component that closes a specific data-integrity gap — preventing two products or pages from claiming the same name or slug in the same language, which would otherwise surface as broken links and duplicate content in search. Cost is hours, not weeks, and there is no vendor lock-in; the code is small enough to absorb internally if needed. The tradeoff is that it is a low-profile dependency from a single maintainer, so we'll pin the version and treat it as a contained utility rather than a platform bet.

For engineering: It provides a unique_translation validation rule that queries inside a JSON translation column for a given locale and supports ignoring the current model on update, so edit forms don't false-positive. It slots into existing Form Requests and Spatie translatable models with no schema change. Two caveats to confirm before we commit: database driver support (MySQL/Postgres; check SQLite in tests) and that exact-match semantics are sufficient — if we need case-insensitive or accent-folded uniqueness, we normalize on write or wrap the rule. Given the maintenance profile, pin the version and note the fork path in the ADR.