Barcode should be shown and be editable while all adding process

[TerEsper]

Problem

The OFF scanner is bad. It often recognizes barcode digits wrongly, changes its opinion several times per second/scan and as consequence, proposes wrong barcodes for adding to the OFF DB. It can be unclear to random/unregistered users, that recognized digits can be wrong or you can miss that because the difference is in one-two digits only. Right now the only one step where you can check, edit and verify the barcode you add is only the first tab which appears after your scan:

After this tab you don't see the barcode you add. So it doesn't provoke users to double check barcodes (which is really important, because barcodes are one of the main identifiers in the whole DB and it is hard to edit them after they were added to DB and impossible without moderators) and it is not possible even if I want to check that because I'm unsure or understand I forgot to do that earlier. Right now the only one way to do that is cancel all entered data and to start the whole process from the beginning.

Proposed solution

Because of that, it will be helpful to show a barcode that some user going to add to the DB, in every step of add process at the top or in other place and make it editable until it is saved in the DB.

Additional context

https://forum.openfoodfacts.org/t/unstability-of-app-barcode-scanner/2265

[monsieurtanuki]

77730837 and 77387735 are not just unknown products, they are invalid barcodes.

Assuming that the barcode scanner only returns valid barcodes, we have that "undetected invalid barcode" issue only for the search with keyboard.

The first step would be to immediately reject invalid barcodes. Or, if we want to be nice with legacy crap data, try to find it on the server, then, if not found, reject it as invalid anyway.

One step further would be to display the barcode at the "select product type" page, because once we select a type, we create an empty product on the server.

[teolemon]

What I've long wished is that we could take and upload a screenshot of the barcode as it is detected (at least on product addition to avoid overloading the server with photos of barcodes).
This would allow us for ground truth, and the possibility to change it afterwards.
What we could do is make it editable on long-press for everyone, or to logged in users. Making the editability too visible to anonymous users could have unintended side effects.

[monsieurtanuki]

What I've long wished is that we could take and upload a screenshot of the barcode as it is detected

Doesn't sound like a big deal, just a parameter, at least in the mobile_scanner version:

/// This class represents a scanned barcode.
class BarcodeCapture {
  /// Create a new [BarcodeCapture] instance.
  const BarcodeCapture({
    this.barcodes = const <Barcode>[],
    this.image,
    this.raw,
    this.size = Size.zero,
  });

  /// The list of scanned barcodes.
  final List<Barcode> barcodes;

  /// The input image of the barcode capture.
  ///
  /// This is the image that was used to detect the available [barcodes],
  /// not the image from a specific barcode.
  ///
  /// This is always null if [MobileScannerController.returnImage] is false.
  final Uint8List? image;

May have performance impacts.

About barcode change, I'm not a big fan, because we don't do it at all in the rest of the app.
As already mentioned, that's the primary key of all our data, and that's obviously something for very advanced users.

My suggestion of rejecting invalid barcodes would solve 99% of the (keyboard) cases, and could be implemented in 10 minutes.

For scanned barcodes, we can display the scanned barcode image, as suggested in the current message.

[TerEsper]

Do you expect only GTIN retail barcodes to be used/entered? Because in fact barcode is just a technology and it can represent much more values and is not strictly limited as these standards.

Also sometimes there are internal barcodes that still can be recognized by user scaners.

For instance:

Both, Binary Eye and OFF app recognized it as "50213546232419". But in BE I see also it is ITF (non-retail standard), so I pretty much sure this code is not something you expect to be added.

But I don't think it is right to expect, that average user will know the difference

Also: does <> in the app search result mean barcode is invalid? I ask because it is not documented anywhere.

[monsieurtanuki]

@TerEsper At least we may expect 13-digit barcodes to be valid EAN13, mayn't we?

For the record in the 2026-05-21 data dump for food:

• 4,526,728 lines
• 4,226,665 are 13-digit barcodes (93,37%). Among them, 98.97% are valid (4,183,192)
• 222,695 are 8-digit barcodes (4.92%)

Your assumption about <barcode> is correct: we display valid barcodes as barcodes, and invalid barcodes as <barcode>.
cf. SmoothBarcodeWidget