New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
226: support locale variants #747
Conversation
6575e41
to
a5d3de8
Compare
locales/locales.php
Outdated
@@ -972,6 +1010,8 @@ public function __construct() { | |||
$gsw->country_code = 'ch'; | |||
$gsw->wp_locale = 'gsw'; | |||
$gsw->slug = 'gsw'; | |||
$gsw->variant_root = $de->slug; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
… while de_DE_formal is missing and should be added to the list of variants for German
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
fdaafa1
to
5ea50d0
Compare
As per the discussion here: #747 (comment)
83da488
to
2e25365
Compare
As per the discussion here: #747 (comment)
8d79097
to
c400170
Compare
21f5d61
to
feeb2ae
Compare
As per the discussion here: #747 (comment)
0b9c55d
to
53836f0
Compare
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. |
1824c06
to
c0d9348
Compare
As per the discussion here: #747 (comment)
dbedf1b
to
6eb21fb
Compare
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. |
c728f45
to
304745d
Compare
77f9188
to
9446ca5
Compare
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.
9446ca5
to
2c28a33
Compare
This can be used with the GP_LOCALES_PATH define to effectively disable variants.
Resolves #226 .