[wp-trac] [WordPress Trac] #28197: Fallback Languages

[WordPress Trac]

#28197: Fallback Languages
---------------------------+----------------------------------------------
 Reporter:  downstairsdev  |       Owner:
     Type:  enhancement    |      Status:  reopened
 Priority:  normal         |   Milestone:  Future Release
Component:  I18N           |     Version:  4.0
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  accessibility, rtl, performance
---------------------------+----------------------------------------------
Changes (by kwadronaut):

 * focuses:   => accessibility, rtl, performance


Comment:

 And they all fall back to 'und'(efined)… @cvedovini is on the right track
 with fallback to 'generic.' What's used in the
 [http://www.unicode.org/reports/tr35/#LanguageMatching cldr] are a
 distance between 2 pairs and a likelihood to calculate how good another
 match would be.
 [https://github.com/golang/text/blob/master/language/match.go#L338 Go]
 takes a similar but simpler approach. It would avoid many frustrated users
 (my lang_reg_script isn't supported! Stupid imperialists!) and developers
 (what's this es-419? Do I also need an es_mx? What language symbol do they
 have there and there for their local currency?).

 It must not be achieved by a separate file for each and every localization
 combination, a combo like: site in es_ec, plugin in es_mx, theme in es_ar
 could work fine and shouldn't display a single English word. Fallback
 means for me to be able to set preferences (nl_be, de_au, he, sr_latin,
 mo…) and that when there's a close enough match, to display that string
 (to continue the example, if a string isn't translated exactly check if it
 exists in: nl_nl, de_formal, de_informal, de_ch, il, hr, ro…).

 That gives peace to:
 * developers:
   - no need to continue es_ar if next time someone helps whose native
 tongue is es_mx, they translate only the new missing strings to es_mx and
 the fallback to es-419 makes most people believe it's well translated
   - no need to decide for a Galician website to fallback to Castillian or
 Portuguese (Iberia), the user will have set their preference
   - no need to copy paste 5 different files and claim you support 6
 different German variants, with only formal and informal both the Swiss,
 Austrian and German users will enjoy your localized plugin!
   - focus on the engineering and designing, no fiddling with the sorting
 of Ä in Danish or understanding which scripts are used where for
 Azerbaijani.

 * users:
   - in a great spot to know their content and (targeted) audience, see
 above
   - prefer Lingala and forgot to say that you prefer a plugin from a
 Belgian developer in fr_BE to the en version? No worries, we got your
 back.
   - I detest the dialect those people from across the river speak. Never
 ever fallback, give me the old behavior. Also the imperial approach of 1
 language is faster ;-)

 * Translators want their work used and appreciated. Users might prefer
 nl_be, but when a translation isn't updated for a new release, or some
 strings are missing, the translation will not get used and the translator
 will receive blame instead of praise. With fallback there's no blame. More
 time for quality control.

 Things that make sense to me:
 * stick to BCP-47 (aka convince @cvedovini I'm not crazy and accept en as
 English)
 * Use CLDR: http://www.unicode.org/reports/tr35/#LanguageMatching it
 already has a ton of good data for currencies, cities, and
 localeMatcherTestfiles.
 * Go's language matching:
 https://godoc.org/golang.org/x/text/language#Matcher
 * how people pick their preferences is something that can be changed or
 ameliorated later on, a simple config file change can be a great start.
 * those aiming for perfect localization can continue adding more and more
 specific files. Don't hold yourself back.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28197#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform