Vitaly V. <dr.vitall(a)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/
--
http://frath.net/