cc @JulienPalard @serhiy-storchaka

Unfortunately I lost several hundreds of local branches and patches a week ago, so I have to start from beginning.

Oh no :-( I'm very sorry for you 😔

I worked on this issue, and it was more complex than just replacing warnings with exceptions. It is an interface with multiple implementations, so we perhaps need to add more warnings before making them errors.

Ah? Would you mind to elaborate? Which function are you talking about? Do you want to deprecate more code paths?

Currently only methods of GNUTranslations emit warnings. NullTranslations does not emit warnings. And global functions silently accept non-integer n if the translation for domain/language is not found. We should first add warnings in all these places, but only emit one warning per function call and with correct stacklevel. It is not easy because functions call other functions recursively.

Currently only methods of GNUTranslations emit warnings. NullTranslations does not emit warnings.

NullTranslations does "nothing". It doesn't parse the input file. I don't see the relationship with this issue which is only about removing deprecated code.

And global functions silently accept non-integer n if the translation for domain/language is not found.

Which global functions? I only found c2py() used by GNUTranslations._parse() to parse plural-forms.

NullTranslations does "nothing".

It does not do "nothing". For example:

    def ngettext(self, msgid1, msgid2, n):
        if self._fallback:
            return self._fallback.ngettext(msgid1, msgid2, n)
        if n == 1:
            return msgid1
        else:
            return msgid2

It does choose msgid1 or msgid2, depending on the value of n. And it accepts float n.

Which global functions?

dngettext() and others.

This PR is about removing deprecated code in GNUTranslations.

So ok, there is a code path in NullTranslations that you would like to change. But it's not deprecated yet, and it's a different class.

Would you be ok to change GNUTranslations right now (this PR), and consider changing NullTranslations later? If yes, I will update the PR to clarify that the change is specific to GNUTranslations.

Note: I'm not convinced that NullTranslations needs to be changed, but I don't have a strong opinion about it.

This PR is about removing deprecated code in GNUTranslations.

Since GNUTranslations inherits from NullTranslations why not implement the checks in the base class and refactor as necessary to gain it in the base class (and potentially any other base classes) automatically? (Aside: I wish we had ABCs back when this module was originally written.)

FWIW, flufl.i18n implements a stack of translations for web-based applications (as opposed to single invocation CLIs) like Mailman which need multiple active translation contexts at any one time. NullTranslations serves as the default based translation context. I think ultimately it would be weird if you got an exception some times but not others depending on whether a context has been pushed on the stack.

Would you be ok to change GNUTranslations right now (this PR), and consider changing NullTranslations later?

No. I would did it a year ago if it be so simple. See #88434.

Adding deprecations which cover all paths (including third-party implementations) and only produce one warning per call is a bit tricky.

Sorry but I don't have the bandwidth to investigate on how to rework deeply gettext to handle the issue in every possible code path. My plan was only to change the few lines related to the current DeprecationWarning. If someone is more motivated than me, please go ahead. You can freely copy my code ;-) Get it as a patch. I just close my PR.