Details
-
Bug
-
Resolution: Unresolved
-
None
-
None
-
Critical
-
Empty show more show less
Description
Problem
DeepL uses nb as language code for Norwegian and in our database we have the following entries for this language:
+-----+---------------------------------+-------+---------+--------------------+-------------+------+---------+ | id | langName | lcid | rfc5646 | iso3166Part1alpha2 | sublanguage | rtl | iso6393 | +-----+---------------------------------+-------+---------+--------------------+-------------+------+---------+ | 262 | Norwegisch | 20 | no | NULL | NULL | 0 | NULL | | 442 | Norwegisch (Bokmal) | 31764 | nb | no | nb-NO | 0 | NULL | | 443 | Norwegisch (Bokmal) (Norwegen) | 1044 | nb-NO | no | nb-NO | 0 | nor | | 445 | Norwegisch (Nynorsk) | 30740 | nn | no | nn-NO | 0 | NULL | | 446 | Norwegisch (Nynorsk) (Norwegen) | 2068 | nn-NO | no | nn-NO | 0 | NULL |
From the table we can see that the major language is no. This produces problems when users are creating DeepL resources ( nb ) and they are expecting those to be matched for tasks with "no" language codes.
This can be fixed if we do internal mapping for those codes (similar as we do in microsoft connector) on connector level.