226: support locale variants #747
Conversation
| @@ -972,6 +1010,8 @@ public function __construct() { | |||
| $gsw->country_code = 'ch'; | |||
| $gsw->wp_locale = 'gsw'; | |||
| $gsw->slug = 'gsw'; | |||
| $gsw->variant_root = $de->slug; | |||
swissspidy
Jul 12, 2017
Member
Please note that while German (Switzerland) as a variant of standard German makes sense, Swiss German (gsw) is something completely different. It's a dialect (well, more than 26 different dialects to be precise) that has nothing in common with regular German. As such, $gsw shouldn't be a variant of $de.
Please note that while German (Switzerland) as a variant of standard German makes sense, Swiss German (gsw) is something completely different. It's a dialect (well, more than 26 different dialects to be precise) that has nothing in common with regular German. As such, $gsw shouldn't be a variant of $de.
pixelverbieger
Jul 12, 2017
•
… while de_DE_formal is missing and should be added to the list of variants for German
… while de_DE_formal is missing and should be added to the list of variants for German
swissspidy
Jul 12, 2017
Member
That would be handled somewhere else though 🙂 de_DE_formal is not listed in locales.php after all, it's probably just a WordPress.org thing.
That would be handled somewhere else though de_DE_formal is not listed in locales.php after all, it's probably just a WordPress.org thing.
toolstack
Jul 12, 2017
•
Author
Contributor
Thanks @swissspidy, I'll remove the relationship.
@pixelverbieger I'm sure there will be many new variants added, like de_DE_formal once the the PR is merged, currently swsisspidy is correct that the formal variants are handled by translate.w.org separately.
Thanks @swissspidy, I'll remove the relationship.
@pixelverbieger I'm sure there will be many new variants added, like de_DE_formal once the the PR is merged, currently swsisspidy is correct that the formal variants are handled by translate.w.org separately.
As per the discussion here: #747 (comment)
As per the discussion here: #747 (comment)
As per the discussion here: #747 (comment)
As per the discussion here: #747 (comment)
|
I’m not sure why the code invokes iso 629-2 codes. BCP 47 Tags should be used. I don’t have a problem with the fallbacks chosen. They make sense. But it seems that the coding seems more complex than needed. ISO 639-2 and 639-3 are alligned for the purposes of locale codes CLDR or Iana should have the already Approved codes. |
As per the discussion here: #747 (comment)
|
Any idea of progress on this PR? While discussing about the details could take forever (this language is/is-not a variant of another language), the functionality itself it's extremely useful for cases that are clear. For example, we now have *Valencian (ca-valencia, Catalan as spoken in Valencia), and falling back to English is simply not an option: there aren't enough translators to keep all themes/plugins up to date in both variants. |
|
It will be merged as part of 3.0, which is scheduled for a Dec 20th release. |
toolstack
force-pushed the
226-support-locale-variants
branch
2 times, most recently
from
c728f45
to
304745d
|
I guess ca-valencia will need to be added as a variant of ca in locales.php for this case to work, right? |
|
@xavivars Correct, it can be done for a site by either hooking in to the |
Also add a link back to the root translation in the detail view.
If someone is using the locale file outside of WordPress, the lack of apply_filters() would cause a fatal error.
And coding standard updates.
And coding standard updates.
This can be used with the GP_LOCALES_PATH define to effectively disable variants.
Resolves #226 .