Tabs for languages

[Анатолій Гончаров]

Sysop of Russian and Ukrainian Wiktionaries Al Silonov suggests to make tabs
for different languages if the word uses in many languages. He made example
here: http://ru.wiktionary.org/wiki/User:Al_Silonov/yucca . I made another
example: http://uk.wiktionary.org/wiki/November . But these examples use
subpages and we cannot add the tab "Add other language...". Can it be made
using scripts and without subpages? And who can make it?

--
Анатолій Гончаров (Ahonc)
mailto:Ahonc.ua@...
_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Gerard Meijssen-3]

Hoi,
How many languages do you currently support? What would be the maximum that
you could safely support ??
Thanks,
       GerardM

On Wed, Aug 13, 2008 at 5:35 PM, Анатолій Гончаров <ahonc.ua@...>wrote:

> Sysop of Russian and Ukrainian Wiktionaries Al Silonov suggests to make
> tabs
> for different languages if the word uses in many languages. He made example
> here: http://ru.wiktionary.org/wiki/User:Al_Silonov/yucca . I made another
> example: http://uk.wiktionary.org/wiki/November . But these examples use
> subpages and we cannot add the tab "Add other language...". Can it be made
> using scripts and without subpages? And who can make it?
>
> --
> Анатолій Гончаров (Ahonc)
> mailto:Ahonc.ua@...
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Conrad Irwin]

It can be done with javascript, I've done it on en.wiktionary. However the
tool that does this ([[en:User:Conrad.Irwin/parser.js]]) does way too many
other things. I ran into a peculiar bug with the # links to each section -
but I'm sure if I were to roll it out again it could be resolved.

The parsing of the page is fairly easy to do, assuming that all language
headers are <h2>, it's just a case of iterating over the whole document and
moving nodes into boxes, tabbing between boxes is trivial to implement in
javascript. The only issue occurs if you expect to get a language heading
within a box, in which case you have to parse recursively which is much
tougher.

The other thing to think about is Category links, do you want to split them
into languages too, that could be the trickiest bit.

It becomes a little ugly after 15 or so languages, as the bar of tabs begins
to take up a noticeable amount of the screen space, and so the useful
information gets pushed further down out of sight.


It would in some ways be nice to have each language separated by some PHP
allowing this effect for anonymous users too, but that leads to further
issues with urls and it would not be a trivial extension to write.

Conrad




2008/8/13 Gerard Meijssen <gerard.meijssen@...>

> Hoi,
> How many languages do you currently support? What would be the maximum that
> you could safely support ??
> Thanks,
>       GerardM
>
> On Wed, Aug 13, 2008 at 5:35 PM, Анатолій Гончаров <ahonc.ua@...
> >wrote:
>
> > Sysop of Russian and Ukrainian Wiktionaries Al Silonov suggests to make
> > tabs
> > for different languages if the word uses in many languages. He made
> example
> > here: http://ru.wiktionary.org/wiki/User:Al_Silonov/yucca . I made
> another
> > example: http://uk.wiktionary.org/wiki/November . But these examples use
> > subpages and we cannot add the tab "Add other language...". Can it be
> made
> > using scripts and without subpages? And who can make it?
> >
> > --
> > Анатолій Гончаров (Ahonc)
> > mailto:Ahonc.ua@...
> > _______________________________________________
> > Wiktionary-l mailing list
> > Wiktionary-l@...
> > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> >
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Gerard Meijssen-3]

Hoi,
If it becomes ugly after 15 languages, consider that there are something
like over 7000 languages out there. This is not taking into account dialects
and other linguistic entities that would make for something like over
30.000.
Thanks,
       GerardM

On Thu, Aug 14, 2008 at 12:48 AM, Conrad Irwin
<conrad.irwin@...>wrote:

