Pascal Birchler 7:26 am on October 18, 2016
Tags: feature projects ( 49 ), i18n ( 33 ), preferred-languages ( 6 )

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 localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. (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) translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization., 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:

: Firefox

: Chrome

: macOS (overview)

: macOS (selection)

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 SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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

Chantal Coolsma 7:42 am on October 18, 2016

I will definitely help testing this when it is available for testing.
Pascal Casier 8:04 am on October 18, 2016

Count me in !
This is very useful for smaller teams e.g. fr_BE to be able to have fr_FR translations if the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme is not yet translated into fr_BE
But also for a ‘startup’ localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. like nl_BE where people could already switch from the beginning to nl_BE but still have nl_NL as backup language while nl_BE is started.
However please remember the final goal is that the plugin/theme gets translated into the main language of the site, so warnings/indications that it uses the backup language should be indicated somewhere and point to e.g. GlotPress where people could contribute.
- Pascal Birchler 8:31 am on October 18, 2016
  
  However please remember the final goal is that the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme gets translated into the main language of the site, so warnings/indications that it uses the backup language should be indicated somewhere and point to e.g. GlotPress where people could contribute.
  
  The user’s desire is to simply have a great experience with functioning translations. A warning doesn’t sound like a great experience, but we can try to pick this topic up during the chat. It sounds more like a case for #23348 / #33007 though.
Torsten Landsiedel 9:21 am on October 18, 2016

I think Bernhards PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is working for most uses cases here:
https://wordpress.org/plugins/language-fallback/

And if you need more, there is a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for doing a “fallback chain”.

I don’t know if it is needed to provide a UIUI User interface to configure a fallback chain (as seen in the screenshots) as I don’t think it is needed by the majority os users.

I really would like to see this in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and I’m happy to help with testing it.
pix365 9:48 am on October 18, 2016

I’d go for this be in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. – With the provision that it has ta UIUI User interface. Why? as i think this provides a simpler management work-flow that will suit none tech savvy users, without this UI, how would one change the preferred languages and their order? ( custom coding, I guess.)
Ryan McCue 9:56 am on October 18, 2016

Sounds great to me! Is there any sort of standard that lists sets of languages with fallbacks that could simplify the UIUI User interface here? (i.e. “de-ch should fallback to de-de”) Having the UI available still would be nice for the case where you know two unrelated languages, however, so I think the UI does make sense.
- Pascal Birchler 10:10 am on October 18, 2016
  
  I initially suggested something similar in the ticketticket Created for both bug reports and feature development on the bug tracker.:
  
  Why not create a new translatable string for a fallback chain. For example, in de_CH_formal we’d say we want to fall back to de_CH, de_DE_formal, de_DE — and of course to en_US in the end. This information could be translated on translate.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ by each localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English..
  
  Leaving such a decision to translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. maintainers or even pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers wasn’t perceived as a great idea back then, as it might not work under all circumstances. Using such a list to help simplify a UIUI User interface might be worth exploring though.
  - Bernhard Kau 11:27 am on October 18, 2016
    
    I liked the idea of a translatable string, as the translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. maintainers usually know best which fallback chain is best. Adding a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. would also enable a developer to change it.
- Mike Nelson 4:30 pm on October 18, 2016
  
  +1 to having coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. just have default fallbacks if possible. If that’s able to serve 90% of users, then I think its reasonable for the other 10% to use a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party which gives them a UIUI User interface for customizing the fallback behaviour
- Ze Fontainhas 7:51 pm on October 18, 2016
  
  Much as I completely understand the drive for “standard fallbacks”, I’m not sure I love the idea, as it very much sounds like an engineering solution to a problem that isn’t one, or at least one that can’t be tackled by an algorithm. My problem with the approach is that it tries to impose hierarchy (i.e. “this language/variant is more… something than this other language/variant”), when not only does such hiereachy exist in real life, but simply cannot exist. To give an example, it is perfectly reasonable to imagine that users of pt_PT (Portuguese, Portugal) would fallback to pt_BR (Portuguese, Brazil) and that users of pt_BR would fallback to pt_PT. In fact, we (pt_PT) do it quite often, as do they (pt_BR). Why would one of those two be more…something than the other?
  - Bernhard Kau 10:52 pm on October 18, 2016
    
    If we have a translatable string, each language pack could define it’s own fallback chain. So pt_PT could have pt_BR and pt_BR could have pt_PT.
    
    I agree that it’s not possible to have a perfect hierarchy, as this just doesn’t exists. But making it possible for the GTEGeneral Translation Editor General Translation Editor – One of the polyglots team leads in a geographic region https://make.wordpress.org/polyglots/teams/. Further information at https://make.wordpress.org/polyglots/handbook/glossary/#general-translation-editor. to define a standard and adding a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to enable (pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party) developers to change it, looks like a pretty good idea to me. And all is better than the current, non-existing, fallback to English.
    - Ze Fontainhas 10:58 pm on October 18, 2016
      
      Fine, but
      each language pack could define it’s own fallback chain.
      
      Let’s bring in another variant of pt_, say pt_AO (Angola, non-existant as of yet, but the case can be made with all the es_ variants). I, as a language pack adminadmin (and super admin), wouldn’t want to impose my vision (because it *is* a vision, and a subjective one at that) that the chain should be, say, PT, BR, AO. Why not PT, AO, BR?
      
      I think it’s for each user/site admin to determine that.
      - Bernhard Kau 11:03 pm on October 18, 2016
        
        Which they could do using the filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. or a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.
        
        Decisions, not options 😉
        
        I would bet any other software that has a fallback did make that decision.
      - Ze Fontainhas 11:20 pm on October 18, 2016
        
        Please, it’s not an option, it’s a decision. It’s just one that isn’t up to the language pack adminadmin (and super admin) to make.
  - Samuel Wood (Otto) 11:54 pm on October 18, 2016
    
    Ze, computers can’t make the decision for you. A hierarchy must exist so that the computer knows what to do. Therefore, somebody must make the decision.
    
    If there is no pt_pt, but there’s both pt_br and pt_ao available, which do you use? Some logic must exist to make that choice.
    
    Putting such a thing back on the user is avoiding the problem instead of solving it.
    - Ze Fontainhas 12:18 am on October 19, 2016
      
      > computers can’t make the decision for you
      
      Nor ought they, and that is precisely my point. For a user, the fact that a “language pack adminadmin (and super admin)” or “a computer” made that decision is the same: it is all “computer says x”.
      Some logic must exist to make that choice.
      
      Indeed it must. I’m saying is that that logic will inevitably be the site’s administrator’s, not someone else’s (me, the language pack admin.) I’m saying that it is not possible to guess that logic for every single site administrator (and sorry, no, filters and more plugins are most clearly *not* editorial tasks.)
      
      Look, I’m wasn’t being religious about this, sorry if it came across that way. I will of course embrace the consensus decision, as always. It’s just that making these kinds of (eminently editorial) calls in spite of the sites’ owners gives me an itch.
      - Samuel Wood (Otto) 1:24 am on October 19, 2016
        
        The site administrator is the “user” in my view. Sorry if that wasn’t clear.
        
        I’m cool with ways to override things, naturally. But a default should exist so that people don’t have to make that choice if it’s pretty standard for most cases.
Jonathan Bardo 12:55 pm on October 18, 2016

I like the idea of a chain of fallback that we would be able to reorder as the user see fit. I also don’t think there is a universal pattern here and we shouldn’t assume anything when it comes down to what is the best fallback for any geographic location.
Greg Ichneumon Brown 3:28 pm on October 18, 2016

Have you already looked at HTTP_ACCEPT_LANGUAGE? I don’t see it used anywhere in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Those FF and Chrome settings get converted to HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. headers which then define fallbacks. We use this on wp.com for trying to select the best language for a user during initial signup. PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me on .org SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. for example code if that helps.

I don’t know the extent to which users properly set multiple fallback languages though.
- Samuel Wood (Otto) 11:57 pm on October 18, 2016
  
  They often don’t, but I’d say that is a valid use case for choosing default languages to display in adminadmin (and super admin) on a per user basis, if such a thing happens. But maybe not the best choice for deciding fallback to other language variants.
John Blackbourn 4:29 pm on October 18, 2016

