Preferred Languages: The Prototype

A bit over six months ago I set the foundation for the Preferred Languages feature project. After highlighting the problems many WordPress users around the world are facing, some time was spent on researching popular platforms and other systems to see how they handle the issue of setting multiple preferred languages. However, this didn’t really help to move one step forward and the project became dormant — until now.

Personally, I’ve been experiencing the same problems with so-called language fallbacks over and over again. During WordCamp Bilbao I decided to revive the Preferred Languages project. In order to do this I used the previously mentioned GitHub repository to build a super-simple proof-of-concept plugin to have a new basis for discussion. As originally envisioned, this repository can be used as a playground for discussions, prototypes, and eventually a working solution.

This new plugin lets you select multiple preferred languages in your settings. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list.

A sneak peek of an early version quickly made the rounds on Twitter:

After some very positive feedback I worked a bit more on it and wanted to share the latest version here with a larger group of people. Here’s what it currently looks like on both the settings screen and when editing your profile:

Without much further ado, please check out the plugin on GitHub, test it on your local WordPress site, and leave some feedback!

#feature-projects, #i18n, #preferred-languages

Preferred Languages: Research

Following the first meeting of the Preferred Languages project, some time was spent on researching popular platforms and other systems to see how they handle the issue of setting multiple preferred languages. To recap, this is needed to show things in the most suitable language for users in case their requested language is not installed.

Browsers & Operating Systems

All major browsers and operating systems have some UI where the user can set their preferred languages. Mostly used for the Accept-Language HTTP header, one can set multiple languages and order them by preference. These systems usually know multiple variants like German and German (Switzerland), but not formal / informal variants.

Worth noting that on these systems you can often choose more settings that are influenced by the language, like temperature units and date formats. Related: #18146.

The Accept-Language HTTP Header

RFC 7231 about the HTTP/1.1 standard says the following about this header:

The “Accept-Language” header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Each language-range can be given an associated quality value representing an estimate of the user’s preference for the languages specified by that range.

This header is quite powerful. For example, Accept-Language: da, en-gb;q=0.8, en;q=0.7 would mean: “I prefer Danish, but will accept British English and other types of English”. I can only recommend reading more about it in the RFC, as it helps getting a better understanding of the problems it tries to solve.

This header is usually used by websites to redirect users to the correct version or display a hint like “This content is also available in XY”. While each language in the header has a specific numeric priority, there is usually only a drag & drop interface to determine the order.

Unicode Common Locale Data Repository

The Unicode CLDR provides key building blocks for software to support the world’s languages, with the largest and most extensive standard repository of locale data available. It contains an interesting chart about Language Matching, data that is used to match the user’s desired language/locales against an application’s supported languages/locales.

There’s also a technical standard about Unicode Locale Data Markup Language (LDML), an XML format for the exchange of structured locale data. The section about Locale Inheritance and Language Matching is particularly interesting. For instance, it describes finding the most well suited language using a weighted graph and gives a better picture of dealing with more complex language fallbacks.

It also takes geographic “closeness” into account, arguing that English (Slovakia) should fall back to something within Europe (e.g. British English) in preference to something far away and unrelated like English (Singapore). It’s clearly stated that these fallbacks aren’t as simple as just saying Spanish (Mexico) -> Spanish (Spain) -> English (US).

Note that this technical standard is about finding the best supported locale based on the requested list of languages. The requested list could come from different sources, such as such as the user’s list of preferred languages in the OS Settings, or from a browser’s Accept-Language list.

Wikipedia

Wikipedia is built on the MediaWiki software, which has a hardcoded list of fallback chains for some locales. This is where MediaWiki will fall back on a different language if it cannot find what it needs. For example, French (Cajun) automatically falls back to French (France) when it doesn’t have all messages defined in it. Unfortunately, there’s only little documentation about this.

Apart from that, MediaWiki distinguishes between various kinds of languages: the site content language, the user interface language and the page content language. The latter can differ from the first two and it influences the language the user views the page in, which depends on the user’s preferences, the available languages, and the defined fallbacks.

It’s worth noting that on Wikipedia, you can not only select your preferred language, but also your preferred gender. In addition to that, you can select multiple different locales for both display and input.

Joomla

I tried the official Joomla Demo to test its language management which is a bit overwhelming at first. After installing all the available languages the user is eventually able to select their preferred language for the front end and the back end. There are a few other settings for language switching on multilingual sites, but that’s pretty much it. So basically the same settings as currently in WordPress 4.7.

