#14570: New format character to represent locale-specifc alternative month names
-------------------------------------------+--------------------------------
Reporter: shell_dweller | Owner: nobody
Status: new | Milestone: 1.3
Component: Internationalization | Version: SVN
Resolution: | Keywords: month, format
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------------------+--------------------------------
Comment (by shell_dweller):
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:
'''[http://www.opengroup.org/onlinepubs/009695399/ 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 '''[http://babel.edgewall.org/wiki/Documentation/dates.html Babel]'''
based on [http://unicode.org/reports/tr35/#Date_Format_Patterns 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:
1. Introduce a new format character
2. 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.
--
Ticket URL: <http://code.djangoproject.com/ticket/14570#comment:2>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
