Bulk edit

Bulk editing should appear as a “Language [dropdown]” field just above the Cancel button in the bulk edit form. However, if you have “Lock Post Language” enabled, it won’t show.

If it’s a custom post type, make sure it’s checked off under Translation > Localizables.

Hello again,
I still do not see bulk editing. There is a language switching option in a “quick edit” section when I am in “Pages” wordpress screen, but there is no option in “Bulk actions”

Now I understand what you meant as “bulk editing” – an option to change language while in quick edit. However, this is not bulk editing. It would be an option to select multiple posts/pages and run an action from “bulk actions” combo box drop down.

If you select muplitle posts/pages and select Edit from the Bulk Actions dropdown, and click Apply, it should show a Language dropdown in the Bulk Edit form that appears.

There is still no Language dropdown?
Also, “Skip Localization for Default Language?”, does not work as well, I am getting /ll/ in url for both languages that are set up.

Further, which may not be at all related to your plugin, but i18n functions in my theme do not work, it may be some issue due to windows environment and local development. Any hint in resolving this would be greatly appreciated.

• This reply was modified 4 years, 3 months ago by Lovro Hrust.

I managed to resolve last issue (i18n functions did not work) and it was apparently due to a change of source file which was not reflected in .po and .mo files.

Now the first two issues still remain…
Also, “Skip Localization for Default Language?”, does not work as well, I am getting /ll/ in url for both languages that are set up.
And there is no Language dropdown in bulk edit.

Any help would be greatly appreciated. Second issue is not so important.

Is the default language the same language as your system/browser? I modified the URL handling so that, say, a french visitor who wanted to view the english homepage could access it at /en/ while english visitors could visit it at /

No, default language is Croatian, while both system and browser languages are English.

(sorry, been juggling way too many rush jobs)

If the default language on the site is Croatian, and you have skip-default-localization enabled, but you’re visiting it in a browser set to english, then that’s actually the expected behavior.

Back in september (version 2.9) I modified how that feature works, because before it was impossible to view the homepage if your browser accepts one of the other supported languages. I was going to limit it to only apply to the homepage, but that caused issues for pages that might share a URL slug, so I was forced to have skip-default-locazation be ignored when the vistor isn’t using the default language on their browser.

If you change the default language to English, or your system/browser to croatian, you should see that it properly handles skip-default-localization. I could see about adding an additional option to disable the exceptions.

• This reply was modified 4 years, 3 months ago by Doug Wollison.

I tried setting language of the site in wordpress to Croatian, as well as disabling “skip localization for default language”, but I am still getting redirected to english version on home page, although I would wish it is Croatian.

Could you give me a hint about the place in the code where I can change this, so default homepage language would be Croatian?

I currently came with this, inside must-use plugin (is there a way to use filters from your plugin in functions.php?).

This prevents redirections from front page to english version of front page if language slug does not exist in URL when root URL of the page is opened.

I would also like to prevent /hr/ slug extensions for croatian pages.

add_filter( 'nlingual_detected_language', function($language) {
	$newlanguage = $language;
	if ($_SERVER['REQUEST_URI'] === "/")
		$newlanguage = \nLingual\Registry::get_language('hr');
 	return $newlanguage;
} );

Hi, sorry I’ve been slammed with must-launch-before-christmas projects all month.

I R&D’d some of this on an english/french site I have, and figured out a hack that should reliably disable the browser language detection. I promise the next update to nLingual will have options to better control how language detection/redirection works, as well as more filters for manipulating stuff in a less bludgeon-y way.

Put this in an mu-plugins file (recommend creating a new one, call it nlingual-patches.php or something).

<?php
// Prevent nLingual from using the browsers accepted language
unset( $_SERVER['HTTP_ACCEPT_LANGUAGE'] );

That should do the job without breaking anything. Skip Default Localization will be maintained as nLingual won’t be able to detect the browser’s language without that header’s data being available. If croation is set to the default language you should be able to view it without /hr/.

Regarding your question about functions.php, most filters can be used there but some apply to code like language detection which runs before your theme code is even loaded (wordpress loads mu-plugins, plugins, child theme, then parent theme).

[Edit: Wow I accidently posted this from my alt account]

• This reply was modified 4 years, 3 months ago by Doug Wollison.

I’ve published an update (2.9.1.1) that makes it possible to “disable” the accept-language handling I mentioned. You can now clear the “Code(s)” field on the Languages manager for any given language. With nothing to compare, the system won’t try to redirect people to their preferred language, and hence won’t igore skip-default-localization.

Thanks, I’ll try that. Cheers!
Edit: your last solution with unset server var in mu-plugins works fine!

• This reply was modified 4 years, 2 months ago by Lovro Hrust.

I tested update. I had to clear both languages codes, and when doing so I got PHP errors, something about vsprint function and that headers had already been sent.

Except for these errors when clearing codes, your change worked the same as mu-plugin solution.