Multilingual glossary cannot be created from CSV correctly

[MTSxoff]

Problem:

• 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.

[JanEbbing]

How would you pass the language pair information for the entries? By having the CSV have 4 "columns", e.g.

Hallo,Hello,DE,EN
Hello,Hallo,EN,DE

?

[MTSxoff]

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]

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.

[MTSxoff]

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 :)