Localization in the admin site and date/time filters.
Bob Thomas
that needs to be reconciled somehow, and I figured this list was the
best way to fight it out.
#2203 summary - Date/time formats in the admin interface use the
{DATE,TIME,DATETIME}_FORMAT string from translation files, and fall
back to settings.DATE_FORMAT if there is nothing found. It is not
possible to override this with settings.DATE_FORMAT
#9366 summary - Date/time formats used by the date and time filters
use settings.{DATE,TIME}_FORMAT. It is not possible to use the
DATE_FORMAT string from a translation file without creating a custom
filter. (I also mention that there is no way to use DATETIME_FORMAT
either from settings or translation files, but that should probably be
a separate issue)
There doesn't seem to be any simple fix for both of these that will
make everyone happy. I've come up with a few ideas, but they probably
break backwards compatibility, or will make a 3rd group of people
unhappy.
1. Make the DATE_FORMAT setting default to empty string. If it's empty
in get_date_formats(), use the format from translation files,
otherwise use the format in the setting. This will break any
installation that has i18n disabled and no DATE_FORMAT in their
settings.py, unless get_date_formats() also hardcodes a fallback
format (the current default setting). This also makes an all-or-
nothing solution where overriding the format in your settings file
prevents you from using any localization of that particular format.
2. A slight improvement on #1 would be making the DATE_FORMAT setting
default to the string 'DATE_FORMAT', and get_date_formats() would then
attempt to translate that string. This would allow for a user to set
it to either an actual date format to override it everywhere, or a
string like 'CUSTOM_DATE_FORMAT' which can then be added to a
project's translation files for all locales. This still needs the
hardcoded fallback as #1 in the case where i18n is disabled and
DATE_FORMAT is not present in the project's settings.py.
I'm not sure if it's possible to make everyone happy, but there needs
to be a clear way to choose either a localized format or a custom
format, and Django needs to be consistent (by default) in every case
where it is formatting a date/time.
Anyone have any better ideas (I haven't done much work with i18n/
l18n)? Did I miss a situation where someone could still get stuck not
being able to easily use the desired format?
-bob
Malcolm Tredinnick
On Fri, 2008-11-21 at 11:33 -0800, Bob Thomas wrote:
> See tickets #2203 and #9366. They're two opposite sides of an issue
> that needs to be reconciled somehow, and I figured this list was the
> best way to fight it out.
>
> #2203 summary - Date/time formats in the admin interface use the
> {DATE,TIME,DATETIME}_FORMAT string from translation files, and fall
> back to settings.DATE_FORMAT if there is nothing found. It is not
> possible to override this with settings.DATE_FORMAT
>
> #9366 summary - Date/time formats used by the date and time filters
> use settings.{DATE,TIME}_FORMAT. It is not possible to use the
> DATE_FORMAT string from a translation file without creating a custom
> filter. (I also mention that there is no way to use DATETIME_FORMAT
> either from settings or translation files, but that should probably be
> a separate issue)
They're both really the same problem: it should be possible to localise
the settings. Right now we're just kind of hacking it into the admin
interface, rather than having a more holistic solution in place.
> There doesn't seem to be any simple fix for both of these that will
> make everyone happy. I've come up with a few ideas, but they probably
> break backwards compatibility, or will make a 3rd group of people
> unhappy.
>
> 1. Make the DATE_FORMAT setting default to empty string. If it's empty
> in get_date_formats(), use the format from translation files,
> otherwise use the format in the setting. This will break any
> installation that has i18n disabled and no DATE_FORMAT in their
> settings.py, unless get_date_formats() also hardcodes a fallback
> format (the current default setting). This also makes an all-or-
> nothing solution where overriding the format in your settings file
> prevents you from using any localization of that particular format.
>
> 2. A slight improvement on #1 would be making the DATE_FORMAT setting
> default to the string 'DATE_FORMAT', and get_date_formats() would then
> attempt to translate that string. This would allow for a user to set
> it to either an actual date format to override it everywhere, or a
> string like 'CUSTOM_DATE_FORMAT' which can then be added to a
> project's translation files for all locales. This still needs the
> hardcoded fallback as #1 in the case where i18n is disabled and
> DATE_FORMAT is not present in the project's settings.py.
A little context here: the various *_FORMAT settings slightly predate
internationalisation support in Django and have never really
interoperated well with them. In places that is worked around manually,
but that's not ideal. We do need to fix that, but things also need to
work with existing code, which means people who haven't touched those
settings and who have USE_I18N=False, as well as those who are using the
internationalisation support.
My preference would be that is you set the various settings to some
special string -- such as "DATE_FORMAT" or "I18N_FORMAT" -- we will use
the translated versions of the various technical message ids
(DATE_FORMAT, DATETIME_FORMAT, etc). I probably prefer at least allowing
the more specific strings ("DATE_FORMAT"), because that would let
somebody add their own technical message ID if they wanted to add, say,
LOCAL_AP_STYLE. Right now, Django doesn't support extra technical
message ids because they aren't needed, but this would be a case where
they could be useful.
Unfortunately, we do need to have these technical translations, because
there isn't a "natural" format that we can choose on a per-locale basis
Django's current default is based on AP style, which isn't necessarily
the natural choice, if you aren't in the journalism sphere, even if you
are only catering for the US locale. It has slightly non-standard month
abbreviations conventions, for example. So this isn't something where we
don't need to bother having a huge choice.
The question as to whether to automatically translate the current
default values is harder to judge. Might be worth doing, though. The
reason is historical: Django's default is rooted in its journalism roots
and uses AP style. AP style has a slightly non-standard month
abbreviation conventions. Anything less than six letters isn't
abbreviated and other things are abbreviated to different lenths
("Sept." vs "Nov."). This style doesn't localise well. The problem being
that translators see only one message id string, such as "April", and
gettext doesn't differentiate between "April" the month name and "April"
the AP-style "abbreviation", even though they're distinct when you move
to other languages. If we didn't need to support USE_I18N=False, this
would be easy to solve, but that's not the universe we live in. The
consequence here is that there's a fairly strong case for adding, say, a
three-letter abbreviation (actually, better, just a "month
abbreviation", since "3 letters" is an English-ism) format string that
produces abbreviated, capitalised month names that translators can use
in place of "N" in the format string ("N" being Django's custom
extension for AP-style month names).
The above paragraph shows why internationalising these settings is
actually a tough problem: there isn't a natural translation for those
strings. You're translating the components -- day names, month names,
etc, -- but with respect to a particular "style" -- by default, AP style
months, in Django's case. There's no locale-wide correct answer, because
it depends on the style preferred, which is going to be something
controlled through the settings, rather than in the application.
Translators don't (and shouldn't) control or influence settings, so
they're stuck up a tree without a map a bit when it comes to translating
the default formats. Introducing the possibility of extra technical
message ids helps there, but we then need a way to fallback so that if
some locale hasn't translated, say, LOCAL_AP_DATETIME_STYLE, it falls
back to DATETIME_FORMAT. Not too hard, but needs doing.
So I would be in favour of allowing technical message ids and values for
*_FORMAT settings, which get translated appropriately. It's a bit of a
toss-up (and something that isn't a showstopper either way) whether to
also translate the current default values. Doing so makes i18n work
better but may confuse some people who haven't changed the default and
don't want it translated. I suspect we'll come down as "don't change"
there, but it's a relatively small issue.
Regards,
Malcolm