Working with variable translation keys about laravel

[sybbear]

Another solution would be creating non-runnable scannable files that use those enums.

return [
   'enums' => [
       'user-roles' => [
            User::ROLE_ADMIN => p('enums.user-roles', 'admin')
       ]
   ],
];

And then creating a function to access those runtime.
Any thoughts on the subject are appreciated :)

[MichaelHoste]

Maybe it should be better explained in the docs, but if you have a definite set of enums to translate, you can just put these enums somewhere in the code (maybe in your model?) and they will be parsed by GetText:

// User.php
private const I18N_ROLES = [
  t('admin'),
  t('manager'),
  t('customer'),
];

Then, later, you can decide to call GetText directly with your role variable like this:

t($user->role)

or with the interpolated syntax (notice both t):

t("Your role is %s", t($user->role));

Since GetText will convert $user->role in runtime to one of "admin", "manager" or "customer", and since it already knows that these 3 words exist and have been localized, it will return the correct translation.

---

This method also works for an outside set of data (API etc.). Just create a small script that will reach the API and generate a dummy PHP file in your project directory that will contain all the words/sentences to translate. And then, execute this script
each time just before syncing.

Is this solution what you were looking for?

[sybbear]

Thank you for your input! I think as a generic solution, it works very well with specifying the keys separately.

As for scannable files, how does the concept sound like in general?

What value that brings is that if code ever gets refactored (e.g. constants removed, values changes), it would automatically update/remove the translation keys. While using an IDE, it would be also possible to track whether a particular constant is translated.
Search usages of a constant -> runnable-file.php -> See also translation parameters and context.

In theory, assuming there would be a PR with tests, what there be some reasons not to integrate it?
Could, of course implement some own standalone solution, but I'd find very convenient to have in one place.

[MichaelHoste]

As for scannable files, how does the concept sound like in general?

I'm sorry but I'm not really sure I understand what your solution would bring.

Your suggested scannable file (1) would be very similar to what I'm proposing (2) and both would be scanned and processed by GetText in the same way.

// (1)
return [
   'enums' => [
       'user-roles' => [
            User::ROLE_ADMIN => p('enums.user-roles', 'admin'),
            User::ROLE_MANAGER => p('enums.user-roles', 'manager'),
            User::ROLE_CUSTOMER => p('enums.user-roles', 'customer'),
       ]
   ],
];

// (2)
private const I18N_ROLES = [
    p('enums.user-roles', 'admin'),
    p('enums.user-roles', 'manager'),
    p('enums.user-roles', 'customer'),
];

What value that brings is that if code ever gets refactored (e.g. constants removed, values changes), it would automatically update/remove the translation keys. While using an IDE, it would be also possible to track whether a particular constant is translated.

It's also the case with the solution (2), or maybe I'm missing something.

In theory, assuming there would be a PR with tests, what there be some reasons not to integrate it?
Could, of course implement some own standalone solution, but I'd find very convenient to have in one place

I don't see any reason not to integrate it, but I'm not 100% convinced it would bring something more than what already exists.