Reimplement usage of Google Translate API as a named utility to be able to provide different services#468
Reimplement usage of Google Translate API as a named utility to be able to provide different services#468
Conversation
|
@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: 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! |
|
@jenkins-plone-org please run jobs |
1 similar comment
|
@jenkins-plone-org please run jobs |
…ookup, so that extra services can be registered
|
@jenkins-plone-org please run jobs |
|
@erral is this an enhancement or a PLIP? |
|
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. |
11fa5a1 to
94f1de0
Compare
|
@jenkins-plone-org please run jobs |
|
@jenkins-plone-org please run jobs |
1 similar comment
|
@jenkins-plone-org please run jobs |
|
Following my latest comment, I have reworked this PR a bit, completely removing the Google Translate functionality from here and renaming the view that is called from the Because of that breaking change, I have added a PLIP explaining the motivation and the deliverables: |
|
@jenkins-plone-org please run jobs |
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
IExternalTranslationServiceis introduced which has several attributes and methods. This interface should be implemented by a utility registered usingzcmlfor 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
IExternalTranslationServiceStrategy
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
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