Ahem.. It does work... When language dependent fields contain the appropriate information.
There are now four options in that list: language_id, language_code, language_id_only, and language_code_only.
Choosing either of the first two offers a preference... The preference is whatever is selected, but if it doesn't exist then the other is used. The two options ending in only will pull information from the import file *only* from the language dependent fields that have that identifier.
So.. It is now possible that an import file could have for example v_categories_name_1 and v_categories_name_en or it could contain either of these. But, the question becomes, when importing the file, which field should be used? Ideally, they would both contain the same information, but we all know that is not going to happen consistently. We also know that former users of this plugin have become accustomed to the _1 style. For those that have upgraded from a previous installation (say 4.0.36 where this feature was first initiated), the default was language_code even though that was not fully implemented throughout. Again, the idea was if _en existed then it would use that field, but if not, then it would attempt to use _1.
What really should have happened is that some level of notification be made about the situation. I thought that I had something for this situation, but based on the above report that does not appear to be true. Even after the extensive testing that I did, it seems I missed a portion of user response. Further it looks like I set the default export to use the 'id' so that leads to the issue you (and likely others experienced).
I previously had the import default to language_code so that if a file happened to use _en then it would offer preference to that field. Then in my testing, I realized that if one chose to delete the _1 column and had language_id set, it would still try to populate with the content of the field ending in _en.... Had some options... 1. Only "choose" between the two fields when both fields are present and ignore the other field if only one is present, 2) add a second set of options where data is populated only from the field type designated and to allow the preference with fallback option to continue/exist or 3) leave it alone and advise people to delete all occurrences of a field if it is not to be updated (I obviously didn't like this option because I didn't keep it that way).
For long time users, I expected that the configuration information and guidance would be helpful enough to change that setting as necessary, it was my goal for new users to be exposed to the language_code (though keeping/making the default export as language_id doesn't do that in the least).
So, like said a little before, need to provide another update, good feedback on the issue thank you.
Although not yet set in stone, my initial thought for this is to modify the default export to the language_code and keep the default import as language_code_only... Feedback/input?
Bookmarks