This makes it very inconvenient to override the default django
translations. Here's a very simple example:
`django/conf/locale/mr/LC_MESSAGES/django.po` has:
{{{
#: utils/dates.py:6
msgid "Monday"
msgstr ""
}}}
I override this in `BASE_DIR / "locale/mr/LC_MESSAGES/django.po"` with:
{{{
msgid "Monday"
msgstr "सोमवार"
}}}
And this works fine; until someone else comes along and runs `./manage.py
makemessages -l mr`, causing the above translation which is used, to be
commented out!
{{{
#~ msgid "Monday"
#~ msgstr "सोमवार"
}}}
I feel that `makemessages` should not delete/comment translations that are
overriding default django translations, otherwise the utility of that
command is severely reduced.
A current workaround is to explicitly copy over all strings that are
overriden into a file in the project so that gettext can pick them up, but
it creates unnecessary boilerplate.
A possible solution could be to change the `makemessages` command to also
scan the `django` source code, in addition to the app's source, although I
am not sure of the complications here.
In addition, the documentation could also be improved by adding a
recommended way of overriding the default translations that ship with
django, that works well with the `makemessages` command.
--
Ticket URL: <https://code.djangoproject.com/ticket/33068>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
Ticket URL: <https://code.djangoproject.com/ticket/33068#comment:1>
* cc: Claude Paroz (added)
* status: new => closed
* resolution: => worksforme
Comment:
Thanks for the report, however I cannot reproduce this issue with
following steps:
- create new project
- copy `django/conf/locale/mr/LC_MESSAGES/django.po` to the
`<BASE_DIR>/locale/mr/LC_MESSAGES/django.po`
- add `LOCALE_PATHS = [BASE_DIR / 'locale']` to settings
- translate some strings in `<BASE_DIR>/locale/mr/LC_MESSAGES/django.po`
- compile messages,
- call `python manage.py makemessages -l mr`
I don't see any lines commented in the
`<BASE_DIR>/locale/mr/LC_MESSAGES/django.po`.
--
Ticket URL: <https://code.djangoproject.com/ticket/33068#comment:2>
Comment (by Satyajeet Kanetkar):
@Mariusz Felisiak Thanks for the attempt at reproducing, but one
additional step is needed to make the bug re appear.
Before running `compilemessages`/`makemessages` you need to add at least
one custom translation so that gettext actually has reason to modify the
`.po` file.
Simplest would be to add the below snippet at the end of the `urls.py` of
the default scaffolding:
{{{
from django.utils.translation import gettext as _
_("Translate This!")
}}}
And then run the `makemessages` and `compilemessages` steps as mentioned.
You should see the legitimate translations getting commented out.
I will be re-opening the ticket as I am able to reproduce this with the
above minimal code added to a default django project.
--
Ticket URL: <https://code.djangoproject.com/ticket/33068#comment:3>
* status: closed => new
* resolution: worksforme =>
--
Ticket URL: <https://code.djangoproject.com/ticket/33068#comment:4>
* status: new => closed
* resolution: => invalid
Comment:
Thanks for extra details. You should copy base translations to the
separate directory if you want to include your own translations, and
override base translations in your project, i.e.
- copy `django/conf/locale/mr/LC_MESSAGES/django.po` to the
`<BASE_DIR>/django/conf/locale/mr/LC_MESSAGES/django.po` (override base
translations),
- `<BASE_DIR>/locale/mr/LC_MESSAGES/django.po` will contain your own
project translations,
see [https://docs.djangoproject.com/en/stable/topics/i18n/translation
/#how-django-discovers-translations How Django discovers translations].
--
Ticket URL: <https://code.djangoproject.com/ticket/33068#comment:5>