You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Multilingual glossary cannot be created from CSV correctly #70
When calling createMultilingualGlossaryFromCsv it is required to pass the sourceLanguageCode and targetLanguageCode parameters, which is weird, since Multilingual Glossaries themselves have no source and target languages.
The parameters are passed on to createGlossaryFromCsvInternal, which creates a glossary with one single dictionary with the given source- and targetLanguageCode.
So, if I want to create a multilingual glossary from a CSV with 3 language pairs, I can always only select one language pair to be included in the newly created glossary.
Expected behavior:
createMultilingualGlossaryFromCsv should not accept the sourceLanguageCode and targetLanguageCode parameters
createGlossaryFromCsvInternal should iterate through the CSV entries and create dictionaries with all language pairs of the CSV. Those dictionaries should be then sent all to the endpoint, instead of just one.
Yes, the CSV, which you can download from DeepL's web app, looks like this:
So it should create as many dictionaries as there are unique language pairs (left - source, right - target) and then add all the entries to their corresponding dictionaries
Hm, I think our rationale when implementing this was the monolingual equivalent accepting files in the format
Hello,Hallo
Good morning,Guten Morgen
and we wanted to stay compatible with this format. And ideally your use case is less relevant now that glossaries are unified, so ideally you don't need to download glossaries like this anymore. Nevertheless I think we should have a CREATE method that can handle CSV files with 4 columns, I can add it in the next release.
Ahh I see, i thought the fromCsv method was implemented with the thought of importing the DeepL web glossaries.
What do you mean by
ideally your use case is less relevant now that glossaries are unified, so ideally you don't need to download glossaries like this anymore.
? Afaik glossaries are not shared between deepl web and the API yet, this is why i needed the CSV export from deepl web and CSV import into the deepl API.
But I do agree there should be a CREATE method which can handle 4 columns :)
Activity
JanEbbing commentedon Jun 18, 2025
How would you pass the language pair information for the entries? By having the CSV have 4 "columns", e.g.
?
MTSxoff commentedon Jun 18, 2025
Yes, the CSV, which you can download from DeepL's web app, looks like this:
So it should create as many dictionaries as there are unique language pairs (left - source, right - target) and then add all the entries to their corresponding dictionaries
JanEbbing commentedon Jun 18, 2025
Hm, I think our rationale when implementing this was the monolingual equivalent accepting files in the format
and we wanted to stay compatible with this format. And ideally your use case is less relevant now that glossaries are unified, so ideally you don't need to download glossaries like this anymore. Nevertheless I think we should have a CREATE method that can handle CSV files with 4 columns, I can add it in the next release.
MTSxoff commentedon Jun 23, 2025
Ahh I see, i thought the
fromCsvmethod was implemented with the thought of importing the DeepL web glossaries.What do you mean by
? Afaik glossaries are not shared between deepl web and the API yet, this is why i needed the CSV export from deepl web and CSV import into the deepl API.
But I do agree there should be a CREATE method which can handle 4 columns :)