moedcal.com — le plan du site

Décidé le 5 octobre 2026, révisé le même soir après trois relectures critiques (référencement, exactitude, design). Site web de Moed : les fonctions de l'app iPhone, en ligne, pour être trouvé sur Google et mener à l'App Store (https://apps.apple.com/app/id6790553505). Maquettes : https://moedcal.vpsdashboard.space/ — le style suit moed-ios/DESIGN.md.

1. Les dix décisions

2. Qui cherche quoi

Les volumes exacts ne sont publics nulle part (Keyword Planner demande un compte Google Ads actif ; Ahrefs, Semrush et keywordtool.io ne montrent rien sans compte : essayé le 05/10). Les chiffres ci-dessous viennent de deux mesures réelles et d'une déduction : - Google Trends (12 mois, relatif, relevé le 05/10/2026 par l'API publique) ; - un seul ancrage absolu : « hanukkah » ≈ 300 000 à 550 000 recherches par mois en moyenne mondiale (https://www.keysearch.co/top-keywords/hanukkah-keywords) ; - les autres volumes sont déduits des rapports Trends × cet ancrage : marge d'un facteur 2 au moins.

Avant de fixer la liste des villes et des langues (étape 0 de §12) : ouvrir un compte Google Ads (sans campagne) pour lire Keyword Planner, et remplacer ce tableau par des chiffres mesurés. Le chiffre de « hebrew date converter » (~50 000) est à vérifier en premier : il paraît haut.

Ce qu'on en retient pour l'ordre de construction : la page ville (familles 1, 2, 3, 9, 15, 17) porte la plus grosse part du volume, mais seulement là où elle apporte plus que Hebcal ; les pages fête × année portent les plus gros pics ; le convertisseur et le calendrier de l'année sont stables toute l'année. En hébreu, la requête forte est כניסת שבת [עיר] (18 fois « זמני שבת ») : elle va dans le titre et le H1 des pages ville hébraïques ; « זמני שבת » reste dans la première phrase. Les concurrents (Hebcal, Chabad, Yeshiva.org.il, Kikar) ont beaucoup plus d'autorité : la fenêtre réaliste est le milieu de classement des villes moyennes, pas Jérusalem ou Tel-Aviv la première année.

3. Les langues

Données : population juive « core » 2024 (DellaPergola, https://www.cbs.gov.il/he/Documents/World%20DellaPergola%202024%20complete.pdf) et pages vues mensuelles de Wikipédia (moyenne sept. 2025 – sept. 2026) pour Hanoukka / Chabbat / calendrier hébraïque.

Un seul critère pour toutes les langues (décidé le 05/10, r1) : une langue entre au plan si la somme des vues Wikipédia des trois articles dépasse 10 000 par mois ou si elle a une communauté de plus de 50 000 personnes qui la lisent ; elle n'ouvre qu'avec un relecteur natif (décision 7) et quand la langue précédente produit du trafic.

Retirées du plan : coréen, chinois, japonais (300 à 2 700 vues, pas de communauté : ne passent pas le critère), yiddish (42 vues ; le public hassidique cherche en hébreu ou en anglais), judéo-espagnol (23), hindi (101).

Calendrier : étape 2 au plus tôt 8 semaines après le lancement, si les seuils de §7.3 sont tenus ; étape 3 après que l'étape 2 produit du trafic. Pas de date fixe.

4. Arborescence et adresses

moedcal.com/
├─ /                                    page de choix de langue (fixe, liens vers chaque langue)
├─ /fr/                                 accueil : date du jour, prochain zman, Chabbat, outils
├─ /fr/horaires/                        toutes les villes, par pays
│  ├─ /fr/horaires/france/              pays : toutes ses villes et l'allumage de la semaine (indexée)
│  ├─ /fr/horaires/paris/               ville retenue (aujourd'hui + prochain Chabbat)
│  └─ /fr/horaires/paris/chabbat-5787/  ville : tous les Chabbats de l'année, à imprimer + iCal
├─ /fr/fetes/                           toutes les fêtes et jeûnes
│  ├─ /fr/fetes/hanoukka/               la fête (définition, dates de 2020 à 2032 en tableau)
│  └─ /fr/fetes/hanoukka/2026/          la fête une année : l'année en cours et la suivante seulement
├─ /fr/calendrier/2026/                 l'année civile, mois par mois
├─ /fr/calendrier/5787/                 l'année hébraïque
├─ /fr/paracha/berechit/                une paracha (prochaines lectures, haftara par rite)
├─ /fr/hilloulot/                       les 30 tsadikim
│  └─ /fr/hilloulot/rabbi-levi-yitzhak-de-berditchev/
├─ /fr/convertisseur-de-dates/
├─ /fr/yahrzeit/                        calculateur de yahrzeit
├─ /fr/bar-mitsva/                      calculateur de bar et bat-mitsva
├─ /fr/guematria/
├─ /fr/omer/                            le compte du jour (ouverte toute l'année, active entre Pessah et Chavouot)
├─ /fr/methode/                         méthode et sources (prérequis du lancement, §5.9)
├─ /fr/widget/                          le widget à intégrer et l'API, documentés (§7.4)
└─ /fr/articles/heure-allumage-bougies-chabbat/

• Mots de chemin : une table par langue (horaires / zmanim / horarios…), tenue avec le glossaire. Les noms de ville viennent du nom ASCII de GeoNames.
• Homonymes : /fr/horaires/paris/ est Paris, France. Les homonymes prennent la région et le pays dans l'adresse (/en/zmanim/paris-tx-us/) et dans le titre (« Paris, Texas ») ; sans communauté connue, ils restent en noindex.
• hreflang en balises <link> dans la page et en xhtml:link dans les sitemaps, générées depuis une seule table de routes ; chaque page ne liste que les langues où elle existe ; x-default → la version anglaise. Un test de construction vérifie la réciprocité (A → B ⇒ B → A), que chaque adresse listée répond 200 et qu'elle est sa propre canonique.
• Canonique : toujours l'adresse propre, sans paramètre.

Pages au lancement (hébreu, français, anglais)

Les parachiot (61) et les tsadikim (30) viennent à l'étape 3 de §12, une fois les pages du lancement indexées.

5. Chaque type de page

Modèles en français ; {} = valeur calculée. Chaque page porte : fil d'Ariane, phrase-réponse en tête (aussi sur téléphone, avant tout autre bloc), données calculées, texte propre, liens internes, carte de l'app, pied de page avec les langues. Titre ≤ 60 caractères, description ≤ 155, l'heure au début : la construction échoue sinon, maquettes comprises (tools/build-mockups.mjs). Pas de « | Moed » dans les titres des pages ville et fête : la marque n'a aucune notoriété et coûte la place de l'heure.

Données structurées : seulement ce qui est vrai et éligible. BreadcrumbList partout ; Article sur les articles ; WebSite (nom du site) sur l'accueil. Retirés : Event (un Chabbat ou une fête n'est pas un évènement auquel on assiste en un lieu à adresse, et VirtualLocation sans composante réelle n'est pas pris en charge), FAQPage (Google a supprimé ces résultats pour tous les sites le 7 mai 2026), WebApplication/MobileApplication (sans avis, pas d'affichage), SearchAction (champ de recherche des liens annexes retiré par Google), Person et ItemList d'Event. Event ne reviendra que pour un vrai évènement localisé (une hiloula à un tombeau, avec adresse). Les questions fréquentes restent en HTML visible.

5.1 Ville — /fr/horaires/paris/ (maquettes : paris.html, yerushalayim.html)

• title : Chabbat à {Ville} : allumage {heure}, sortie {heure} · zmanim ; he : כניסת שבת ב{עיר}: הדלקת נרות {שעה}, צאת השבת {שעה}.
• meta : Vendredi {date}, allumage des bougies de Chabbat à {heure} à {Ville}, sortie samedi à {heure} ({paracha}). Zmanim du jour et tous les Chabbats de l'année. — la fin varie selon ce que la ville a en propre (coutume, Chabbat le plus tôt, synagogues).
• H1 court et différent du titre : Chabbat et zmanim à {Ville} ; he : כניסת ויציאת שבת ב{עיר}. Puis la date hébraïque en grand (serif), comme l'app.
• En haut : phrase-réponse, trois réglages (ville, coutume, jour), puis sur téléphone dans cet ordre : carte Chabbat, carte « prochain zman » avec l'arc, zmanim ; sur ordinateur : Chabbat | prochain zman, puis zmanim | une colonne qui suit le défilement (à venir, l'app).
• Contenu propre à la ville : zmanim avec variantes, 5 prochains Chabbats, « Le calcul pour {Ville} » (coordonnées, altitude, fuseau, coutume, fin de Kippour), 5 villes proches, et le contenu local du seuil §7.2 (coutume locale sourcée, synagogues et leurs horaires d'office, texte relu). Chabbat le plus tôt et le plus tard ne sont plus dans le corps : ils sont sur la page annuelle, liée.
• Graphies : les variantes (shabbat, chabat, shabbath) sont écrites une fois en texte visible, naturellement.
• Anglais : heures en 12 h (6:56 PM) par Intl ; « Shabbat / Shabbos » et « candle lighting » dans le texte.
• Liens : pays, villes proches, paracha, fête suivante, article sur le calcul, page annuelle.

5.2 Fête × année — /fr/fetes/hanoukka/2026/ (maquette : hanoukka-2026.html)

• title : {Fête} {année} : du {début} au {fin}, heures d'allumage.
• H1 : {Fête} {année} ; sous-titre hébreu ; la réponse en grand dans une carte (« Premier soir à Paris : avant 16:38 »).
• Contenu : les huit soirs avec les deux heures (coucher et nuit, chaque communauté choisit la sienne, Choulhan Aroukh 672:1) et le nombre de bougies dit aussi en mots ; ce qui se passe pendant la fête ; les autres années ; questions ; les graphies (Hanouka, Hanoucca, Hanukkah, Chanukah) en texte visible.

5.3 Convertisseur — /fr/convertisseur-de-dates/ (maquette : convertisseur.html)

• title : Convertisseur de date hébraïque · aujourd'hui {date hébraïque}.
• En haut : le formulaire prérempli avec aujourd'hui, et juste dessous le résultat en grand (il change quand on change un champ, aria-live), les trois prochaines occurrences, des liens vers yahrzeit, anniversaire, guématria.
• Rendu : le formulaire marche sans JavaScript (GET ?d=…&m=…&y=…, page en noindex) ; le JavaScript ne fait que l'accélérer.

5.4 Paracha — /fr/paracha/berechit/

• title : Paracha {nom} : lue le {date} · {références} ; références, haftara par rite, dates de lecture diaspora et Israël, résumé écrit, lien vers le texte sur Sefaria. BreadcrumbList.

5.5 Tsadik — /fr/hilloulot/{slug}/

• title : Hiloula de {nom} {année} : {date hébraïque} ; monogramme de l'app, dates, tombeau, œuvres, biographie sourcée (celle de l'app). BreadcrumbList.

5.6 Calendrier de l'année — /fr/calendrier/2026/

• La grille de l'app (dimanche → samedi, date hébraïque dans chaque case, allumage du vendredi), une fête par ligne en dessous, export iCal et impression. BreadcrumbList.

5.7 Outils yahrzeit, bar-mitsva, guématria

• Même schéma que le convertisseur : le formulaire prérempli, le résultat calculé, les règles écrites (décès après le coucher du soleil, Adar en année embolismique), questions fréquentes. Le calculateur de yahrzeit propose « Ajouter à l'app Moed » (lien profond) et un fichier iCal.

5.8 Article — /fr/articles/{slug}/ (maquette : article-allumage-chabbat.html)

• 800 à 1 500 mots, encadré « En bref » en tête, illustration à la largeur du texte (générée et validée, recadrée sur son sujet) ou graphique tiré des calculs, sources précises (traité et page, siman et paragraphe), « À lire ensuite ». Article + BreadcrumbList ; author = l'organisation tant que le relecteur n'est pas désigné, puis une personne avec sa page.
• Un article de halakha ne paraît qu'après relecture par le relecteur (à désigner) ; la page affiche alors son nom. D'ici là, la maquette n'affiche aucune mention de relecture.

5.9 Méthode et sources — /fr/methode/ (prérequis du lancement)

• Les formules (NOAA, KosherZmanim), la règle d'altitude et la règle d'arrondi (§6.1), les degrés (16,1°, 11,5°, 8,5°), les coutumes d'allumage par ville et leur source, la comparaison avec Hebcal et Chabad et pourquoi une minute peut différer, les sources halakhiques, le relecteur (à désigner) et le formulaire de signalement.

6. Technique

6.1 Les règles de calcul (une seule fois, pour le site et l'app)

Altitude — la règle de l'app (moed-ios/Sources/Moed/Engine/ZmanimEngine.swift et SolarCalculator.swift) : le lever et le coucher du soleil sont corrigés de l'altitude de la ville quand elle est positive ; tout ce qui en dérive aussi (heures proportionnelles du Gaon de Vilna et du Maguen Avraham, hatzot, minha, plag, allumage = coucher − minutes, Rabbénou Tam = coucher + 72 min). Ce qui se mesure en degrés (aube 16,1°, michéyakir 11,5°, tombée de la nuit 8,5°) se calcule au niveau de la mer. Le site applique la même règle, avec la même altitude par ville (cities.json de l'app, puis GeoNames). - Conséquence à trancher par le propriétaire et le relecteur : en altitude, le coucher est plus tard. À Jérusalem (754 m), l'allumage du 9 octobre tombe à 17:38 au lieu de 17:34 chez Hebcal et sur les calendriers de la ville, qui comptent les 40 minutes depuis le coucher au niveau de la mer. Quatre minutes plus tard, c'est le sens contraire de la prudence. Proposition : compter l'allumage depuis le coucher au niveau de la mer, dans l'app et sur le site ensemble ; tant que ce n'est pas décidé, le site suit l'app.

Arrondi — une seule règle, prudente : ce qui ferme une permission ou commence une interdiction s'arrondit à la minute inférieure ; ce qui ouvre une permission ou termine une interdiction, à la minute supérieure. La même heure peut donc s'arrondir différemment selon son rôle sur la page.

• L'app tronque aujourd'hui toutes les heures (format système). Elle doit prendre la même règle ; les captures de l'app utilisées par le site sont à refaire après (la capture de l'accueil montre encore 7:54 et 19:57 là où le site dit 7:55 et 19:58).
• Coutume d'allumage par ville : la table de l'app (Jérusalem 40 ; Haïfa, Petah Tikva, Beer-Sheva 30 ; ailleurs 18). Hebcal met 20 minutes par défaut en Israël : le test de parité lui passe les minutes de la ville ; la table entière est à faire relire (relecteur à désigner) avant le lancement.

6.2 Le reste

• Next.js 16 (App Router, React 19, TypeScript, Tailwind v4), un projet /root/apps/moedcal déclaré dans Ariane ; moedcal.com en domaine.
• Cache : chaque page ville est recalculée par la tâche de 00:01 (heure de la ville, un passage par fuseau) et servie avec Cache-Control: s-maxage={secondes jusqu'à minuit local}. Cloudflare devant le serveur, avec une règle « Cache Everything » sur le HTML (il ne le garde pas par défaut) et une purge par adresse quand une page est recalculée. Fêtes, parachiot, outils : 24 h.
• Calcul : un paquet moed-engine (les fonctions de l'app, en TypeScript, @hebcal/core + kosher-zmanim), appelé côté serveur ; le navigateur ne reçoit que le résultat. Le délai « dans 1 h 05 » vient d'un petit script (< 3 Ko) qui lit les heures déjà écrites dans la page.
• Parité avec l'app : la matrice de validation (NATIVE_SPEC.md §3) tourne chaque nuit contre le site, avec les règles de §6.1 ; une différence de plus d'une minute bloque la mise en production.
• Villes : GeoNames (cities15000 + toutes les localités d'Israël), altitude et fuseau.
• Polices : celles du système d'abord (SF Pro sur Apple), puis Inter, Source Serif 4, Frank Ruhl Libre et Noto Sans Hebrew servies par le site, en sous-ensembles latin et hébreu (les maquettes le font déjà : mockups/assets/fonts/). Aucun appel à Google Fonts : la construction le vérifie.
• Vitesse : HTML rendu au serveur, aucune bibliothèque côté client hors les formulaires ; objectifs LCP < 1,5 s, CLS 0, INP < 100 ms sur téléphone moyen ; images en AVIF/WebP avec dimensions.
• Mode sombre : suit le réglage de l'appareil (prefers-color-scheme), comme l'app ; clair par défaut. Ambre sombre #FF9F45.
• Accessibilité : lien « Aller au contenu », focus visible sur tout ce qui se touche, cibles de 44 px sur téléphone, contraste ≥ 4,5:1 partout (les heures passées restent en gris lisible, seule l'icône s'efface), ambre #B4500A (5,1:1 sur blanc), aucune information portée par la couleur seule (chaque point de couleur a son symbole), prefers-reduced-motion respecté, hébreu isolé (<bdi lang="he">) dans les pages de gauche à droite et latin isolé dans les pages hébraïques, flèches retournées en hébreu.

7. Indexation, ouverture et autorité

7.1 Ce que Google reçoit

• Search Console : une propriété de domaine moedcal.com (DNS), plus une propriété par dossier de langue.
• Sitemaps : un index sitemap.xml qui renvoie à un fichier par langue et par type, < 10 000 adresses chacun, avec xhtml:link pour les langues. lastmod exact pour les pages qui changent rarement ; pas de lastmod pour les pages ville, qui changent chaque jour.
• Bing Webmaster Tools + IndexNow pour les pages qui changent (fêtes de l'année, nouvelles villes).
• robots.txt : bloque seulement la recherche interne et les exports iCal. ?date= et ?d= ne sont pas bloqués : ils portent noindex et une canonique, que Google doit pouvoir lire ; on ne leur fait aucun lien explorable.

7.2 Le seuil d'une ville indexée

Une ville n'est indexée que si sa page a au moins trois blocs que la formule ne produit pas et que Hebcal n'a pas : 1. la coutume d'allumage et de sortie de la ville, avec sa source (rabbinat, consistoire, communauté) ; 2. au moins deux synagogues avec leurs horaires d'office ou leur lien ; 3. un texte écrit sur la communauté, relu par un humain. Sinon elle reste en noindex et apparaît comme une ligne de la page de son pays (indexée). Le contenu local vient des partenaires de §7.4 et du relecteur ; il n'est jamais généré.

7.3 Ouverture par étapes, avec des seuils

• Lancement : ≈ 730 pages (§4). On attend 6 à 8 semaines.
• Passage à l'étape suivante (plus de villes, ou les langues de l'étape 2), mesuré par type de page dans Search Console : ≥ 40 % des pages envoyées indexées, « Explorée, actuellement non indexée » < 30 %, et au moins 20 domaines référents.
• Gel : au-dessus de 30 % d'« explorée, non indexée » sur un type de page, on n'ouvre plus rien de ce type et on repasse en noindex les pages les plus faibles.
• États-Unis et Canada : pages par quartier à communauté (Brooklyn, Crown Heights, Lakewood, Los Angeles…) à l'étape 2, d'abord dix, avec un test d'indexation avant tout élargissement ; pas de pages par code postal avant ce test.

7.4 Le plan d'autorité et de liens (avant la mise en ligne)

1. Widget à intégrer pour les synagogues, écoles et communautés : un <iframe> ou un script qui affiche l'allumage et la sortie de leur ville, avec l'attribution fixe « Horaires : Moed » en lien rel="nofollow". Ancre de marque, jamais un mot-clé : un lien de widget optimisé est du spam de liens pour Google. La valeur vient du trafic et des mentions.
2. API publique et flux : JSON des horaires par ville, iCal et RSS par ville, gratuits et documentés sur /widget/, données sous licence ouverte avec attribution. C'est ce qui a donné à Hebcal ses milliers de liens.
3. Annuaires et partenaires : une liste nominative de 50 organisations (consistoires régionaux, FSJU, communautés locales, centres Chabad, fédérations en Israël et aux États-Unis), un courriel chacune avec la page de sa ville prête et le widget, suivi dans un tableau. Elles fournissent aussi le contenu local du seuil §7.2.
4. Contenu à citer : des pages tirées des calculs que la presse reprend (le jour le plus court et le plus long par ville, l'écart de Chabbat entre Tel-Aviv et Reykjavik, l'heure d'allumage dans le Grand Nord), proposées à Times of Israel, Jewish Press, Actualité Juive, Tribune Juive, Hamodia.
5. Un relecteur nommé : relecteur à désigner (un rabbin pour la halakha), avec sa page sur le site ; c'est le signal de confiance le plus fort de la niche. Tant qu'il n'est pas désigné, aucune page ne parle de relecture.
6. Entité : identifiants Wikidata des fêtes et parachiot dans le glossaire ; mentions sur Reddit, forums et groupes communautaires (trafic et marque, pas de lien suivi). La fiche App Store pointe vers le site.

Objectif : 20 à 50 domaines référents en trois mois, condition du passage à l'étape suivante (§7.3).

8. Production des langues

1. Glossaire par langue (avant toute traduction) : 12 mois hébreux, 54 parachiot, 40 fêtes et jeûnes, 25 noms de zmanim, mots de chemin. Français : la table de §13. Hébreu : le propriétaire. Autres : écrit par le modèle, validé par le relecteur natif.
2. Gabarits (les phrases de l'interface, ~600 chaînes en ICU MessageFormat) : traduits par Claude avec le glossaire imposé.
3. Contrôle automatique à chaque construction, bloquant : toutes les clés et tous les paramètres présents ; glossaire respecté ; formats de date et d'heure de la langue (Intl, 12 h en anglais), sens d'écriture ; titre ≤ 60, description ≤ 155 ; réciprocité hreflang ; aucun appel à Google Fonts ; capture Playwright d'une page de chaque type à 390 et 1440 px, sans défilement horizontal.
4. Relecture humaine : tous les gabarits et le glossaire de chaque langue avant son ouverture (décision 7). Le contrôle automatique s'ajoute, il ne remplace pas.
5. Articles : écrits en français (propriétaire), traduits et relus pour he et en ; adaptés (pas traduits mot à mot) pour les langues de l'étape 2.

9. Les 30 premiers articles

Classés par intérêt de recherche (estimation : volume de la famille de requêtes × durée de la saison).

Rythme : deux articles par semaine en français, traduits en he et en dans la semaine ; les sujets saisonniers sont publiés au moins 8 semaines avant la fête.

10. Le lien avec l'app

• Bannière native de Safari sur iPhone : <meta name="apple-itunes-app" content="app-id=6790553505, app-argument={adresse de la page}"> (les maquettes la portent) ; l'app ouvre l'écran correspondant (ville, fête, tsadik) quand elle reçoit l'argument. Ce n'est pas un interstitiel. Rien d'autre ne recouvre la page.
• Badge officiel « Télécharger dans l'App Store », fichier d'Apple dans la langue de la page, à deux places seulement : la carte « Ces horaires sur votre iPhone » de chaque page et le bloc de l'app sur l'accueil. Le pied de page n'a qu'un lien texte ; le bouton « Obtenir l'app » de la barre du haut n'existe que sur ordinateur (sur téléphone, la bannière Safari en tient lieu et la place va à la ville et à la langue).
• Android : tant que l'app n'existe pas, le bouton et le badge sont masqués sur Android.
• Liens suivis : chaque lien App Store porte ?ct={place}-{langue} (header, ville, fete, outil, accueil, footer) pour savoir quelles pages amènent des téléchargements.

11. Les risques et ce qu'on fait

12. Ordre de construction

1. Compte Google Ads pour Keyword Planner ; volumes mesurés ; liste des villes du lancement (§7.2) et des langues (§3).
2. Paquet de calcul partagé avec les règles de §6.1 + test de parité (tout dépend de lui). Décision sur l'altitude de l'allumage, dans l'app et le site ensemble.
3. Relecteur désigné ; page Méthode ; table des coutumes relue ; contenu local des ≈ 210 villes avec les partenaires (§7.4, point 3).
4. Gabarits fr/he/en des pages ville, pays, fête × année, convertisseur, accueil ; widget, API et flux ; sitemaps ; Search Console. Mise en ligne (≈ 730 pages).
5. Paracha, calendrier de l'année, tsadikim, yahrzeit, bar-mitsva, guématria, omer. Articles (2 par semaine, saisonniers 8 semaines avant).
6. Après 6 à 8 semaines, si les seuils de §7.3 sont tenus : plus de villes, quartiers des États-Unis, langues de l'étape 2.

13. Glossaire français (translittération)

Une seule convention, celle de l'app (moed-ios/DESIGN.md §12), étendue aux parachiot : ch pour ש, h pour ח ('h quand le h se collerait à la consonne d'avant ou finirait le mot : min'ha, Noa'h), kh pour כ sans dagech, tz pour צ, accent aigu sur le é prononcé.

• Zmanim : Chabbat, Chéma, Tefila, hatzot, minha guedola, minha ketana, plag hamin'ha, chkia, tzeit, netz, michéyakir, Rabbénou Tam, Maguen Avraham, Gaon de Vilna.
• Mois : Tichri, Hechvan, Kislev, Tevet, Chevat, Adar (I, II), Nissan, Iyar, Sivan, Tamouz, Av, Eloul.
• Fêtes : Roch Hachana, Kippour, Soukkot, Simhat Torah, Hanoukka, Tou Bichvat, Pourim, Pessah, Chavouot, Roch Hodech, Issrou Hag ; hiloula / hilloulot (orthographe de l'app : un l au singulier, deux au pluriel).
• Parachiot (début) : Béréchit, Noa'h, Lekh Lekha, Vayéra, Hayé Sarah, Toledot, Vayétzé, Vayichla'h, Vayéchev, Miketz, Vayigach, Vayé'hi.
• Autres : paracha, haftara, yahrzeit, hanoukkia, chamach, tossefet Chabbat, Chabbat Mevarkhim, les Maccabées.