[IMPLEMENTED] Support more languages for auto-translation

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [x] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

The following languages are not automatically translated: Arabic (any type of Arabic), Hebrew (any type of Hebrew), Korean (any type of Korean), Thai (any type of Thai).

Expected behavior

When clicking on the auto-translate button, the languages mentioned above should have a translated value from the master field

Minimal reproduction of the problem

  1. Add the languages mentioned above to the project (from the settings panel)
  2. In Scheme, add an “input” type of field to the scheme
  3. In Content, add a post and enter “Test” in the field, and click on “All Languages”
  4. Click on Auto-translate
  5. The fields of the languages mentioned above won’t receive an auto-translte value


  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [x ] Cloud version

Version: Cloud version

  • [ ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [x] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge


Not all languages are supported by the translation provider. It is not a bug…

1 Like

Thanks! Is the translation provider is Google? Is there any option to change the provider or support more languages?

At the moment it is deepl: https://www.deepl.com

Thanks. DeepL is good, although a bit limited compared to Google Translate’s API.

Yes, but when I started with it the pricing was better. I can also add a second provider …

That would be awesome, if possible. If there’s an additional cost, maybe it can be added to the usage costs somehow?

I have implemented a new system that supports multiple providers: https://github.com/Squidex/text/tree/master/Squidex.Text/Translations

Thank you, @Sebastian! Is that for self-hosted only or for the cloud one too? We’re using the cloud-based version.

Also for cloud, but it was not deployed…now it is.

Thank you! And is it something we can set from the user-interface or from the back-end? (sorry for all the questions - I’m not the technical person)

I have to configure something and then it should just work.

Awesome! Thank you so much for your prompt support!

You can try it again…

so so cool! It works!

Thank you, this is really great!

1 Like

Question about “Rich Text” field translation.

I understand the reason not to place an auto-translate button for that field because of the issues it can cause to the HTML structure. With that said, I tested it by:

  1. Copying the source code of the rich text field with many different type of strings
  2. Pasting in a “Text Field” which supports localization, and all languages were translated perfectly, except for Arabic and Hebrew (RTL), which makes sense, but not something that should prevent us from adjusting the text in those languages manually

Is there any chance that the “Rich Text” field will support the auto-translate feature? We find this feature one of the best Squidex advantages over other CMS products out there (beyond other amazing features).



Yes, I am planning to work on this. I would like to support markdown and html as well, but it is challenging and I expect the first versions to be buggy.

1 Like

I assume 90% of the time it will be fine, so if that’s “buggy” - I think it will work out :slight_smile:

Thank you!

I already give up on this. It is super complicated.

My naïve approach was to start with markdown and to translate texts,e.g. “# Book” becomes “# Buch” in german. But when you have inline texts with formatting, it is a nightmare, for example when you have a bold text somewhere like “Hello ** friend **” friend, because you cannot isolate the different parts isolated from each other, because they build a sentence.

The only option that would somehow work is a conversion from html or markdown to text and to translate it then. But all the formatting is lost.

From what I saw, the “Text Filed” field works without any issues (after pasting the HTML source code into it), except for RTL languages. I wonder what is the difference?

In this example it’s: Hello World Hello Again