This page is no longer active. It is being kept for historical interest.
	No discussion is needed to revive this page; simply remove the {{inactive}} tag and bring it up to date.

This page is intended to become a discussion of the issues people have with Wiktionary's usability, and a set of possible solutions. In that sense it is really an extension of the beer parlour. No decisions reached here should be implemented without a finalizing discussion on the beer parlour (as that is where most people spend their time), or (if the situation warrants) a formal WT:VOTE.

There is too much irrelevant information on the first screen of many Wiktionary entries. Assuming that a default dictionary user is looking for definitions, the information that often appears here (TOC, Etymology, Pronunciation, Alternative Spellings) is less relevant. Conrad.Irwin 11:23, 26 June 2008 (UTC)

With the system of linking relevant parts of the entry by glosses, any robots have to "guess" which definition the translations (or other information) are relevant to. While this guessing seems to be at least 95% successful (see WT:PREFS#Conrad Irwin's paper view and Language button view which attempts to do this) this still leaves 1/20 cases where the matching is incorrect or unreliable. Conrad.Irwin 11:23, 26 June 2008 (UTC)

The Wikimedia search engine is often less than ideal in several situations

1. Searching for uncommon symbols often yields no results even when pages about it exist. For example searching for ⌹ in the Appendix namespace yeilds no results, even when an article containing it Appendix:APL exists.

   Options) Maybe we could allow hard-redirects from the main namespace to other pages for uncommon symbols that don't meet our CFI.

Colors: Our table color-schemes should be checked for appropriate contrast and viewability by the color-blind. See w:Wikipedia:Accessibility#Color for more information and resources.

Images: Most of our images lack Alt-text which is very helpful for screen-readers.

Transliterations: Transliterations should always(?) be provided for text in non-Latin type. This is especially important as many screen-readers handle poorly non-Latin type.

Links: For one having a difficult time distinguishing links it may help to force all links to be underlined. This may be accomplished by going to Special:Preferences → Appearance tab → Advanced options section and then choosing "Always" for "Link underlining:"

Display Management: CSS should not be used as a content management system to dynamically change the contents of pages. This should be done using Javascript. Otherwise this can cause problems for mobile viewers (apps, gateways) and accessibility tools (e.g. screen readers).

Often it is visual appropriate to show a list horizontally instead of vertically. Usually this is done is done manually by separating the elements on a line with a comma and a space. This approach however removes the HTML structure of the list resulting in impaired use by automated tools such as screen readers. An alternative is the use {{flatlist-top}} and {{flatlist-bottom}} to keep the HTML structure of the list while formatting it with CSS to be shown horizontally. In modern browsers (Firefox, Chrome, Opera), elements will be separated visually with a comma and spacing and ended with a period while in older browsers (IE) elements will just be separated by spacing.

{{flatlist-top}}
*one
*two
*three
{{flatlist-bottom}}

{{flatlist-top}}{{sense|foo1}}
*one
*two
*three
{{flatlist-bottom}}

*{{sense|foo1}} 1
*{{flatlist-top}}{{sense|foo2}}
**one
**two
**three
{{flatlist-bottom}}
*{{sense|foo3}} first

Users often miss the whole idea of wikilinks, judging by the nature of some of the questions and complaints at Feedback. One departure of our wikilinks from common Web practice is the absence of underlining for links. I would hope that underlining would help and can't imagine an unobstrusive change that could help more. Web standard practice seem to be a not very intrusive dashed or dotted underline.

Underlining could address two other issues:

1. Currently there is no differentiation between one link to a two-word term and two consecutive links to one-word terms.
2. Currently there is no differentiation for in-line links between a link within Wiktionary and a link to a sister project (usually WP). Potentially color or dots vs dashes could be used to differentiate. Users would benefit from knowing what type of information (and how long a download) they might expect. DCDuring TALK 01:22, 17 January 2010 (UTC)

Wiktionary uses WT:PREFS for it's customization a system that predates mw:Extension:Gadgets. This is difficult to use for newer users as (a) options they'd want are hidden among all the others (both experimental and idiosyncratic) (b) has a bad layout (no "Save" button and not in the same place as other User preferences).

