Make it easier to see the available wheels per package release

[cofiem]

As described in the issue: "For non pure python, it's often challenging to be able to determine if a wheel is available for a given Python implementation, abi, and platform. Currently, a user has to wade through a long list of wheel file names and decipher their meaning."

This change aims to add these interface elements:

• a text box that allows filtering the list of files by any of the implementations, abis, and platforms that match the typed text
• 3 select elements that show the available options and allow filtering the list of files to only those that match the selected option

I would appreciate feedback on whether this is a reasonable approach or not?
I'm willing to adapt to whatever make sense.

So far I've parsed the filenames and populated the select elements.
My next step will be to create a Stimulus controller that uses the input element and the 3 select elements to filter the list of wheel files.

Closes #14549

[miketheman]

cc @di is this along the lines you were thinking of for filtering?

[di]

I like this! I think the UI could be simplified a bit by moving the label into the select boxes, and putting them all on one line, something like Google Drive:

but otherwise this looks great!

[cofiem]

I've added the controller, which is relatively generic for filtering any list using input / select elements.

I've also styled the input & select elements.

See the screenshot and video attached.

I'd appreciate feedback on:

• how to properly apply the {% trans %} blocks to the text in my changes.
• if this is what you were envisioning?
• any further changes

2023-12-21.23-09-26.mp4

[di]

This is going to be fairly tricky to translate because it a) includes embedded HTML and b) needs to handle pluralizations c) the pluralized value is being determined on the frontend after the HTML has already been rendered, so Jinja's {% pluralize %} tag won't work here.

I think we might want to define these strings into the JS source instead, which will allow us to use ngettext on them there, but we don't currently do that in this codebase I believe, so it will probably require figuring out how to start doing that.

[di]

This looks great, although translations are going to be tricky here, I think we can figure it out.

One other thing to note: we should make sure this degrades gracefully when JS is unavailable/disabled (essentially, it should fall back to the current existing behavior).

[cofiem]

I've added tests for the filter_list_controller.js, ensured that the noscript display is reasonable, fixed the failing tests, and added the Jinja translation blocks.

The remaining work is the new approach to translations in js.
I'm not sure where to start with ngettext in js.

I'm willing to explore it, if I can get some pointers as to how you want it to work?

[di]

I'm not sure where to start with ngettext in js.

I'm willing to explore it, if I can get some pointers as to how you want it to work?

Sorry for the delay, I went on leave and forgot to respond. I also am not sure where to start either, but here's some pointers:

• Here's our existing docs on how our translations work: https://warehouse.pypa.io/translations.html
• Here's the Makefile that builds our translations currently: https://github.com/pypi/warehouse/blob/main/warehouse/locale/Makefile
• Here's the top-level Makefile that calls it: https://github.com/pypi/warehouse/blob/main/Makefile

How I imagine it would work:

• We continue to be able to call make translations to build our translation files
• Translations in js are included in the same translations files that we already have
• The call to translate a string on the frontend is straightforward, supports pluralization, falling back to English when the locale is not set or the translation is missing, etc.

[miketheman]

Labelling as blocked on the JS Translations #15612

[edgarrmondragon]

Just wanted to comment here, though it may be out of scope:

It'd be nice if the applied filters could be reflected in the URL query params, e.g. https://pypi.org/project/uv/#files?interpreter=3.11&interpreter=3.12.

That'd make it really neat for sharing the filtered list as a link.

[cofiem]

Hi @di @miketheman, do you think this change is still useful given the change in #15606?

My take is that it would still be useful to be able to quickly filter the list of wheels.
The dropdowns in this PR could make use of the 'pretty wheel tags' from 15606.

Once the JS translations PR #15612 is resolved, I'm happy to get this PR updated to use the js translations.

[cofiem]

I've updated this PR to use the recently-merged JS translations.

I also added the ability to copy the url to the page with the filters in the querystring, and load the filters from the querystring.
That part likely needs a close review to check if there's any areas that could end up with security issues.

I decided not to use the 'pretty tags' from #15606, as it made it hard to work out which part of the wheel filename was being matched.
I'm happy to discuss and change any of this.

[cofiem]

@di This PR is no longer blocked.
Please review again when you are able.