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?
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.
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.
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.
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
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?
@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
@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
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.
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.