Joomla User Settings

Joomla User Settings

 

Drupal

Drupal 8 has a rather powerful user interface text language detection mechanism. There is a per session, per user and per browser option in the detection settings. However, users can only choose one language, so they cannot say (in core at least) that they want German primarily and Spanish if German is not available. But the language selected by the user is part of the larger fallback system, so it may fall back further down to other options.

The Language fallback module allows defining one fallback for a language, while the Language Hierarchy module provides a GUI to change the language fallback system. It allows setting up language hierarchies where translations of a site’s content, settings and interface can fall back to parent language translations, without ever falling back to English. This module might be the most interesting one for our research.

Drupal Language Hierarchy

Drupal Language Hierarchy

TYPO3

TYPO3 has had a locale hierarchy since 2011. Quote:

TYPO3 4.6 comes with a clever fallback mechanism when a label is not found in the requested language; instead of returning the default (English) version, it allows you to define your own hierarchy of locales.

By default, French (Canada) will first use French before falling back to English. Similarly, missing labels in Brazilian Portuguese will first try to return Portuguese labels before the English ones. This feature also accommodates completely custom fallbacks.

The same goes for the underlying Flow Framework and the Neos CMS. This is only a front end thing though. On the back end, a user can only configure one language. If there’s no translation in that language, it will fall back to the site’s default and eventually to English.

TYPO3 Back end Language

TYPO3 Back end Language Setting

WordPress.com

On WordPress.com there’s a user interface language selection in the account settings. One cannot select multiple preferred languages though, but only one.

WordPress.com User Interface Language

WordPress.com User Interface Language Setting

Facebook

Facebook only has a really simple language settings. Although a user can select multiple languages they understand for use in the News Feed, they can only choose one specific locale for the overall UI.The locales that Facebook supports are referenced in the Facebook Locales XML file. That file includes multiple variants for various languages, but only one variant for others. For example, there’s only de_DE, but no de_CH. Plus, you can’t choose between formal and informal variants.

Facebook User Language Setting

Facebook User Language Setting

Summary

We’ve now covered a bunch of well-known web platforms and content management systems to see how they are handling this problem. Various techniques exist to assist with finding the right translation. Sometimes they are automated, but most of the time the choice is left up to the individual user.

This research should help with the next steps of the Preferred Languages project as these observations need to be adapted for WordPress so that we can learn from them. Feel free to leave any comments about this research in the comments. After that, I try to schedule a new meeting in December where the next steps can be discussed.

#feature-projects, #i18n, #preferred-languages

User Admin Languages and Locale Switching in 4.7

In WordPress 4.7 users will be able to select their preferred locale (language) when editing their profile. 🎉🎉 This allows for greater personalization of the WordPress admin and therefore a better user experience.

The back end will be displayed in the user’s individual locale while the locale used on the front end equals the one set for the whole site. If the user didn’t specify a locale, the site’s locale will be used as a fallback. The new locale property of the WP_User class can be used to retrieve the user’s locale setting.

The new user language option when editing the profile

The new user language option

To enable sending emails in the language of the recipient and not the current user’s language, an API has been introduced to switch locales and translations at any point during the page load.

Here are some of the new API functions with usage examples.

get_user_locale( $user_id )

This function is used to retrieve the locale of any user. When no user ID is set it uses the current user. The user locale should be used for any user-facing screens in the admin.

The user locale is stored as a user meta locale. Therefore it can be modified with the get_{$meta_type}_metadata filter.
If the meta field is empty the value of get_locale() is returned.

switch_to_locale( $locale )

switch_to_locale() switches the locale and (un)loads text domains according to a given locale. This includes the global $wp_locale object as well. It can be used together with get_locale() or get_user_locale(). Core’s main purpose of this function is to be able to send emails like password/email change notifications in the recipient’s language. Admin emails, emails for  get_option( 'admin_email' ), are using get_locale(), the site language.

When switching a locale several actions are fired which allows one to perform further actions:

  • change_locale: Fires when a locale is switched or restored. Core uses it to re-init post types and taxonomies.
  • switch_locale: Fires when a locale is switched.
  • restore_previous_locale: Fires when a locale is restored to the previous one.

restore_previous_locale() and restore_current_locale()

restore_previous_locale() can be used to restore the previous locale. Example:

$locale_switched = switch_to_locale( get_user_locale() );

// Do something.

if ( $locale_switched ) {
    restore_previous_locale();
}

Use restore_current_locale() if you want to empty the current stack and restore the original locale.

is_locale_switched()

