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