Download the PHP package brunoscode/twill-translation-handler without Composer

On this page you can find all versions of the php package brunoscode/twill-translation-handler. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of brunoscode/twill-translation-handler

Informations about the package twill-translation-handler

Twill Translation Handler

A Twill CMS capsule for managing Laravel translations directly from the admin panel. Built on top of LaravelTranslationHandler.

Latest Version on Packagist GitHub Tests Action Status GitHub Code Style Action Status Total Downloads

Twill compatibility: Currently supports Twill 3 (Laravel 11–13, PHP 8.2+). Twill 2 support is available in the v0.x releases.

Table of Contents

Supported versions

Package version PHP Laravel Twill
v2.4 8.2 · 8.3 · 8.4 11 · 12 · 13 3.x (3.6+ on Laravel 13)
v2.2 8.2 · 8.3 · 8.4 11 · 12 3.x
v2.0 8.2 · 8.3 11 3.x
v1.x 8.1+ 10 2.x

Features

Requirements

Laravel PHP Twill
11 8.2 · 8.3 · 8.4 3.x
12 8.2 · 8.3 · 8.4 3.x
13 8.3 · 8.4 3.6+

Installation

Publish the config (step below). Without it, the core package's defaults win the config merge: translations go through the core DatabaseHandler, so groups are never created, only the en locale is handled and imports default to JSON instead of the database.

Run the migrations:

The package loads its own migrations: they create translation_keys and translation_values when missing, or add the Twill columns to the tables of an existing LaravelTranslationHandler install. You do not need the core migrations. If you publish them anyway, they skip the tables that already exist (since LaravelTranslationHandler v2.8.1), so migrate keeps working in either order.

Publish the config file:

Both this package and LaravelTranslationHandler publish config/translation-handler.php. Publish this one: it holds every core option plus the Twill defaults (dbHandlerClass, database as source of truth, legacy-twill-navigation). Do not also run the core's translation-handler-config tag, it would overwrite the file with the core defaults.

Optionally publish the views to customise them:

Navigation

The package provides three sub-pages:

TwillNavigation builder

If your app uses the newer TwillNavigation builder API, disable the automatic registration in config/translation-handler.php:

Then register the entries in your AppServiceProvider (or wherever you build your Twill navigation):

If you have a custom admin_route_name_prefix, replace twill. accordingly:

Legacy twill-navigation config array

By default the package registers the navigation automatically via the legacy twill-navigation config array. The package will merge the translations key into the array at boot. To control where it appears in the sidebar, add an empty placeholder in the right position — PHP arrays preserve the insertion order of existing keys:

Configuration

See LaravelTranslationHandler for the full list of configuration options.

locales decides which locales are exported to the lang files, and the group edit page offers exactly those. The key edit page uses Twill's translatable.locales instead: keep the two lists identical, otherwise a value saved for a locale missing from locales stays in the database and never reaches a lang file.

Usage

Once installed, a Translations section will appear in the Twill admin navigation with three pages:

Keys

Lists all translation keys stored in the database. Each key can be opened to edit its translated value for every configured locale. Translation keys are managed exclusively through import — manual creation is intentionally disabled to keep the database in sync with source files. The search box matches both keys and values.

Groups

Lists all translation groups, auto-generated from the key prefixes. Every import or sync into the database creates the missing groups and deletes the ones no key belongs to any more. Opening a group shows all matching keys in a repeater, allowing batch editing of every locale's value from a single form. The search box matches prefixes, keys and values.

Import / Export

A tools page with actions to sync translations:

Action Description
Import from CSV Uploads a CSV file, imports all translations into the database, and writes the PHP language files
Export to CSV Downloads all database translations as a CSV file

Per-group CSV export is also available directly from each group's edit page.

CSV import rules

PHP language files are kept in sync automatically: every import (CSV via the tools page or per-group) writes the affected PHP files immediately after updating the database. Saving a single key or group from the edit form also triggers the same export.

Editorial interface

Editing a key

Opening a translation key shows:

