Add language support for Markdoc

[louiss0]

The problem with markdoc is that it has no language support at all. If you guys think about it it's a templating language on top of markdown. I don't know how to create language support but I think it's necessary. Astro and Next.js are relying on it for their futures. Developers get no type inference for the functions or even the basic tags that are used. Someone created a tool called Volar.js which is a tool that allows for the creation of language support. You guys could experiment with this Volar Language Tools Starter. You could talk to the creator himself Johnson Chu

[rpaul-stripe]

Markdoc's schema system supports declaring types for tag attribute values. It also allows you to define custom validation logic for individual custom tags. These features can be used today to validate Markdoc content and ensure that tags are used correctly. We also have experimental support for Markdoc function validation behind a setting. At Stripe, we have an internal VSCode extension that uses our Markdoc schema to display validation errors and enable tag and attribute auto-completion. We're currently refactoring this extension and creating an official VSCode language server for Markdoc that we expect to release as open source later this year.

There's an existing thread about this here: #5

[mfix-stripe]

Markdoc language server out today! #407

[louiss0]

Can you give me an update on this? or at least tell the Astro team and many other people who rely on markdoc to when it's going to be good. People who rely on markdoc need this.

…

On Wed, Feb 22, 2023 at 8:13 AM Ryan Paul ***@***.***> wrote: Markdoc's schema system supports declaring types for tag attribute values. It also allows you to define custom validation logic for individual custom tags. These features can be used today to validate Markdoc content and ensure that tags are used correctly. We also have experimental support for Markdoc function validation behind a setting. At Stripe, we have an internal VSCode extension that uses our Markdoc schema to display validation errors and enable tag and attribute auto-completion. We're currently refactoring this extension and creating an official VSCode language server for Markdoc that we expect to release as open source later this year. There's an existing thread about this here: #5 <#5> — Reply to this email directly, view it on GitHub <#333 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG5PB6K67G6DKV3F4Q7GMQLWYYGF7ANCNFSM6AAAAAAVDXH7QQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[nkohari-stripe]

We can't deliver updates on progress, sorry! Beyond improving our tooling support, is there something specific you need today that Markdoc doesn't do?

[leoplct]

Any updates about how to add i18n for an existing markdoc project?
Basically I need to read from:

• post.en.md
• post.fr.md
• post.es.md

depending on the locale variable from next js i18n

[nkohari-stripe]

I don't think the OP was talking about internationalization, but I'll jump in to answer:

The approach for implementing this would be pretty specific to your project. If you already have localized versions of your files, selecting which one you serve would involve your web server and wouldn't really have anything to do with Markdoc.

If you're asking how to create localized versions of those files, that depends on your approach to localization and is a really deep topic by itself. 😄 At Stripe, the current approach is to walk the Markdoc AST at runtime and replace reference (English) strings with their localized counterparts, which are read from a large hashmap. However, handling it at runtime is pretty inefficient (and only works that way for legacy reasons), so we're moving towards a solution where we do this at build time. It'll be essentially what you described in your post: parsing the Markdoc text, then writing out one copy of the AST per available language.

[leoplct]

So there no way to tell markdoc to process {file_name}.{locale}.md instead of just {file_name}.md ?
We use nextjs + i18n. The locale variable is in the router.