#34630 closed Bug (worksforme)
Neither `pgettext` nor `pgettext_lazy` return contextual markers in PO files
Reported by: | Kamil Paduszyński | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | 4.2 |
Severity: | Normal | Keywords: | tr |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I have noticed the problem when moving from 4.1.9
to 4.2.1
.
Contextual marker is returned as the message ID, whereas the actual message is ignored. For example:
pgettext_lazy("month name", "May")
gives the following in the respective PO file:
msgid "month name" msgstr ""
Change History (10)
follow-up: 2 comment:1 by , 17 months ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
follow-up: 3 comment:2 by , 17 months ago
Replying to Mariusz Felisiak:
Thanks for rapid review and answer!
To my surprise, it started to work on my setup (using the same version of gettext
, 0.21).
But... When I was posting the ticket, pgettext_lazy
was aliased it with _
(like this is commonly done with gettext_lazy
). If I do not use the alias, everything works normally... So, it looks like the way pgettext_lazy
works depends on the way it's imported. Is that even possible?
Thanks for the report, however it works for me, see e.g. MONTHS_AP and their translations. Maybe it's an issue in
gettext
, I checked withgettext
version 0.21.
follow-up: 4 comment:3 by , 17 months ago
Replying to Kamil Paduszyński:
But... When I was posting the ticket,
pgettext_lazy
was aliased it with_
(like this is commonly done withgettext_lazy
). If I do not use the alias, everything works normally... So, it looks like the waypgettext_lazy
works depends on the way it's imported. Is that even possible?
I don't think so. This can be an issue in your code. You can try to prepare a minimum, sample project that reproduces your issue and ask folks on one of support channels for help in debugging.
comment:4 by , 17 months ago
If you'll find a minute, please take a quick look:
https://github.com/paduszykam/django-pgettext_lazy-issue
Dzięki!
Replying to Mariusz Felisiak:
Replying to Kamil Paduszyński:
But... When I was posting the ticket,
pgettext_lazy
was aliased it with_
(like this is commonly done withgettext_lazy
). If I do not use the alias, everything works normally... So, it looks like the waypgettext_lazy
works depends on the way it's imported. Is that even possible?
I don't think so. This can be an issue in your code. You can try to prepare a minimum, sample project that reproduces your issue and ask folks on one of support channels for help in debugging.
follow-up: 6 comment:5 by , 17 months ago
Hi Kamil,
The project you posted is not configured correctly. LOCALE_PATHS
must be a list of directories, not a single directory.
@felixx
I think part of the problem here is that the error message highlighting this misconfiguration wasn't being shown when running makemessages
, I could only see it when I simply ran ./manage.py
with no args. I'm unfamiliar with makemessages
but should it be showing errors? 🤔 Note that if I run ./manage.py showmigrations
(for eg) it does show the error.
comment:6 by , 17 months ago
Sorry for that silly config error.
I have just fixed it and pushed the changes. This did not resolve the issue though.
Replying to David Sanders:
Hi Kamil,
The project you posted is not configured correctly.
LOCALE_PATHS
must be a list of directories, not a single directory.
@felixx
I think part of the problem here is that the error message highlighting this misconfiguration wasn't being shown when runningmakemessages
, I could only see it when I simply ran./manage.py
with no args. I'm unfamiliar withmakemessages
but should it be showing errors? 🤔 Note that if I run./manage.py showmigrations
(for eg) it does show the error.
follow-up: 8 comment:7 by , 17 months ago
I'm pretty sure you can't simply alias the (n|p)gettext
family like you can do with the simpler gettext/gettext_lazy
calls. Remember that gettext works by parsing code. So this is not a Django-specific issue, it's how gettext works. See also the --keyword
xgettext parameters in makemessages.py
. If aliases are used, then those aliases should also be present in some --keyword
parameter (which are not customizable in Django currently).
comment:8 by , 17 months ago
Thanks! Now it's clearer to me. Is that "aliasing limitation thing" mentioned in docs? Maybe it should.
Replying to Claude Paroz:
I'm pretty sure you can't simply alias the
(n|p)gettext
family like you can do with the simplergettext/gettext_lazy
calls. Remember that gettext works by parsing code. So this is not a Django-specific issue, it's how gettext works. See also the--keyword
xgettext parameters inmakemessages.py
. If aliases are used, then those aliases should also be present in some--keyword
parameter (which are not customizable in Django currently).
follow-up: 10 comment:9 by , 17 months ago
This is clearly mentioned in documentation that you cannot alias non-single argument translation functions with _
See https://docs.djangoproject.com/en/4.2/topics/i18n/translation/
What functions may be aliased as _?
Because of how xgettext (used by makemessages) works, only functions that take a single string argument can be imported as _:
gettext()
gettext_lazy()
comment:10 by , 17 months ago
Thank you guys for all the help! And sorry for bothering. Next time I will dive deeper into docs.
Replying to Antoine Humbert:
This is clearly mentioned in documentation that you cannot alias non-single argument translation functions with _
See https://docs.djangoproject.com/en/4.2/topics/i18n/translation/
What functions may be aliased as _?
Because of how xgettext (used by makemessages) works, only functions that take a single string argument can be imported as _:
gettext()
gettext_lazy()
Thanks for the report, however it works for me, see e.g. MONTHS_AP and their translations. Maybe it's an issue in
gettext
, I checked withgettext
version 0.21.