User talk:Hippietrail/nearbypages.js

• The random arrow types feature is temporary so you can see how the various candidates look. After hearing your feedback I will permanently set it to the most popular type.

TO DO

• Include only base forms of words. "run" but not "runs" or "running".
• Preferences to set the number of previous and next links.
• Interact nicely with cirwin's iwiki extension.

---

Arrows

The solid pointers don't match in Safari 4/Mac. The left arrow is narrow, with a base matching the font's x-height, while the right arrow's base matches the ascent. The cause may be that the OS's big Unicode font, Lucida Grande, lacks the left-pointer character. Both of these are much too heavy and black, standing way out over any other character on the page (except maybe parts of the main logo). They might work if they were medium grey.

In Firefox/Mac these are consistent and much smaller, with the bases corresponding to the top half of the x-height. Much better, but still heavier than any letter or bullet in normal text size and weight.

The solid triangles are a bit bigger than the pointers in both browsers: not bad in Firefox, but much, much too large and black on the page in Safari.

Arrows look odd, implying motion to me, rather than just alphabetical order.

Whatever is used as separators need only be as prominent as a small bullet, but with a shape expressing the directional relationship. A very small triangle would be sufficient, perhaps grey or bullet-blue if it needs to be any larger than a dot for clarity. The single guillemets come closest to this, and I like them best. Small grey pointers might even be better, if their size and shape could be controlled--specifying Arial Unicode MS font may be the solution here.

For cross-browser consistency it may be worth trying graphical arrows, just as the monobook theme uses blue squares for unordered lists.

See also the {{rank}} box, which expresses a similar relationship in a very different way (just for reference: I don't like the box, and it bugs me that it and previous/next are so completely visually different). --Michael Z. 2009-06-14 14:52 z

Thanks for the feedback. It's a shame the triangles/pointers are too inconsistent across fonts and platforms to use. Using graphic versions instead would be an alternative but they won't scale for all people who change the font size. I'll try throwing a smaller set of triangle characters in the mix but they will probably suffer the same way.

I also prefer the guillemets. They're in most fonts and quite a few sites use them for "breadcrumbs" in a visually similar way if different semantics.

I personally hate the ranking box so much that I have had it hidden since its inception. I think we need to decide whether to move them to the talk page, or maybe somebody could edit the templates to make them generate output that doesn't clash with nearbypages? — hippietrail 22:42, 14 June 2009 (UTC)

• OK I've gone ahead and made the Gutenberg frequency ranking format match the nearbypages format for a while. Let me know what you think. — hippietrail 23:17, 14 June 2009 (UTC)

I'd prefer the arrows all point forward through the alphabet, instead of outward from the current word. No major preference as to what character to use as arrow, though.​--msh210℠ 23:32, 14 June 2009 (UTC) 23:43, 14 June 2009 (UTC)

Forward towards the front of the alphabet? There are obviously more points of view than I had anticipated. I have now randomize whether the arrows point back towards A and forwards towards Z, or always point in the A to Z direction so everybody can see how both look. — hippietrail 11:13, 16 June 2009 (UTC)

I meant forward toward z.​—msh210℠ 17:48, 16 June 2009 (UTC)

If possible, the arrow character used, whatever it is, should be bidi mirrored for use in right-to-left languages.​--msh210℠ 23:43, 14 June 2009 (UTC)

The complete list of mirrored characters includes the following arrow-shaped characters (I don't think I've missed any): > (the plain greater-than sign U+003E), ≫ (U+226B), ≻ (U+227B), ⊳ (U+22B3), ⋗ (U+22D7, hideous for our purposes imo), ⋙ (U+22D9), 〉 (U+232A), 〉 (U+3009), 》 (U+300B), ＞ (U+FF1E), and several for which I, for one, have no support in local fonts: these latter are in the ranges 2768-2775, 27E8-27EF, 2991-2998, 29FC-29FD, 2A79-2A7A, 2AA1-2AA2, 2AA6-2AA7, 2AAA-2AAB, 2ABB-2ABC, and 2AF7-2AF8.​--msh210℠ 01:16, 15 June 2009 (UTC)

Are you sure that's the right thing to do? Even though I'm looking at a list of, e.g., Arabic words, I'm seeing them in an English context, and I may use the list even though I don't read Arabic. The words may read right-to-left, but I expect a list in English-language Wiktionary to go from left to right.

Well since all modern browsers implement the bidi algorithm the terms are already rendered right-to-left no matter whether mirrored arrows are used or not. But if you can give me some code to make it always left-to-right I guess I could throw it in. I don't quite know how to do it on my own. — hippietrail 11:13, 16 June 2009 (UTC)

The code to do that is the nonprinting character U+200E, added immediately next to each arrow (before or after it). That will ensure that the list gets listed from left to right, and will also obviate the need for bidi mirrored arrows. Actually, I agree with whoever that was, above, who suggested this as the way to go.​—msh210℠ 17:48, 16 June 2009 (UTC)

I have added a new preference "Make the links left-to-right for all languages." It affects only right-to-left scripts. Perhaps the wording could be improved. — hippietrail 06:32, 20 July 2009 (UTC)

Furthermore, the arrows aren't matching the alphabetical order anyway. They are pointing outwards from the current term. Wouldn't they look the same in this previous/next list even in an Arabic Wiktionary? --Michael Z. 2009-06-15 22:09 z

No, not if they're not mirrored, and the U+200E trick I mention above is not used. Then the arrow points leftward in the first part of the list (since it's not mirrored) but the first part of the list is on the right side of the page (since this is Arabic and U+200E is not used). I really do think that that U+200E trick is best.​—msh210℠ 05:27, 18 June 2009 (UTC)

