My Troubles with the Bogo Multilingual Plugin for WordPress

Symptoms of the problem

This article is being written during the New Year of 2026. On this WordPress site, the bilingual site functionality using the Bogo plugin, which had been operating without issues until the end of the year, suddenly began malfunctioning. The symptoms are as follows:

• The English front page set on the static page does not display; the Japanese version always appears instead. “/en/” redirects to “/”.
• Depending on the article, either the English version is displayed or it redirects to the Japanese homepage.
• The environment is Sakura Internet’s Standard Plan rental server.

I tried various solutions, but nothing worked. Restoring from a backup taken when it was functioning normally didn’t help either. Finally, I tried installing WordPress fresh and rebuilding everything from scratch, but the issue persisted.

I was at my wits’ end.

Since I had already published numerous articles using Bogo in a cross-referenced format, introducing a different system that would change the URL structure at this late stage was unthinkable.

What follows is the story of how I spent an entire day, using brute force, to somehow wrestle it into a state that functioned close to how it did before the trouble started.

By the time you see this, the issue may already be resolved, but just in case… someone else might be facing the same problem, so I’m leaving this here for the record.

First, the conclusion

I imagine you’d like to skip the tedious preamble and get straight to the conclusion, so I’ll summarize the measures I took below.

Articles with slugs containing “-” will be redirected.

While investigating the unstable behavior, I discovered that articles other than the front page being redirected to the root directory is limited to articles using a “-” (hyphen) in their slug. For example, “itc-curriculum”.

Therefore, the solution is simple: just modify the slugs containing a hyphen. (That said, considering the need to fix all the linked content, it’s not exactly simple…)

For the earlier example “itc-curriculum”, changing it to “itccurriculum” or ‘itc_curriculum’ will display correctly. The underscore (_) does not seem to cause issues.

Note that custom URLs for categories or other elements containing “-” do not affect functionality.

The front page issue was addressed using a query

I managed to fix the article issue, but the front page remains unsolved.

Desperate to try anything, I suddenly thought of adding the language attribute “?lang=en” to the URL.

This was a huge success! While “/en/” redirected to “/”, “/en/?lang=en” perfectly displayed the English front page.

Having found a starting point for the fix, I’ll now consider how to force the addition of “?lang=en” to URLs ending in “/en/” or “/en”.

For menu items, it would suffice to assign a custom link like “/en/?lang=en” to a menu labeled “ENGLISH”. However, this method cannot be used for links like the site logo or breadcrumb list.

The simplest approach is likely to handle it on the client side.

We’ll use jQuery and JavaScript.

//
// Workaround for Bogo Issues
// 2025/01/05 msat
//
$(document).ready(function() {
	//
	// Scan the a tags and append ?lang=en to URLs ending with /en/
	//
	$("a").each(function() {
		var href_prop = this.href;
		if ( href_prop.substr( -3 ) == '/en' ) {
			$(this).attr( 'href', href_prop + '/?lang=en' );
		} else
		if ( href_prop.substr( -4 ) == '/en/' ) {
			$(this).attr( 'href', href_prop + '?lang=en' );
		}
	});
});

Depending on your theme, adding the above code to your child theme’s javascript.jp file should achieve the desired result immediately. (If it doesn’t work properly, first suspect the cache.)

The cause is unknown: However, it has been restored

As of the end of January 2026, the issue persisted with the cause remaining unknown.

When tested at the end of February 2026, it had been restored.

Ultimately, both the cause and the reason for the restoration remain unknown. Since this symptom did not reproduce on WordPress sites launched on other domains, I believe it was an environment-dependent issue.

If anyone has any idea what might have caused this, please let me know.

Note 2: Converting the Menu to a Bogo Switcher

During the process, I realized I could create a script to apply the Bogo switcher to the header menu using the same mechanism, so I made one. For sites where Bogo is functioning normally, please remove the code that appends “?lang=en” before using it.

