Translate blocks

[olafgrabienski]

There are a few custom blocks with content on the Backdrop4Good site:

• Logo icons (no language specific content as the image has no alt attribute)
• Call to Action icons
• One liner CTAs
• Sponsors
• Footer

In contrast to nodes, blocks are not directly translatable by Backdrop at the moment. There is a workaround described in the core issue, UX: Layout UI: Collapsible block groups:

create multiple custom blocks (one for each language) [...] making sure that each custom block has a properly configured visibility (language)

Drawback, pointed out in the same issue description:

In websites with 2 or 3 languages this might not be a big deal, but when reaching close to a dozen languages, that makes the Layout UI really cluttered and just horrible to work with.

@klonos suggested to not wait on Backdrop 2 with extended language support but to improve the situation by adding "Collapsible block groups", i.e. the option "to group multiple blocks together and somehow collapse them so they don't get in the way all the time. That way one could create a [...] group of blocks that would include all the language-specific [...] blocks".

The "Collapsible block groups" suggestion got some positive feedback but there were also other suggestions based on different language related and block related core issues which made no more progress at a certain point. Subsequently, there were no more activities in the issue. In my opinion, the suggestion of @klonos remains an interesting approach to translate blocks.

So, to translate blocks on Backdrop4Good, there is one workaround which should work: create one block per language and set respective visibility conditions. In my opinion it's not ideal but manageable (Backdrop4Good is being translated to 4 languages at the moment).

There are however a couple of approaches to improve the situation. I'd like to discuss them first, as Backdrop4Good is a use case for general multilanguage improvements in Backdrop. Here are the approaches I'm aware of:

• [UX] Layout UI: Collapsible block groups (see above)
• [CMI] Add config translation (blocks are configuration)
• Use nodes for blocks (nodes are translatable). See for instance:
  • Add a system of page-less nodes (open)
  • Provide an Existing content block for layouts (fixed)
• Make blocks directly translatable. In Drupal 7, this functionality is provided by the i18n module.

My favorite is the last one: make blocks directly translateable. This feature was also requested several times in the central Backdrop contrib i18n issue but i18n is far from working in Backdrop. So let's have a look at i18n and see if it's possible to port the block translation option to Backdrop core.

[serundeputy]

@olafgrabienski I agree that the best option is the last one:

• Make blocks directly translatable. In Drupal 7, this functionality is provided by the i18n module.

I think we should work towards that.

Here is the config file block.custom.nav_call_to_action_icons.json:

{
    "_config_name": "block.custom.nav_call_to_action_icons",
    "delta": "nav_call_to_action_icons",
    "info": "Nav Call to Action Icons",
    "title": "",
    "body": {
        "value": "<div class=\"container\">\r\n  <div class=\"row\">\r\n    <div class=\"col nav-apply-for-assistance nav-cta\">\r\n<div class=\"pencil-icon nav-circle\">\r\n<a href=\"/webform/apply-assistance\">\r\n<webicon icon=\"simple-line:pencil\"/></a>\r\n</div>\r\n      <a href=\"webform/apply-assistance\">Apply<br />for<br />Assistance</a>\r\n    </div>\r\n    <div class=\"col nav-volunteer nav-cta\">\r\n<div class=\"puzzle-icon nav-circle\">\r\n<a href=\"/webform/volunteer\">\r\n     <webicon icon=\"simple-line:puzzle\" class=\"puzzle-piece\"/></a>\r\n</div>\r\n      <a href=\"/webform/volunteer\">Volunteer</a>\r\n    </div>\r\n    <div class=\"col nav-partners nav-cta\">\r\n<div class=\"badge-icon nav-circle\">\r\n<a href=\"/partners\">\r\n    <webicon icon=\"simple-line:badge\"/></a>\r\n</div>\r\n      <a href=\"/partners\">Our Projects<br />and<br />Nonprofit Partners</a>\r\n    </div>\r\n  </div>\r\n</div>",
        "format": "full_html"
    },
    "description": "A reusable custom block."
}

off the top of my head we could:

• give each block an id key either in config or DB
• give each block a _langcode key
• associate each block with the canonical block (in the case of backdrop4good the english block)
• give the block edit form an Add Translation tab similar to how node/edit forms have that

something like that; it will probably get a little hairy, but it will be worth the effort IMHO.

[olafgrabienski]

That sounds exciting! And I guess we could need more feedback, will ask for it in Gitter.

[herbdool]

