Laravel Translation Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for i18n tooling. The package owns a translation_lines table, which puts an in-app translation workflow within reach without licensing Phrase, Lokalise, or Crowdin. The 1.1.0 change matters here: making the migration a publishable stub means the schema is ours to extend (add columns, indexes, tenant scoping) without forking — which is usually the deciding argument for building rather than buying.
• Schema ownership and data governance. Migrations no longer load implicitly from the vendor package. That is a governance improvement: schema changes now go through our own migration directory and our own review process, so DBAs and platform teams can see and approve every table the package creates.
• Deploy-pipeline decisions. Publishing is an explicit step (vendor:publish --tag="translation-manager-migrations"), so the table only exists where we choose to run it. That supports decisions about which environments and which databases (single vs. per-tenant connections) get the feature.
• Upgrade risk posture. The release is backward compatible: 1.0 installs need no action, and running the publish/migrate path anyway is safe because the migration skips an existing table. That means this can ride along in a routine maintenance window rather than needing a scheduled migration event — relevant if we track upgrade cost per dependency.
• Roadmap timing for admin/editor tooling. The install now requires an extra setup command, so any internal docs, onboarding scripts, or CI bootstrap need a one-line update before we hand this to another team. Small, but it should be scoped into the adoption ticket rather than discovered during onboarding.

When to Consider This Package

• You are on Laravel and want translation editing inside the app rather than a separate SaaS — the value is the admin surface over the translation_lines table, not the table itself.
• You need to own the schema. 1.1.0 removes the main historical objection to embedding this: you now get a real migration file you can modify, version, and run per connection/tenant. If custom columns or scoping are foreseeable, this release is the reason to reconsider it.
• You are already on 1.0. Upgrading is a no-op; the only cost is deciding whether to adopt the publishable-migration convention now or later.
• Look elsewhere if you need vendor-managed translation memory, machine-translation integrations, translator marketplaces, or a high-volume queued translation pipeline — this package is app-embedded tooling, not a TMS.
• Also look elsewhere if you cannot add a publish step to your deploy process (e.g. immutable container images built without a release hook), or if your spatie/laravel-package-tools / Laravel version pairing with the package's hasMigrations() support is unverified. Confirm both before committing.
• Caveat on scope: this assessment is based on the 1.1.0 release notes and the migration/table naming only. The feature surface of the translation-management UI and its authorization model should be reviewed hands-on before adoption.

How to Pitch It (Stakeholders)

• For executives (one paragraph): "Version 1.1.0 is an internal packaging change, not a customer-facing one. Previously the package installed its database table automatically; now it ships that migration as a file we publish and control. The practical effect is that we own the schema for our translation data instead of inheriting the package author's decisions, and nothing else changes. Upgrades from our current version require no action, and the migration is written to be safe to re-run. The only cost is one extra setup command on fresh installs — meaning a small doc and CI update on our side."
• For engineering (detail): Migrations are now declared via hasMigrations() and shipped as a publishable stub rather than loaded from the package. New installs: php artisan vendor:publish --tag="translation-manager-migrations" then php artisan migrate. From 1.0: nothing to do; publishing and migrating is also safe, as the migration skips the table when it already exists. This is the standard package-tools convention, so it should feel familiar and it simplifies per-tenant/connection migration runs.
• Risk summary to state explicitly: minor semver bump, backward compatible, idempotent migration, no deprecations. Operational action items are limited to updating install documentation and any bootstrap/deploy script that provisions the app, plus verifying the publish tag in a staging run.
• Recommendation: adopt the publishable migration convention at the next natural deploy; treat 1.1.0 as low-risk maintenance rather than a feature release, and schedule a hands-on review of the translation UI itself if we are evaluating it for roadmap inclusion.