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

Glossary ID has to be added in typoscript #41

Open
tw-wolfgang opened this issue Aug 7, 2024 · 2 comments
Open

Glossary ID has to be added in typoscript #41

tw-wolfgang opened this issue Aug 7, 2024 · 2 comments

Comments

@tw-wolfgang
Copy link

We discovered that glossaries only work if the ID is added in typoscript (like described in https://docs.typo3.org/p/dmitryd/dd-deepl/12.7/en-us/Configuration/TypoScriptReference/Setup.html).
The solution works fine, but makes it very uncomfortable to "edit" glossaries. As deepl allows no editing of glossaries, every "editing" means to remove the existing glossary and upload a new one. This leads to an new ID which then forces you to edit the typoscript.
While editing glossaries is a task that every editor should be able to do, editing typoscript is definitly not.
So in the current state there is no effective way for editors to update glossaries.

Deepl suggest to use the name as identifier for "editing" glossaries (https://developers.deepl.com/docs/api-reference/glossaries). Could this also be an option here? Would be nice if you could also use the name as an identifier, as it can stay the same after every upload.

@kauz56
Copy link

kauz56 commented Nov 21, 2024

@tw-wolfgang Check these:
kauz56@76ebd90
kauz56@e576ac9

I believe these solve your issue, without introducing a breaking change.

Firstly we autodetect the first matching glossary (by lang pair) directly from the API, circumventing the need to define glossaries in typoscript. Secondly we add a "Replace glossary" button. The ID will still change, but the autodetection makes this a non issue. The only case where this doesn't work is when you have multiple page trees with differing glossaries, which I would say is likely an edge case.

@tw-wolfgang
Copy link
Author

@kauz56 thank you, works just fine! This makes using the glossaries much smoother.
Only thing we had to do to make it work was to rewrite

$glossary = $this->glossaries[$key]
to
$glossary = $this->glossaries[$key] ?? null;

in order to avoid following error:

Screenshot 2024-11-22 103214

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

No branches or pull requests

2 participants