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

[Feat] Add glossary support for DeepL translation service #86

Open
michafaw opened this issue Mar 6, 2023 · 4 comments
Open

[Feat] Add glossary support for DeepL translation service #86

michafaw opened this issue Mar 6, 2023 · 4 comments
Assignees
Labels
Feature Request New functionality the app doesn't provide yet Size: Small Probably less than 1 week of work

Comments

@michafaw
Copy link

michafaw commented Mar 6, 2023

Problem Statement

My team is using DeepL and would like to use at least two features that are available in DeepL Pro via their "translate text" API: formality and glossary_id. The API doc for that request is here. Currently, it appears that the only option I have in RemafoX is to set the API key for DeepL.

Suggested Solution

Add a text field within the DeepL section under Machine Translation -> API Keys to allow the user to set additional request parameters that will be passed to DeepL when making calls to their translate text API.

Additional Considerations

This would be for advanced use of RemafoX/DeepL, and bad/duplicate input could conflict with RemafoX's existing request parameters. Fixing #83 might be necessary to help users resolve syntax issues caused by these problems.

@Jeehut
Copy link
Member

Jeehut commented Mar 6, 2023

@michafaw Thank you for requesting this feature. I will consider adding a text field for additional options as requested.

@Jeehut Jeehut added Feature Request New functionality the app doesn't provide yet Size: Small Probably less than 1 week of work labels Mar 6, 2023
@michafaw
Copy link
Author

tl;dr - As originally suggested, a single text field for DeepL API parameters makes our use-case possible, but would not be as user-friendly as it could be.

Full post
After further research, it may not be as simple as the single text field I suggested. One of the two parameters we wish to pass is glossary_id, and each source<->target language pair has a different glossary. So the parameters would need to be per language.
There's ways to get around this by modifying the search paths in RemafoX to only include the source and one target language at a time, then set the appropriate parameter string, then trigger translation. The user would need to do this for each language they have a glossary.
Maybe a fuller solution would be instead of a single text field for all languages, there would be one text field for each target language RemafoX detects in the project.

@Jeehut
Copy link
Member

Jeehut commented Mar 15, 2023

@michafaw Thank you for the additional insight. It sounds like glossaries are a feature for themselves and probably need a more deeper integration into the RemafoX workflows, machine translation support only being one of them. But I think it makes sense to tackle them for RemafoX at some point.

@Jeehut
Copy link
Member

Jeehut commented Apr 14, 2023

@michafaw Just want to let you know that I just set the default formality of DeepL prefer_less which should result in informal translations. This matches the behavior of all other translation services and that of Apple in their operating systems, thus I believe this to be a better default. The change will ship with version 1.5.0 in a couple of days. You might want to consider re-translating some of your languages to convert them to the informal style.

I'm leaving this feature request open for the glossary support part that I will have a deeper look into at a later time.

@Jeehut Jeehut changed the title [Feat] Send additional request parameters to DeepL [Feat] Add glossary support for DeepL translation service Apr 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request New functionality the app doesn't provide yet Size: Small Probably less than 1 week of work
Projects
None yet
Development

No branches or pull requests

2 participants