Hi!
@yindesu added https://tickets.metabrainz.org/browse/STYLE-2204 - I mostly agree with the suggestion, but wanted to make sure that I’m not missing some important reason why this should be in the barcode field. I think the wording should be something like:
Only one barcode can currently be stored in this field. If a release has add-on codes, store them in the annotation. Similarly, if a release has multiple full barcodes, enter all others in the annotation.
Any opinions?
Don’t know what an EAN-5 add-on code is. But barcodes should be barcodes and nothing else jammed into that box. Looking at the example in the style note it was a typo anyway.
The art shows a clear barcode on its own. 8420565204187 is what a barcode reader would read.
If you look at your screenshot you see another smaller barcode with only 5 digits next to the EAN-13 barcode you quoted. That’s the addon barcode. Because it is also a barcode it’s clear why people get confused and might add that to the barcode field. See also
Since it is only an addon and only exists in addition to the EAN-13 barcode, which is sufficient to identify the product, I agree with the proposal.
As that article says “this is a separate code for pricing”, then it seems clear to keep it as a separate entity.
Just the same as when someone mistakenly puts the French “PM532” price code as a cat no. Data for the annotation. Not really part of the main indexing or identification.
Hey, I’m glad to see this change. This is great! For the message, I suggest something shorter and more direct, like
Enter no more than one barcode in the Barcode field. If the release has additional barcodes, please put them in the annotation.
IMO it’s obvious that barcode (not barcodes) field should contain a single barcode.
I never saw that mistake before, and I believe it was fixed (but there are no release links to check).
It would be nice to be able to set all releases’ barcodes, though, one day:
But maybe not those EAN-5, anyway, as they are not release identifiers, they are price codes, apparently.
Well, the point is to specifically mention the add on ones to clarify they are not part of the main barcode itself (like the edit which caused this implied) 
In any case, it seems we’re mostly in agreement that we did not miss a reason why this should be allowed, so I’ll change the guideline. Thanks!