Translation Laravel Package

Product Decisions This Supports

• Multi-market launch sequencing. Whether to ship a second-language storefront, and which surfaces must be localized first: product names/descriptions, categories, attributes, option values. This module defines the content model that decision rests on.
• Catalog translation architecture: one catalog with N translations vs. duplicated catalogs per market vs. external PIM/CMS. The module commits you to the first pattern. That choice cascades into merchandising workflows, reporting, search, and how "same product, different market" is represented in analytics.
• Build vs. buy for translation plumbing. It replaces a bespoke translations table plus locale-aware accessors — modest scope, but exactly the code you'd otherwise own forever and re-solve on every Vanilo upgrade.
• Authoring workflow roadmap. Who edits translations, whether partial translations may be published, default-locale fallback behavior, and whether translation completeness becomes a launch gate.
• SEO roadmap. hreflang, localized slugs/URLs, and indexable localized metadata all depend on where translated fields live and how they're resolved at render time.
• Search and filtering scope. Locale-scoped queries, facets, and sorting on translated attributes are a follow-on decision; this module is a prerequisite, not the answer.
• Separating UI localization from content localization. Laravel lang files handle interface strings; this handles catalog content. Different owners, different tooling, different budget lines — a distinction worth making explicit before anyone says "we're doing i18n."

When to Consider This Package

Consider it when:

• You are already on Vanilo, or actively committing to it, and need entity-level translations without forking or extending the core.
• You want ecosystem-native conventions — the same accessor patterns, migrations, and admin assumptions as the rest of the framework — rather than reconciling a generic translatable trait with Vanilo's models.
• Your need is catalog-content-shaped: roughly 2–5 locales, human-authored copy, and fallback to a default locale is acceptable.
• You prefer a small, MIT-licensed, ecosystem-aligned module over a heavier dependency with its own release cadence and upgrade risk.

Look elsewhere when:

• You are not on Vanilo. Nothing here justifies adopting the framework. Use spatie/laravel-translatable, astrotomic/laravel-translatable, or plain JSON columns against your own schema.
• You need a translation pipeline, not a schema. Machine translation, translation memory, vendor/TMS integrations, per-market review states — that is a TMS or PIM purchase, not a trait.
• You need per-locale pricing, currencies, or genuinely independent per-market catalogs. Those are separate architectural decisions this module does not make for you.
• Locale count or content volume is large. Per-field translation rows become a real query and authoring burden at scale.
• You require commercial SLAs or an audited supply chain. Low stars and zero dependents here reflect that the module ships inside a framework distribution rather than being consumed directly — not that it is abandoned. Still, confirm compatibility with your pinned Vanilo version and check recent maintenance activity before betting a launch on it.

How to Pitch It (Stakeholders)

Executives. This is a low-cost enabler for entering a new language market: one catalog carrying N languages instead of a separate storefront per country. Licensing cost is effectively zero. The real cost is content operations — translating, reviewing, and keeping product copy current — so approve it inside a market-entry scope that names the target markets, the content owner, and the launch quality bar. Do not frame it as a purchase; frame it as plumbing inside a localization initiative.

Engineering. A small, MIT-licensed Vanilo module that stores translated entity fields using the framework's own conventions, so we avoid writing and maintaining a bespoke translation layer. It deliberately does not solve search, URL localization, or per-market pricing — scope those as separate tickets. Principal risks are ecosystem coupling (it only makes sense if we are on Vanilo) and upgrade alignment with our Vanilo version. Recommend a short spike: model our translated entities, confirm fallback behavior, and measure query impact on catalog listing pages before committing.

One-liner. Adopt if we are a Vanilo shop going multilingual across a handful of human-translated locales; skip if we are not on Vanilo, or if the underlying need is a translation management system rather than a data model.