Currently in Krita, by pressing F1 or via Menu -> Help -> Krita Handbook, Krita will open a link to https://docs.krita.org/ . But the website doesn't auto-detect browser language, it will always display an English landing page. As a result, many people don't even know Krita's document has translated versions. I suggest we either make the URL of that link translatable, so the localization teams can set it to something like: https://docs.krita.org/zh_CN/ , or we somehow make the website auto-detect browser language. The string of "Krita Handbook" is at #: krita/kritamenu.action:1756
Or, we can make Krita open a link corresponding to the current locale it's using.
@wolthera Do you know how the docs site is redirecting to the per-language pages? If I try to load https://docs.krita.org/user_manual/getting_started.html, it seems to always redirect to https://docs.krita.org/en/user_manual/getting_started.html, ignoring the `accept-language` header from the web browser.
Let's consider this first: Do we want to change it from Krita or on the server side? I feel that it is worth changing it on the server side. If users visit docs.krita.org directly the best UX would be to have it respect the Accept-Language header and automatically redirect to the user's preferred language. If we can implement proper redirection for the root path, then surely it makes sense to apply the same redirection for the other paths. Then we can proceed to remove the `en/` part from all the untranslated docs.krita.org paths from within Krita. However, I have no idea where to even start looking to implement this. Does this need a sysadmin ticket first?
This needs a sysadmin ticket... because it proly relates to the htaccess file, and we have several issues with that file... https://forums.mobirise.com/discussion/12237/automatic-language-redirect-with-htaccess
Mind that parsing the Accept-Language header properly and selecting the best language match is a tricky business, especially when it comes to languages with regional and script variants, specifically for Chinese. (We only have zh_CN docs for now, but a zh_TW version is on my list, and that will need to handle more exotic codes like zh-HK, zh-Hant-TW, etc.) I don't think .htaccess has enough power to do that. We might need to forward it to be handled by a PHP script...
With the help from Ben Cooksley, the redirection issue has been fixed: https://phabricator.kde.org/T14693