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

[WordPress Trac]

#28197: Fallback Languages
---------------------------+------------------------------
 Reporter:  downstairsdev  |       Owner:
     Type:  enhancement    |      Status:  reopened
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  I18N           |     Version:  4.0
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:
---------------------------+------------------------------

Comment (by cvedovini):

 Replying to [comment:47 Kau-Boy]:
 > But how would a static fallback to a "generic" locale such as "es_ES" or
 "de_DE" be better than a translatable string?

 Not a static "es_ES" but "es" which is the naming convention for the
 locale-independent language file for Spanish (mydomain_es.pot)

 > I don't think, that the translation teams would have to fight out a
 political warfare.

 It's been said before, not by me, and I can totally see it. What do you
 think will happen if the decision is officially made by the Wordpress.org
 entity that zh_CN should fallback to zh_TW (which is the logical choice
 from a language perspective since mainland Chinese can read traditional
 characters but Taiwanese cannot read simplified ones)

 My solution doesn't require anybody in core to take that decision if they
 don't want to (there's no managing a central piece of data giving a
 fallback chain)

 > If any user from a language variant want's to change the fallback for
 all plugins and themes, he can easily change the translation of this one
 string.

 It wouldn't work better than my solution because plugins and themes who
 don't provide all variants are only providing one or two, the chance that
 any set of plugins and themes would all provide one particular locale to
 fallback to is the same as the chance they would provide the actually
 locale you want (which is slim). Plus, such a mechanism can still be
 achieved with a plugin and you could recycle yours ;)

 Now, if plugin and themes want to provide a locale-independent translation
 for Spanish (I use Spanish because there's a lot of locales) they can do
 so by providing an "es" file.

 Same for the core translators. If they decide that for certain languages
 they deem non-politically dangerous (for example French) to provide a
 locale-independent they can do it by providing a new file (or renaming an
 old one). It works too is they start to cover a new language but do not
 want to bother covering locales for that language.


 > If we would have a function with some generic fallback as in your
 example code, we must have a filter to allow users to alter the fallback
 anyways. But a translatable string is more flexible, as it easily provides
 a way to have a "fallback chain" and we don't have to add all those
 fallbacks statically into some core files.

 like I said just above, your plugin could provide that mechanism and it
 makes sense in that case that it's out of core.

 > For me as a plugin developer, I don't want to deal with those things
 myself. If I prepare it correctly, anyone can translate it on
 translate.wordpress.org into their own language.

 Am afraid that if users who don't see the specific locale they want were
 concerned enough to actually translate our plugins we wouldn't have that
 discussion.

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