Weave Code
Tomato Translations Laravel Package
tomatophp/tomato-translations
Tomato Translations is a Laravel package for managing app translations from an admin interface. Browse, add, and edit language files and database-backed strings across locales without touching code, making multilingual Laravel apps simpler to maintain.
Database Base Translations Keys with Google Translations API Integration
Frequently asked questions about Tomato Translations
- What is tomatophp/tomato-translations used for?
- Tomato Translations is a Laravel package for managing application translations from an admin interface. It lets you browse, add, and edit PHP and JSON language files plus database-backed translation keys across locales without touching code. It also wraps a Google Translate API integration for machine-assisted generation, including an Artisan command that can translate a scoped path instead of the whole application.
- How do I install tomato-translations in a Laravel application?
- Install it with Composer using composer require tomatophp/tomato-translations, then publish the package config. Add your Google Translate credentials to the .env file, and optionally run the migrations if you want the database-backed key store. Filament panel registration is also optional but expected if you want the admin editing UI.
- Does it require Filament or the TomatoPHP ecosystem?
- The admin surface assumes a TomatoPHP and Filament host application, so the full UI experience works best inside that ecosystem. Outside it, routes, panel registration, and shared UI dependencies become bespoke integration work. The underlying file editing and API translation still function, but the value proposition narrows toward a lang-file editor with an API key.
- Which Laravel and PHP versions are supported?
- The provided documentation does not specify clear Laravel or PHP version ranges, and the last release was around April 2024. Because of that, you should check composer.json constraints and run a quick compatibility spike against your current Laravel major before committing. Do not assume support for the newest Laravel or PHP releases without verifying it.
- How does the Google Translate integration work and do I need an API key?
- Yes, machine translation requires Google Translate API credentials configured through your environment file. That introduces per-character costs, quota and rate-limit failures, and data-egress considerations for any string that is not purely product copy. You can adopt the editor and database key store without enabling the auto-translation features if you prefer to keep translations human-authored.
- Does it store translations in the database or in language files?
- It supports both. Translation keys can be stored in the database through optional migrations, while the package also reads and writes PHP and JSON lang files that Laravel already loads. Importantly, there is no runtime dependency on the package for serving translations, which keeps the blast radius small and makes rollback a matter of reverting the lang directory.
- Can I translate only a specific module or path instead of the whole app?
- Yes, version 1.2.6 added an Artisan command that translates a selected path rather than the entire application. That makes localization a scoped, repeatable step you can align with individual module releases instead of a big-bang locale sweep. However, the command signature and option details are not documented, so confirm the exact behavior in the source or with a spike.
- Will the auto-translation command overwrite my existing translation files?
- The merge-versus-overwrite behavior is not documented, which is the single biggest risk when using this package. An auto-translation run that replaces existing keys would destroy human-curated copy that may have had brand, legal, or translator review. Back up your lang directory, test on a copy first, and check the source for dry-run, force, and idempotency options before running it anywhere real.
- Is it safe to run in CI or production, and what about API costs and rate limits?
- Provider failures are external and non-deterministic, which is hostile to CI pipelines, and Google Translate bills per character with quota limits. Machine output combined with database key ordering can also produce unstable diffs, turning review into rubber-stamping. Until write semantics and dry-run support are proven, treat it as a controlled admin tool rather than a release-blocking pipeline step.
- Is tomato-translations actively maintained, and what are the alternatives?
- The repository has very few stars, no dependents, and a single-maintainer ecosystem with the last release in April 2024, so there is no bus factor or adopter community to inherit fixes. That makes it acceptable for an internal admin convenience but not as a release-blocking dependency. Alternatives include Laravel's built-in lang files, community language packs, database translation loaders such as spatie/laravel-translation-loader, or SaaS localization platforms like Phrase and Lokalise.
Weaver
How can I help you explore Laravel packages today?