How to handle block pattern translations

A few months ago, in July 2021, a new Core-related translation project was added to translate.wordpress.org: Patterns. The new Pattern Directory was released along with WordPress 5.8, allowing site owners to choose from a selection of block patterns via a new directory.

The patterns currently included in the Pattern Directory were submitted and selected by WordPress community designers. Launching the Directory with these curated patterns was the first milestone. Next is working on allowing anyone to create and submit a new block pattern to include in the Directory.

Localizing block patterns

The current selection of block patterns has a fixed number of strings, all of which can be found in the Patterns project. Note: locales can also translate the Pattern Directory interface through the Meta > Pattern Directory project. As more patterns are added, two new challenges arise for localizing block patterns:

  • The ongoing and growing number of strings from user-submitted block patterns.
  • How to handle translating block patterns.

I’ve been thinking about both of these quite a bit and had a really helpful chat with @ryelle (thanks Kelly!) to better understand where development is going for the Directory.

Handling a growing number of strings

Strings for patterns added to the Directory are currently imported regularly into GlotPress using an API. As new, user-generated patterns are also regularly added, the Patterns project can, and likely will, grow exponentially.

Like other Meta projects, there isn’t a threshold for translating Patterns – once a string is translated, it will show in the Pattern Directory. At the same time, it’s also really satisfying to see that 100% next to a project you’re working on completing. I’m not sure if that will be realistic for future block pattern translations.

Translation methods

When thinking about how to translate all these new strings, one possible option is to skip GlotPress entirely and allow end-users to translate block patterns through the block editor. The result would look like a “forked” pattern, with an original version in English and a second, translated version. (For context, here’s a related Github conversation.)

I see a few benefits to this approach. First, it may be easier for anyone to translate block patterns since they’re basically recreating the pattern in their language. Second, it avoids a gigantic GlotPress project. Would we see more localized patterns this way? Maybe!

The downside: there is no review process. This would depend on users and/or Polyglots to catch any inconsistencies or mistakes by flagging them through the Pattern Directory. In other words, it’s totally separate from our usual translation process.

How to help?

Now is the perfect time for Polyglots to share feedback on the Pattern Directory’s future, especially on the best ways to localize the block pattern experience. 

What are your thoughts on:

  1. How important is it to your community that a translation project is 100% complete?
  2. If new strings are added every day, what would be helpful for communication and/or notifications? 
  3. How do you feel about a translation mechanism outside GlotPress? How can it help? How would it hurt your locale?
  4. What else might help support your community in localizing block patterns?

I would like to keep the discussion on this post open until Monday, October 11th, 2021. Then, figure out the best way to share a summarized version of this feedback with the development team working on user-generated patterns. Anyone is welcome to comment and share thoughts!

Update: I added a summary of this feedback to the related GitHub issue. Thank you @psmits1567, @felipeloureirosantos, and @vladytimy for commenting!

I originally suggested today, October 11th, as a day to “close” this post, but I think we should leave it open to continue the discussion. Feel free to keep adding more comments and thoughts!

Top comment
View in context

Hi here are my comments
1. Being 100% is nice, but not necessary, as long as there is a lower threshold then at GlotPress
2. For new strings use the same message as currently is used in polyglots
3. Translation outside GlotPress, will also take time and make it more complex
4. Using the current GlotPress mechanism is fine, combined with the current available tools for translations
5. Why not have a look at this proposal:http://wayback.fauppsala.se:80/wayback/20211027143807/https://make.wordpress.org/polyglots/2021/07/31/glotpress-translation-handling-improvement/
There are a lot of commonly used originals. So it would save time to translate them over and over for every pattern. It would also save database space
6. Not reviewing translations is a bad idea, as there will be added automated translations, which are sometimes very bad

Thank you for your feedback, Peter!

There are a lot of commonly used originals.

I know we don’t have support for this in GlotPress yet, but this is a really helpful proposal to keep in mind. Especially if we continue to use GlotPress for block patterns.

When thinking about how to translate all these new strings, one possible option is to skip GlotPress entirely and allow end-users to translate block patterns through the block editor. The result would look like a “forked” pattern, with an original version in English and a second, translated version. (For context, here’s a related Github conversation.)

If I understood correctly, it means that we would end up with multiple versions of the pattern, so new changes to the structure of the main pattern wouldn’t apply for “forked” versions, right?

I wouldn’t like to have the patterns with the same issues that we have on HelpHub where new changes wouldn’t apply for the localized versions (unless updating the changes manually).

Exactly, the translated patterns would exist separately from the original. I did not think about that in relation to HelpHub, but that is an awesome point!

Here’s my 2 cents on this. 🙂

1. Unreviewed translations on w.org would put WordPress in a bad light with bad translations or even translations containing spam.
2. A continously increasing amount of strings it’s not something we can handle. Sure, it looks amazing to have demo content localized, but it’s not critical, so our limited resources can’t handle an indefinite amount of strings. Plus the database overload.

Possible solution
What if in the process of submitting a pattern, there would be a strings pre-procesor thingy that would allow user to select strings from a predefined list of strings available in the translation project? I have not seen the submission process of patterns, but I’m pretty sure this can be done. Sure, other strings can be accepted, but within a limit. I don’t see why demo content text cannot be reused in various patterns.
I see several benefits to this approach:

  • limited strings = a chance for all of of them to be translated
  • reviewed strings = quality translations
  • limited DB space

Sure, this would need additional work from the awesome #meta team in the start to implement this thing, but in the long term this would save us all from a lot of trouble. 🙂

Thank you so much, Vlad 🎉 So far, it seems like everyone prefers keeping things in GlotPress, but I also really like your thoughts on trying to help leverage existing translations!

I’m wondering if @ryelle might have some initial thoughts on how something like that might work and if it’s feasible. I believe the workflow is largely still being decided, but there may be a way to encourage new patterns to use repeated text in some form – even if it’s just a strong recommendation to start.

+1, loved this idea. Seems like a great way to handle that.

Update: I added a summary of this feedback to the related GitHub issue. Thank you @psmits1567, @felipeloureirosantos, and @vladytimy for commenting!

I originally suggested today, October 11th, as a day to “close” this post, but I think we should leave it open to continue the discussion. Feel free to keep adding more comments and thoughts!