Doug Wollison

<p>The nLingual system allows for flexible multilingual support and translation management for WordPress. The system handles translations on a per-post basis, and can be set to be synchronized so changes to certain details on one are copied to the others. It offers you control over what can be translated and how, with a number of utilities available for 3rd party themes and plugins to utilize.</p>
<p><strong>nLingual 2 offers more robust control of translation management, better extensibility, and fixes to numerous core issues with the previous incarnation.</strong></p>
<h4>Translation for Almost Anything</h4>
<p>When setting up, you have control over what content supports translation. Any UI-enabled post types or taxonomies will be available for enabling, along with any navigation menus or sidebar locations registered. In addition, nLingual includes a LocalizeThis API that can be enabled on nearly any text field found in the admin, allowing just about any option or meta field to support separate values in each language.</p>
<h4>Simple Translation Creation and Management</h4>
<p>Assigning a language and translations to a post can be done on either the post editor screen or the posts management screen via Quick Edit (language can also be set for multiple post via Bulk Edit). You can also easily create new translations for existing posts on the fly; select “New [language] [post type]”, provide a translated title if you wish, and a new draft post will be created that is an exact copy of the original, ready for translation.</p>
<p>Translations are stored as independent posts, associated with their counterparts via a custom table. This allows you to translate the custom fields and other metadata associated with a post, and can assign them their own separate terms if desired. However, since there are plenty of occasions where you want the same information used between posts, nLingual offers <em>post synchronization</em>.</p>
<h4>Post Synchronization</h4>
<p>Each post type has it’s own rules for what data is synchronized between translations. When changes are saved to a post, it’s translations will be updated with to have the same data in the approved fields. This covers post data (e.g. date, status, and menu order), terms of specified taxonomies, and any meta fields you specify (e.g. the thumbnail image used, or a custom field value).</p>
<p><strong>Note: Currently, there is no per-post basis override for the synchronization rules</strong></p>
<h4>Free-form Language Management</h4>
<p>Admittedly, this is a feature few will need, but it’s a godsend to those that do. When setting up the languages nLingual will use, you can define you own languages from scratch or based on numerous presets. Each language has a number of fields:</p>
<ul>
<li>System Name: the name to use when referring to the language within the admin.</li>
<li>Native Name: the name of the language as it appears to native speakers on the site.</li>
<li>Short Name: a shorthand version of the native name, if applicable.</li>
<li>Locale: the language/country code to represent this language, as well identify the .mo file to load for text domains.</li>
<li>ISO Code: the official ISO 639-1 code for the language (2 letters)</li>
<li>Slug: the value to use when localizing a URL for the language (typically the same as the ISO code).</li>
<li>Text Direction: the text direction the language should be rendered in (Left-to-right or right-to-left). Will override the one specified in the text domain files.</li>
<li>Active State: whether or not to allow public access to content in the language.</li>
</ul>
<h4>Flexible Language Detection/Switching</h4>
<p>When the public-facing side of the site is loaded, nLingual will attempt to detect what language to serve the page in, using the following process:</p>
<ol>
<li>Use the language code in the <code>$_REQUEST</code> array for the specified key, if present.</li>
<li>Use the language code in either the subdomain or directory path, depending on method specified.</li>
<li>Use the browser’s preferred language setting and find the closest match, falling back to the default language.</li>
</ol>
<p>Once the language is set, it can be overridden by the language belonging to the requested post. This override is an configurable option.</p>
<p>In addition, the language can temporarily be switched to another by 3rd party theme or plugin code, similar to switching blogs in a multisite installation. When the language is switched, all text domain files will be reloaded in the desired language (the originals cached for when it’s restored), so any gettext translations will reflect the current language.</p>
<h4>Extensibility and 3rd Party Development</h4>
<p>In addition to numerous hooks to modify the functionality of nLingual, this plugin also includes some useful gettext utilities: <code>_f</code>, <code>_ef</code>, <code>_fx</code>, <code>_efx</code>, <code>_a</code>, and <code>_xa</code>, all of which are documented in <code>includes/functions-gettext.php</code>.</p>
<h4>Backwards Compatibility</h4>
<p>Although nLingual 2 has be rewritten from scratch, most if not all of the functions and filters are still available via the backwards compatibility feature, which is automatically enabled upon upgrading. However, any code that directly queries the database using the old nLingual language and translation tables will need to be updated to reflect the new structure.</p>


nLingual

This is plugin that I chose as a developer because of it's simplicity and minimal impact on page speed. I tested it along with several other much more famous plugins, and this gave me the best speed results. If some small issues with plugin would be resolved, I would give it a 5 star. I see a potential in it.

The plugin I like

A simple but flexible multilingual system. Features custom language management, post data synchronization and theme/plugin development utilities.

Atte Liimatainen

