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?

[serundeputy]

I'm fine with that approach @olafgrabienski if it unblocks you.

Just for reference I put in a PR to get a start on config translation against backdrop/backdrop: backdrop/backdrop#2044

[olafgrabienski]

Good to know, @serundeputy! Testing Rabbit Hole which looks already good I became aware that we have to fix a core issue before we can use the nodes for blocks approach on Backdrop4Good: "Add Existing Content" block doesn't respect the "Show author and date information" checkbox

[serundeputy]

@olafgrabienski I've added a PR against the core issue: backdrop/backdrop-issues#2536

[olafgrabienski]

@serundeputy That's great! I saw that the PR is already reviewed and the issue has status RTBC. Tested the sandbox as well, works as expected, nice!

[olafgrabienski]

@serundeputy IIRC, to replace the custom blocks in Backdrop4Good by translatable 'node blocks' we have to wait on a new Backdrop version which will probably include the fix for "Existing content" blocks.

The same applies to #31 for translating 'normal' nodes. So it might be a good idea when I continue with other tasks in the meantime.

[bjoern-st]

Hey @olafgrabienski
Config translation is of course a really good thing .. but for custom blocks it might not be a good idea. A custom block can have a lot of HTML code .. and content translation - as far as I know - is text based - and I think it should be.
So it might be annoying to filter out the text from within the HTML tags and translate that ..

So I've started rewriting the block module for translatable blocks and I've developed some kind of prototype .. please see https://github.com/bjoern-st/block

It is working, but for now I'm totally unhappy with the backwards-compatibility section .. So feedback and issues are very welcome

Cheers Bjoern

[olafgrabienski]

@bjoern-st Thanks for your feedback! I'm also skeptical about config translation for custom blocks: holding primarily content, custom blocks don't seem to fit very well in the configuration paradigm. That said, I'm not sure about the technical background and if it however would make sense to build a translation interface around configuration, or if it's better to choose an alternative.

Speaking of which, I'm looking forward to test your rewrite in the next days, even if I won't be able to give feedback on backwards-compability, but I will install it and try it out. To do so, I just replace core/modules/block of a vanilla Backdrop installation with https://github.com/bjoern-st/block, correct?

[bjoern-st]

@olafgrabienski Yes, that is correct.
The translation ability is triggered by enabling the "Content Translation" Module.
After that you'll find a new operation "translate" on the overview page for Custom blocks.

[olafgrabienski]

@bjoern-st I've tested the rewritten rewritten block module. Translation of custom blocks is working in the backend: On a German / English site I was able to add a translation of a custom block and to edit both of the variations separately afterwards. (I was a bit puzzled that the English and the German variation were both called translations.)

What are you thoughts about the frontend integration? When I place a translated block in a Layout, I only see the English variation on the respective page, even if I'm on a German page.

[olafgrabienski]

When I place a translated block in a Layout, I only see the English variation on the respective page, even if I'm on a German page.

Sorry, that was not correct. Using the Default Layout, I see the German block variation on a German page. (It didn't work on the Home page layout.)

[olafgrabienski]

@bjoern-st Are you up to make an issue and provide a PR in the core issue with your rewrite of the Block module to get more feedback and to discuss the approach more detailed? AFAIK, there is no issue yet in the core queue to make blocks directly translatable.

I guess we have to discuss the different approaches for block translation then in the core queue and while dev meetings. To make the start easier, I'll try to summarize the discussion of this issue in the next comment.

[olafgrabienski]

Thanks again for all your feedback on Block translation! There has been made some progress on different approaches in the meantime, let me shortly summarize:

(1) Collapsible block groups

• [UX] Layout UI: Collapsible block groups
• no progress so far, didn't find favor here

(2) [CMI] Add config translation

• has a PR by @serundeputy now
• promising for configuration translation in general
• there are doubts if it's the right thing for Custom blocks (technically config, but ...)

(3) Use nodes for blocks

• Recommended by many participants, also because it has other benefits like fieldability.
• Rabbit Hole is ported, but there is one important issue to fix
• Add a system of page-less nodes has a PR now to integrate Rabbit Hole like features for nodes in core
• To use Rabbit Hole or the core approach we need also to fix "Add Existing Content" block doesn't respect the "Show author and date information" checkbox. backdrop/backdrop-issues#2536.

(4) Make blocks directly translatable

• From user perspective probably the most straightforward approach.
• In D7 by the i18n module. For Backdrop there is a rewrite of the Block module by @bjoern-st , see Translate blocks #39 (comment).

[bjoern-st]

Hey @olafgrabienski,

Sorry for the delayed answers.

At first: thank you for your work here and thank you for your feedback!!

Perhaps my thoughts for the different approaches:
1.) Really not my favorite. It would make the backend more clear, but depending of the number of languages and blocks it might make the site really slow!

2:) There is not even an UI to edit a config file ..

3:) Great thing! If it is going to work, the block module might be unnecessary .. but I like it :-)

So, if this might be a alternative I'll of course like to make a PR against the core. But this is only - as mentioned, some kind of prototype. I had some time left and I tried to solve this, so it needs revisions, discussion and feedback!
Unfortunately I don't have the time to work on this continuous and follow all discussions, but if this is an interesting approach I would try to finish that.

Cheers Bjoern

[mikemccaffrey]

I think that rabbit hole is a good solution for the immediate future, since we should be able to release it soon and let people proceed with their projects while we find a more long-term solution.

As I mentioned in our call, I think that any config translation system that we put in place should allow the translations to be stored in the same configuration file as the original text. That way any translations can be deployed along with related changes to the original text, and also be more performant since queries wouldn't need to be made to the database.

Nate seemed to think that we shouldn't go that route in general, and instead stick to the existing translation system which uses the t() function and stores the translations in the database. However, the config blocks are a special case where we might be able to try storing translations in the config files and see how that works in terms of usability.

[olafgrabienski]

I've an unpleasant update: over in the core issue about pageless nodes it turned out that the promising "nodes for blocks" approach doesn't help with block translation.

backdrop/backdrop-issues#100 (comment):

I was curious to test how people were thinking of using it for translated blocks. When I enable a second language and then translate a node and then insert the node into a layout directly, it doesn't show the translated node when switching languages.

I've used views myself to accomplish this but can't see how to do it with a single piece of content inserted into a layout.

backdrop/backdrop-issues#100 (comment):

Oh my, you're absolutely right! When I insert a node in a layout, I have to pick content of a certain node ID. As a translated node has a different ID than the 'original' one, I have to decide which one to include: the original or the translation.

Thanks a lot for testing this, I should have done it long ago! (In a way it's funny, that we didn't noticed this in the whole discussion about Translating blocks over in the Backdrop4Good issue. (Will report the problem also there.)

At the moment, I'm not sure what to do regarding the not working translation approach. On first sight, it doesn't seem to be crucial for this issue which actually isn't about translation but about pageless nodes. On the other hand it feels strange to introduce the pageless option knowing that one of its main use cases (Fieldable and typable block content) ends up with not translatable content. Opinions?

:-/

[mazzech]

Just a brief detail, not sure if this helps... I also recommended the node approach, which I am using in current D7 projects (after fiddling around with Panels, Panelizer, Paragraphs and every possible combination of them;-)

But the D7 Node Block approach has a small difference: it places a checkbox on every node "to be rendered also as block" or similar. After saving the node, the block is there. I am not sure if this changes anything for this issue here, compared to the "make block, search for content" approach.

[olafgrabienski]

I've finally filed two core issues regarding block translation:

• nodes as blocks: Blocks of existing content should follow the translation system
• direct approach: Translate custom blocks