Use short names of languages.

• Update Stable tag in readme.txt to the current stable version (3.4)
• Update Version and the BOGO_VERSION constant in bogo.php to 3.5
• Update Tested up to in readme.txt to 5.7
• Add 3.5 change log to readme.txt
• Update the copyright year in license.txt to 2021

When opening Languages > Terms Translation you see two PHP notices because there are unidentified index used.

Major part of the current rewrite rules generating process (includes/rewrite.php) was implemented almost 10 years ago. We should be able to do a lot of things to improve it with the current rewrite API of WordPress.

• de_AT
• es_UY
• hsb
• pt_AO
• snd
• skr

These locale codes on the Languages > Language Packs menu page don't have their language names yet. Update bogo_languages() in includes/functions.php to add their locale code and language names (in English). Correct language names should be retrieved from https://translate.wordpress.org/

For example Contact Form 7 has the Privacy Notices section in its plugin page (readme.txt):

Privacy Notices

With the default configuration, this plugin, in itself, does not:

• track users by stealth;
• write any user personal data to the database;
• send any data to external servers;
• use cookies.

If you activate certain features in this plugin, the contact form submitter’s personal data, including their IP address, may be sent to the service provider. Thus, confirming the provider’s privacy policy is recommended. These features include:

• reCAPTCHA (Google)
• Akismet (Automattic)
• Constant Contact (Endurance International Group)

Let's add an appropriate privacy notices to Bogo's page as well.

While you'll find a post-ID-like integer in the _original_post post-meta value, it is actually not used as a reference to any post. It just indicates that "If there is another post with the same _original_post, it is a translation copy with the same origin." So, it can be any value, as long as it is unique.

To clarify this rule and ensure it works correctly even when you export posts to another site, let's use the GUID for the default value of _original_post. You can use get_the_guid() to get the GUID of a post.

Always refer to bogo_available_languages() output for language names.

Since WordPress 4.7 introduced the concept of user locale, its API has been improved a lot, and we can utilize it to improve Bogo's code around user locale management.

https://make.wordpress.org/core/2019/09/23/date-time-improvements-wp-5-3/

Date/Time component has been improved in WordPress 5.3. A lot of date/time related functions are now obsolete, and sophisticated alternatives are available.

Let's refactor our code using new recommended date/time functions.

The current Bogo's coding is mainly based on very old versions of WordPress (5+ years old), and there is much space where we can make it much more efficient using APIs the current WordPress provides.

The project aims to raise the minimum supported WordPress version to 5.3 in the next release (Bogo 3.3). This also means we can use new PHP features available in PHP 5.6.20+ in plugin development.

We plan to do coding modernization in the following areas:

• Use the metadata API and register all meta keys using register_meta() and register_post_meta().
• Use PHP anonymous function to define a WordPress filter/action function where it's appropriate (removal of the filter/action is not anticipated).
• Use Block Editor features aggressively (but, keep a minimum level of Classic Editor compatibility).

If there is a possibility to be used in admin screens.

Related: #77

https://core.trac.wordpress.org/changeset/45926

Following this WP core change, let's check translator comments used in our code and improve them if necessary.

Related forum topic: Category base and Category archive

When you set the Category base option, localized permalinks are not created for category. The same problem is seen with post tags.

In bogo/includes/post.php we use the wp_unique_post_slug filter hook to generate a post slug unique within the same locale. We can change the hook to pre_wp_unique_post_slug (introduced in WP 5.1.0), and this change should make the process much more efficient.

After adding translation languages in the edit page and when reloading the edit page, it is still showing empty select container even if there are no language options are available.

Screenshot

Sometimes the process takes a bit long time than that expected and makes users feel lost.

See https://developer.wordpress.org/block-editor/components/spinner/ for the Spinner component.

• Add 3.3.3 change log to readme.txt
• Change Stable tag to 3.3.2 (previous version) in readme.txt
• Update Version and the BOGO_VERSION constant to 3.3.3 in bogo.php

The bogo_access_locale capability determines if the user is permitted to access resources in the specific locale. The check of this capability should be done inside another meta capability check (such as edit_post or delete_post).

In bogo_duplicate_post(), a new translation post inherits the original post's post-metas excluding non-inheritable post-metas. Non-inheritable post-metas are _locale and _original_post now, and they are not customizable. In some cases you'll need to add some post-metas to this list. For such cases let's add a filter hook that allows to do so.

If you have post-metas that you think should be in the non-inheritable list, take this opportunity to add them to the default list.

See includes/language-switcher.php

• Link to a translation page even when the target locale is equal to the current locale
• Wrap each label text (language name) with <span class="language-name"></span>
• Add the current class to the current <li> and <a>
• Add aria-current="page" to the current <a>

