Multilify

<?php if ( function_exists( 'multilify_switcher' ) ) multilify_switcher(); ?>

<?php if ( function_exists( 'multilify_switcher' ) ) multilify_switcher( array( 'show_name' => false ) ); ?>

[multilify_switcher show_name="false"]

Changelog

1.4.0

Changed
* An entry given a custom slug in the default language now answers on that address alone. Its WordPress slug returns a permanent redirect to it, the way WordPress answers any renamed entry, and page numbers, feeds and embeds are carried across. Both addresses used to return 200, and inconsistently: the paged form already redirected, because WordPress only runs its canonical check on a request carrying a page number
* An entry with no custom slug in the default language is untouched, and so is every prefixed language, which has one address already

1.3.3

Fixes
* Renaming an entry left the cached answer to “does a real entry already live at this address” untouched for both the address it left and the address it took. A rename is not a status change, so nothing cleared it. On a site with a persistent object cache, an entry whose own translated slug was the freed address returned a 404 for up to an hour. Measured against a persistent cache on MySQL, before and after

1.3.2

Fixes
* The marker added to a translation panel heading in 1.3.0 was written as markup. The block editor lists the same heading in its preferences panel and renders it as text, so the tag showed there verbatim. It is plain text now, and reads the same in the panel heading, the preferences list and Screen Options

1.3.1

Fixes
* A paged page nested under a translated parent had no working address at all. /{lang}/parent/entry/2/ returned a 404 and /{lang}/parent/entry/page/2/ redirected to it, so the redirect landed on the 404 as well. Both now serve the right page, and a child page whose own slug is a number still resolves ahead of either
* The address a visitor asked for is restored once routing has matched it. It was being left rewritten to the untranslated path, which put a paged entry into a redirect loop with itself and handed every other plugin an address nobody requested

1.3.0

Fixes
* A custom slug in the default language produced a link that 404ed. Every link to the entry pointed at an address nothing resolved, while the entry itself stayed reachable only at its old one
* A child page with no translated slug of its own returned a 404 under a translated parent, so a half-translated page tree lost every page below the first
* ?lang= on any address forced the front page onto it, which turned archives, search results and date listings into the blog index
* An unknown language code from ?lang= reached the <html lang> attribute and the Content-Language header unchanged; only configured codes are honoured now
* A paged entry under a language prefix returned a 404, and a feed of one did too, because both routed through the query variable an archive uses and through a rule WordPress rejects for a post. /{lang}/entry/2/ now serves page two, and /{lang}/entry/page/2/ reaches it the same way it does without a prefix
* Two entries could be given the same translated slug in one language, leaving the second unreachable. A duplicate is now numbered the way WordPress numbers a duplicate post slug
* Cached routes are dropped when an entry is trashed, restored or deleted, instead of answering for an hour from a persistent object cache
* A language code that WordPress already serves, or that an existing post or page already lives at, is refused with an explanation instead of quietly taking the address over
* Uninstall removes translation meta in batches, so a large site is not held on one unbounded delete

Added
* Each language on the settings page carries a measure of how much of it is done
* A translation panel on the post editor says so in its heading when that language already has something, which a collapsed panel shows

Changed
* The switcher marks the active language with aria-current="page"
* The switcher stylesheet and script are left out entirely on a site with one language

1.2.0

Added
* Turkish, German and Spanish translations of the admin interface. WordPress shows the plugin in its own language when the site runs in one of them, and falls back to English otherwise.
* Any other locale can be contributed at translate.wordpress.org, from the translation template the plugin already ships

1.1.0

Fixes
* Language detection now works when WordPress is installed in a subdirectory; the install path is no longer mistaken for a language code
* /{lang}/page/2/ and /{lang}/feed/ return content instead of a 404; paged entries, entry feeds and search under a language prefix now route correctly
* Child pages keep their parent path in translated URLs, so /{lang}/parent/child/ resolves instead of 404ing
* The document title on the front page and on archives is no longer overwritten with a post title from the loop
* Translation panels no longer save on revisions or on post types they were never added to
* Meta box fields no longer inherit the inline editor’s layout, which shrank their labels and clipped their inputs

Added
* rel="alternate" hreflang tags, including x-default, in <head>
* <html lang> and a Content-Language header that follow the language being viewed
* Browser language detection for first-time visitors, remembered per visitor and overridable with the multilify_enable_browser_detection filter
* Translation progress per language on the settings page
* A flag picker in place of the free text emoji field
* Custom post type support through the multilify_post_types filter
* Filters: multilify_translated_title, multilify_translated_content, multilify_flag_choices, multilify_locale

Changed
* Rebuilt the settings screen: language entries read as a list with their code, name, default state and progress
* Corrected readme claims that the code did not support

1.0.5

• The default language no longer gets a URL prefix, so each post has a single canonical address
• Added uninstall cleanup that removes plugin options, translation meta and the lookup index
• Made the plugin translatable: interface strings now use the multilify text domain and a .pot template ships in /languages
• The default language can no longer be deleted, and only an existing language can be set as default
• Language switcher is now a nav list with hreflang, aria-current and a screen-reader label when only flags are shown
• Fixed the delete confirmation appearing twice
• Added a LICENSE file (GPL v2)

1.0.4

• Tested up to WordPress 7.1
• Verified compatibility with the always-iframed post editor introduced in WordPress 7.1
• Verified compatibility with the jQuery UI 1.14.2 update shipped in WordPress 7.1
• No functional changes

1.0.3

• Added the ability to edit existing languages (name and flag) from the admin
• Prevented adding a language with a code that already exists (shows an error)
• Registered the [multilify_switcher] shortcode (supports show_name and show_flag)
• Fixed a blank settings page after saving (form handling moved to admin_init so redirects work)
• Fixed PHP warnings in the language switcher when a post object was unavailable
• Tested up to WordPress 6.9

1.0.2

• Added flag-only language switcher support via show_name and show_flag arguments
• Made the language name optional (falls back to the language code when left empty)
• Fixed an empty/underlined language label appearing in the switcher

1.0.1

• Added plugin icon for WordPress.org directory
• Added Plugin URI (https://multilify.vercel.app)
• Updated support section with website and GitHub links

1.0.0

• Initial release
• Unlimited language support
• Custom slug functionality
• Performance caching system
• Database indexing
• Language switcher
• SEO optimization
• Browser language detection
• Admin interface
• Translation meta boxes