Issue status update for http://drupal.org/node/11623 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: pancho Reported by: Goba Updated by: pancho Status: patch P.S. What the hell did I write about www.cvs.net? No, what I meant was of course www.drupal.org (here), where you can write a comment! pancho Previous comments: ------------------------------------------------------------------------ October 15, 2004 - 19:52 : Goba Attachment: http://drupal.org/files/issues/Drupal-translate-date-formats.patch (1.99 KB) Currently if I set a date format for the site, then it will be used with all interface translations. Different languages however have different needs when presenting dates. The Hungarian date format does not allow the day name to be the first and it calls for a dot between the hour and minute (yes, a dot not a colon). This means that Drupal ships with no suitable date format for Hungarians. Also none of the Hungarian date formats will be suitable on an English interface, while none of the English date formats are acceptable on a Hungarian interface on a bilingual site. The only option is to make date formats translateable. Since these are dynamic t() calls, extractor.php needs to be extended to include the date formats shipped with drupal in the pot output, so translators will get them (much like we do for some numbers and day names). I will take care of extending extractor.php, once this patch gets applied. ------------------------------------------------------------------------ October 15, 2004 - 20:00 : Goba Attachment: http://drupal.org/files/issues/Drupal-translate-date-formats_0.patch (1.99 KB) Well, the t() needs to be called on the date format set by the admin, so I needed to fix three t() calls. Updated patch attached. ------------------------------------------------------------------------ October 15, 2004 - 20:01 : killes@www.drop.org *g* I recall that there was a time when you didn't like this approach. Anyway, I fully endorse it and would like to see it in 4.5. There is also no suitable data format for German in core. And yes, that's a bug not a feature request. ------------------------------------------------------------------------ October 15, 2004 - 20:05 : Goba Yes, I didn't like it, because these are dynamic t()s. But since the selected format always needs to be presented in the actual language, it needs to be dynamic by nature. We have some of these dynamic t()s already, handled specially in extractor.php. ------------------------------------------------------------------------ October 16, 2004 - 00:07 : Steven I like this idea a lot, but I don't like the simplistic "wrap it all in t" feature. There are instances where format_date output is intended for script output. Changing those date formats would mean a bug in the code or UI (for example the way a node date is specified and parsed). Only those strings that are intended for user consumption should be translated. That's why I think we need a more specialized date handling component. It would deal with stuff like variations ('show hour/hide hour'), long/short variations (we need to review the usage of small/medium/long), as well as localizing them. We would need to revise the formats shipped with Drupal, but this gets tricky. For example would we only ship US-style AM/PM date formats with core? Should we only have M/D/Y ordering, or also D/M/Y ordering? If we move the time format settings to locale (where they do below, in principle) we might get a drop in usability: moving from a simple selection box, to requiring the whole localisation framework 'just to switch from 12 hours to 24 hours'. In some parts of the world, there is only one format for dates (e.g. chinese/japanese 2004年10月16日 1時00分). For them, the only variations are long vs short (whether to show the year, the time, etc), in other parts of the world all bets are off and people use what they like. This would mean that if we provide a default set of formats, and let them be translated through PO files, some languages might require more items than provided and some languages would have to use duplicates to fill all available options. On top of that, there is no guarantee that format #3 in French matches format #3 in German, so you'd need to be able to specify this per language. Ideally, we would let a language define any number of date formats, and let the user choose one of those per language. We could also provide a custom option where you enter your own date format, for the realy picky ones. The question remains: what do we do for sites without locale enabled? We can't go to requiring locale just to switch the date on a non-localized site. In that case, perhaps we could do this: - Have locale.module deal with date formats when it is enabled. Have a per-language format setting, selected from a language-specific, po-defined date format list. - Have system.module implement a 'localization' admin menu item if locale.module is /not/ enabled. This page carries the old selector, which acts like a simplified version of locale's format selector, with the list we current have in Drupal (i.e. variations of 24/12hours, d/m/y, y/m/d, m/d/y, ...). To prevent confusion, we add a link to system.module's version of the localization page, which instructs users to enable locale.module for full localization abilities). I know it sounds a bit weird (we certainly don't do this anywhere else), but it would be consistent in terms of UI (the date format is "localization" no matter how you look at it) and keep both non-localized site admins and localized site admins happy, without sacrificing too much ease of set up. ------------------------------------------------------------------------ October 16, 2004 - 10:34 : Goba Steven, you say: "/There are instances where format_date output is intended for script output. Changing those date formats would mean a bug in the code or UI/ " But the current approach is to translate the month and day names in every case, so format_date **already** assumes that the date it outputs is for human consumption and not for machines. So changing the order of the fields in user date formats should not hurt. Sure it might not be a useability dream, but it does not hurt. By the way, adjusting date formats based on user language is only a small piece of localisation not covered by Drupal core yet. I need to use one mission statement and site name in all languages, and even my primary and secondary links need to have the same text in all site languages, since they are not translateable. If we are about to find a generic solution for locale covered settings, we need to take these into account too. ------------------------------------------------------------------------ October 29, 2004 - 01:10 : Steven ""so format_date *already* assumes that the date it outputs is for human consumption and not for machines." " What I mean is changing the placement of the date components (day, month, year). For numerical dates which are parsed by a program, this will introduce bugs. I'd much rather have a cleaner date format selection method integrated with locale. ------------------------------------------------------------------------ October 29, 2004 - 14:19 : Goba Steven, the custom date formats are not translated, only those selected by the admin. And the admin can select date types with spelled out month/day names at any level, so they are not machine parsable anyway in the current Drupal version. **This patch does not introduce bugs.** I admit it does not look good, but there is no system for locale dependant admin settings yet. ------------------------------------------------------------------------ October 29, 2004 - 16:05 : Steven I'm saying we do need such a system. With your patch, the format that the admin selects in language A will not necessarily match the one in language B. We should go for locale-defined formats with a locale-neutral list to fallback on. ------------------------------------------------------------------------ March 13, 2005 - 15:55 : pancho Attachment: http://drupal.org/files/issues/dateformat.patch.zip (14.91 KB) ************************ DATEFORMAT-PATCH PACKAGE ************************ by pancho@suenderhauf.net 2005-03-13 03:07 This 'DateFormat' patch package only works with the latest CVS version of Drupal 4.60 RC. This 'DateFormat' patch package applies the following changes: 1. It introduces a more flexible system of standard date and time formats which helps both users and developers while staying backwards-compatible. We often see special date formats be used in modules, which is only second best, as these can neither be adapted by the user nor localized. More flexibility allows the developers to use the built-in format functions wherever possible. Changes in detail: - The standard date formats used to be combined date&time-formats. This is now split into separate date formats and time formats, to allow dates and times to be rendered in a more flexible way. - Still it's backward compatible: the combined formats - while deprecated - still exist. - A "Tiny" format is added to the "Small", "Medium" and "Large" formats. 2. It enables Drupal to show e.g. German and Hungarian date formats (with a colon as separator), which was _not_ possible before. 3. It prepares both the Drupal system and module developers for the upcoming locale_dateformat module. This module will fully localize date and time formats according to the localization of the current user. The locale_dateformat module will be available within the next weeks. I'm always happy about suggestions and criticism, if constructive. You can either write a comment on www.cvs.net or an email to pancho@suenderhauf.net. Bye, Pancho ------------- INSTALLATION: ------------- The package contains two patches for the latest CVS versions of Drupal 4.60 RC, both of which should be applied: 1. common.inc (patch for v.1.429) 2. system.module (patch for v.1.197) There are no changes in database structure.