<p>WordPress plugin that helps to serve content through REST routes and gives<br />
customizability to developers through filters.</p>
<h3>Available Routes</h3>
<ul>
<li><code>/wp-json/arha/v1/post</code></li>
<li><code>/wp-json/arha/v1/page</code></li>
<li><code>/wp-json/arha/v1/options</code></li>
<li><code>/wp-json/arha/v1/archive</code></li>
</ul>
<h3>Example queries</h3>
<ul>
<li><code>/wp-json/arha/v1/post?post_type=POST_TYPE&slug=SLUG</code></li>
<li><code>/wp-json/arha/v1/page?path=PATH</code></li>
<li><code>/wp-json/arha/v1/options</code></li>
<li><code>/wp-json/arha/v1/archive?post_type=POST_TYPE&posts_per_page=POSTS_PER_PAGE&paged=PAGED&orderby=ORDERBY&order=ORDER</code></li>
</ul>
<h3>tax_query and meta_query in archive-route</h3>
<ul>
<li><code>tax_query</code> and <code>meta_query</code> are supported and they work how the query is built for it in <code>new WP_Query()</code></li>
<li>both needs their values to bes passed in as stringified json</li>
</ul>
<h3>Multiple post_types in archive-route</h3>
<ul>
<li>To pass multiple post_types in archive-route, use syntax that lets PHP read GET-param as an array. https://stackoverflow.com/a/9547490</li>
</ul>
<h3>Filters</h3>
<ul>
<li>
<p>To exclude querying specific post types from <code>post</code>– and <code>archive</code>-routes, you<br />
can use following filters:</p>
<p>`<br />
add_filter(‘arha_routes/archive_excluded_post_types’, ‘exclude_post_types’);<br />
add_filter(‘arha_routes/post_excluded_post_types’, ‘exclude_post_types’);</p>
</li>
</ul>
<p>function exclude_post_types($excluded_post_types) {<br />
  $excluded_post_types = [‘post’];<br />
  return $excluded_post_types;<br />
}<br />
    `</p>
<ul>
<li>To format <code>post</code>-route’s post before it’s served to client, use <code>arha_routes/format_post</code>-filter<br />
`<br />
add_filter(‘arha_routes/format_post’, ‘format_post’);</li>
</ul>
<p>function format_post($post) {<br />
  return $post;<br />
}<br />
    `</p>
<ul>
<li>To format <code>page</code>-route’s post before it’s served to client, use <code>arha_routes/format_page</code>-filter<br />
`<br />
add_filter(‘arha_routes/format_page’, ‘format_page’);</li>
</ul>
<p>function format_page($page) {<br />
  return $page;<br />
}<br />
    `</p>
<ul>
<li>
<p>To format <code>archive</code>-route’s posts before they are served to client, use <code>arha_routes/format_archive_post</code>-filter</p>
<p><code>add_filter('arha_routes/format_archive_post', 'format_archive_post');<br />
function format_archive_post($post) {<br />
return $post;<br />
}</code></p>
</li>
<li>
<p><code>options</code>-route returns empty result by default. To add content to it, use <code>arha_routes/format_options</code>-filter<br />
`<br />
add_filter(‘arha_routes/format_options’, ‘format_options’);</p>
</li>
</ul>
<p>function format_options($options) {<br />
  return $options;<br />
}<br />
    `</p>
<ul>
<li>
<p>By default Arha Routes returns only published content with post-, page- and archive-route, this can be modified by adding following filters.<br />
`<br />
// for archive route<br />
add_filter(‘arha_routes/allowed_post_statuses_archive’, ‘allowed_post_statuses’);<br />
// for post route<br />
add_filter(‘arha_routes/allowed_post_statuses_post’, ‘allowed_post_statuses’);<br />
// for page route<br />
add_filter(‘arha_routes/allowed_post_statuses_page’, ‘allowed_post_statuses’);<br />
function allowed_post_statuses($post_statuses) {<br />
// … change post_statuses array</p>
<p>return $post_statuses;<br />
}<br />
`<br />
After adding setting up these filters, request can include “post_status” parameter and it will be compared to $post_statuses array.</p>
</li>
</ul>
<h3>SearchWP</h3>
<p>Arha Routes supports SearchWP-plugin, which lets WP users to make keyword search engine for their content.</p>
<p>Activating SearchWP-plugin adds optional keyword-search functionality to <code>archive</code>-route. This is done by adding <code>s=KEYWORD</code> to the route<br />
– Example: <code>/wp-json/arha/v1/archive?post_type=products&posts_per_page=10&paged=1&orderby=date&order=ASC&s=monitor</code></p>
<h3>Polylang</h3>
<p>Arha Routes supports Polylang-plugin, which allows users to create content in multiple languages.</p>
<p>Activating Polylang changes how endpoints work:</p>
<ul>
<li>All routes require additional <code>lang</code>-param
<ul>
<li>Example: <code>/wp-json/arha/v1/archive?post_type=products&posts_per_page=10&paged=1&orderby=date&order=ASC&lang=en</code></li>
</ul>
</li>
<li><code>page</code>-route doesn’t support language prefix in path
<ul>
<li>Example: Permalink <code>/zh/info</code>, use like this <code>/wp-json/arha/v1/page?path=/info&lang=zh</code></li>
<li>Example: Permalink <code>/en/info/test</code>, use like this <code>/wp-json/arha/v1/page?path=/info/test&lang=zh</code></li>
</ul>
</li>
<li><code>options</code>-route passes <code>lang</code>-param forward to <code>arha_routes/format_options</code>-filter<br />
<code>add_filter('arha_routes/format_options', 'format_options', 10, 2);<br />
function format_options($options, $lang) {<br />
return $options;<br />
}</code></li>
</ul>
<h3>Polylang + SearchWP</h3>
<p>In order to make these two plugins work together, you need to add extra plugin to WP installation.</p>
<p>https://searchwp.com/extensions/polylang-integration/</p>


Arha Routes

Wordpress plugin that helps to serve content through REST routes and gives customizability to developers through filters.

nLingual vs Arha Routes