When content changes are saved in Code view and published, the content changes are not reflected

Hi Document360, Is it possible to translate the date under the title of an article in a language other than English? Thank you, Best,

When editing the Alt-Text and Tags of an image in the File Details panel and Save, the folder list does not display the newly added tags. If you open the File Details panel for that image, the Alt-Text is there but not the Tags. If you Save the image at this point, the newly added Tags are removed. However, if instead of opening the File Details panel, you click on another folder then go back to the folder the image is in, the Tags will be displayed in the list. This happens on folders with large number of images. It does not happen on lists smaller than 20 images. This issue makes it difficult to see what image files have been updated in the folder listing. I have to select another folder, go back to the folder I was working in, then set the filter to see what image files have been updated. :-(

When the file structure changes in Doc360, these changes are not pushed to crowdin. Also files in Crowin tend to be doubled and show in weird places. This messes up translations.

When clicking a Table of Contents heading, two things seem to be wrong: Document360 highlights the preceding heading instead of the one clicked. The UI scrolls down to slightly before the heading clicked, rather than to the heading's exact location on the page.

The broken links feature is a mission-critical feature for any documentation product like Doc360. Especially if you use extensive intra- and extra-page linking because you follow an "every page is page one (EPPO)" paradigm. But your current broken links implementation becomes rapidly worthless and untrustworthy if you include ANY links to external sites that are behind some form of security authentication. For example, articles written for our internal developers routinely contain links to our private GitHub Enterprise repos. Because your link crawler cannot authenticate and actually follow these links, all the articles containing such links are reported as containing broken links. When in fact they are not. This same problem exists when you might link to a design document on a Sharepoint host, or to a privately team-shared Google Sheet, etc. etc. As a result, we already have a running list of 42 articles with broken links, when in fact no links are broken at all. And it makes it nearly impossible to recognize a TRUE broken link (internal KB links), because of all the NOT broken pages already sitting in the broken links report. I'd honestly recommend just globally ignoring ALL external links. But if you are worried about doing that, then at the very least, please give us a config option to disable broken link checking for external links, for those of us who might be linking to private hosts in this manner. Note that a major content platform (MadCap Flare) also has excellent link-checking features, and it completely ignores external links during its link-checking process. That never posed an issue in the 10+ years I worked in a Flare authoring environment.

Change the default editor to WYSIWYG At some point (not sure what the trigger is) when creating a new article, the default editor reverts to Markdown.

When exporting the project to PDF, any links specified in the documentation as relative links (e.g. Supported Platforms ) do not get converted to fully qualified URLs and therefore do not work in the PDF

We have queries but no views, reads, likes in the weekly report.

While in Dark Mode on the KB site, our categories display as a wide black bar: black background and black text. This renders it unusable.