If you don't mind having nodes directly accessible there's also the option of using a content type of "snippets" that's translatable. I've had to do that in D7.

How does i18n do it again?

[mazzech]

I am not a Backdrop user yet, but still doing a lot of D7, most of the projects multilingual in some way. I completely stopped using blocks "directly" for content, it's a pain whenever a customer wants something to be changed after some time. Here's what I use instead: having a content type called "Promotion Block", with all the necessary fields, some Display Suite sauce (i.e. to help link the entire block IF link field has been filled out). Then I use the D7 node block module to place the block in the layout. Since I started using this approach, I managed to handle also quite tricky i18n problems (well, all of them are complex in some way;-). I did not see any downside so far, it's compeletely fieldable, it's available in translation management, customers understand it and like it (which was never the case with having content in blocks... did you ever had to explain the difference to a customer....got you;-). It also allowed me to get rid of Panels.

[olafgrabienski]

@herbdool + @mazzech Thanks for your feedback! If I understand correctly, both your suggestions correspond to the "Use nodes for blocks" approach mentioned in the issue description. A nice concept in my opinion, especially as Backdrop allows to place existing content (nodes) as blocks in layouts out of the box.

@herbdool I think for Backdrop4Good it would be okay if 'block snippet' nodes were directly accessible. But there will be other use cases where it isn't desirable. As you know, there are some ideas to build a system of page-less nodes, the latest focus of the issue was however to rely on contrib modules, for instance on Rabbit Hole (which is not ready to use yet, afaik).

That said, the "use nodes for blocks" approach remains a workaround for experienced site builders. I'm sure that I'll use it as long there is no more direct solution, and we should consider it for Backdrop4Good as well. But I'd still be happy if Backdrop could also provide the option to make blocks directly translatable. That would be the most straightforward approach in my opinion. (Drupal 8 provides the direct option as well.) @herbdool Unfortunately I don't know how i18n is doing it technically. Have you seen serundeputy's implementation ideas above?

[mazzech]

Yes, and it's a fieldable solution (I do not know if BD blocks are either)

[olafgrabienski]

@mazzech Backdrop custom blocks are not fieldable so far. The feature is discussed in the mentioned System of page-less nodes issue but I don't think that it will be implemented soon.

I agree, fieldability is a point for the "Use nodes for blocks" approach. Another point is that nodes are content while blocks are configuration, which feels a bit strange if you're actually putting content in a block.

[mazzech]

@olafgrabienski It might be for more experienced site builders, but from my experience it's much more logical for content creators and has some great advantages architectual-wise. From my understanding it'a also in line with the pageless approach you mentioned. And IMHO it's a huge advantage when it comes to multilingual environment, and the translation proces itself, compared to blocks. It's also compatible with Display Suite (while D7 blocks are not), which I use a lot, sometimes 10+ different view modes per content type.

[jenlampton]

From a user experience pov, blocks are content. The fact that what we have in core now is configuration is only because that was much easier than turning blocks into content-entities, which is what happened in Drupal 8. For Backdrop, I prefer the pageless nodes solution, it's simpler in concept and people already know how to work with nodes.

For BackdropForGood we have two options:

1. switch to using nodes (and port rabbit hole)
2. sort out config translation

Option #1 might be a better short-term solution since we can implement it right away. But option #2 will need to happen anyway, as there are likely other non-block things that are stored in configuration that will also need to be translated eventually.

At this point, it's a matter of what needs to happen first. :)

@serundeputy I think adding a _langcode key to the config file is similar to the approach @quicksketch was working on for the 1.7 and 1.8 release. Were you able to find his issue about config translation, and was that documented in there?

[serundeputy]

For reference: looks like this is the main issue for translating config: backdrop/backdrop-issues#704 🍿

[olafgrabienski]

For BackdropForGood we have two options:

1. switch to using nodes (and port rabbit hole)
2. sort out config translation

Option #1 might be a better short-term solution since we can implement it right away. But option #2 will need to happen anyway, as there are likely other non-block things that are stored in configuration that will also need to be translated eventually.

At this point, it's a matter of what needs to happen first. :)

On Backdrop4Good, we're translating content at the moment (see section 5 in the issue description of [Meta] Make Backdrop4Good multilingual). Content translation doesn't need necessarily to happen first but it would be nice to continue with it, so I'm open to go for option 1 and to tackle configuration translation later. (Apart from that, I really like the node + rabbit hole approach.) What do you think, @serundeputy?