Global Content Area, Selective Exclude for Language Switching

I have no idea how this would be implemented in light of how Blocs 3.x works now, but it would be great if I could selectively exclude language switching content from the Global area at the top and bottom of the page.

More specifically, I have an ENGLISH text link in the navigation area of my Japanese language sites and a 日本語 text link on my English language sites. All my web pages built in Blocs force me to make that language-switcher link the same URL on every page, which means I am forced to take people to the TOP page of the alternate language site. But it’s easy for people to get lost that way.

On my older web pages built in SoftPress Freeway, I would have that navigation switcher link automatically placed on every page using its Master Page area, but I could also selectively remove Global control over objects on an object by object basis. That feature in Freeway allows me to have the ENGLISH or 日本語 text links auto-placed in their proper positions in the header and footer, but with the click of one checkbox setting, I could disconnect them from Master Page control, thereby allowing me to link pages individually. But even after they were partially disconnected from the Master, they would remain in the same location where the Master (Global) content page originally placed them.

Why does this even matter? Imagine a huge website with dozens upon dozens of web pages. You find a particular web page via Google, or perhaps you simply dug down deep into a site but then you see a language switcher link at the top of the page you want to click. You click that in hopes of seeing the language of the page you are currently on be switched. You don’t want to click that link and be taken to the top page of the alternate language site because then you would need to figure out how to get back to the page you were on!

All said, my feature request is about making language switching easier and more intuitive, for links that really do need to be inside the top and bottom of every page in a website (within the navigation bar itself).

Here’s an example page from my site, where you can see the language switcher link in the top right corner, just to the left of the search icon. Click 日本語 and you’ll be taken to the top page of the Japanese version of that same website, which is not helpful. Here is an older page that was built in Freeway. Note how intelligent you can switch from one language to another! I want to achieve that in Blocs.


1 Like

I’m not sure I understand the issue. Blocs can already allow you to create multi-lingual sites with a language switcher. I think. I’m missing something! Your language switcher appears to be displaying the same page without an option to switch back to English. Your older site is working correctly, as you pointed out, but blocs can do exactly the same. Maybe you can clarify what it is that blocs isn’t doing that you would like it to do.

I’m afraid I don’t know what “language switcher“ you’re talking about, but I doubt that it is a human translation, and I doubt that it also translates text embedded in graphics too, like I can.

Like I said, I’m probably missing something!!! The language switcher is the link on your old website that takes you to the alternative language page. You’re right about translations. There isn’t currently a way to automatically have browsers translate text in a graphic (I wish there was). I assume that your pages are translated by yourself and uploaded as alternate language pages. If this is the case, then placing the menu in the top global area will give you problems. You will have to drop your navigation block into the main body of each page so you can set up individual links on each page. This way you can direct the language link to the corresponding page in the opposite language.

Hope I’ve got it right!!!

I believe JDW wants to have the user stay on the page they currently are, when hitting the other language button. But using the global area, which is the same on all pages, it’ll take the user to the main page, wich indeed is not helpful on larger sites. He wants a solution to have the user hit the other language button and find himself on the exact same page he was before, just in that other language.

I can’t think of a solution right now, as this it not how the global area works. The only idea that springs to mind is to not use the global area and put the header in the normal content area instead. That way you can have different links in each header, but you’d have to change every site’s header when you change the header, which is … quite cumbersome even on smaller sites, so probably not an option.

Maybe @Norm has the ability to change that? :wink:

The solution is in my response above. Move the navigation bric to the main dynamic page area - not the global area. This way, the link can be set to go to the correct page on EVERY page. The navigation can remain in the global area until it hs been transferred to the dynamic area of each page. Simply duplicate the navigation bloc and move the copy to the dynamic area. When this has been done on all pages, simply remove the original navigation bloc from the global area. Then the work can begin on changing the language link on each individual page.

Yes, but still a very annoying way if you have like … 100 pages and need to change something in the header or navigation, which is simple when you have it where it belongs. I can understand JDWs needs.

