[FEATURE] Introduce API v3 support for glossaries#493
Open
[FEATURE] Introduce API v3 support for glossaries#493
Conversation
54a8467 to
607d487
Compare
607d487 to
78422ea
Compare
3f0d558 to
ca183ca
Compare
81eacb2 to
6b61889
Compare
6b61889 to
0fffc14
Compare
Documentation renderingYou can find files attached to the below linked Workflow Run URL (Logs). Please note that files only stay for around 5 days! |
f25e846 to
af1199f
Compare
dad916c to
410b077
Compare
In preparation of switching DeepL TYPO3 extensions to API v3 support, it is necessary replacing the old `Translator` to the new `DeepLClient`, which holds the new features introduced.
The new API v3 changes the behaviour in glossary handling completely. However, the support for v2 is not dropped for the moment, but will be. As it is more simple to maintain only one functionality for glossaries, deprecate the old methods.
Add the new muli lingual glossary methods to the `ClientInterface` and set the old ones deprecated. The deprecation is done because supporting API v2 and v3 does not make sense and should be skipped soon. Only kept until addon implementation has been aligned to this.
Due to ongoing issues and not working with semver by deepl-php API,
we need a possibility to harden our implementation against the DeepL PHP
API. This is done by the new introduced `DeepLClientInterface.php`
mirroring the official `DeepLClient`.
This helps to detect changes inside the DeepL PHP API and update the
extension itself, if needed.
Besides, the complete registration of the `DeepLClient` is made
auto-configurable to ensure DI for the DeepLClient connection.
The positive side effect on this change is the drop of the
`test_extensions_override` and the `PHPMock` from the functional tests,
as the DI load now is given even for the test instances and against the
mock server.
To achieve the goal of a full Dependency injection, the `Configuration`
has to be changed, too, to allow the override for headers and the server
URL.
With this change, the PHP mock and the `test_services_override` could
be easily dropped, as the Client is now automatically set up.
Due to the changes for the injection of the DeepL client, the internal
unit test ClientTest.php was removed completely, as the only goal was to
check the exceptions being thrown correctly. With the Dependency
Injection of the DeepLClient, this is no longer necessary.
Side-change: Removed `helmich/php-json-assert`, as the trait was
implemented, but unused.
Used commands:
```shell
Build/Scripts/runTests.sh -s composer remove --dev \
helmich/phpunit-json-assert \
php-mock/php-mock-phpunit
```
For a better overview and encapsulation of functions according to the DeepL API, the internal `Client`, used as wrapper to the official API, is split into dedicated functional parts. The respective Interfaces for `Usage` and `Translator` were introduced times ago, and now this will take effect by defining clients for their use cases. The Services needing the CLient were adopted to the new interfaces to keep functionality `as-is`. As the `Client` was set to final and therefore was not extendable, this change should have no unwanted side effect to other extensions building up on `deepltranslate_core`. This was needed to split out the Glossary functionality completely from the `deepltranslate_core` and only define the Interfaces for Glossary API v2 and v3. The functionality of glossary management is moved into `deepltranslate_glossary` as it's unused inside `deepltracnslate_core` and a dedicated functionality should be handled inside the respective extension.
fd2aa7d to
fc08736
Compare
sbuerk
pushed a commit
to web-vision/deepltranslate-glossary
that referenced
this pull request
Apr 21, 2026
`EXT:deepltranslate_core` refactors the DeepL client structure shared across all `WebVision DeepL Ecosystem` extensions [1]. This prepares future support for `Glossary API v3`, including multilingual glossaries, bidirectional synchronization, and import/export capabilities. Enhanced glossary support is a highly requested feature and will be delivered in a follow-up change. For now, this patch restores the `Glossary API v2` implementation to ensure a working baseline compatible with TYPO3 v13 and v14. Next-generation glossary integration will be introduced as a separate feature in a minor release of `deepltranslate_glossary`. [1] web-vision/deepltranslate-core#493
fc08736 to
7bb064a
Compare
This change does a tabula rasa throughout the prefvious change and `EXT:deepltranslate_core` in general having streamlining of dependency injection attribute usages and definition in mind.
7bb064a to
f1c7084
Compare
sbuerk
pushed a commit
to web-vision/deepltranslate-glossary
that referenced
this pull request
Apr 22, 2026
`EXT:deepltranslate_core` refactors the DeepL client structure shared across all `WebVision DeepL Ecosystem` extensions [1]. This prepares future support for `Glossary API v3`, including multilingual glossaries, bidirectional synchronization, and import/export capabilities. Enhanced glossary support is a highly requested feature and will be delivered in a follow-up change. For now, this patch restores the `Glossary API v2` implementation to ensure a working baseline compatible with TYPO3 v13 and v14. Next-generation glossary integration will be introduced as a separate feature in a minor release of `deepltranslate_glossary`. [1] web-vision/deepltranslate-core#493
sbuerk
pushed a commit
to web-vision/deepltranslate-glossary
that referenced
this pull request
Apr 23, 2026
`EXT:deepltranslate_core` refactors the DeepL client structure shared across all `WebVision DeepL Ecosystem` extensions [1]. This prepares future support for `Glossary API v3`, including multilingual glossaries, bidirectional synchronization, and import/export capabilities. Enhanced glossary support is a highly requested feature and will be delivered in a follow-up change. For now, this patch restores the `Glossary API v2` implementation to ensure a working baseline compatible with TYPO3 v13 and v14. This is based on the refactoring inn `EXT:deeptranslate_core` and the dedicated, splitted client implementation, and opens the ability to deal with the Glossary API versions directly within `EXT:deepltranslate_glossary` regarding interfaces and client implementation. That reduces roundtrips in the future between these two extensions. [1] Next-generation glossary integration will be introduced as a separate feature in a minor release of `deepltranslate_glossary`. [1] web-vision/deepltranslate-core#493
sbuerk
pushed a commit
to web-vision/deepltranslate-glossary
that referenced
this pull request
Apr 23, 2026
`EXT:deepltranslate_core` refactors the DeepL client structure shared across all `WebVision DeepL Ecosystem` extensions [1]. This prepares future support for `Glossary API v3`, including multilingual glossaries, bidirectional synchronization, and import/export capabilities. Enhanced glossary support is a highly requested feature and will be delivered in a follow-up change. For now, this patch restores the `Glossary API v2` implementation to ensure a working baseline compatible with TYPO3 v13 and v14. This is based on the refactoring inn `EXT:deeptranslate_core` and the dedicated, splitted client implementation, and opens the ability to deal with the Glossary API versions directly within `EXT:deepltranslate_glossary` regarding interfaces and client implementation. That reduces roundtrips in the future between these two extensions. [1] Next-generation glossary integration will be introduced as a separate feature in a minor release of `deepltranslate_glossary`. [1] web-vision/deepltranslate-core#493
sbuerk
pushed a commit
to web-vision/deepltranslate-glossary
that referenced
this pull request
Apr 23, 2026
`EXT:deepltranslate_core` refactors the DeepL client structure shared across all `WebVision DeepL Ecosystem` extensions [1]. This prepares future support for `Glossary API v3`, including multilingual glossaries, bidirectional synchronization, and import/export capabilities. Enhanced glossary support is a highly requested feature and will be delivered in a follow-up change. For now, this patch restores the `Glossary API v2` implementation to ensure a working baseline compatible with TYPO3 v13 and v14. This is based on the refactoring inn `EXT:deeptranslate_core` and the dedicated, splitted client implementation, and opens the ability to deal with the Glossary API versions directly within `EXT:deepltranslate_glossary` regarding interfaces and client implementation. That reduces roundtrips in the future between these two extensions. [1] Next-generation glossary integration will be introduced as a separate feature in a minor release of `deepltranslate_glossary`. [1] web-vision/deepltranslate-core#493
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In preparation of the glossary usage of DeepL API v3 some structural changes
needed to be applied, before the main work could be done in deepltranslate_glossary.
This pull request prepares the changes.
Split one client into dedicated interfaces
Instead of using only one client wrapper for communicating with the
DeepL API, a basic abstract client is now made, which is the basic for
all other implementations across DeepL.
New introduced interfaces:
WebVision\Deepltranslate\Core\Client\DeepLClientInterfaceMirrors the official DeepL PHP API [1]. This helps to identify changes
inside the DeepL API, which will be made by the DeepL team even on minor
level, not correctly following semver.
WebVision\Deepltranslate\Core\ClientInterfaceThe main interface for all usages against the DeepL API and extendable
through other interfaces allowing use case specific implementations.
WebVision\Deepltranslate\Core\UsageInterfaceExtends the ClientInterface and provides methods for fetching usage
statistics from the DeepL API
WebVision\Deepltranslate\Core\TranslatorInterfaceExtends the ClientInterface with a method skeleton needed for DeepL
translations.
WebVision\Deepltranslate\Core\GlossaryV2InterfaceProvides method skeletons for the old DeepL API v2 glossary
implementation. THis interface is deprecated and will be removed as soon
as DeepL drops API v2 support.
WebVision\Deepltranslate\Core\GlossaryV3InterfaceInterface for the new DeepL API v3 multilingual glossary, which now is
persisted.
DeepLClient
This client is now autowired and autoconfigured by PHP Attributes and
gets configuration from the ConfigurationInterface injected. This makes
the class auto loadable without further configuration.
It implements the DeepLClientInterface and extends the official
DeepLClient.
Other changes
In favour of the new configuration API inside DeepL Translate core the
former php-mock for the Client for test usages is no longer needed.
Therefore, the AbstractDeepLTestCase is adopted to fit the new
structure, and the mock together with the mock instantiation is removed.
In this step, the
test_services_overrideextension is no longer neededand therefore removed.
Tests were streamlined, using a global configuration in all cases to
improve stability and maintainability.
In preparation to more flexibility against the DeepL API, a config file
ext_conf_template.txtwas added to allow more configuration. This iscurrently working, but not finished yet and needs more testing and
documentation, before the feature is officially announced. Currently,
this is internal only and code could change without further notice.