I'm a little confused about where you are clicking. Please could you add screenshots

After selecting help (first screen) there will be a pop-up.

Same in J3 afaik

Just checking I understand that the problem is with the second screenshot and the link on that page.

I can see that the link on that page is correct on the source docs page with the special tag

From what I can tell the problem is with the way help.joomla.org and docs.joomla.org are linked together.

It's not a core joomla issue as that code is not part of this repo. - not sure where it does live - sorry

This "problem" is the same in j3

The help proxy just renders the contents of a docs page as parsed from the MediaWiki API with rewrites of the URLs to stay within the proxy. Aside from other minor revisions to unlink images or remove red links (meaning a wiki page does not exist for that link), it does not do anything special with page contents beyond printing them.

In the docs helpscreens we use S:MyLanguage/ to point to the right language.

This generally is not the intended behavior for the help proxy. Generally, the language of the CMS interface is the preferred language, then if a page is not found in that language it falls back to English (the same way the CMS translations work). Using that special URL would not work correctly anyway because the help screen proxy is making a server-to-server API call to the MediaWiki API meaning no client information about the user who requested the page is provided through the API context for those calls to do anything meaningful with it (such as cookies or user agent strings).

I would suggest this item be closed as working as intended. The help proxy is not MediaWiki and if you want MediaWiki’s functionality then I would just rip out the middleman and have the help buttons open directly to the docs wiki and remove all inline rendering of help from the CMS.

It's not a core joomla issue as that code is not part of this repo. - not sure where it does live - sorry

https://github.com/joomla/help.joomla.org

Unlike other teams I believe in transparency and open sourcing of project resources to the extent practical.

Closing as expected behavior for the reason stated above: #30080 (comment)

Thanks @mbabker for the detailed information.

I dont agree that it is the expected behaviour from a user perspective at all. However I do agree that this is not the repo where it can be addressed

I dont agree that it is the expected behaviour from a user perspective at all. However I do agree that this is not the repo where it can be addressed

@brianteeman Fully agree. Expected behavior was regarding the CMS, not regarding the help Wiki or the help proxy.

I dont agree that it is the expected behaviour from a user perspective at all.

S:MyLanguage can’t be used from an API context, I rechecked this before walking away from the computer. This is why that is rewritten out of the URLs in the proxy and where possible the language code provided in the query string when requesting a proxy page is used. The one thing it isn’t doing, and I personally think this benefits nobody to do, is arbitrarily rewrite every rendered link to use the language code from the proxy request query string, that to me creates more end user confusion (why is an English rendered page generating links to German pages?). Also, there is heavy caching on the proxy to avoid bombarding the MediaWiki API, so a French user seeing an English page may have different expected links than a Dutch user. Not things that are easily dealt with short of disabling the cache integration, too many user dynamics to get it “right”.

About the only sane thing I can think of is to un-hide the “Other languages” node (it’s hidden with CSS only and not stripped from the DOM like other edits do). But any automatic language resolution in the same way that MediaWiki behaves just isn’t going to work when you’re dealing with the API and server-to-server communications. That’s why I said if you want what the help buttons render to behave exactly as the docs wiki does, the best option is to link directly to the docs wiki and eliminate all the pieces that try to render the help inline into the CMS. Sure would make my life easier at least.

I see this problem is inherited from Joomla 3. It seems to me that links that we have entered as [[S:MyLanguage/Help4.x:Components_Banners_Tracks|Banner Tracks Manager]] should be [[Help40:Components_Banners_Tracks/en|Banner Tracks Manager]]. Now testing to see if it works to produce the desired behaviour.

Arghh! The translate tags disappeared from that last comment and I don't know how to fix it.

@ceford Use the "insert code" button or quote that part of your comment with "`" so GitHub shows it as it is.

What I meant to say is that the internal Help links should be one or other of the following:

*Test 1: [[Help40:Components_Banners_Tracks/<translate>
en</translate>|<translate>
Banner Tracks Manager</translate>]]

*Test 2: [https://help.joomla.org/proxy?keyref=Help40:Components_Banners_Tracks&lang=<translate>
en</translate> <translate>
Banner Tracks Manager</translate>]

This way the required language code is in the translation. Currently testing.

The first one. The second one forcibly links the pages from the docs subdomain to the help subdomain.

@ceford and me tested and found a way in docs to have links act like we want in the helpscreens.