There lies one of the disadvantage of putting stuff in the global area of any website - it gets transferred to every page - including the links it contains. By definition, the dynamic area is used for content that is exclusive to that particular page. I think the duplication and move option is simple enough - even if it’s several pages that have to be handled. The alternative would be to add a language switching link into the first dynamic bloc on every page - just as much work and won’t look so good. It’s really a design consideration when starting a new site. If there is any content that is likely to be different on any page, then it doesn’t belong in a global area. That said, the global area is a good place to put something that you want to copy and duplicate on other pages and then move it into the dynamic area. It saves you having to recreate the whole thing on every page.

I think its more a work-around. That’s my beginners opinion.
I searched for all the solutions, yours seemed what @eldar suggested in this video.
And its a lot of pain, if you have a lot of pages.
I think, blocs should have an built-in solution to generate multi-language websites, easily(yes, I know this is a lot of work to do for @Norm) .
Every page has a language, you could choose. And you can build a specific menu for each language. And you can choose a different folder for each language(in output and in Blocs sidebar). And you have this special language-switcher, which automatically does the job.

I don’t think it would be a problem to create a multi-lingual option as a Blocs feature (assuming enough users needed this option). I don’t know of any web development tool that has a multi-lingual option - it’s something that has to be created by the website developer. However, it doesn’t solve the issue of creating a navigation in a global area. The global area is going to implant the SAME content on EVERY page of the website. If the content has to be different (links) on every webpage it cannot be a global option - it must be page specific.

I think if you have so many pages that managing multi languages is difficult and time consuming, it time to seriously consider a CMS. Design in Blocs but deploy in a content manager. Most of which have multi language systems built into them.

Friends, thank you for commenting. I read all your comments but I think many of you are missing the point of my Wish List. Some folks hate my “essays” but that’s just my way. So here’s the whole story…

For decades (yes, “decades”) I have built, translated and managed dual websites for my employer. I am not exclusively a web designer, actually. I am really an electrical engineer who just happens to be somewhat of a jack-of-all-trades and tries to save the company money where possible. So I was the self-appointed web designer of both my current employer and prior employer here in Japan all the way back into the 1990’s. I found SoftPress Freeway in 1999 and was dumbstruck with how great the app was back then. I was able to get many changes made to the app, and even brought it to Japan and did translation work on the printed documentation and the UI. I was also on their beta list for decades. Then the company went under and I eventually made my way to Blocs. I am a 100% Blocs user now. (No need to question my loyalty to Blocs – I really love Blocs now. I do!)

Through those years, I maintained dual language websites. Currently, my employer has two domains, so I build and maintain a total of 4 websites. Two are Japanese and two are English. We are based in Japan, so naturally I spend the most time on the Japanese sites. I write all the English content myself, in addition to shooting all the photos and videos, and even designing the vector art too. In fact, I even created all of the English product documentation and made the template design for our Japanese documentation. Pretty much all the website work is my doing. I have complete control.

Much of that work is still in Freeway format. I am slowly rebuilding the sites, page by page, in Blocs, to make everything modern and responsive. But there are things I can do very easy in Freeway that I cannot do AT ALL in Blocs, and that it really frustrates me. (And no, I am not going to consider RapidWeaver or another web design app. I am a Blocs-only guy now. I’m sticking with Blocs.) Please also know that my words are in no way, shape or form some kind of knock against Blocs. I am basically sharing my own internal feelings with you folks so we can work together and figure out some solution that perhaps will not only benefit me, but for everyone else who uses Blocs and reads this public forum. Sometimes I can post in this forum and find a way to rethink the problem to build a workaround. And if I can find that with regard to my language switching text link, that would be great.

So just to clarify…

  • I don’t want machine translation. Nothing beats a human.

  • I don’t want anything automated because nothing automated can translate text inside graphics and made it look lovely to behold.

  • I don’t want machine translation because our Japanese web pages target Japanese speakers in Japan whereas our English pages target folks outside Japan. So because the content differs a bit, machine translation is impossible.

All said, my Wish List request has NOTHING to do with automated translation whatsoever.

