-Seems many links are redirecting to 404
Example: glossary, Proceed to Templates → many more [refer screenshot]

@Hutchy68 can you take a look at this please.
The original page is correct here https://docs.joomla.org/J3.x:Getting_Started_with_Joomla!
But the copied page is wrong here https://help.joomla.org/proxy/index.php?option=com_help&view=help&keyref=Special:MyLanguage/J3.x:Getting_Started_with_Joomla!#

And the images are missing

Thanks @brianteeman for confirming this issue.

Most help can't be tested here with current staging as it is looking for links like
https://docs.joomla.org/Help34:Site_Global_Configuration

Note the "Help34:"

@infograf768 The issue reported has nothing to do with that and occurs on
3.3.6

On 29 December 2014 at 10:51, infograf768 notifications@github.com wrote:

Most help can't be tested here with current staging as it is looking for
links like
https://docs.joomla.org/Help34:Site_Global_Configuration

Note the "Help34:"

—
Reply to this email directly or view it on GitHub
#5548 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I can confirm the issue, but I'm not able to fix it at the present time. The problem is in the help proxy server and not in Joomla itself. Not sure what has caused it, might have been the switch to https or maybe some markup change in the wiki itself, but it's breaking the multi-language link parsing. The problem is that the proxy is not recognising the Special:MyLanguage links and replacing them with links to the proxy.

@brianteeman

@infograf768 The issue reported has nothing to do with that and occurs on 3.3.6

I guessed so. Was just adding the 3.4 situation.
In any case, the version of joomla tested should have been stated when creating the issue.

Added JVersion in Title

It was - you use github and not the issue tracker so you didnt see it - not the posters fault ;)

@infograf768 there is NO need to do that. We have a specific field to use
on the issue tracker for this and the poster did exactly what they were
supposed to do. If you refuse to use the issue tracker then you will miss
out on certain information - please don't start duplicating information
just because you wont use the tool - this is a waste of your time and just
another useless email in the inbox

On 29 December 2014 at 12:14, infograf768 notifications@github.com wrote:

Added JVersion in Title

—
Reply to this email directly or view it on GitHub
#5548 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@chrisdavenport @Hutchy68 - It's in part an issue with the Mediawiki API too. During the server upgrade, we changed the API call to a different point since we weren't using any data returned with the original API call. So I've done some debugging.

Old API URL: https://docs.joomla.org/api.php?action=parse&format=json&page=Special:MyLanguage/J3.x:Getting_Started_with_Joomla!
New API URL: https://docs.joomla.org/index.php?action=render&title=Special:MyLanguage/J3.x:Getting_Started_with_Joomla!

If you ping the old URL, it returns a message saying the Special namespace is unsupported. Visiting the new URL in a browser results in a 302 redirect to https://docs.joomla.org/J3.x:Getting_Started_with_Joomla! and this is what's being rendered by the proxy. In the old version, an empty page was just rendered since the HTTP connector wasn't following those redirects. Since the updated code is using JHttp, I've just told it to not follow redirects and now it's back to rendering that empty page.

Yep, a couple of things going on here.

So the big issue is the way links work. Special:MyLanguage/Name_of_page is a puts the clicked link actually on docs through a pre-check asking for some feedback when the link is clicked. Is the user browsing in a language, is the browser set to a specific language, what is the geo location of the user browsing? Then tries to determine their language code. The next check determines quickly, pagename/{{lang_code}} yes exists send the user there, no it doesn't fall back to English. Yes, you can add &uselang={{code}} to either call, but all it effects is the interface language. Table of contents becomes "Sommaire" for example with a fr code because Table of contents is an interface string.

All Special:MyLanguage/ should be regexed out. All specific languages besides en should strip it out too but also add /{{lang-code}} to the end of the title and also &uselang={{lang-code}} to the URL end.

There is no way I know of except to check each and every link in a page to see if the article exists in another language from the proxy easily then default back to English. I suppose you could do an article check via api, but that would be really expensive as a parser function on the proxy and docs with multiple api calls.

For now, I would suggest we just regex out the Special:MyLanguage/ to make sure everything works as expected in English on the new proxy server. Then we can start addressing the languages. Will have to address a few issues in core in regards to help server choices, switching too.

@Hutchy68 Can I close this here as it is really an issue regarding the docs server and not the joomla code - if I understand it correctly

Closing, will create issue on different repo when repo with help component for help proxy is created by @mbabker