-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help button does not work in its default implementation (returns a wrong url) #25383
Comments
Author Name: Harrissou Santanna (@DelazJ)
|
Author Name: Giovanni Manghi (@gioman) If I understand correctly this need to be fixed in the QGIS web site, correct?
|
Author Name: Harrissou Santanna (@DelazJ) Yes, the fix has to be done in the QGIS-Documentation Github repository if that's the question. But the "entry point" of the issue is experienced in the application: when clicking a Help button.
|
Author Name: Giovanni Manghi (@gioman) Harrissou Santanna wrote:
is there an issue filed on github? cheers! |
Author Name: Harrissou Santanna (@DelazJ) Giovanni Manghi wrote:
A kind of. See qgis/QGIS-Documentation#1834 |
Author Name: Alexander Bruy (@alexbruy) QGIS help system does work as expected. As were outlined in QEP and as we all agreed during QEP and PR discussion, documentation site should be updated to provide corresponding redirections. Also I don't see anything wrong with URLs construction. Tested with German, French and Ukrainian locales, result always correct Ukrainian: http://docs.qgis.org/2.99/uk/docs/user_manual/introduction/qgis_configuration.html#options If issue exists, please provide exact steps to reproduce issue.
|
Author Name: Harrissou Santanna (@DelazJ) Alexander Bruy wrote:
I'm not sure I said anything else, did I? I neither see anything wrong with the URL; you might mix the issues (see #25130 where I feel there's something to change in QGIS application side in the url construction). Please read my comments above (short version: I report it here because I'm looking for a dev willing to pick the issue):
Alexander Bruy wrote:
Based on the previous remark (only english is provided) I'd be tempted to say: just click any help button. But let me be verbose with some steps:
So, to summarize, this issue report is to draw devs, I guess the know-how, attention on QGIS-Documentation (and the help system particularly has direct impact on QGIS application).
|
Author Name: Alexander Bruy (@alexbruy) Harrissou Santanna wrote:
Maybe I misunderstand you, but in the ticket you said Harrissou Santanna wrote:
which is not true. QGIS part works exactly in the same way as it should according to the QEP.
I'm afraid you are confused with release and development stuff here. Of course, you can't reach any of these URL's because there is no (and never will be) localized documentation for master. We provide documentation only for releases and you should not transfer development URLs to the release version. But URLs constructed correctly, there is a valid sequence of version, locale and documentation chapters. May I ask you how will look URL for 3.0 release? Won't it be something like http://docs.qgis.org/3.0/fr/docs/user_manual/introduction/qgis_configuration.html#options? If yes, what is the problem? Also why you expect fr_FR instead of fr? Documentation site use fr for French, not fr_FR. Same with other languages. If you mean that you get URL's with fr_FR, then please provide more information about you environment, because I'm unable to reproduce it on my system. That's why I asked
Please, please, don't confuse development version and release version. Of course with development version you can't access localized docs because there is no localized docs for master. There is nothing wrong here and it was already discussed and explained several times. But if you want, you can access English version, just adjust your settings and remove locale from the base URL. |
Author Name: Harrissou Santanna (@DelazJ) OK. "Balle à terre". There seems to be a lot of misunderstanding in both parts. 1/ when I do not override the system locale option, the language is retrieved as fr_FR as you can see in the locale_system screenshot. So when I hit the help button, the docs link is constructed with fr_FR (it's not me expecting that, it's what Firefox tries to open) instead of fr 2/ when I override it with the "American English" (I do not have "English" in the drop-down list) and I hit the Help button, I get links with en_US (I already sent the screenshot for that) instead of en We need in QGIS-Documentation to map these languages to what is really provided by our Docs otherwise, each time someone hits a help button, he'll then need to manually replace the language part (this is true for french and maybe american but also for all the languages that are not present in QGIS-Docs). Or add another help link in the Options dialog, which I'm not sure the average user will do (reason why I said the default implementation, meaning the whole system without any change from the user, does not work for a part of the world and won't return a valid page until the next LTR doc is released for another part). I hope that this helps to clarify my comments and answers you.
|
Author Name: Alexander Bruy (@alexbruy) Harrissou Santanna wrote:
Hmm, which OS are you using? Because on Linux with default locale uk_UA.UTF-8 without overriding locale in QGIS settings I get correct URL. Also if I override locale either via QGIS settings or by defining different LC_* environment variables resulting URL still correct, no fr_FR or similar codes, only two-letter code. |
Author Name: Harrissou Santanna (@DelazJ)
|
Author Name: Alexander Bruy (@alexbruy) Seems this happens only with languages which have different variations, like en_US and en_GB, pt_PT and pt_BR. As I can see documentation website also has same codes in the URLs, look for example at Portuguese docs for Brasil and Portugal. Do you think we should drop them or maybe just handle case of en_US locale? |
Author Name: Harrissou Santanna (@DelazJ) i could have sworn that i got a wrong link with fr_FR but i might have dreamed it: only en_US locale seems to be not return the right language, afaics. |
Author Name: Richard Duivenvoorde (@rduivenvoorde) @Harrissou: some background: at a certain point in time be decided to NOT use language_country ISO codes (like nl_BE, fr_FR) to minimize the amount of translations. We ONLY use the language code: fr, de, nl, en etc. Also we tried to synchronize these 'language-codes' between QGIS-application, QGIS documentation, Transifex etc. If I'm correct, the logic from Alexander just used those language codes (so is NOT looking into the locale of the Operating System). Testing here: if I start (translated) QGIS 2.18 with:
it successfully starts QGIS in dutch, but if I then click Help/Inhoudsopgave (F1) I go to Mmm, will look into this and report back which url exactly is fired, and if we redirect or not... If there is something in the website we should fix, please let me know (as we are going to move the sites to another server in near future)... |
Author Name: Richard Duivenvoorde (@rduivenvoorde) For 2.18, at least 'en' seems hardcoded: https://github.com/qgis/QGIS/blob/release-2_18/src/app/qgisapp.cpp#L9184 as in translation I do not think 'en' will be translated to 'fr' or 'uk' :-) This could be fixed, though this is I think only used for the F1/help icon isn't it? But..., you were talking about master.... So THAT is a web server (my) problem... |
Author Name: Richard Duivenvoorde (@rduivenvoorde) Ok, I think that I have done the right redirectMatches now at docs.qgis.org to redirect a given language url to the right english one for testing. EG, the help button in the open vector dialog is pointing to: If not, or you see other problems, please let me know Can this issue be closed then? |
Author Name: Harrissou Santanna (@DelazJ)
Actually, I do translate this kind of links, even though Transifex complains. As long as it's a valid link, I find it normal to translate instead of sending the user to an english page he'll then have to switch to french.
Does it mean that any issue regarding the web side should be reported to you ? Only you are in charge of this? In which case, sorry for having moved the discussion here. |
Author Name: Richard Duivenvoorde (@rduivenvoorde) @Harrissou: well yes, most server stuff is my problem... Though I do not have a solution yet for the url's which are actually 404 (like pointing to a non available translation). Also note that all this here, should only have an effect in master (only in master we go to either a zip or the online help via this class: https://github.com/qgis/QGIS/blob/master/src/gui/qgshelp.cpp I just created a Pull Request which made that a valid(!) help url like: https://docs.qgis.org/2.99/en/docs/user_manual/working_with_ogc/ogc_client_support.html to be not shown. Reason was that the check of a valid url did not handle the 301 redirection we (apparently) use. |
Author Name: Harrissou Santanna (@DelazJ) What is the status of this report? Are all raised issues considered as fixed now? |
Author Name: Giovanni Manghi (@gioman) Harrissou Santanna wrote:
Agree, can the involved people close or tag this open, as necessary? thanks! |
Author Name: Harrissou Santanna (@DelazJ) From the initial message, all requests are done so closing.
|
Author Name: Harrissou Santanna (@DelazJ)
Original Redmine Issue: 17486
Affected QGIS version: master
Redmine category:translations_and_international
This is likely a QGIS-Documentation repo issue but more a dev issue than a doc writer's. And given that this is the place where devs are and it's directly related to the QGIS application behavior, let me report it here.
With the Help button (being) added to dialogs, user should directly be able to find the appropriate web page of the dialog he's using. It's a nice way to teach him the dialog features but also, and we could expect, for those who know, incitate them to directly fix issues in documentation.
However, in its default implementation, it does not work.
Afaict, in QGIS, a URL to user manual is built based on the current language and version used. Problem is that languages (or the code of languages) used in the application do not match what is provided in documentation, leading to a Not Found page.
What is needed in the QGIS repository is:
Setting the priority to High, as not fixing this is like providing a broken feature by default and would not help for its adoption.
The text was updated successfully, but these errors were encountered: