# laravel-translations puts Laravel translation files behind a dashboard

> The outhebox/laravel-translations package gives Laravel 11 and 12 applications a browser UI and artisan commands for importing, editing, searching and exporting translation strings, at the cost of a database rewrite in v2. It suits teams that have outgrown hand editing of lang files, and it suits nobody who wants a dependency-free translation workflow.

**MohmmedAshraf/laravel-translations** — Laravel Translations UI package provides a user-friendly interface for managing translations in your Laravel application. It simplifies tasks such as adding, editing, deleting, and exporting translations. The package also includes a handy search feature and the ability to invite collaborators for easy translation management

- Repository: https://github.com/MohmmedAshraf/laravel-translations
- Stars: 821 · Forks: 114
- Language: PHP
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/mohmmedashraf-laravel-translations

## The problem it solves: lang files that only developers can edit

Laravel keeps translated strings in language files on disk. When a product team needs to change the wording of a button, the request usually lands with whoever knows the repository layout well enough to find the right key in the right nested array. This package exists to move that job to the browser. It provides a user friendly interface for managing translations, and the README is blunt about the scope: import, edit, search and export translations, all from a clean dashboard. The repository description adds that the package includes a handy search feature and the ability to invite collaborators for translation management, so the intended user is a team rather than a single maintainer.

The value is not the CRUD screen by itself. Laravel language files are nested PHP or JSON arrays with dotted keys used throughout the views, and the practical pain is that nobody outside the code base knows which key holds which sentence. Moving the strings into the package's database and exposing them through a dashboard means a non developer can find a key by reading its value rather than by guessing a file path.

Two details shape how far you should trust that promise. The first is that this is an application level package with migrations, a published config file and a route mount at /translations, so it is part of your deployable surface, not a build time helper. The second is that the README points to a separate commercial product, Laravel Translations Pro, for AI powered translations, revision history and team collaboration. The MIT package covers the core dashboard and the artisan commands. Anything beyond that core is a different product with a different price.

## Installing the package and reaching the /translations route

The requirements are stated plainly: PHP 8.3 or newer, and Laravel 11.x or 12.x. Installation is a Composer require followed by an install command that publishes assets, config and migrations.

```bash
composer require outhebox/laravel-translations
```

```bash
php artisan translations:install
```

The install command is the step that makes the UI reachable. It publishes the assets, the configuration and the migration files, so skipping it leaves you without a route to visit. After it runs, the migration needs to be applied.

```bash
php artisan migrate
```

With the migration applied, the README tells you to visit /translations in your browser. Note that this route is a mounted dashboard, not a configuration-free default you can rely on being safe in production. The README does not describe a default authorization rule for the route, and the published config file is where middleware and authentication are configured, so you should publish it and set those values deliberately before you expose the path to a network.

One design choice here is worth calling out because it is unusual for a modern Laravel package: the README states that no npm or Vite is required in your project. The repository does contain a vite.config.ts, a package.json with React, Inertia and Tailwind dependencies, and a resources directory, but those belong to building the package itself. The shipped frontend arrives as compiled assets, which is why a consuming application does not need a JavaScript toolchain.

## Import, export and status commands that share the dashboard's data

The command line mirrors the interface, and the two can be mixed. Imports are done with an artisan command, and the existing translations are overwritten when the fresh flag is passed.

```bash
php artisan translations:import
```

```bash
php artisan translations:import --fresh
```

Exports run the other way, writing the edited strings back out to files so that a deployment or a pull request can carry the changes.

```bash
php artisan translations:export
```

A status check is also provided.

```bash
php artisan translations:status
```

The README does not document in detail what the status command reports, nor which file formats the import accepts or which files the export writes, so the exact semantics of a round trip are not something you can confirm from the documentation alone. That matters for the fresh flag, because it is described only as overwriting existing translations, with no mention of a backup step. If you run it in a shared environment, treat it as destructive until you have verified what export produces first.

The pragmatic pattern the commands support is import to seed the dashboard, edit in the browser, export to produce files, and commit those files. That keeps translation changes reviewable in version control while still letting a product manager type the sentences. The command surface is small, five verbs in total, which makes it easy to script into a deployment or a scheduled job without a lot of surface area to learn.

## The published config file governs path, middleware and source language

Everything about the integration is described in one published file. The README gives the publish command for it explicitly.

```bash
php artisan vendor:publish --tag=translations-config
```

That produces config/translations.php, which the README describes as the place to configure the path, middleware, authentication, source language, and import and export settings. This is the single most important file in the package for an adopter, because the defaults are what determine whether the dashboard is reachable, which directory it reads, and which language is treated as the source of truth during an import.

Middleware and authentication are named as configuration points rather than as defaults, which means the route protection is your responsibility. If your application serves both an admin area and a public site, the /translations path belongs behind whatever guard and stack you already use for administrative screens. The README does not give a recommended middleware stack, so there is no documented answer to copy, and you will have to pick one from your own application.

The source language setting also determines the direction of an import. An import reads from the configured path and source language, and the export writes back. If your application uses a source locale plus several targets, the source language key decides which set is treated as canonical during the import, and getting it wrong can leave the target locales empty after the first import. That is worth checking against your config/translations.php before you run translations:import in an environment that already has strings in production.

## The v2 rewrite is a breaking change with a data migration path

Version 2 was a full rewrite, and the README is explicit about what that means for anyone on v1. The upgrade path exists, but it involves a namespace change, a frontend replacement and a new database structure, so it is a migration project rather than a version bump.

The package name is the Composer package, and the version constraint for the new major line is given directly.

```bash
composer require outhebox/laravel-translations:^2.0
```

