Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative Ingredients #2581

Open
grantmulholland opened this issue Nov 16, 2024 · 9 comments
Open

Alternative Ingredients #2581

grantmulholland opened this issue Nov 16, 2024 · 9 comments
Labels
enhancement New feature or request Frontend Issue or PR related to the frontend code

Comments

@grantmulholland
Copy link

Is your feature request related to a problem? Please describe.
I've got a recipe that has "3 tbsp fresh parsley or 2 tsp dry", and it doesn't change the second number when I change the servings count.

Describe the solution you'd like
I'd like for the amount of the alternative ingredient to change.

Describe alternatives you've considered
I could see having a button to add an alternative ingredient working.

@stefan123t
Copy link

Could you simply write it as two separate ingredients:

3 tbsp fresh parsley **or**
2 tsp dry parsley

Alternatively there needs to be some numeral indicator $2,#2 (which has to have no other relevance like #r/1234 linking to other recipes), {2} or enclosed in ` backticks e.g.

3 tbsp fresh parsley `2` tsp dry parsley

@grantmulholland
Copy link
Author

I like the backticks. Quick to type, and no possible confusion with pounds.

@stefan123t
Copy link

@grantmulholland I also like it as a shorthand for numerals or preformatted text in markdown.

Though on a second thought it may be more common and easier to type to use the curly braces {n} syntax for "variables".
This could be useful to implement ranges or ingredients given as intervals too, see #2234

@christianlupus christianlupus added the Frontend Issue or PR related to the frontend code label Dec 2, 2024
@christianlupus
Copy link
Collaborator

@j0hannesr0th this sounds like an extension to the recalculation scripts of yours. What do you think of this?

@j0hannesr0th
Copy link
Contributor

Hi @christianlupus,

I made some comments and shared some thoughts on the other topic, which is somewhat connected.

  1. Using "1 ingredient fresh or 3 ingredient dried" adds unnecessary complexity and, in my opinion, is not good practice. As soon as the data model becomes more structured, an "or" within the data model will likely be disallowed.
  2. In a database, it's never a good idea to store multiple values in one cell. Instead, it’s better to list the alternative ingredient separately, below the original ingredient.
  3. Introducing "ingredient types" would resolve this. Alternatives could be displayed in cursive below the original ingredient.

@stefan123t
Copy link

@j0hannesr0th

Introducing "ingredient types" would resolve this. Alternatives could be displayed in cursive below the original ingredient.

Yes, maybe it would already be sufficient to have something like an (optional) flag / postfix ?

1 ingredient fresh (optional)
3 ingredient dried (optional)
5 other things (optional)
3 other stuff (optional)

Indenting or otherwise prefixing them with a dash - or star * would be the natural markdown unordered list identifier.

* 1 ingredient fresh
* 3 ingredient dried
- 5 other things
- 3 other stuff
- 1 other jiffy

To distinguish two consecutive list of alternatives we have to change the prefix - / * or use a local language postfix.
We may thereby group ingredients to make them related and use / require always one of the alternatives.

IMHO postfixing with a local language or, oder, ou, etc. would be a syntactical way of denoting multiple such alternatives.

1 ingredient fresh or
3 ingredient dried
5 other things or
3 other stuff or
1 other jiffy

@j0hannesr0th
Copy link
Contributor

IMHO postfixing with a local language or, oder, ou, etc. would be a syntactical way of denoting multiple such alternatives.

1 ingredient fresh or
3 ingredient dried
5 other things or
3 other stuff or
1 other jiffy

There will be some languages which we did not implement and users will complain.

So a symbol or emoji ↔️ should be used.

@stefan123t
Copy link

For simplicity sake, we should prefer the pipe symbol like | or || and not some arbitrary emoji,
as one may find this difficult typing on a PC keyboard, i.e. without a virtual / on-screen keyboard like on a mobile interface.

@christianlupus
Copy link
Collaborator

OK, I do not want to stop your bubbling ideas and brainstorming. But....

Unless we rebuild the complete backend to use the DB much more intensively, we are bound to the https://schema.org/Recipe description. There is no Markdown in this encoding. It is just a plain array in JSON encoded.

So, there are two parts here: A short-term solution where you cannot rely on the encoding but need to use just plain strings and a more fancy version where we can model something in the DB/...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Frontend Issue or PR related to the frontend code
Projects
None yet
Development

No branches or pull requests

4 participants