Wiktionary:Votes/2012-10/Enabling Tabbed Languages

Hello, you have come here looking for the meaning of the word Wiktionary:Votes/2012-10/Enabling Tabbed Languages. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Votes/2012-10/Enabling Tabbed Languages, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Votes/2012-10/Enabling Tabbed Languages in singular and plural. Everything you need to know about the word Wiktionary:Votes/2012-10/Enabling Tabbed Languages you have here. The definition of the word Wiktionary:Votes/2012-10/Enabling Tabbed Languages will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Votes/2012-10/Enabling Tabbed Languages, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.

Enabling Tabbed Languages


  • Vote starts: 00:01, 22 October 2012 (UTC)
  • Vote ends: 23:59, 4 December 2012 (UTC)

Support

  1. Support Yair rand (talk) 02:00, 22 October 2012 (UTC)
  2. Once problems are fixed (those described by Ruakh in the BP poll that preceded this vote, and others. For example, a bot should be set in place to edit pages even only to place categories in the correct sections, both from recentchanges and from allpages or a dump, if none does now).​—msh210℠ (talk) 06:52, 22 October 2012 (UTC)
    The one I mention above is a deal-breaker AFAI'm concerned: no bot moving cats, this shouldn't go forward. Likewise Ruakh's things that I refer to (moving lede content into language sections and making plain links link to English sections from other languages'). This is an oppose vote until such are implemented. Another thing that should be done (but isn't a deal-breaker, since it affects only editors, not readers) is that on saving a section-edit, the view should revert to that section and not the first. Another is that the tabbed layout be made to load sooner if possible (per Dan P.'s comment, below, of 12:31, 27 October 2012 (UTC)).​—msh210℠ (talk) 07:57, 28 October 2012 (UTC)
    I've disabled the category edit tool. Re section-editing, as far as I can tell it has always been the case that the user is brought to the section they just finished editing. A category placement bot and lede fixes can't be implemented until the results of this vote are clear. --Yair rand (talk) 09:10, 25 November 2012 (UTC)
  3. Support —CodeCat 12:58, 22 October 2012 (UTC) But we should make lang= mandatory for linking templates like {{term}}, as it causes usability issues with tabbed languages otherwise. —CodeCat 12:58, 22 October 2012 (UTC)
  4. Support, once we make various needed changes. —RuakhTALK 13:40, 22 October 2012 (UTC)
  5. Support. — Ungoliant (Falai) 22:22, 22 October 2012 (UTC)
  6. Support —Μετάknowledgediscuss/deeds 20:56, 23 October 2012 (UTC)
  7. Support. It's great. This, that and the other (talk) 06:52, 26 October 2012 (UTC)
  9. Support Liliana • 18:52, 12 November 2012 (UTC) it's hard to go through beta testing without a public test phase. This is something that has been needed for years now. -- Liliana • 18:52, 12 November 2012 (UTC)
  10. Support. Yes, there are problems, and they should be solved (before implementation if possible, but I'm OK with it happening later too). I note that, as someone commented elsewhere, most Wiktionary pages only have one language and won't be terribly affected by this change anyway. Only the big pages like water or a will be really affected, and as far as I can tell for the better. --Pereru (talk) 09:15, 15 November 2012 (UTC)
    Sounds important. Maybe someone can determine the exact number of entries with and without multiple L2 titles? (i.e., entries with one or multiple languages) --Daniel 10:34, 15 November 2012 (UTC)
  11. Support Bequw → τ 16:34, 16 November 2012 (UTC)
  12. Support Dan Polansky (talk) 18:15, 21 November 2012 (UTC). I am switching to support, as I believe this is an issue that should be decided by a plain majority, given enough voters have taken part on the vote. --Dan Polansky (talk) 18:15, 21 November 2012 (UTC)
  13. Support DTLHS (talk) 18:16, 21 November 2012 (UTC)
  14. Support. I enabled them for me long ago. --Vahag (talk) 18:34, 22 November 2012 (UTC)
  15. Support. Matthias Buchmeier (talk) 12:50, 27 November 2012 (UTC)
  16. Support. —Angr 06:51, 28 November 2012 (UTC)
  17. Support but no sooner than the sysop making the switch is assured that there will not be wholesale breakage, per the objections raised. DAVilla 05:08, 29 November 2012 (UTC)

Oppose

  1. Oppose DCDuring TALK 03:24, 22 October 2012 (UTC)
    We have always had RhS ToC available, which yields the purported advantage of this proposal.
    This in no way solves the increasingly debilitating performance problems that we are increasingly suffering as our coverage of languages grows and use of our Rococo template system continues. If this proposal somehow relieved the server of the burden of transcluding templates for content that a given user is not interested in, like any translation tables, extended lists of cognates, or any but selected L2 sections, I could support it. #: I fear that it will end by worsening these problems. I am not impressed with the results of the radical reforms that have been imposed in the past. DCDuring TALK 18:04, 26 October 2012 (UTC)
    IMO, this isn't meant to improve performance, but instead to improve layout. When I look at WT:FB or scholarly analyses of Wiktionary's merits as a usable dictionary, I see complaints about aesthetic details often, but I can't remember ever having seen a complaint about loading times. —Μετάknowledgediscuss/deeds 23:36, 26 October 2012 (UTC)
    It is the massive use of templates instead of plainlinks required to the links from the tab for a language section one one page to go to the correct tab on another page that will be killing performance, AFAICT. I think almost all plainlinks to principal namespace will have to be replaced by {{l}}, {{term}} or similar. If each instance of those requires a performance-sapping template-existence test to get language (and script) right, the loading performance of ] (which uses {{t}} to the same effect) will become the norm for all large pages. A dictionary needs to have reasonably fast performance to be attractive to users. We will definitely not have fast performance with our current architecture. Tabbed languages will worsen performance by forcing more use of templates. If the template architecture could be replaced by something less kludgey (Will Lua save us?), perhaps tabbed languages could work. DCDuring TALK 01:53, 27 October 2012 (UTC)
    To test whether {{l}} makes a difference, get a timer and compare loading time for Wiktionary:Requested entries (English) (current version), which does not have {{l}}, with that for User:Ruakh/Test, which is a copy of the same page before {{l}} was removed. I get a huge difference, but YMMV. DCDuring TALK 19:10, 28 October 2012 (UTC)
    Oppose Dan Polansky (talk) 20:12, 25 October 2012 (UTC). While I acknowledge that our TOC is needlessly long and detailed, the tabbed languages option seems to make it too obscure to the reader of Wiktionary that there is in fact one underlying wiki page for all the languages. The TOC problem can be solved. I have a CSS that shows TOC most often as one line containing only the names of languages. You can try it out:
    /* Use simple horizontal TOC */
    .ns-0 table#toc li { display: inline; }
    .ns-0 table#toc li + li:before { content: ' · '; }
    .ns-0 div#toctitle { display: none; }
    .ns-0 table#toc { border-color: #DDDDFF; border-right: none; border-left: none; background-color: white; padding-top: 0px; }
    --Dan Polansky (talk) 20:12, 25 October 2012 (UTC)
    Why is it valuable that our readers know there's one underlying wiki page for all the languages?​—msh210℠ (talk) 05:35, 26 October 2012 (UTC)
    I don't really know. I kind of sense that it is valuable. I find it confusing when too much of what is going on underneath is obscured. I like wiki markup and prefer it to what-you-see-is-what-you-get editing variant of Wiktionary, should someone come up with such a thing.
    On another note, I don't like how the tabs are at the left rather than at the top.
    Furthermore, I do not see how section editing is possible with the tabbed languages enabled. Thus, while the read-only interface pretends there is a separate page dedicated to a single language, the editing interface no longer makes it possible to edit content relating to a single language. However, chances are I just haven't figured out how to edit a single language in the new tabbed language interface.
    Moreover, when editing a page and making a preview, I see non-tabbed language appearance; I think it confusing to have the two appearances, depending on what one is doing. --Dan Polansky (talk) 12:23, 27 October 2012 (UTC)
    When I enter a page such as cat#Malay, I see the non-tabbed wiki appearence for a short while after which it gets switched to the tabbed interface. Ugly. --Dan Polansky (talk) 12:31, 27 October 2012 (UTC)
    Last month I changed the script so that users of small screens (width less than 580px) get the tabs on top instead of at the side, but in general I think at the side is probably better. There's a section edit button at the top-right corner, just above the tab's top border. The preview problem is caused by a bug that was introduced with a Mediawiki upgrade some months ago. If the bug isn't fixed on the Mediawiki end before it's time to deploy, I'll add a temporary workaround to fix it. --Yair rand (talk) 18:30, 28 October 2012 (UTC)
    Actually, I'll just add the preview workaround now. Fixed. --Yair rand (talk) 19:50, 28 October 2012 (UTC)
    The appearance of the non-tabbed display for a bit before switching is due to the fact that loading and running gadgets from the top is not allowed by Mediawiki yet. Hopefully bug 27488 will be fixed at some point... --Yair rand (talk) 04:38, 31 October 2012 (UTC)
    What do you think of the delay now? I just made a change (which happens to come with some problems that I'm not sure how I'll fix) which might improve things significantly. --Yair rand (talk) 10:42, 25 November 2012 (UTC)
    There is still a delay at cat#Malay. It looks a bit different from what it was before, but a delay is still there. I am using Firefox on Windows Vista. --Dan Polansky (talk) 10:55, 25 November 2012 (UTC)
    Are you using the gadget version? That's the only one I applied the change to. Does it at any point display the standard table of contents? --Yair rand (talk) 11:01, 25 November 2012 (UTC)
    I think I am using the gadget version: I have enabled the thing via preferences. cat#Malay does not display the standard TOC at any point; it does display the cat image of the English entry, however. It shows the bars more horizontally distant than they should be, for a short while; it did not do this before. --Dan Polansky (talk) 11:06, 25 November 2012 (UTC)
    Okay, so here's the situation: JS currently doesn't have any way to run until the page is finished loading, and the page pretty much loads bit by bit, displaying the contents as they come in. This results in the non-TL format being displayed for a bit. What I was thinking might be a temporary solution until a fix for bug 27488 allows the JS to run earlier, would be to have CSS, which runs before the content is loaded, immediately fiddle with how the TOC will be displayed when it comes in, so that it looks like tabs until TL JS runs and makes the actual tabs and removes the TOC. This would allow it to look close enough to correct most of the time (but not when the user goes straight to a lower section, which is unfortunate). Since the TOC's list is also made up of links, the user could even click on them and have TL act on it once the page is finished loading. In your case, it was messing up a bit more than usual due to your TOC-modifying CSS that I had forgotten about despite you mentioning it in this very thread. (Sorry about that.) --Yair rand (talk) 15:31, 25 November 2012 (UTC)
  2. Oppose --Daniel 18:27, 27 October 2012 (UTC) Pretty, but... controversial. Maybe I'd support it when the project makes it past the beta stage. --Daniel 18:27, 27 October 2012 (UTC)
    Oppose at this time, given that even many of the voters who support it do so conditionally and noting its many problems. I'd rather those issues be solved first. - -sche (discuss) 19:00, 28 October 2012 (UTC)
    One complication with that line of reasoning is that some of those "problems"/"issues" are debatable if we don't intend to turn on Tabbed Languages. For example — right now we have a lot of links that point to entire entries rather than to specific sections. If we're not planning to enable Tabbed Languages, then are those links something that can (or should) be "solved"? If such issues prevent us from even making the decision to turn on Tabbed Languages, then we might have a Catch-22. —RuakhTALK 18:46, 21 November 2012 (UTC)
    Good point. And while I agree with much of what DCDuring says, above, I don't think some users' desire to use {{l}} in ever more places will or should be affected by the outcome of this vote: it's just as useful for users of non-tabbed browsing to be sent to the right section of a page as it is for TB users to be so sent, and the IMO triflingly minor inconvenience of not being sent immediately to the right section is no worse for TB users than non-TB users if we, as I prefer, continue to use plain wikilinking. So I abstain. - -sche (discuss) 23:27, 21 November 2012 (UTC)
    I suppose it wouldn't be so bad where {{l}} were not so expensive. If {{l}} or a replacement for it simply went to the L2 section if it existed and to the first L2 section if it did not and did not carry all the look-up-other-templates baggage, the performance penalty that it imposes would be virtually eliminated. DCDuring TALK 05:41, 22 November 2012 (UTC)
    I actually proposed removing the extra baggage from that template some time ago (it doesn't need gender, gloss etc. if all it does is make links), but it was opposed. —CodeCat 14:18, 22 November 2012 (UTC)
    Perhaps we need an alternative one-letter template that can replace {{l}} when appropriate. DCDuring TALK 15:45, 22 November 2012 (UTC)
    We could use subtemplates like {{l/en}} for all languages. — Ungoliant (Falai) 16:19, 22 November 2012 (UTC)
    Assuming that is indeed less taxing on the database, which it seems to be, let's do that! - -sche (discuss) 17:55, 22 November 2012 (UTC)
    I do think that would be a good idea, but how would we make sure that such a subtemplate exists for every language? Should we add it to {{langt}} so it can automatically check? —CodeCat 18:20, 22 November 2012 (UTC)
    We should have a bot create all of them, to make checking unnecessary. — Ungoliant (Falai) 18:32, 22 November 2012 (UTC)
    I see DCDuring has created {{k}}. I think it is desirable to have the linking template check for script, etc, so that the text can be displayed in font that can handle it, so I think Ungoliant's idea of {{l/fr}}, etc, is better than either {{l|fr}} or {{k|fr}}. And I agree, creating the subtemplates should be bot-able. - -sche (discuss) 19:36, 22 November 2012 (UTC)
    I think I need to understand why it is so important to check for script. I am obviously not on the same page with many folks here. What is the trauma caused by a failure of {{k}} (a failure of {{langname}}, the incredibly simple-minded template that only speeds the creation of L2 section links (the same syntax as the most common use of {{l}})? DCDuring TALK 19:43, 22 November 2012 (UTC)
  3. Oppose -- Gauss (talk) 17:54, 10 November 2012 (UTC)
  4. Oppose -- SemperBlotto (talk) 11:44, 18 November 2012 (UTC)
  5. Oppose --WikiTiki89 11:55, 18 November 2012 (UTC)
  6. Oppose Ƿidsiþ 07:41, 20 November 2012 (UTC)
    Support but not right now. DAVilla 05:43, 26 November 2012 (UTC)
    When, then? After the issues mentioned above are resolved? I fully realize that TL is in no state to be pushed site-wide right now (especially since I've been experimenting on it over the last little while, and there's still no disable button, and we still haven't made the necessary formatting changes to certain pages) but I don't think this vote passing would mean that it has to be enabled right away. --Yair rand (talk) 06:00, 26 November 2012 (UTC)
    I'll hold you to that. DAVilla 05:06, 29 November 2012 (UTC)

Abstain

Decision

Fails 13–6–0 (68%).​—msh210℠ (talk) 19:22, 23 November 2012 (UTC)

I will not argue the point if I can help it, but votes have passed at 68% before. —Μετάknowledgediscuss/deeds 19:24, 23 November 2012 (UTC)
68% is a pass as far as I know. —CodeCat 19:24, 23 November 2012 (UTC)
I opposed this proposal before abstaining; I'm no fan of TL. Even I have to say this proposal passes: depending on how you (msh210) read your vote of "This is an oppose vote until such are implemented", either 2/3 or slightly more than 2/3 of those voting supported the proposal. - -sche (discuss) 20:31, 23 November 2012 (UTC)
Does is take more than 2/3 or more than 3/4 for a pass on a non-constitutional matter like this? DCDuring TALK 20:49, 23 November 2012 (UTC)
In past investigations of passage thresholds, it has been established that nothing has ever required 3/4 support to pass. It's been said that, years ago, 70% was used as a threshold in some votes, but I can't offhand find an example, if one exists. I like some leeway (does 60% pass? depends on how major the vote is), but I don't think "a non-constitutional matter" (as two of you refer to it) like this—a vote on turning on by default a script that many users have already enabled, and which opponents can disable—can be rejected despite having two-to-one support. I note that, if construed as a vote, the "vote" on how to close this vote (!!) is currently 3/4 in favour of "it passes"... :P - -sche (discuss) 21:04, 23 November 2012 (UTC)
I was thinking (when I closed this) that 70% passes. If we say 2/3 passes, then this vote passes 13–6–0 (68%) once changes are made as described in my own vote: until then, it fails 11–7–0 (61%) (omitting Ruakh's vote also, since it was conditional). If we say 60% passes, then this vote passes 11–7–0 (61%) now.​—msh210℠ (talk) 06:34, 25 November 2012 (UTC)
I don't think Ruakh's vote was expressly conditional like yours, or if it was, he expressed himself rather unclearly. Unless he says something that clarifies his position, I think it would be incorrect to count him as anything but a support vote. (You, however, made your position extremely clear, so counting you as conditional makes perfect sense.) —Μετάknowledgediscuss/deeds 15:58, 25 November 2012 (UTC)
Correct — my vote was not conditional. I unconditionally support enabling Tabbed Languages by default; however, I believe that the process of enabling Tabbed Languages is more complex than just adding default into the gadget-definitions code, because it also involves things like (1) some mechanism for pointing links at the right language section, and (2) a bot-run to move lede content into language sections (or some sort of JavaScript change with that effect), and (3) etc. —RuakhTALK 03:47, 26 November 2012 (UTC)
I don't think we should really consider such conditional votes. The purpose of a vote is to clarify and codify consensus; if we introduce conditions then support no longer means support, and we get situations like this. It makes the vote lose much of its value. —CodeCat 16:02, 25 November 2012 (UTC)
If a vote is going to be binary — yes or no with no options for "yes after fixes" or the like — then you're going to get conditional votes (sometimes). A conditional vote then may be the sign of either a badly sculpted vote or one that's not yet ripe.​—msh210℠ (talk) 14:43, 26 November 2012 (UTC)
By my lights, a result strictly above 2/3 on a non-constitutional matter should be a pass, unless some unspecified extraordinary condititions ensue. --Dan Polansky (talk) 21:09, 23 November 2012 (UTC)
I think we could create a meta-vote like this: "For some votes, the result that strictly surpasses 2/3 is a pass". This would not clarify for which votes, but it would clarify that the threshold is as low as 2/3 under some circumstances. --Dan Polansky (talk) 21:11, 23 November 2012 (UTC)
As far as I know, there has never been a consensus on what constitutes a pass and a non-pass, it's just down to whoever closes the vote. Mglovesfun (talk) 15:36, 25 November 2012 (UTC)
That's my impression as well, though I doubt anyone would get away with calling 23% support a pass.—msh210℠ on a public computer 03:24, 26 November 2012 (UTC)
I've heard that, but personally I feel that 2/3 should be sufficient. Anyway, msh voted for the proposal, so I trust him to call it defeated. I've also added a late vote, thinking to mention that extending the voting period may have been considered a better approach. DAVilla 05:47, 26 November 2012 (UTC)
There's also the issue of the two users who voted in the BP pre-vote poll (one of which while this vote was running) but didn't vote here. I still don't know whether it would be considered canvassing to notify them of this discussion... --Yair rand (talk) 05:53, 26 November 2012 (UTC)
Not IMO. I've mentioned then-ongoing votes to people who had expressed interest in the issue, being careful to mention it to both those who had supported and those who had opposed.​—msh210℠ (talk) 14:43, 26 November 2012 (UTC)
Re: "..., there has never been a consensus on what constitutes a pass and a non-pass": There has never been a consensus about an exact threshold, but there has been consensus about approximate range, discernible from countless votes that passed or were closed as "no consensus" without there being a loud opposition to their closing. In its detail, this closing is not based on previous practice but rather may be used in further votes as evidence of thresholds actually being used. This is why I record here my opposition to using a threshold higher than 2/3 for this vote. -Dan Polansky (talk) 20:56, 27 November 2012 (UTC)

To legalize DAVilla's vote and allow Yair rand to get more interested editors to cast a vote, I have unilaterally extended this vote by about a week from today. If anyone disagrees with this extension, it can be reverted, but take care to strike DAVilla's vote as well. If this extension is accepted, I conclude that the vote is not yet closed. —Μετάknowledgediscuss/deeds 21:09, 26 November 2012 (UTC)

I support the extension. --Dan Polansky (talk) 20:56, 27 November 2012 (UTC)
Me, too.​—msh210℠ (talk) 09:10, 30 November 2012 (UTC)

Looks like it passes, 16-6-1. There are still a lot of things that need to be done before it's deployed, including:

  • We probably still have lots of uncategorized language sections that need to be dealt with. Ruakh, do you think you could generate User:Yair rand/uncategorized language sections/English and User:Yair rand/uncategorized language sections/Not English again?
  • Lede content needs to be moved into language sections. This would probably be best done by bot.
  • Links need to direct to language sections. This can be done either by javascript or by templates, not sure which would be better.
  • TL delay needs to be improved. There's probably not much we can do about this before a fix for bug 27488 is available, and I have no idea when that will be.
  • The script needs lots of testing to check for bugs. I think that when we eventually deploy, we should do it in stages, first just admins, then logged-in users, then everyone, so that we find as many bugs as possible before it reaches most readers.
  • We'll need code for an enable/disable button, to be added to Common.js. (I filed a bug 42687 asking for documentation on the API's action=options, so that I'll hopefully be able to have the disable button work on a per-user basis for logged in users, and not just per-computer.)
    Apparently it's just action=options&optionname=gadget-TabbedLanguages&optionvalue=#&token=XXXXXX+\\, with optionvalue=0 to turn off and optionvalue=1 to turn on. Enabling and disabling per account is fully possible. --Yair rand (talk) 20:36, 14 January 2013 (UTC)
  • (List is incomplete (probably). Feel free to add other deployment-blocking issues.)

Since the eventual default-on version is going to be the gadget, I'm going to consider both the PREFS version and the "button version" to be obsolete-ish, to be removed after deployment of the gadget version, so those might become buggy. --Yair rand (talk) 01:49, 5 December 2012 (UTC)

We had an all-admin test some time ago, actually. So we can skip that. Adding links to language sections would be better suited to templates, considering we already have the infrastructure in place. A JavaScript-only approach would not work here, because the JS can't know which language a link should point to, unless something on the page told it, in which case you've already arrived at the templated solution very quickly. —CodeCat 02:04, 5 December 2012 (UTC)
Wikious
Boobota
Sagapedia