Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hello,
I was looking in the RFC 4646 in term of letter case for language-code.
Instead of defining language-code in all lowercase, it should use uppercase for the region part.
Example zh-hans => zh-Hans.
So I start talking in this issue : http://drupal.org/node/1231402#comment-7172196
The idea is to stay consistent, in most of the other third-part they follow the recommendation, so when we want to integrate something, we are not consistent, I think is a best practice to follow those recommendation.
Thanks
Comments
Comment #1
Gábor HojtsyHow do you imagine such a change happening? Would you take existing data in Drupal releases and update with old language codes to new language codes? How do you tell what uses language? Once you change the main language code value, relation of those to other data elements would break. So we would need to update all data, which we cannot really tell given whatever module can reference the core Drupal data including contributed and custom modules on sites.
Are you proposing to only change for new sites, not for existing sites? How do you imagine to do that?
Also we currently use language codes in Drupal releases in several versions as well as localize.drupal.org group setup and file export names. The language codes are syncronized, so zh-hans on localize.drupal.org feeds zh-hans on a Drupal website. If we change it on the Drupal side, the translation exports will not feed into Drupal clients proper anymore.
Since you keep referring to RFC 4646, just pointing out again that it has long been obsoleted by BCP 47 (http://www.w3.org/International/articles/language-tags/).
(Emphasis from me).
Finally, Drupal core changes by policy happen first in the latest version and backported. So also not sure how to make these changes across 3 major Drupal versions relatively at the same time (or build compatibility layers into all of them).
Comment #2
sir_squall CreditAttribution: sir_squall commentedHello Gábor Hojtsy,
If you take time to look they use all this convention:
PHP
Wordpress
Symfony
Java
Etc...
In the BCP 47 : On the other hand, you may be using language tags in a context where letter-case is important, such as file names on some systems. In such cases, you should ensure that you follow a consistent policy for letter-case; for any new system that is not case-insensitive, it is recommended that you follow the BCP 47 conventions
I don't say it's an easy task to do. That's why I open the issue, to talk and find what is the best way to implement such change. As the moment, I don't have any solution to resolve this issue.
Comment #3
Gábor HojtsyGiven the quote above from BCP 47 (especially with the complexity explained with the intertwined systems) I'm not planning to work on this issue. However, most multilingual issues were not solved by me in Drupal 8, so that is no stop sign for people interested to solve the problem.
Comment #4
xmacinfoPlease note that the vast majority of languages (2-letter lowercase code) for Drupal are for the international version of the language, not the localized ones.
Language “en” alone is not USA-based, Canadian-based or UK-based for that matter. Same thing for the “fr” language on Drupal. We do not have any localized language yet, unless a few exists on http://localize.drupal.org/.
To officially go from 2-letter code to 4-letter code, we would need to fix all the available translation to:
Comment #17
skyredwangJust to provide another reference:
BCP 47: 2.1.1. Formatting of Language Tags