Enhancement: Recalculate ingredient quantity (e.g. double it)

[nivekznews]

Often people want to double or cut in halve the amount that should be cooked or baked.

Suggestion:
Provide the possibility to multiply the amount of ingredient's quantity temporarily.

---

Depends on #340

[mrzapp]

Agreed, I would want this feature too.

The issue is that knowing what is the numerical part of an ingredient is a bit tough, since literally any string is permitted as a recipe ingredient according to schema.org/Recipe.

For instance:

• A pinch of salt
• Half a cup of coconut milk
• One banana
• 2 quarts of orange juice

Unless we implement some restriction on ingredient input, which prevents the above ingredient formats and potentially angers some users, this feature cannot work.

Have you perhaps seen a good way to work around this issue?

[Teifun2]

I have once read through the schema.org issue on this topic. (The one i linked matrix)

One proposed solution was to use the supply tag to store the recipe ingredients.

We could save the ingredients with (amount, type, name) in the supply tag and to support data recovery and the current schema.org idea, we could then save one variant of this data in the ingredients tag. This would lead to data duplication in the JSON. We could only expose the supply tag to the users and fill the ingredients tag in the background. This is exactly the same as the above mentioned proposed solution.

"supply": [
  {
    "@type": "HowToSupply",
    "name": "rolled oats",
    "requiredQuantity": {
      "@type": "QuantitativeValue",
      "value": 100,
      "unitCode": "GRM"
    }
  }
],
"recipeIngredient": [
  "100g rolled oats"
]

[mrzapp]

@Teifun2 I like that solution, and I support that we would start saving and inputting recipes this way.

The problem is that no one else on the internet agrees (yet), so the ingredient recalculator would only work on manually entered recipes.

I think solving this issue inevitably leads to 3 tasks:

• Implement the new supply value input method
• Write a parser that automatically translates recipeIngredient to supply
• Provide a graceful fallback to recipeIngredient if no supply was found.

[Teifun2]

@mrzapp Yes. I agree. Especially the parser will be difficult :/

I think that all that should not be included into the goals of the next release, rather it could be the main focus of the version after that.

[mrzapp]

@Teifun2 agreed, we'll keep it in "to do" for now

[spikusmax]

Hi again,

Just wondering if you need to actually modify the way ingredient quantities are stored. Could one not specify that if no numerical value was found the ingredient would be listed as a text string with the value of the division/multiplication happened to the front. So if a recipe called for:

• 250g plain flour
• a pinch of salt

...and you wanted to double it the results would be:

• 500g plain flour
• 2x "a pinch of salt"

That way the internet does not get angered, output is functional if not perfect, and individual recipe holders then have the ability to modify their recipes for more streamlined conversions next time? These days recipes frequently only have one or two ingredients that aren't indicated as a numerical value, it would not be a huge burden on the individual cook to have to quality control the output of the quantity conversion script.

Cheers,

Spike

[mrzapp]

@spikusmax is on to something. What say you @Teifun2, should we not think too much ahead and actually just write a "lazy" parser in JavaScript?

[Mannshoch]

If you cook, doubling would work. But not when you bake. Here you would need two or three recipes for different quantity to calculate a quantity curve per ingredient so you could calculate for specific amount of people.

[ghost]

I was wondering if this could be extended to do unit conversion?

[Mannshoch]

Is there somewhere a kind of unit-table where units and their value are listed?
I only know https://en.wikipedia.org/wiki/Cooking_weights_and_measures
If there is no table we should create one with basic data.

[j0hannesr0th]

Hello, I migrated all my recipes from Tandoor to Nextcloud Cookbook. Now I'm missing this feature, which Tandoor has.

I think Tandoor is storing the unit, amount and name separately so scaling and calculating is easy.

Since this issue already exists since 2019 and hasn't been resolved yet I guess the chances are high that a refactoring to the "Tandoor way of storing data" is too complex?

[christianlupus]

The problem with this is that the recipe schema does not provide a way to store the data separated into number, unit, and name. Instead the standard we are sticking to dictates a pure string.

Currently, we try to stick with said standard to allow this party apps to understand our data. Extending the structure might be possible but at the same time might break this support.

This, any change here needs some considerations to be done. It is not forgotten and still stands open.

[j0hannesr0th]

@christianlupus do I understand this correctly?

You try to stick with the standard when exposing the stored data via REST-API that third-party apps/tools understand the data?

If yes, then internally we could store the data separately and when exposing the data we can concat it like this (pseudo code):

$x = '%s %s %s';
$singleString = sprintf($x, $amount, $unit, $ingredient);

So for third-party apps nothing will change since it's still one single string which will be delivered via REST-API. On the other hand we can update the docu that this string will always be delivered in this specific format (amount unit ingredient). Third-party apps are then able to parse it correctly too and implement a calculator/scaler too. We in the Nextcloud Cookbook can parse it correctly too and implement the calculator.

Extra bonus: the database will be normalized since we do not store "g" as a unit or "milk" as an ingredient 100+ (just an estimation depending on your recipes) times.

[christianlupus]

Hello @j0hannesr0th,

well, that is not 100% true what you are assuming here. There are in fact three ways to access the recipes that I am aware of: The website and the REST API you have already identified. There is also one Android app (and as far as I know one desktop app) that makes use of the file synchronization apps of Nextcloud to sync the recipes to the local store and use that set.
This means that the JSON files in the storage must be conforming with the standard as well.

