- Is sylius/ui-translations a Laravel package?
- No. It is a Sylius and Symfony translation resource bundle, not a Laravel package, and it has no architectural fit in Laravel or framework-agnostic PHP without a rewrite. Evaluate it only if your application actually runs Sylius.
- Can I use sylius/ui-translations in Laravel 10 or 11?
- No. It assumes Symfony's Translator component and Sylius's translation conventions, and there is no Laravel service provider, config, or Laravel language-file integration. Using it in Laravel would require a rewrite, so choose Laravel language files or a Laravel-specific i18n package instead.
- How do I install sylius/ui-translations in a Sylius project?
- You normally get these translations by using Sylius, which already bundles them, rather than by directly wiring this read-only subtree split. Add or upgrade Sylius in your application and let its dependency set provide the package. Then add app-level translation overrides for any project-specific terminology or gaps.
- Which Sylius, Symfony, and PHP versions does sylius/ui-translations support?
- There is no independent support matrix for this repository because it is a subtree split published from the Sylius monorepo. Compatibility follows the Sylius release that ships it, including that release's Symfony and PHP constraints. Confirm the exact matrix in your Sylius composer.lock and upgrade plan rather than treating this package as independently versioned.
- What locales are included in sylius/ui-translations?
- The package ships per-locale message catalogs, but there is no public per-locale coverage contract or SLA in the repository. You must measure coverage empirically for your target locale and the admin flows you use, such as orders, catalog, promotions, and customers. Do not assume complete translation coverage from the package name alone.
- How do I override a Sylius UI translation string in my application?
- Add locale-specific translation files in your host application using Symfony's standard translations conventions so your keys take precedence over Sylius defaults. Keep a list of every override because each one must be re-audited after Sylius upgrades. For corrections that benefit everyone, contribute upstream to the Sylius monorepo rather than this read-only repository.
- Does sylius/ui-translations provide an admin UI for editing translations?
- The package description frames it as a collection of ready-made translation resources, not an active CRUD plugin. Prior notes describing an admin translation editor conflict with that description, so confirm which artifact you are evaluating before committing scope. If you need admin editing, that is a different requirement and likely a different package or custom build.
- Is sylius/ui-translations production-ready, and how should I test it?
- It can be production-safe only inside a supported Sylius application, because runtime behavior is inherited from Sylius and Symfony. Test each target locale against the admin and shop flows you actually use, and record coverage gaps instead of assuming completeness. Plan an override and re-audit process for every Sylius upgrade, because terminology drift is the main production risk.
- Is sylius/ui-translations actively maintained?
- Treat it as a read-only subtree split published from the Sylius monorepo, with no independent release cadence, issue queue, or changelog. Maintenance follows Sylius itself, so your update path is a Sylius upgrade rather than a package-level release. Rely on Sylius's broader adoption for evidence, not this repository's zero-star and zero-dependent signals.
- What are alternatives to sylius/ui-translations for Laravel or non-Sylius apps?
- For Laravel, use Laravel language files, a Laravel translation package, or a TMS integration; sylius/ui-translations is not an alternative there. For Sylius, the options are inheriting Sylius translations, overriding strings in-app, contributing upstream, or maintaining a private fork. If you are not on Sylius, treat this package as reference only and exit the evaluation.