Breaks menus with Hueman theme

[keunes]

As the title says, activating the plugin breaks the menu's, at least in my case. I have the Hueman theme installed and when I activate the plugin my menu bar simply disappears. I tried creating a new menu, assigning it to all possible menu places, but nothing appears. Sth to look in to.

[dougwollison]

I'll look into it when I can but there might not be a way around it depending on how that theme's handling menus. My focus on this plugin is for it to be used in conjunction with custom themes anyway, not stock ones.

[keunes]

Thanks for getting back so quickly! Hope it'll come out to be an easy fix. (I don't really understand the reasoning on stock vs custom themes, btw. If sth's broken, it's broken, and I guess that by supporting stock themes you can even help more ppl than by focussing on custom themes. In any case, thanks in advance for looking into it :+1: )

[dougwollison]

Same thing appears to be happening on Twenty Fifteen; I guess there's something I missed in the menu hooks due to how I normally setup nav menu when I build themes for sites.

[dougwollison]

Found the issue, thought at the moment I have no idea how to solve it.

The plugin creates fake copies of the registered nav menu locations, one in each language registered. This allows you to create separate menus in each language for the same location (e.g. header). When wp_nav_menu() is called, a hook checks for the location being requested and replaces the requested location with the special version for the current OR default language.

For example, calling the header location while in english will instead request header--en.

The issue is that Hueman and Twenty Fifteen—along with I imagine numerous other themes that are designed to function without needing those menus to be populated—is that it calls has_nav_menu() to check if a menu is registered for that location. However, because you would've registered menus to the individual language versions of those locations (e.g. header--en), not the vanilla location (e.g. header), it's returning false.

Normally, this could be handled by a hook somewhere to change the outcome of the has_nav_menu() test, however none currently exists. I will put in a request for such a hook to be added, but so far I don't think there's any other solution; I'm digging through the core code now and see no sign of a way to work around this.

I think the only alternative is to add an option to not clone the nave menu's in the first place, and add filters to make sure the nav items are swapped out with their counterparts for the current language. However, this could make managing the menu options like a custom title a bit less user friendly. I can't guarantee a time I can get this built for a new release either.

I've never encountered this issue in my own development because I write themes custom-tailored for each site, and there's no point in using has_nav_menu() since all nave menus are mandatory for the theme.

The thing is, this plugin is still fairly experimental, and is more intended for use on custom one-off themes for custom sites (I should've noted that somewhere). Since I imagine this has put a roadblock in whatever you're doing, I suggest you look into another plugin to get the job done; I've had luck with qTranslate in the past, though it handles things in a completely different fashion.

[keunes]

Well, great that you found the issue! I see your point now about just working with custom themes, where this hook isn't an issue.

I think that the workaround you propose would work for me, even if that'd involve a bit more work in managing the menu's. That's something you'd normally not do too often.

For as my personal issue: I found other translation plugins too complicated for my use. I didn't intend to translate all of my blog posts, but wanted to enable visitors to make it easy to select if they wanted to view all blogs or just the blogs in English. I've now solved this with using tags, and in the rare case I will translate a blog, I'll have two of them appearing - not too big of a problem in my case.

In any case, I'll watch the project, and if any update enables me to try and use the plugin, I'll test it :)

Thanks!

[dougwollison]

Okay, sorry for the delay (been slammed with work and just got back from vacation, plus I was focusing on development of QuickStart), but I just finished some changes that should allow it to work better with your theme and hopefully all others with regard to the has_nav_menu() issue.

Basically, I have it re-add the entries on the front-end for the plain locations—"primary" instead of "primary--$language"—and point them to the current or at least default language's locations. This fix kinda teeters on being a straight up hack but it does the job. I tested it on twentyfifteen and it seems to work fine.

I'll be polishing it up along with the other yet to be released changes and be issuing version 1.2.4 soon.

[keunes]

Heya, Again: thanks for the work. Unfortunately, after installing the plugin from the wordpress repository, I get a 'fatal error' preventing its activation:

Warning: require() [function.require]: Unable to access /public/sites/www.example.com/wp-content/plugins/nlingual/php/global/quickstart.php in /public/sites/www.example.com/wp-content/plugins/nlingual/php/load.php on line 22

Warning: require(/public/sites/www.example.com/wp-content/plugins/nlingual/php/global/quickstart.php) [function.require]: failed to open stream: No such file or directory in /public/sites/www.example.com/wp-content/plugins/nlingual/php/load.php on line 22

Fatal error: require() [function.require]: Failed opening required '/public/sites/www.example.com/wp-content/plugins/nlingual/php/global/quickstart.php' (include_path='.:/usr/share/php:/usr/share/pear') in /public/sites/www.example.com/wp-content/plugins/nlingual/php/load.php on line 22

[dougwollison]

Okay, redownload the plugin and try it now; for some reason SVN didn't commit properly (this happens WAY too often for me) and some files didn't actually get transmitted.

[keunes]

Yeey. It almost works. By default, I want to show all posts (ie both languages, as I guess most of my visitors speak both languages and I want them to be able to read everything - moreover, I have few posts so if I kick out half of them based on language, it looks a bit pathetic ^^). Thus, I don't set a default language in the nLingual settings. However, there's no option when I edit my main menu to enable its appearance if there's no language set.

--EDIT-- Under the nLingual settings, I've added a custom language without filling in any data. I selected that and then was able to enable the menu for 'no language'. If you go to my homepage it shows all blogposts (of the two languages), just as I like it. As soon as you view an article or category, however, you 'get assigned' a language, hiding articles in the other language.

It would be great if the Language redirection method would not be applied (to menu items and post URLS) if there was no language selected (e.g. when you come fresh to the site), or if some kind of 'combined languages' option would be offered. But I can totally see if that goes beyond the scope of the plugin :)

Of course I could make multiple copies per post (one with the 'no language' label, and one with the actual language label), but that would lead to a large amount of exact duplicates (which may be annoying in future if I need to import the articles into a new site).

So again I'll stick to my system with tags, but with the change you made the plugin will be way easier to use/more useful for many Wordpressers! :+1:

[dougwollison]

I'm sorry, but as you suspected that kind of functionality is out of scope; the plugin is intended to allow a site to be viewed in each language separately, content and all. In fact, my main hurdle building this plugin is making sure what you're describing can't happen. I'd personally consider your use case of offering content in all languages at once to be, well, incredibly niche. I think you may have to resort to your previous solution of tagging the content rather than using an actual multilingual system.

It's entirely possible I'll end up needing to add this functionality should a future project actually require this feature (hell, I built this for a site that used Simplified and Traditional Chinese, which most systems wouldn't do and most people would never consider), but I don't think it's worthwhile to do so at this time.

[dougwollison]

Since the original issue has been resolved—at least in the use cases described—I'll be closing this issue now.