> It can be done with javascript, I've done it on en.wiktionary. However the
> tool that does this ([[en:User:Conrad.Irwin/parser.js]]) does way too many
> other things. I ran into a peculiar bug with the # links to each section -
> but I'm sure if I were to roll it out again it could be resolved.
>
> The parsing of the page is fairly easy to do, assuming that all language
> headers are <h2>, it's just a case of iterating over the whole document and
> moving nodes into boxes, tabbing between boxes is trivial to implement in
> javascript. The only issue occurs if you expect to get a language heading
> within a box, in which case you have to parse recursively which is much
> tougher.
>
> The other thing to think about is Category links, do you want to split them
> into languages too, that could be the trickiest bit.
>
> It becomes a little ugly after 15 or so languages, as the bar of tabs
> begins
> to take up a noticeable amount of the screen space, and so the useful
> information gets pushed further down out of sight.
>
>
> It would in some ways be nice to have each language separated by some PHP
> allowing this effect for anonymous users too, but that leads to further
> issues with urls and it would not be a trivial extension to write.
>
> Conrad
>
>
>
>
> 2008/8/13 Gerard Meijssen <gerard.meijssen@...>
>
> > Hoi,
> > How many languages do you currently support? What would be the maximum
> that
> > you could safely support ??
> > Thanks,
> >       GerardM
> >
> > On Wed, Aug 13, 2008 at 5:35 PM, Анатолій Гончаров <ahonc.ua@...
> > >wrote:
> >
> > > Sysop of Russian and Ukrainian Wiktionaries Al Silonov suggests to make
> > > tabs
> > > for different languages if the word uses in many languages. He made
> > example
> > > here: http://ru.wiktionary.org/wiki/User:Al_Silonov/yucca . I made
> > another
> > > example: http://uk.wiktionary.org/wiki/November . But these examples
> use
> > > subpages and we cannot add the tab "Add other language...". Can it be
> > made
> > > using scripts and without subpages? And who can make it?
> > >
> > > --
> > > Анатолій Гончаров (Ahonc)
> > > mailto:Ahonc.ua@...
> > > _______________________________________________
> > > Wiktionary-l mailing list
> > > Wiktionary-l@...
> > > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> > >
> > _______________________________________________
> > Wiktionary-l mailing list
> > Wiktionary-l@...
> > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> >
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Анатолій Гончаров]

Gerard, do you know words which used in 7000 languages?

2008/8/14 Gerard Meijssen <gerard.meijssen@...>

> Hoi,
> If it becomes ugly after 15 languages, consider that there are something
> like over 7000 languages out there. This is not taking into account
> dialects
> and other linguistic entities that would make for something like over
> 30.000.
> Thanks,
>       GerardM
>
> On Thu, Aug 14, 2008 at 12:48 AM, Conrad Irwin
> <conrad.irwin@...>wrote:
>
> > It can be done with javascript, I've done it on en.wiktionary. However
> the
> > tool that does this ([[en:User:Conrad.Irwin/parser.js]]) does way too
> many
> > other things. I ran into a peculiar bug with the # links to each section
> -
> > but I'm sure if I were to roll it out again it could be resolved.
> >
> > The parsing of the page is fairly easy to do, assuming that all language
> > headers are <h2>, it's just a case of iterating over the whole document
> and
> > moving nodes into boxes, tabbing between boxes is trivial to implement in
> > javascript. The only issue occurs if you expect to get a language heading
> > within a box, in which case you have to parse recursively which is much
> > tougher.
> >
> > The other thing to think about is Category links, do you want to split
> them
> > into languages too, that could be the trickiest bit.
> >
> > It becomes a little ugly after 15 or so languages, as the bar of tabs
> > begins
> > to take up a noticeable amount of the screen space, and so the useful
> > information gets pushed further down out of sight.
> >
> >
> > It would in some ways be nice to have each language separated by some PHP
> > allowing this effect for anonymous users too, but that leads to further
> > issues with urls and it would not be a trivial extension to write.
> >
> > Conrad
> >
> >
> >
> >
> > 2008/8/13 Gerard Meijssen <gerard.meijssen@...>
> >
> > > Hoi,
> > > How many languages do you currently support? What would be the maximum
> > that
> > > you could safely support ??
> > > Thanks,
> > >       GerardM
> > >
> > > On Wed, Aug 13, 2008 at 5:35 PM, Анатолій Гончаров <ahonc.ua@...
> > > >wrote:
> > >
> > > > Sysop of Russian and Ukrainian Wiktionaries Al Silonov suggests to
> make
> > > > tabs
> > > > for different languages if the word uses in many languages. He made
> > > example
> > > > here: http://ru.wiktionary.org/wiki/User:Al_Silonov/yucca . I made
> > > another
> > > > example: http://uk.wiktionary.org/wiki/November . But these examples
> > use
> > > > subpages and we cannot add the tab "Add other language...". Can it be
> > > made
> > > > using scripts and without subpages? And who can make it?
> > > >
> > > > --
> > > > Анатолій Гончаров (Ahonc)
> > > > mailto:Ahonc.ua@...
> > > > _______________________________________________
> > > > Wiktionary-l mailing list
> > > > Wiktionary-l@...
> > > > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> > > >
> > > _______________________________________________
> > > Wiktionary-l mailing list
> > > Wiktionary-l@...
> > > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> > >
> > _______________________________________________
> > Wiktionary-l mailing list
> > Wiktionary-l@...
> > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> >
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

