Working with variable translation keys

[sybbear]

Hello,

I'm wondering if there is a way to register translation keys that come from other sources rather than being hardcoded.
Example use case is having a set of data (e.g. API or local constants), which need to be translated, but they would need to be changed over time.

I would envision a need for a separate scanning tool, that would require a script to be fully functional and therefore would be able to read variables/constants runtime.

Use example:

class User  {
    const ROLE_ADMIN = 'admin';
}

//dynamic-translations.php
rtp('enums.user-roles', User::ROLE_ADMIN);

//config/translation.php
'scan_runtime' => [
    'runnable-file.php'
];

//Result:
msgctxt "enums.user-roles"
msgid "admin"
msgstr ""

If one wants to change the value of ROLE_ADMIN to let's say, administrator, it would need to be done in just one place.
In theory, is this something that you would be eager to have as a part of your package?

[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.