Multilingual Item description, terms and conditions, emails, etc

Frappe Framework
1

Hi all

I am using frappe.after_ajax(function() in order to change the description of an item in a quote after the default description has been pulled. It worked fine until now. I see that the description changes, but it comes back to the default one right after. Is there another way of running client side script in last position?

Thank you

2

try to put the script under “refresh” event

3

Can you share your script, what have you tried so far. So, it will be easy to understand the problem.

4 
frappe.ui.form.on("Quotation Item", "item_code", function(frm, cdt, cdn) {
    ct = locals[cdt][cdn]
    frappe.after_ajax(function() {
	    frappe.call({
		    method: "multilingual_extension.item_description.fetch_item_description",
		    args:{
			    customer_code: frm.doc.customer,
			    item_code: ct.item_code,
			    },
        	    callback: function(r) {
		            frappe.model.set_value(cdt, cdn, "description", r.message);
	                }
        })
    });
});
1 Like
5

This feature should be contributed. Extend the original get_item_details and send a pull request.

6

I’ll do. I also have a similar process to fetch multi-lingual Terms and Conditions.

7

A child table will be needed on the Item doctype

image.png948Ă—440 10.7 KB

8

If we integrate this as part of the core, then I won’t spend too much time fixing my issue.
I’ll be working on the pull request instead. I will be away for a couple of days, I will work on this as soon as I come back.

1 Like
9

Anything that you think is useful to a lot of users, should be contributed. We don’t want to fragment the product into 100s of “apps” like Odoo

10

Ideally, I think we should completely replace the current Description field by a child table, like in the above picture, but that would involve a lot a modifications. It would also involve a script to copy the current description into the child table.

Of course, adding the child table while leaving the current Description field in place would be much easier. The current Description field could also become the description for the Company’s default language, and the child table would be used only to add non-default languages.

What are your thought on this?

Thank you

11

We are ready to make modifications to enhance the multilingual side of ERPNext, but I would appreciate to get input from the community about the direction to take.

About Item description, I think the best approach would be to completely replace the current description field by a child table, as explained above

Terms and Conditions could also benefit from a similar treatment. We could go a bit further and add some “filters” or “categorization” to them, like Country and Customer Group, on top of language. A bit like the Pricing Rules, but for Terms and Conditions.

Emails would also need to be built around the customer / supplier language, not the currently logged-in user.
Standard Replies also need to receive a Language field.

Please share your thoughts about the project!

Thank you

Bernard

2 Likes
12

@lefebvre_bern thanks for taking the initiative.

I think the table should be in addition to the current description field so that it does not change for most users (also is backward compatible)

We would have to do the same for terms and conditions.

1 Like
13

Hi @rmehta!

I’m here, to put an update on the discussion!
Recently I joined the @lefebvre_bern team, so we I worked developing that feature for ERPNext.

I developed a very small prototype but with an high impact in Frappe and ERPNext
The main concept of the feature is based on a Role, and the fact that Controls are present everywhere in the application, so we are dealing the main idea, that multilingual description should be contextual.

We applied an icon over the label of certain fields like the image below

Image1
Image1941Ă—287 14.4 KB

A pop-up show up, to user enable the translation

Image2
Image2607Ă—563 14 KB

The major issue that we found is:

Some features needs to be translated in a record level, for example, if we want to apply for example this feature at “Standard Reply” it’s unable to apply the translation, due the record don’t have any translation enable.

So, I’m here to ask how we can go ahead with that feature, using the standard solutions included in Frappe.

How we can join forces to enable that translation, in the templated informations in frappe?

8 Likes
14

@max_morais_dmm I love what you did there. This really needed addition. I just have two suggestions:

  • The current design having an icon over each field where the user click, get a pop up, choose target language, then enter the translation, seems like really time consuming if you want to translate each field in the form, what if:
    – Add translate dropdown menu in the top of the form, the dropdown shows
    ----1- languages already translated, where clicking any of them allows you to edit translation
    ----2- add new translation, when click shows a popup asking for the target language.
    – when adding new translation, the source language value will be in a label on top or under its field, and the field will be cleared ready to enter the translation, and if the user leaves the field empty then its value will be the same as source language.
    This way you can translate the whole form at once.
  • I think each field should have a property “is translatable” as I would assume there are some use cases where you don’t want a certain field to be translated
1 Like
15

@ganas that’s an initial prototype, I’m being playing with the options to turn it easy to the end user, and I agree with you that the actual behavior is a time consumer, by the way, is more contextualized, than the active translations :wink:

I agree about translatable field, but after discuss some certain situations, I think the best approach is go trought the fields types, is less one configuration, given to you see that icons, you need an specific role too, called “Translator”.

The major issues are the fetches in the code that aren’t not translated today, so, we need to think a bit more, on where to put that changes, to prevent a full refactor in an large among of places.

2 Likes
16

Great initiative!
Have you considered implementing some kind of .csv import/export? That would facilitate the process.

17

@max_morais_dmm good to have you back :smile:

Lets implement this specifically for Item Description. Maybe a new child table in the Item Doctype that can be linked to a language (?). Will be happy to merge that PR

I think it will be hard to make a generic tool.

2 Likes
18

I’m really in need of this feature too. We’re located in Switzerland where people speak four different languages. Especially in Europe this is crucial for an ERP system.
It’s most important for product description, but would be nice for product name too.

Speaking of products: Where do you see the main difference between description and name? Because in the search fields for products, for example when adding product items to a quotation or an invoice, the auto-complete always shows both name and description. This always looks a bit stupid, considering name and description are often the same content.

2 Likes
19

Is there a pull request laying around somewhere, so I could play with it?

20

@Andy, first!
We are glad that it will help others!

We are dealing the changes in frappe to release the changes.

No - Item name is not same of description, because, item name can be something silly

eg:

Item Code: SH00343
Item Name: Shoes # 13
Item Description: Shoes size 13
Color Red:
Brand Nike
Model: 894-45949-2017

The major difference between Item Name and Description, is that one is short, and another shold be detailed!

1 Like