Bogo sets its lang cookie in bogo_init() (bogo.php), but this cookie has actually been unused for a long time. We have to decide to drop this setcookie(), or make its use restricted with new cookie settings.

Related issue: #11

It should return posts in the same locale as the post you are editing.

It seems that there are some compatibility issues between the current version of Bogo and the Block Editor (Gutenberg).

https://wordpress.org/support/topic/how-to-set-the-parent-of-a-translated-page-to-another-translated-page/

Register post metadata (we are using _locale and _original_post now) using register_post_meta().

• Update Stable tag in readme.txt to the current stable version (3.3.3)
• Update Version and the BOGO_VERSION constant in bogo.php to 3.3.4
• Update Tested up to in readme.txt to 5.5
• Add 3.3.4 change log to readme.txt

https://developer.wordpress.org/reference/functions/wp_parse_url/

• Update Stable tag in readme.txt to the current stable version (3.3.4)
• Update Version and the BOGO_VERSION constant in bogo.php to 3.4
• Update Tested up to in readme.txt to 5.6
• Add 3.4 change log to readme.txt

• Add 3.3.1 change log to readme.txt
• Update Version and the BOGO_VERSION constant to 3.3.1 in bogo.php

If you switch locale too early, lang tags in header (such as <html lang="en-US">) may be unintentionally affected by the user locale.

No auth_callback arg is set in the register_post_meta() calls. The auth_callback arg is optional, but __return_false() is assigned if omitted.

Related forum topic: Gutenberg: Updating failed with custom post meta

Rewrite admin/includes/js/admin.js without using jQuery.

Sometimes the display name of a language gets unnecessarily long. For example, you don't need to display the full name of "English (United States)" when you don't have other English languages like "English (UK)", you'll think just "English" is OK.

My suggestion is to add a "short name" option to bogo_available_languages(). The option should have a boolean value, and when the value is true, the output of the function will be shortened, as long as it's appropriate, by removing tails in parentheses.

Displaying "—" (em dash) instead of "—" is the best, but using the original input ("---") is also acceptable.

https://github.com/takayukister/flamingo/wiki/Coding-Standards

Some parts of Bogo code are old so you may find code that is not following the coding standards. Let's check whole coding and refactor based on the standard on this occasion.

• Update the copyright year in license.txt to 2007-2020
• Add itpixelz to Contributors in readme.txt
• Revise readme.txt based on the documentation style guide
  • Use sentence case for headings
  • Use ** to wrap a menu item (Languages > Installed Languages)
  • Use ` to wrap a code in text (_locale)
  • Not "allow to" but "let"
• Some other explanation in readme.txt need to be revised
• Add 3.3 change log to readme.txt
• Update Requires at least (5.3), and Tested up to (5.3)
• Donate link of pledgie.com is dead; replace it with contactform7.com/donate for now
• Update Version and the BOGO_VERSION constant to 3.3 in bogo.php
• Screenshot images need to be updated; use ones of Block Editor UI

You can make function calls efficient by using static variables appropriately.

They are already used in some functions of Bogo.

These functions should use static variables but are not using them now:

• bogo_get_post_translations() in includes/post.php

Related forum topic: Bogo & Sitemap
About XML Sitemaps: New XML Sitemaps Functionality in WordPress 5.5

I could confirm that localized posts are not included now.

When the user locale is en_US and in the Posts screen (Posts > All Posts) you select Japanese from the "Show all locales" filter, the whole UI should keep English, but it actually shows Japanese.

See https://make.wordpress.org/polyglots/2020/03/26/the-language-name-in-english/

In includes/functions.php we have "Punjabi" now. If the name is changed in https://translate.wordpress.org/ then we will change it as well.

See the same issue on Contact Form 7

• Add 3.3.2 change log to readme.txt
• Update Tested up to (5.4)
• Update Version and the BOGO_VERSION constant to 3.3.2 in bogo.php

Update the package.json file following webpack documentation.

https://webpack.js.org/guides/getting-started/#basic-setup

In post translation meta widgets the en_US translation appears even when en_US is deactivated in the Language Packs page.

In determine_locale(), get_user_locale() takes priority over get_locale() when is_admin() returns true. This makes the lang variable unintentionally ignored in the admin screen.

See the same issue on Contact Form 7

Hi, I have built a custom rewrite rule that includes also the locale.

Since the update to 3.5 it is not working anymore.

This is my custom rewrite rule:

// Photogallery filter pictures by event
add_rewrite_rule( '^([^/]*)?/?gallery/([^/]*)/([^/]*)/event/([0-9]+)/?$', 'index.php?competition=$matches[3]&external_id=$matches[2]&event=$matches[4]&lang=$matches[1]','top' );

The first capturing group is the locale. If I use the query string url is not working anymore.

Any quick clue? I will investigate more in the next hours, at the moment I hotfixed reverting the 3.4 back