Translations Bundle Laravel Package

Product Decisions This Supports

• Dynamic, Database-Driven Localization: Enables storing translations in a database (vs. static .po/.json files), allowing runtime updates without redeployments. Ideal for SaaS products with frequent UI/UX changes or multilingual content managed by non-technical teams (e.g., CMS-driven apps, e-commerce platforms).
• Catalogue-Based Organization: Supports grouping translations by "catalogues" (e.g., auth, dashboard), simplifying maintenance for large codebases or modular applications (e.g., microservices with shared translation layers).
• Build vs. Buy: Buy for teams needing a lightweight, Doctrine-ORM-backed solution without reinventing translation storage. Avoid if requiring advanced features like machine translation APIs, translation memory, or collaborative editing (consider tools like Crowdin or Lokalise).
• Roadmap Prioritization:
  • Phase 1: Replace static translation files with DB-backed system for faster iterations.
  • Phase 2: Integrate with a translation management platform (TMP) for workflows (e.g., Crowdin webhooks to update the DB).
  • Phase 3: Extend to support entity translations (via the linked EntityTranslationsBundle) for localized model attributes (e.g., product names in different languages).

When to Consider This Package

Adopt If:

• Your app uses Symfony 5.4+ and Doctrine ORM (core dependencies).
• You need runtime translation updates (e.g., A/B testing labels, admin-editable content).
• Your translation volume is moderate (not enterprise-scale; no need for professional TMPs).
• You prefer SQL-based storage over file systems (easier backups, versioning via migrations).
• Your team lacks dedicated localization tools but needs a simple, self-hosted solution.

Look Elsewhere If:

• You require machine translation (e.g., Google Translate API integration).
• Your app needs collaborative translation workflows (e.g., approvals, glossaries).
• You’re using non-Symfony PHP or a different ORM (e.g., Eloquent).
• You need performance at scale (this bundle adds DB overhead; static files may be faster for read-heavy apps).
• Your translations are 100% static (no runtime changes needed).
• You’re already using a dedicated TMP (e.g., Lokalise, Phrase) with direct API integrations.

How to Pitch It (Stakeholders)

For Executives:

"This package lets us store translations in our database instead of static files, enabling faster UI updates without redeployments. For example, marketing can tweak labels in real-time for A/B tests or regional campaigns. It’s a lightweight, self-hosted solution that avoids vendor lock-in with tools like Crowdin—ideal for our [SaaS/e-commerce] product where agility matters. Upfront cost: minimal (just a Composer install); long-term savings: no need for expensive TMPs if our translation volume stays moderate."

Key Ask: "Can we allocate 2 dev days to migrate translations to this system and test with our [high-churn feature]?"

For Engineering:

"This bundle replaces Symfony’s default translation system with a Doctrine-backed approach. Here’s the tradeoff:

• Pros:
  • Dynamic updates: No more php bin/console translation:update or redeploys for label changes.
  • Catalogues: Organize translations by domain (e.g., auth, dashboard) for cleaner code.
  • SQL storage: Easier to audit, backup, or sync with other systems (e.g., via webhooks).
• Cons:
  • Performance: DB queries add ~5–10ms per translation load (benchmark in staging).
  • Migration effort: One-time cost to move existing .po/.json files to the DB.
  • Limited features: No built-in MT or workflows (but we can layer those later).

Recommendation: Pilot this for our [non-critical module] first, then expand. We’ll need to:*

1. Set up the DB schema (3 tables: languages, translation_tokens, translations).
2. Write a script to import existing translations (using translation:update --output-format=db).
3. Update the translation loader in services to use the new repository.

Dependencies: Symfony 5.4+, Doctrine ORM. No major BC risks if we follow the [migration guide]."*

Key Ask: "Can we scope this to [specific feature] and measure DB impact before full rollout?"