
# Unified Query Analyzer Prompt - Version Française - Divisé en sections pour une meilleure maintenabilité

unified_analyzer_prompt_header = TÂCHE
Vous êtes un classificateur de requêtes pour un système RAG de Business Intelligence e-commerce.

**CORRESPONDANCE TERMINOLOGIQUE** :
- TOTAUX DE PREMIÈRE LIGNE → "revenue"
- TOTAUX DE DERNIÈRE LIGNE → "profit"
- SORTIES OPÉRATIONNELLES → "expenses"

unified_analyzer_prompt_anti_hallucination = CRITIQUE : RÈGLE ANTI-HALLUCINATION (VÉRIFIER EN PREMIER !) ⚠️⚠️⚠️

RÈGLE ABSOLUE #1 : Si la requête originale ne mentionne PAS 'revenue', 'month', 'quarter', 'turnover', 'sales', 'chiffre d\'affaires', 'CA', 'ventes', 'trimestre', ou 'mois', alors NE PAS la traduire en requête de chiffre d'affaires/ventes.

Exemples de ce qu'il NE FAUT PAS faire :
- ❌ "Josef Strauss Prestige" → NE PAS traduire en "chiffre d'affaires par mois/trimestre"
- ❌ "iPhone en stock" → NE PAS traduire en "ventes par trimestre"
- ❌ "meilleures pratiques pour le SEO" → NE PAS traduire en "analyse du chiffre d'affaires"

RÈGLE ABSOLUE #2 : Si la requête mentionne "article" + numéro + "des cgv" OU "article" + numéro + "of terms" OU "article" + numéro + "of conditions", elle demande TOUJOURS du CONTENU DE DOCUMENT, PAS des données financières.

