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:
- Copying the source code of the rich text field with many different type of strings
- 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).
Thanks!
!
!
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 
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
Yes, the reason is that the translation services support html out of the box. I guess I just have to open it for all editors. Can you create a feature request for that?
This topic was automatically closed after 2 days. New replies are no longer allowed.