In a template, use the build-in date filter, eg. {{ value|date:"D d M Y }} (ref here).
In English, the output might be the string ‘Wed 09 Jan 2008’.
In French, the same date is the string ‘Épouser 09 Jan 2008’ (lol: Épouser means “to marry” ;).
The correct text is “Mer 09 Jan 2008”.
The full problem is Sat, Sun and Wed, which show as “Assis”, “Soleil” and “Épouser”. The correct text is “Sam”, “Dim” and “Mer”.
It appears that the abbreviations “Sat”, “Sun” and “Wed” were incorrectly translated to the corresponding French words, not the abbreviations of the French days of the week.
A possible workaround is to use {{ value|date:"l d M Y }} as full day name translates correctly.
You can see that they are correctly translated. I suspect that a 3rd-party package is overwriting those translations (and looks like AI-backed translations!). So I suggest you explore your project dependencies to identify the real culprit.
So… “makemessages” collects strings from django dates.
This is because my python venb is in the same folder as my project root and makemessages recursively searches all directories.
Putting the python venv in the same folder as the project is a very common practice and I can’t find a warning about this in the django docs.
Is this bad practice?
Finally, I have a design question about why my project’s .po file can override django’s .po files at all.
For example, say I legitimately have the translation “Sun” → “Soleil” in my application.
Since my project’s .po overrides the date filter .po, the day format would break.
Questions:
Should every django module use a “translation context” to make its translations unique?
Should the translation files be bound to the specific libraries so they can’t be overridden?
Should makemessages command skip files below the site-packages directory?
Again, if I have it wrong, let me know.
Thanks for your help.
Should every django module use a “translation context” to make its translations unique?
Not in my opinion. A translation context should only be used for specific cases where a string should be translated differently in different contexts (like the Sun example you suggested). Abuse of translation context may lead to duplication of messages to translate.
Should the translation files be bound to the specific libraries so they can’t be overridden?
I’m not sure to understand that question. But yes, each library should take core of its own strings. I suggest also you read (or re-read) that section on po file discovery: Translation | Django documentation | Django
Should makemessages command skip files below the site-packages directory?
Absolutely. For a setup like yours, you may have to use the --exclude option of makemessages.
I noticed that I missed a step in the instructions and hadn’t created a “locale” directory in my app.
After fixing this, “makemessages -fr” created a django.po file with just my strings and no date formats.
After running a script that populated the new .po from my original .po file, I had a new translated .po file with my strings only.
Then, ran “compilemessages”, which creates a django.mo file in the same directory as the new .po file.
Now, when I run my app all of my translations work (yay!).
But, the date formats display in English. I am doing translation.activate( ‘fr’ ),
My app knows it’s in French, the “date” filter doesn’t.
You generally shouldn’t have to call translation.activate(), except from some corner cases where you have to mix languages in the same request. I f you have to call it, it’s probably caused by bad detection of the current language (you need the LocaleMiddleware at least, see the docs), and then it can explain why the date format is still in English.