I have tried to narrow down the problem and find the cause. Unfortunately, I have not been 100% successful, but here are my findings so far:
General:
- Translations usually work without problems
- With Web Forms, however, there are isolated problems
- Translations in Web Forms, which are standard fields or controls, have problems (but not, for example, the main action buttons such as Discard)
Frontend console
- frappe._message provides a complete list of all translations in the desk view
- frappe._message only provides a very limited selection of translations in the Web Form view. These are only the superficial elements, but not nested elements such as grid controls or the calendar.
- Since (I assume) the translation in the frontend is based on frappe._messages, there is probably a problem here
Backend:
- Here I am slowly despairing of finding the causes. I only have a rough guess
- Some time ago there was a commit that tackled translations:
refactor!: remove redundant sending of translations (#22962) · frappe/frappe@f015567 · GitHub - According to my idea, a possibility should be created in load_translations in frappe/website/doctype/web_form/web_form.py that the fieldtypes are checked and, if necessary, if text is available, these are also added to the translation in messages=.
But what really surprises me: why is it only now coming to light if the commit is from 2023? So I’m very unsure whether it’s a local problem for me or something more general. I have also found very few reports of problems on Github and here in the forum.
However, here are two other posts with possibly similar problems:
@rmeyer I hope I haven’t misinterpreted anything here, I’m just looking for a solution to my problem.
Kind regards