Wp-calypso: Translated patterns UI vs content

[simison]

A couple confusing points around translated patterns and translated patterns UI:

Steps to reproduce

Account English, site Spanish

1. Have your UI language in English
2. Have your site's locale in Spanish
3. Open block editor and patterns inserter
4. Note:
   
   
   
   
   • Categories list in site's locale: expected in UI locale 🚫
   
   
   • Pattern content in site's locale: as expected 👍
   
   
   • Pattern names in UI locale: as expected 👍
   
   
   • Note how "contacto" is in lowercase, is that correct?
   
   

Account Spanish, site English

The same is visible if I set my account in Spanish, but site is in English:

Account Spanish, site Spanish

Furthermore, when I change both UI and site's locale to Spanish, I still see pattern names in English:

I couldn't find the pattern name from Translator.

Actually looks like some of them are translated, but I couldn't find those from translate tool either:

[ramonjd]

Categories list in site's locale: expected in UI locale

The category labels come from the patterns API. Just confirming that @lsl resent dotcompatterns.wordpress.com off for retranslation this week.

That might resolve many of the issues we're seeing here I hope!

[ianstewart]

@simison it took me a while here to realize the issue until I tried it out in French and the rest of the Editor UI. :)

Category Labels in select menu translated when they shouldn't be

Current Status: Translated when site language is non-EN but UI is EN.

Expected Status: Category labels should remain in English when only the site language settings have changed but not the UI language settings.

Meaning these labels here, because they're UI, should be in English.

To reproduce:

1. Visit settings and change your language to a non-EN language while keeping your /me UI settings in EN.
2. Compare the select menu for category labels with other parts of the Gutenberg UI.

@apeatling we'll need to either update the Patterns Toolkit API here or how it integrates with the Editor.

Pattern names never translated.

With both the site and UI language settings set to non_EN it looks like these are incompletely translated in multiple languages.

@ramonjd @lsl or @andrewserong these should be corrected over time as translations come in, correct?

[ramonjd]

@ramonjd @lsl or @andrewserong these should be corrected over time as translations come in, correct?

I'm _fairly_ confident this is correct. Just looking at strand 68958 (sv) as an example in Linguine, the Pattern title string Layered Images and Call to Action is being translated.

[ianstewart]

Great. I believe we're also tracking in another repo a task to send these out for translation automatically. That'll help prevent the mixed or late translations.

That leaves just the UI update to be taken care of by View Engineering.

[apeatling]

Grabbing this one 👍

[apeatling]

I've updated the patterns in editor code to always use the user language setting in https://github.com/Automattic/wp-calypso/pull/47297, although I'm not sure my conclusion was correct from the above. Does it make sense to use the user's language setting here?

[ianstewart]

Left a comment on the PR!

[andrewserong]

Just updating this issue: #47297 was closed with the conclusion that:

the UI elements should be in the user's language but any content that actually gets inserted into the site should be in the site's language.

I've added this issue to Ganon's patterns backlog, and that the goal would be for the API (or somehow the consumer) to support displaying pattern categories in the user's locale, but the pattern content in the _site's_ locale. I believe this would be non-trivial to implement in a single API call due to locale switching being an expensive operation. So, perhaps another way to do it would be:

• [ ] Add an additional endpoint that gets a list of _just_ the pattern categories in one locale, ensure the category _slugs_ are not translated
• [ ] In the existing API endpoint for getting patterns, ensure that the category slugs are not translated
• [ ] In the consuming code, get the list of pattern categories using the user's locale and store them in a variable
• [ ] In the consuming code, get the list of patterns in the site's locale, and look up each category based on its untranslated slug to get the translated category name, when registering the patterns

I _think_ something like that should work, and would result in the fewest locale switches.

I also assume that most of the time, for most of our users, the user's locale and the site's locale will be the same? So I'll add a low priority label to this one, but let us know if you think it's a higher priority to fix this @apeatling!