--
Анатолій Гончаров
mailto:Ahonc.ua@...
_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Muke Tever]

On Wed, 13 Aug 2008 10:34:03 -0600, Gerard Meijssen  
<gerard.meijssen@...> wrote:

> Hoi,
> How many languages do you currently support? What would be the maximum  
> that
> you could safely support ??

It's just a fancy format for a disambiguation page.  That particular  
design may not extend well, but in principle one could be devised to  
handle as many languages as necessary.


        *Muke!
--
http://frath.net/

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Gerard Meijssen-3]

Hoi,
Try the word Niue, we have a selection of languages that know this word in
OmegaWiki. I agree with Muke that another interface can be found that will
do a better job.  Even for this word you will not find 7000 languages,
obviously different scripts makes for smaller collections.
Thanks,
      GerardM

http://www.omegawiki.org/index.php?title=DefinedMeaning:Niue%20(631572)&dataset=uw

On Thu, Aug 14, 2008 at 11:06 AM, Анатолій Гончаров <ahonc.ua@...>wrote:

> Gerard, do you know words which used in 7000 languages?
>
> 2008/8/14 Gerard Meijssen <gerard.meijssen@...>
>
> > Hoi,
> > If it becomes ugly after 15 languages, consider that there are something
> > like over 7000 languages out there. This is not taking into account
> > dialects
> > and other linguistic entities that would make for something like over
> > 30.000.
> > Thanks,
> >       GerardM
> >
> > On Thu, Aug 14, 2008 at 12:48 AM, Conrad Irwin
> > <conrad.irwin@...>wrote:
> >
> > > It can be done with javascript, I've done it on en.wiktionary. However
> > the
> > > tool that does this ([[en:User:Conrad.Irwin/parser.js]]) does way too
> > many
> > > other things. I ran into a peculiar bug with the # links to each
> section
> > -
> > > but I'm sure if I were to roll it out again it could be resolved.
> > >
> > > The parsing of the page is fairly easy to do, assuming that all
> language
> > > headers are <h2>, it's just a case of iterating over the whole document
> > and
> > > moving nodes into boxes, tabbing between boxes is trivial to implement
> in
> > > javascript. The only issue occurs if you expect to get a language
> heading
> > > within a box, in which case you have to parse recursively which is much
> > > tougher.
> > >
> > > The other thing to think about is Category links, do you want to split
> > them
> > > into languages too, that could be the trickiest bit.
> > >
> > > It becomes a little ugly after 15 or so languages, as the bar of tabs
> > > begins
> > > to take up a noticeable amount of the screen space, and so the useful
> > > information gets pushed further down out of sight.
> > >
> > >
> > > It would in some ways be nice to have each language separated by some
> PHP
> > > allowing this effect for anonymous users too, but that leads to further
> > > issues with urls and it would not be a trivial extension to write.
> > >
> > > Conrad
> > >
> > >
> > >
> > >
> > > 2008/8/13 Gerard Meijssen <gerard.meijssen@...>
> > >
> > > > Hoi,
> > > > How many languages do you currently support? What would be the
> maximum
> > > that
> > > > you could safely support ??
> > > > Thanks,
> > > >       GerardM
> > > >
> > > > On Wed, Aug 13, 2008 at 5:35 PM, Анатолій Гончаров <ahonc.ua@
> gmail.com
> > > > >wrote:
> > > >
> > > > > Sysop of Russian and Ukrainian Wiktionaries Al Silonov suggests to
> > make
> > > > > tabs
> > > > > for different languages if the word uses in many languages. He made
> > > > example
> > > > > here: http://ru.wiktionary.org/wiki/User:Al_Silonov/yucca . I made
> > > > another
> > > > > example: http://uk.wiktionary.org/wiki/November . But these
> examples
> > > use
> > > > > subpages and we cannot add the tab "Add other language...". Can it
> be
> > > > made
> > > > > using scripts and without subpages? And who can make it?
> > > > >
> > > > > --
> > > > > Анатолій Гончаров (Ahonc)
> > > > > mailto:Ahonc.ua@...
> > > > > _______________________________________________
> > > > > Wiktionary-l mailing list
> > > > > Wiktionary-l@...
> > > > > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> > > > >
> > > > _______________________________________________
> > > > Wiktionary-l mailing list
> > > > Wiktionary-l@...
> > > > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> > > >
> > > _______________________________________________
> > > Wiktionary-l mailing list
> > > Wiktionary-l@...
> > > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> > >
> > _______________________________________________
> > Wiktionary-l mailing list
> > Wiktionary-l@...
> > https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
> >
>
>
>
> --
> Анатолій Гончаров
> mailto:Ahonc.ua@...
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Test Pilot]

