- For i18n I already have some idea on how this could work, as it was a reported issue: https://github.com/vriteio/vrite/issues/7 https://github.com/vriteio/vri

- For i18n I already have some idea on how this could work, as it was a reported issue: https://github.com/vriteio/vrite/issues/7 https://github.com/vriteio/vrite/issues/7 - When integrating with Git, I agree that having a single source of truth is important. In the ideal case I'd like it to work a bit like Git in VS Code. The edited content is still stored in Vrite, though it can be committed and pushed to or pulled from Git to sync. Kanban wouldn't work for that though (unless it's Vrite-only for management purposes) and some other view to represent the structure of the "documentation project" would have to be used. Also, when syncing with files in Git, some kind of format would have to be used to convert the content back and forth. Not everyone might want to use standard Markdown or MarkDoc (especially if they already have some docs in your custom format), so this should likely be customizable as well (with good defaults). - I won't really be pushing Vrite into docs-as-code and other spaces like this. The primary use-case is dev marketing (right now) and general documentation like usage guides, explainations, etc., where the content is primarly text with addition of code (in the future). Wrote more on this in this comment: https://news.ycombinator.com/item?id=36339020 https://news.ycombinator.com/item?id=36339020 - Features like versioning, comments and edit requests are planned. Vrite already saves the history of your edits, so it's a matter of implementing a proper UI to view that. - I agree that companies won't jump on the tool that they'll have to first develop custom extensions for. That said, the idea with extensions (and Vrite being open-source) is that, once an extension system is ready, community will be able to build and publish extensions, hopefully growing the collection as a whole. I know it's rather hard to pull of, but still possible. That's another inspiration from VS Code, btw. - The features to fetch code snippets or handle contribution licensing make sense, though they are quite specific. In dev marketing (and often times in docs) you'll still need to write small, custom code snippets that don't necessarily exist anywhere else in the first place. On the other hand, licensing sounds like a custom need to me, and it would make most sense if it was available as an extension. - In general, my approach to adding features is to create something as simple as possible, but highly versitile. I think highly-specific features can quickly bog-down the entire product (and its codebase). It's not always easy, but to give you a few examples for features you've discussed: > I18N could be handled with "content variants" which would also be useful when you need to slightly adjust the content for different endpoints (though, in some cases maybe conditional inline content blocks would be better for that) > Code snippet fetching/sync - likely a system of custom content blocks would be best for this and many other use-cases. You'll still be able to create entirely custom block that fetches content and displays it in a read-only editor or just simple view with syntax highlighting). These could be added via extensions. Adding this functionality to built-in code blocks (either directly or through hooks or something) would be too complex for the core, imo. > Licensing - don't have anything good for this one as of yet, but likely some hooks in the mids of the editing process.