Ingredient parser mishandles dual-measurement text ("4 tbsp/58 grams" and "1½ cups (210 grams)")

Description

Recipe sites that give both imperial and metric measurements inline (common on NYT Cooking, America's Test Kitchen, and similar) produce corrupted food/unit fields after import — both via URL import and the browser bookmarklet. The amount value is generally still numerically correct; the problem is that leftover text from the second measurement leaks into the food or unit field instead of being discarded.

Confirmed via both /api/recipe-from-source/ and the bookmarklet import flow, so this appears to be in the shared ingredient-parsing logic, not the fetch/scrape step.

Impact

This isn't a niche formatting edge case — it affects two of the most widely used recipe sites: NYT Cooking and America's Test Kitchen / Cook's Illustrated, both of which write dual imperial/metric measurements inline for essentially every ingredient with a meaningful quantity. Anyone importing recipes from either site will hit this on most recipes, not occasionally.

Example 1 — slash format (NYT Cooking)

Source text: "4 tablespoons/58 grams unsalted butter"

Result:

{"amount": 4.0, "unit": {"name": "tablespoons/58"}, "food": {"name": "grams unsalted butter"}}

Expected: amount: 4, unit: "tablespoons", food: "unsalted butter"

Another instance from the same recipe, where the metric unit ends up as the clean unit field instead: Source text: "⅔ cup/140 grams granulated sugar"

Result:

{"amount": 140.0, "unit": {"name": "grams"}, "food": {"name": "⅔ cup/ granulated sugar"}}

Note the numeric value itself is a defensible interpretation here (140g ≈ ⅔ cup sugar), but which of the two measurements gets treated as canonical varies inconsistently even within the same recipe, and the discarded measurement's text isn't fully stripped from food.

Example 2 — parenthetical format (America's Test Kitchen)

Source text: "1½ cups (210 grams) self-rising flour"

Result:

{"amount": 1.5, "unit": {"name": "cups"}, "food": {"name": "(210 grams) self-rising flour"}}

Here amount/unit are correct, but the parenthetical metric annotation is left stuck to the front of the food name instead of being stripped or moved to a separate field.

By contrast, a trailing parenthetical annotation (after the food name) is already handled correctly: Source text: "7½ ounces strawberries, hulled and chopped (1½ cups)" → cleanly drops (1½ cups), leaving food: "strawberries, hulled and chopped".

Suggested fix direction

When the parser encounters a <amount> <unit> sequence immediately followed by a second <amount> <unit> sequence (separated by / or wrapped in parentheses) before any food-name text has been consumed, it should treat the second measurement as a duplicate/alternate unit annotation and discard it entirely (or store it as an alternate unit, if that's supported), rather than letting its trailing words merge into the food field.

Environment

• Tandoor version: 2.6.13 (self-hosted, Docker, vabene1111/recipes image)

Related issues

• #3803 (closed) requests first-class support for storing multiple measurements per ingredient — related in spirit, but this report is about the current parser corrupting food/unit when it encounters two measurements in one line, independent of whether multi-measurement storage is ever added.
• #703 (closed/fixed) covers a different pattern (package-size clarifiers like "1 (16 ounce) package") that doesn't overlap with this one.