As the name implies, it checks whether switch_to_locale() is in effect.

WP_Locale_Switcher

switch_to_locale(), restore_previous_locale(), restore_current_locale(), and is_locale_switched() are wrapping the same named methods of a new WP_Locale_Switcher class. This class is responsible for holding a stack of locales and filtering the actual locale through the locale filter.

Note about admin-ajax.php

As admin-ajax.php is in the admin, anyone getting translated strings via Ajax will get strings in the user’s locale when they are logged in. You can use switch_to_locale( get_locale() ) to ensure the string is returned in the site’s locale, rather then the user’s locale. Or, ideally, leverage the REST API. 💪🏼

For background information on these changes see #29783, #26511, and #38485.

Related dev note: Changed loading order for current user in 4.7.

#4-7, #dev-notes, #i18n

New Post Type Labels in 4.7

In WordPress 4.7, two additional labels have been made available for custom post types. These get passed in via the labels argument when using register_post_type(). The following labels are new:

  • view_items – The post type archive label used in the toolbar on the edit screen. Default “View Posts” / “View Pages”. See #34113.
  • attributes – The label used for the title of the post attributes meta box (used to select post type templates). Default “Post Attributes”/ “Page Attributes”. See #18375.

 

#4-7, #dev-notes, #i18n

Preferred Languages Chat Summary: October 26

After introducing the Preferred Languages project less than two weeks ago, we held our first meeting on Wednesday. This is a summary of the Preferred Languages chat from October 26. (Slack log)

Attendees: @casiepa, @chantalc, @petya, @swissspidy

Topics

After going through initial feedback on the introduction post, there was a short recap of ideas that have been suggested so far:

  • Have a translated setting of preferred languages, where the translators would define the locales they should “fall back” to in case there’s no translation available. E.g. de_CH states to prefer de_DE and de_DE_formal after that.
    • Pros: simple solution, no UI changes needed
    • Cons: very subjective, unclear how the expected translations would be installed
  • Rely on the Accept-Language header every browser sends, which is set based on the user’s system preferences.
    • Pros: no UI changes needed, it’s a reliable standard
    • Cons: no support for formal language variants, unclear how the expected translations would be installed
  • Extend the UI to allow setting multiple preferred languages
    • Pros: leaves the choice to the user, clear how to install the expected translations, could be used together with Accept-Language
    • Cons: makes the UI option more complex

Besides that, it was suggested to display a note to the user when there’s a missing translation to encourage them to translate WordPress. However, this can be worked on independently in #23348.

Before we get into details and possible solutions, more (non-technical) research needs to be done. We’re mostly interested in how other platforms and content management systems handle this. Think Wikipedia, Facebook, Drupal, Joomla, and so on. WordPress isn’t the only system facing this situation.

Research results can be shared in the comments to this post. Every help in that regard is highly appreciated! So far I’ve collected some information about Drupal and Joomla. After that, I’ll publish the results in a separate blog post.

The next meeting will be on Wednesday, 9 November 2016, 17:00 UTC in the #core-i18n Slack channel.

#feature-projects, #i18n, #preferred-languages, #summary

Preferred Languages

With the introduction of language packs two years ago ([29630]), it’s easier than ever for users to change the main language of their site. However, in some cases a single locale (i.e. the language variant, like Canadian French) is not enough.

