Alternative ingredients

[tstehr]

Alternative ingredients

[tstehr]

Got this idea from a pizza recipe, where it specified multiple valid Flour types.

While #4 could be used to express this thing, I think that it is a bit clumsy to express such xor Relations for single ingredients.

Agreed, that seems like overkill and would lead to variants that basically restate the ingredient name

My suggestion:

- *1kg* Weizenmehl Type 405
  or *1kg* Weizenmehl Type 550

For this particular case I'd just create once ingredient with a compound description, since the amount is the same for both types of flour:

- *1 kg* Weizenmehl Type 405 oder Weizenmehl Type 550

Also useful for fresh and dried yeast (different amounts/amount units)

The situation where the different ingredients use different amounts seems like the stronger justification for a feature like this
to me.

I did a quick search for cases like this and found quite a few of them (1, 2, 3, 4, 5, 6). Number 2 is exactly the
case yeast case you mentioned, btw :)

For the spec, we consider it an alternative ingredient, if it comes after a linebreak and contains a valid amount. The text before the amout is ignored.

We would still need to store the text before the amount somehow, otherwise it will get lost during a parse/serialize cycle. Not sure where to put it, maybe a sort of ingredientPrefix on the ingredient?

I'm also a little concerned with putting that much semantics into a line break. People tend to have opinions on line length and often hard wrap at that point, which would change the meaning for alternative ingredients in this proposal.

I know that this won't work with ingredients without amount, but it was the best idea I could think of.

That would be okay with me. As said above the use case becomes a lot weaker if the amount for both ingredients is the same.

[tstehr]

An alternative approach here would be to wait until we get a decision on #1 and then extend that to also cover the ingredient name (and possibly other text in the recipe as well).

That would also allow ingredients like *2 tbsp* tomato paste (*40 g*) to work correctly.

[blabug]

For this particular case I'd just create once ingredient with a compound description, since the amount is the same for both types of flour

