Cannot import vocabulary translations in "localize mode" (or do anything meaningful) when source language is different from default language

I'm afraid there is a mistake in understanding "Localize mode" specification for CSV import/export module. In "Localize mode" vocabulary terms need to have language "undefined" in order to be localized, that is correct. But this undefined language does not need to coincide with "default language" of the site, but with "source language", which is considered as source for translation strings (or msgid in gettext parlance).

Source language doesn't need to be default language for user content, although this default value in i18n module. You define source language at administration pages /admin/config/regional/i18n/strings and there is a remark:

Language that will be used as the source language for string translations. The default is the site default language.

For my case source language is English (so modules that have English as source language for gettext translation are by default compatible with my Drupal site), but default language for the site itself is Estonian (so that users will be presented content in their preferred language no matter what is the source language at code level).

Now if I export my translated vocabulary with export CSV I get list of translations which both are in English, however in administration pages /taxonomy/term/123/translate I have translated them to Estonian and use them that way all over my site. So I presume the problem is in CSV import/export module and not Drupal i18n module.

Because of that misunderstanding of source/default language I also cannot import my CSV to update translations and I get hit with:

With "Localize" mode, you cannot translate a term into the default language ("et = Estonian"). Term in that language will be the first one on each csv line.

This is not correct. The first one on each CSV line has to be "undefined language" not the default language, the next one in i18n modules is any language different from "undefined language" which is taken as "source language" (more on that later, there is a second mistake in the checks about that too).

However if we take it even further, you can translate strings in "undefined language" into "source language" and this is exemplified by Translation Table module /admin/config/regional/translate/table/taxonomy where it presents me three columns, the first one is "original language" (which, as I understand, means the "undefined" source language), then in second column the first "defined" language that is different from source language, in my case Estonian, the default language of the site, and as third column even once again English as second "defined" language (although it is also the source language in technical sense, but as it can be also translated in locales_target database table, this might mean the presentation layer where spelling mistakes of the programmers are corrected).

So using source language instead of default language as basis for "Localize mode" would be the first step to start following i18n standard for Drupal. Besides code, there are also user instructions that need to be corrected.

The next step might be allowing to import/export undefined language and then all other/defined languages (basically any language that is allowed on system). The point of having undefined source language different from "defined" languages might be reasonable if one uses machine name msgid for the source or considers it a technical "working language" and not the actual presentation language. Otherwise the point of not allowing the source language to be defined would be lost, however I'm not sure if i18n modules actually implement that feature.

But despite all the misconceptions, I was able to use the module to import translations of localized terms if I commented out the checks in taxonomy_csv.import.admin.inc starting on line 1114 "With a localizable vocabulary, terms should have a undefined language." (don't get the point of that at all, is this check actually meant for importing vocabulary terms themselves and not the translations?) and starting on line 1141 "With "Localize" mode, you cannot translate a term into the default language..."

See the attached diff, if interested.