Vitaly V. dr.vitall@gmail.com wrote:
First, proposed system will make user less likely to check what word mean in second/third language.
You mean they'll be able to find the information they're looking for more easily, and not be distracted by the information they're not looking for?
It make it more harder - for many languages definitions user will HAVE TO make an extra mouse click. Plus you can feed your curiosity about what word in question mean in other languages just by scrolling - without need for multiple mouse clicks.
Is there a source you can offer for scrolling = good, clicking = bad? I know usability expert Jakob Nielsen often has asserted exactly the reverse.[1][2][3] Now, while people of course *do* scroll[4] that doesn't make it the best way to navigate websites.
It will also make user less likely to edit second third language definition, especially if languages belong to same family and user/editor speaks more then 2 languages.
If a user's going to edit information, they're going to edit information, whatever page it's on.
You seems to miss the point - if user don't see information/definition, he will never edit it. And there lots of editors, that fix or add definitions only when they use Wiktionary and see mistakes or missing information.
Well, that's what the wiki format is. If you want a system that presents information to knowledgeable editors to review whether they were looking for it or not, that's something outside normal wiki practice, and could be implemented a lot more efficiently than just relying on whether a word happens to be spelled the same as another word the editor knows.
Put it another way, these multilingual editors are used to, say, Spanish [[hermano]] and Portuguese [[irmão]] being on different pages when they go to contribute information, as this is the usual state of affairs. If Spanish and Portuguese entries for [[amigo]] are on the same page, this may be a little easier for them (depending on how many other languages have entries on the page between them) but if they're on different pages _it doesn't make it any more difficult than the usual state of affairs_.
Also, that will make some comparisons of different languages definitions less convenient - now for words defined in two-three languages you can use scroll/mouse scroll. With proposed system,again, you have to click.
You mean you can click and bring up a new tab or window to see it side-by-side, instead of having to scroll back and forth each time you want to compare bits of information?
I mean what I said - with current system you have NO NEED to make an extra clicks at all if word defined using up to 3 or 4 languages - and there a LOT of words like that.
Again, a click is often easier than pages of scrolling. Were it otherwise, we may just well put the whole dictionary on one page.
If you prefer multiple clicking over mouse scrolling - then current way don't have advantages over proposed one. On the other hand, proposed one don't advantages over current one either.
As I've been saying, using disambiguation reduces signal-to-noise ratio for the user. It's also easier on page load times. It just took about twenty-four seconds on this old computer to load and display [[a]] (compared to five for [[amigo]]) -- and odds are if I go there I'm only looking for an entry in one language, which may well turn out to be a one-line stub.
Sorry to hear you, Muke, have difficulties using/find it inconvinient to use Contents to find proper language definition. Is [[en:wikt:a]] article is a real word example? Like you come across lots of articles that got MULTIPLE screens of "Contents" menu? From my personal experience, I think I never saw one. I mean during usual, real life usage of Wiktionary.
Just because 99% of Wiktionary entries are stubs does not mean that it's supposed to be this way. When Wiktionary grows up more pages are going to be like [[a]] than otherwise. Even a word like [[muke]] with stub entries for only nine languages has a page and a half table of contents. After they become respectable entries with more information under more headings it'll be much worse, even before any other languages are added.
But it could be possible that we got very different search pattern behavior. If problem widespread and real, could you please providefew, like 5 or six examples of such words you expirienced in reallife Wiktionary use? I really curiouse, what type of words will be that.
http://en.wiktionary.org/wiki/lead - a page of contents covering the decent-sized English entry alone, with two other entries that could grow just as large.
http://en.wiktionary.org/wiki/do - over four pages of contents covering 24 languages.
http://en.wiktionary.org/wiki/iron - a page and a half of contents for the English entry alone.
http://en.wiktionary.org/wiki/go - about two pages, only nine languages
http://en.wiktionary.org/wiki/one - two screens, twelve languages
http://en.wiktionary.org/wiki/box - two screens, only five languages
Seeing these entries, keep in mind that ideally all entries, not just the English ones, ought to be as comprehensive in the amount and type of information offered (in everything but the translation sections, which of course are generally only placed on entries for the wiki's native language). There *ought* to be, according to the way en.wikt structures its information, enough information to have as long a table of contents as [[lead]] or [[iron]] for each entry. If you can see more than one or two languages in the table of contents at a time, that's generally a sign you're looking at *stubs*. But the wiki shouldn't be designed for stubs, but for properly-sized articles.
*Muke! [1] http://www.useit.com/alertbox/9712a.html >> [P]ages that can be markedly improved with a scrolling >> design may be made as long as necessary, though it should >> be a rare exception to go beyond three screenfulls on >> an average monitor. [2] http://www.useit.com/alertbox/20050711.html >> In any case, all key information should be visible on the >> initial screen because scrolling can cause accessibility >> problems: >> * The additional action that scrolling requires can be >> difficult for users with motor skill impairments. >> * Low-literacy users can't easily reacquire their position >> in the text after it moves. >> * Elderly users often have trouble getting to the right >> spot in scrolling menus and other small scrolling items. [3] http://www.useit.com/alertbox/screen_resolution.html >> [S]crolling is always a key consideration. Users generally don't like to scroll [...] [4] http://blog.clicktale.com/2006/12/23/unfolding-the-fold/