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.There are multiple bugs reported about Drupal being unable to display date format depending on the site's locale. One of these reports evolved into a full fledged custom date format input widget (which is nice and does help those interested in custom date formats), but does not help those who have multiple languages set up, and are basically interested in language dependent date formats provided by their translation teams and Drupal.
Plone does a very similar thing for a few years now, so we might as well catch up :) The attached patch does the following:
- reorders the date format settings, so always the first in the select box is the default (previously two had the second as default)
- adds a new first option, which is language dependent (and now that is the default for all new Drupal sites)
- this format is translated with t(), so translators can provide language dependent date formats
New English only Drupal sites have the following impact: an strpos(), a trim(), an str_replace() and a t() call for all format_date() calls, if the default date formats are used. This small performance impact get us to a usability gain, so that if you enable locale module and import a language, you don't need to go into date format settings, as it is already language dependent by default.
If it is decided that English sites should not have this localized format set by default, then we can set this in the install profile if a localized install is used (in which case locale module gets enabled), and let people enabling locale later deal with setting the date format to language dependent themselfs.
Translators will have three new strings to translate with hints at the start to understand that these are date formats.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | localizable-dates.patch | 7.43 KB | kkaefer |
| localedate.patch | 4.69 KB | Gábor Hojtsy | |
Comments
Comment #1
Gábor HojtsyOh, the custom date formats discussion I referenced is here: http://drupal.org/node/105039
Comment #2
Dries CreditAttribution: Dries commentedNot sure. Wouldn't it be a more transparent (for the user) if the time/date settings moved to the 'edit language' page, and if they would have to set them explicitely? It seems to me that that kind of behavior would be a lot more predictable.
Comment #3
Gábor HojtsyI don't see what do you mean... I try to avoid requiring Drupal site admins to know the PHP date format string components and all the proper date formats for every language they set up on their site. How would having two concurrent places to set date formats help here?
Comment #4
kkaefer CreditAttribution: kkaefer commentedThis patch uses the same approach as Gábor’s, but cleans everything up a bit. I also added a feature to create custom date formats. If the user selects a date format provided by a translation, then deletes that translation, the previously selected date format is now displayed as “custom”.
Comment #5
Gábor Hojtsy@kkaefer: let's not duplicate efforts. I have linked the custom date format patch in, where Dries already expressed his willingness to commit that (it is much more mature than your version). Our goal here is not to provide custom date formats.
Also, there was a reason to put the t() as late as possible. With your version, only one date is saved for the whole site, provided for the locale used to first save the selection. Even with language support for variables, the user needs to go in and select the locale dependent variant for all languages set up. With my solution (t()-ing as late as possible, and saving the gettext msgid of the date format), once a translated date format is selected, every language will show the appropriate date format for that language.
It would be nice, if you could clear this up (which would also shorten your patch as far as it seems).
Comment #6
kkaefer CreditAttribution: kkaefer commentedI might disagree with the translator’s choice.
Comment #7
Gábor HojtsyIn which case you will be able to set custom date formats for every language with the new custom date formats feature in development.
(Or alternatively go into the locale string editing interface and edit the date format there, but it is more cumbersome, I would not suggest that to users).
Comment #8
Gábor HojtsyDries, you suggest we provide the date setting interface as part of the language dependent variables (site settings) interface? With our new concepts in development, that would indeed be possible. We would however need to allow Drupal translators to provide defaults for foreign languages, so users would not need to work with PHP date formatting strings. Anyway, good idea to fold it into the site setting translation editor interface. (We will be able to provide specialized form widgets there for values, so this will work there too).
Setting this to by design. This feature will come later with our site setting localization feature patch.