Weave Code
Translator Bundle Laravel Package
kunstmaan/translator-bundle
A Symfony bundle for managing translations across your project with a web interface for editing, importing, and exporting language files. Supports multiple translation backends and integrates with the Kunstmaan CMS ecosystem.
The KunstmaanTranslatorBundle adds a browser-based translation management layer to Symfony applications. Instead of hand-editing YAML/XLIFF files, translators get a dedicated interface to search, add, and edit messages across every configured locale, backed by pluggable translation sources.
- Web UI for browsing and editing translations per locale
- Automatic extraction of translation keys from templates and code
- Pluggable sources (e.g. live files vs. database storage)
- Configurable locales and import/export workflows
- Seamless integration with the Symfony Translator component
Ideal for projects where non-developers maintain multilingual content.
Frequently asked questions about Translator Bundle
- Is kunstmaan/translator-bundle a Laravel package?
- No. It is a Symfony bundle that ships a Symfony DI extension, a Doctrine ORM entity, a TranslatorInterface loader and an admin CRUD screen. There is no service provider, no facade and no Laravel-compatible translation loader, so a Laravel application cannot consume it. Even the repository is only a read-only subtree split of the KunstmaanBundlesCMS monorepo.
- Can I install kunstmaan/translator-bundle on PHP 8 or Laravel 11?
- No. The last release is from 2014-08-01 and targets PHP 5.4 to 5.5 with Symfony 2.3 to 2.6, so Composer platform resolution fails outright on PHP 8.x. Even with --ignore-platform-reqs the code would break on removed APIs such as TranslatorInterface signatures, the Controller base class and getRequest(). This is not an integration task, it is a rewrite using the source as reference.
- Which Symfony, PHP and Doctrine versions does the TranslatorBundle support?
- The bundle targets Symfony 2.3 through 2.6, Doctrine 2.4 with annotations-based mapping, and PHP 5.4 to 5.5. The admin UI is built on a Bootstrap 2/3 era theme inherited from the Kunstmaan CMS admin stack. There is no support for Symfony 5, 6 or 7, and no PHP 8 support.
- How do I install and configure Kunstmaan TranslatorBundle in a Symfony application?
- Historically you registered the bundle in AppKernel, imported its DI extension configuration, created the Doctrine translation entity schema and wired the admin CRUD routes. In practice the admin screens depend on the Kunstmaan Bundles CMS admin stack, which is itself derived from Sonata Admin. It is not a standalone drop-in bundle for a plain Symfony app.
- Does the Translator Bundle work without the Kunstmaan Bundles CMS?
- The admin interface does not, because the CRUD screens are built on the Kunstmaan CMS admin stack. The genuinely reusable idea is narrow: store translations in a database table and load them through a caching translator loader. That loader piece would still need to be rewritten against modern Symfony cache and translator contracts to be usable on its own.
- What is a good Laravel alternative to kunstmaan/translator-bundle?
- For Laravel the maintained equivalent is a database translation loader such as spatie/laravel-translation-loader combined with a CRUD screen in Filament or Nova. That gives you the same edit-translations-without-touching-files outcome in a few days, with active maintenance and no Symfony dependency. If a translation vendor already exists, integrating Crowdin, Phrase or Lokalise usually beats building an in-house admin screen.
- Is kunstmaan/translator-bundle abandoned or still maintained?
- It is abandoned. There has been no release in roughly eleven years, the bundle has zero dependents and around fifty stars, and the repository is a read-only subtree split with no maintenance signal. That means no upstream security patching, no PHP 8 support and no compatibility work for current Symfony versions. The only clean item is licensing: it is MIT, so forking is legally unencumbered.
- What are the security risks of a database-backed translation editor?
- The bundle's core value proposition is letting admins write strings that render into every page, which is a stored-XSS and format-string injection vector by design. With no upstream maintainer there is nobody to patch that surface, so escaping and placeholder validation become your responsibility. You also inherit cache invalidation on edit, multi-node cache coherence and a DB-unavailable fallback that must never render raw keys to users.
- How do I replace file-based Symfony translations with a database loader?
- The maintainable path is roughly 200 to 400 lines of your own code: a TranslatorInterface-compatible loader reading a translation table, a cache warmer, and a CRUD form in EasyAdmin or Sonata. Keep YAML or XLIFF files as the source of truth in the repo and treat the database as a runtime override layer, resolving DB then files then key. Ship import and export commands so deploys, code review and rollback keep working, and enforce a single sync direction in CI to avoid drift.
- How much work is forking kunstmaan/translator-bundle for PHP 8 and Symfony 6?
- Realistically two to four engineer-weeks including tests: PHP 5.4 to 8.2, Symfony 2.x to 5.4 or 6.x, annotations to attributes, getRequest() to RequestStack, the deprecated admin asset pipeline and updated Doctrine mapping. A clean custom loader that delivers the same outcome typically takes about one week and leaves you with modern PHP and your own security posture. Forking is only justified if you are already running the Kunstmaan CMS and cannot move off it.
Weaver
How can I help you explore Laravel packages today?