i18n

[jayvdb]

(Can of worms opener ...)

All messages emitted by drf-spectacular should be from message catalogs, and the appropriate language used based on the HTTP request headers using standard Django i18n mechanisms including fallbacks (to English usually).

e.g.

drf_spectacular/openapi.py:                return {'204': {'description': 'No response body'}}
drf_spectacular/openapi.py:            return {'description': 'No response body'}
drf_spectacular/openapi.py:                return {'description': 'No response body'}

I guess the only way to have l10n is to embed all available languages in the mandatory description's using html blocks

c.f. OAI/OpenAPI-Specification#274 , api-platform/api-platform#1363 , OAI/OpenAPI-Specification#1740 (comment) .

But this is Django, and Django REST Framework, and so should follow its conventions where possible ;-).

[jayvdb]

Another way to do multi-lang would be to adjust the language used by drf-spectacular for parts of the tree according to the language of LocaleRegexURLResolver when it is encountered.

[tfranzel]

doing i18n on the explicit string (like above) through the django facilites would we rather easy. schema serving endpoints should honor the language header by default. the cli command could receive the language via an extra parameter. however, translating the docstring documentation would be the real problem. solving that in a clean way looks messy/complicated.

[jayvdb]

__doc__ = _(..) isnt that complicated for views and serializers, etc.

And drf-spectacular can monkey patch the __doc__ attrs so that the user doesnt need to do anything out of the normal.