Download the PHP package edulazaro/laratext without Composer

Laratext for Laravel

Introduction

Laratext is a Laravel package designed to manage and auto-translate your application's text strings. In laravel, when using the __ gettext helper method you specify the translation or the key. Both options have issues. If you specify the key, the file becomes difficult to read, as you don't know what's there. If you specify the text, your translations will break if you change a single character. With Laratext you specify both the key and the text, making it useful and readable.

It also allows you to seamlessly integrate translation services (like OpenAI or Google Translate) into your Laravel application to automatically translate missing translation keys across multiple languages.

It includes these features:

• Simplifies working with language files in Laravel.
• Auto-translate missing translation keys to multiple languages.
• Supports multiple translation services (e.g., OpenAI, Google Translate).
• Easy-to-use Blade directive (@text) and helper functions (text()).
• Commands to scan and update translation files.

Requirements

• PHP 8.2, 8.3, 8.4 and 8.5
• Laravel 10, 11, 12 and 13

Every combination of those is covered by the test suite on each push, and once a week so a new release that breaks the package shows up here first.

Installation

Execute the following command in your Laravel root project directory:

To publish the configuration run:

Or if for some reason it does not work:

This will generate the texts.php configuration file in the config folder.

Configuration

The texts.php configuration file contains all the settings for the package, including API keys for translation services, supported languages, and more.

Example of the configuration (config/texts.php):

This configuration allows you to define your translation services, API keys, and the supported languages in your Laravel application.

The language your source texts are written in

The scanner compares the text in your code with the one stored in the language file of your source language, and tells the translator to translate from it. By default that is config('app.locale'), which is right in most projects.

It is not right when they differ, and the usual case is an application that runs in one language while its source texts are written in English:

Here the Spanish translation, "Portafolio", would be compared against "Portfolio" and every key would look like its source text had changed, so a single --write would retranslate the whole project. Point the package at the right file:

Leave it out and nothing changes: the application locale keeps being used.

Giving the translator context

A translator sees short strings on their own, so it has to guess. "Book" can be a noun or a verb, and it has no way of knowing whether your application addresses people formally or that your product name must be left alone.

Fill in context and it is sent with every batch:

Use it for what the application does, the register you want, and the terms that must not be translated. It is optional: leave it empty and nothing is added to the prompt. Translators that take no prompt, such as Google Translate, ignore it.

Translation keys are used as context too. Since they travel to the translator with their text, a key like nav.home says that "Home" is a navigation link and should be "Inicio" rather than "Hogar". The prompt states that keys may be used this way, not that they must: a key like common.name says nothing useful, and one inherited from an older part of the codebase can be misleading, so the text itself always comes first.

This is an example of the .env:

To use Claude as the translator for a scan run, pass --translator=claude:

You can also set it as the project default by changing default_translator in config/texts.php or via the default_translator config entry. The Claude translator uses the Messages API with prompt caching enabled on the system prompt, so repeated batches in a single scan reuse the cached instructions automatically.

Usage

Here is how you can use the blade directive and the text function:

Use the text() helper function to fetch translations within your PHP code.

Use the @text Blade directive to fetch translations within your views.

Auto-Generated Text from Keys

You can also use just the key without providing a default value. The system will automatically generate readable text from the key name:

The auto-generation works by:

• Taking the last part after dots (e.g., pages.contact_us → contact_us)
• Replacing underscores with spaces (e.g., contact_us → contact us)
• Capitalizing each word (e.g., contact us → Contact Us)

Replacement Texts (Placeholders)

You can include placeholders in your text strings using the :placeholder syntax. These placeholders will be preserved during translation and can be replaced with actual values when displaying the text.

Basic usage without replacements:

Usage with replacement values:

When these texts are scanned and translated, the placeholders (:name, :count, etc.) will be preserved in all target languages.

Plurals

Separate the forms with | and pass the quantity as count, which is the same syntax Laravel uses:

The form is chosen by Laravel's own selector, so the rules of each language apply. A language with three forms uses three, and the translated file drives the choice:

Explicit ranges work as well, for when the wording changes at a threshold rather than at the singular:

Both signals are needed for this to kick in, a | in the text and a numeric count in the replacements. A text that merely contains a pipe is returned untouched, so text('shortcut', 'Ctrl|Alt') keeps being Ctrl|Alt.

Note that the translator decides how many forms each language gets. Review the result for languages with more forms than your source language, and lock the key once it is right:

Scanning Translations

You can use the laratext:scan command to scan your project files for missing translation keys and translate them into multiple languages:

