- How do I install jayesh/laravel-gemini-translator in a Laravel app?
- Install it as a dev dependency with composer require --dev jayesh/laravel-gemini-translator, then publish the config file with php artisan vendor:publish and set GEMINI_API_KEY in your .env. After that you run the translations:extract-and-generate Artisan command. Because it is a development-time tool with no runtime middleware or service bindings, keeping it out of production dependencies is the intended setup.
- Does this package support Laravel 10 or PHP 8.2?
- No. The package requires PHP 8.3 or higher and targets Laravel 11, 12, and 13 only, so Laravel 10 and PHP 8.1/8.2 estates are excluded outright. If you are still on Laravel 10 you would need to upgrade PHP and the framework first, or keep using manual translation files. Check the composer.json constraints before adding it to a legacy project.
- Can I run the Gemini translation command headless in CI with --no-interaction?
- The command is documented as interactive, and v4 replaced the --source option with interactive target and file-group selection, so fully headless CI execution is the biggest unknown to verify in a pilot. Test --no-interaction against a single locale before wiring it into a pipeline. Also confirm your concurrency driver: the pcntl fork driver is often missing in container images, so fall back to the Process driver or the sequential sync mode.
- Why do I get a configuration exception about request_timeout from google-gemini-php/laravel?
- The Gemini Laravel config expects request_timeout to be cast to an integer, and the uncast env() value throws a runtime configuration exception on first run. Edit the published config so the value reads (int) env('GEMINI_REQUEST_TIMEOUT', ...) and the error goes away. This is a documented onboarding papercut rather than a bug in your app.
- What is the difference between --skip-existing, --refresh, and --refresh-clean?
- Full sync translates everything the scanner finds, --skip-existing only fills in missing keys so existing manual translations survive, --refresh regenerates wording from the existing file text, and --refresh-clean rebuilds from keys only. Use --dry-run first to inventory which keys the scanner detects and to catch false positives from dynamic keys or concatenated __($var) calls. Commit the generated lang files as reviewable artifacts so you can diff and restore manual work.
- Does it work with nwidart/laravel-modules, lang packs, and Vue files?
- Yes. The scanner covers Blade, PHP, Vue, JavaScript, TypeScript, and JSON, including Vue $t(), i18n.t(), and v-t attribute usage, and there is explicit --consolidate-modules support for modular applications. Extra folders such as lang/app3/ and lang/web/ are treated as lang packs separate from lang/ in both the CLI and the browser Translation Manager. That makes it a good fit for a Laravel monolith with a Blade plus Vue frontend, and a poor fit for API-only backends or SPAs whose copy lives in another repo.
- Is it safe to send my Laravel source strings to Google Gemini?
- The scanner reads your source files and sends the extracted strings, which can include validation messages, UI copy, and domain-revealing text, to the Gemini API for translation. That is a third-party data-processing decision you should clear with your security and privacy owners before running it on a private codebase. Avoid extracting keys that sit next to secrets, and review the generated files before they reach version control or production.
- How much does it cost per run, and does --max-retries re-bill failed translations?
- Cost scales with the number of keys multiplied by the number of target locales, so measure a single locale first and extrapolate rather than translating every locale at once. Because retries resend failed requests, --max-retries can re-bill partially failed batches, so watch the logs on the first real run. Pin the Gemini model in the config so a silent model change does not shift your token profile or output style.
- Will it overwrite framework files published by laravel-lang/lang?
- The package bootstraps Laravel framework translations, so it can collide with auth.php, validation.php, and passwords.php files already published by laravel-lang/lang. Snapshot your lang/ tree before the first run and diff the output to see exactly which files were touched. If framework files must stay under laravel-lang control, exclude those keys or skip that directory in your workflow.
- Is jayesh/laravel-gemini-translator actively maintained, and what are the alternatives?
- It is a single-maintainer package with around 69 stars and no dependents, so bus factor is one and there is no ecosystem hardening against edge-case codebases. Version velocity has been high, with breaking changes in v4 and v5, so pin an exact version and expect upgrade work. Alternatives include manual translation, the laravel-lang/lang community files, or dedicated translation services and PO-based tooling if you need determinism and vendor-backed support.