Translation architecture and tooling

Before the first string is translated, a project has already made choices that are expensive to reverse: where translations live, who can change them, how they are loaded, and what happens to them at deploy time. Lang files in the repository, a database table, a package with an admin screen and a hosted translation platform each answer those questions differently.

The articles in this category compare the options on the things that decide it in practice: what each costs at request time, how it behaves with many locales, what breaks at scale, and where each stops being the right tool.

Keep going

Frequently asked questions

Should Laravel translations live in files or in a database?

Interface strings belong in language files or a translation service, where they are versioned and loaded once per request group. Content that users create, such as product names, belongs in the database next to the record. Mixing the two is where most confusion comes from.

Does loading translations slow a Laravel app down?

Rarely in a measurable way. Laravel loads a translation group the first time a key from it is requested and keeps it in memory for the request. Problems appear with very large JSON files or with loaders that query a database per key.

When does a team outgrow a translation manager package?

Usually when non-developers need to edit text, when several projects share strings, or when changes have to go live without a deploy. A package that writes to lang files still needs a release to reach production.

We'd like to use analytics and marketing cookies to understand how the site is used. They stay off unless you accept them. Cookie Policy