It simply retrieves the content from the Bogo switcher placed via widgets or similar, then replaces the menu links with JavaScript. (If the original Bogo switcher is a nuisance, you can hide it with `display:none;`.)

Some users place the Bogo switcher in the menu using shortcodes and CSS, but I find this method much less troublesome.

This is purely for reference, but I’ll share it below.

//
// Bogo Workaround & Menu Support
// 2025/01/05 msat
//
$(document).ready(function() {
	//
	// Scan the a tags and append ?lang=en to URLs ending with /en/
	//
	$("a").each(function() {
		var href_prop = this.href;
		if ( href_prop.substr( -3 ) == '/en' ) {
			$(this).attr( 'href', href_prop + '/?lang=en' );
		} else
		if ( href_prop.substr( -4 ) == '/en/' ) {
			$(this).attr( 'href', href_prop + '?lang=en' );
		}
	});
	//
	// Reflect the BOGO switcher widget URL in the menu
	//
	$("ul.menu-header>li div.item-label").each( function() {
		const label_jp = 'JAPANESE';
		const label_en = 'ENGLISH';
		const bogo_jp = 'Japanese';
		const bogo_en = '英語';
		const bogo_id = 'div#bogo_language_switcher-7';
		var targetObj;
		var replaceUrl;
		if ( $(this).text() == label_jp ) {
			targetObj = $(this).parent().parent();
			$("div#bogo_language_switcher-7 span.bogo-language-name a").each( function() {
				if ( $(this).attr( 'title' ) == bogo_jp ) {
					replaceUrl = this.href;
					if ( location.hash != "" ) replaceUrl += location.hash;
					$( targetObj ).attr( 'href', replaceUrl );
					return false;
				}
			});
			return false;
		} else
		if ( $(this).text() == label_en ) {
			targetObj = $(this).parent().parent();
			$( bogo_id + " span.bogo-language-name a" ).each( function() {
				if ( $(this).attr( 'title' ) == bogo_en ) {
					replaceUrl = this.href;
					if ( location.hash != "" ) replaceUrl += location.hash;
					$( targetObj ).attr( 'href', replaceUrl );
					return false;
				}
			});
			return false;
		}
	});
});

This code depends on your WordPress configuration environment, so you will need to customize it yourself before use.

The key point is to modify the constants defined with `const` to match your own environment.

This mechanism works exceptionally well. It may have provided us with a valuable byproduct that made the effort worthwhile—the effort that originally took a full day of troubleshooting.

If you like it, feel free to use it.

Note 3: Language Control for Widget Category Items

When Japanese and English articles are categorized into separate groups, you’ll want to control which category items appear on the Japanese and English pages. However, Bogo lacks a mechanism to manage category language attributes, so you’ll need to implement your own solution.

For the main menu, it’s sufficient to prepare two sets of categories—one for Japanese and one for English—and control their display using the language checkmark.

However, widget categories cannot be individually shown or hidden, so another solution is needed.

The most reliable approach would be to query whether any English articles are linked to that category and control its visibility based on that result. But here, I’ll introduce a simpler method: implementing a client-side solution.

We determine visibility based on whether the category name contains any characters other than half-width alphanumeric symbols.

For example, “ict-curriculum” would be hidden on the Japanese site, while “ICTカリキュラム” would be hidden on the English site.

This is a simple management method, but depending on your site’s category naming rules, it might not be usable. In that case, please understand. The script is as follows:

//
// Widget Category Display Control 
// (Determined by whether all characters are half-width alphanumeric symbols)
//
$(document).ready(function() {
	var lang = $( 'html' ).attr( 'lang' );
	$( 'li.cat-item' ).each( function() {
		if( $( this ).text().match(/^[ -~]+$/) ) {
			if ( lang == 'ja' ) $( this ).css( 'display', 'none' );
		} else {
			if ( lang != 'ja' ) $( this ).css( 'display', 'none' );
		}
	});
});

I think it’s fine to integrate and use it with the above Bogo malfunction avoidance/menu response script.