make deepl_client.get_target_languages() accessible without AUTH Key or make other call that does the same w/o AUth key #148

Activity

1. zorbaTheRainy

   changed the title [-]make deepl_client.get_target_languages() accessible without AUTH Key[/-] [+]make deepl_client.get_target_languages() accessible without AUTH Key or make other call that does the same w/o AUth key[/+] on Nov 22, 2025
2. JanEbbing commented on Nov 24, 2025

   

   JanEbbing

   on Nov 24, 2025

   Last edited by JanEbbing

   Contributor

   More actions

   I would like to call this {deepl_client.get_target_languages()} when error checking my program's inputs, before I do any actual AUTH_KEY related activities.

   What is your higher level goal? I don't think we want to expose an API point on the open internet that requires 0 auth.

   Are you trying to see if the DeepL API is up? Are you trying to initialize your application before a user puts in an API key?
   For the latter, you could e.g. hardcode a starting list of languages you know we support, then as soon as the user puts in their API key kick off a background process to get the languages we currently support, and asynchronously update the list of languages you offer to the user.
3. zorbaTheRainy commented on Nov 24, 2025

   

   zorbaTheRainy

   on Nov 24, 2025

   Author

   More actions

   I would like an official version and non-Auth-Key programmatically available version of the DEEPL_LANGUAGES variable that I don't have to maintain.
   I could just query DeepL and get the one-true-source-of-truth.

   I would be perfectly OK with a public URL that returns a text list of target_languages. Something I could get with curl. You know like some have a http://www.myprogram.com/version URL that returns the current version number of the program (plain text "2.3.4"). For example, https://nxfilter.org/curver.php
   Admittedly, this may be a request for DeepL's web team, not the API team.

   My basic flow is

   1. Read config file
   2. Validate config vars (this is where validating the target_languages() would be called, but I haven't asked for an AUTH Key yet)
   3. If all is OK, then read the Auth Key.
   4. Proceed to, use API

   
   def get_valid_deepl_target_lang(lang_code: str) -> Optional[str]:
       """
       Validate and normalize a DeepL target language code.
       Can take code or language name, if the same as in the DeepL docs.
       https://developers.deepl.com/docs/getting-started/supported-languages#translation-target-languages
   
       Args:
           lang_code (str): Language code to validate.
   
       Returns:
           Optional[str]: Valid DeepL code, or None if unsupported.
       """
   
       # https://developers.deepl.com/docs/getting-started/supported-languages#translation-target-languages
       DEEPL_LANGUAGES: Dict[str, str] = {
           "AR": "Arabic",
           "BG": "Bulgarian",
           "CS": "Czech",
           "DA": "Danish",
           "DE": "German",
           "EL": "Greek",
           "EN": "English",  # unspecified variant for backward compatibility; we recommend using EN-GB or EN-US instead)
           "EN-GB": "English (British)",
           "EN-US": "English (American)",
           "ES": "Spanish",
           "ES-419": "Spanish (Latin American)",
           "ET": "Estonian",
           "FI": "Finnish",
           "FR": "French",
           "HU": "Hungarian",
           "ID": "Indonesian",
           "IT": "Italian",
           "JA": "Japanese",
           "KO": "Korean",
           "LT": "Lithuanian",
           "LV": "Latvian",
           "NB": "Norwegian (Bokmål)",
           "NL": "Dutch",
           "PL": "Polish",
           "PT": "Portuguese", # (unspecified variant for backward compatibility; we recommend using PT-BR or PT-PT instead)
           "PT-BR": "Portuguese (Brazilian)",
           "PT-PT": "Portuguese (European)", # (all Portuguese variants excluding Brazilian Portuguese)
           "RO": "Romanian",
           "RU": "Russian",
           "SK": "Slovak",
           "SL": "Slovenian",
           "SV": "Swedish",
           "TR": "Turkish",
           "UK": "Ukrainian",
           "ZH": "Chinese (Simplified)", #  (unspecified variant for backward compatibility; we recommend using ZH-HANS or ZH-HANT instead)
           "ZH-HANS": "Chinese (simplified)",
           "ZH-HANT": "Chinese (traditional)"
       }
   
       # Exceptions
       if lang_code.strip().lower() in ("zh-cn", "zh", "chinese (simplified)"):
           lang_code = "zh-hans"
       elif lang_code.strip().lower() in ("no", "norwegian"):
           lang_code = "nb"
       elif lang_code.strip().lower() in ("en-ca", "en-ph"):
           lang_code = "en-us"
       elif lang_code.strip().lower() in ("en", "english", "en-au", "en-nz", "en-za", "en-in", "en-ie", "en-sg", "en-hk", "en-uk"):
           lang_code = "en-gb"
       elif lang_code.strip().lower() in ("pt", "portuguese"):
           lang_code = "pt-pt"
   
   
       # Normal processing
       code_format = lang_code.strip().upper()
       name_format = lang_code.strip().lower()
   
       for code, name in DEEPL_LANGUAGES.items():
           if code_format == code.upper() or name_format == name.lower():
               return code
       return None
   
4. JanEbbing commented on Nov 27, 2025

   

   JanEbbing

   on Nov 27, 2025

   Contributor

   More actions

   But what do you need this for? You cannot translate without an auth key anyway. As I suggested above, the work required for this is nontrivial (as we'd need to secure such an endpoint against abuse), so I'm trying to understand how useful this would actually be to users. If it's just about offering a dropdown in a UI before a user entered an API key, I think there are better solutions.
5. zorbaTheRainy

   closed this as completedon Nov 28, 2025