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.Date localization function started in Drupal 7 is a big step forward. One can create new date types, date formats and can assign a date format to every date type in every language. However the process is not too user friendly and can be pretty much tedious and long when you have several languages.
So there are possibilities to improve this function. I try to describe some ideas.
1. The most comfortable thing would be that, if one could download localized date formats as part of the Drupal core localization. Drupal has default date formats for English, why couldn't we have defaults for other languages too? This way localization teams, who know it best, could set the right format. The site builder should not digg for the information and should not know php date format characters.
2. I think it is useful to have the choice of custom date types and formats. Now, in D7 we have separate tabs for types, formats and localization. I think it would be much more user friendly to have the choice to assign a new format to a type of a language in the same place. The process would be something like:
a) create a new date format (there should be more common way than php date characters – see for example #169187: Easier date-time format setting –, or at least there should be a built in help...:o))
b) choose the language(s) where the new date format should be used (autocomplete field or language list)
c) choose the date type
This way one don't have to search again for the format she've just created (and maybe is almost the same like 10 other formats – see #989894: Too many "Localize date formats" options and #279570: Make date format choices less ambiguous). I let others now to draw the best GUI... :o)
These are my two cents, suggestions and notices are welcome.
Parent issue
#1260690: META: Improve multilingual user experience in Drupal 8
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | IKENZE-2013.5.24-16.50.png | 83.52 KB | pixelite |
| #6 | Screenshot_2_25_13_11_58_AM.png | 31.35 KB | Gábor Hojtsy |
| #5 | d7_date_formats.png | 21.47 KB | thamas |
| #5 | d8_date_formats.png | 33.35 KB | thamas |
| #5 | d8_edit_date_format.png | 32.73 KB | thamas |
Comments
Comment #1
Gábor HojtsyGood topic! I agree this needs a long hard look in itself and I totally agree it is confusing and overcomplicated. Weaving into the D8MI issue tree.
Comment #2
jherencia CreditAttribution: jherencia commentedSubscribe.
Comment #3
Gábor HojtsyAdd language-config tag.
Comment #4
YesCT CreditAttribution: YesCT commentedI'm not sure if #501428: Date and time field type in core has any impact on this.
Screenshots of the current ui might help spur someone to draw up a new suggestion for a ui.
This one sounds challenging to me.
Comment #5
thamasOk, here are some screenshots. Drupal 7 date formats page:
It seems there are massive improvements in D8. :) Types and formats are merged into one page, and when editing a format you can select localizations. (However it is not automatically displayed on the selected language, but maybe I'm missing something in configuration…)
Drupal 8 date formats page:
Drupal 8 date format edit page:
If we can make it obvious how to display different date formats in different languages, this issue may be closed. But maybe it's just a documentation problem from now…
Comment #6
Gábor Hojtsy"Localizations" is definitely not something that we use anywhere else in Drupal core. Something like "Used for languages" or "Languages to apply to" or something along those lines would be more in line with Drupal core's terminology.
Drupal 7 already provided language based date formats on a "Localize" tab. (Again that was out of line with core and even contrib terminology elsewhere):
There if you went to edit for a language, it let you assign different formats to the date types separately for each language. So you defined date types, then formats and then paired them up per language on a separate screen. That functionality is kept for Drupal 8 in a different way. Now you can define formats that belong to certain languages and then can have a different set of formats for different languages I guess.
I think it would be great to include the list of languages the format applies to in the table on top of fixing the terminology problem as mentioned above.
So I think there is definitely work to be done here. Drupal 8 works differently, but this is not necessarily all the way we should go in improving language specific date formats.
Comment #7
Gábor HojtsyAlso tagging for usability.
Comment #8
pixeliteMaybe we could add the language data to the date and time formats table. Like this:
I think adding the languages to the table would make it more obvious that editing a format would let you edit the languages it applies to.
Comment #9
Gábor Hojtsy@pixelite: YES! Is that a mockup somehow? :) Looks great. Also, we need to fix the actual language selector to not say "Localizations" (meh :D)
Also may be tangentially related: #2003802: Under Configuration => regional and language, merge Regional settings and date and time formats
Comment #10
Kristen PolI like the Languages in the table... would there ever be a bunch of languages though so it would become ugly/cumbersome?
As for the field label, "Languages to apply to" seems okay or why not just "Languages"?
Comment #11
Jose Reyero CreditAttribution: Jose Reyero commentedI think this should be better integrated with User interface translation.
Related issue #2052193: [META] Date format localisation is a huge mess, conflicts, does not work, regressed
Comment #11.0
Jose Reyero CreditAttribution: Jose Reyero commentedAdd parent
Comment #12
Gábor HojtsyDrupal 8 now has a translate tab on date formats which is also exposed as a translate operation in those dropdowns. Date formats are also pre-translated on localize.drupal.org now and they get a 'PHP date format' context. As of #2333987: Fix schema translation context terminology and add context for date_format configuration. So this is all resolved I believe.