The main idea behind this (and #50 ) is that the computer can separate these metainformations from the actual ingredients. The motivation behind this is to have a grocery management system (like https://grocy.info/) and being able to match your inventory with your recipes (only buy missing thing, list all recipes that you can make with your ingredients). Furthermore this is probably also necessary for my proposal in #1 to be able to match ingredients to the actual instructions (as you could just write Weizenmehl Type 405 in the instructions and it would match the ingredient).

This is also the reason, why I proposed the newline idea, as it allows to parse and ignore binding words/phrases like or/oder/alternativ without having to guess or detect them via a dictionary.

[blabug]

I'm also a little concerned with putting that much semantics into a line break. People tend to have opinions on line length and often hard wrap at that point, which would change the meaning for alternative ingredients in this proposal.

I don't see this as such a big problem, as we only consider a linebreak as an alternative ingredient, if it contains a valid amount. Furthermore these breakpoints are usually longer than a single ingredient, so the forced break only affects additional information about the ingredient.

We would still need to store the text before the amount somehow, otherwise it will get lost during a parse/serialize cycle. Not sure where to put it, maybe a sort of ingredientPrefix on the ingredient?

Although being an implementation detail, it would be just a prefix/bindingPrefix field for every ingredient. Other implementions may also not try to serialize the recipe back, but just patch the amount numbers in-place, as exact serialization would also require recording/capturing every whitespace and newline in the data representation (e.g. # Mac'n'Cheese, notice the leading whitespace).

[tstehr]

I don't see this as such a big problem […]

Let me expound on my concerns for a bit. The main thing going on is that the parser interprets the newline as the alternative ingredient separator, while any casual user will see the "or" (or another string) and consider that the separator. Differing interpretations make it very easy for incorrect recipes to sneak in. Some examples:

• These ingredients would parse differently, even though they look very similar to a user and in fact render to exactly the same HTML.

  - *1kg* Weizenmehl Type 405 or *1kg* Weizenmehl Type 550
  - *1kg* Weizenmehl Type 405
  or *1kg* Weizenmehl Type 550
  - *1kg* spring onions, white part only, thinly sliced or *1kg* shallots, peeled
     and cut into quarter rings
  - *1kg* spring onions, white part only, thinly 
     sliced or *1kg* shallots, peeled and cut 
  into quarter rings
  - *1kg* spring onions, white part only, thinly sliced 
     or *1kg* shallots, peeled and cut into quarter rings

• Using a different prefix could create very confusing ingredients where casual interpretation will not match the parse result.

  - *200g* mozarella 
    and *100g* parmesan
  - *200g* onions 
    and *100g* shallots
    or *300g* onions

[tstehr]

What do you think about using a slash as the separator for alternative ingredients? That would match common use of the slash and not have the prefix problem. Example:

- *1kg* Weizenmehl Type 405 / *1kg* Weizenmehl Type 550

One open question here is if we could still allow slashes in the ingredient name without that creating an alternative ingredient. We could also apply the heuristic of "does it contain an valid amount" here, but I'd want to think about the consequences of this in more detail before committing to it.

[blabug]

These ingredients would parse differently, even though they look very similar to a user and in fact render to exactly the same HTML.

Ah, damn. I've just looked at the Github Markdown renderer, which renders these newlines in lists. While the HTML differs even in the official implementation, it is just a newline that doesn't get rendered to the user, as the HTML ignores it. I understand that this may confuse users which write recipes based on the look of the rendered recipe of other users.

Using a different prefix could create very confusing ingredients where casual interpretation will not match the parse result.

yep. But even now we have cases where people violate the current spec (like in #38 ). It was a balance between being able to have the binding wording and the unlikely case of people using this for things that are probably better done using #4 .

What do you think about using a slash as the separator for alternative ingredients?

I don't have a problem doing it this way 👍

One open question here is if we could still allow slashes in the ingredient name without that creating an alternative ingredient. We could also apply the heuristic of "does it contain an valid amount" here, but I'd want to think about the consequences of this in more detail before committing to it.

I wouldn't allow slashes in the ingredient at all! It will make confusing things like *1kg* Weizenmehl Type 405/550, which provide no parsing benefit over *1kg* Weizenmehl Type 405 or Type 550

[tstehr]

What do you think about using a slash as the separator for alternative ingredients?

I don't have a problem doing it this way 👍

I think I prefer slashes over line breaks + prefix, if you're also fine with it let's pursue slashes for now and see where we get to.

I wouldn't allow slashes in the ingredient at all! It will make confusing things like 1kg Weizenmehl Type 405/550, which provide no parsing benefit over 1kg Weizenmehl Type 405 or Type 550

I don't think that's going to work. I just did a very cursory search and found all of the following. These all seem like perfectly reasonable ingredients to me which would be torn apart if the slash in them was to be interpreted as an alternative ingredient marker:

fresh mozzarella, cut into 1/2-inch cubes (optional)
firm tofu (natural/"Naturtofu")
flavourful vegetable broth/stock, divided
grüne oder rote Chilis (mehr/weniger nach Geschmack)
Gelbe/orangene Marmelade
liquid aminos (or tamari/soy sauce)
Milchersatz, vegan (Reis-/Dinkel-/Hafer-/Sojamilch)
Paprika (rot/gelb)
russet potatoes, peeled and sliced 1/8 inch thick on a mandoline slicer (5 to 6 medium potatoes; see note)
schwarze und/oder grüne Oliven
Shiratamako (glutinous rice flour/sweet rice flour)
Wadschunken (Hesse/Beinscheibe) vom Rind
Weichkäse (Brie/Camembert)
zum Servieren: Pinienkerne, geröstet und/oder Parmesan

For all of these, a rule as follows would work: A slash is interpreted as an alternative ingredient divider iff it is followed by an emphasis with only whitespace in between.

[blabug]

I don't think that's going to work. I just did a very cursory search and found all of the following. These all seem like perfectly reasonable ingredients to me which would be torn apart if the slash in them was to be interpreted as an alternative ingredient marker:

The idea was not, that every slash denotes an alternative ingredient, but to reserve the slash for the purpose of alternative ingredients. E.g. when we define *1kg* A / *1kg* B as alternative ingredients, we want to disallow/discourage the use of *1kg* A/B or Oil/Butter to prevent the user thinking that this is an alternative ingredient definition. Much like you have reserved keywords in programming languages so you can't define a function named if, because it can confuse humans and is harder to parse for computers.

For all of these, a rule as follows would work: A slash is interpreted as an alternative ingredient divider iff it is followed by an emphasis with only whitespace in between.

Either I would define it more concrete: A slash is interpreted as an alternative ingredient divider iff it is followed by a valid amount followed by a non slash character (ignoring whitespaces).

But thanks to your search, we could also define an alternative ingredient separator to be defined by a slash, which is preceeded and followed by an whitespace character (regex: \s+/\s+). This would allow alternative ingredients for ingredients without amount (Oil / Butter).