Laravel Translations — overview

The bug that ships#

Laravel's own MessageSelector returns six plural indices for Arabic — 0, 1, 2, 3, 4 and 5 for the counts 0, 1, 2, 3, 11 and 100. So an Arabic trans_choice string needs six segments separated by |.

English needs two. A translator who has only ever seen English gives you two. Nothing complains — not the framework, not the existing translation managers — and in production trans_choice('items', 3) returns the wrong form, or the raw string with its pipes showing.

One step down, the same shape: :name present in the English string and missing from the Arabic. The page renders without the name, and every test passes.

Pointed at Laravel's own published Arabic translations, this finds two of those: mimes and mimetypes both drop :attribute, so a user is told their file is the wrong type without being told which field.

Why a linter rather than another manager#

Their open issues are not about missing features. They are about the shape:

• #445 — "How can I use this lib in production environment?" It wants a database table and a web UI, and people do not want either on a production box.
• #442 — the scanner does not read @lang in Blade.
• #449 — the UI breaks when a string contains {...}.
• #456 — nested arrays are lost in export.
• #435 — export is broken for subdirectories.

Both are a database and a UI bolted onto a file problem, and the database and the UI are where they break. So this is neither: a set of commands over the files you already have, that runs in CI and cannot break in production because it does not run there. The service provider registers nothing outside the console.

The six checks#

missing · unused · placeholder · plural · empty · same — each a reason code, with the file and line, and a non-zero exit.

The plural counts come from Laravel's own getPluralIndex, so the linter and the framework cannot drift apart. A string using explicit ranges — {0} none|[1,*] some — is the author declaring how many forms there are, and the check stands back.

One thing found by running it on real data#

An earlier version reported الحقل:attribute as a missing placeholder. It is not: no space before a placeholder is ordinary in Arabic and Laravel replaces it perfectly well. The cause was a lookbehind of (?<![\w:]) — and PCRE2's \w under /u counts an Arabic letter as a word character, so every placeholder written that way was reported missing.

That would have made the tool useless for exactly the language it was written for, and no synthetic fixture would have caught it. It came from pointing the thing at Laravel's published Arabic pack and reading the output.

What we do not claim#

That barryvdh's package is bad. It has 1,701 stars for a reason, and a web UI is genuinely what a non-technical translator wants. If you want people editing strings in a browser, use it — and use this in CI as well.

Translation memory or machine translation. Both are somebody else's API and neither belongs in a linter.

Perfect unused detection. A key reached through a variable looks unused. Those files are reported by dynamic() rather than guessed at, and unused is the check to leave out of a build.