Compatibility boundaries

This page records what the reviewed LibreOffice source catalog establishes and what it does not establish. It is an evidence matrix, not a claim that an installed locale has the same recognition behavior as LibreOffice or Hunspell.

Every row names exactly the .aff/.dic pair in the digest-pinned catalog at LibreOffice/dictionaries commit f2ff99058268502bdcf4cad25c1ca2935ad8aa7d. The catalog verifies the two source-byte digests during ferrolex dictionary fetch; it does not download a license notice and it does not validate a dictionary as part of fetching. See Dictionary fetching for the acquisition contract and Hunspell import contract for the import subset.

Each catalogued pair also has a reviewed SPDX expression and a link to its immutable upstream notice in license evidence. This is provenance for the exact source pair, not legal advice or a blanket statement about the LibreOffice collection.

How to read the status

The columns deliberately use different kinds of evidence:

• Source encoding is a checked catalog fact. Fetching preserves those bytes, so this column is not an assertion that the pair is already usable by a particular importer entry point.
• AFF strict gate is a static scan of the pinned .aff file against the documented importer subset. No known AFF error means that the file uses only supported recognition directives or suggestion-only directives. It is not a successful full-pair import, dictionary-entry audit, or recognition result.
• Strict probe records one current strict import of the digest-verified local source pair. It establishes neither recognition probes nor a reusable fixture.
• Known boundary identifies why validate --strict must currently be expected to reject the pair, or what still needs live evidence. Suggestion directives alone produce warnings and do not fail strict mode; every other unimplemented directive can affect recognition and is an error.

The matrix intentionally has no general supported checkmark yet. A strict fixture is evidence only for the documented ferrolex subset and its recorded probes; broader support also needs a completed source-license review and language-relevant behavior coverage. This keeps a source catalog from turning into an accidental quality promise.

Pinned source matrix

No known AFF error is purposefully weaker than "strict validation passes". For example, strict mode also checks malformed affix rules, dictionary entries, declared encoding, size limits, and flags. Conversely, a blocked locale may still be useful in lenient mode for diagnostic exploration, but lenient output must never be presented as equivalent dictionary recognition.

License evidence

These expressions are reviewed against the named notice at the pinned source revision. OR records an upstream license choice; consumers that redistribute a dictionary must select and comply with one permitted option.

Reproducing and advancing a row

Use an explicit cache, then validate the installed exact bytes. For a current strict-import candidate, prefer install with pl_PL:

ferrolex dictionary install pl_PL --cache .ferrolex-dictionaries

Rows marked Blocked intentionally return exit status 1 from install. That result is diagnostic evidence, not a failed download.

For shared legacy encodings, validate and install select the lossless decoder from the AFF SET declaration. Never relabel or rewrite the fetched cache in place: the cache digest is evidence for the upstream bytes, while the importer decodes only in memory. id_ID is a special case because its AFF and DIC use different encodings; its catalogued install path supplies the reviewed per-file override.

When a row becomes a strict fixture, add an opt-in local fixture that records the source revision, both source digests, decoding, accepted probes, rejected probes, and the source-specific license evidence. The existing real-world fixture procedure is the required format for that evidence. Do not commit third-party dictionary contents merely to make the matrix green.

Explicit scope limits

CJK locales are not catalogued or represented by this matrix. Chinese, Japanese, and Korean need a dedicated text-segmentation contract before a Hunspell pair can be described as text-checking support.

Urdu is also absent, for a different reason: the pinned LibreOffice collection has no Urdu Hunspell pair. It must not be silently substituted with a different source; adding it requires its own provenance, license, encoding, and compatibility review.

Recognition scorecard

The optional external Hunspell oracle produces a per-locale accept/reject scorecard. Reproduce it with:

scripts/fetch-compat-fixtures.sh --set scorecard /tmp/ferrolex-compat-fixtures
FERROLEX_COMPAT_FIXTURES=/tmp/ferrolex-compat-fixtures \
FERROLEX_COMPAT_FIXTURE_SET=scorecard \
FERROLEX_COMPAT_ORACLE=hunspell \
FERROLEX_COMPAT_SCORECARD=/tmp/recognition-scorecard.tsv \
FERROLEX_COMPAT_SCORECARD_BASELINE=crates/ferrolex-hunspell/tests/real_world/scorecard-baseline.tsv \
  cargo test -p ferrolex-hunspell --test real_world -- --nocapture

Weekly, manual, and release compatibility runs invoke Hunspell for the seven scorecard fixtures and compare their deterministic rows with the checked-in baseline. Each artifact records the corpus recipe, oracle command, and oracle version as well as the per-locale agreements, disagreements, and a per-word outcome digest that binds the UTF-8 corpus word and both engine decisions. The 150-minute job limit is based on the preceding 107m10s all-fixture measurement and leaves diagnostic/artifact headroom; it does not claim a faster seven-locale run. The scorecard is evidence for its recorded corpus, not a general Hunspell-parity assertion.