My Wish is a lot more simple than many of you seem to be thinking. All I want is what I wrote in my opening post. My navigation bar atop my pages and the navi bar in the foot is complex. It really needs to be placed on every page automatically by the Global Content Area. I am not about to manually put that on every single page in my site and then change every single page in my site when I need to alter the navigation menus. No way! I want it to be Globally applied. But as you can see from my Blocs-made sites, I have that text link in the navi header and navi footer that takes people to the alternate language site. That text link works, but it’s the same old URL on every page, so if you spent 10 minutes digging down in my site and then decide to language switch, you’ll be taken to the top page of the alternate language site, which is, quite frankly, really troublesome for the user to have to deal with.

On my Freeway sites, the Global Content Area is called Master Pages, and it works somewhat similar to Blocs. The fundamental difference is that I can selectively delink content from the Master. Hence, I am able to get the Master to automatically place the English or Japanese clickable button in the header, but then I can customize the URL on that button individually for every page, and that change will stick, yet all other globally applied content remains unchanged and fully linked to the global area. The beauty of that approach is that no matter where you are in the website, all you need to do is just click the language button to immediately get my custom-made alternate language page for the page you are on.

Again, this is not a knock against Blocs or complaining. This is open analysis for consideration, that is all. I want to figure out an easy way to accomplish in Blocs what I am able to do in Freeway with regard to global contact and selective delinking from that Global Content so I can get a more intuitive clickable language switching text link in my globally applied Header and Footers. For now, I cannot see a good workaround, hence my Wish List post. If you have additional ideas in light of what I have written, I’d love to hear them!


@JDW I remember the concept of master pages very well - many web design apps used master pages for creating content that would appear on every page of a website. However, there is a fundamental difference between master pages and the Blocs global areas.

Master pages were never published as part of a website. They were, in fact, a sort of template that could be applied to every page of a website (or at least some of them if you had multiple master pages). As such, the pages created that used the master page template would effectively be self-contained DYNAMIC pages with no global areas at all, so you could make changes to any element on the page without it affecting other pages using the same master. In Blocs, things are simply different. The global area is a sort of page add-on that appears at the top or bottom of every page you create. Therefore, any change you make to a global page element will reflect across all of your pages that have a top or bottom global area. This is just the way Blocs works.

If you want to revert back to a master page concept you have to forget about global areas. Instead, you can create a template page that contains your navigation or footer elements as part of the DYNAMIC area of the page. When you then create a new page for your website, you will simply base it on your template - in the same way as a master page in other applications. You are then free to edit the content, including its links on a page by page basis.

Using this method you have to understand that your navigation source should be set as NONE - not Primary menu. This enables you assign pages to your links as you create each new page. This can clearly become a little tedious on a multipage site as you will have to assign the links on every page. Therefore, to simplify matters. You should do what I suggested in a previous post. Add your navigation to the global area while you develop your site, and when its all done simply duplicate your navigation bloc and move the copy to your DYNAMIC area. You can then delete the original navigation from the global area. All your links will be the same on every page, but you will have the option of designating a specific page to your language switching link.

When I make multi-lingual sites, I actually make two sites (duplicating the english language version by saving as a different file name). I then translate the duplicate site and upload it to a separate sub folder of the main site using the ISO country code as the folder name for the foreign language version. I can then go back to each site in Blocs and set the language switch link to point to the relevant language version of the page using the URL link option. For example, on the about page of the English version of the site, The language switch link would be something like /jpn/about.html. this will take visitors to the Japanese version of the same page. You would then do the reverse on the Japanese version of the page. When all the changes have been made, upload the two sites again and check that all works well.

Of course, if you know in advance the page names you intend using, you can create these links as you work in the original project files so you don’t have to keep editing and uploading the sites.

The advantage of using two separate sites in language specific subfolders is that each site can have its own language tag set for search engine use. This can often be better than setting language tags on a page by page basis - just set the primary language in the project settings of each site variant. Search engines also recognise ISO folder names as being language-specific variants of the site. You also have the advantage of a smaller Blocs project file and the ability to make changes to each language version of the site independently. The ISO folder option also gives you TWO index.html files - the launchpad for most search engines when they crawl a site.

Thank you for your detailed reply.

My navigation right now is all hand-built because Blocs’ built-in navigation tool do not offer the flexibility I need for large and complex navigation. I am not using Blocs built-in navigation tools at all.

