Set language for tabs in URL query

[titusfortner]

I've been using this in custom-hacked code for a while, but now that I'm upgrading to the most recent tabpane implementation (nice work on that!), I figured I should submit it to see if I can avoid adding my own hacks. :)

~This would allow users to link directly to the language they want:~ ~https://selenium.dev/documentation/webdriver/actions_api/mouse/?language=ruby#forward-click~

Update: New syntax uses tab. (seems easier than the more descriptive activeTab): https://selenium.dev/documentation/webdriver/actions_api/mouse/?tab=ruby#forward-click

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[geriom]

This is not working for me. It seems the persistent tab functionality is broken, but has nothing to do with your PR. I'm seeing an error on console:

I'm going to try and figure out what's going on.

The page you linked to also shows an error, but a different one:

That one is likely caused by a recent update to the tabpane shortcode that changed handleClcik to persistLang. Updating to the latest docsy release should fix that, but may introduce the new error I am seeing.

[titusfortner]

Looks like we're not actually using the latest version of docsy in our code right now either. Trying to update all the things right now. Let me put this in draft, and I'll ping you when I can verify it works. Thanks.

[titusfortner]

Ok, I got the selenium.dev example working. We're using a version of docsy from a couple months ago, but the only commits that might change things are in #1037, and I don't see anything specific there.

My previous PR commit didn't set the local session properly, but that shouldn't result in the error you are seeing... I'm not a JS dev, though and don't know what $('#' + element.id).tab('show') is actually doing.

Also as a side note, is there a reason for the change from code=true to text=false? One option literally results in a code tag being generated and the other can be either html or markdown depending on the Hugo syntax used. I guess I think "plain text" when I see "text" (and also I don't want to update everything again). But also I know my project isn't the only one that uses git submodules instead of actual releases....

[deining]

This is not working for me. It seems the persistent tab functionality is broken, but has nothing to do with your PR. I'm seeing an error on console:

This doesn't work for me either (with tip of main branch, I get the same message on the error console). I started looking into that and found out that this is a regression introduced with 10fae88de482d836f0c81437afad5674418a888d. However, it's not fully clear to me yet what exactly is going wrong here. I hope this information can serve as starting point for further investigations.

[geriom]

I tried this on you website and it works as expected, but for some reason it doesn't work when I try it with the docsy user guide. It's probably related to another issue and not your implementation. I gonna take another look today and get it merged.

[titusfortner]

Well, We're not using the latest version of Docsy, so it's possible something else is getting in the way. :(

I don't have time to dig into it, so we can put this into draft if you want and I can revisit it once @diemol updates us to the latest version of Docsy.

[geriom]

I can't confirm- For me, setting the language via URL parameter works as expected, both with a module site from scratch and with the user guide.

Must be something with my local environment, the Netlify preview also works fine.

I am uncertain if we should persist the active language given when given as URL parameter. Currently, the language is always persisted, even if the user set persistLang=false for the tab pane. So maybe it is better to not persist the language at all when given as URL parameter.

I think it's OK to persist the language. I feel that having it in the URL explicitly makes a language selection that supersedes the persistLang flag.

[titusfortner]

Maybe we can unclear it if they switch to another tab and persistLang isn't set? persistLang just makes much more sense when used in conjunction with #1227.