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/