Cannot translate word `None` using `gettext_lazy`

[Wladislav Artsimovich]

We have setup translation following ​https://docs.djangoproject.com/en/5.1/topics/i18n/translation/#lazy-translation .
Works great.

We have found a case, where translation is simply refused though and the initial string is returned, even though complete translation is provided with the django-admin makemessages --> Weblate --> django-admin compilemessages workflow. The word None.

from django.utils.translation import gettext_lazy as _

damage = {
    PRESENT: {
        "verbose_name": _("Present"),
    },
    NONE: {
        "verbose_name": _("None"),
    },
    NO_INFORMATION: {
        "verbose_name": _("No information"),
    },
}

backend\RestAPI\locale\ja\LC_MESSAGES\django.po

...
#: .\RestAPI\algorithms\AD00002\cl20231101_2.py:25
#: .\RestAPI\model_constants.py:89 .\RestAPI\model_constants.py:98
msgid "None"
msgstr "なし"
...

this code results in translations for all words, except None, which keeps returning None untranslated. Didn't debug deep enough to understand whether this is an issue with Django, specifically gettext_lazy or the underlying gettext suite of tools.

[Sarah Boyce]

I don't think it's that "None" can't be translated, I see that in ​django/contrib/admin/locale/ja/LC_MESSAGES "None" is translated to "None"

This could be a precedence issue, see ​how django discovers translations.

Can you share your LOCALE_PATHS and INSTALLED_APPS settings? We also have this existing ticket #34221, does your .po file contain Plural-Forms?

[Wladislav Artsimovich]

Good to know it's not a bug regarding some special or reserved keywords. I literally mentioned to my colleague "There is no way we are the first ones to try and translate None".

LOCALE_PATHS is simply LOCALE_PATHS = ["locale"]
INSTALLED_APPS is:

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "django.contrib.admindocs",
    "django_docutils",
    "corsheaders",
    "rest_framework",
    "RestAPI",
    "drf_yasg",
    "taggit",
    "social_django",
]

I have never enabled any form of fuzzy matching or plural handling, but we do have "Plural-Forms: nplurals=1; plural=0;\n" at the top of our backend\RestAPI\locale\<language>\LC_MESSAGES\django.po, so I'm not what to make of it.

[Sarah Boyce]

Then I think this might be a duplicate of #34221, I think manually removing Plural-Forms: nplurals=1; plural=0;\n might be a work around

[Wladislav Artsimovich]

You are correct! That solves the issue and makes this indeed a duplicate of https://code.djangoproject.com/ticket/34221

It's "Plural-Forms: nplurals=2; plural=(n != 1);\n" in the German django.po, "Plural-Forms: nplurals=1; plural=0;\n" in the Japanese django.po and

"Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || (n"
"%100>=11 && n%100<=14)? 2 : 3);\n"

in the russian django.po.
I'm fairly worried about just deleting those and causing Weblate to flag all translations for Check or something, but I suppose since we specifically disabled all forms of fuzzy or plural it should be fine?