But the issue with that is what I was describing in my previous post; namely, that I will indeed make changes to the navigation over time. And if I move that out of the Global Area into the dynamic space and delete it from the Global Area, then any future changes would be a huge burden on me because I have in each site (in each Blocs document).

I actually do something similar, putting all my English pages in a “/en” directory. But it seems you are able to create unique URLs for your language switcher only because you have your navigation in the dynamic space, right? If so, that again brings me back to the point that my navigation is complex and so leaving it in the Global Area is a huge advantage for me.

This is why I have not used the dynamic space for my navigation. I do make changes to my navigation over time, and sometimes a lot of changes. And that is why I have turned a bind eye to our web visitors until now, simply ignoring the inconvenience of the language switcher URL being the same on every page in Blocs. While giving those web visitors a unique URL would be in their bests interest, making changes to dynamic content (individually changing multiple navigation links on every single page in a huge Blocs document), would not be in my best interest. So it would seem I need to just drop the idea for now.

I appreciate all the input!


The only thing I can suggest is that you include your language switching facility in it’s own dynamic bloc on every page of your site. This way you can keep your global navigation and have the variable language links page-specific, as in the example below.

Just create the bloc on one page and then copy it to all the other pages of your site. You will still have to set your language links on a page by page basis (as you would in any development application), but at least you will be able to change your main navigation globally. At the end of the day, it’s a solution to something that is proving to be a herculean task for you.


That’s probably the best solution for now.

I’m not going to do that because it will require me to change my menus in the header and my footer too. The easiest thing for me to do is NOTHING. So I am going to do that. It’s trouble for the web visitors, but oh well! :slight_smile: I need to focus my time and energy elsewhere. Should Blocs remedy this in the future though, I will of course take advantage of that new functionality. But for now, I will continue on as I have been.

I don’t think there will ever be a remedy for this - Global is global - the same on every page and dynamic is dynamic - differences on each page. But, as you currently have your menu in the global area of your pages, all you have to do is remove the language link on one of the pages and it will be removed from all of the pages - fairly quick and simple. You would then just have a custom block for your language switching option and insert that as the first block in the dynamic area of every page. Apart from the creation of the block itself, it would involve no more work than changing the language links on every page, something you would have to do if that option was available in the global menu. Here is an example of what a two tier menu would look like (sorry it’s not as slick looking as your one - it’s only an example based on your design)

As you can see from the screenshot below, its made of two blocs - one in the global area and one in the dynamic area. All the links in the main nav can be changed site-wide, whilst the language link can be set for each page separately.

Anyway, I hope you get it sorted - its a nice comprehensive site and a language switch would be a great added feature.

My dear friends, I found the solution! It is the perfect solution I was looking for because it doesn’t force me to move my language link outside my globally placed header and footer! Ha ha! Here it is…

Step-1: I changed my language link URL in the global Header and global Footer to be this:

Here’s why…

I deliberately put http & www in that URL (the URL of my language switcher text links in my page Header & Footer, both globally applied) because: (1) I don’t use www or http in any of my other URLs, and (2) that URL will still lead to the top page of my website despite using http & www. You see, I use .htaccess to change all http links to https, and my htaccess code also removes the www too (when you load my site in a browser). So by adding http & www to the URL, I then have a unique URL for my jQuery code to search for on my page, AND that http URL still works fine too, should I not use jQuery to swap it out on a given page.

Step-2: I added the following code to the Footer of every page, changing the URL inside “attr()” to be the correct alternate language page URL (this must be changed on every page in the site):

<script>$("a[href='']").attr('href', '')</script>

It works great. And the best part is, the jQuery changes both the language switcher link in my Header and my Footer too! All I need to do is edit the swap-out link in my jQuery code for every page, and boom! Done!

So there’s no need to clutter up your body with language links, folks. You can do it in your globally applied navigation links! You just need a line of jQuery to swap out the links and of course change that swap-out link on every page. That’s it!

1 Like

Thank you for this information. I have my language switching setup for me and it works well. But I sure can see the benefits of your method. Shall bear in mind for future use. Many thanks again. Much appreciated.


1 Like