Translations handling cleanup (with performance boost, too)

[Anssi Kääriäinen]

The attached patch implements a different way to handle the delayed translations handling. The idea is to use a class and a getattr based method instead of using the delayed_loader and manipulating the globals.

The only problem with this patch is that if settings.USE_I18N is changed dynamically, the change setting will not change which function (the trans_null or trans_real one) is called. For normal use this is only a good thing (dynamical settings changing is evil), but can cause some problems if testing relies on this. If this is a problem, the class based method can easily be changed to not cache the functions. Just remove the setattr from the getattr method of the TransProvider.

The patch passes all tests.

[Anssi Kääriäinen]

Forgot to add info about the performance: I am using the test from #14290, ​http://localhost:8000/test/10000?timing. Without this patch, I get 16.5 seconds, with this patch, I get 13.5 seconds. There is a total of 60000 calls to get_language. In other words, the performance increase is noticeable only in case get_language gets called in hotspots. This happens to be the case in the ticket #14290, and it will be the case in any code using massive amounts of localization (10x1000 spreadsheet, for example). Also, if you have, say 100, translated strings in your view, this means you will get a free bonus of about 4ms per request (not tested, just calculated) (Or on a real server, probably somewhere in the range of 1ms to 2 ms.

[Jannis Leidel]

(In [13899]) Fixed #14306 -- Cleaned up django.utils.translation module a bit to be quicker. Thanks for the report and initial patch, Anssi Kääriäinen.