We have the idea to add additional data in a separate per-recipe JSON file (#340) that contains custom information. This one will not stick to the standard and we can use it to store for example the decomposed ingredient values.

Once there is a storage location available, we need to think about how to migrate the current data (aka the pure strings) into the structured format. There are already some ideas but no ultimate solution so far.

[github-actions]

This PR/issue depends on:

• Meta: Future file structure #340
  By Dependent Issues (🤖). Happy coding!

[j0hannesr0th]

@christianlupus ping me if you made a decision. I want to help on this feature.

[j0hannesr0th]

Sorry @christianlupus I have to ping you again.

What about adding a regex as a quick win?

Using regex on the input of the ingredient:

• 0-9 a-Z a-Z (just a simple example; syntax does of course not work like this)
• 1 g Salt
• 3 piece Tomatoes
• 1 kg Minced Meat

So the input is structured in: amount unit ingredient.

Now only ingredients in the given format are accepted. Nothing changes for third-party apps since still one single string will be delivered.

Once all ingredients of the recipe are "migrated" into the new format we can show the calculator and if they are not migrated correctly we show a button "migrate" and open a view where the user has to update the ingredients of the specific recipe. So the user can update step by step and they don't have to convert all recipes at once.

What are your thoughts about this?

[seyfeb]

So the input is structured in: amount unit ingredient.

How would you handle things like:

• a pinch of salt
• pepper to taste
• 1 tsp. dried or fresh basil
• 500g broccoli, alternatively cauliflower

(there are certainly more of these typically and arguably useful ingredient descriptions)

is minced meat a different ingredient than meat? Should it be "meat (minced)", where meat is the ingredient and minced is simply a kind of preparation (you might have the tools at home)?

[j0hannesr0th]

@seyfeb

How would you handle things like:

* a pinch of salt

* pepper to taste

* 1 tsp. dried or fresh basil

* 500g broccoli, alternatively cauliflower

• 1 pinch of salt (preferably Himalayan salt)
• 1 pinch of pepper to taste
• 1 tsp. Dried of fresh basil
• 500 g broccoli, alternatively cauliflower
• 0.5 cup of cream

So basically I’d suggest to structure it like this:

1. any positive float value with only two decimal places (n.XX)
2. followed by whitespace
3. any char unlimited length
4. followed by whitespace
5. any char unlimited length

OR we could even allow

1. any positive float value with only two decimal places (n.XX)
2. followed by whitespace
3. any char unlimited length

The only important thing is, that we have the amount separated from the other parts.

There’s even no need to add the regex on the input as a validation. It’s possible to check all ingredients just in time if they have the „correct“ syntax. If they have it, we show the calculator – if not, we disable it. The calculator just has to parse the ingredient and split by whitespace.

Example recipe „butter bread with cress“ (2 servings):

• 2 slices of bread (whole grain)
• 1 piece of butter
• 0.5 table of cress

When clicking the + or - sign the numbers only change on client side.
The „algorithm“ is: amount / storedServings * clientServings

recipe „butter bread with cress“ (changed to 6 servings):

• 6 (2 / 2 * 6) slices of bread (whole grain)
• 3 (1 / 2 * 6) piece of butter
• 1.5 (0.5 / 2 * 6) tablespoon of cress

Of course we don’t show the computing path – it’s just for better understanding.
I know grammatically it’s not correct to say „3 piece of butter“ – but who cares? In my opinion most of the people do care more about this feature instead of grammatically perfect recipes.

[Zocker1999NET]

It’s possible to check all ingredients just in time if they have the „correct“ syntax. If they have it, we show the calculator – if not, we disable it.

I think it may be better to let the calculator be enabled, but on entries which don't follow the expected syntax to write out (with italic formatting so the user knows, it was added by the calculator):

3 times of pinch of salt

and when the user hovers with the mouse over the italic part, an explanation could show up saying "We didn't found a number to increase/decrease this ingredient. We expect it to be number (of) name." so the user knows how to fix this if this is not appropriate, e.g. if the original contains an ingredient called "a pinch of salt" or "three bananas" (which need to be "1 pinch of salt" & "3 bananas").

Just disabling the calculator could feel cumbersome if you have a big library of "not appropriate" recipes where you then would be required to fix every single ingredient before you can finally use the calculator on them. At least having this fallback enables user to at least use the calculator without needing to fix it right away, as especially IMO if ingredients have no number, the amount of them is most often not that important (e.g. spices), while for other ingredients having the calculator really helps (e.g. flour).

[j0hannesr0th]

@christianlupus @seyfeb

I can implement it as described in my last post.

Do you merge it, if I develop it? I don't want to invest time for a merge request which will never be merged.

[Eothred]

How would you handle things like:

* a pinch of salt

* pepper to taste

* 1 tsp. dried or fresh basil

* 500g broccoli, alternatively cauliflower

Talking from experience using another app, I would say if you multiply the initial numbers for each bullet that suffices. E.g. for "a pinch of salt", nothing happens but I remember I've multiplied by X so should probably increase accordingly compared to the default recipe. If a recipe says "one banana", I simply edit my recipe and put "1 banana" so that the multiplier works. I did not find this unreasonable or problematic I would say.

Multiplier that only works on the initial number (also without space for unit, such as "500g"), is afaik much easier and robust to implement, and solves 95% of the issue. Personally I would not see the need to spend tremendous effort to solve the last 5%.

[christianlupus]

Let's discuss the PR of @j0hannesr0th in a separate discussion to keep here only to separate the technical discussions a bit.

[GVLLIFESTYLE]

when will be the next release with those new features?

[christianlupus]

The next release will be done once the outstanding issues are solved. There are a few minor issues to be addressed and one security concern. There is not yet a final schedule but it should not be too long.

[GVLLIFESTYLE]

any update on the release date of this feature?

[seyfeb]

It has been released a month ago, see 0.10.3 in the CHANGELOG.

[GVLLIFESTYLE]

thanks