Menu style guide¶

The method pages decide what the menu contains. The schema decides its shape. This page decides how it reads — in English and in Hebrew, because every client-facing string in a localizedText is both.

Write both languages together¶

Not an English draft followed by a translation pass. Write an option's name, then its Hebrew name, then move to the next food item — so neither language quietly becomes the source of truth the other is translated from. A phrase that is awkward to say in Hebrew is often a sign the English was already too clever; writing them side by side catches that immediately, where a translation pass at the end would not.

Register¶

Second person, warm, direct. The client is an adult being handed a plan, not a patient and not a project. In Hebrew this means choosing and holding a gender throughout — see below.

• Write "eat", not "consume" — לאכול, not לצרוך.
• Write "breakfast", not "the first meal of the day" — ארוחת בוקר, not הארוחה הראשונה ביום.
• No exclamation marks. No emoji. No encouragement that is not information — "you've got this" tells the client nothing they can act on, in either language.
• No hedging. "Finish dinner by 20:00", not "you might want to try to finish dinner by around 20:00 if you can".

Hebrew gender¶

Hebrew's second person is gendered — there is no neutral form. Read client_gender and hold it for the whole file:

A file that opens את יכולה and drifts to אתה יכול partway through reads as written for someone else. Check every verb and every adjective before a menu ships — the schema cannot catch this, because both forms are grammatically valid Hebrew.

Plainness is a requirement, in both languages¶

The reader may not be fluent in either, and they are reading instructions, not prose.

Short sentences. One instruction per line. No idiom, no metaphor, no wordplay — the first things to fail in translation, so avoided in both directions rather than smoothed over afterward.

Vocabulary¶

Use one name for one thing, every time, in both languages. A menu that calls the same thing two names is a menu the client has to decode.

Structure¶

ארוחת ביניים, not נשנוש — a snack is a scheduled meal in this menu, and the surrounding text should say so in both languages: "the 11:00 snack" / ארוחת הביניים של השעה 11:00, not "if you get peckish".

Food groups¶

Exactly as the exchange lists name them in both languages. Not "carbs" for starch, not "veg" for vegetables, not פחמימות טובות for anything. The client is counting portions of six named groups, and the names have to match what they are counting against.

Measures¶

Spell fractions out in prose in both languages — "half a cup" / חצי כוס, not ½ cup. Grams for meat, fish and cheese; household measures for everything else, because those are the things a client already owns in either kitchen.

Writing a food item and an option¶

Every food in the menu is one foodItem: a food name, a qty, and the portions it delivers — each a localizedText, written together per food, not per language.

{
  "food": { "en": "cooked lentils", "he": "עדשים מבושלות" },
  "qty": { "en": "½ cup", "he": "חצי כוס" }
}

An option is a short bilingual name plus its list of items:

{ "en": "Rice and lentils", "he": "אורז ועדשים" }

Four rules, unchanged by the format:

1. Lead with a name. "Rice and lentils" / אורז ועדשים — so the client can refer to it and remember it, in whichever language they're reading.
2. Every quantity measurable. Not "some", not "a portion of", not "a handful of vegetables" where a count exists — in either language.
3. List items in plate order — the starch, then the protein, then the vegetables, then the fat. Consistent order across every option makes them comparable at a glance, and the order does not change between languages.
4. One food per item. A composed dish is broken into its parts — see the exchange lists — not folded into one food string with two quantities in it.

Tone in the notes¶

notes — what a client sees as "the things we adjusted for you" — is the only part of the menu that explains itself, and it is where tone goes wrong in either language.

• State the change, then the reason. "Breakfast moves from 11:00 to 08:15 and gains protein — that is what holds your energy to lunch." / ארוחת הבוקר עוברת מ-11:00 ל-08:15 ומקבלת יותר חלבון — זה מה שמחזיק את האנרגיה עד הצהריים.
• Never comment on the client's body, their weight, their shape or their eating history. Not critically, and not approvingly either.
• Never moralise about food. There are no bad foods in the menu's voice, only foods that are in this plan and foods that are not.
• Say a limitation plainly. "This menu cannot cover B12 on a vegan pattern — worth raising with your doctor" is the right shape in both languages. Do not soften it into vagueness in either.
• One sentence per note. A note that runs to a paragraph is doing a reference page's job.

What never appears in the menu¶

• Field IDs. Not once, in either language.
• The agent's arithmetic. No kcal, no grams of macronutrient, no g/kg, no activity factor. dailyTarget exists in the file for validation; it is not rendered. The client sees portions and food.
• A weight, BMI or body-fat figure where meas_weight_aware or meas_blind_weigh said not to.
• A promised outcome. No predicted weight, no timeline, no "you will".
• A diagnosis, or any interpretation of a test.

The disclaimer¶

Fixed text, both languages, at the schema's disclaimer key, pinned by const so it cannot be edited and still validate:

"disclaimer": {
  "en": "This menu was built from what you filled in on the questionnaire. It is not nutritional therapy, not a medical diagnosis, and not a substitute for advice from a doctor or a registered dietitian. If you have a medical condition, take medication, or something does not feel right, talk to them before you start.",
  "he": "התפריט הזה נבנה על סמך מה שמילאת בשאלון. הוא אינו טיפול תזונתי, לא אבחנה רפואית, ולא תחליף לייעוץ עם רופא או דיאטניתית קלינית. אם יש לך מצב רפואי, את‏/ה נוט‏/לת תרופה, או שמשהו לא מרגיש בסדר — כדאי להתייעץ לפני שמתחילים."
}

The Hebrew keeps the את‏/ה form regardless of the client's gender — it is the one string in the file that is not addressed personally, so it does not follow the gender rule above.