Existing v1 data is then converted by a dedicated command, which the README says detects the v1 tables and migrates languages, groups, keys and translations into the new structure.

```bash
php artisan translations:upgrade
```

Old tables can be dropped afterwards, optionally.

```bash
php artisan translations:upgrade --cleanup
```

Finally the new assets are published with the same install command used for a fresh setup.

```bash
php artisan translations:install
```

Three breaking points are listed: the namespace moves from Outhebox\TranslationsUI to Outhebox\Translations, Vue is replaced with React (the README notes no action is needed because the assets are pre compiled), and the config structure changed so it must be re published with the translations-config tag. The namespace move is the one that will surface as a fatal error in code that imported classes directly, since any custom controller or listener referencing the old namespace has to be rewritten by hand. The Vue to React change is the reason the repository still lists vue among its topics while the current code and the upgrade notes point to React and Inertia, so treat the topic list as a legacy artifact rather than a description of the current stack.

## Limits worth knowing: a fixed route, pre built assets and a paid tier for the rest

Three constraints come straight out of the documentation. The first is that the dashboard lives at /translations and the README gives no alternative mount point, so an application that already reserves that path, or that wants the tool out of the public URL space, will need to work around it rather than configure it.

The second is the pre compiled frontend. Because the assets ship built and require no npm or Vite in the consuming project, there is no documented path for restyling the dashboard to match an existing design system. The Tailwind and Headless UI dependencies in the repository package.json belong to the package's own build, and the README describes no theme override. If your evaluation of a package like this depends on matching your design system, you should confirm that with the maintainer before committing to it.

The third is the split between the MIT package and the Pro product. AI powered translations, revision history and team collaboration are advertised under Laravel Translations Pro, not in the open source package. The MIT licence covers the core dashboard and commands, and the README points to a separate LICENSE.md file for the terms. If your rollout depends on having an audit trail of who changed which string, the open source package does not document revision history, and you should not assume the export and import cycle gives you one.

For contrast, the alternative approach to the same job is to keep strings in language files and edit them directly in an editor or through a spreadsheet that generates PHP or JSON. That approach has no database layer, no migration and no dashboard route to secure, but it requires someone comfortable with the repository to make each change. The trade is simple: this package spends a migration, a route and a config file to let non developers do the editing.

## Maintenance and upgrade cost

The repository is not archived, and the last push was on 2026-07-12. Releases in the recent list follow the same date, with v2.1.1 published on 2026-07-12, v2.1.0 on 2026-04-07 and v2.0.2 on 2026-02-22, so the tagged versions and the last push line up.

The upgrade cost has two parts. The first is recurring and small: after updating the package, the assets have to be re published, and the README offers to automate this in composer.json.

```json
{
    "scripts": {
        "post-update-cmd": ["@php artisan translations:update --ansi"]
    }
}
```

The second is one-off and larger, for anyone arriving from v1, because the v2 upgrade command, the namespace rewrite and the config re publication all have to be done together.

Licensing is MIT, so the core package can be used, modified and redistributed under those terms. No legal advice is offered here beyond reading LICENSE.md, and note that the commercial Pro product is a separate purchase rather than an open source upgrade path.

## Conclusion

Adopt laravel-translations if you run Laravel 11.x or 12.x on PHP 8.3 or newer and want non developers to change translated copy through a dashboard, and accept that the strings then live in your database rather than in PHP files. Skip it if your translation set is small, if you need frontend sources you can edit yourself, or if the Pro features such as AI translation and revision history are the real requirement, since those sit in a separate paid product. Before installing, confirm the published config/translations.php exposes the path, middleware and source language you expect, and check whether translations:import --fresh would overwrite translations that already exist.

## FAQ

### What are the requirements for installing laravel-translations?

The README states PHP 8.3 or newer and Laravel 11.x or 12.x. Installation is done with composer require outhebox/laravel-translations followed by php artisan translations:install and php artisan migrate.

### Do I need npm or Vite to use laravel-translations in my Laravel app?

No. The README says no npm or Vite is required in your project, because the frontend assets ship pre compiled. The repository does contain a vite.config.ts and React, Inertia and Tailwind dependencies, but those are used to build the package itself.

### How do I move existing translations into laravel-translations, and will the import overwrite my strings?

Run php artisan translations:import to load existing translations into the dashboard, and php artisan translations:import --fresh to overwrite existing translations. Export the result with php artisan translations:export to write the strings back out.

### What happens to my data and code when I upgrade laravel-translations from v1 to v2?

The README describes v2 as a full rewrite. Run php artisan translations:upgrade to migrate v1 languages, groups, keys and translations into the new structure, and php artisan translations:upgrade --cleanup to drop the old tables. The namespace changes from Outhebox\TranslationsUI to Outhebox\Translations, and Vue is replaced with React.

### Where is the laravel-translations dashboard route and how is it protected?

The README tells you to visit /translations in your browser after installing and migrating. Protection is a configuration matter: publishing the config file with php artisan vendor:publish --tag=translations-config produces config/translations.php, where middleware and authentication are set.

## Sources

- [Issues](https://github.com/MohmmedAshraf/laravel-translations/issues)
- [License: MIT](https://github.com/MohmmedAshraf/laravel-translations/blob/main/LICENSE)
- [MohmmedAshraf/laravel-translations on GitHub](https://github.com/MohmmedAshraf/laravel-translations)
- [README](https://github.com/MohmmedAshraf/laravel-translations/blob/main/README.md)
- [Releases](https://github.com/MohmmedAshraf/laravel-translations/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mohmmedashraf-laravel-translations