Uploaded image for project: 'translate5'
  1. translate5
  2. TRANSLATE-2357

introduce DeepL config switch "formality"

XMLWordPrintable

    • Critical
    • Hide
      The "formality" deepl api flag now is available as task import config.
      More about the formality flag:

      Sets whether the translated text should lean towards formal or informal language. This feature currently works for all target languages except "EN" (English), "EN-GB" (British English), "EN-US" (American English), "ES" (Spanish), "JA" (Japanese) and "ZH" (Chinese).
      Possible options are:
      "default" (default)
      "more" - for a more formal language
      "less" - for a more informal language
      Show
      The "formality" deepl api flag now is available as task import config. More about the formality flag: Sets whether the translated text should lean towards formal or informal language. This feature currently works for all target languages except "EN" (English), "EN-GB" (British English), "EN-US" (American English), "ES" (Spanish), "JA" (Japanese) and "ZH" (Chinese). Possible options are: "default" (default) "more" - for a more formal language "less" - for a more informal language

       

      A DeepL-specific switch in the configuration should determine, what "formality"

      value is used for translation with DeepL.

      By default "default" should be used.

      This should be overwriteable on client and task-import-level, but not on task level.

      See https://www.deepl.com/docs-api/translating-text/ the switch "formality".

          [TRANSLATE-2357] introduce DeepL config switch "formality"

          Marc Mittag [Administrator] added a comment -

          Hi Aleks,

          bitte ändere die Überschrift der Config-Option in:

          DeepL api parameter: language formality

          Vielen Dank!

          Marc Mittag [Administrator] added a comment - Hi Aleks, bitte ändere die Überschrift der Config-Option in: DeepL api parameter: language formality Vielen Dank!

          Thomas Lauria added a comment -

          aleksandar In that cases the config must come from outside as parameter. Where is the first possible place where the task (and its config) exist?

          In which cases this parameters are used? Only in querying context? If yes we should consider to introduce a flexible "config" parameter in the query/translate/search methods - or a setConfig(config) method on the connector itself. This setConfig receives the config instance (in that case with the task specific stuff loaded) and internally the connector can get the configs it wants. OpenTM2 the showMulti, DeepL the formality and so on.

          Do we have the task instance where the connector is instanced?

          Thomas Lauria added a comment - aleksandar In that cases the config must come from outside as parameter. Where is the first possible place where the task (and its config) exist? In which cases this parameters are used? Only in querying context? If yes we should consider to introduce a flexible "config" parameter in the query/translate/search methods - or a setConfig(config) method on the connector itself. This setConfig receives the config instance (in that case with the task specific stuff loaded) and internally the connector can get the configs it wants. OpenTM2 the showMulti, DeepL the formality and so on. Do we have the task instance where the connector is instanced?

            aleksandar Aleksandar Mitrev
            marcmittag Marc Mittag [Administrator]
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: