#14570 closed (fixed)
New format character to represent locale-specifc alternative month names
Reported by: | shell_dweller | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Keywords: | month, format | |
Cc: | s.kuzmenko@…, claude@… | Triage Stage: | Unreviewed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Why this is required
In certain locales "F" is not enough to represent full month name in long date formats. The reason is that "F Y" (e.g., "October 2010") and "F j Y" (e.g., "October 1 2010") will require two different grammatical forms for month name.
This patch is useful for Greek and the majority of Slavic languages. Other languages may find use of it too.
Solution
New format character is introduced to represent alternative locale specific month names. The choice of character is "E". Rationale: alphabetically it is the closest one to "F" that represents full month name.
TODO
After this patch is committed to trunk I will create a patch for documentation and will notify translators.
Historical note
This is a duplicate of ticket 12309 that was created and subsequently closed by me. At the time I reckoned that it would be better to use Babel for locale specific date representations. However, after careful consideration I changed my mind and I do believe this is a useful addition to Django because it follows batteries included principle, specially in view of new format localization rules introduced in 1.2
Attachments (2)
Change History (7)
comment:1 by , 14 years ago
Cc: | added |
---|
comment:2 by , 14 years ago
Suggestion to use pgettext instead of "_Month" makes good sense. I will adjust my patch accordingly.
I do share the concern about introducing extra format character that is going to be used only by a limited number of locales. So for the record here's how this is done elsewhere:
POSIX has no notion of "alternative month". Instead, there is a special conversion specification modifier (%O) that is used to represent alternative numbers (probably with languages such as Persian in mind). This is commonly used as a work around when an alternative month name representation is required.
In Babel based on LDML specification various alternative representations of month names are achieved by character repetition, e.g., "MMMM" is usually the "alternative" month representation I'm talking about here. Note that there are two format characters for month: "L" (stand alone which would be an equivalent of what "F" is currently in Django) and a more generic "M" format (which would be an equivalent of my proposed "E" format).
So basically this leaves us with two major options:
- Introduce a new format character
- Use some sort of extended notation (either though a modifier character of mere repetition)
The benefit of 1 is simplicity of implementation (and use). Option 2 requires more significant changes to the date formatting engine but is potentially more robust (e.g., can be easily extended towards alternative numeric representations for month, day, hour and so on without introduction of new format characters).
Yet another option would be to adopt LDML notation with gradual phasing out the existing PHP based notation which is not particularly i18n friendly. This would be the most dramatic change of course.
It would be very nice to get some feedback form the core team on this subject before I commit to providing my final patch.
by , 14 years ago
Attachment: | alternative-long-date-format.diff added |
---|
A better patch based on pgettext
by , 14 years ago
Attachment: | alternative-month-name-localizations.diff added |
---|
A clean translation patch (translations were loaded from Babel based on LDML definitions)
comment:3 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I have some doubt about the "_Month" syntax used in your patch. We are currently working on pgettext support in ticket #9988. If it gets committed, you would then be able to take advantage of the new pgettext function to obtain amore standard contextual marker. More generally, I'm still a little worried by the extra strings you add even for languages that do not use the feature, but I don't see any other/better method to achieve the same goal.