Confusing documentation on data location

[mikegerber]

This is more of an UX issue, I suppose. In https://ocr-d.de/en/models#where-is-the-data the docs say:

In Docker though, $XDG_CONFIG_HOME=$XDG_DATA_HOME/ocrd-resources=/usr/local/share/ocrd-resources gets symlinked to /models for easier volume handling (and persistency).

While I was trying to debug OCR-D/ocrd_all#413, I read this and thought it was garbled. It is not, I just didn't comprehend it. I suggest changing it to something more readable, e.g.:

In Docker though, $XDG_CONFIG_HOME (set to $XDG_DATA_HOME/ocrd-resources, which ultimately is /usr/local/share/ocrd-resources) gets symlinked to /models for easier volume handling (and persistency).

[mikegerber]

Do the $XDG_ variables matter here at all?

[bertsky]

Good idea! Would you be willing to submit a PR for this (and similar stumbling points)?

Do the $XDG_ variables matter here at all?

One could of course set XDG_CONFIG_HOME=/models in the Dockerfile, but we really want to allow the user overriding these variables (at runtime or in a derived Dockerfile).

[mikegerber]

Good idea! Would you be willing to submit a PR for this (and similar stumbling points)?

Will do. The only other thing I encountered so far (besides our METS caching bug) was the permission problem on /models (OCR-D/ocrd_all#413, and, somewhat connected the corresponding error message).

[mikegerber]

Good idea! Would you be willing to submit a PR for this (and similar stumbling points)?

Will do. The only other thing I encountered so far (besides our METS caching bug) was the permission problem on /models (OCR-D/ocrd_all#413, and, somewhat connected the corresponding error message).

Will do. The only other thing I encountered so far (besides our METS caching bug) was the permission problem on /models (OCR-D/ocrd_all#413, and, somewhat connected the corresponding error message).

(ocrd_tesserocr's docs about the model location also is somewhat hard to understand IMO. I'll try to explain in a new issue there)