I propose that WT:PREFS be used for experimental options and those that only a few might want. All mature options for the global user should be moved into Gadgets. --Bequw → ¢ • τ 21:54, 26 January 2010 (UTC)

Please help me understand this. I thought that our truly experimental (late alpha-ish, early beta-ish) stuff was available only via monobook.css and monobook.js. Where does mw:extension:gadgets fit with those. What is the user interface like for extension gadgets? DCDuring TALK 00:18, 27 January 2010 (UTC)

That's true, but there's other experimental stuff still in WT:PREFS such as "User:Connel MacKenzie/reformat.js" and "User:Conrad.Irwin/parser.js". The most options though are due to our inability to settle on formatting (eg "Show “form of” definitions with an italic definition" and "Hide the “transitive” and “intransitive” qualifiers in definitions. "). Currently we don't use any gadgets, though they serve exactly the same purpose (each just includes a snippet of JS and/or CSS). As for the UI, have a look at the Preferences on Wikipedia and select the "Gadget" tab. It's basically similar (a single check-box per gadget with some wikitext description). --Bequw → ¢ • τ 02:00, 27 January 2010 (UTC)

For the Mediawiki stock system messages that we modify locally and ones that we create for local purposes (eg the ones listed at MediaWiki:Sidebar) it is helpful to provide translations into foreign languages. For example Mediawiki:Newarticletext has been translated into Swedish by creating Mediawiki:Newarticletext/sv and so when someone has selected "Swedish" as their interface language they will automatically see a Swedish version of our Newarticletext when appropriate. Looking at All pages in the Mediawiki namespace we see that relatively few have been modified (it's unknown however how many people use Wiktionary with the UI set to a foreign language). --Bequw → τ 00:10, 23 February 2010 (UTC)

• List of current keyboard shortcuts
• m:Manual:Interface/Access keys
• w:Wikipedia:Keyboard shortcuts (includes JS code to have shortcut keys automatically shown around the UI)

These don't have to be completely possible or relevant, it's just a forum for ideas.

This would help with #Mess above the fold by allowing the written text of the entry to always start at the top of the page, whereas currently the TOC always appears before any content. The result of this change can be previewed by enabling WT:PREFS#Float Tables of contents to the right of entries. Were this to be implemented the WT:PREF would be changed to allow users to return to the default display. There is some concern that, as the current entries were written with the left TOC in mind this will mess up the right-floating stuff that we have (I personally think this claim is unfounded and that the benefit outweighs the cost). Conrad.Irwin 11:23, 26 June 2008 (UTC)

This would help with all problems above. The idea is to rewrite our layout so that all the problems just magically go away. Please feel free to edit and extend this proposal, don't remain constrained by the boundaries of the current software. Conrad.Irwin 11:23, 26 June 2008 (UTC)

• Second level headings remain as language specifiers
• Most of the third-level "headers" should be definitions, so that the TOC displays the definitions at the top of the page.
• Under the third-level headings should be fourth-level headings of translations, synonyms, antonyms and other definition specific details.
• The last few third-level headings should be "Etymology" "Pronunciation" and other homonym specific sections.
• For words with more than one Etymology or pronunciation, each definition section should contain a link to the relevant one.
• Use templates for each header. For example, editors would enter {{noun}} instead of ===Noun=== or ====Noun====. The header template would automatically "know" what level it is supposed to be in depending on what header comes before and after it.
• Moving TOC - is always visible on the screen, moves with scrolling.
• Pop-up info boxes - for the lack of a better term. This is to provide information about sections on the bottom of the screen that are not visible when the screen first comes up. For example, if Etymology is on the bottom, instead of scrolling, a small link would be placed next to the word (this is already implemented as a test for long pages), when the cursor is placed on the link without clicking, a small infobox would pop-up with the Etymology. When the link is clicked, the screen would jump to the actual Etymology section.
• TOC collapsible by section (as to reduce the length). Especially paired with the moving TOC, this would give shortcut-links to the relevant (language) section, and if more fine-grained control is needed, one can un-collapse that particular language's section of the TOC.

One incremental improvement includes putting the content under headings above definitions (principally Alternative spellings, Pronunciation, and Etymology) under "hide/show" bars. A more radical approach would make the gloss on the show/hide bar serve as the header. DCDuring TALK 11:42, 26 June 2008 (UTC)

Place lists of alternative spellings horizontally, separated by commas; do something similar with pronunciation material. DCDuring TALK 11:50, 26 June 2008 (UTC)

Many listing sections could be reduced to one line if there is no needed for additional organization. For instance, single sense words could have all antonyms on one line, and synonyms on another. Related terms, coordinate terms, Derirved terms, etc. could all conceivably be placed horizontally. --Bequw → ¢ • τ 11:08, 25 August 2008 (UTC

All pronunciation elements (IPA, SAMPA, enPR, audio, rhymes, homophones) for a single accent and/or groups of parts of speech with the same pronunciation. DCDuring TALK 23:41, 14 December 2008 (UTC)

All definitions on one line would save a lot of space. --EncycloPetey 23:58, 14 December 2008 (UTC)

Can we get clean-up lists of entries with definitions that are more than, for starts, 2 lines long, especially where the entry takes up more than one screen? DCDuring TALK 17:10, 3 June 2009 (UTC)

Once a list get's to be very long, it's probably better to put them in a multi-column layout using something like {{top3}} or {{top4}} and their ilk. Not sure what number would be the cutoff, but maybe 8 or 9? --Bequw → ¢ • τ 14:12, 2 October 2009 (UTC)

Though Wiktionary:Etymology states that they should be short, as they are before the fold, I think they are still too wordy and off-putting for newbies. Why does each entry need to be able to "stand on its own" in terms of etymology. If the entry for foo has a complete etymology why does a derived term bar have to list the entire etymology again, rather than just linking to its existing, immediate ancestor? --Bequw → ¢ • τ 11:08, 25 August 2008 (UTC)

A vague concept, which could be implemented variously. We already have a virtual third column occupied by some right-floated elements, but they interact strangely with the layout and make a mess of the page. Right-floated content could include the table of contents, sister-project links, images, Korean symbol navigation (e.g.), .

Stuff from the main column could be moved to the right, using position to establish a main–supplementary relationship (e.g., alternate forms and synonyms to the right of the headword; or derived and related terms to the right of synonyms; or translations to the right of same-language lists).

Collapsed sections (translations, etc.) could sit in the right column, expanding to full width. —Michael Z. 2008-12-14 21:22 z

1. Virtual right-hand column: the layout would look much neater if right-floating elements all had the same fixed width.
2. Clear right-hand column: if the main content had a generous right margin, elements floated in the margin wouldn't make a mess of the page.
3. Top-aligned right-hand column: essentially an infobox, which collects all of the right-hand column elements. This might improve the layout, but may weaken the spatial relationship between floated elements and parts of the main text.
4. Fixed right-hand column: Like an infobox, but remaining visible in the browser window as a long entry is scrolled.

Headers are larger than typical text and have extra space around them and, especially, to the right. An inflection line (with hyphenation) could look like:

Noun: foo^.bar (plural foobars)

The pronunciations and etymologies could be off the page completely, perhaps each in a namespace of its own. DCDuring TALK 00:17, 15 December 2008 (UTC)

The default ToC should have only Language headers, PoS headers, (Translation header, too, I think) and definition glosses made from an editor-selected emboldened word or context keyword on each sense line. Fans of etymology, anagrams, semantic relations, etc. would have to suck hind tit. DCDuring TALK 17:19, 3 June 2009 (UTC)

People complain that they can't find the definitions; one solution is to change form the current ==Language==, ===POS===, infl, #defn, ====Other stuff==== to ==Language==, ===POS===, infl, ====Definitions====, #defn, ====Other stuff====.—msh210℠ 17:27, 3 June 2009 (UTC)

Anyone searching google and gets a wiktionary hit, sees nothing about any definition in the snippet that google provide. Instead they may see a piece of the etymology or the inflection table, which may, if we want to attract readers that route, not be the ultimate thing to show. Short of badgering google into changing the snippet, how can *we* create a workaround for this? \Mike 09:13, 15 June 2010 (UTC)

• Help:Mobile access
• user:msh210/ELE