Opened 10 years ago
Closed 10 years ago
#23568 closed Bug (invalid)
timesince / timeuntil is not localized
Reported by: | Lé | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | 1.7 |
Severity: | Normal | Keywords: | l10n, i18n |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When l10n/i18n are on, the |timeuntil
and |timesince
filters do not provide translated strings.
I.e., with end
a datetime
object obtained with timezone.now() + timedelta(days=21)
:
{% load i18n l10n humanize %} {% get_current_language as LANGUAGE_CODE %} {{ LANGUAGE_CODE }}, {{ end }}, {{ end|timeuntil }}, {{ end|naturaltime }}, {% trans "Password" %}
returns:
es_ES, Oct. 20, 2014, 3:30 p.m., 2 weeks, 6 days, 2 weeks, 6 days a partir de ahora, Contraseña
So the localization is working, but those filters do not seem to use it.
See attached project for a working version of this example.
Attachments (1)
Change History (4)
by , 10 years ago
Attachment: | test_l10n.tar.gz added |
---|
comment:1 by , 10 years ago
Can you try using the "es" as language code in your settings instead of es_ES? This is what django uses [1].
IIRC, gettext will fallback to English, if it cannot find the files that correspond to the correct locale, which could explain the weird behavior here.
The code looks correct to me with a quick look.
[1]: https://github.com/django/django/tree/master/django/conf/locale/es
comment:2 by , 10 years ago
Same thing. The point of my example is that "regular" strings do get translated (I don't have any project-specific locale file to translate "password", this is Django's translation), so it is able to find the locale files.
comment:3 by , 10 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Turned out I did not realize I was still using RC2. 1.7 does not have this bug, even though I don't know when/where it has been solved. Sorry.
Example project