I’ve changed the language-code from en-us to es-ar and the url’s began to fail.
Example: When I click in “Agosto 2010” the URL is “http://mysite.com/weblog/2010/ago/” and the server couldn’t finde the page. But if I browse “http://mysite.com/weblog/2010/aug/ the server finds and shows the page.
urls.py:
urlpatterns = patterns('django.views.generic.date_based',
(r'^$', 'archive_index', entry_info_dict, 'coltrane_entry_archive_index'),
(r'^(?P<year>\d{4})/$', 'archive_year', entry_info_dict,
'coltrane_entry_archive_year'),
(r'^(?P<year>\d{4})/(?P<month>\w{3})/$', 'archive_month', entry_info_dict,
'coltrane_entry_archive_month'),
)
templatetags.py:
@register.inclusion_tag('coltrane/month_links_snippet.html')
def render_month_links():
return {
'dates': Entry.objects.dates('pub_date', 'month'),
}
month_links_snippet.html:
<ul>
{% for d in dates reversed %}
<li><a href="/weblog/{{ d|date:"Y/b" }}/">{{ d|date:"F Y" }}</a></li>
{% endfor %}
</ul>
The
archive_monthgeneric view takes amonth_formatparameter, which specifies astrftimedirective (defaulting to'%b', for the locale’s abbreviated month name) to parse themonthvalue with.The problem is that
strftimeuses the process’s POSIX locale, which is not set by Django’s own locale mechanism (which is what thedatetemplate filter uses). See this earlier question:You could fix this in one of two ways:
LANGUAGE_CODE, for example by addinglocale.setlocale(locale.LC_ALL, LANGUAGE_CODE)to your settings module. This should makestrptimeparse the same month abbreviations as produced by thedatetemplate filter. (Note: This assumes that you treat the installation’s locale as static, and won’t use something likeLocaleMiddlewareto change it dynamically.)archive_monthview:(?P<month>\d{2}), and addmonth_format='%m'{{ d|date:"Y/m" }}