---
title: Content dialect
description: The one field migrated MDX almost always needs.
---

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.