First, proposed system will make user less likely to check what word mean in
second/third language.
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.
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.

In terms of language selection convenience, we already got "Contents" menu
with all languages clearly visible.

Vitaly

On Wed, Aug 13, 2008 at 11:35 AM, Анатолій Гончаров <ahonc.ua@...>wrote:

> Sysop of Russian and Ukrainian Wiktionaries Al Silonov suggests to make
> tabs
> for different languages if the word uses in many languages. He made example
> here: http://ru.wiktionary.org/wiki/User:Al_Silonov/yucca . I made another
> example: http://uk.wiktionary.org/wiki/November . But these examples use
> subpages and we cannot add the tab "Add other language...". Can it be made
> using scripts and without subpages? And who can make it?
>
> --
> Анатолій Гончаров (Ahonc)
> mailto:Ahonc.ua@...
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Muke Tever]

Vitaly V. <dr.vitall@...> 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 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.  I suspect, as well, that people who habitually  
edit two or more languages are used to finding the information for  
corresponding words on different pages; having them on the same page is  
merely a bonus (and increasingly less of a bonus on those future pages  
that may have entries for over a hundred languages on them).

> 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 don't know about your browser, but  
in mine it's _more_ convenient to open a link in a new tab than to  
duplicate one.

> In terms of language selection convenience, we already got "Contents"  
> menu with all languages clearly visible.

Really?  On http://en.wiktionary.org/wiki/a I get six screens of  
"Contents" to scroll through to see everything, and it's only got thirty  
languages and "Translingual" on it.  (There's also a screen's worth of  
categories at the bottom to boot.)  Even without adding more languages  
it'll be a lot less 'clearly visible' once more of the entries start  
progressing beyond the stub level and accumulate subheadings.



        *Muke!
--
http://frath.net/

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Test Pilot]

>> 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.

>> 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.

>> 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.

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.


>Really?  On http://en.wiktionary.org/wiki/a I get six screens of
>"Contents" to scroll through to see everything, and it's only got thirty
>languages and "Translingual" on it.

I use Wiktionary daily and look up lots of words different languages. I
never had a problem finding definition using "Contents", and in fact in most
cases I don't have to look/click contents menu.
Simple scrolling is more then enough usually. And that is fun, from time to
time, to check what word in question mean in weird  languadge...

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. But it could be
possible that we got very different search pattern behavior. If problem
widespread and real, could you please provide few, like 5 or six examples of
such words you expirienced in real life Wiktionary use? I really curiouse,
what type of words will be that.

