Doug Wollison

The plugin by default adds a “Translate This” widgets to the Site Title and Tagline fields. It should appear as a grey button next to the field with a translate icon. Hover over this and it will expand to list buttons for each language you have available; select a language and the field will change to show the translation for that language. You can then write in the translated value, and when you hit update or change to another language, that value will be saved for that language only.

For other fields, you can write a custom init hook that calls the nLingual\Localizer::register_option_field utility to add this to a field on any settings page on the site (may not work with certain plugin control panels though).

function mytheme_register_localizer_fields() {
	nLingual\Localizer::register_option_field( 'SETTING_NAME', 'PAGE_ID', array( 'field_id' => 'SETTING_FIELD_ID' ) );
}
add_action( 'init', 'mytheme_register_localizer_fields', 10, 0 );

Crap I’m sorry I was in a frustrated rush to post this and went to the support forum for the wrong plugin (right next to each other in the plugin list on the site I’m working on).

Also, I’d suggest tweaking how you’re fetching the $stickies list; you’re calling get_posts which by default supresses filters, whereas the native wordpress method inherits the settings of the original query.

$stickies = get_posts(
	array(
		'post__in'               => $sticky_posts,
		'post_type'              => $q['post_type'],
		'post_status'            => 'publish',
		'posts_per_page'         => count( $sticky_posts ),
		'suppress_filters'       => $q['suppress_filters'],
		'cache_results'          => $q['cache_results'],
		'update_post_meta_cache' => $q['update_post_meta_cache'],
		'update_post_term_cache' => $q['update_post_term_cache'],
		'lazy_load_term_meta'    => $q['lazy_load_term_meta'],
	)
);

Again this assumes $q is defined as referring to $wp_query->query_vars

• This reply was modified 1 year, 11 months ago by Doug Wollison.

Sorry about the delay.

To get the translation of a given post in a given language, you can use the following code:

$default_language = nLingual\Registry::default_language();
$translated_post_id = nLingual\Translator::get_post_translation( $post_id, $default_language );

The latter method is a shortcut to the get_object_translation method, since I went a bit overboard future proofing this to handle objects other than posts. I apparently also did a poor job tagging the code so your editor’s autocomplete can’t event recognize it. I’ll brush up on my phpDoc stuff and see about at least fixing that.

I’m going to also try and finally start writing a codex/wiki for the plugin; documenting all the public-use functions.

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

I have to get post (post object or id) in default language if I know $post object from another language. Is there any method for that?

Sorry, can you rephrase that? I don’t quite understand the question.

That’s… odd. I didn’t run into that during testing. I’ll take a closer look this week and iron that out.

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.

I have a pending update that includes handling for sitemap requests but apparently it doesn’t work with AIOSEO due to how it flags sitemap requests. I’m adding handling for that plugin, aiming to publish the update in the comming weeks.

In the mean time, you can add this code to your theme’s functions.php file, should prevent the redirect.

add_filter( 'nlingual_maybe_redirect_language', function( $url ) {
	if ( get_query_var( 'aiosp_sitemap_path' ) ) {
		return false;
	}

	return $url;
} );

(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 3 years, 11 months ago by Doug Wollison.

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 /

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.

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.

Hi,

The plugin offers a way to add these links via the nav menu (a Language Links box will appear in the left column of the menu editor), however there’s not much of a built-in utility for printing a language nav outside of the template, since I didn’t want to lock-in the markup (though I could write something with config options for it).

In most cases on my projects, I write something like this in the header template.

<nav class="language-nav" role="Language">
    <?php foreach ( nLingual\Registry::languages() as $i => $language ) : ?>
        <?php echo $i ? '/' : ''; ?>
        <a  rel="alternate"
            href="<?= nLingual\Rewriter::localize_here( $language ) ?>"
            hreflang="<?= $language->locale_name ?>"
            class="<?php echo nLingual\Registry::is_language_current( $language ) ? 'is-current' : ''; ?>"
        ><?= $language->short_name ?></a>
    <?php endforeach; ?>
</nav>

That will print a <nav> element with an >a< link for each language the site supports, flaging the current one with the is-current class. The aria-label might be tricky to implement (maybe a sprintf() call using a localized string), but otherwise that should do the job.

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

Sorry for the delay; it’s been a hell of a month.

Disabling the plugin would turn off the link rewriting, however if you have it set to run the backend through the primary domain (e.g. subsite-example.com/wp-admin instead of example.com/subsite/wp-admin) you’ll likely find a number of URLs in your page content (links, images, etc) using the mapped URLs. This may happen regardless if you’re using the block editor; haven’t actually tested this plugin with it but it’ll probably rewrite any URLs in the JSON responses.

As for the staging approach, yes that would work just fine.

I’m not sure I understand what the problem is. I’m having trouble finding the buddypress pages you mentioned.