[wp-trac] [WordPress Trac] #51871: Site Health actions that use the REST API receive an untranslated response

[WordPress Trac]

#51871: Site Health actions that use the REST API receive an untranslated response
--------------------------+--------------------------------
 Reporter:  oglekler      |       Owner:  TimothyBlynJacobs
     Type:  defect (bug)  |      Status:  assigned
 Priority:  high          |   Milestone:  5.6
Component:  Site Health   |     Version:  5.6
 Severity:  normal        |  Resolution:
 Keywords:  2nd-opinion   |     Focuses:  rest-api
--------------------------+--------------------------------
Changes (by SergeyBiryukov):

 * keywords:   => 2nd-opinion


Comment:

 For reference, this appears to be a result of moving async tests to REST
 API endpoints in [49154] / #48105.

 I can confirm the PR works as expected and the strings are displayed in
 Russian after I manually copy them from the `wp-content/languages/admin-
 ru_RU.po` file to `ru_RU.po` and rebuild the `ru_RU.mo` file with Poedit.
 As noted above, after the change is committed to core, the strings will be
 moved automatically.

 I do, however, have a couple of other concerns:
 * With this change, the front-end package will include ~250 more strings
 that are primarily used in the admin. This will increase memory footprint
 and might have performance implications similar to those previously raised
 in #19852. Granted, 250 is only 6% of all current front-end strings
 (4149), but still a non-trivial number. If there was a way to only move
 the async test strings we need and leave the rest in the admin, I think
 that would be better.
 * More importantly, I'm concerned with moving ~250 strings from the admin
 language project to the front-end while being in string freeze. I don't
 think translate.wordpress.org will handle that automatically, so
 translators will have to manually copy and approve each string. Granted,
 the strings should already be in translation memory, but copying,
 checking, and approving them is still a lot of work.

 As an alternative approach, could we load the admin language file on these
 requests instead, similar to how it's done in `load_default_textdomain()`?
 {{{
 load_textdomain( 'default', WP_LANG_DIR . "/admin-$locale.mo" );
 }}}
 That seems to also work as expected in my testing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51871#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform