How well does Docusaurus support Weblate?

As I noticed from docusaurus v.1 documentation, the translations support only works for the text and there is nothing with the layout. I want to know is there any plan to support RTL layout for v2? I mean if the translation changes in the website, the layout changes from LTR to RTL. Thanks

An alternative to Algolia search. Working offline, under VPN and in private networks.

Could you please provide additional editUrl like explicitEditUrl which will not append additional paths to the given editUrl for docs and blog presets? Currently if I give an edit url like https://github.com/mysite/docsedit/url/ https://github.com/myblog/blogedit/url/ docusaurus is appending this path with docs/ and blog/ along with the file name like: https://github.com/mysite/docsedit/url/ https://github.com/myblog/blogedit/url/docs/docfile.md https://github.com/myblog/blogedit/url/blog/blogfile.md But instead it would be better to have an explicit editUrl too like editExplicitUrl which will only append the file to this URL. I'm requesting this feature because even though I still keep docs/ and blog/ within my docusaurus site but I want to separate the git repos of site, docs and blog. By doing this I intend to make site repo private and docs and blog repos public repos. Let's say my docusaurus project structure is like this: /my/docusaurus-project/ /my/docusaurus-project/docs /my/docusaurus-project/blog Here docs/ and blog/ could belong to totally different public git repositories. Thanks

Support for AsciiDoc in Docusaurus would be extremely helpful! Markdown works well for simple pages and blog posts, but it lacks standard syntax support for superscript, subscript, definition lists, embedded comments, variables, callouts in code listings, etc. Using HTML for these is not a solution. For example, HTML definition terms can't be linked to from other markdown files. Adding support for GitHub Flavored AsciiDoc, or something like it would address these problems and provide a more powerful documentation solution.

Forcing an MDX parser on users is limiting. Making a distinction between .md and .mdx formats will make it easier for users to use one or the other. While MDX is great, markdown is still the de facto standard and forcing users to tweak their HTML (often auto-generated markdown files) with className and style={{}} wii make many potential users look elsewhere.

Allow users to comment on blog posts and documentation pages via JavaScript-based comment systems such as Disqus!

At the bottom of every GitBook doc page, there's a feedback widget that users can use to provide feedback to the docs maintainers about the page. The traditional way of opening an issue/pull request is usually too troublesome. This feedback widget could be a frictionless way of getting feedback on docs. Users would have to be in-charge of finding their own back ends for feedback storage or simply leverage on their analytics solution. Example: https://docs.gitbook.com/content-editing/pages-structure

It would be nice if clicking a category could render a page. This could serve as the top-level overview page for that category. Perhaps allowing an optional href attribute on the category sidebar type would allow this?

Markdown is great format to create documentation, but is not very good when you want to create and represent technical or functional diagrams. If we can have .drawio files, which when opened in docusaurus present the diagram created - would be great!