Typo issue - media_lable vs media_label

[addison74]

Exporting the products from a store and taking a look at the columns in the CSV file, I immediately noticed a typo error media_lable.

I searched the OpenMage repository and I found 4 files containing this error

https://github.com/search?q=repo%3AOpenMage%2Fmagento-lts%20media_lable&type=code

Do you consider we should correct this typo? I checked the Magento 2 source code and this error was not found.

[kiatng]

Correcting it is a breaking change, probably not worth it.

[fballiano]

I know about that typo since many years but I'm not sure it's worth fixing, because everybody will have to change their import files if we fix that name.

[pquerner]

What if we accept both keys instead? (And internally map to the typo one)

[fballiano]

good idea! (I didn't have coffee this morning so.. 😅)

[fballiano]

What if we accept both keys instead? (And internally map to the typo one)

I was checking this idea but I think there's a problem, this media_lable is only used in import/export, but if we support both the media_lable and media_label, what if a user has both in their file? also, when we generate an export we have to generate ether one or the other, risking of breaking the export file...

so... IMHO, I'd close this bug and leave it as it is

[addison74]

I pressed the wrong button. I agree that mapping is not the solution. If we make the change then only those who use the same previously exported files would be affected. otherwise, nothing changes in the database.

However, if the CSV file has a wrong column, when the data check is done, it will find out that that column does not exist.

[fballiano]

if an export file is used as import source for another system, that will break it.
my opinion is to leave it as it is.

[addison74]

Changing the OM source code will not create trouble. As I expected, if a file with the old column name is used, by checking the data before import, the error is shown (see bellow). That column is invalid because it does not exist, the header of a column must be changed.

The only problem is that for someone who has learned how to import with that file, there will be a time of confusion until he understands what happened.

If you are more in favor of keeping the current behavior, then I close it.

[fballiano]

those import files can be generated by 3rd party systems that can't be changed easily.
or in case of export files, those can be sent to 3rd party systems, same thing, changing the structure of the CSV just to fix a label is not worth the risk IMHO.

ans most of the times import/export are automated and maybe nobody will see the error

[kiatng]

May be for next branch?

[addison74]

It is not a bad idea for all these mistakes to be corrected in the next branch. Here is another example #2084.

Not to mention the fact that there are phrases in the PHP code that are not corrected and the change in the locale CSV files was preferred. A much-discussed situation is the "Price Alert" module, where if you look at the PHP code, the displayed messages are completely wrong, devoid of logic, but have been corrected in the translation files.

More detail here
#2590
#2585
#2429

[fballiano]

fixing typos in CSV allows us not to break things, fixing it here will break every existing import/export from/to 3rd party systems. most probably run by cron, people will not notice, 3rd party systems are ofter hard to fix.

IMHO not worth the risk, people will not see the line in the changelog and will not fix it preemptively and then they'll discover their image import has been broken for some time.