How to model multi-language entities or fields?

Get Help
1

Hey all, we’re currently migrating more and more processes to Fibery. Especially topics regarding product development are working really well. Some stuff of our product is customer-facing, for this we mainly use additional rich text fields which also works pretty good.

As our customer base is both english and german, we need to serve both languages in public facing content.

What are you suggested solution?

  1. Currently, we’re using multiple multi-language fields. This setup gets cumbersome really fast. When you have 3 fields which should be multi-language, you’ll need 6 fields for two languages etc. Also the configuration of forms and layouts takes up quite some time (when you want to have one view layout per language).
  2. Another option would be having one entity per language, but I’m not really sure how to correctly link them to each other – as there wouldn’t be one “root” entity which links to all others.

Would love to hear how other teams are solving this :slight_smile:

2

Good question. I will experiment a bit with this and I’ll come back to you if I find something interesting.

3

Hello,

In relation to the fields names, there’s no solution. If you really want to traduce the fields names, you need to duplicate your fields for every languages as you already do. On my case, I choosed to used 1 language for fields name despite some users does not speak or speak less this language.

In relation to the fields content, I do not really see a solution either. If it was possible to dynamically load a formula field by reading Users fields, then we would be able to load the right content language based on the User language. At that point you would have a database with 3 fields : Field name, Language (EN/DE), Content, and a field Language on your Users database (something like that). Then we should be able to match the Field name and Language with the User language in order to load the Content.

Not sure the team will solve this soon.

4

Hello Jonathan1,

I think our current setup with one entity and then an extra field for each combination of field + langauge is fine for now. I know this is probably rather nieche, but if I could wish for a solution it would probably be the possibility to have multiple “variants” for one field, or just multiple languages and then a switch to switch between all of them.

Anyway, current setup is already ok-ish and I only need to create the fields once, so it’s not a very big pain.