Allow users to emphasise languages when looking up words.
Problem: Sometimes a word is shown in many languages that do not interest a given user (much, at a given time). This applies both to the words shown on a page (both lemmas and translations) and to those in suggested in the various search boxes, and can result in inconvenience and confusion.
Proposed solution:
Interface Allow users to pick the languages they are interested in from a list, and to turn on or off the option to restrict words show on pages and during searches. A more luxurious version would show the user words in other languages as well (which can be helpful), but avoid them cluttering the view. Ideally, this feature would also apply to lists of translations, but I fear that would need a drastic change to the way these work.
Implementation I am not sure how hard this would be, but here are a few ideas. Perhaps searching for pages limited to a category would help, but I fear that is not currently possible. Perhaps the Tabbed languages gadget also uses relevant techniques. If is possible in CSS, that could be used to hide unwanted sections, so that cached pages require no extra processing in the server and no script in clients. Filtering translations might become feasible if they were generated from Wikidata.
Who would benefit: Particularly, anyone using Wiktionary (in a language they know, especially English) to support them while learning a specific other language. More generally, anyone with a strong focus on a few languages, which probably covers most users most of the time (though casual users would probably not use such a feature).
More comments: The Tabbed languages gadget goes a long way towards solving this as far as page display is concerned, but (a) does not help with searching, (b) appears not to work in Firefox on Android.
Thanks for this proposal, it is a real issue. Wiktionaries tend to have too much content and it is not really convenient for the readers. The gadget you mention is in use in English Wiktionary but not in many other versions, to my knowledge. This issue have a UX design part, and it could be explore through testing, in order to calibrate the options. Then, there is a structural component. Since the beginning, the description of different entries (words or multi-word expressions) from different languages are displayed in a single page based on the sequence of signs (letters mostly) used to write it. The content is also stored in those pages. Another option to explore could be the way Wikisource deal with content, with separated subpages for each languages and a simple page with several automatic transclusion. This option could help the filtering of information, but may complexify the editing process to add information. So, it is a great challenge, and an important one for the future of Wiktionaries 🙂 Noé (talk) 11:30, 24 January 2023 (UTC)[reply]
Thanks for the positive reaction; I am glad you sympathise. While there is some superfluous content, I think the greater problem is presenting too much content. Perhaps we could put lemmas ¿for non-native languages? in separate namespaces, though that would probably need to be backed up by good editing tools and checks. The transition for a single Wiktionary could be fairly easy to automate, but only if we could take that wiki off-line for the duration. PJTraill (talk) 19:15, 26 January 2023 (UTC)[reply]
Very much needed. Even though I'm an experienced editor, I often use https://ninjawords.com as a frontend to Wiktionary when I just want to quickly look up a word, because the contents of a Wiktionary page are typically cluttered and full of information that should IMO be progressively disclosed. For beginning editors or readers, the current way information is displayed in Wiktionary pages is very likely to be overwhelming. --Waldyrious (talk) 10:36, 11 February 2023 (UTC)[reply]
This, or something similar to this, would be very much needed on mobile pages, for performance reasons. Pages are served with all language sections initially collapsed, and they are then all expanded by some Javascript once the page has loaded. (IIRC there's a checkbox for auto-expanding in the user settings, but I may be wrong, and in any case it doesn't help logged-out users.) On a not-top-of-the-line smartphone, this expansion is slow: it takes a good 5–10 seconds, an eternity in UX terms, for the browser to re-render this section expansion on long pages with more than 20 or so entries; pages such as wikt:a or other single-letter pages are basically un-openable. (An additional frustration is the user (me) tapping on a collapsed section's heading, but section expansion hasn't completed yet, and once it does the section that was tapped on will then immediately collapse again, hiding the desired content.) Oatco (talk) 16:23, 14 February 2023 (UTC)[reply]
Support Geofferic (talk) 20:16, 10 February 2023 (UTC)