Any of the "solid" arrows are too much, too visual, and way too distracting, IMO. --Neskaya kanetsv 22:30, 15 June 2009 (UTC)

What about if they were grey instead of black? — hippietrail 11:13, 16 June 2009 (UTC)

Grey helps tone them down, but solid triangles bigger than any of the letters (in my browser) are not justified. —Michael Z. 2009-06-18 04:47 z

Unidirectional arrows

All the arrows pointing the same direction is pointless (ha ha). We already read from left to right. In this case, just plain separators are sufficient, like commas, middle dots, the extremely webbish vertical lines, or just plain em spaces. —Michael Z. 2009-06-17 01:57 z

They give the impression that the list of words is an ordered list, rather than just some words. Perhaps even with an extra arrow at each end and an ellipsis sign?​—msh210℠ 17:12, 17 June 2009 (UTC)

Every list of words is ordered. We read them in order, from left to right, and if they are alphabetized, so much the better. Look at an ordered lists in any book: a table of contents, list of contributors, index, bibliography. None of them needs so much fluff added to show that it is an ordered list.

The one I was looking at had grey triangles, bigger than any letter in the whole thing. It's completely unnecessary to grab our attention from across the page and hold so much of it, to carry so little meaning. Middle · dots · accomplish · the · same · thing—in   fact,   so   do   em   spaces. —Michael Z. 2009-06-18 04:38 z

only base forms

Can you make the including only base forms of a word an option rather than a default if you do get around to it? Including non-base-form words is infinitely useful when going through a language and making the same edit manually to every page (because the edit requires logic). Thanks --Neskaya kanetsv 22:27, 15 June 2009 (UTC)

Sure can. It's not close yet though. I have worked on it a little bit but it's tricky so I'm working on other stuff while I keep it in the back of my mind. — hippietrail 11:13, 16 June 2009 (UTC)

Neat. As long as it never becomes including only base forms being a default, because I think that could be really detrimental to the way that it works overall. It's nice to be able to go through all the words in the language. Though. On that note, could we maybe get a nearbypages-part of speech, sometime? --Neskaya kanetsv 21:39, 27 June 2009 (UTC)

Sidebar vs below heading option

Okay, I still really like this, but I haven't found myself using it much. But it grabs the eye all the time, because most of the divider characters which show up in my browser are totally inappropriate. I'm ready to just turn this off, but I'd really prefer to just keep the sidebar list. —Michael Z. 2009-06-20 21:14 z

OK I'll add subpreferences as soon as possible. Hopefully later today if it's not too busy, but I may have a weeklong wikibreak in a couple of days. — hippietrail 02:22, 21 June 2009 (UTC)

If you refresh your browser cache you should now find prefs to select the navbar and language heading next/previous links independently. For compatibility with old pref settings, having the links turned on but navbar & headings turned off is the same as having both turned on. This may change when I think it out some more. — hippietrail 06:15, 21 June 2009 (UTC)

Vote on final feature set

I'm not really into the voting stuff around here but if somebody else wants to set up a vote to decide on which variant to make standard and which few to keep as options then I will go ahead and remove the randomization and implement the subpreferences. — hippietrail 02:22, 21 June 2009 (UTC)

Sidebar placement

Is it possible for the sidebar links to below the "toolbox" section? On pages with many entries, it pushes the toolbox all the way to bottom. --Bequw → ¢ • τ 00:44, 8 July 2009 (UTC)

Should be easy enough. I just copied the code for "other projects" to begin with. — hippietrail 10:23, 8 July 2009 (UTC)

dump

Any way the data this feeds off of can be updated? It's quite old.​—msh210℠ (talk) 17:10, 28 March 2011 (UTC)

I ran into insurmountable problems updating my dump indexer - limitations and bugs in scripting languages when it comes to the 64-bit offsets I need for offsets into dump files. I'm relearning C to do a low-level port. Other problems are changes on the toolserver plus the fact that the script needs a long time to run and I don't get much free Internet time these days. I could learn the Unix "screen" command but I've had a lot on my plate. If you or somebody else wants to try to update it for me I'm happy to try to guide somebody through it. — hippietrail 17:41, 29 March 2011 (UTC)

I've updated this stuff on the last two dumps now so let me know if anything is awry. — hippietrail 01:53, 6 May 2011 (UTC)