What problem does this solve?
Many products in Open Food Facts contain a serving size defined by the manufacturer, such as:
1 slice
1 biscuit
1 cookie
1 square
1 candy
1 bottle
1 pot
1 bar
Open Food Facts exposes these values through fields such as:
serving_size
serving_quantity
*_serving
These serving units are often the most natural way for users to log foods.
For example:
Bread → 1 slice
Chocolate → 1 square
Cookie → 1 cookie
Candy → 1 piece
Soft drink → 1 bottle
Yogurt → 1 pot
Currently, users may need to manually convert these portions into grams or milliliters before logging them, even though Open Food Facts already provides the serving information.
This makes food logging less convenient and increases the likelihood of logging errors.
Proposed solution (optional)
When a product imported from Open Food Facts contains a valid serving size:
serving_size
serving_quantity
automatically expose the serving as an available unit in the quantity selector.
Examples:
Bread
OFF data:
serving_size = "1 slice"
serving_quantity = 35 g
Available units:
Chocolate
OFF data:
serving_size = "1 square"
serving_quantity = 10 g
Available units:
Soda
OFF data:
serving_size = "1 bottle"
serving_quantity = 500 ml
Available units:
When the user selects a serving-based unit, nutrients can be calculated using the serving quantity already provided by Open Food Facts.
Alternatives you've considered
Additional context
Open Food Facts supports nutrition data both per serving and per 100 g / 100 ml.
Relevant fields include:
serving_size
serving_quantity
energy_serving
fat_serving
proteins_serving
...
Examples from Open Food Facts documentation include serving sizes such as individual candies, where nutrients can be calculated "per candy" in addition to per 100 g.
Supporting serving units directly would:
- Improve logging speed
- Better match packaging labels
- Reduce manual conversions
- Improve usability for common foods such as bread, cookies, chocolates, snacks, drinks, and dairy products
References:
Implementation Reference Links (open nutriment tracker support it)
What problem does this solve?
Many products in Open Food Facts contain a serving size defined by the manufacturer, such as:
Open Food Facts exposes these values through fields such as:
These serving units are often the most natural way for users to log foods.
For example:
Currently, users may need to manually convert these portions into grams or milliliters before logging them, even though Open Food Facts already provides the serving information.
This makes food logging less convenient and increases the likelihood of logging errors.
Proposed solution (optional)
When a product imported from Open Food Facts contains a valid serving size:
automatically expose the serving as an available unit in the quantity selector.
Examples:
Bread
OFF data:
Available units:
Chocolate
OFF data:
Available units:
Soda
OFF data:
Available units:
When the user selects a serving-based unit, nutrients can be calculated using the serving quantity already provided by Open Food Facts.
Alternatives you've considered
Continue requiring users to enter only grams or milliliters.
Allow users to manually create custom serving units.
Additional context
Open Food Facts supports nutrition data both per serving and per 100 g / 100 ml.
Relevant fields include:
Examples from Open Food Facts documentation include serving sizes such as individual candies, where nutrients can be calculated "per candy" in addition to per 100 g.
Supporting serving units directly would:
References:
Open Food Facts nutrition data documentation:
https://openfoodfacts.github.io/openfoodfacts-server/dev/explain-nutrition-data/
Open Food Facts API field documentation:
https://test-wiki.openfoodfacts.org/index.php?mobileaction=toggle_view_desktop&title=API_Fields
Open Food Facts product API documentation:
https://test-wiki.openfoodfacts.org/index.php?mobileaction=toggle_view_desktop&title=API/Read/Product
Implementation Reference Links (open nutriment tracker support it)