And, if that is the case, could it be possible that we could improve
"Contents" menu itself, ruther then make an extra menu on top of the screen
PLUS remove/destroy some functionality that is already there.

Vitaly, aka TestPilot, author of WikiLook (Firefox extantion,
https://addons.mozilla.org/en-US/firefox/addon/7675)

On Fri, Aug 15, 2008 at 4:19 PM, Muke Tever <muke@...> wrote:

> Vitaly V. <dr.vitall@...> 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 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.  I suspect, as well, that people who habitually
> edit two or more languages are used to finding the information for
> corresponding words on different pages; having them on the same page is
> merely a bonus (and increasingly less of a bonus on those future pages
> that may have entries for over a hundred languages on them).
>
> > 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 don't know about your browser, but
> in mine it's _more_ convenient to open a link in a new tab than to
> duplicate one.
>
> > In terms of language selection convenience, we already got "Contents"
> > menu with all languages clearly visible.
>
> Really?  On http://en.wiktionary.org/wiki/a I get six screens of
> "Contents" to scroll through to see everything, and it's only got thirty
> languages and "Translingual" on it.  (There's also a screen's worth of
> categories at the bottom to boot.)  Even without adding more languages
> it'll be a lot less 'clearly visible' once more of the entries start
> progressing beyond the stub level and accumulate subheadings.
>
>
>
>        *Muke!
> --
> http://frath.net/
>
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Muke Tever]

Vitaly V. <dr.vitall@...> 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/

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Conrad Irwin]

2008/8/16 Muke Tever <muke@...>:

> Vitaly V. <dr.vitall@...> 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/
>
> _______________________________________________
> Wiktionary-l mailing list
> Wiktionary-l@...
> https://lists.wikimedia.org/mailman/listinfo/wiktionary-l
>

The format of the page makes no difference to the dictionaries
structure. This means that the only thing the tabs do is provide a
user view preference. As everyone has different opinions on what looks
and feels nice, there will be no agreement that tabs are good or bad,
people either like it or don't. I personally like it, and think that
is we had the option to open more than one tab at a time, and to
select multiple tabs to be open by default (or even no tabs at all),
then there would be a way to keep everyone happy. Whether to turn it
on for anonymous users or not is a discussion that can wait until
after people are using it as a personal preference.

Conrad

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Test Pilot]

What, clicking = good, scrolling = bad? No! We all use both ways to navigate
web pages and Wiktionary.
It is not about being bad/good thing. It is about removing/keeping choice...
And you can use either way at present.

But think, what happens if user look for Russian "язык" or "месяц" etc. with
new system? He will be forced to page that got Belorussian definitions.
What if person looks for Spanish "justa"? User will get irrelevant Esperanto
definition.
Italian "cinta"? Ones again, not related page about Indonesian noun.
While with interface as it is, I don't even have to click/scroll -
information is shown directly on my screen after search of above-words .
There dozens(if not hundreds) of thousands articles like that. And as
Wiktionary grow, there would be even more.

You say that there is few articles with too huge Contents menu. Legitimate
point. But why than we don't fix the real problem - menu itself. For example
by adding option to collapse all but top level entrees (e.g. languages).
Just the way we got "Hide" option right now.
But adding an extra menu to the top of each and every article plus
aggressively changing page layout do not sound to me like a right solution
for that.

My main point - current system more versatile and more convenient. In a
different ways. And contrary to what you say, I do believe, that the chances
of article to be edited/corrected related to how many time it was
shown/visited/looked into.

Vitally, aka TestPilot
_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Muke Tever]

Vitaly V. <dr.vitall@...> wrote:
> But think, what happens if user look for Russian "язык" or "месяц" etc.  
> with new system? He will be forced to page that got Belorussian  
> definitions.
> What if person looks for Spanish "justa"? User will get irrelevant  
> Esperanto definition.
> Italian "cinta"? Ones again, not related page about Indonesian noun.

