The CTSX Google module performs translation via Google Cloud Translation API. Google Translation API supports more than one hundred different languages, from Afrikaans to Zulu. Used in combination, this enables translation between thousands of language pairs.

Installation

Maven is the easiest way to install the module. Add the following dependency to your bundle:

Known Issues

Too many text segments

In case of submitting many contents (such as the whole /travel page includes dependences), an error will be thrown as below. This is known issue as number of submitted segments is over google's threshold.

Thanks. No, I guess it is not required on these three child pages as well then, but it would be helpful if in the installation section of these pages there was a link to the parent page and a note that the CTX module must be installed. Consider that links will send people directly to this page, so they might not be aware of the parent page at first.

As far as I know the only way to work around it is stay under the threshold with small batch sizes. I know that probably isn't easy to estimate when creating them. I will open a ticket and take a look to see if we can make some improvements there.

Hugo Venancio may I ask are you just testing out the module or actively using it? If you are trying to decide which translator to use I can tell you we have put a big effort into Translations.com. Most customers are going with that solution.

Currently i am analysing the possible integration with this module, and i was initially planning to use the Google service (thou i also checked the Microsoft cloud service as well).

However (every day is a new day ) In fact today i got the request from our BUS they would like to use even a different Translation service than the ones supported out-of-box => (deepL): https://www.deepl.com/en/translator

I am actually trying to figure out how exactly we can do it but maybe we will need to create our own Connector based on the CTSX, connecting the this engine's API. The API is basic in fact.

I suppose this is feasible, right ? Obviously it would be at our own effort/responsibility, but technically i don't see anything (at 1st sight) that could be a show stopper.

Sorry for my late reply. We have v3.0.3 of Google translate ready. This should fix the segments issues. Please let me know if you have an issues with it.

As far as the other translator I would say it looks feasible. I would not depend on any classes from our translation modules though. There is a high probability this will go through a major refactoring soon. See
EXCONTRANS-328
-
Getting issue details...STATUS
So either wait for that or try the Google service in the mean time.

The only concern I have would be creating any kind of link between our module and yours. These incubator modules are in a constant state or refactoring and improvement as feedback comes in. So some modules are more mature than others. This would be a module that is still in that improvement phase.

Hi Richard Gange, will these changes also be applied to the version compatible with 5.7, i suppose 2.9-SNAPSHOT ?

We are still on Mgnl 5.7 and we will not upgrade to 6.1 soon, but still planning to use the CTSX on 5.7.

Is it possible to have it there as well ?

And another question is: how stable is Google Translator (in the version compatible with 5.7) ? Is it "stable enough to use it" ? You mentioned in one of your previous comments Mgnl put a lot of effort on Translations.com. Does that mean Google is not stable enough? Cause our business is really pushing either for google or this other provider DeepL, so theoretically the best approach would be google naturally.

I spoke with the developer. We can do that. Please follow the progress on
EXCONTRANS-334
-
Getting issue details...STATUS
.

As far as stability goes, 2.9 is pretty much the same business logic as 3.x. It's the M6 UI changes that required the next iteration to be released. As I said about the incubator, each module has its own state of maturity. I would say this module does work but the code quality (and maintainability) needs improvement. Before this module can take the next step we really need to refactor some of the backend design. There are plenty other customer actively using it and it's quite popular. It's definitely something we will keep improving and maintaining.