Wiktionary:Grease pit/2012/January

From Wiktionary, the free dictionary
Jump to navigation Jump to search
This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.
Grease pit archives edit
2024
2023
Earlier years
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

January 2012

"familiar" and "slang" templates

Hi there,

can someone in the know fix the said templates to accommodate for this type of edit, please? http://en.wiktionary.org/w/index.php?title=reek&diff=15713037&oldid=15505223
Thanks, --Jerome Potts 06:15, 4 January 2012 (UTC)[reply]

Why would adjusting them for that be a fix? Use {{qualifier|slang}}.​—msh210℠ (talk) 18:37, 4 January 2012 (UTC)[reply]
Aha, thanks. --Jerome Potts 21:11, 4 January 2012 (UTC)[reply]
@Jerome Charles Potts I actually thought you meant 'can someone fix all these edits'. I probably can, I'll give it a go. Mglovesfun (talk) 21:25, 8 January 2012 (UTC)[reply]

Watchlist issue - deletions and blocks not showing up

I've noticed recently that I'm not seeing page deletions or user blocks on my watchlist. I remember seeing blocks a while ago, but I'm not sure I've ever seen deletions. Is this an admin-privileges thing, or a site issue? — lexicógrafa | háblame — 19:57, 8 January 2012 (UTC)[reply]

I don't know, but here are some data: I'm an admin here, but not at enWP. I picked an arbitrary deleted-today page at enWP and watchlisted it, and the deletion shows up on my watchlist. I did the same at wikt, and the deletion doesn't show up on my watchlist. Both sites are using the same version of the site software.​—msh210℠ (talk) 20:00, 8 January 2012 (UTC)[reply]
I deleted (deprecated template usage) ceiler a little while ago. I've just gone back and "Watched" it. It shows up when I "view and edit watchlist". SemperBlotto 20:17, 8 January 2012 (UTC)[reply]
Should have specified - I meant the "relevant changes" page of the watchlist, I can see recently deleted pages on the edit watchlist page too. — lexicógrafa | háblame — 20:20, 8 January 2012 (UTC)[reply]
Ditto.​—msh210℠ (talk) 22:53, 8 January 2012 (UTC)[reply]

Babel for language varieties

Do you think it would be useful to have babel templates for specific varieties of a language? It might be useful if you need someone who specifically speaks Belgian Dutch for example, or Valencian Catalan, especially for pronunciation sections. —CodeCat 18:30, 10 January 2012 (UTC)[reply]

Our pronunciation sections need to be based on reliable sources rather than users' personal intuitions anyway, don't they? —Angr 18:33, 10 January 2012 (UTC)[reply]
Ideally they ought to be, yes, but that's not how it's usually done AFAICT. Knowledge of what dialect someone has may be useful for things other than pronunciation.​—msh210℠ (talk) 20:45, 10 January 2012 (UTC)[reply]

Proposed change to {{does-template-exist}}

I'd like to replace the current contents of {{does-template-exist}} with the current contents of {{does-template-exist/temp}}. Since that is one of the most widely transcluded templates on the entire project, and it depends on weird parser edge cases, I thought I should post here first, and request review.

This is the change:

<onlyinclude><includeonly>{{safesubst:#switch:{{safesubst:urlencode:{{safesubst:Template:{{{1}}}}}}}|%5B%5B%3ATemplate%3A{{safesubst:urlencode:{{{1}}}}}%5D%5D=|%7B%7Bsafesubst%3ATemplate%3A{{safesubst:urlencode:{{{1}}}}}%7D%7D=|#default=1}}</includeonly></onlyinclude> {{documentation}}

As you can see, it's a small change. I believe it should have only the following effects:

  • Currently, {{subst:does-template-exist|/...}} always reports that {{/...}} doesn't exist (even if it does), and {{does-template-exist|/...}} always reports that it does exist (even if it doesn't). After the proposed change, both versions will correctly report whether it exists or not.
    • The main situation I've encountered this is {{/script}}, which frequently gets tested-for when lang= isn't specified in a template like {{term}}.
    • This effect is the purpose of the change.
  • Currently, {{subst:does-template-exist|User:...}} (or any other namespace) correctly reports whether User:... exists, but {{does-template-exist|User:...}} (transcluded rather than substituted) always reports that it does exist, even if it doesn't. After the proposed change, both versions will always report that it doesn't exist (because it will actually be testing for the existence of Template:User:...).
    • In particular: whereas {{subst:does-template-exist|Template:...}} currently correctly reports whether Template:... exists and {{does-template-exist|Template:...}} currently always reports that it does exist, both of these will now always report that it doesn't, because they'll actually be looking for Template:Template:.... This special case could be (mostly) addressed, by testing for the existence of {{safesubst:#ifeq:{{safesubst:padleft:|9|{{{1}}}}}|Template:||Template:}}{{{1}}} rather than the existence of Template:{{{1}}}, but I don't think the currently-proposed behavior is a problem, since there should never be a need for the caller to specify Template: anyway.
    • In particular: whereas {{subst:does-template-exist|:...}} currently correctly reports whether ... exists and {{does-template-exist|:...}} currently always reports that it does exist, both of these will now always report that it doesn't, because they'll actually be looking for [[Template::...]].
    • This effect was not specifically intended, but it doesn't seem detrimental to me.

I've tested this at User:Ruakh/Test.

—RuakhTALK 22:29, 10 January 2012 (UTC)[reply]

I won't pretend to understand all of this, but it looks good, and more importantly, I trust you. Mglovesfun (talk) 10:43, 12 January 2012 (UTC)[reply]
Ditto.​—msh210℠ (talk) 17:19, 12 January 2012 (UTC)[reply]

Default script for Serbo-Croatian

Right now this is Cyrillic, but that's only used in Serbia as far as I know, Bosnia and Croatia use only the Latin alphabet if I'm not mistaken (I don't know what Montenegro uses). So wouldn't it be better to make Latin the default script? —CodeCat 20:52, 12 January 2012 (UTC)[reply]

I agree. —RuakhTALK 23:15, 12 January 2012 (UTC)[reply]
Probably more important for us is that we have more sh in Latin script than we do in Cyrillic. Mglovesfun (talk) 19:39, 13 January 2012 (UTC)[reply]

Wiktionary very slow or not loading at all

Since I got home last night, Wiktionary is very slow or not loading at all. This also affects AWB. Am not having any problems with other websites. Mglovesfun 11:13 18 01 2012

The interface has been getting faster and faster for me all day; still a bit slow now, AutoWikiBrowser can't load Special:WhatLinksHere/Template:infl in order to change it to head; by the way, down to about 50 000 now which will be about two days work, starting from whenever AWB can load the list. Mglovesfun (talk) 13:11, 18 January 2012 (UTC)[reply]
Back to normal again, hmm. Mglovesfun (talk) 10:52, 19 January 2012 (UTC)[reply]
That was the same on fr.wikt. JackPotte

A little bug

If, in Recent Changes, you try to look at the diff of a page which has been deleted in the meantime, you get an inappropriate error message: "Sorry: the page title you requested is not supported by our software." (Example, a page I deleted: [1]). Equinox ◑ 19:41, 20 January 2012 (UTC)[reply]

That's the same on fr.wikt. JackPotte 17:36, 21 January 2012 (UTC)[reply]

Collapsible templates, especially {{trans-top}}

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

With MW 1.18 there are two classes, mw-collapsible and mw-collapsed1 which are available to make nearly any html element collapsible. This may obviate some of the measures currently in use on en.WT. This is particularly relevant to mobile use of wiktionary, with the infamous example of the translation tables at en.m/water. The mobile site is served using Extension:MobileFrontend2, which strips out a range of content deemed inappropriate for mobile devices - apparently including the show/hide scripts used by Wiktionary via common.js.

The reason this has been noticed as a problem is a group of student developers are working to create and improve a Wiktionary-specific Android app. They have a working product now, but are working on adding wiktionary-specific features and functions, and very very long translation tables which do not collapse correctly are UX issue for their project. - Amgine/ t·e 05:38, 22 January 2012 (UTC)[reply]

A simple demo is at Template:trans-top/new. It would be easy to move the correct styles over. It should be straightforward to tweak User:Yair rand/TargetedTranslations.js and User:Conrad.Irwin/editor.js. The visibility toggling might also have to be tweaked, but I can't remember how that's handled. If it's possible, the shift sounds like a good idea since we'd be shifting to more standardized mediawiki structures as well as helping mobile users. --Bequw → τ 21:04, 24 January 2012 (UTC)[reply]
The mobile site does not load the scripts for mw-collapsible and mw-collapsed, either. It would be difficult (if not impossible) to switch everything over, but even if it was simple, I don't think it's a good idea. The $.makeCollapsible script used is not better than our NavBar script.
What I'd like to have would be the expandable tables using the <details> and <summary> elements to allow native handling of expandable sections, with a JS fallback for nonsupporting browsers, but unfortunately those elements are not in the Mediawiki tag whitelist. --Yair rand 22:50, 24 January 2012 (UTC)[reply]
That would certainly not work across many wiktionaries. I am working with the MW developers to get support for collapsible inside the MobileFrontend. The local solution which only works in traditional desktop browsers will certainly break any support by the MW developers in the MF. Do you think you will consider using the standard which does exactly the same thing? - Amgine/ t·e 23:00, 6 March 2012 (UTC)[reply]
Yair rand informs me this is unlikely to ever be implemented on en.WT. Most likely this means the app will never be published as en.WT is pretty illegible and useless huge scrolls translation tables. I guess that's the community's choice. - Amgine/ t·e 06:08, 7 March 2012 (UTC)[reply]
This seems like a WT:BP matter. From this discussion, it is not clear what the implications would be for either mobile users or computer users under the options that seem to be proposed. It may be that our current entries with full translation tables are not suited for mobile applications on most current hardware. Perhaps we need private developers to implement display of translations only in languages selected by the user. DCDuring TALK 12:40, 7 March 2012 (UTC)[reply]
For mobile users, currently all collapsible templates are uncollapsed, but all L2 sections are collapsed by default. For desktop/laptop users all L2 sections except the top one (English or International) are collapsed, and all collapsible templates are collapsed. (en.WT is completely responsible for the maintenance of this script, and none of it is internationalised.)
If en.WT implemented mw-collapsible, for mobile users the collapsible templates will be collapsed, all other elements will remain the same. For desktop users there will be no visible change. (en.WT will not be responsible for maintenance of the script, and it will continue to be internationalised.) - Amgine/ t·e 17:40, 7 March 2012 (UTC)[reply]
Thanks. Wouldn't we want to follow MW for the medium- and long-term good of en.wikt? What are the other considerations? It certainly seems like a BP matter, rather than a narrowly technical one. DCDuring TALK 18:44, 7 March 2012 (UTC)[reply]
It is not correct that there would be no visible change for desktop users. The VisibilityToggles system, which allows users to change the default visibility of all of any type of expandable table (see the "Visibility" section of the sidebar), requires that the current system be used. The thread referenced by Amgine is here, by the way. --Yair rand (talk) 20:34, 7 March 2012 (UTC)[reply]
Presumably we could rewrite VisibilityToggles to work with the new MW standard. If it's a standard baked into the MW software, I suspect we'd want to make use of it, all else being equal. Of course, whether all else is actually equal is a question we'll need to answer with some trial. The new mw-collapsible forces the user to click on the show/hide button, whereas our homebrew solution allows them to click anywhere. Also....the mw-collapsible seems to expand really slowly, as in it takes about a full second to fully expand. If that's a standard speed in terms of pixels/time, then large translation tables would take forever. If it simply takes that long to open, regardless of how big the underlying content is, that's probably ok. -Atelaes λάλει ἐμοί 20:53, 7 March 2012 (UTC)[reply]
*tests a bit* It seems to be a constant amount of time, so if there's more content, then it opens and closes proportionally faster. —RuakhTALK 20:56, 7 March 2012 (UTC)[reply]
If we have a sufficient number of technically adept admins with eyes on this matter and we are not departing from MW's technical evolution, this need not be a BP matter. DCDuring TALK 13:02, 8 March 2012 (UTC)[reply]
Eventually this'll probably need to go to the BP, but not before we have the technical details hammered out as best we can. Once we have all our technical stuff worked out, then we can bring them there and let the general public (so to speak) weigh the pros and cons of all the options. -Atelaes λάλει ἐμοί 05:25, 9 March 2012 (UTC)[reply]

I've given the matter a bit more thought, and here's where I'm at so far. I really like Conrad's global visibility toggles, and use them quite frequently. As mw-collapsible is currently coded, there's no good way that it could plug into that system, and so if we converted everything to mw-collapsible, we'd lose the visibility toggles, and I think that would be a shame. Some of you may have noticed the wording 'good way', and, to be clear, there are probably some really terrible, kludgy ways we could make it work, like adding an event to the show/hide buttons, so we'd have the link activating the actual toggling, with an event communicating with the global toggles. I've no idea if it would even work. If any of our resident JS ninjas have any thoughts on this, they should produce them. Another route is we could post a note at the MW talk page and see if they'd be willing to add some kind of a hook we could attach stuff to, in which case it would be pretty easy to make everything work. It should be noted that fixing this or not fixing this shouldn't be a deal breaker for the mobile Wiktionary site. The English Wiktionary is clearly the biggest and most important of the Wiktionaries, and if the developers can't deal with our homebrewed translation tables, they're really being a bunch of slackers. It shouldn't be that hard, regardless of what we do on this end. That being said, it behooves us to do what we can to make their lives as easy as we can practically do. Also, and this is admittedly an idle rant, but this all comes back to the fact that MW is a fucking terrible platform to build a dictionary on. Home-brew solutions are the only route we have to making our project somewhat presentable, but they can come back to bite us from time to time. However, I remain convinced that they're better than simply accepting MW as given. -Atelaes λάλει ἐμοί 05:25, 9 March 2012 (UTC)[reply]

The mobile team is looking at some options which will deal with this.
  • Simplest: delete all translation/derivation templates and content.
  • Create a custom solution for each collapsible template on en.WT, which will break as soon as en.WT alters those template. (Process will need to be replicated for each language which uses en.WT's custom code.)
More options are being looked at, but those are the two most likely to be implemented at the moment. - Amgine/ t·e 18:38, 9 March 2012 (UTC)[reply]

categorytree

Apparently, trying to do {{#categorytree:en:Canids}} tries to load up Category:Canids instead, while all other languages work fine. This seems to be a remnant from when we still had English words in the parent category, so can this be fixed? -- Liliana • 05:51, 23 January 2012 (UTC)[reply]

Actually, I think this is because en: is this wiki, so it strips out en: from the beginning of any links. {{#categorytree:Category:en:Canids}} works. --Yair rand 05:55, 23 January 2012 (UTC)[reply]

α

The link on the upper right of the entry for α that should go to β is a redlink, but β is definitely an article. What's going on, and how do I fix it? Metaknowledge 20:55, 23 January 2012 (UTC)[reply]

Similar problem at ζ and σ, except worse: no link appears. Metaknowledge 21:34, 23 January 2012 (UTC)[reply]

Fixed. —Stephen (Talk) 23:29, 23 January 2012 (UTC)[reply]

A question about template transclusions...

Does anyone know if a template with no parameters that is transcluded many times on a page is any slower than when it's transcluded only once on the page? —CodeCat 23:00, 23 January 2012 (UTC)[reply]

Normally, the hard work of transclusion takes place when you edit a page that uses the template, or when you edit a template that is directly or indirectly transcluded in such a page. (This includes the case where you edit the template itself, of course.) So it shouldn't have a noticeable effect. (Unless the template itself does expensive things, of course, but it doesn't sound like that's what you mean?) —RuakhTALK 23:35, 23 January 2012 (UTC)[reply]
I was wondering mostly... if a page includes many language templates, would it hurt to include them all a second time on that page? —CodeCat 23:45, 23 January 2012 (UTC)[reply]
Not noticeably, no. —RuakhTALK 00:32, 24 January 2012 (UTC)[reply]

Problem with accelerated entries

For a little while now accelerated entries I've created have ended up looking like this. Could someone fix this so we don't have to replace {{subst:?}} with #? I would ask Conrad.Irwin, but he hasn't been active in a while. Ultimateria 22:13, 27 January 2012 (UTC)[reply]

I bet someone with a non-Unicode capable browser broke the script. -- Liliana • 22:15, 27 January 2012 (UTC)[reply]
It works for me. I don't know if that's because someone has fixed it, or because there's some relevant difference between our browsers. (FWIW: I'm using Firefox 9.0.1 on Windows 7.) —RuakhTALK 23:02, 27 January 2012 (UTC)[reply]
Since posting this, I see no green links even where I know they should be (anomal for instance). I use Chrome on Windows 7 but I also tried Internet Explorer, I checked my per-browser preferences, and I connected to a different network. I'm not sure what else to do... Ultimateria 23:45, 27 January 2012 (UTC)[reply]
Update: takeover bids appeared as a green link, but non-English forms are still redlinks. Ultimateria 00:04, 28 January 2012 (UTC)[reply]
I fixed the {{subst:?}} issue; the lack of green links for non-English entries is new to me, I have no idea why that is. Mglovesfun (talk) 20:10, 31 January 2012 (UTC)[reply]
By the way, {{♯}} (a really bastard to type) isn't needed anymore, is it? WT:ACCEL uses it for section linking, such as {{plural of|nocat=1|[[casa{{subst:♯}}Spanish|casa]]|lang=es}} whereas as {{plural of|nocat=1|casa|lang=es}} does the same thing. No piped link needed, not for about 18 months now. Mglovesfun (talk) 22:59, 1 February 2012 (UTC)[reply]
Everything is working again. I don't know if it's something you guys did...but just in case, thank you. :P Ultimateria 18:11, 2 February 2012 (UTC)[reply]

Quotations

Hi, may I ask my question here? If not, please tell me where to go ...

I've got a question regarding quotations, and another Wiktionary (no.wiktionary.org): We like your way of making quotations collapsable (with the text "quotations [arrow]", but so far, I haven't been able to adopt the script to no.wikt ... Is there anyone that could help me? If you know, I would appreciate it a lot! Mewasul 18:28, 28 January 2012 (UTC)[reply]

I think that you're making reference to the paragraph Hidden Quotes of MediaWiki:Common.js. JackPotte 19:06, 29 January 2012 (UTC)[reply]
Maybe fr:MediaWiki:Gadget-HiddenQuote.js can help you to install the function. JackPotte 20:08, 29 January 2012 (UTC)[reply]
I am refering to that paragraph exactly .. and I can copy it, but I still don't get how to make it work on no.wikt. What exactly do I write in on the entries, or at the quotation template, to make it use that function? Mewasul 10:24, 1 February 2012 (UTC)[reply]
Nothing special needs to be added. Any unordered list inside an ordered list will be collapsed:
# ...
#* ...
--Yair rand 10:27, 1 February 2012 (UTC)[reply]

I see – thank you so much, every one of you!! It works perfectly. Greetings, Mewasul 13:44, 1 February 2012 (UTC)[reply]

Beer parlour --> 敠

Why on earth, when I click on Wiktionary:Beer parlour, does it redirect to 敠? This is unusually infuriating. Metaknowledge 23:56, 28 January 2012 (UTC)[reply]

It appears to have been vandalism. Liliana-60 (talk • contribs) has reverted it now. —RuakhTALK 01:28, 29 January 2012 (UTC)[reply]
Successful troll was (ephemerally) successful I guess? 50 Xylophone Players talk 01:10, 2 July 2012 (UTC)[reply]

Template:recons feature request

I think it would be useful, if when you hovered over ' * ', a tool-tip saying “unattested” appeared. If we are replacing '<' with 'from', this should be done too; not everyone knows what * means. --Vahag 09:22, 31 January 2012 (UTC)[reply]

Done. --Yair rand 09:26, 31 January 2012 (UTC)[reply]
Thanks. --Vahag 11:56, 31 January 2012 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2012/January&oldid=65117904"