Content dialect

If your MDX came from another documentation platform, content.dialect is the field that decides whether it builds.

json

{ "content": { "dialect": "mintlify" } }

Valid values are exactly "reed", "fern" and "mintlify". The default is "reed" — Reed’s own canonical, dialect-independent authoring form.

Nothing else is accepted. Writing "mint" is rejected by the schema:

Invalid enum value. Expected 'reed' | 'fern' | 'mintlify', received 'mint'

mint is a template name, not a dialect. The two vocabularies are separate, and mixing them fails loudly rather than silently picking one.

Why the same markup means two things

ParamField’s path attribute is spelled identically in Fern’s and Mintlify’s docs and means different things in each:

• Fern’s <ParamField path="limit"> uses path as the parameter’s name.
• Mintlify’s <ParamField path="limit"> uses path as the parameter’s location — an implicit in: "path" — and expects the name to come from elsewhere.

Reed’s canonical ParamField requires a name prop. So a page of Mintlify-authored MDX, left at the default dialect, fails reed check with:

✗ [DS-S03] content file "....mdx"'s "ParamField" is missing required prop "name" (contract: ParamField)

Setting content.dialect: "mintlify" makes Reed read path as a location shorthand, and the same page passes cleanly. content.dialect: "fern" switches the mapping for content migrated from Fern, where path genuinely does mean the parameter’s name.

Choosing

Set the dialect your MDX was written in, not the one you wish it were. The field changes how existing markup is interpreted; it does not convert files. One project has one dialect — there is no per-page override, so content from two upstream platforms has to be normalized before it can share a site.