I have been looking into the Drupal localisation files, and I noticed (well it seems to me) that most localisation is done on an individual component basis (component being a module, theme, etc)
What I would like to suggest is that a localisation pack could support a general settings file (note the "COULD" -- it would be up for the loclaisation authors) that would add some general localisation settings, which could be in an XML file. Some general settings could include:
* Language orientation (left-to-right or right-to-left)
* Default date format (DD/M/YY, YYYY.MM.DD, MM-DD-YY, etc)
* Default time format (HH:MM:SS, H:MM:SS am/pm, etc)
* Currency symbol
* Days of the week localisation
* Months of the year localisation
* Decimal separator (period or comma, etc)
* Measurement system (metric, imperial, etc)
* Temperature system (celcius, ferenheint, etc)
* Localised names of the language (i.e.: how is the language called in other languages besides English)
My view is that these general settings would give Drupal a further boost in its multi-language system. For example:
* A weather module could show the default temperature in Celcius or Farenheint depending on the defaults of the current language.
* Numbers would also show the correct decimal separator and digit grouping (e.g.: 1,000,00 or 1.000,00)
* Ensure that date and times are shown consistently around the Drupal portal, following the default taxonomy and nomenclature
Finally I also suggest that language pack creators could add their custom flag.PNG file on their language pack, which could be used in a graphical language selection menu. I think that localisation flags should really be up to the authors. For example, a Latin American language pack could use a Mexian Flag, or an Argentinean Flag... Is really up to the authors, isn't it?
Active
11.0 🔥
language system
It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.
It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.