Field Behaviour
Key Read-only. Keys are created only via import.
Value Translatable textarea — one tab per configured locale.
Allow empty Checkbox (sidebar). See below.

Saving a key immediately exports the affected PHP language file.

Editing a group

Opening a group shows the prefix (read-only) and one textarea per translation key that belongs to the group. Each textarea is translatable — every configured locale is available as a tab. A Download CSV button lets editors export the group directly from the edit page.

Field naming: each textarea is internally keyed as trans_<id> where <id> is the translation_keys.id. This is transparent to editors but relevant if you extend the form.

Saving a group writes all locale values, marks them active and immediately exports the affected PHP language file. The save is refused with a validation error, before anything is written, when it would leave the lang file with a key that is both a value and a parent (e.g. auth.a and auth.a.b), or when it carries a locale missing from translation-handler.locales.

allow_empty

Both modules show an Allow empty checkbox in the sidebar. Its effect is on form validation:

Module allow_empty unchecked allow_empty checked
Keys Value is required for every locale Value is nullable — empty strings are accepted
Groups Every locale value of every key is required Empty values are accepted (locale and key conflict checks still apply)

When a value reaches the repository as null (e.g. the editor cleared a field), it is normalised to an empty string before being persisted. This means the database never stores null in translation_values.value through a form save.

Deployment

The database is the source of truth for translation values. PHP language files are used only to carry new keys and new locales between environments.

A typical deploy script:

The first command (without --force) inserts only keys and locale entries that do not yet exist in the DB — existing values are left untouched. The second command rewrites the PHP files so they always reflect the DB state.

First deploy / fresh environment: if the DB is empty, seed it from the PHP files:

Syncing translations from production

When content editors have updated translations directly in production or staging, you can pull those changes back into the repository:

  1. Download the CSV from the production admin panel via Translations → Import / Export → Export to CSV.

  2. Copy the file into your project (e.g. storage/lang/translations.csv) and import it to regenerate the PHP files:

  3. Commit the updated PHP files and push:

The next deploy will import the updated PHP files into any environment whose DB does not yet have those values.

AI integration (Laravel Boost)

The underlying LaravelTranslationHandler exposes its translation operations as Model Context Protocol tools through Laravel Boost. Boost is an optional dependency — install it only if you want an AI agent (e.g. in your editor) to read and edit translations directly.

Once Boost is installed the core package auto-registers the translation MCP tools — no configuration. Any MCP-compatible agent (Claude, Cursor, GitHub Copilot, …) can then browse and edit translations directly. They cover the same operations as the admin panel and CLI:

The tools are registered by the core package and operate on the same database and language files described above. See the LaravelTranslationHandler README for the full tool reference.

Guidelines and skills

Running php artisan boost:install and selecting twill-translation-handler (guidelines, skills) installs an AI guideline plus two skills — translation-handler-mcp (the agent workflow) and translation-handler-development (writing custom PHP) — into your editor's agent. This package ships them because Boost only discovers the guidelines and skills of direct Composer dependencies: in a Twill app the core laravel-translation-handler package is a transitive dependency, so its own Boost resources would never be offered. The content is read live from the installed core package at install time, so it always reflects the installed laravel-translation-handler version, plus a Twill-specific note on editing translations from the admin.

Database Structure

Table Description
translation_keys Translation keys (key, published)
translation_values Per-locale values (locale, value, active)
translation_groups Group prefixes (prefix, published)

Testing

Changelog

Please see CHANGELOG.md for what has changed recently.

Credits

Contributing

Contributions are welcome! Please submit a pull request or open an issue to discuss what you would like to change.

License

The MIT License (MIT). Please see License File for more information.

All versions of twill-translation-handler with dependencies

PHP Build Version
Package Version
Requires php Version ^8.2
area17/twill Version ^3.0
brunoscode/laravel-translation-handler Version ^2.8.1
laravel/framework Version ^11.0|^12.0|^13.0
spatie/laravel-package-tools Version ^1.16
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package brunoscode/twill-translation-handler contains the following files

Loading the files please wait ...