Custom language selection for rendered areas (Schema Fields)

Feature Requests
1

Hi, Sebastian,

Panel users can sometimes be used by users with other native languages than the language usage of the fields created for the panel. therefore, if the label and hints fields in the schema fields are multilingual and there is a language setting for this, for example, I want to make the schema and content fields in the panel available to English and French users. and I assume that I have created all my fields to support these 2 languages. when the user selects one of the allowed languages from the profile section or from one of the usage areas of the site, it would be good if the user could see the titles and descriptions of the schema fields in that language. so we can offer the panel usage for different users. the language selection I am talking about should be a language selection that can be managed differently from the language selection area under the profile, as well as adding and managing languages in the current settings. Because content entries and panel usage are at a different point from each other.

Thanks for all your efforts,
Good work.

2

Sorry, but I am lost, I do not really understand it tbh.

3

Hi Sebastian,

Initially, my goal was to enable multilingual support specifically for the ‘Labels’ and ‘Hints’ fields within the schemas, allowing users to manage data entry fields in multiple languages seamlessly. However, I realize my previous explanation might have been a bit unclear, and after reconsidering the idea, I’ve thought of an even more effective approach.

Currently, Squidex supports English, French, Dutch, Italian, Chinese, and Portuguese as application interface languages. However, if a user wishes to use schema labels or descriptions in a language not supported by the application—for instance, Arabic—this could create usability issues.

While users can contribute new language files through the open-source community, maintaining and managing these contributions could become complex. To address this, I suggest adding an “Application Interface Language” option directly within each application’s settings. This feature would allow users to define custom languages easily, which could then be used specifically for schema Labels and Hints fields.

I’ve included visuals below to clarify this suggestion further.

The languages will be displayed in a listing screen as shown below, allowing users the flexibility to add custom application interface languages. Whenever a user adds a new interface language, they will be responsible for providing translations themselves for each newly added language. Specifically, they’ll need to manually enter the translations corresponding to the default backend and frontend English content.

image
image1507×1344 162 KB

I believe that the data for any newly added language should be stored in the database.

When the user presses edit, the editing screen should appear as follows.

image
image1510×1350 212 KB

This way, users can add a custom interface language for their application directly through the control panel.

Not only that, but this approach also enables multilingual input for schema labels, hints, and similar data entry fields according to the added and active interface languages.

image
image1045×787 24.2 KB

I tried to explain in more detail.
Thank you for everything

4

I really understand the demand for labels and hints (even though I think most users would not maintain that anyway). But I disagree with the panel language thing. I think this is an absolute edge case and it will be difficult to keep up with changes when a new version is released. For me the goal would be to make the translations better to maintain. Perhaps there is a service that can be used so that users can contribute small improvements more easily.

5

I believe that the panel language and the labels and hints fields in the schemas should be synchronized. If you are designing and providing a panel to your customers, I believe this panel should fully support their preferred languages from end to end. It may not be appropriate to leave the entire language management burden solely on you; therefore, this responsibility should be assumed either by us or by the users.

As you mentioned, tracking this process can be challenging. Therefore, it might be beneficial to consider developing a centralized language management interface outside of Squidex’s panel system. Such an interface would function as a common platform used by everyone, listing new language definitions at the top to facilitate their support. Additionally, AI assistance could be employed for translations, with many languages supported by default, and users potentially correcting any errors.

Google had implemented a system like this, where translations are voted on by the community, and the most accurate translation is determined based on the percentage of votes, effectively refining the correct translation. Perhaps a similar community-driven approach could be considered to ensure the accuracy of translations in a centralized system.

In summary, while I am not entirely certain about the exact approach, I firmly believe this is definitely a necessity. The primary priority should be ensuring that fields such as labels and hints in the schemas work seamlessly with multi-language support.