[samuelsov]

Overview

First step towards multilingual SearchKit. This makes core SearchKit compatible with multilingual installation. Columns, links and buttons are translated as expected.

Before

The ts function in .mgd.php files is only used once to insert the data in the database. At runtime, there is no translation so this works ok for monolingual installation but not for multilingual.

After

The ts are removed from the .mgd.php files and the translation is done at runtime in the API SearchDisplay::get

Comments

This is just a first step as we need to:

• fix SK in civicrm_admin_ui and maybe other extension shipped in core that used E::ts instead of ts
• ensure that it still works as before for SK which have E::ts in them.
• change the export to remove the E::ts
• make it work or fix odd cases like in SavedSearch_Scheduled_Jobs_Log.mgd.php, where we have ts in rewrite

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[colemanw]

@samuelsov what needs to happen to move this forward?

[samuelsov]

@colemanw The part done is working (SK table header is translated) but this is just not enough as it is:

• we need to fix civicrm_admin_ui (not complicated, just a big search/replace for the most part)
• some SK table content are still untranslated but I don't remember the details at this stage.

My plan is to finish all this in December so that it's committed into 6.11

[samuelsov]

I did a new pass. I think we are good to go.

A few notes:

• the translation will check where the SearchKit comes from and apply the domain translation if needed
• I haven't fixed the SavedSearch export yet (don't know where to look)
• remaining ts and E::ts in .mgd.php files will work as before, i.e. translating the string when clearing the cache. The new code will try to translate but it simply won't find any translation if it's already translated in the database (but works ok if in en_US when clearing the cache)
• this add a dynamic translation even for monolingual sites because the translation is not in the DB anymore

[colemanw]

This label is a database column, not part of the settings blob.

[samuelsov]

Ok, I limited the search/replace to SavedSearch.mgd.php and kept the 'label' that are preceded by 'name' as is.

[samuelsov]

@colemanw Once civicrm/civistrings#25 is reviewed, I think we're good to go with this one ?

[samuelsov]

@colemanw Ok,now that civicrm/civistrings#25 is merged, I've done a rebase and separated in 2 commits so that's easier to see the php code changes vs the mgd.php changes. Ideally, we need a fast merge to avoid having conflict with other mgd.php changes.

[colemanw]

@samuelsov we also need to change the code generator to not add E::ts() when it generates mgd.php files for searchKit displays... but only within the scope of the settings array. Hmm, that's a little tricky.

[samuelsov]

@samuelsov we also need to change the code generator to not add E::ts() when it generates mgd.php files for searchKit displays... but only within the scope of the settings array. Hmm, that's a little tricky.

Yes, I was thinking about that. I don't think it should block this PR but I'll try to fix that asap.