The scanner reads your source files statically, so the key must be a literal string. text($key) or text("prefix.$name") will work at runtime if the key already exists, but the scanner will never see it, so it is never created or translated.

An interpolated key is skipped, and it is worth avoiding for a second reason: the scanner cannot report it as missing, so a language that lacks it shows the raw key to the user and nothing warns you. Write one literal call per case instead:

Only the key is affected, and only when it genuinely interpolates, meaning a double-quoted string containing $. Single quotes never interpolate in PHP, so text('hol$a') is a valid key, and the default text and the replacements can be anything.

You can also specify the target language or the translator to use:

These are the command Options:

• --write: Write the missing keys to the language files.
• --lang: Target a specific language for translation (e.g., es for Spanish).
• --dry Report what a real run would do without writing anything and without calling the translator.
• --diff: Show the diff of the changes made.
• --resync: Retranslate every key from scratch, ignoring existing translations (use after changing translator or model).
• --only-missing: Only translate brand-new keys; skip keys whose source text has drifted (they are listed as warnings instead).
• --prune: Remove keys present in lang files but no longer referenced in code.
• --translator: Specify the translator service to use (e.g., openai or google).

Looking before spending: --dry

--dry compares your code with the language files and reports what a real run would do. It writes nothing and, more importantly, never calls the translator, so it costs nothing:

It combines with the other flags, so --dry --only-missing shows how many drifted keys would be left alone, and --lang=es narrows the comparison to one language.

Note that dropping --write is not the same thing. Without --dry the command translates and simply does not save the result, so it spends tokens all the same. --dry is the one that costs nothing.

Keeping Translations In Sync

By default, laratext:scan --write translates:

1. New keys: keys in code that don't exist yet in the lang files.
2. Drifted keys: keys whose source text in code no longer matches the value stored in lang/{defaultLocale}.json. These are retranslated in every target language so translations stay aligned with the source.

Skipping drift: --only-missing

If you want the conservative behaviour (translate only new keys, leave drifted keys untouched), pass --only-missing. Drift is still detected and printed as a warning, but no API calls are made for drifted keys:

Protecting reviewed translations: locking keys

--only-missing is all or nothing: it stops every drifted key from being retranslated. When a translator reviews a single string and you want that one string protected forever, lock it:

A locked key is never written by the scanner. It is not retranslated when the source text drifts, it is not touched by --resync, and it is not removed by --prune. Locks are per language, so protecting a Spanish correction still lets French follow the English source.

Unlocking is symmetric, and --all asks for confirmation because the damage only shows up on the next scan:

Locks live in lang/.locked/{locale}.json as a plain list of keys, so they are easy to review in a diff. Commit them: they are a decision about your translations, not local state. If nothing is locked the files do not exist and the scanner behaves exactly as it did before.

When a scan skips something, it says so:

That second line is also a saving: a key locked everywhere never reaches the API.

Forcing a full retranslation: --resync

--resync retranslates every key in your codebase from scratch, even keys whose source text has not changed. Useful when you've switched translator providers, upgraded the OpenAI model, or want to regenerate inconsistent translations left over from older runs. Expect this to be expensive in tokens.

Cleaning up orphan keys: --prune

--prune detects the opposite drift: keys that still live in lang/{locale}.json but are no longer referenced anywhere in code (removed text() / @text calls). By default it only lists them; combined with --write it removes them from every configured language file:

Recommended cadence

• During development: run php artisan laratext:scan --write after adding or editing @text / text() calls. New keys get translated; edited source texts get retranslated automatically.
• Periodically (weekly / pre-release / CI): run php artisan laratext:scan --write --prune to also drop orphan keys left behind by refactors.
• After switching model or translator: run php artisan laratext:scan --write --resync once to regenerate every translation against the new backend.

Creating translators

To create a custom translator, you need to implement the TranslatorInterface. This will define the structure and method that will handle the translation.

To facilitate the creation of custom translators, you can create a make:translator command that will generate the required files for a new translator class.

To create a translator run:

This will create the BeautifulTranslator.php file in the app/Translators directory:

The translate method, which translates a single string into one or more target languages, is required:

Optionally, you can implement the translateMany method to translate multiple texts in batch, which can improve performance when supported by the translation API:

If translateMany is not implemented, only single-string translations (translate) will be available for batch processing. For full support, both methods are recommended, so there are less requests and create a cost effective solution.

Laratext in the wild

Read how Kenodo uses Laratext for AI-powered Laravel i18n: English | Español.

License

Laratext is open-sourced software licensed under the MIT license.