Design: Multilingual pattern plugins for harvest extractor

[filhocf]

Hey @doobidoo — another design-first proposal per #870 guidelines.

Problem

The harvest extractor uses hardcoded English regex patterns ("decided", "root cause", "convention:", "learned that"). Non-English users get dramatically fewer candidates — in our case (Portuguese), harvest found 9 candidates vs 75 with locale patterns enabled. That's an 8x gap.

This affects any user whose conversations happen in a non-English language.

Proposed Design

YAML-based pattern plugins loaded at startup:

src/mcp_memory_service/harvest/patterns/
├── __init__.py      # loader: reads YAML, merges with built-in English
├── en.yaml          # existing English patterns (extracted from code)
└── pt_BR.yaml       # Portuguese patterns (example)

Loading mechanism:

• HARVEST_LOCALE=en,pt_BR env var controls which files to load
• Default: en only (backward compatible)
• Patterns are additive — each locale adds regex patterns per category (decision, bug, convention, learning, context)

YAML format:

decision:
  - "decidimos"
  - "decisão:"
  - "vou usar .* em vez de"
bug:
  - "causa raiz"
  - "o problema era"

No changes to extraction logic — only the pattern list grows. Same confidence scoring, same dedup.

Why not LLM-based?

LLM classification (Phase 2 in harvest) already exists as opt-in. This proposal is for the regex Phase 1 — fast, deterministic, zero-cost. The two are complementary.

Scope

• harvest/patterns/__init__.py — YAML loader
• harvest/patterns/en.yaml — extract existing patterns
• harvest/patterns/pt_BR.yaml — Portuguese example
• harvest/extractor.py — use loaded patterns instead of hardcoded

Thoughts? The implementation is straightforward — main question is whether YAML plugins is the right format or if you'd prefer something else.

[doobidoo]

Design approved retroactively — this is exactly what #935 implements.

PR #935 merged yesterday (2026-05-15) with HARVEST_LOCALE=en,pt_BR,de support via YAML-based pattern plugins. The instance-level self._patterns in PatternExtractor.__init__ approach won out over module-level for testability reasons.

Your 8x candidate improvement (75 vs 9 per session) became the headline number in the PR description — a compelling case for locale support. Portuguese and German patterns are both in the initial merge; adding further locales is now a one-YAML-file contribution.

Thanks for the careful design-first write-up — it made the implementation review straightforward.