Hello, you have come here looking for the meaning of the word Wiktionary:Grease pit/2016/February. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Grease pit/2016/February, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Grease pit/2016/February in singular and plural. Everything you need to know about the word Wiktionary:Grease pit/2016/February you have here. The definition of the word Wiktionary:Grease pit/2016/February will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Grease pit/2016/February, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
Some people have reported not receiving pings sent using {{ping}}. Anyone know why this happens? Someone once mentioned something about the ping needing to be in the same paragraph as the signature. Is this really true? (It seems quite suspect to me.) Benwing2 (talk) 07:01, 1 February 2016 (UTC)
User:Benwing2, And someone said it works when a new signature is added (or updated). This seems very logical to me.— This comment was unsigned.
I believe the ping is done as part of, or is triggered by, the expansion of the tildes. I've had good results with simply replacing my signature with the tildes when re-pinging, but I seem to remember someone saying it wouldn't work if you decreased the size of the post. Chuck Entz (talk) 13:34, 1 February 2016 (UTC)
@CodeCat I tried to put {{inh|rup|LL.|sclavus}} at the beginning of the etym section for shcljau and got an error "Lua error in Module:etymology at line 73: Late Latin is not an ancestor of Aromanian." Seems to me Late Latin IS an ancestor of Aromanian and other Romanian dialects. Is this fixable easily or is it a more basic bug in how {{inh}} deals with etymology-only languages? Benwing2 (talk) 07:14, 1 February 2016 (UTC)
A lot of entries in this category are due to someone using {{quote-newsgroup}} with both date= and year= set. A solution is to move the year into the date= parameter like . Would it be possible to fix these pages in that manner with a bot? - -sche(discuss)22:26, 1 February 2016 (UTC)
I'm searching pro a website listing all terms using Qoppa, San, Digamma (both version) and others ancient removed letter, I can't find any in web, do you know something ? 91.180.227.17209:57, 20 January 2016 (UTC)
Why would we need to create a separate module? We can easily modify the show_headword_line function in Module:headword. Perhaps add a category in Module:languages/data for a list of 'notable' characters (e.g. "", although it would certainly have more characters), then something like for i in mw.ustring.gmatch(<headword>,<list>) do <add category> end. (Alternatively, you could do the reverse, and make a list of characters that are typical, then your function would be the same except the list would be "". This may be easier.) CodeCat, comments?—ObsequiousNewt (εἴρηκα|πεποίηκα) 17:22, 20 January 2016 (UTC)
@ObsequiousNewt: That's fair. Though specifying them in each headword template for a language is a pain. The optimal method, I think, would be to specify notable = "", in Module:languages per language and then reference that list in Module:headword. I think it would be nice to have a "notable" category that get categories by character and then a catchall which will get anything outside of the "standard characters" + "notable characters". This would also be useful for debugging. —JohnC518:34, 20 January 2016 (UTC)
@Wikitiki89: Lol, I do now! I skimmed over this earlier and clearly misread everything. Newt shows him/herself to be as prudent and wise as ever; whereas I am always making careless misakes. —JohnC523:01, 20 January 2016 (UTC)
I think we will want to have some kind of global list of characters that are not interesting in any language. This would include spaces, punctuation and the like. For individual languages, a list of uninteresting characters would be far more effective than a list of unusual characters, too. —CodeCat01:00, 25 January 2016 (UTC)
It can be done, but I would propose a trial with just one language first, so that we can iron out any problems before it's done more widely. —CodeCat00:02, 2 February 2016 (UTC)
Support. An alternative is to have a bot go through the database dumps periodically and add categories, but ... this sounds like less work in the long run. - -sche(discuss)02:40, 2 February 2016 (UTC)
Support, but I disagree with CodeCat and think that we should specify characters that we want categories for, rather than characters that we don't want categories for. Not all random characters that might happen to appear in a word are actually interesting. --WikiTiki8919:48, 3 February 2016 (UTC)
Done. The second category was created by User:Babel AutoCreate, a script (not a user or bot) which mostly adds valid cats whenever people use them on their user-pages. In cases where it adds invalid cats, the solution is to delete them and protect the pages so they can only be recreated by an admin. - -sche(discuss)03:14, 13 February 2016 (UTC)
prefix template
Hi ! I just created heahflod, using the prefix template in the Etymology section, and I'm seeing what looks like an attempt by it to establish a template (it's asking for documentation tab). Please help Leasnam (talk) 00:10, 4 February 2016 (UTC)
See image. Someone seems to have broken MediaWiki somehow so that <noinclude> is now just unformatted text. See image above. I encountered the same problem on commons: while trying to upload the image. Renard Migrant (talk) 00:23, 4 February 2016 (UTC)
I wonder how long it will take for this to flush out of the system once fixed. I wonder whether the system will have to go down for to accelerate the flushing. DCDuringTALK00:31, 4 February 2016 (UTC)
Hi folks, sorry about that. I tried to change the behavior of unclosed XML-like tags to no longer eat everything afterwards on a page, which tends to break things horribly for most tags. It's being reverted now. Although I don't understand why you chose to rely on this behavior for apparently every single template with documentation on the whole wiki… Matma Rex (talk) 00:42, 4 February 2016 (UTC)
I don't think anyone "relied" on this on purpose. It was probably an oversight in one template and then just got copy&pasted into other ones, as things go in MediaWiki land. Jberkel (talk) 00:59, 4 February 2016 (UTC)
I did it on purpose a lot. One thing I have learned is that people will use whatever works, and to stop them, you have to make it stop working. —CodeCat01:09, 4 February 2016 (UTC)
Oh well then. Regardless of the reasons, it's definitely not safe for the parsing code to assume well-formed input. Probably a task for a bot to check & add the missing closing tags? Jberkel (talk) 01:42, 4 February 2016 (UTC)
For the less technically literate among us, what exactly is causing this problem? Is it a problem with templates themselves, or does it need fixing on individual pages? A lot of pages are still displaying like this for me, though oddly, some that were before now look normal. Andrew Sheedy (talk) 03:00, 4 February 2016 (UTC)
Imagine <noinclude></noinclude> as a box, where things go inside the box, such as <noinclude>HOW TO USE THE TEMPLATE:</noinclude>. Specifically, <noinclude></noinclude> means that the text inside should be shown when looking at a page (template, in this case) directly, but not when you include the page on another page (after all, no one needs to see "HOW TO USE THE TEMPLATE:" when trying to navigate an entry; that would be downright odd). For some reason a lot of the templates have boxes that aren't closed (<noinclude>). The box used to be automatically closed by the code that converts wikicode to HTML, but not anymore, so now all of the contents (template documentation) spill out onto the pages (because the software no longer sees the unclosed 'box' as "do not include this text when including the page on another page"). —suzukaze (t・c) 03:06, 4 February 2016 (UTC)
(e/c) The cause of the problem is that many templates used improper syntax (omitting the closing </noinclude> tag). This improper syntax used to work anyway, but the MediaWiki developers released an update that caused this syntax to stop working. The two potential solutions are: (a) to fix all our templates or (b) to roll back the software update. Option (a) is the only one we have control over, and is something we should do regardless of whether it is necessary. Option (b) is out of our control and probably not the best solution in the long run anyway. Essentially only templates need to be fixed, and some have already been fixed. --WikiTiki89 03:12, 4 February 2016 (UTC)--WikiTiki8903:12, 4 February 2016 (UTC)
It looks like the update has been rolled back, but there are still lots of entries that won't be normal until the edit queue gets around to them or until someone does a null edit on each of them. I do recall an incident not that long ago when someone added categories or interwikis (I don't remember which) to the end of a template after the </noinclude>, and they ended up in every entry that used the template. That would be less likely to happen without a closing </noinclude>. Still, I don't like leaving loose ends like this hanging. Chuck Entz (talk) 03:50, 4 February 2016 (UTC)
Makes sense, suzukaze and Wikitiki, thanks. And while I figured out that null edits fixed the problem since the rollback, I wasn't sure if I was actually accomplishing anything, so I'm glad to learn that it is. Andrew Sheedy (talk) 03:58, 4 February 2016 (UTC)
The lingering effect seems to on search more than on the entries themselves. That is, the loaded entry pages generated by the search Chuck linked to above don't contain the nonsense. DCDuringTALK04:01, 4 February 2016 (UTC)
I will go through the ones which are easy to fix, the ones which just need a closing noinclude at the end. I will also make a list of templates which have unbalanced noinclude and includeonly tags which will have to be cleaned up manually. - TheDaveRoss02:59, 5 February 2016 (UTC)
They seem fine to me. They are a bit confusing though, because they are meant to be substed and some of the tags are actually meant to be including themselves in the subst. --WikiTiki8902:34, 7 February 2016 (UTC)
If it could be done, .... Maybe we need special edit windows for template and module space that managed syntax and formatting. Too bad missing documentation couldn't be handled the same way. DCDuringTALK14:56, 4 February 2016 (UTC)
I have never made an edit filter, but I think something along the lines of this would work for the two main offenders:
On second thought, I just gave it a try and created Special:AbuseFilter/47. If those who know about such things would like to take a look that would be great. It seems to work, and gives a warning when there are unbalanced noinclude or includeonly tags. If regex is allowed in abuse filters I suppose it could work for any unbalanced tags, but that would get more complicated and more expensive. - TheDaveRoss00:20, 7 February 2016 (UTC)
Looks good. Regexes are more complicated and processing intensive, I think this should be good enough for the majority of cases. Also checked, there's no whitespace allowed (e.g. </ noinclude>) and the tags are case sensitive (</Noinclude>), so we shouldn't need anything more complicated anyway. Jberkel (talk) 03:49, 7 February 2016 (UTC)
I wrote a tool to check for unclosed noinclude tags in an XML dump. Looks like most occurrences have already been fixed by @TheDaveRoss (thanks!). I fixed the remaining handful I came across except for {{documentation subpage}} which is locked. I'll rinse and repeat once a more recent dump gets published. Jberkel (talk) 02:53, 7 February 2016 (UTC)
Not taking screen to right section header from watchlist
For some time (weeks?), clicking on the section header as for sheer on a page like WT:RFV (WT:RFV#sheer) would not take me to the section. Why? I assume this occurs because there is an obsolete section number. In contrast, the above named section link takes me to the right section. Does it happen to others? Is it something that can be corrected? What could I change in my behavior to reduce the annoyance? DCDuringTALK13:04, 4 February 2016 (UTC)
I created multireflector recently. If you visit Category:English words prefixed with multi-, it's listed in both "Recent additions to the category" and in "Oldest pages ordered by last edit". Why should it appear in the latter? Does creating a page not count as an edit? If so, that stops this feature from being very helpful in finding long-untouched pages. Equinox◑15:42, 4 February 2016 (UTC)
According to the specification the second list comprises of "pages sorted by date pages were last edit". I have removed "Oldest" part.
Interestingly the specs also adds
It should be noted, that lastedit really sorts by the last time the page was touched. In some cases this is not equivalent to the last edit (for example, this includes permission changes, creation or deletion of linked pages, and alteration of contained templates).
Now, I have a dim memory that somewhere on Wiktionary it was said that you can create templates using JS as well as Wikitext and Lua, but I can't find it anymore and it contradicts what the Wiki HQ says about Scribuntu. So I'm no longer that much convinced that it was about templates - or even more than a dream. Can JavaScript ever be used to edit mainspace pages? Korn (talk) 22:47, 7 February 2016 (UTC)
I meant whether I can {{#invoke:}} modules written in Javascript so I don't have to write e.g. conjugation tables in Wikitext. Korn (talk) 08:56, 8 February 2016 (UTC)
The template {{rfdef}} is malfunctioning. The documentation does not explain what is missing when I use the template on the entry for marvellously to request a definiton. Instead the template thinks a translation is needed and spouts something about Lua. In the event that the template is functioning correctly, then the documentation needs to be altered to match current template function. --EncycloPetey (talk) 01:41, 8 February 2016 (UTC)
I thought this was pretty clear: "Lua error in Module:utilities at line 97: Language code has not been specified. Please pass parameter 1 to the template." --kc_kennylau (talk) 01:53, 8 February 2016 (UTC)
I think there should be more effort made by folks updating or converting templates/modules to ensure backwards compatibility. So many templates/modules are broken in historical revisions, and plenty of things are broken on live pages. In the case of the current topic it should handle a missing language parameter either by providing a default value or by gracefully failing (by categorizing the entry and providing the expected output). I support updating things to provide improved functionality, but it should be done properly. - TheDaveRoss17:08, 8 February 2016 (UTC)
I am not saying that modules shouldn't throw errors, I am saying that if a template has been in use for years modifying it in such a way that historical revisions are all broken or worse live usage is broken, then that is a design failure. - TheDaveRoss14:55, 9 February 2016 (UTC)
Re: TheDaveRoss I erroneously added notext=1 to {{inh}} ({{bor}} has notext and this doesn't) and it broke the entire template. In the pre-Lua days then simply the parameter would do nothing and in this specific case it would work perfectly. {{IPA}} has a similar problem. We seem to be getting less good at handling user input errors, not better. Renard Migrant (talk) 15:00, 9 February 2016 (UTC)
deleting pages by bot
Is there a way to delete pages by bot? I ran a bot to create noun and verb forms for Russian lemmas and it created some erroneous forms due to errors in the declension templates on the lemma pages. I've gone through half the created forms and so far identified 14 such lemmas; this amounts to maybe 150 forms, too many to easily do by hand. Benwing2 (talk) 02:46, 8 February 2016 (UTC)
OK, I think I've figured it out. I assume however that I need to use an admin account, not a bot account ... is this correct? Or should I seek to have delete privileges added to my bot account (if there are such things)? Benwing2 (talk) 04:07, 8 February 2016 (UTC)
FYI, if you ever need to delete a lot of pages more quickly than can be done using the normal method, but want slightly more control / opportunity for review before each deletion than you get with a bot, (a) AutoWikiBrowser can delete pages (if you log in with your admin account), and (b) quite a while ago Ruakh wrote some javascript, of which you can find a copy here, which can be modified (change "ri" to whatever you need, and the deletion reason to whatever is appropriate) so that when you land on the "delete page" page associated with entries starting with some string, it prefills the deletion summary and clicks delete; you can use that + Lupin / Navigation popups (which have a 'delete' button) to delete a lot of entries quickly but still "by hand". - -sche(discuss)22:18, 8 February 2016 (UTC)
Thanks. I wish AWB worked better on a Mac. I've gotten it to work (sort of) through Wine, although it's a pain to install and it had some problems, if I remember ... I think it didn't respond properly to keyboard shortcuts. Benwing2 (talk) 01:29, 9 February 2016 (UTC)
I was trying to create a wiktionary entry for "MasculinitySoFragile" and was labeled as "probably spam." I'd like to report this as incorrect. Here is the code below
formatted the wiktionary entry wrong, despite it being a bad fit for inclusion. Thanks!]
deleted entry wikicode
==English==
===Phrase=== {{head|en|phrase}}
# A hashtag-turned-phrase referring to the instability of hypermasculinity and toxic masculinities that often lead men to commit misogynistic harassment and violence against women, particularly when challenged.
===Etymology=== {{head|en|etymology}}
Coined by California-based writer and student Anthony Williams<ref name="will.aj">Anthony Williams, "," "about.me," no date</ref> under the username @anthoknees on Twitter<ref name="ant">@anthoknees, "," "Twitter.com," no date</ref> on September 23, 2015<ref name="anthoknees">Anthony Williams, "," ''anthoknees, please ," 23 September 2015</ref><ref name="independent">Anthony Williams, "," "Independent Voices," 27 September 2015</ref><ref name="the-ipf">Priyanka Mogul, "," "The IPF," 4 October 2015</ref><ref name ="mic">Julie Zeilinger "," "Mic.com," 23 September 2015</ref><ref name="LA-Times">Dexter Thomas, "," "LA Times," 23 Setpember 2015</ref>, the hashtag was first created by @puppydogexpress. <ref name="tweet">@puppydogexpress Twitter.com," 23 September 2015 </ref><ref name ="philosophy">David Michael Newstead "," "The Philosophy of Shaving," 22 January 2016 </ref>.
Williams stated that he had previously used the hashtag on Twitter to express the fragility of masculinity, but after reading a tweet from FeministaJones (@FeministaJones on Twitter) about multiple instances of intimate partner violence, he began using the hashtag again in a long series of tweets. <ref name="anthoknees" />
He writers, "o I went on a long series of tweets about domestic violence, abuse, rape, and other forms of violence under the hashtag #MasculinitySoFragile. I’m not the first to use the hashtag, but I continued a conversation tonight that women–and Black women in particular–have been having for centuries." <ref name="anthoknees" /> Buzzfeed<ref name="buzzfeed"> Luke Bailey, "," "Buzzfeed," 23 September 2015</ref> and other news sources continued to the the hashtag to reference and point out gendered products and toys.<ref name="guardian">Olivia Marks, " Get real: Lammily - the doll with acne and cellulite - now gets her period, too]," "Guardian," 25 September 2015</ref>
Williams continues to write about #MasculinitySoFragile academically<ref name="ASA"> Anthony Williams, "," "American Sociological Asssociation Sex & Gender Newsletter," November 2015</ref>, with a workshop planned in late February at the University of California, Berkeley.<ref name="CRG"> Anthony Williams, "," "University of California, Berkeley Center for Race & Gender" no date</ref>
@Anthoknees Thanks for your post. Regarding the suggested entry, please see Wiktionary:Criteria for inclusion. Has this word been used in durably archived sources (generally meaning published books or Usenet posts) by at least three different people over a period of more than one year? If so, please provide evidence. If not, it does not meet Wiktionary's criteria for inclusion. —Mr. Granger (talk • contribs) 03:03, 9 February 2016 (UTC)
(edit conflict) This is a really bad entry for a number of reasons- so much so that I would delete it on sight if I saw it. First of all, please see our Criteria for inclusion- we never allow entries for something that someone just made up, unless it's clearly in widespread use independent from its creator and is likely to be around after a year. Please also be aware that this is a dictionary, not an encyclopedia, so all the biographical background info and interview material from the creator have to go (the fact that it's basically self-promotion just makes it worse). We strongly discourage links to personal web pages/blogs, not to mention commercial sites. Basically, all that's permissible would be the language header, a very short etymology header & section, the part of speech header followed by the {{head}} template (this is the only place it belongs), followed by a real definition, not a description of the term. Quotes in durably-archived sources showing the term being used are permissible, with the bare minimum of links. See Entry layout for details. By the way, "#" can't be used in an entry name, for technical reasons.
In other words, 90 percent of your text and almost all of the links (which are what triggered the edit filter) are inappropriate for an entry here- this isn't a blog, magazine, encyclopedia or link-farm. You also have a number of formatting problems, typos/misspellings and grammatical errors which would have to be fixed. Chuck Entz (talk) 03:13, 9 February 2016 (UTC)
I doubt that it is a configuration issue. I think the devs intentionally disallowed it, but I agree that there is no reason to prevent anons from being thanked. --WikiTiki8916:13, 9 February 2016 (UTC)
Etymology-only languages are variations on recognized languages. The modules should know that NL. is a variation of la, and link NL. terms to Latin entries. Chuck Entz (talk) 06:50, 11 February 2016 (UTC)
Exactly. If I write {{der|fr|VL.|*foobarius}}, it's interpreted as exactly the same as {{etyl|fr|VL.}}{{m|la|*foobarius}}, so {{der}} knows that the etymology-only language "VL." is to be matched with "la". {{inh}} knows that too. But {{calque}} doesn't. —Aɴɢʀ (talk) 07:31, 11 February 2016 (UTC)
@Angr: Oh, it's the same, because the script cannot find the language for the code "NL.", which makes the value of "source" nil (nil = nothing). --kc_kennylau (talk) 12:33, 11 February 2016 (UTC)
This template was created so that descendants could be shown on different pages without duplication. It does its job well, but a major downside is that we have to create, maintain and watch a separate descendants page. I've been thinking about whether it's feasible to do this without the need for a separate page. Instead, the page for, say, Proto-Indo-European, would transclude the descendants from the Proto-Germanic page. That way, the descendants of each branch can be kept on their respective pages, while also being included on the ancestor page. Is this doable? —CodeCat15:56, 10 February 2016 (UTC)
We frequently need (or ought) to add citations within the descendants tree structure. I have been hesitant in the past to add them to etymtrees. Can this be done safely? —JohnC516:06, 10 February 2016 (UTC)
I've not encountered a problem as of yet. I am just curious about the behavior of a transcluded <ref> tag. —JohnC516:24, 10 February 2016 (UTC)
@CodeCat: I think it is better to put it on a separate page, because the display-text in the PIE page is not exactly same with the database page. Sure, it is still feasible to have different display-text on the same page. I am neutral in this vote. --kc_kennylau (talk) 18:33, 10 February 2016 (UTC) Stroken 18:41, 10 February 2016 (UTC)
What about implementing my proposal? Could you make that work? I'd much rather have descendant content on the same pages as the entries. Etymtree is a pain on the watchlist... —CodeCat03:40, 14 February 2016 (UTC)
The issue I have with it is not the duplication (there is none as far as I can tell), but the need for creating a separate page to list all the descendants on. I would prefer to keep them in the entries. —CodeCat04:05, 14 February 2016 (UTC)
Then why do we have etymtree? The point of it was to show all descendants, even those of sub-branches, without duplicating the information. I think we should not put the descendants on their own page. —CodeCat18:46, 15 February 2016 (UTC)
Sorry about that, looks like a copy/paste error on my part. I went through the other template revisions I made and didn't see any further similar errors, of course that doesn't ensure that there are none. - TheDaveRoss12:35, 12 February 2016 (UTC)
The sound still isn't working for me, even allowing for the usual time delay. The menu comes up when clicked on though. Donnanz (talk) 17:29, 12 February 2016 (UTC)
I'm not very good with abuse filters. My last edit was meant to allow the prefix "doi" in links, which is not a language code but is an inter-project code similar to "wikipedia". You can revert it if you want, but please try to fix the problem I originally intended to fix. —CodeCat17:11, 12 February 2016 (UTC)
@CodeCat: I'm not blaming you, but there has been no hits since 29 October 2015, which is coincidentally the date that you edited the filter. I'm not blaming you. I'm still finding out what caused the filter to be useless. --kc_kennylau (talk) 17:33, 12 February 2016 (UTC)
The ((?!doi)pattern) does negative lookahead, so the {2,3} will not match doi. If that needs to be expanded, the doi can be changed to (?!(doi|w|ws|...) - TheDaveRoss18:35, 12 February 2016 (UTC)
More than half of the Special:Tags had no documentation in the table, so I have written up the ones that I could. This leaves a handful that I don't understand. If they are yours (undocumented abuse filters, etc.) then please update the table with a brief description. Equinox◑16:45, 12 February 2016 (UTC)
Could someone do a list of all the uses of {{a}} outside of pronunciation sections? A couple under ====Usage notes==== will likely be valid, but other than that it's occasionally misused for {{qualifier}} such as {{a|idiomatic}}. Some of the uses in pronunciation sections are technically incorrect too because of things like {{a|rare}} but they're a bit harder to find. Renard Migrant (talk) 17:55, 12 February 2016 (UTC)
Could someone prepare a list of all the occasion where it is easier to type "qualifier" than "a". (I suspect that this might be easy.) DCDuringTALK05:00, 13 February 2016 (UTC)
I think {{i}} is more common than {{q}} as a shortcut for {{qualifier}}, but yes, there are bots that convert both shortcuts to the long form, G-d knows why. —Aɴɢʀ (talk) 13:08, 13 February 2016 (UTC)
The reason why bots should convert to the verbose form is that, unless one is already familiar with all of the "shortcut" templates (which even very high volume editors are not per this discussion) then the resulting wiki markup becomes incomprehensible. There are hundreds of possible templates which {{a}} might point to, laziness costs more time than it saves. {{accent}} would be a much better template name, {{dialect}} (or similar) better still. - TheDaveRoss14:10, 13 February 2016 (UTC)
I have seen bots replace {{i}} with {{qualifier}} but I object to it. There's nothing wrong with renaming {{a}} to {{accent}} and making {{a}} a redirect; but I object to replacing shorter template names with longer ones. It makes life harder for editors, for one thing. It's not clear to me that {{qualifier}} is any more obvious to a neophyte than {{q}}. What I do think is a good idea is to standardize on one name, e.g. replace all {{i}} and {{italbrac}} with {{q}}. Benwing2 (talk) 03:17, 14 February 2016 (UTC)
I thought that we use {{lb}} for that kind of thing. I thought that {{a}} was for "attribute". Can we take a census of the types of uses of {{sense}}, {{label}}({{lb}}), {{a}}, and {{qualifier}}({{i}}, {{q}})? Do we have any single page that compares and contrasts these and, for that matter, {{gloss}} and similar others? DCDuringTALK15:40, 13 February 2016 (UTC)
{{a}} = accent, used to label accents in pronunciation sections, goes before the pronunciation.
{{sense}} = sense, used to label senses in synonym sections, goes before the synonym.
{{lb}} = label, used to attach contexts like "metallurgy" or "physics" or "obsolete" to definitions; potentially adds the page to a category, goes before the definition.
{{gloss}} = gloss, used to gloss a definition by redefining it in different words, goes after the definition.
{{n-g}} = non-gloss definition, similar to a gloss but for non-gloss explanatory text that instead of a definition, often to explain the usage of grammatical particles.
{{i}} or {{q}} = miscellaneous italicized and parenthesized text.
I appreciate the effort, but in what findable, permanent location will it reside? What path of links would a user follow to get to it? [[User: DCDuring
What do you think such a page should be named? IMO, each such template's documentation should point to the page describing them. Benwing2 (talk) 20:24, 15 February 2016 (UTC)
I think there was a problem somewhere else that got fixed. A null edit cleared it up (as far as I can tell). I always try a null edit before I report things like this. Chuck Entz (talk) 05:38, 13 February 2016 (UTC)
Mglovesfunbot is renaming {{i}}, {{q}}, {{qual}} -> {{qualifier}}. I don't like this much; I think rather they should all be renamed to {{q}}. Now, if Mglovesfunbot can do this, what prevents me from running my own bot to rename them the way I like? And wouldn't this lead to a bot war? So I suggest that Mglovesfunbot shouldn't do this any more, and we should vote on which form to prefer. Benwing2 (talk) 17:15, 14 February 2016 (UTC)
Let Mglovesfunbot stop doing it. For one thing, the bot operator did not demonstrate consensus. For another thing, a recent vote for switching to certain short template names suggest a general preference for short names so the bot should not be switching things in the opposite direction. --Dan Polansky (talk) 20:28, 14 February 2016 (UTC)
I agree totally. It's still happening by the way, I had a load of these edits pop up on my watchlist the other day. DonnanZ (talk) 20:58, 3 November 2016 (UTC)
@Renard Migrant Please stop doing these substitutions now. Bots are supposed to be making uncontroversial changes but this change is clearly controversial: I, Donnanz and Dan Polansky all object. You really should have stopped months ago, when this issue was first brought up. (If you don't stop, I may write a bot to undo these changes.) Benwing (talk) 07:26, 5 November 2016 (UTC)
It was uncontroversial at the time I started. Note that your bot would also be controversial because I would object to it, so that would be a violation of WT:BOT. Are you in favour of violating WT:BOT or against it? Seems you're against me doing it, but in favour of doing it yourself. Renard Migrant (talk) 11:16, 5 November 2016 (UTC)
You can be damn sure the next time your bot does something I will object to it. WT:BOT says 'I will make sure that the task is so innocuous that no one could possibly object.' Therefore any objection is enough to stop the bot. It doesn't matter why there is an objection. Renard Migrant (talk) 11:19, 5 November 2016 (UTC)
Cut the crap; this is a personal attack me pure and simple and has nothing to do with changing a redirect to a full form. If that were the case I'd have been blocked for about a million years already. Clearly none of you are moronic enough to think that somehow using the full name harms Wiktionary, so this is about me. So get on with it; what's the real problem here? Stop being cowards and lying about your true intentions. Renard Migrant (talk) 11:31, 5 November 2016 (UTC)
When I saw all these bot edits I was beginning to wonder whether {{q}} was deprecated, but I have now learnt that this is far from the case. No personal attack on RM intended though. I just want these edits to cease. DonnanZ (talk) 12:22, 5 November 2016 (UTC)
Type, scripts and family data is now optional in language and family data modules
Just a small heads up that the modules that handle the data now supply a default value for these, so you no longer need to put in "type = regular", "scripts = {"None"}" or "family = qfa-und" anymore. Instead, you only specify a value if it's a real value, rather than an empty placeholder. The access modules (Module:languages, Module:families) fill these default values in automatically for now, so code that uses these works like it did before. —CodeCat00:13, 15 February 2016 (UTC)
Yes, but it's fixed. There are a handful of modules that process lots of data at once, and so they circumvent the normal access modules for speed. —CodeCat00:44, 15 February 2016 (UTC)
For me, the entry for "Thai" in that table displays a flag where the code should be, the code where the name should be, etc, with all the fields shifted to the right by one, resulting in an extra column in the table that only has a value ("9") on that one row. (Perhaps this bug is connected to the feature that puts flags next to language headers.) - -sche(discuss)01:22, 15 February 2016 (UTC)
User:Hippietrail has added {{attention|th|Which classifiers, counters, measure words are used with this noun?}} to พิซซ่า(pít-sâa), which is a missing feature, not a problem with the entry.
IMO, {{attention}} shouldn't be added to entries requesting additional info or features but to entries having some problems.
Could someone please add a cls= parameter to {{th-noun}}, similar to {{vi-noun}} or {{zh-noun}}?
It seems to be OK for Chrome and Microsoft Edge, but now it's even worse for Firefox: instead of being half-hidden, the IPA is fully obscured (the audio box covers the entire. darned. line. wtf.). I don't know whether to cry or laugh —suzukaze (t・c) 07:04, 16 February 2016 (UTC)
Formatting issues with "Template:audio"
Did something recently happen to {{audio}}? It used to be grey, but suddenly it's gone mostly black, which makes it difficult to see the duration of the recording and the "Menu" link. — SMUconlaw (talk) 17:19, 15 February 2016 (UTC)
Replacement of uses of "Template:reference-book", et al.
Now that the {{cite-}} and {{quote-}} templates have been sorted out, would it be possible for someone to run a bot and do the following?
Replace uses of {{reference-book}} with either {{cite-book}} (if it is used within <ref> tags or in ==References== sections) or {{quote-book}} (if it is used elsewhere, mostly to provide quotations for definitions of lemmas). The following parameters may need changing:
If |origyear= and |year= are used together, |origyear= → |year= and |year= → |year_published=.
Replace uses of {{reference-journal}} (a redirect) with either {{cite-journal}} (if it is used within <ref> tags or in ==References== sections) or {{quote-journal}} (if it is used elsewhere).
Replace uses of {{reference-news}} (a redirect) with either {{cite-journal}} (if it is used within <ref> tags or in ==References== sections) or {{quote-journal}} (if it is used elsewhere).
Can you cite some examples that use "|prefix=#" and "|prefix=#*"? And some examples of {{reference-book}} inside of ==Reference== sections, some inside of <ref>...</ref> tags, and some that are neither? This will help with testing. Benwing2 (talk) 20:26, 15 February 2016 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Sure, here you go:
It's inherent in the name: Usenet. But in all seriousness, I can't tell you if people still use it, but we certainly still quote it. --WikiTiki8922:43, 16 February 2016 (UTC)
There are many cases where origdate= and origmonth= are present, but blank. In those cases, I just remove them, is this safe? Sometimes e.g. origmonth= is present and blank, and month= is present and non-blank.
What about templates in pages outside of the main namespace? I think we should fix 'Citations:', 'Appendix:', 'Reconstruction:' and certain others, but we need to leave alone 'Template:', and I'm not sure about 'User:', 'Talk:', 'Template talk:', 'User talk:', 'Appendix talk:', 'Category talk:', 'Wiktionary:', 'Transwiki:', etc.
Hmmm. I agree you should fix "Citations:", "Appendix:" and "Reconstruction:", and would also suggest "Talk:", "Appendix talk:", "Category talk:", "Template talk:", "User talk:", "Wiktionary:" and "Transwiki:". It's probably best to leave the "Template:" and "User:" pages alone first – I'll need to see how the deprecated templates are being used there. — SMUconlaw (talk) 07:08, 17 February 2016 (UTC)
If id= is present but doesn't begin with 'ISBN ', currently I just leave it alone. Should I go ahead and rename to isbn= without stripping anything? Some examples:
id=4-00-301001-9
id=SBN 416 27990 2
id=ISSN 0716730510
id={{ISSN|00062510}}
id=10-{{ISBN|4-000-60067-2}} (should I strip '10-ISBN ' in this case?)
id=ISBN-13 978-0-00-722391-6 (should I strip 'ISBN-13 ' in this case?)
I suggest dealing with these situations as follows:
id=4-00-301001-9 → isbn=4-00-301001-9
id=SBN 416 27990 2 → isbn=0-416-27990-2 (the SBN was the predecessor of the ISBN, and an SBN can be converted to an ISBN by adding a "0" in front)
id=ISSN 0716730510 → issn=0716730510 (I suspect, though, that this particular example is an error as ISSNs only have eight digits. It's probably supposed to be an ISBN.)
id={{ISSN|00062510}} → issn=0006-2510
id=10-{{ISBN|4-000-60067-2}} (should I strip '10-ISBN ' in this case?) → yes, convert this to isbn=4-000-60067-2
id=ISBN-13 978-0-00-722391-6 (should I strip 'ISBN-13 ' in this case?) → yes, convert this to isbn=978-0-00-722391-6
Page 65 lake: WARNING: Would replace id= -> isbn= but id=SBN 416 27990 2\n doesn't begin with 'ISBN'
As mentioned above, "id=SBN 416 27990 2" can be changed to "isbn=0-416-27990-2" (i.e., add a "0" in front of the SBN). If it isn't feasible to add the hyphens, leave them as spaces. — SMUconlaw (talk) 15:26, 18 February 2016 (UTC)
Page 263 secondary structure: WARNING: Would replace id= -> isbn= but id=ISSN 0716730510\n doesn't begin with 'ISBN '
Page 919 Talk:lathe: WARNING: Would replace id= -> isbn= but id= Reprinted by Lindsay Publications, Inc., Bradley, IL, USA. →ISBN (paper); →ISBN (cloth) doesn't begin with 'ISBN'
Page 919 Talk:lathe: WARNING: Would replace id= -> isbn= but id= (Available as a reprint from Lindsay Publications in paperback →ISBN and cloth →ISBN doesn't begin with 'ISBN '
@Smuconlaw I'm doing another bot run now so you might have to search down a bit to find the start of the relevant changes to check (choose "500" at the bottom and search for "Xenu", the most recent entry of the relevant changes). Benwing2 (talk) 01:41, 18 February 2016 (UTC)
Had a random look at the some of the changes, and here are some thoughts:
In Citations:frozen cow juice, this edit ended up with "##*" instead of "#* because there was already a "#" there. Similarly, if there was already an "*" which leads to "*#*", that would need to be fixed.
In Citations:LTRFTW and other pages which originally used {{cite-usenet}}, |text= needs to be changed to |passage=.
I see some occurrences like this: "|pages=p. 88" (haartätäkki). If there is a "p.", can this be changed to "|page=88"? Similarly, if there is a "pp." this should be changed to "|pages=88".
Also, in abirritant and ability, an editor has typed something like "pages=6". Is it possible to change this to "page=6" if there is only a single number, and to "pages=6–10" if there are two numbers separated by a hyphen or en dash?
@Smuconlaw Rather than add special-case code for SBN and ISSN, these should be handled manually; the above cases are the only ones. Also, it looks like there are other parameters that need to be changed, e.g. looking at the definition of {{cite-usenet}}, it has params |group=, |googleid=, |link= that don't exist in {{quote-newsgroup}}. Similarly, {{quote-usenet}} has numbered params 2,3,4,5,6. Could you go through the various templates and make a full list? Also, why are the defns of {{cite-usenet}} and {{quote-usenet}} defined in terms of {{quote-web}} rather than {{quote-newsgroup}}? Benwing2 (talk) 18:51, 18 February 2016 (UTC)
Oops, missed it. I'll get to this soon. Do any of the other templates that you want renamed have parameters that need changing? I wouldn't be surprised if they did. Benwing2 (talk) 03:29, 8 March 2016 (UTC)
At the moment, I don't think so. If you can work on the changes I mentioned in my 27 February post and my original 15 February post, that would be great. Thanks. — SMUconlaw (talk) 22:14, 10 March 2016 (UTC)
@Smuconlaw I'm working on this now. I think instead of having me set |url=http://groups.google.com/group/ABC/browse_thread/thread/XYZ you should support googleid= directly. In general you don't want to require people to insert lots of boilerplate like this, and furthermore the URL used by google could potentially change. Benwing2 (talk) 22:24, 15 March 2016 (UTC)
OK, I did the whole run. I had to fix up some templates because of use e.g. of text= when only passage= was accepted, in places where you didn't tell me to correct text -> passage. I'm sure there are other such issues; be alert for them. In general it sounds like you might need to be a bit more careful in the future when converting templates like this to make sure everything gets properly converted or supported. Benwing2 (talk) 06:21, 17 March 2016 (UTC)
It's been doing it for about a week. The errors start in the middle of the French section, but I doubt there's any significance to that. I've been comparing the execution times of the different language sections, but I don't see anything obvious:
Execution times for all 89 language sections
Num
Language
Seconds
1
Translingual
0.194
2
English
1.002
3
Abau
0.032
4
Afar
0.040
5
Albanian
0.119
6
Ama
0.047
7
Aragonese
0.045
8
Asturian
0.051
9
Azeri
0.032
10
Bavarian
0.039
11
Catalan
0.118
12
Chuukese
0.158
13
Czech
0.036
14
Dalmatian
0.043
15
Danish
0.114
16
Dutch
0.209
17
Egyptian
0.034
18
Esperanto
0.045
19
Fala
0.074
20
Faroese
0.107
21
Finnish
0.045
22
French
0.136
23
Fula
0.058
24
Galician
0.213
25
German
0.031
26
Gilbertese
0.119
27
Greenlandic
0.035
28
Haitian Creole
0.041
29
Hawaiian
0.045
30
Hungarian
0.036
31
Ido
0.148
32
Indo-Portuguese
0.085
33
Interlingua
0.055
34
Irish
0.214
35
Istriot
0.035
36
Italian
0.074
37
Japanese
0.041
38
Krisa
0.030
39
Ladin
0.029
40
Latgalian
0.031
41
Latin
0.201
42
Latvian
0.065
43
Livonian
0.136
44
Lower Sorbian
0.029
45
Malay
0.026
46
Mandarin
0.125
47
Mandinka
0.066
48
Maori
0.022
49
Middle French
0.059
50
Middle Welsh
0.108
51
Min Nan
0.055
52
Mopan Maya
0.031
53
Nauruan
0.030
54
Navajo
0.068
55
Neapolitan
0.048
56
Norman
0.059
57
Norwegian Bokmål
0.067
58
Norwegian Nynorsk
0.039
59
Novial
0.031
60
Old Danish
0.129
61
Old English
0.097
62
Old French
0.063
63
Old Irish
0.211
64
Old Portuguese
0.078
65
Polish
0.040
66
Portuguese
0.792
67
Rapa Nui
0.027
68
Romanian
0.084
69
Scots
0.068
70
Scottish Gaelic
0.079
71
Serbo-Croatian
0.150
72
Skolt Sami
0.214
73
Slovak
0.271
74
Slovene
0.045
75
Spanish
0.076
76
Sranan Tongo
0.033
77
Swahili
0.064
78
Swedish
0.043
79
Tagalog
0.035
80
Tarantino
0.021
81
Tok Pisin
0.028
82
Turkish
0.044
83
Turkmen
0.148
84
Upper Sorbian
0.030
85
Vietnamese
0.187
86
Walloon
0.034
87
Welsh
0.090
89
Zhuang
0.032
Total
8.554 (Limit 10.000)
Language sections with above-average execution times
Num
Language
Seconds
2
English
1.002
66
Portuguese
0.792
73
Slovak
0.271
34
Irish
0.214
72
Skolt Sami
0.214
24
Galician
0.213
63
Old Irish
0.211
16
Dutch
0.209
41
Latin
0.201
1
Translingual
0.194
85
Vietnamese
0.187
12
Chuukese
0.158
71
Serbo-Croatian
0.150
31
Ido
0.148
83
Turkmen
0.148
22
French
0.136
43
Livonian
0.136
60
Old Danish
0.129
46
Mandarin
0.125
5
Albanian
0.119
26
Gilbertese
0.119
11
Catalan
0.118
15
Danish
0.114
50
Middle Welsh
0.108
20
Faroese
0.107
61
Old English
0.097
I would expect English to be highest in execution time, but Portuguese was a surprise. It does seem to be just a matter of lots of content, rather than a technical problem, though.
I would guess that something introduced by the recent edits to the modules has slowed things down enough in each link so that the total execution time goes over the limit (10.027/10.000 seconds). Chuck Entz (talk) 08:39, 16 February 2016 (UTC)
You are probably right. In the page source we read
You should probably do this checking using a bot, either live or on the dump, and then create a user page containing all the errors. Benwing2 (talk) 17:26, 16 February 2016 (UTC)
If they ever complete Phab:T114072, then we will get not only the ability to auto-detect the language in many templates but also set up this sort of checking. But until that point, I think bots will be necessary. —JohnC517:37, 16 February 2016 (UTC)
Kenny was the author, AFAICT. I don't trust myself with any technical task, nor should others trust me. So, if Kenny hasn't and you trust yourself, then go ahead. DCDuringTALK19:43, 16 February 2016 (UTC)
That repair ensures that the checkusage function (the culprit here) only runs in the mainspace. This does not prevent the checkusage function from continuing to be extremely expensive. —JohnC520:01, 16 February 2016 (UTC)
Other pages are not affected because ] is a huge page. Someone probably slowed down a widely transcluded template by a little, which caused huge problems at ]. --WikiTiki8923:02, 16 February 2016 (UTC)
I've removed the check, fixing the issue. And yes, if we want to do this kind of checking, it should be done by bot, not in modules. I left the function there for reference, but it should not be used in actual invocations of {{a}}. --WikiTiki8923:07, 16 February 2016 (UTC)
The water entry is actually not that big (11 language sections)- it just has a planet-sized translation section imbedded in it. Changing the subject: let's not overlook Module:labels, which has similar logic added by Kenny at about the same time. It's not nearly as much of a time-hog as Module:a, but if you look at the next template in the list above, Template:l-self uses less execution time than Template:lb in spite of being used 22 times as much. Chuck Entz (talk) 03:31, 17 February 2016 (UTC)
Do we have lists of the entries that are the top users of each template or use the largest number of templates, the top 10 entries in size, the top 10 L2 sections? Some such lists seem like they would be useful for testing performance issues. Such a set of lists could be taken from the dumps, which include a 250Mb file of "Wiki template inclusion link records". Someone more knowledgeable than I could probably think of more useful lists, also.
I just noticed the logic to detect wrong placement in Module:labels: it's horribly inefficient and definitely the wrong place to perform these kind of checks. As a general rule, modules should only work on the data which is passed to them via parameters, not by fetching the whole content of the surrounding page. It's very brittle and likely to blow up any time. Can somebody please revert it? Jberkel (talk) 13:50, 24 February 2016 (UTC)
I agree that modules shouldn't parse the entire page in which they are transcluded, especially one such as this which is used all over the place. The section in question doesn't provide and front-end functionality (I think) it just categorizes errors. @Kc_kennylau can we just comment the section out for now? - TheDaveRoss14:20, 24 February 2016 (UTC)
I was curious how many {{label}}s are actually incorrectly tagged and wrote a script to perform an offline analysis. The answer: not that many. Surprisingly there are only around 500 instances which means I could have overlooked something. Anyway, feel free to help clean up entries in "your" language. – Jberkel (talk) 02:36, 26 February 2016 (UTC)
So, I know that water wasn't malfunctioning before and that this may not be {{a}}'s fault, but water is now running out of execution time near the end. —JohnC522:16, 26 February 2016 (UTC)
You'll notice that Template:label is 4th on that list, in spite of only 25 calls to t-simple's 1539 calls. Let's take the known outrageously inefficient code out of there before we try to squeeze anything more out of t-simple. Also, this is an intermittent problem: after a null edit, it was back to normal, with 5.4 seconds total script execution time on the preview before I saved. When I viewed the source, it was back up to 8.2 seconds:
I think he means that the second translation table (last part of the digest system) under Etymology 1 (punctuation) belongs under a different Etymology section. DCDuringTALK23:17, 16 February 2016 (UTC)
Yes, I noticed that. Had a quick look yesterday, but can't figure out what's wrong. Also, I don't know if it was already showing errors before any changes were made. Let me know if you can figure out what's wrong. — SMUconlaw (talk) 13:42, 17 February 2016 (UTC)
OK, I figured out what happened. These pages use {{reference-journal}} which has now been renamed {{quote-journal/source}}, and there was a typo in the |start_year= parameter. I think the problem is now solved (you may need to do a page purge to see the change take effect). — SMUconlaw (talk) 14:14, 17 February 2016 (UTC)
Thank you! Glad to see I pinged the right person. I've done null edits on all the mainspace uses, which did clear them. There are still 569 pages left, but I don't have the patience, let alone the time, to deal with those. Chuck Entz (talk) 15:04, 17 February 2016 (UTC)
Missing deletion reason
In the deletion reasons list, what happened to "intimidating behaviour/harassment"? I saw no vote about its removal. Equinox◑22:58, 18 February 2016 (UTC)
I tried to add the "Alternative forms" section to as-yet-unknown and got the warning that the change was auto-identified as harmful and disallowed. This is some false-positive somewhere that needs to be corrected. 73.71.174.7500:26, 20 February 2016 (UTC)
See for example armee which has the plurals armees but the automatic module-generated plural is armes. I assume it's just a pure error and not intentional. Also specifying manually the plurals armees adds it to Category:Old French irregular nouns which of course, couldn't be further from the truth, it's just a case of manually fixing a module error. Hopefully that one's fixed, can anyone find and fix or find and tell me where the -ees to -es error is? Renard Migrant (talk) 18:08, 21 February 2016 (UTC)
Lü language in Lanna (Tai Tham) script not using correct font in translation tables
I have begun investigating support for the traditional script for the Lü language of Yunnan, China. ISO language code 'khb'
The modern script, New Tai Lue (ISO code 'TALU') is working fine if you have a font installed. The CSS in Medaiwiki:Common.css is set to use any of several known fonts and it works with both {{l}} in the various links and {{t}} in translation tables.
I've just added some known working fonts for the traditional script, Lanna aka Tai Tham (ISO code 'LANA'). This seems to work fine for {{l}} links but is not working for {{t}} translation entries.
See the {{a}} translation entry working for 'TALU' but broken for 'LANA': and#Translations
For some reason, translations with language set to 'khb' and script set to 'LANA' in the resultant HTML end up with a CSS class 'None' rather than the expected 'Lana'.
I don't know the full pipeline of templates, modules, CSS files etc that might play a part. Can anyone help get this working? — hippietrail (talk) 10:12, 23 February 2016 (UTC)
This is a poorly designed template because it uses the html tags for something they aren't designed for. There is only a fixed list of html tags that wiki officially supports. HTML in wikitext, and there is also the detailed official documentation somewhere specifying which tags are allowed, and which ones are considered self-closed and which ones aren't. 73.71.174.7522:20, 23 February 2016 (UTC)
Before you go calling Kenny's template poorly designed, I'd point out that the angle brackets are not html tags at all but an input syntax used internally by the module. They are not and would never be rendered as html tags by the html parser. —JohnC523:38, 23 February 2016 (UTC)
They are present in the wiki document, therefore such syntax implicitly exploits the lack of syntax checking in the wiki parser, which is never a good thing (to exploit some obscure and undocumented things). If the parser checked the syntax better, this would have been a syntax error that it really is. 73.71.174.7502:40, 24 February 2016 (UTC)
I don't see how it's "exploiting" anything. The angle brackets are part of the input to the template, and they get processed before the final page is rendered. They are not "syntax" targeting the "wiki parser". Equinox◑09:15, 24 February 2016 (UTC)
Looking for a template to say "See X for related terms"
Concerning the foreign WOTD проплывать: This verb is composed of prefix про- plus combining form -плывать; there are many other related verbs with the same comining form and other prefixes, and many more verbs related to the corresponding perfective verb проплыть. All are listed under плыть. I'd like to put an entry under "====Related terms====" that says essentially
I'd prefer to direct users to the entry where the content is, rather than shifting the content onto a 'subpage' which is from a technical standpoint still a page in the main namespace (just like s/he is not a subpage of s) that will show up in search. I see "seefoo" (untemplatized) a lot. We could create a template. (Maybe even repurpose {{see}}? Or use {{vide}}?) - -sche(discuss)09:03, 25 February 2016 (UTC)
Old Czech missing?
I'm surprised that there's apparently no language code for Old Czech. There's Old Polish, zlw-opl, which suggests that Old Czech should be zlw-ocs. Can someone create this? Benwing2 (talk) 00:07, 25 February 2016 (UTC)
Thanks, this has always bothered me. Although I had assumed there was a good reason for its absence, but I have learned not to assume such things anymore. --WikiTiki8916:08, 26 February 2016 (UTC)
And why does the category title say "on", and the "id=" parameter say "on", but the automated transliteration say "...the prefix ան- (an-)."? - -sche(discuss)17:49, 25 February 2016 (UTC)
What appears in the category name is the id, it's used to disambiguate the category when there are multiple homonymous affixes. So it's not a transliteration. —CodeCat18:06, 25 February 2016 (UTC)
Another useful feature would be if the category description "Old Armenian words beginning with the prefix {{m|xcl|ան-}}" generated by {{prefixcat}} would automatically be "Old Armenian words beginning with the prefix {{m|xcl|ան-|id=on}}". --Vahag (talk) 19:05, 25 February 2016 (UTC)
Hi. I was just congratulated on performing my 100th edit. That's pretty lame, IMHO. Do we get new congratulations on 1000th edits, millionth, etc. ? I suppose I could avoid it but changing usernames every 99 edits...--Sit comfy (talk) 08:42, 26 February 2016 (UTC)
Was it a "Thanks" perhaps? I see you received one of those, they are manually done by any user who feels like saying thanks to you for something you did. If you don't want to see them you can turn off notifications for "thanks" in your preferences. I am not sure that you can prevent them from being sent to you entirely. - TheDaveRoss12:05, 26 February 2016 (UTC)
I think it's an automatic notification by the system. I got something similar after 10 edits while fooling around on the Test Wikipedia. —suzukaze (t・c) 12:15, 26 February 2016 (UTC)
I think that MW wants to make wiki editing less hostile for newbies. Because they can't change human behavior, they are trying to use the software in support of the objective. DCDuringTALK18:16, 26 February 2016 (UTC)
This template was made to autodetect the type of morpheme based on where hyphens are placed. A hyphen at the start makes it a suffix, at the end makes it a prefix, on both ends makes it an interfix, and no hyphens means a regular word. This works well enough in practice that several editors now use it by default. But it has some limitations: not all words beginning or ending with hyphens are prefixes and suffixes. Proto-Indo-European roots, for example, are not prefixes but should be treated as regular words. Some PIE suffixes like *-éye- "look" like interfixes because they have a hyphen at both ends, but the hyphen on the right is really a stem termination. The Finnic languages also have a few cases where prefixes are used as roots for word formation. For example, Veps edeta uses ezi- as the root, and adds a suffix to it. Using {{affix}} would not work here, as it would consider ezi- a prefix when it's not in this case.
I would like to know what others think about this. How could we improve the template so that it allows it to be used in these cases as well? I can think of two possible solutions myself:
Use another mark instead of - to indicate a hyphen that is not indicative of morpheme status. We could use ~ or -- for example: {{affix|vep|ezi--|-eta|id2=neb}} in the Veps example above. The template would automatically convert it to a proper hyphen before displaying and linking.
Use a parameter such as affixtypeN= to override the automatic detection. The Veps example then might become {{affix|vep|ezi-|affixtype1=-|-eta|id2=neb}}, with - indicating that it's not an affix.
Yes. My proposals aren't exhaustive though, I don't think my suggestions are all that good and I'm asking for better ideas if anyone has any. —CodeCat20:54, 26 February 2016 (UTC)
All the hyphens, minus signs, and dashes look too similar, there are too many of them, and only one is easily available on most keyboards. It's just too easy to use the wrong one and wonder why certain entries aren't working right with the templates.Chuck Entz (talk) 21:48, 26 February 2016 (UTC)
You could put a backslash before the hyphen to quote it, Unix-style -- or put the whole morpheme in quotes, which might be the best solution. Benwing2 (talk) 00:46, 27 February 2016 (UTC)
I like the idea of using a backslash. It's not a newly invented syntax but re-use of what's already commonly used and therefore more likely to be understood intuitively. It's also very unlikely to appear legitimately in any affixes. —CodeCat01:46, 27 February 2016 (UTC)
Do exclamation marks cause problems in links?
I have been trying to link dag and herlig to the Bokmål phrase for en herlig dag!, but it doesn't work. Is the exclamation mark the problem here? I have revised the phrase entry, which links OK to herlig and dag, but not the other way round. Donnanz (talk) 11:57, 27 February 2016 (UTC)
So you redirected the page (minus !) and restored the header. I hope I don't come across too many of those. Thanks a lot! Donnanz (talk) 12:45, 27 February 2016 (UTC)
Automatic linking of Gothic transliterations
There seems to have been a recent change to something with the result that when Gothic words are enclosed by {{l}}, the automatically generated transliteration is now automatically also linked. In other words {{l|got|𐍈𐌰𐍃}} now results in 𐍈𐌰𐍃(ƕas) with the "ƕas" as a blue link, instead of as unlinked black text, as it used to be. This is a good thing, since we have entries for all attested Gothic words in their romanized forms, so why not link to them. However, the link is also there even when the Gothic word's own link is overridden by being put in position 3: thus {{l|got||𐍈𐌰𐍃}} results in 𐍈𐌰𐍃(ƕas) with the "ƕas" as a blue link, even though "𐍈𐌰𐍃" itself does not have a link. Could this be changed, so that the romanization is linked only if the native script version is also linked? The reason is that I use {{l}} when providing quotations, putting the Gothic text in position 3 since we don't want a link to a whole sentence, but then the transliteration of the entire quotation is rendered as a (red) link: see for example the quotations under the definition at 𐌰𐍆𐌼𐌰𐍂𐌶𐌾𐌰𐌽. —Aɴɢʀ (talk) 18:21, 27 February 2016 (UTC)
{{ux}} is for usage examples, not quotations, isn't it? And anyway, 𐌰𐍆𐌼𐌰𐍂𐌶𐌾𐌰𐌽 isn't the only one: I've added quotations to a whole slew of Gothic words using {{l|got||...}}. —Aɴɢʀ (talk) 18:36, 27 February 2016 (UTC)
At least in Latin-alphabet languages, they're formatted differently. Usage examples are italicized, quotations aren't. —Aɴɢʀ (talk) 18:55, 27 February 2016 (UTC)
I agree. I've used a bot to rewrite cases where {{l}} is being used for quotations to use {{ux}} (or {{ru-ux}}, which probably should have its special features merged into {{ux}}). I think the docs saying that {{ux}} shouldn't be used for quotations should be changed. Benwing2 (talk) 21:25, 27 February 2016 (UTC)
Even if I stop using {{l}} for quotations (and I've been using it for quotations in all languages other than English for quite some time now), I still feel that if a term is put in pos.3 of {{l}} in order to override the link, then the link to the romanization ought to be overridden as well. —Aɴɢʀ (talk) 22:22, 27 February 2016 (UTC)
I agree. For example, someone might want to mention (and correctly tag, etc) a hypothesized Gothic word in an etymology, for example (citing some scholar who suggests the term under discussion is from that Gothic word). - -sche(discuss)22:27, 27 February 2016 (UTC)
Why is this happening, esp. as there is no consensus to do this? These two are synonyms, what is the point of renaming to a longer name that adds nothing? Benwing2 (talk) 21:59, 27 February 2016 (UTC)
Presumably it's preparation for using {{quote}} for non-block-quote quotations, as a parallel to {{ux}}. It is unintuitive that "quote" currently formats things very differently from all the templates that begin with "quote" ("quote-book", etc). However, there should have been some notice and discussion about that. (Tangential: I find it unhelpful that both {{q}} and {{Q}} exist and do very different things; our templates are usually only case-sensitive in terms of whether or not they exist, and not in terms of what they do.) - -sche(discuss)22:11, 27 February 2016 (UTC)
I did see your WT:RFM proposal but (a) it doesn't mention renaming quote -> blockquote, and (b) IMO you should wait for the proposal to be discussed before going ahead with a rename like this. Bot changes are supposed to be uncontroversial. Benwing2 (talk) 22:29, 27 February 2016 (UTC)
It was uncontroversial before anyone complained. In any case, I didn't move {{quote}}, Dixtosa did. I just edited out the redirects. —CodeCat22:35, 27 February 2016 (UTC)