Hmm? No, that would be silly. The only language that should get that  
priority in any kind of disambiguation scheme is the language of the  
wiki.  If the language of the wiki doesn't have that word, but other  
languages do, then one would get a disambiguation page, not whatever  
language happens to be first in alphabetical order.  This is how the Latin  
Wiktionary has done it for years now.  e.g.

http://la.wiktionary.org/wiki/greet
   (Not a Latin word, thus disambiguation)

http://la.wiktionary.org/wiki/formica
   (A Latin word; other languages linked from the bottom)

> While with interface as it is, I don't even have to click/scroll -
> information is shown directly on my screen after search of above-words .
> There dozens(if not hundreds) of thousands articles like that. And as
> Wiktionary grow, there would be even more.

Again, if you get all the information at once, it is because there is not  
much information there: you're looking at stubs.  As Wiktionary grows,  
there will be *fewer* like that.

> And contrary to what you say, I do believe, that the chances of article  
> to be edited/corrected related to how many time it was
> shown/visited/looked into.

Fair enough; but either the user is a casual browser, or someone looking  
for a specific piece of information.  In the former case, they are exactly  
as likely to run across [[язык (ru)]] as [[язык (bg)]], and in the latter  
case, they are by definition not interested in anything else we feel like  
showing them.

Again, there are better ways of getting people to look at information than  
relying on other headwords happening to be spelled the same way as what  
the user is actually looking for.  Heck, just showing five articles from  
the main namespace at *random* in addition to the main entry would be more  
useful for that purpose than just showing homographs, if exposure is the  
goal you're aiming at.

        *Muke!
--
http://frath.net/

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Lars Aronsson]

Vitaly V. wrote:

> What, clicking = good, scrolling = bad? No! We all use both ways
> to navigate web pages and Wiktionary.

This sounds like my favorite line from the movie "The
Bluesbrothers".  The band (playing blues) comes to a small place
in the countryside and asks what kind of music is usually played
there.  "We have *both* kinds: Country *and* Western."

When the choice is between scrolling and clicking, perhaps we
need to move on to something entirely new in interface design.

Wiktionary is limited by the Mediawiki software, which is great
for collaboratively writing an encyclopedia, but its innovation
is the "edit" button, not its browsing user interface.  What kind
of user interfaces do commercial dictionary software (without the
edit button and revision history) use?  Dynamic mind-maps?


--
  Lars Aronsson (lars@...)
  Aronsson Datateknik - http://aronsson.se

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Test Pilot]

>
> > But think, what happens if user look for Russian "язык" or "месяц" etc.
> > with new system? He will be forced to page that got Belorussian
> > definitions.
> > What if person looks for Spanish "justa"? User will get irrelevant
> > Esperanto definition.
> > Italian "cinta"? Ones again, not related page about Indonesian noun.
>
> Hmm? No, that would be silly. The only language that should get that
> priority in any kind of disambiguation scheme is the language of the
> wiki.

What? There is no "disambiguation scheme" in this proposal. Look at example
http://uk.wiktionary.org/wiki/November provided by Анатолій Гончаров in
original post. First language that starts with A was shown. Lets stick to
the point of discussion. *The core idea of this proposal is that we show
user only one language after he searched for a word.  Instead of showing all
results.*

And my major objection - we better show relevant information after user hit
"search" button, which is way more convenient, other then showing randomly
selected alphabetical article. Not showing anything would be even worse.

If the language of the wiki doesn't have that word, but other
> languages do, then one would get a disambiguation page, not whatever
> language happens to be first in alphabetical order.  This is how the Latin
> Wiktionary has done it for years now.  e.g.
>
> http://la.wiktionary.org/wiki/greet
>   (Not a Latin word, thus disambiguation)
>
> http://la.wiktionary.org/wiki/formica
>   (A Latin word; other languages linked from the bottom)


This is entirely different subject. I feel against creating millions of
disambiguation page, but this is something for different discussion.

 As Wiktionary grows,
> there will be *fewer* like that.


