I would expect the layouts to be localized to the language of the site.
The text on page layouts will be localized based on the user account language, not the site's language. Conversely, if the user's account is set to Spanish, the layouts will be added in Spanish, even if the site's language is set to English.
Chrome Version 78.0.3904.97
MacOS 10.13.6 (17G2307)
Account [EN]:
Site [ES]:
Result [EN]:
Looks the same issue #38776 but leaving both open just in case.
2680626-zen Another case of a user where switching site language from French to English still didn't trigger Page louts to show on Mayland Theme. Only after switching account language from French to English Page Layouts appeared.
@zdenys There are currently no templates that are translated to French, so French users will always be served English templates.
Conversely, if the user's account is set to Spanish, the layouts will be added in Spanish, even if the site's language is set to English.
Have you actually tried that? Because I could not reproduce it.
@mrfoxtalbot @apeatling Could you help me reproduce the user language issue with a language other than English?
I'm able to reproduce the original reported behavior. The SPT template content follows the user's UI locale and not the site's locale.
Switching the UI locale to another language (i.e. ES) reduces the number of homepage templates to just those with a "translated" annotation (Dalston, Leven, Redhill, Rivington, Stratford), but there seems to be the additional issue that some of these annotations are supposed to be translated, but still have english strings in them (i.e. /wp-content/themes/pub/redhill/inc/headstart/es.json#180).
UI: Spanish, Site: English:

UI: Spanish, Site: English, "false positive" translation:

UI: English, Site: Spanish:

@obenland @apeatling: to start, I'll open a diff to remove the "false positive" translations from the backend. That should at least have the API returning the correct translated content. Then we'll need to troubleshoot the API request to see where it's getting switched from the site locale to the user locale.
It looks like we're filtering get_locale() and return the user locale because we're calling it from the admin. Next steps for troubleshooting would be to find out which callbacks are hooked to locale and which ones we'd need to unhook to get the blog locale.