Let’s say a site of mine is running German (Switzerland), which there is a language pack for. However, most plugins only have a German (Germany) translation, or perhaps only even a de_DE_formal translation. As a native German speaker, I’d prefer to read a German (Germany) translation instead of English, if a German (Switzerland) version did not exist. Instead of getting translations as I’d wish (as the translations are very similar), WordPress falls back to the original English strings. That’s a poor user experience for many non-English speakers. Now, since the addition of a user-specific language (#29783), this issue is even more important.

There’s been a long discussion about this issue in #28197, where possible solutions have been suggested without any consensus. Instead of directly talking about how this can be technically implemented, we should first explore the actual user experience problems and see what’s possible and how it might look.

For this, I began researching how other software approach this problem. Those of us interested in this problem can learn from existing solutions and proceed from there.

These screenshots should give you a better understanding of what I’m talking about:

As you can see, these software products create a “fallback chain” for the user’s preferred languages. In theory, I could also set my preferred languages to es_ES -> de_DE -> en_GB -> en_US, if that was the order in which I preferred translations.

To keep momentum and continue thinking through this problem, I want to kick off a feature project, about improving the experience for WordPress users who use the product in non-English languages, of which multiple locales may exist.

Get Involved

Your feedback is incredibly important to ensuring we get this right. Leave any thoughts in the comments below. Would you like to help out? Awesome. Let’s have an initial chat on Wednesday, 26 October 2016, 17:00 UTC in the #core-i18n Slack channel and go from there.

I’ve set up a GitHub repository that can be used as a playground for discussions, prototypes, and eventually a working solution. For this, design and accessibility feedback would be very helpful. I’m confident that we can build something that we can propose for inclusion in a future WordPress release!

#feature-projects, #i18n, #preferred-languages

JavaScript Internationalization

Prequel

Over the last few releases, WordPress has made huge steps in prioritizing internationalization and localization throughout around core. To name a few highlights: language packs for core, language packs for plugins and themes, a language chooser, just-in-time loading for translations, and a user-specific language setting. But core isn’t the only place improvements have been made.

translate.wordpress.org is the platform for making WordPress available in as many languages as possible. Did you know that WordPress 4.6 is currently translated into 72 – s e v e n t y t w o – languages? Recently the number of unique translators passed the 10k mark. 🌎🌍🌏

The platform is powered by GlotPress, a collaborative, web-based software translation tool.

Internationalization is not a feature, it fixes a usability issue for many users whose primary language is not English. And that’s about 47% of our users.

The next big thing

As of today, WordPress doesn’t support a proper internationalization API in JavaScript. There are two, 4-year old tickets, #22229 and #20491, which request such an API. (The former one was closed as a duplicate of #20491 since an internationalization API in JavaScript should provide support for plurals by default.)

And that’s what this post is about: JavaScript Internationalization.

@swissspidy and I (@ocean90) have been thinking about and working on this topic, and now is the time to gather feedback on the direction and get help from everyone interested.

As you may have noticed in the prequel, internationalization spans more than WordPress core. We’ve split the task into four areas: Core, GlotPress, wp-i18n-tools, and language packs.

Jed and wp.i18n (Core)

Since we didn’t want to reinvent any wheels, our proposal is to use Jed as the base library. Jed provides “Gettext Style i18n for Modern JavaScript Apps”.

wp.i18n will be a wrapper for Jed and should be used by WordPress and plugins/themes. One of the biggest benefits of leveraging Jed is that the actual implementation is very similar to the one we already have for PHP code. The latest patch currently introduces these API functions:

  • wp.i18n.getLocale()
  • wp.i18n.loadLocaleData( data )
  • wp.i18n.addTranslations( domain, data )
  • wp.i18n.__( text, domain )
  • wp.i18n._x( text, context, domain )
  • wp.i18n._n( single, plural, number, domain )
  • wp.i18n._nx( single, plural, number, context, domain )
  • wp.i18n.esc_attr__( text, domain )
  • wp.i18n.esc_html__( text, domain )
  • wp.i18n.esc_attr_x( text, context, domain )
  • wp.i18n.esc_html_x( text, context, domain )
  • wp.i18n.numberFormat( number, decimals )
To do
  • Rethink WP_Scripts::load_translation_file() and get_js_i18n_data(), add tests.
  • Get feedback on the proposed API. (That’s this post!)
  • Apply the new API in our JS files.
    • There’s a POC patch that can be worked upon.
    • Do not forget: Underscore templates.
  • Include date of json files in update requests for language packs.
    • See wp_get_installed_translations().
    • See wp_get_json_file_data(), maybe json_decode() might be enough for this case.
    • What’s the format for meta data? See this GitHub issue for discussion.
  • sprintf() in JavaScript – useful for core?

GlotPress (translate.wordpress.org)

Jed supports JSON for translation files. GlotPress currently doesn’t support exporting translations in a JSON format. But there is a pull request which adds the required functionality to GlotPress. The format is going to support “simple” JSON (key -> value) and a Jed 1.x compatible format. The latter will be used by wp.i18n.

To do
  • Get the PR merged. Done. 🎉
  • Find a solution for the missing meta data, see the GitHub issue mentioned before.
  • To enable exports like “get all translations for file common.js”, the current filter system in GlotPress needs to be improved to support search only in file references and search for multiple file references.

wp-i18n-tools (Meta)

A script named MakePOT parses PHP files to extract the original strings and their file references. This script needs to be extended to also parse JavaScript files. A POC has been created.

To do
  • Convert the POC into nice code with tests.
  • Fix #20881 because it’s important for the GlotPress export that all file references remain.

Language Packs (Meta)

Currently a language pack includes a .po and a .mo file. Support needs to be added so that a .json file gets bundled if a project has translations for JavaScript files.

To do
  • Export Jed files when JS translations exist.
  • Include JSON file in language packs.
  • Update API to support version checks for JSON files.

Feedback

Thanks for reading, now it’s your turn. 🙂 Do you have any feedback? Are there things we should do differently? Do you have resources to help us? Please let us know in the comments!

There are currently no meetings scheduled but we’re happy to discuss any topics in #core-i18n. Just say “Hi”!

#i18n, #javascript

I18N Improvements in 4.6

WordPress 4.6 significantly improves the way translations are loaded for plugins and themes which are hosted in the WordPress Plugin and Theme Directory and using language packs via WordPress.org’s translation platform.

Loading Translations in Different Order

Functions like load_plugin_textdomain( $domain ) and load_theme_textdomain( $domain ) are used to load the translations for a specific text domain, where $domain equals the slug of your plugin or theme.

Up until now, these functions first looked inside the plugin/theme folder for available translations before checking the wp-content/languages directory, where language packs reside. With WordPress 4.6, this order has been reversed.
The translation platform for plugins/themes was opened up in December last year. Since then 15,000 plugins and themes were imported and are now benefiting from automated translation updates. That’s why translation files are most likely to be located wp-content/languages directory, hence this change. See [37414] / #34213.

Just-in-time Loading for Translations

By far the biggest change is that you do not have to call load_plugin_textdomain() or load_theme_textdomain() anymore with WordPress 4.6. Of course the same goes for load_muplugin_textdomain().

Again, since translations files are usually inside wp-content/languages, WordPress now scans that directory for available translations and automatically loads them if it encounters a text domain for the first time. That’s handled by the new _load_textdomain_just_in_time() function which gets called in get_translations_for_domain(). See [37415] / #34114.

This so-called just-in-time loading of text domains works really great and removes one more step for developers to worry about. If you do not want this to happen, however, you can still use the override_load_textdomain filter to load your text domains manually.

Also, if you use unload_textdomain() you will have to manually load translations afterwards if you want to use them again because it keeps a record of unloaded text domains.

Localized jQuery UI datepicker

https://make.wordpress.org/core/2016/07/06/jquery-ui-datepicker-localization-in-4-6/

Other Changes

  • Support for comment number declension in get_comments_number_text(). See #13651.
  • Fallback for TextDomain header field in get_plugin_data(). See #36706.
  • Updated list of continents and cities for the timezone selector. See #37554.
  • Support for the German (Switzerland) locale in remove_accents(). See #37076.
  • Improved support for month name declension. See #36790.

 

#4-6, #dev-notes, #i18n

jQuery UI datepicker localization in 4.6

In WordPress 4.6 (#29420) localization defaults were added for the jQuery UI datepicker based on the current locale using the new wp_add_inline_script() function. With 4.6 you can enqueue the datepicker and you are set. It works out of the box.

Instead of using the language files from the jQuery UI project the necessary information, mainly from the WP_Locale class, is directly passed to the datepicker. The list of localized information: closeText, currentText, monthNames, monthNamesShort, nextText, prevText, dayNames, dayNamesShort, dayNamesMin, dateFormat, firstDay, and isRTL.

If you are using the files from jQuery UI in your theme or plugin, please be aware of this change. With 4.6 you can omit calling these files and enqueue the default datepicker which will use the built-in defaults from WordPress.

If you want to change the defaults or add custom settings, you can still use all the arguments from the datepicker. WordPress only sets sane defaults for the chosen locale. But you should check if jQuery UI datepicker is enqueued and you should check if the browser is showing a native datepicker (like Chrome).

@ipstenu has scanned the plugin repo for plugins including the jQuery UI files. The following plugins can be changed to use WordPress’ own translations.

Advanced Booking Calendar, Albo Pretorio On line, Altos Toolbar, AWPCP – Classifieds Plugin, Appointment Calendar, Banner Garden Plugin for WordPress, BBS e-Popup, Beaverlodge Maintenance, Beaverlodge Menu Styler, BigContact Contact Page, Blog Post Calendar Widget, Booking Calendar Contact Form, Events Calendar, Class Booking, Contact Form 7 IE DatePicker and Number Spinner Fix, Custom fields, Datepicker i18n, Easy Calendar, EEXCESS, Event Post Type, Events Made Easy, Events Manager, Social Marketing Scheduler, FormCraft – Form Builder, Date Picker in List Fields for Gravity Forms, Gravity Forms (Spanish), Gravity Forms (nl), inquiry form creator, Jet Event System for BuddyPress, JQuery Accessible Accordion, JQuery Accessible Autocomplete, JQuery Accessible Button, JQuery Accessible Carousel, JQuery Accessible Checkbox, JQuery Accessible Datepicker, JQuery Accessible Dialog, JQuery Accessible Menu, JQuery Accessible Progressbar, JQuery Accessible Slider, JQuery Accessible Tabs, JQuery Accessible Tooltip, JQuery Accessible Tree, Js-appointment, LearnPress – WordPress LMS Plugin, LePress, List Urls, Livemesh SiteOrigin Widgets, Lodgix.com Vacation Rental Listing, Management & Booking Plugin, MailChimp List Subscribe Form, Social Media Share Buttons | MashShare, Member Register, Membership 2, Meta Collections, mind-body, Tribulant Newsletters, Orbis, Order Delivery Date for WooCommerce, OpenWebAnalytics, Pay2Post, PDF Catalog, Pronamic Events, RPB Calendar, Vinum Master Tracking Plugin, Simple Ads Manager, Simple Photos Contest, Sk Multi Tag, Solidres – Hotel booking plugin for WordPress, Cubilis Fastbooker, Surbma – Datepicker localization for Gravity Forms, teachPress, TemplatesNext ToolKit, TheNextTable, Toolset Types, Uiform – Cost Estimation & Payment Form Builder, Uiform – Form Builder, Vacation Rentals, Video Central for WordPress, Visual Form Builder, Webagency Widget – Website builder, WEeventscalendar, WooCommerce Checkout Manager, WooCommerce Quick Donation, WP Agenda, WP-AMD – Global JS and CSS handling, WP Any Form, WP Contact Slider, wp-creator-calculator, WP-CRM – Customer Relations Management for WordPress, WP FEvents Book, wp-greet, WP-Invoice – Web Invoice and Billing, WP Maintenance, WP Online Store, WP-Property – WordPress Powered Real Estate and Property Management, Wp-Recall, WP Scripts Updater, WP Swiper, wpShopGermany Free, and XO Event Calendar.

#4-6, #dev-notes, #external-libraries, #i18n

I18N Kickoff for 4.6 Chat Summary

This is a summary of the I18N Kickoff chat from April 21st.

Attendees: @petya, @SergeyBiryukov, @swissspidy, @ocean90

JavaScript i18n

User Admin Language

  • #32879 was closed as a duplicate of #26511.
  • Having a switch_to_locale() function is a precondition for #29783 and thus this feature is part of the 4.6 milestone.

Language Packs

  • To push language packs to the next level, #34213 (Change priority for loading theme/plugin translations) and #34114 (Remove the requirement to call load_plugin_textdomain() or load_theme_textdomain()) are part of the 4.6 milestone.
  • #34213 should go in early.
  • #34114 needs a refresh and the tests should make use of the WP_LANG_DIR constant.

Database Collation

  • No decision was made for #32405 because @pento wasn’t around.

Other Tasks

  • @swissspidy mentioned #18146 (Add user-level timezone setting) as an UX improvement similarly to #29783
    • @ocean90: “Have to read that ticket in detail but one of the biggest task is probably to define the line between user setting and site setting.”
  • @SergeyBiryukov volunteers to expand https://make.wordpress.org/core/handbook/best-practices/internationalization/
  • @SergeyBiryukov mentioned #13651 and that it should finally get fixed.
    • @ocean90 will review the latest patch.
  • @ocean90 mentioned that the i18n report has a lot of tickets by @ramiy related to “Avoid using HTML tags in translation strings*” which need to be reviewed. One of the reasons why it’s good to have the handbook page ready as soon as possible.
  • @ocean90 mentioned Ginger-MO https://github.com/dd32/ginger-mo, “a minimal .mo reader (with support for PHP & JSON representations), multiple text domains, and multiple loaded locales in the future” by @dd32.
    • @swissspidy asked what this would mean for #17268.
    • (after the chat) @dd32: “As for Ginger-MO, my main intention was so we *didn’t* have to use the native gettext tools. I built it with one aim – To get English (US) and non-English pageloads closer to eachother in terms of performance.”

Bug Scrub

It was decided that the first bug scrub for the i18n component is on Tuesday April 26th, 2016 at 18:00 UTC.

 

Full meeting logs: https://wordpress.slack.com/archives/core-i18n/p1461243825000006

#4-6, #i18n