As Greg mentioned, the browser language settings get sent with each request via the HTTP_ACCEPT_LANGUAGE headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. It would be very worthwhile researching whether these settings could be used either as a seed for the user’s settings in WordPress, or whether it could be used as the actual language stack in place of a new UIUI User interface in WordPress, or as a fallback for when the user has yet to set their language stack in WordPress.
- Torsten Landsiedel 5:16 pm on October 18, 2016
  
  HTTP_ACCEPT_LANGUAGE doesn’t help with formal language variants, but for the other use cases this a good idea.
Patrick Robrecht 5:23 pm on October 18, 2016
+1 for language fallbacks in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. I don’t see any need for a fallback list UIUI User interface for the list as fallbacks seem be quite clear:
- For de_CH_informal the fallback list could be (in this order) de_DE (informal), de_CH_formal, de_DE_formal
- For de_DE_formal the fallback list could be de_CH (formal), de_DE (informal), de_CH (informal)
i. e. choosing other locales of the same language, but for languages with formal and informal versions consider about the formal/informal variant if available.

As @casiepa I think that it’s important to show administrators if a fallback is used such that I’m informed if the de_DE is used instead of de_DE_formal as a company having set the German “Sie” as language might not want to use the “du” variant as fallback. If they get notified, then can check whether this is relevant for the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party they use or simply contribute the missing translations.

+1 for showing a hint “X isn’t available in your language yet. Translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. is at y % – you can contribute translations at “. X could be WordPress itself or any plugin or theme.
Dirk Weise 6:10 pm on October 18, 2016

I’d rather see my native language in my blogblog (versus network, site)’s backend when I log in from a Chinese internet café to update my page with my latest impressions instead of having to guess what I’m doing. I think this headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. is more useful for displaying a fitting front end language to a visitor than choosing an administration page language.
Knut Sparhell 3:54 am on October 19, 2016

Both language preference and most of the fallback question was solved over 20 years ago and communicated over HTTP_ACCEPT_LANGUAGE. If user language option is not set, and the preferred language in HTTP_ACCEPT_LANGUAGE is installed, use that, top down.
Dominik Schilling (ocean90) 11:04 am on October 19, 2016
Some resources which may help in the process:
Juniper 7:24 pm on October 20, 2016

Great brainstorming on an excellent idea! Configurable language-variant stacks.

The data themselves could be stored as a simple string ‘aa_ee, aa_bb, cc_gg’ on three levels: WordPress defaults set in code or database, site defaults defined in wp_config or set in wp_options, and user defaults in usermeta; then concatenated to prefer user stack then site stack then wp stack.

The add/remove/order UIUI User interface could make it easy to select a language family (a cluster of related language-variants) at one go and then order & remove individual variants within it.

Like it or not, we can’t avoid setting fundamental defaults for the underlying code to guide fallbacks in case none of the requested variants are available, even if doing so might feel like linguistic bias. If a stack consists of ‘de_ch_formal, de_ch’ but no Swiss German variant is available, I’d hope the software would be clever enough to default to any DE on hand before it defaulted to EN. But if EN is not the underlying default, what will be? Since we can’t avoid that ultimate bias, I figure we might as well create a variety of biases from which to choose; in selecting a language-specific version of WordPress to install or download, one implicitly selects a set of language stack defaults that is biased toward, variously, English or Chinese or Portuguese, etc.

Pascal – “improving the experience for WordPress users who use the product in non-English languages, of which multiple locales may exist.” I would prefer, “who use the product in languages for which multiple locales exist.” Prithee don’t omit English from consideration of significant localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. variants. Even if the variations are more often orthographic (spelling) rather than lexical (word choice), the differences do matter.

Perhaps this goes without saying, but I easily see the same mechanism catering to both back-end and front-end users. While a language-selection UI may become part of the standard back-end adminadmin (and super admin) settings it also could and arguably should have (perhaps as a bundled pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party) a stylable, configurable widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. to be used by website visitors to set their language preference in the front end. In such a widget, storing its data in a cookie if the user isn’t logged on, the default presentation could simply be a single-selection menu of available language groups and/or variants as pre-selected by the site admin without any of the back-end’s stack-editing complexity.

Comments are closed.

Welcome!

Communication

Preferred Languages

Get Involved

Welcome!

Communication

Get Involved

Share this: