How to translate the keys that will be sent in the body of the REST API in the Django Rest Framework UI? I created my models and code in English, using gettext_lazy to translate things, but the keys remain in English. They appear in my language in the form when creating instances, but the responses in the body always show the keys in English.
#Translate DRF keys in the body of the response
fading wedge
What's the issue? Code in English is good. Serialized data is not user-facing, so the keys don't matter all 🤔
It's common practice to use English for such things, as you may one day support different languages, and it would be silly to have a /users/create/german/ and /users/create/french/ endpoint with localized keys.
spare aspen
What's the issue? Code in English is good. Serialized data is not user-facing, s...
I know the best approach would be to have the API in English only, as it is a universal language. But then, is it not possible to build an API with support for other languages in this way? I've seen people commenting on this—what approach do they use? Even if they use gettext_lazy or similar, will the keys in the body always be in the original language in which the variables were written in the code? I'm new to this, trying to understand the possibilities and what fits best for my case. Thank you.
glass stirrup
I would call it highly uncommon to translate the response keys in an API. It really does not make sense, as the API is supposed to be machine/source readable. Translating the values on the other hand is much more common
spare aspen
I would call it **highly** uncommon to translate the response *keys* in an API. ...
I see, that makes sense. So there's nothing I can do about it, right? What I'm doing is already the standard approach? Translating only the "interface" for the user consuming the API and keeping the request/response body keys in English.
fading wedge
I see, that makes sense. So there's nothing I can do about it, right? What I'm d...
Ultimately, assuming you are the developer, you are free to name the keys what you want. It can be primeiro_nome, it can be first_name, it can be dskfhhgsdhgfsgdsf 🤷♂️
I generally recommend keeping things like API keys, variable names, comments, etc. in English, as much as possible, as it is the de facto business language, makes collaboration with other countries easier, and if you translate your app into many languages, as I've said, you only want the user-facing text to be translated.
Naturally, if your coworkers all speak only/mostly Portuguese, you can use Portuguese, rather than English... just be consistent, IMO.
spare aspen
Yes, I agree. It's just that I'm starting to follow the REST standard in API development now. I want to try to follow a consistent pattern that makes sense according to common practices. I believe that in cases where the API will be consumed by people from different countries, the correct approach would be what you mentioned—keeping everything related to the code in English and only the user interface in their native language, right?
Additionally, I noticed something: when trying to create a superuser using create_superuser, some error messages remain in English or mix translations between English and my language. Here are some images that better illustrate what I mean.
glass stirrup
The strings to not appear in the .po file 🤔 https://github.com/django/django/blob/main/django/conf/locale/pt_BR/LC_MESSAGES/django.po
Looks like the command is not translated https://github.com/django/django/blob/stable/5.1.x/django/contrib/auth/management/commands/createsuperuser.py
I asked here #contributor-discussion message
spare aspen
So, is this something that needs to be fixed? The message was not marked for translation and therefore didn’t appear in the .po file to be translated, correct?
glass stirrup
Yes. The question is if it should be translated ... thus the questions
The fact that some of the messages are translated is because those come from the model, not the command.
spare aspen
I understand, I’m doing some tests and it’s possible that I’ll come across other untranslated messages. I’m working on a small test/study project, allowing the languages pt-br and en, so if I find anything unusual in my language, I can report it.