- How do I install and configure Laratext in a Laravel application?
- Run composer require edulazaro/laratext in your project root, then publish the package config with php artisan vendor:publish --tag="texts" to get config/texts.php. Add your translation provider credentials to .env and pick a provider via the default_translator config key. After that, run php artisan laratext:scan --dry to preview what the scanner finds before it writes any language files.
- How is Laratext different from Laravel's built-in __() translation helper?
- With __() you either pass a key, which makes language files unreadable, or pass the source text, which breaks every translation the moment a single character changes. Laratext uses a text('key.name', 'Default text') signature so the key stays stable for lookups while the source string stays readable in code and diffable in review. That dual key-plus-text approach is the core reason to consider the package.
- Which PHP and Laravel versions does Laratext support?
- Laratext supports PHP 8.2, 8.3, 8.4 and 8.5, and Laravel 10, 11, 12 and 13. Every combination of those versions is covered by the test suite on each push, and the matrix also runs weekly so a new framework release that breaks the package shows up quickly. That compatibility coverage is stronger than most packages of this size.
- How does Laratext auto-translate missing translation keys?
- The laratext:scan command walks your application for text() and @text usages, collects keys that are missing from your language files, and sends the source strings plus your configured context to the selected translation provider. Translated results are written into JSON language files. Commands like --resync re-translate existing entries and laratext:lock lets you protect entries from being overwritten.
- Which translation services does Laratext support out of the box?
- Laratext ships with OpenAITranslator, ClaudeTranslator (Anthropic) and GoogleTranslator, selected through the default_translator config key. You provide the relevant API key in .env and the scan command routes missing strings to that provider. The package does not bundle a human review step, so machine output lands directly in your language files unless you add one.
- Can I swap OpenAI for DeepL, a self-hosted model, or an internal translation gateway?
- Yes. The translators sit behind a strategy-style interface with a default_translator config key, so you can implement the interface for DeepL, a self-hosted model, or an internal machine translation service and bind it in config. Call sites using text() and @text do not change at all. This seam is the most architecturally valuable part of the package for teams with existing MT infrastructure.
- What does the laratext:scan Artisan command actually do?
- laratext:scan statically scans your codebase for text() helper calls and @text Blade directives, then creates or updates entries in your JSON language files. Use --dry first to see the scope without writing anything, and use flags like --resync or --prune deliberately. Because it writes to committed files, reviewing the resulting git diff is mandatory rather than optional.
- Is laratext:scan --prune safe to run, and can it delete keys that are still in use?
- --prune removes keys from language files based on static reference analysis, so any key built dynamically, such as text("activity.{$this->type->value}"), is invisible to the scanner and can be pruned even though it is used at runtime. The README itself notes that dynamically constructed keys surface the raw key to end users with nothing warning you. Treat prune runs as destructive, run them in a branch, and inspect the diff before merging.
- Does the text() helper or @text Blade directive collide with existing helpers or Laravel's own translations?
- text() and @text are very generic names, so any existing app helper, another package helper, or a future Laravel addition could collide. Confirm the package guards the helper with function_exists() and that you are comfortable reserving that name permanently, and test in a spike. It is also worth verifying whether Laratext registers itself into Laravel's translator so that __('key.name') resolves the same entries, or whether it is a parallel lookup path, because a parallel system means two translation mechanisms in one codebase.
- Is Laratext production ready, and what should I review before adopting it?
- Machine-translated strings become committed source files, so re-running a scan with a different model or prompt produces different output and noisy diffs; there is no reviewer, approval state, or glossary workflow beyond a free-text context string and the laratext:lock escape hatch. Source strings and your context blob are sent to OpenAI, Anthropic or Google, which is a third-party data-processing and possibly DPA review. The package is MIT licensed with a small surface and a single maintainer with roughly 77 stars, so plan to be the de facto QA for anything beyond the documented happy path.