You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optional support using javaabu/translatable's contract for other packages: in suggest, feature-detected, documented on its own page, and tested with and without it.
Blocked until javaabu/translatable v3's contract for other packages exists (wave 2; tracked in n4ff4h/translatable#10).
The likely shape here: role descriptions translatable through that contract, feature-detected with interface_exists(). Today role descriptions are free text, and permission descriptions and labels are translation keys, so nothing depends on it.
Done on next-gen with translatable v3's contract (n4ff4h/translatable#10); CI green, including a job with translatable removed.
Suggest and dev only:javaabu/translatable is in suggest and require-dev. Support\Translations wraps every check (class_exists first).
Translated field: the role description. Names are identifiers, and permission descriptions are already JSON translation keys.
Model: the package ships Models\Translatable\Role (JSON storage, keeps the base morph class). Apps opt in by setting permission.models.role to it. Decision: no automatic swap, because spatie's registrar reads the role class once, at boot.
Migration:add_translations_to_roles_table adds nullable translations and lang columns, and runs with or without translatable.
Forms and API:RoleRequest expands its rules with Translatable::rules(). The Blade form uses <x-translatable::text>; the React form renders one Text per input from the translations prop, with dir, lang and thaana. RoleResource adds translations.
Tests:tests/Translatable is its own PHPUnit suite. CI runs the Package suite with translatable removed.
Activity
n4ff4h commentedon Nov 4, 2026
Blocked until javaabu/translatable v3's contract for other packages exists (wave 2; tracked in n4ff4h/translatable#10).
The likely shape here: role descriptions translatable through that contract, feature-detected with
interface_exists(). Today role descriptions are free text, and permission descriptions and labels are translation keys, so nothing depends on it.Add the role pages in Blade and Inertia React (work in progress)
Test the role pages in both stacks and with translatable; CI for JS a…
Document the role pages, translatable descriptions and right to left;…
n4ff4h commentedon Nov 4, 2026
Done on
next-genwith translatable v3's contract (n4ff4h/translatable#10); CI green, including a job with translatable removed.javaabu/translatableis insuggestandrequire-dev.Support\Translationswraps every check (class_existsfirst).description. Names are identifiers, and permission descriptions are already JSON translation keys.Models\Translatable\Role(JSON storage, keeps the base morph class). Apps opt in by settingpermission.models.roleto it. Decision: no automatic swap, because spatie's registrar reads the role class once, at boot.add_translations_to_roles_tableadds nullabletranslationsandlangcolumns, and runs with or without translatable.RoleRequestexpands its rules withTranslatable::rules(). The Blade form uses<x-translatable::text>; the React form renders oneTextper input from thetranslationsprop, withdir,langandthaana.RoleResourceaddstranslations.tests/Translatableis its own PHPUnit suite. CI runs thePackagesuite with translatable removed.docs/advanced-usage/translatable-roles.md.