How come? Have you ever paid attention how many words defined in English or
French Wiktionary? Less then a million! And that is best Wiktionaries out
there. In Russian language alone there are roughly one and a half million
words. And there is absolutely nothing special about Russian language.
Estimations for Ukrainian or Belorussian would be similar. With very low
overlap - even alphabets are different. And there is thousands of languages
out there. Even if Wiktionaries grow at a rate of one million new articles
per year, in one century it would not be half of it supposed state in terms
of words defined.


>  they are by definition not interested in anything else we feel like
> showing them.


I don't know who define what I'm interested in, as a user. And I'm a user
indeed. And I rather have an easy access to information about word that
interests me, other then have it hidden behind interface.

Vitaly aka TestPilot
_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l

[Muke Tever]

Vitaly V. <dr.vitall@...> wrote:
>> Hmm? No, that would be silly. The only language that should get that
>> priority in any kind of disambiguation scheme is the language of the
>> wiki.
>
>
> What? There is no "disambiguation scheme" in this proposal. Look at  
> example http://uk.wiktionary.org/wiki/November provided by Анатолій
> Гончаров in original post.

...which is a page which apparently (for whatever reason) considers the  
English article primary, and has perfectly ordinary disambiguation links  
to [[November/la]] and [[November/de]]--no different than what you might  
find at the top of a wikipedia page--only displayed in a fancy simplified  
format instead of with the usual text which would be along the lines of  
"This page is about the English word 'November'.  For the Latin word, see  
[[November/la]].  For the German word, see [[November/de]]."

> This is entirely different subject. I feel against creating millions of
> disambiguation page, but this is something for different discussion.

Against millions of disambiguation pages when there are millions of things  
to disambiguate against?  Could you sell that viewpoint on any wiki?  Why  
this one?

>>  As Wiktionary grows, there will be *fewer* like that.
>
> How come? Have you ever paid attention how many words defined in English  
> or French Wiktionary? Less then a million! And that is best Wiktionaries  
> out
> there. In Russian language alone there are roughly one and a half million
> words. And there is absolutely nothing special about Russian language.
> Estimations for Ukrainian or Belorussian would be similar. With very low
> overlap - even alphabets are different. And there is thousands of  
> languages out there.

Overlap between languages doesn't matter for the particular point that  
remark was about.  There will be millions of articles, certainly.  But the  
remark was about seeing all the information at once after searching for  
the word, which is irrelevant to the number of languages on it: as  
Wiktionary grows, most pages will need to have all their separate sections  
for homographs, pronunciations, alternative spellings, etymologies, parts  
of speech, declension or conjugation tables, associated terms of various  
kinds, derived terms, etc., depending on the format of the wiktionary.  As  
I mentioned with the examples, some of those had *tables of contents* more  
than a screen high even with only one or two languages on the page, and  
this is supposed to be normal: when the pages are no longer stubs, you  
will not have the situation where "information is shown directly on [your]  
screen after search".

>>  they are by definition not interested in anything else we feel like
>> showing them.
>
> I don't know who define what I'm interested in, as a user. And I'm a user
> indeed. And I rather have an easy access to information about word that
> interests me, other then have it hidden behind interface.

Exactly the point.  If the user wants easy access to the word of interest  
to them, that pretty much excludes having several other words *not* of  
interest to them presented at the same time just because by some  
historical accident they happen to be spelled with the same letters.  The  
irrelevant data, namely the words the user is not interested in, should  
not be part of the interface hiding the word that does interest them, but  
so long as the words are all on the same page, that is the state of  
affairs.

And if a user happens to be interested in words that have the same  
spelling, they can click through to find them just as people click through  
to reach words with the same rhyme scheme in pronunciation sections, or as  
they click through to reach words with the same meaning in translation  
sections, or as they click through to reach words with the same root in  
etymology or derivation sections.  Is there a particular reason why words  
with the same spelling should be accorded special preference?

        *Muke!
--
http://frath.net/

_______________________________________________
Wiktionary-l mailing list
Wiktionary-l@...
https://lists.wikimedia.org/mailman/listinfo/wiktionary-l