Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reimplement usage of Google Translate API as a named utility to be able to provide different services #468

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

erral
Copy link
Member

@erral erral commented Sep 29, 2024

Addresses #467

Motivation

The current implementation requires anyone wanting to provide some other external translation service, to override the existing view and do the logic there.

I think that the implementation proposed here is flexible enough to be able to register several different services

Introduced components

A new interface IExternalTranslationService is introduced which has several attributes and methods. This interface should be implemented by a utility registered using zcml for each translation service you want to have.

  • is_available(): to return whether the adapter is available (for instance, is the Google translation API key entered into the control panel?)
  • available_languages(): a list of language pairs (source, target), that this service supports.
  • order: the order in which this adapter will be executed. This way, one can prioritize some services over others.
  • translate_content(content, source, target): the actual function that does the translation call.

I have converted the function that currently calls Google Translate into a utility providing IExternalTranslationService

Strategy

The current browser view that does the call to Google Translate has been rewritten to get all registered utilities that are available.

Then it checks that the adapter supports the language-pair (source, target) translation.

If so, it requests the translation and returns it.

Other solutions I thought of

  • I thought also on creating a ZCML tag just for registering this kind of adapters, but found easier going the adapter way.
  • Another way could be to register adapters instead of utilities.

Documentation

If this is accepted, a documentation PR will be issued from this branch, where this adapter registration has been documented:

Branch: https://github.com/plone/documentation/tree/erral-adapter-registration
Documentation of the adapter: https://github.com/plone/documentation/blob/erral-adapter-registration/docs/i18n-l10n/use-an-external-translation-service.md#using-other-translation-services

Other

I will update the PR with the changes in #462 if/when merged

@mister-roboto
Copy link

@erral thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

@erral
Copy link
Member Author

erral commented Sep 30, 2024

@jenkins-plone-org please run jobs

1 similar comment
@erral
Copy link
Member Author

erral commented Sep 30, 2024

@jenkins-plone-org please run jobs

@erral
Copy link
Member Author

erral commented Oct 2, 2024

@jenkins-plone-org please run jobs

@tisto
Copy link
Member

tisto commented Nov 28, 2024

@erral is this an enhancement or a PLIP?

@erral
Copy link
Member Author

erral commented Nov 28, 2024

As discussed, I don't know if this in itself is a PLIP... it is definetly an enhancement.

Something worth a PLIP would be to integrate these translations options in Volto.

I will add a REST API endpoint to this PR in order to be able to use these translation services, which would definetely help in the volto implementation.

@erral erral changed the title Reimplement usage of Google Translate API as an adapter registration, to be able to provide different services Reimplement usage of Google Translate API as a named utility to be able to provide different services Nov 30, 2024
@erral erral requested a review from mamico November 30, 2024 16:09
not available_languages
or (source_language, target_language) in available_languages
):
translation = adapter.translate_content(
Copy link
Member

@mamico mamico Nov 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO it is better to handle this loop using a try/except pattern, so that that you do not try all the services if you try to translate something like empty text.

class GoogleCloudTranslationAPIFactory:
"""implement the external translation using Google Cloud Translation API"""

order = 999
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An idea might be to define a schema for translation service controlpanel with “enabled”, “order”, “available_source_languages”, and “available_target_languages” fields.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I tried to keep backwards compatibility in thilese changes and that's why I didn't change the controlpanel at all.

But what you say makes total sense. The point is: should we extract the google translate support from p.a.multilingual and put it in an addon?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants