Maintain glossary terms during automated translation.

[ghost]

Describe the problem

With the Glossary Weblate offers a way to organize terms that should not be translated. It would be helpful and more consistent, if those term were also fix, when using automated translation with deepl.

Describe the solution you'd like

The new Syntax Feature from issue #6529 could be used, to simply mark all glossary terms with xml before messages are transmitted to the translation service.

Describe alternatives you've considered

No response

Screenshots

No response

Additional context

Appreciating hints, if this is already possible somehow.

[nijel]

Unfortunately, this is not that easy:

1. This will most likely ruin the grammar handling in DeepL and will actually produce worse translations.
2. There can be multiple matching glossary terms.
3. This can't properly handle declination in languages which need it.

What might be more useful to use DeepL glossaries, but it has own set of problems:

1. Very limited language support - DeepL supports glossaries only for a subset of languages.
2. There is limit of 1000 glossaries, what would be easy to reach - 10 projects translated to 100 languages are you are there.

[github-actions]

This issue has been put aside. It is currently unclear if it will ever be implemented as it seems to cover too narrow of a use case or doesn't seem to fit into Weblate.

Please try to clarify the use case or consider proposing something more generic to make it useful to more users.

[nijel]

There is discussion on this topic at #9063 as well.

What I think would be a viable approach is to add an option for glossary synchronization to machinery configuration, this allows to enable it at both project and site-wide level based on user decision. The limit of 1000 glossaries at DeepL makes it unsuitable for site-wide usage on larger instances.

[amq]

People could use multiple deepl api keys for such big instances.

[amq]

This is how I would imagine it:

• Weblate glossaries are synced to deepl on every change, creating one deepl glossary per weblate glossary-language pair
• There is a mapping between weblate glossary-language id to deepl glossary id
• When requesting translations from deepl, relevant glossary id is supplied, if exists

[nijel]

People could use multiple deepl api keys for such big instances.

Using project scoped machinery is way for that.

Weblate glossaries are synced to deepl on every change

The API for glossaries at DeepL supports create/delete glossary only, there is no update. We definitely don't want to do that for every glossary edit in Weblate.

creating one deepl glossary per weblate glossary-language pair

Yes.

[amq]

The API for glossaries at DeepL supports create/delete glossary only, there is no update. We definitely don't want to do that for every glossary edit in Weblate.

Yes, an "update" would do delete and create in background, that's also what deepl suggests. Is a bit clumsy, but it doesn't incur additional costs, so shouldn't be a major problem. For me it wouldn't be a blocker if it doesn't happen on every update, but it would probably actually mean more work, because an additional sync button would be required etc.

[nijel]

I don't want manual sync, but either delayed or daily to avoid wasting resources on both Weblate and DeepL side (this will become more of a problem for huge glossaries).

[github-actions]

Thank you for your report; the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.