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.

I'm seeing undefined function fatal errors in my logs for the above line.

I believe that should be get_the_author_posts_link, with the the. I'd make a PR but it's so small a change that any workflow disruption (for you) of the PR flow seems not worth the hassle. If you'd prefer a PR, I can do that, no problem.

Original proposal for the relevant function in WP, named as in line 452 but, apparently, modified after some comments

Function docs

Hi
I try to use Persian and English language for my WordPress. I want to set Persian as default and English as a second language.
So I added two languages and activated Skip Localization for Default Language option in the admin panel. Then I changed Permalink to Plain and seated it back to Post name.
Now, when I open my website, it redirects to /en/ while I put Persian as default, and I was active skip localization for the default language. But when it sets on English as the default language, everything works normally.

Plugin version: 2.9.1.2
Wordpress: 5.8.1

Checking "URLs for the default language will be unmodified" prevents redirection to user agent's preferred language. Unchecking it causes redirection to start working, but of course means the default language also gets redirected. Fiddling with other maybe-relevant settings like "Should the language of the requested post take precedence in the event of a language mismatch?" doesn't fix the behavior.

I've reproduced this in a basic docker-compose set-up of Wordpress with just nLingual installed, by creating a translation of the initial "Hello world!" post, getting redirection from the home page to work when my browser language is set to that of the translation, then breaking redirection by checking the "URLs for the default language will be unmodified" box.

This seems like a bug to me in that it's preventing functionality I both wanted and expected, given the settings I'd chosen, to work, but is that the case, or is it in fact working as intended?

Hi,
your plugin is really great. The only thing I've not found is an option to link two already existing translation.
Exampe: I've a post with an id 1 in german and the same post was translated into english with an id 3. How can I group this two posts? The same with reusable blocks, terms and taxonomies.

At the moment I make this directly in database table.

Kind regards and many thanks for this plugin. It seems to be a really good aleternative to polylang.

Create a post with multiple pages using the page break block. Only the first page of this post is now accessible, the rest loops back to the first page.

i can't Find Any Language switcher in the plugin ?
why

Version: 2.9.0

Situation:
Site uses a page as its homepage (the URL of which is typically retrievable with get_option('page_on_front')). This happens to be named "desktop", in this case. Without nLingual, and under nLingual 2.8.10, this resolves simply to example.com/ with no page slug. Under nLingual, the home page is redirected to example.com/desktop/, and get_option('page_on_front') not only returns that desktop/ path while on the homepage, but proceeds to return whatever the current page is, as one nagivates around the site, such that a link that would normally always point at the homepage (simply, example.com/) points instead to, say, example.com/some-page while visiting some-page.

So there seem to be two things going on, that are different from behavior under vanilla WP or nLingual 2.8.10:

1. A page that normally serves as the front-page, is now explicitly redirected to when one visits the home page (load example.com, end up on example.com/desktop)
2. WordPress is unable to locate the home page URL via the page_on_front option, and ends up providing the current page path for some reason.

The first is just undesirable, but the second actually breaks things.

Possibly relatedly, I'm also seeing page URL lookups built into WooCommerce, for things like the cart or checkout URLs, return a link to the site root instead, with the result that these links are non-functional with nLingual 2.9.0 enabled. There seems generally to be something odd happening with internal WordPress page URL lookups, though not with lookups for the purposes of request routing, as far as I can tell (if you put the URLs in manually, they work).

(It may be premature to report bugs in 2.9.0 since it's not up on the plugin market yet, but given the version bump on master I thought it safe to at least try out; if you already knew or suspected it has issues of this sort and aren't ready for anyone to be messing with it, I'll take no offense at a fast close on this issue)

hi great little plugin, but I've encountered a bug: the author archive url gets mangled when nLinugal is active.

Tested with fresh wp 5.8 and Twenty twenty theme, and with nLingual master at 7fbe5fd

How to reproduce:

1. just install the plugin, with all default settings.

2. go to the author archive page.

3. this results in a 404, and the url is something like: the following: (where base url is example.com, author slug is demo_author)

    https://example.com/a href=https:/example.com/author/demo_author/ title=Posts by demo_author rel=authordemo_author/a