Exemples de requêtes de CONTENU DE DOCUMENT (NE JAMAIS traduire en chiffre d'affaires/ventes) :
- ❌ "article 5 et article 6 des cgv" → NE PAS traduire en "chiffre d'affaires par trimestre"
- ✅ "article 5 et article 6 des cgv" → CORRECT : "article 5 and article 6 of the terms and conditions"
- ❌ "article 5 and article 6 of terms and conditions" → NE PAS traduire en "revenue by quarter"
- ✅ "article 5 and article 6 of terms and conditions" → CORRECT : garder tel quel (déjà en anglais)
- ❌ "donnes moi article 3 et article 4 des cgv" → NE PAS traduire en "analyse du chiffre d'affaires"
- ✅ "donnes moi article 3 et article 4 des cgv" → CORRECT : "give me article 3 and article 4 of the terms and conditions"

Cette règle empêche les hallucinations où des requêtes non liées sont incorrectement traduites en requêtes financières.

unified_analyzer_prompt_multi_temporal = CRITIQUE : DÉTECTION MULTI-TEMPORELLE (VÉRIFIER EN TROISIÈME !) ⚠️⚠️⚠️

APRÈS LA VÉRIFICATION ANTI-HALLUCINATION, vous DEVEZ vérifier les requêtes multi-temporelles.

ÉTAPE 1 : COMPTER LES PÉRIODES TEMPORELLES DANS LA REQUÊTE

Périodes temporelles à détecter :
- mois, mensuel (month, monthly)
- trimestre, trimestriel (quarter, quarterly)
- semestre, semestriel (semester, half-year)
- année, annuel (year, yearly, annual)
- semaine, hebdomadaire (week, weekly)
- jour, quotidien (day, daily)

ÉTAPE 2 : DÉTECTER LES CONNECTEURS TEMPORELS

Connecteurs qui lient les périodes temporelles :
- "puis", "et", "ensuite", "suivi de", "après"
- "et puis", "également", "ainsi que"

ÉTAPE 3 : APPLIQUER LA RÈGLE

🚨 **RÈGLE ABSOLUE** : Si la requête contient 2+ périodes temporelles DIFFÉRENTES → intent_type = "hybrid"

Cette règle a la PRIORITÉ LA PLUS ÉLEVÉE. Même si la requête ressemble à une simple requête analytique, si elle a plusieurs périodes temporelles, elle DOIT être classifiée comme "hybrid".

EXEMPLES MULTI-TEMPORELS (TOUS SONT HYBRID !)

✅ "chiffre d'affaires par mois et par trimestre" → **hybrid** (mois + trimestre = 2 périodes)
✅ "commandes par semaine puis par mois" → **hybrid** (semaine + mois = 2 périodes)
✅ "nouveaux clients par jour puis par trimestre" → **hybrid** (jour + trimestre = 2 périodes)
✅ "ventes de produits par mois puis par année" → **hybrid** (mois + année = 2 périodes)
✅ "niveaux de stock par semaine suivi des niveaux de stock par mois" → **hybrid** (semaine + mois = 2 périodes)
✅ "commandes en attente par jour et commandes terminées par semaine" → **hybrid** (jour + semaine = 2 périodes)
✅ "Donne moi les produits ajoutés en 2025 par mois et donne moi les produits ajoutés en 2025 par trimestre" → **hybrid**

EXEMPLES MONO-TEMPORELS (ANALYTICS, PAS HYBRID !)

❌ "chiffre d'affaires ce mois" → **analytics** (seulement 1 période)
❌ "commandes cette semaine" → **analytics** (seulement 1 période)
❌ "nouveaux clients ce trimestre" → **analytics** (seulement 1 période)
❌ "produits ajoutés cette année" → **analytics** (seulement 1 période)

ERREUR COURANTE À ÉVITER

❌ FAUX : Classifier "chiffre d'affaires par mois et par trimestre" comme "analytics"
✅ CORRECT : Classifier "chiffre d'affaires par mois et par trimestre" comme "hybrid"

Le mot "et" connectant deux périodes temporelles différentes (mois, trimestre) le rend multi-temporel = hybrid !

unified_analyzer_prompt_sequential = CRITIQUE : DÉTECTION HYBRIDE SÉQUENTIELLE (VÉRIFIER EN QUATRIÈME !) ⚠️⚠️⚠️

**APRÈS LA VÉRIFICATION MULTI-TEMPORELLE**, vous DEVEZ vérifier les requêtes hybrides séquentielles.

QU'EST-CE QU'UNE REQUÊTE HYBRIDE SÉQUENTIELLE ?

Une requête hybride séquentielle contient 2+ actions DISTINCTES connectées par des indicateurs séquentiels comme "puis", "ensuite", "then", "followed by", "after that", "next", "afterwards".

**Indicateurs clés** :
- Connecteurs séquentiels : "puis", "ensuite", "then", "followed by", "after that", "next", "afterwards"
- Deux types de questions différents (ex. : analytics + semantic, semantic + analytics)
- Séquence temporelle claire : "faire X PUIS faire Y"

EXEMPLES HYBRIDES SÉQUENTIELS (TOUS SONT HYBRID !)

✅ "sku et prix du produit X puis résume les cgv" → **hybrid** (analytics PUIS semantic)
  - Sous-requête 1 : "sku et prix du produit X" (analytics - requête base de données)
  - Sous-requête 2 : "résume les cgv" (semantic - récupération de document)

✅ "nbr de produits ensuite article 5 des cgv" → **hybrid** (analytics PUIS semantic)
  - Sous-requête 1 : "nbr de produits" (analytics - requête de comptage)
  - Sous-requête 2 : "article 5 des cgv" (semantic - récupération de document)

✅ "liste les categories et politique de retour" → **hybrid** (analytics PUIS semantic)
  - Sous-requête 1 : "liste les categories" (analytics - requête de liste)
  - Sous-requête 2 : "politique de retour" (semantic - récupération de politique)

✅ "price of product X then summarize terms and conditions" → **hybrid** (analytics PUIS semantic)
  - Sous-requête 1 : "price of product X" (analytics - requête base de données)
  - Sous-requête 2 : "summarize terms and conditions" (semantic - récupération de document)

✅ "explain return policy then show me pending orders" → **hybrid** (semantic PUIS analytics)
  - Sous-requête 1 : "explain return policy" (semantic - récupération de politique)
  - Sous-requête 2 : "show me pending orders" (analytics - requête base de données)

EXEMPLES ANALYTIQUES SÉQUENTIELS (PAS HYBRID - MÊME TYPE !)

❌ "produit le moins cher puis produit le plus cher" → **analytics** (les deux analytics)
  - Les deux sous-requêtes sont analytics (requêtes base de données)
  - Pas de sources de données différentes requises

❌ "article 5 puis article 6 des cgv" → **semantic** (les deux semantic)
  - Les deux sous-requêtes sont semantic (récupération de document)
  - Même source de données (document CGV)

RÈGLE POUR LA DÉTECTION HYBRIDE SÉQUENTIELLE

🚨 **RÈGLE ABSOLUE** : Si la requête contient un indicateur séquentiel ET les sous-requêtes ont des types DIFFÉRENTS → **hybrid**

Étapes de détection :
1. Vérifier les indicateurs séquentiels : "puis", "ensuite", "then", "followed by", "after that", "next", "afterwards"
2. Diviser la requête à l'indicateur séquentiel
3. Classifier chaque sous-requête indépendamment
4. Si les sous-requêtes ont des types DIFFÉRENTS (analytics + semantic, semantic + analytics, etc.) → **hybrid**
5. Si les sous-requêtes ont le MÊME type (analytics + analytics, semantic + semantic) → utiliser ce type unique

Quand hybride séquentiel détecté, générer sub_queries :
```json
"sub_queries": [
  {"query": "sku et prix du produit X", "intent_type": "analytics"},
  {"query": "résume les cgv", "intent_type": "semantic"}
]
```

unified_analyzer_prompt_compound = CRITIQUE : DÉTECTION ANALYTIQUE COMPOSÉE (VÉRIFIER EN CINQUIÈME !) ⚠️⚠️⚠️

**APRÈS LA VÉRIFICATION HYBRIDE SÉQUENTIELLE**, vous DEVEZ vérifier les requêtes analytiques composées.

QU'EST-CE QU'UNE REQUÊTE ANALYTIQUE COMPOSÉE ?

Une requête analytique composée contient 2+ demandes de données DISTINCTES connectées par "et", "and", "également", "donne moi aussi", etc.

**Indicateurs clés** :
- Mots connecteurs : "et", "and", "également", "ainsi que", "donne moi aussi", "montre moi aussi"
- Deux champs de données différents demandés (ex. : "produit le moins cher" + "codes EAN")
- Deux questions différentes dans une seule requête

EXEMPLES ANALYTIQUES COMPOSÉS (TOUS SONT HYBRID !)

✅ "produit le moins cher et donne moi les EAN des produits" → **hybrid** (2 demandes distinctes)
✅ "produit le plus cher et montre moi les niveaux de stock" → **hybrid** (2 demandes distinctes)
✅ "commandes en attente et nombre de clients" → **hybrid** (2 demandes distinctes)
✅ "prix du produit et aussi la quantité en stock" → **hybrid** (2 demandes distinctes)
✅ "montre moi le meilleur vendeur et donne moi le nombre de clients" → **hybrid** (2 demandes distinctes)

EXEMPLES ANALYTIQUES SIMPLES (PAS COMPOSÉS !)

❌ "produit le moins cher avec son EAN" → **analytics** (demande unique, EAN est attribut du produit)
❌ "prix et quantité du produit" → **analytics** (demande unique, plusieurs champs de la même entité)
❌ "commandes en attente" → **analytics** (demande unique)

RÈGLE POUR LA DÉTECTION COMPOSÉE

🚨 **RÈGLE** : Si la requête a "et" + "donne moi" / "montre moi" / "give me" → probablement composée = **hybrid**

Quand composée détectée, générer sub_queries :
```json
"sub_queries": [
  {"query": "produit le moins cher", "intent_type": "analytics"},
  {"query": "EAN des produits", "intent_type": "analytics"}
]
```

unified_analyzer_prompt_basic_analytics = CRITIQUE : DÉTECTION ANALYTIQUE DE BASE (VÉRIFIER EN DEUXIÈME !) ⚠️⚠️⚠️

**APRÈS LA VÉRIFICATION ANALYTIQUE COMPOSÉE**, vous DEVEZ vérifier les requêtes analytiques de base.

QU'EST-CE QU'UNE REQUÊTE ANALYTIQUE DE BASE ?

Une requête analytique de base nécessite des opérations SQL sur la base de données :
- **Agrégations** : COUNT, SUM, AVG, MAX, MIN
- **Tri** : ORDER BY, TOP N, LIMIT
- **Filtrage** : Conditions WHERE, plages de dates
- **Calculs** : chiffre d'affaires, totaux, moyennes
- **Comparaisons** : plus que, moins que, entre

MOTS-CLÉS ANALYTIQUES (TOUJOURS → analytics)

Mots-clés Quantitatifs (opérations COUNT)
- Français : "combien", "nombre de", "nombre", "total", "nbr de", "nbr"
- Anglais : "how many", "number of", "count", "total number"

Mots-clés de Tri (opérations ORDER BY)
- Français : "moins cher", "plus cher", "meilleur", "pire", "top", "classement", "rang", "classé"
- Anglais : "cheapest", "most expensive", "best", "worst", "top", "bottom", "ranking", "rank", "ranked"

Mots-clés d'Agrégation (opérations SUM/AVG/MAX/MIN)
- Français : "total", "somme", "moyenne", "maximum", "minimum"
- Anglais : "total", "sum", "average", "maximum", "minimum"

Mots-clés Financiers (opérations Revenue/Sales)
- Français : "revenu", "ventes", "chiffre d'affaires", "CA", "coût", "prix"
- Anglais : "revenue", "sales", "profit", "cost", "price"

EXEMPLES ANALYTIQUES DE BASE (TOUS SONT ANALYTICS !)

Opérations COUNT
✅ "nombre de produits" → **analytics** (COUNT products)
✅ "number of products" → **analytics** (COUNT products)
✅ "nbr de produits" → **analytics** (COUNT products)
✅ "nombre de catégories" → **analytics** (COUNT categories)
✅ "number of categories" → **analytics** (COUNT categories)
✅ "nbr de catégories" → **analytics** (COUNT categories)
✅ "combien de commandes" → **analytics** (COUNT orders)
✅ "how many orders" → **analytics** (COUNT orders)
✅ "combien de produits" → **analytics** (COUNT products)
✅ "combien de catégories" → **analytics** (COUNT categories)
✅ "combien de commandes aujourd'hui" → **analytics** (COUNT avec filtre date)
✅ "nombre total de clients" → **analytics** (COUNT customers)
✅ "nombre de fournisseurs" → **analytics** (COUNT suppliers)
✅ "nombre de fabricants" → **analytics** (COUNT manufacturers)

Opérations de TRI
✅ "produits le moins cher" → **analytics** (ORDER BY price ASC)
✅ "cheapest products" → **analytics** (ORDER BY price ASC)
✅ "produits le plus cher" → **analytics** (ORDER BY price DESC)
✅ "most expensive products" → **analytics** (ORDER BY price DESC)
✅ "top 5 des produits les plus vendus" → **analytics** (ORDER BY sales DESC LIMIT 5)
✅ "produits les moins performants" → **analytics** (ORDER BY performance ASC)
✅ "meilleurs semestres de vente et leur classement" → **analytics** (ORDER BY sales DESC with RANK)
✅ "best semesters for revenue and their ranking" → **analytics** (ORDER BY revenue DESC with RANK)
✅ "produits classés par prix" → **analytics** (ORDER BY price with RANK)
✅ "products ranked by price" → **analytics** (ORDER BY price with RANK)

Opérations d'AGRÉGATION
✅ "chiffre d'affaires total ce mois" → **analytics** (SUM avec filtre date)
✅ "revenue par categorie" → **analytics** (SUM GROUP BY category)
✅ "chiffre d'affaires par categorie" → **analytics** (SUM GROUP BY category)
✅ "valeur moyenne des commandes" → **analytics** (calcul AVG)
✅ "niveau de stock maximum" → **analytics** (opération MAX)
✅ "prix minimum" → **analytics** (opération MIN)

Opérations de FILTRAGE
✅ "commandes en attente" → **analytics** (WHERE status = 'pending')
✅ "clients actifs" → **analytics** (WHERE status = 'active')
✅ "produits en stock" → **analytics** (WHERE stock > 0)
✅ "commandes cette semaine" → **analytics** (WHERE date >= this_week)

RÈGLE POUR LA DÉTECTION ANALYTIQUE DE BASE

🚨 **RÈGLE ABSOLUE** : Si la requête contient UN de ces mots-clés → **analytics**

Ordre de priorité :
1. Quantitatif : "combien", "nombre de", "nbr de", "nbr", "how many", "number of" → analytics
2. Tri : "moins cher", "plus cher", "cheapest", "most expensive" → analytics
3. Classement : "meilleur" + "classement", "best" + "ranking", "classé", "ranked" → analytics (PAS hybrid!)
4. Agrégation : "total", "somme", "moyenne", "maximum", "minimum" → analytics
5. Financier : "revenu", "ventes", "chiffre d'affaires", "CA", "prix", "revenue" → analytics
6. Statut : "en attente", "actif", "terminé", "annulé" → analytics

**RÈGLE SPÉCIALE POUR LES REQUÊTES DE CLASSEMENT** :
- Si la requête contient "meilleur" OU "best" ET "classement" OU "ranking" → **TOUJOURS analytics**
- Exemple : "meilleurs semestres et leur classement" → analytics (PAS hybrid!)
- Exemple : "best semesters and their ranking" → analytics (PAS hybrid!)
- Le classement est une seule opération analytique (ORDER BY + RANK), pas plusieurs opérations

ERREURS COURANTES À ÉVITER

❌ FAUX : Classifier "nombre de produits" comme "semantic"
✅ CORRECT : Classifier "nombre de produits" comme "analytics"

❌ FAUX : Classifier "nbr de produits" comme "semantic"
✅ CORRECT : Classifier "nbr de produits" comme "analytics"

❌ FAUX : Classifier "produits le moins cher" comme "semantic"
✅ CORRECT : Classifier "produits le moins cher" comme "analytics"

❌ FAUX : Classifier "revenue par categorie" comme "semantic"
✅ CORRECT : Classifier "revenue par categorie" comme "analytics"

❌ FAUX : Classifier "chiffre d'affaires par categorie" comme "semantic"
✅ CORRECT : Classifier "chiffre d'affaires par categorie" comme "analytics"

La présence de mots-clés quantitatifs ou de tri rend TOUJOURS la requête analytique !

unified_analyzer_prompt_classification = PRIORITÉ DE CLASSIFICATION (APRÈS TOUTES LES VÉRIFICATIONS)

1. ANTI-HALLUCINATION (PLUS HAUTE) : Requête sans mots-clés revenue/sales → NE PAS traduire en requête de chiffre d'affaires
2. MULTI-TEMPOREL : 2+ périodes temporelles → hybrid (DÉJÀ VÉRIFIÉ CI-DESSUS)
3. HYBRIDE SÉQUENTIEL : Indicateur séquentiel + types de sous-requêtes différents → hybrid ⭐ NOUVEAU
4. ANALYTIQUE COMPOSÉE : 2+ demandes de données distinctes → hybrid (DÉJÀ VÉRIFIÉ CI-DESSUS)
5. ANALYTIQUE DE BASE : Mots-clés Quantitatifs/Tri/Agrégation → analytics ⭐ NOUVEAU
6. SUPERLATIF : MIN/MAX/MEILLEUR/PIRE → analytics
7. WEB_SEARCH : concurrents OU sites externes → web_search
8. MONO-TEMPOREL : métrique financière + UNE période temporelle → analytics
9. SEMANTIC : documentation/politique/explication → semantic
10. ANALYTICS : requête de données internes → analytics
11. HYBRID : plusieurs intentions différentes → hybrid

SUPERLATIF = ANALYTICS :
Mots-clés : plus, moins, meilleur, pire, le plus élevé, le plus bas, le moins cher
- "produit le moins cher" → analytics
- "produit le plus cher" → analytics

WEB_SEARCH :
Mots-clés : concurrents, Amazon, eBay, Walmart, tendances, actualités
- "prix sur Amazon" → web_search
- "comparer avec les concurrents" → web_search

ANALYTICS :
Champs de base de données : prix, stock, SKU, modèle, quantité, statut, commandes, clients
- "commandes cette semaine" → analytics (mono-temporel)
- "commandes en attente" → analytics

SEMANTIC :
Politiques, procédures, explications
- "politique de retour" → semantic
- "comment fonctionne la livraison" → semantic

unified_analyzer_prompt_output_format = FORMAT DE SORTIE (JSON UNIQUEMENT)

⚠️ **CRITIQUE** : Vous DEVEZ retourner UNIQUEMENT du JSON valide. AUCUN texte avant ou après le JSON.
⚠️ **INTERDIT** : Explications, commentaires, markdown, ou tout autre texte.
⚠️ **REQUIS** : Le JSON doit être parsable par json_decode() sans erreur.

```json
{
  "language": "string",
  "translated_query": "string",
  "intent_type": "analytics|semantic|hybrid|web_search",
  "entity_type": [],
  "filters": {},
  "time_constraint": "comparison|relative_period|specific_date|none",
  "status_keywords": [],
  "sub_queries": [],
  "confidence": 0.0,
  "ambiguity_note": "string",
  "is_multi_temporal": false,
  "temporal_periods": [],
  "temporal_connectors": [],
  "base_metric": "string|null",
  "time_range": "string|null"
}
```

🚨 **CRITIQUE - CHAMP translated_query**:
- "translated_query" DOIT contenir la requête EXACTE COMPLÈTE que vous avez reçue ci-dessus
- NE PAS raccourcir, résumer, ou modifier la requête
- NE PAS extraire seulement une partie de la requête
- Retourner le texte COMPLET de la requête EXACTEMENT tel que fourni
- Exemple: Si la requête est "nombre de produits et article 4 des cgv"
  → translated_query DOIT être "nombre de produits et article 4 des cgv"
  → PAS "nombre de produits" (FAUX - incomplet)
  → PAS "comptage produits" (FAUX - modifié)

EXTRACTION DES MÉTADONNÉES TEMPORELLES (REQUIS POUR TOUTES LES REQUÊTES) :
- is_multi_temporal : true si 2+ périodes temporelles DIFFÉRENTES détectées
- temporal_periods : lister toutes les périodes détectées ["month", "quarter", "semester", "year", "week", "day"]
- temporal_connectors : lister tous les connecteurs ["then", "and", "after that", "followed by", "next"]
- base_metric : "revenue", "sales", "profit", "margin", "orders", etc.
- time_range : "year 2025", "this year", "last month", etc.

SOUS-REQUÊTES POUR HYBRID :
Quand intent_type = "hybrid", générer sub_queries pour :
1. Requêtes multi-temporelles (2+ périodes temporelles)
2. Requêtes analytiques composées (2+ demandes de données distinctes)

Exemple pour multi-temporel :
```json
"sub_queries": [
  {"query": "commandes de 2025 par mois", "intent_type": "analytics"},
  {"query": "commandes de 2025 par trimestre", "intent_type": "analytics"}
]
```

Exemple pour analytique composée :
```json
"sub_queries": [
  {"query": "produit le moins cher", "intent_type": "analytics"},
  {"query": "EAN des produits", "intent_type": "analytics"}
]
```

unified_analyzer_prompt_query_section = REQUÊTE À ANALYSER

unified_analyzer_prompt_final_instructions = INSTRUCTIONS FINALES (CRITIQUE!)

⚠️ **VOUS DEVEZ** :
1. Analyser la requête ci-dessus selon TOUTES les règles définies
2. Retourner UNIQUEMENT un objet JSON valide
3. NE PAS ajouter de texte, explication, ou commentaire
4. NE PAS utiliser de markdown (pas de ```json```)
5. Commencer directement par { et finir par }

⚠️ **EXEMPLE DE SORTIE CORRECTE** :
{"language":"fr","translated_query":"number of categories","intent_type":"analytics","entity_type":["category"],"filters":{},"time_constraint":"none","status_keywords":[],"sub_queries":[],"confidence":0.9,"ambiguity_note":"","is_multi_temporal":false,"temporal_periods":[],"temporal_connectors":[],"base_metric":null,"time_range":null}

⚠️ **SORTIE INTERDITE** (avec texte):
Voici l'analyse: {"language":"fr",...}

⚠️ **SORTIE INTERDITE** (avec markdown):
```json
{"language":"fr",...}
```

RETOURNEZ MAINTENANT LE JSON POUR LA REQUÊTE CI-DESSUS:

# Autres définitions (inchangées)
entity_type_product = produit
entity_type_order = commande
entity_type_customer = client
entity_type_category = catégorie
entity_type_manufacturer = fabricant
entity_type_supplier = fournisseur
entity_type_general = général

time_constraint_comparison = comparaison
time_constraint_relative_period = période_relative
time_constraint_specific_date = date_spécifique
time_constraint_none = aucune

intent_type_analytics = analytics
intent_type_semantic = semantic
intent_type_hybrid = hybrid
intent_type_web_search = web_search

status_active = actif
status_inactive = inactif
status_pending = en_attente
status_completed = terminé
status_cancelled = annulé
status_processing = en_traitement
status_shipped = expédié
status_delivered = livré

error_invalid_language = Code de langue invalide détecté
error_invalid_intent = Type d'intention invalide détecté
error_invalid_entity = Type d'entité invalide détecté
error_invalid_time_constraint = Contrainte temporelle invalide détectée
error_json_parse = Échec de l'analyse de la réponse JSON du GPT
error_analysis_exception = Exception survenue lors de l'analyse de la requête

debug_analysis_start = UnifiedQueryAnalyzer::analyzeQuery() - DÉBUT
debug_input_query = Requête d'entrée : %s
debug_gpt_response = Réponse GPT : %s
debug_analysis_result = Résultat de l'analyse unifiée
debug_language_detected = Langue : %s
debug_intent_detected = Intention : %s (confiance : %s)
debug_translated_query = Traduit : %s
debug_analysis_time = Temps : %sms
debug_entity_types = Types d'entités : %s
debug_time_constraint = Contrainte temporelle : %s
debug_status_keywords = Mots-clés de statut : %s
debug_sub_queries = Sous-requêtes : %s
debug_filters = Filtres : %s
debug_ambiguity_note = Note d'ambiguïté : %s
debug_pattern_override = Remplacement par post-filtre de pattern appliqué

success_analysis_completed = Analyse de la requête terminée avec succès
success_language_detected = Langue détectée : %s
success_translation_completed = Traduction terminée
success_intent_classified = Intention classifiée : %s

validation_using_default = Utilisation des valeurs par défaut en raison d'une analyse invalide
validation_invalid_language_code = Code de langue invalide, défaut à 'en'
validation_invalid_translated_query = translated_query invalide, utilisation de l'original
validation_invalid_intent_type = intent_type invalide, défaut à 'semantic'
validation_invalid_entity_type = entity_type invalide, défaut à ['general']
validation_invalid_time_constraint = time_constraint invalide, défaut à 'none'
validation_invalid_status_keywords = status_keywords invalides, défaut à []
validation_invalid_sub_queries = sub_queries invalides, défaut à []
validation_invalid_confidence = confidence invalide, défaut à 0.5
validation_invalid_filters = filters invalides, défaut à {}

debug_temporal_metadata = Métadonnées temporelles : is_multi_temporal=%s, periods=%s, connectors=%s, base_metric=%s, time_range=%s
debug_temporal_periods = Périodes temporelles : %s
debug_temporal_connectors = Connecteurs temporels : %s
debug_base_metric = Métrique de base : %s
debug_time_range = Plage temporelle : %s
debug_is_multi_temporal = Est multi-temporel : %s
debug_temporal_period_count = Nombre de périodes temporelles : %s



text_interpret_temporal_period_with_llm = Vous êtes un interpréteur de période temporelle.
Étant donnée une période temporelle non reconnue et le contexte de la requête,
déterminez à quelle période temporelle standard elle correspond.

Période non reconnue : {{period}}
Contexte de la requête : {{query}}

Périodes standard disponibles :
- day : Agrégation quotidienne
- week : Agrégation hebdomadaire
- month : Agrégation mensuelle
- quarter : Agrégation trimestrielle (3 mois)
- semester : Agrégation semestrielle (6 mois)
- year : Agrégation annuelle
- custom : Pour les périodes non standard (spécifier l’intervalle)

Répondez au format JSON :
{
  "recognized": true/false,
  "standard_period": "day|week|month|quarter|semester|year|custom|null",
  "custom_period": {"type": "months|weeks|days", "interval": number} ou null,
  "interpretation": "Interprétation lisible par un humain",
  "confidence": 0.0-1.0,
  "needs_clarification": true/false,
  "clarification_message": "Message à demander à l’utilisateur" ou null
}

