[drupal-devel] [feature] Localize date formats
Bèr Kessels
drupal-devel at drupal.org
Wed Jul 27 16:32:25 UTC 2005
Issue status update for
http://drupal.org/node/11623
Post a follow up:
http://drupal.org/project/comments/add/11623
Project: Drupal
Version: cvs
Component: base system
Category: feature requests
Priority: normal
Assigned to: pancho
Reported by: Goba
Updated by: Bèr Kessels
Status: patch
+1 for the idea. +1 for the implementation.
The idea is simple: just pull the format string trough the locales. No
new interfaces (+1), no new configuration options (+1) and no
additional cruft. po files will then take care of the real format.
However, I see one issue: we should remove the dopdowns in
/admin/settings.
The patch still applies.
Bèr Kessels
Previous comments:
------------------------------------------------------------------------
Fri, 15 Oct 2004 18:52:24 +0000 : 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.
------------------------------------------------------------------------
Fri, 15 Oct 2004 19:00:27 +0000 : 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.
------------------------------------------------------------------------
Fri, 15 Oct 2004 19:01:56 +0000 : killes at 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.
------------------------------------------------------------------------
Fri, 15 Oct 2004 19:05:33 +0000 : 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.
------------------------------------------------------------------------
Fri, 15 Oct 2004 23:07:29 +0000 : 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.
------------------------------------------------------------------------
Sat, 16 Oct 2004 09:34:09 +0000 : 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.
------------------------------------------------------------------------
Fri, 29 Oct 2004 00:10:44 +0000 : 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.
------------------------------------------------------------------------
Fri, 29 Oct 2004 13:19:01 +0000 : 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.
------------------------------------------------------------------------
Fri, 29 Oct 2004 15:05:28 +0000 : 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.
------------------------------------------------------------------------
Sun, 13 Mar 2005 14:55:22 +0000 : pancho
Attachment: http://drupal.org/files/issues/dateformat.patch.zip (14.91 KB)
************************
DATEFORMAT-PATCH PACKAGE
************************
by pancho at 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 at 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.
------------------------------------------------------------------------
Sun, 13 Mar 2005 14:59:33 +0000 : pancho
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!
------------------------------------------------------------------------
Sun, 13 Mar 2005 15:08:35 +0000 : pancho
I feel better if I refile the thread as a feature request. The only
thing you could describe as a bug was that German & Hungarian date
formats were not supported. The rest are definitely feature
improvements.
------------------------------------------------------------------------
Sun, 13 Mar 2005 16:38:02 +0000 : Steven
- Localizing date formats seems like something that should be solved
properly in core once and tied into locale.module. We need a solution
which does not pose problems with mixing languages, and which does not
require us to keep adding more and more date formats to the list (e.g.
what about asian date formats? They don't have spaces.)
Your "if (!module_exist('locale_dateformat'))" solution is
unacceptable for core.
- What's the point of the 'tiny' date format if it's not used anywhere?
Where would it be used?
- Please don't post patches as zips, this is annoying. Just make one
global patch file instead of separate ones. Multiple files can be
posted with multiple follow ups.
- You need to see how this affects the date usage around Drupal, e.g.
the profile date field formatting, which depends on the date format
being in a specific format.
- Code style: check spaces around quotes. Also, avoid trailing spaces
on lines, this is untidy.
- This issue is not "critical" IMO. It is a new feature request, and as
such should probably wait until after 4.6, as 4.6 is in feature freeze.
- The apostrophes around the separator item seem a bit unnecessary.
------------------------------------------------------------------------
Mon, 14 Mar 2005 17:08:34 +0000 : pancho
*/First of all: This patch works!
Even it may be not yet ready to be adopted in the core, it is good for
individual use./*
To Steven:
Okay, Steven, I was asking for criticism... :)
With some of the points you make I can agree:
- This feature should be completely and properly rewritten and not just
fixed to have a good solution for a longer period and not only for now.
- The "if (!module_exist('locale_dateformat'))" solution is not good
code style at least for core, as well as the spaces. I didn't take
enough care about that, as I wanted to present a solution now, before
the release of 4.6.
- Sorry about the zipped patches. I didn't expect it to bother anyone.
But on the other hand:
- It's not about adding more and more date formats. You will agree that
the German web is a big enough market which should not be left aside
anymore. Therefore the feature request /is critical/ from my
perspective at least. And the solution I presented doesn't blow up the
date format lists, in the contrary it makes them easier to use.
- How can you complain about the tiny version not to be used. If it
doesn't exist it /can't be used/.
- The apostrophees do make sense, because the separator can also be a
single space. Nobody would identify that in the menu without
apostrophees.
So you were critizising some points which I will fix in a new version
of the patch as soon as possible. But you didn't say anything about the
split of date and time formats. To me it makes sense, as there have
already been more people asking for "just date" or "just time".
While I already started the development of a
"locale_dateformat.module", I will put this on hold, until we figured
out a good solution altogether. Anyway, I'm ready to help developing
this feature within "locale.module" if I'm being asked. Otherwise
developing a separate module would at least offer the so needed
functionality /within this century/ ;-)
Pancho
------------------------------------------------------------------------
Fri, 18 Mar 2005 07:50:14 +0000 : Steven
Firstly:
"Even it may be not yet ready to be adopted in the core, it is good for
individual use.
"
The patch queue is really part of the Drupal development process. It
does not help us much to work on patches that are not intended for
core.
"It's not about adding more and more date formats. You will agree that
the German web is a big enough market which should not be left aside
anymore. Therefore the feature request is critical from my perspective
at least. And the solution I presented doesn't blow up the date format
lists, in the contrary it makes them easier to use.
"
I'm just saying, that solutions like the German date format (which has
a special notation for the day numbers) or Asian formats (which have no
spaces and reversed order) should really be handled through locale IMO,
where date formats are picked per language, and can be added manually
or through .po files.
"How can you complain about the tiny version not to be used. If it
doesn't exist it can't be used.
"
I imagine you introduced this format for a reason, no? Adding new
features without knowing exactly where they should be used is silly. If
you add a new feature in a patch, you should put in the work to see that
this feature is actually used.
I didn't really talk about splitting date/time formats for now, as it
is mostly a usability thing. I'd much rather wait for a solution
integrated with locale before I comment on it.
More information about the drupal-devel
mailing list