Hi!
I’m working on/trying out making a dual language site/menu using Custom Interactions.
So, making two div’s, one for NO the other for EN, and switching between them by adding and removing a hide class (as in display:none;) seems to work fine. But if I also add a rule to load the other language’s index page (or if I just click any entry in the menu), the page is loaded using the default (NO) menu.
The menu is located in the global top area, so the initial state shows the NO menu. I was thinking a way to solve it would be to load a custom interaction checking if path contains /en, but I don’t see how I can load a custom interaction upon page being loaded … Is it possible?
Or do you have a suggestion for a different logic that might work?
My 2 cents, you could just add a class to the body, one for each language, or just on one of the languages and use CSS to show or hide the language button.
Eg. If you had either .lang-en or .lang-no on the body and the language buttons were .btn-no and .btn-en
At first I tried adding an Interaction that used conditional checking to then change menu. Didn’t get that to work. But since I apply this to every page, I only need to apply the Custom Interaction that adds hide class to the NO menu and removed the hide class from the EN menu ID’s.
It works, but does flicker a bit upon each page load. (Like it loads fonts …)
Ah, interesting … Will give that a try …
So … Keep the number of pages down, even, just maintain both in the same page and hide blocs for the other language? Or did I misread that?
Yes you misread , you definitely do not want to manage both languages on the same page. That will have big SEO implications.
Maybe I misunderstood what you were doing, I assumed this was a language toggle you were making between the languages?
This would be a good case example, of why proper templating or global blocs would be great.
UPDATE: I just re read your OP and I think I mis understood. It’s such a shame that when the blocs community was crying out for page management, we got that custom url field instead, and not a proper page manager like every other app. (we did get a page rearrange option that had no impact on the actual site structure it makes no sense).
I got the button to work, and to switch the menus. And making the English pages load the interaction that sets hide class on NO menu and removes the same class for EN, it works. And it seems the flickering I mentioned is just an issue in Preview, not live. (But I’m not overly excited to have everything depend on JS, whatever can be fixed in CSS is preferred.)
The old/other way of making it in Blocs would be to move menus away from the global area and maintain copies for each page (as we’re still waiting for reusable global blocs or what it will be called) …
On a related note, but quite different question:
When viewing an English page, does it make most sense, in the menu, to:
Show the English flag to show the current language? Or
Show the Norwegian flag to indicate you should click that to switch to Norwegian?
(I’ve used the latter before, but have seen both, hard to decide. Maybe I should make both flags visible and some highlight or fade one of them … )
The flag is for switching isn’t it? So the EN doesn’t need to be visible on the English page.
But from a nice UX, and since it’s only 2 languages you could have both and the current language is disabled. Up to your design though and how much focus you want to give it
One question though, is even the link would need to reflect the page you’re on. So if it’s in the global area you will need to have some JavaScript update it.
This is due to the nature of the event that triggers the interaction. The onload event is fired once everything has loaded. So the page is loaded using the “old” language, and then the interaction is triggered; the change involves flicker from the old language to the new one.