Hello Frappe community,
My proposal below was already created on Github. I am sharing here for your valuable input, validation, and support.
This proposal addresses the existing limitations in the Frappe Framework’s multilingual support and suggests a comprehensive overhaul to enhance its functionality, particularly for dynamic content such as item names, item group names, and descriptions.
Is your feature request related to a problem? Please describe.
The current method in Frappe for handling multiple languages, which relies on wrapping the multilingual text with underscore and parenthesis, is not practical for content-based translations, such as names and descriptions of Website Items, and Item Group names. While the existing method may be adequate for static labels or translations that are done only once, it is not efficient for dynamic content that is subject to frequent changes by users.
Current Issues with Multilingual Support:
- Inefficiency with User-generated Content: Whenever there’s a small change in the original text (like removing a trailing space) its available translations become invalid. Besides, it requires a complicated process involving several steps to get it translated again: clicking an icon, searching for the new language, and entering the new translation.
- Challenges with Translating HTML-Embedded Content: The process of translating content that includes HTML tags (like description fields) under the current method is notably inefficient. Precise duplication of HTML tags in the translated text is required, which not only adds complexity but also increases the potential for mistakes.
- Storing Invalid Translations: Minor changes in content necessitate complete re-translation. Thus, it leads to an accumulation of outdated translations in the database. Consider translating the name of a ‘Website Item’ - if the original name contains a type error or is changed for marketing purposes, each change requires the creation of a new translation entry and not updating the existing one.
- Performance issues: For example, to develop a search function that works per the user language, it requires to search in the translations table, find the matched text, retrieve its source text, and then search for the source text in the original table.
- Ambiguity in Translation of Common Terms: For instance, in my experience while using the Frappe Framework for a Web Store catalog, the fruit ‘orange’ was translated as ‘Valencia Orange.’ However, in another context, where the product was a T-Shirt, its color was also translated as ‘Valencia Orange’.
- Lack of Easy Language Switching: Currently, the Frappe Framework lacks a straightforward and efficient mechanism for managing translations of different docfields simultaneously. Desk users face a significant challenge in viewing and handling translations across various fields. The framework needs an enhancement that allows seamless toggling between languages for different fields within the same document.
Describe the solution you’d like
This proposal outlines a structured approach to introduce multi-language support for dynamic content within the Frappe Framework. The core idea is to maintain a separate database table for fields marked as multilingual. The table can be called tabMultilinguals, similar in concept to the tabSingles but designed for storing translations from fields across doctypes. This approach is similar to the concept used by CS-Cart, as detailed in their developer guide.
Structure of the Multilingual Table in Frappe Framework:
name: Serves as the Primary Key for the table.
doctype: Refers to the name of the doctype or its corresponding table name (e.g., tabDoctype Name). This column links the multilingual content back to its relevant doctype.
Reference: Acts as a Foreign Key that links to the doctype’s primary key, typically represented by the name field in the doctype’s table.
lang_code: Dedicated to storing the language codes (such as ‘en’ for English, ‘es’ for Spanish, etc.). This column identifies the language of the translation.
value: Stores the actual translated value of the field corresponding to the specified language_code.
New ‘Multilingual’ Property Setter for docfields of the supported types (data - text):
Add a new checkbox named ‘Multilingual,’ similar to the existing ‘Translatable’ checkbox. This would act as a toggle for enabling multilingual support for specific fields. When this checkbox is enables, the Framework will refer to the field value from the tabMultilingual table as per the language selector described below.
Desk Interface Adaptation for Language Selection:
Introduce a language toggle feature at the top of the doctype form view within the desk interface, facilitating an easy switch between different languages. This feature is designed to enhance user experience in multilingual content management. When the form is viewed in English and a specific field lacks a corresponding ‘en’ entry in the multilingual table, the system will default to displaying values from the primary doctype table. Conversely, when a user switches to another language and there is an existing entry in the multilingual table for the field in that language, the form will fetch the fields’ values from the multilingual table for the selected language. This process ensures a more efficient and seamless language transition, enabling users to view and manage content in various languages with just a single click.
Retrieving values for docfields with Multilingual:
When a user accesses a doctype item, the Frappe Framework will automatically retrieve data for fields marked as ‘Multilingual’ from the tabMultilingual table, corresponding to the language currently selected at the top of the form.
If the display language is changed by the user, the page will refresh to update the values of the relevant fields. It will fetch these updated values from the tabMultilingual table based on the new language selection.
Fallback to Default Values:
In instances where the tabMultilingual table does not contain values for a particular language, the framework will default to displaying values from the primary doctype table. This ensures that there is always content available for display, regardless of the completeness of the translations.
Saving Updated Multilingual Content:
When a user modifies and saves a field that is marked as ‘Multilingual’, and the language in use is different from the system’s default language, the updated value will be saved in the tabMultilingual table. This update will be associated specifically with the language in which the edits were made.
Why this change:
If the Frappe Framework is looked by its founders as a tool for maintaining and developing ERPNext, the necessity for advanced multilingual capabilities might not be immediately apparent. However, when considering Frappe as a versatile platform for creating sophisticated web applications and mobile backends by the developers around the world, this feature becomes not just an enhancement; it’s a fundamental requirement for internationalization and catering to bilingual or multilingual cultures.
What we can provide:
- Code Development: Our team is prepared to actively participate in the coding efforts to implement this feature. But guidance from Advanced Developers may be required.
- Design and Mockups: We will provide detailed mockups illustrating the expected UI changes.
- Sponsorship: We are also ready to offer financial sponsorship. This support underscores our commitment to this enhancement and its importance for the broader Frappe community.
For a clearer understanding of the concept, we refer to a video demonstrating similar functionality in CS-Cart. This video shows how to change the content language and at the end of the video we show how the primary display language can be changed (the one that is already available in Frappe).
https://github.com/frappe/frappe/assets/17312481/292e836d-2965-4468-8b6e-379e66bf42f3