How are translations handled 2024?

1

Dears, I was just about to update a translation in System Settings Doctype but was not able to find the translation *.csv in the frappe/frappe repo as I was used to.

Please let me know where and how I can add translations to the core. Thank you.

2

Short answer: the file is now called [lang].po (e.g. de.po for German) and translations can be added comfortably via the crowdin UI:

Here’s how you can manage po files for your custom apps (this is largely automated for frappe, erpnext, hrms and lms):

https://frappeframework.com/docs/user/en/bench/reference#translation-management

Here’s the PR that introduced this, with further info in the description:

If you find it more comfortable to translate directly in the ERPNext/Frappe UI, there’s In-Context Translation. In order to use this, you have to enable the Language “In-Context Translation” / “eo”, select this for your current user and use the modal to log into your Crowdin account.

3 Likes
3

@rmeyer Would this work for .tsx files (React apps) as well? I’ve added translation functions in my React app, but I’m not sure if the PO files will get generated for those strings. They are wrapped as __(“String”) in the app.

4

@rmeyer I would add Hungarian translation and translate as I was done on
https://translate.erpnext.com/

As today you and others using in Hungarian language, if ever want, is almost all my work, I just want to keep it updated.
Is it possible to add Hungarian and put me editor + approval ?

Would appreciate any positive response.

5

Yes, in principle strings can be extracted from any file type. Check frappe’s babel_extractors.csv, which maps file paths to extractor functions. You’ll have to add one for .tsx. This can either be a real .tsx parser or you can use the existing pattern matcher for html-like templates (Jinja, JS Microtemplates).

So, for example, you’d create [app]/babel_extractors.csv and add the following line:

**.tsx,frappe.gettext.extractors.html_template.extract

This has some limitations compared to a real parser: backticks as quotes, the context parameter and translation statements formatted over multiple lines might not work as expected.

1 Like
6

Hey guys, believe it or not, this might be one of the most critical things to get right with frappe / erpnext, specially in the website / frontend part.

I’m still wondering how can we translate the following in a webshop:

  • Categories
  • Attributes
  • Variants
  • Products / Items
  • Prev & Next ( Switch Page Buttons )

Are there any solutions yet for dynamic variables?

7

Done :white_check_mark:

1 Like
8

How can I keep my custom translations when upgrading? For example, it is essential to retain the translations I have completed when translations on Crowdin have not been merged in a timely manner or when there is a need for personalization.

9

Custom translations via the Translation doctype or via custom apps are always retained.

1 Like
10

I´m checking the translation and most of the time it works quite fine. However I have some problems and you may help me with an answer.

I have a Table Docfield in the webform but the “Add Row”, “No.”, … are not translated. I already checked the de.po file but it´s not working somehow. I already tried a custom solution with translation doctype, but this does not work at all (maybe wrong format).

All with Frappe Framework: v15.51.2 (version-15)

webform:
image

the original file:
image

de.po:
image

Custom translation

image
image1063×224 6.1 KB

But some translation like My Account and Logout works:
image

Am I doing something wrong?

11

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

12

Your analysis is correct. We’ve discussed a very similar issue here:

1 Like
13

Thank you very much for the response! I did not find this github issue :confused: I´m not familiar with contributing to big projects like frappe, but I will check if I can add maybe something. Thank you very much!

EDIT:

I tried to write a Fix: frappe/frappe/website/doctype/web_form/web_form.py at develop · petnd/frappe · GitHub
It will fix a lot but I guess there will be more fields with missing translation which I do not know.

Right now I cant post an issue on frappe github because it seems there was a lot of spam and is now temporarily closed. I will try to post it soon and make my first Pull Request ever :slight_smile: