Wealth Maker: Wiktionary - Recent changes [en]: Wiktionary:Grease pit/2013/June

Wiktionary - Recent changes [en]

Track the most recent changes to the wiki in this feed. // via fulltextrssfeed.com

Wiktionary:Grease pit/2013/June

Jun 27th 2013, 00:55

Revision as of 00:31, 27 June 2013 (edit)		Latest revision as of 00:55, 27 June 2013 (edit) (undo) CodeCat (Talk \| contribs)
Line 392:		Line 392:
	: The problem with apostrophes is sort of a known problem. I don't remember how to fix it, I think Ruakh does. The problem with [[avant-coureur]] is because {{temp\|fr-noun}} is badly coded. It uses {{{head}}} as the base form for the plural, which does not work when it is overridden to provide links. {{User:CodeCat/signature}} 00:18, 27 June 2013 (UTC)		: The problem with apostrophes is sort of a known problem. I don't remember how to fix it, I think Ruakh does. The problem with [[avant-coureur]] is because {{temp\|fr-noun}} is badly coded. It uses {{{head}}} as the base form for the plural, which does not work when it is overridden to provide links. {{User:CodeCat/signature}} 00:18, 27 June 2013 (UTC)
	:: Oh, is it related/similar to the problem with asterisks? If so, perhaps it can be fixed the way [[[[nix]]]] was fixed. Incidentally, AFAICT all [//en.wiktionary.org/w/index.php?title=nix&diff=next&oldid=21066179 this edit] to *nix did was remove the (proper) bolding from the plural forms...? [[User:-sche\|- -sche]] [[User talk:-sche\|(discuss)]] 00:31, 27 June 2013 (UTC)		:: Oh, is it related/similar to the problem with asterisks? If so, perhaps it can be fixed the way [[[[nix]]]] was fixed. Incidentally, AFAICT all [//en.wiktionary.org/w/index.php?title=nix&diff=next&oldid=21066179 this edit] to *nix did was remove the (proper) bolding from the plural forms...? [[User:-sche\|- -sche]] [[User talk:-sche\|(discuss)]] 00:31, 27 June 2013 (UTC)
		+	::: In that particular case I wonder why the bolding is not provided by the template, like it should. Removing it from the entry seems sensible. {{User:CodeCat/signature}} 00:55, 27 June 2013 (UTC)

Latest revision as of 00:55, 27 June 2013

One-click patrolling gone away[edit]

For a couple of days now, the ability to patrol an edit with a single click has gone away. I can't remember who created the system. Any ideas? SemperBlotto (talk) 06:58, 2 June 2013 (UTC)

Ruakh I think. Mglovesfun (talk) 08:57, 2 June 2013 (UTC)

Yeah, Ruakh. The script in question is [[MediaWiki:Gadget-PatrollingEnhancements.js]], I think. I assume an update to the MediaWiki software is to blame. - -sche (discuss) 17:42, 2 June 2013 (UTC)

Indeed. The problem is that unpatrolled "diff" links in the UI no longer include the recent-changes ID (&rcid=...), which the gadget needs in order to mark the edit as patrolled (since that's how the API identifies the edit). The good news is, I added support a long time ago for Special:Contributions, which never included the recent-changes ID in the "diff" links, so that support should be mostly transferable to other pages. I'll give it a shot . . . —Ruakh_TALK 18:13, 2 June 2013 (UTC)

Fixed, I think, but it won't surprise me if there are some cases that used to work and no longer do, or that used to work perfectly and now work less-than-perfectly. If you encounter any, please let me know. —Ruakh_TALK 04:11, 3 June 2013 (UTC)

Oh, one harmed case is Special:Watchlist. The API's list=recentchanges feature doesn't let you filter by whether a page is watched, and its list=watchlist feature doesn't offer a way to retrieve the RCID, so there doesn't seem to be a good way to handle it. This is pretty unfortunate, IMHO, since I think the watchlist is a good way to nudge admins to do a little bit of "easy" patrolling. I'll have to think about this . . . —Ruakh_TALK 04:33, 3 June 2013 (UTC)

Still not working for me. Is there anything I have to do? (I use monobook, with no customization - but "patrolling enhancements" ticked) SemperBlotto (talk) 07:21, 3 June 2013 (UTC)

Ugh, sorry, I made another change after commenting above, and apparently I failed to re-test afterward. It should be good now. —Ruakh_TALK 14:11, 3 June 2013 (UTC)

Thanks. Works a treat now. SemperBlotto (talk) 14:12, 3 June 2013 (UTC)

Missing toolbox in IP contrib pages[edit]

I seem to no longer have that little toolbox on IP contrib pages :/ Y'know the one with links for Geolocate and all that. User: PalkiaX50 ^{talk to meh} 18:17, 2 June 2013 (UTC)

I still have it. —An gr 06:42, 3 June 2013 (UTC)

I can't add a Galician translation.[edit]

I could put in Portugese mercado negro as a translation for black market if I wanted, but for some magical reason I can't use the same box to put in Galician mercado negro. Explain this shit. --Æ&Œ (talk) 03:02, 4 June 2013 (UTC)

Having a {{trreq}} preceding or following the position of where the translation would be placed causes this bug. — Ungoliant ^(Falai) 03:06, 4 June 2013 (UTC)

I believe MewBot has fixed a load of these; could someone update it so I don't end up trying to fix a load of entries that have already been fixed. Mglovesfun (talk) 10:43, 7 June 2013 (UTC)

MewBot is still running and will be for about a week I predict, there are a lot of entries to be done still (currently 120 thousand). However, I told it to add Category:Context label misused to some of the entries (particularly Romance verbs) so they can still be found. —CodeCa t 11:59, 7 June 2013 (UTC)

Once the bot finishes putting {{context}} in front of all context labels, it should be possible to make a list of misused context labels by looking for uses of {{context}} not immediately preceded by (# |#). - -sche (discuss) 18:47, 7 June 2013 (UTC)

senseid[edit]

Recently {{senseid}} was mentioned in the BP, which brought it to my attention for the first time. It looks like it was made a couple of years ago and hasn't been widely adopted. I like the idea behind it myself so I tried to use it for the senses at field and linked them to those at フィールド. It took quite a long time and added a lot of clutter to the entry. In particular I noticed that it becomes very cumbersome to use when the sense IDs are long, as they were because I was using the translation headers verbatim, as implied (but not stated) in the documentation. So I was wondering:

Is the use of this template still encouraged?
If so, are shorter sense IDs preferred? I think one-word IDs would be ideal, being perhaps the context when it is present. Putting underscores between each word is very time-consuming.

Perhaps this would be difficult, but would it be possible to add an option to select the sense ID from the wikilink pop-up? --Haplology (talk) 16:21, 7 June 2013 (UTC)

It's not necessary to replace blank spaces with underlines; MediaWiki will do that. You can use {{l/beta}} which has a parameter for senseid BTW. --Z 17:08, 7 June 2013 (UTC)

I have long thought of the senseid as an experiment. It seems incomplete and possibly abandoned. Would the widespread deployment of it make it even more difficult to contribute to polysemic English entries? Would the senseid structure be frequently broken by bad edits? Is those non-issues because those entries are now complete or because only a few experienced contributors are willing to tackle these entries and they can deal with senseid? DCDuring TALK 18:38, 7 June 2013 (UTC)

You can/should use shorter glosses, IMO. - -sche (discuss) 18:40, 7 June 2013 (UTC)

Why? Abbreviating the glosses increases the danger of adding a duplicate ID, which invalidates the page's HTML and breaks a link. —Michael Z. 2013-06-07 19:02 z

The reason to abbreviate glosses is that a long sense ID adds a lot of clutter for the editor working on it. Take the first sense:

#{{senseid|en|land area free of woodland, cities, and towns; open country}}A land area free of [[woodland]], cities, and towns; open country.

I suspect that if I were not an autopatroller, my edit to field would be reverted immediately. That's partly why I brought this up here--I thought adding a whole lot of sense IDs would irritate some people. It's hard to say how much risk there would be of broken links. In "field", I don't think that field#English-geology would ever break, but others might be harder to reduce to 3 or fewer words without ambiguity. Am I right in understanding that there is no "What links here" function for these?

I see. I see that you can't even put a space after the trailing braces }} without it showing up on the page. What if the entire first sentence of the definition was in the braces, so there was no redundant text at all? —Michael Z. 2013-06-08 01:49 z

# {{senseid|en|A land area free of [[woodland]], cities, and towns; open country.}}

You mean it isn't a template for telling different 先生s apart?. Seriously, though, "what links here" works, but it includes both these, and every other kind of link, and doesn't show which is which. As for the "whole sentence" suggestion: any rewording of the definition would break the links. The link should be free of content that future editors will feel compelled to change. Even using "sense1","sense2", etc., would lead to editors changing the numbers if they reordered the definitions. Chuck Entz (talk) 02:18, 8 June 2013 (UTC)

Quite right. There may be an advantage to going the other way, and giving the ID no meaning at all. Just a random alphanumeric like "LTas2jzH". —Michael Z. 2013-06-08 03:28 z

There is also {{anchor}}. - -sche (discuss) 18:40, 7 June 2013 (UTC)

I would prefer keeping Sensei D friendly to humans, meaning both that it has the meaning in English and that it's as short as possible to avoid clutter and save typing. I think context labels should be used instead of glosses when possible. I added this one to isolate:

#{{senseid|en|chemistry}}{{context|transitive|chemistry}} To [[separate]] a [[substance]] in [[pure]] [[form]] from a [[mixture]].

...which is linked to by 遊離, by the way.　--Haplology (talk) 05:20, 8 June 2013 (UTC)

Each sense is a unique sense, while several can have the same usage or grammatical label. Using the label would be a bad habit for editors, and a bad example for newbs. —Michael Z. 2013-06-08 05:41 z

Underscores aren't an issue after all and the assisted gloss addition tool selects suggests senses as you type, so using the full sense would be easy, and much easier than I thought earlier. The only worry I have is people complaining about a situation like this:

#{{senseid|en|chemistry: separation of a component from a mixture}}{{context|chemistry}} The obtaining of an [[element]] from one of its [[compound]]s, or of a compound from a [[mixture]]

But if that's acceptable then using the translation header as a sense ID is fine with me. Yet I don't see why using the context as a means of disambiguation is a bad practice. Sometimes there are multiple senses in with the same context, but often not. The wording of the geological sense of field is more likely to change than the number of geological senses. I doubt it would be a problem in practice.

As for broken links, would there be an easy way to find those if links were made using {{l/beta}}? I assume there would be but I have no idea how it would be done. --Haplology (talk) 13:08, 8 June 2013 (UTC)

Using a label instead of a gloss for an ID means:

Teaching editors to make a unique sense ID out of a label.
Teaching them what to do when there is no label (what is that? Use a gloss, I presume.)
Teaching them what to do when there is a duplicate label (Use a gloss for one, or both?).
Teaching them not to add a label just to serve as the source of an ID.
Teaching them to check the IDs when they add a sense with a label, in case it is a duplicate.
Dealing with the mess when they add labels for IDs.
Dealing with the mess when they add conflicting IDs for identical labels.
Living with a system that will break HTML validation predictably, based on the content of the page.

The best way to deal with broken links is to not make broken links. Creating a unique ID from a unique gloss makes sense. Creating a unique ID from a label which may be absent or duplicated does not. —Michael Z. 2013-06-09 20:25 z

Help:Glosses gives a pretty good description of how glosses should be made.
Using glosses in senseids is recommended, by me at least :) . The senseid adding tool in the definition editing options gadget autocompletes to the existing glosses on the page (from translation boxes, synonyms sections, etc.) to make things easier. One significant benefit of using glosses is that it allows machines to identify other areas that have glosses as being associated with a particular definition.
The standard linking template, {{l}}, does not yet support an id= parameter for linking to senseids, though I hope it will at some point. Once it is added, I would be glad to add an equivalent of the wikilink pop-up that would allow selecting senseids from a list. --Yair rand (talk) 14:59, 9 June 2013 (UTC)
I have considerable doubts about senseid. It is likely to make things more complicated, the wiki markup more busy, with not much benefit. If this is to become more widespread, the supporters should better write up how that is supposed to work, what the benefits are, and admit the disadvatanges to the extent to which they are aware of them. Such a write-up does not seem available from {{senseid}} documentation page, nor is it linked from the documentation page. Therefore, I asumme that the benefits are as unclear and as poorly articulated or even unarticulated as they were years ago when senseid was discussed in Beer parlour. --Dan Polansky (talk) 18:02, 9 June 2013 (UTC)
- One way we could lessen the clutter is by integrating it into {{context}}. That way, a context tag would automatically become a sense id. Would that work? —CodeCa t 20:33, 9 June 2013 (UTC)
  A multi-functional template meant for every sense. I would call it {{sense}}, or {{s}}. Each line could look like this:

  # {{s|gloss=A gloss of this sense|labels=history, intransitive|lang=en}} The definition of this sense.

Is lang useful? —Michael Z. 2013-06-09 20:52 z
- The language would be necessary for the same reason it's currently needed on {{context}} and {{senseid}}. It specifies the anchor (in case several languages have the same sense id) and it sets the category language for the labels. —CodeCa t 21:05, 9 June 2013 (UTC)
Could also be {{definition}} or {{d}}. What about capitalizing some important class of template as {{S}} or {{D}}? —Michael Z. 2013-06-09 23:33 z

Thanks for the explanations, I see now why it's better to use glosses than unique labels for sense IDs. I'll look at Help:Glosses carefully soon.

Adding a gloss field to a sense template sounds like a good idea to me. I think human eyes can easily look past a single bracketed blurb, even if it is long. Currently with {{senseid}} you have to delete a space between the hash # and the start of the definition, and it would be nice to avoid that.

For me the appeal of sense IDs is hard to explain, but when writing definitions it always feels like a struggle to get the reader to understand exactly what sense is meant. Usually I do this by lumping glosses together and hoping that the reader sees the senses that they all share, or by putting the usually associated words in parenthesis, but there's something about a linked sense ID that gives it an exact, "snap-in" feel that is very satisfying.

I notice that usually the translations are in the same order as the definitions that they correspond to, but not always: should they always be? --Haplology (talk) 06:30, 10 June 2013 (UTC)

Perhaps one contributor to the lack of use of {{senseid}} is that it doesn't really play well with things like redirects, AFAICT. It would be very handy to be able to use redirects to get people from an expression like "our butts" to butt#English-body, self. I thought it could be done, but I tried several approaches that didn't work at one's butt. Many of the entries for highly polysemic English terms are very hard to sift through without something better than the very poor section-level granularity that we can achieve. We know what definition would help a user interested in a given SoP expression, but can't direct her to it, AFAICT. (I hope I'm wrong about this.) —This unsigned comment was added by DCDuring (talk • contribs) 21:15, 14 June 2013 (UTC).

Redirects to senses seem to work fine... --Yair rand (talk) 17:00, 24 June 2013 (UTC)

Maybe I should have waited longer. Many cross-entry things don't work right away. My first attempt was well-formatted and didn't work right away, so I fooled around with alternatives, thinking I'd forgotten what redirects were supposed to look like.

This could enable the creation of a lot of helpful redirects for failed RfD items. DCDuring TALK 19:37, 24 June 2013 (UTC)

New usage pages with br[edit]

There are a lot of spambot using the code <br> (for break, linebreak). Can we block these edits to save time? I'm spending more and more of my time deleting spam. Mglovesfun (talk) 20:31, 7 June 2013 (UTC)

I wish there were a way to block user-page creation by accounts with no mainspace edits- though it might just encourage garbage edits. Chuck Entz (talk) 02:27, 8 June 2013 (UTC)

Suffix search?[edit]

Although the prefix search (Special:PrefixIndex) comes in handy at times, I would dearly love to have the equivalent for search words with a common ending string, like what Perseus has for its "Dictionary Entry Lookup" tool. Is there any way to do that here? Chuck Entz (talk) 03:51, 8 June 2013 (UTC)

I just use, as an example, *ization in the Search box. You just get unformatted search results, but that's often what you want. SemperBlotto (talk) 07:01, 8 June 2013 (UTC)

Script errors[edit]

Do we really need to have script errors for using {{term}} with a language family name? See chigoe. DCDuring TALK 16:07, 8 June 2013 (UTC)

What alternative do you suggest? —CodeCa t 16:17, 8 June 2013 (UTC)

How would I know what's possible? Can I insert sc=Latn? DCDuring TALK 16:49, 8 June 2013 (UTC)

Apparently, I can. The error message is somewhat less dramatically ugly. Good enough for me. DCDuring TALK 16:50, 8 June 2013 (UTC)

As far as I know we don't have entries for entire language families, so I don't know why it should be linked. DTLHS (talk) 16:52, 8 June 2013 (UTC)

That's why I asked. Such terms shouldn't actually exist, neither in a dictionary, nor in real life. So they don't actually meet CFI and should probably use {{recons}} instead. —CodeCa t 16:57, 8 June 2013 (UTC)

The term is from an unknown member of the family, probably from a time when those in contact were not particularly interested, probably from a language that was and remains little attested. I guess that makes it a nonword. It is obviously not reconstructed by linguists. DCDuring TALK 17:42, 8 June 2013 (UTC)

But if it's not reconstructed then it must be attested, right? And if it's attested, wouldn't we also know the language? Or is there a kind of "gap" in CFI in this case? —CodeCa t 18:12, 8 June 2013 (UTC)

Of course there's a gap. In the real world there can be terms that are not attested and not "reconstructed". The reporting is simply not sufficient to merit inclusion as far as we know. I can't say for sure whether this term is attested in one of the five language that are recognized members of the family. I can say that we will be slow to find out if we make it hard for an interested person to find references to the putative term. Taxonomic names are chock full of names that provide some early evidence of words from native languages. I don't understand whey we don't use term to generate lists of missing words in each language. Such lists would be at least as good as the pages at WT:RE. DCDuring TALK 19:38, 8 June 2013 (UTC)

(edit conflict) I've run into this kind of thing with California Indian languages: early sources may be the only record of extinct languages, but the missionaries, explorers, etc. who wrote these things down didn't know/say what language they were recording (at least not with the kind of precision suggested by use of a language code). Evidence from related lects and comparative work may narrow it down to a given group of languages, but that's it. The terms are definitely attested, but their exact language isn't known. In some cases, it's different enough to assign its own language name (Crimean Gothic may be an example of this, for instance), but often the evidence is too fragmentary to be sure it's not a variety of something already known. While linguists are debating back and forth over the decades about the identity of such fragments, you can't pin a language name on it, but it's not a reconstruction, either. Chuck Entz (talk) 20:03, 8 June 2013 (UTC)

I suppose we could allow {{term}} to use family names then, but only on the condition that the first parameter is blank (no link)? —CodeCa t 20:10, 8 June 2013 (UTC)

Alternatively, what I had started doing was writing {{etyl|afa|en}} {{term|foo|lang=und}}. - -sche (discuss) 20:48, 8 June 2013 (UTC)

Both solutions lose the possibility for using term to generate categories of missing terms by language/language family in the way that {{taxlink}} does for taxonomic names. DCDuring TALK 22:04, 8 June 2013 (UTC)

What exactly do you mean by "missing term"? Do you mean that the template should check if the link target page exists? —CodeCa t 22:05, 8 June 2013 (UTC)

NadandoBot to upload remainder of CJK Unified Ideographs Extension A (U+3400 through U+4DB5)[edit]

Requesting permission for these edits. This is at the request of User:Bumm13. The bot will upload approximately 4557 pages (skipping any pages that already exist). It will also skip any characters without definitions. Test / example edits: 㔫, 㨀, 㨁. I can also provide a file with all of the pages I intend to create upon request. DTLHS (talk) 22:02, 8 June 2013 (UTC)

Would it make more sense to put the definitions in the Mandarin section? (See this short discussion of 佦.) - -sche (discuss) 04:14, 10 June 2013 (UTC)

Not necessarily, some characters simply don't exist in Mandarin, and certain meanings may be restricted to certain languages (e. g. Cantonese), so just putting everything in Mandarin doesn't work. -- Liliana • 04:28, 10 June 2013 (UTC)

Researcher looking for info[edit]

See WT:Information_desk#PhD_research_-_inclusion_dates.

She seems to looking for the date when entries were first created - for all entries - or is that all L2 sections? DCDuring TALK 16:38, 11 June 2013 (UTC)

Context label redirects[edit]

Is anyone able to make an inventory of all redirects that point to a context label template, along with the template they point to? A list of pairs, in other words, like: Template:UK - Template:British. Alternatively (perhaps better), could a category be added to them instead, like Category:Context label redirects (yes, you can categorise redirects!)? That would be very helpful in converting them to a module at some point, and it would also give us an idea of which labels actually exist (in case we want to weed some of them out). —CodeCa t 17:03, 11 June 2013 (UTC)

User:Robert Ullmann/Context labels covers this, just it hasn't been updated for a long time. Mglovesfun (talk) 17:21, 11 June 2013 (UTC)

{{rel-top}} does not seem to function outside of principal namespace, eg, in Appendix space and User space. This seems like yet another regression. Can it be fixed? DCDuring TALK 18:11, 11 June 2013 (UTC)

I can't see anything about it that would make it not work. It should just be fine... —CodeCa t 18:13, 11 June 2013 (UTC)

I know that it should be. Have you tested it in any space other than principal namespace? Try User:DCDuring#Taxonomy. On my PC (Win 7, FF 21) the all-important unhiding icon is not visible and the unhiding functionality is absent on that page and on a test I ran in Appendix space. DCDuring TALK 18:20, 11 June 2013 (UTC)

Also, as my computer is rarely off and keeps several windows open continuously, including to my main user page, this behavior need not have been caused by a recent change, but could have been caused by something days or even weeks ago. As I am neither a CSS nor a template maven, I have no idea of what the cascading consequences of changes to classes might be or even where to find the various class definitions. DCDuring TALK 18:25, 11 June 2013 (UTC)

The "show" button is visible for me and works as normal. I think it must be on your end? —CodeCa t 18:28, 11 June 2013 (UTC)

Aarrgghhh. I have not changed by CSS or JS in a long time. What could make a difference in any of the preferences (though I don't remember making a change there either)? DCDuring TALK 18:31, 11 June 2013 (UTC)

I can't unhide the above. DCDuring TALK 18:34, 11 June 2013 (UTC)

And can make trans and rel unhiding work as normal in principal namespace. DCDuring TALK 18:37, 11 June 2013 (UTC)

I'd always wondered what kind of thing would finally get me to stop spending time here. This would be an example. DCDuring TALK 18:58, 11 June 2013 (UTC)

In both Firefox and Opera, on a PC running Windows 7, the above rel-box works for me. :/ A while ago, some users complained that the "show quotations" button was missing, and I found that it was indeed taking a while longer than usual to load. That problem seems to have cleared up, but perhaps some of the elves/hamsters that run javascript call in sick from time to time? Because it's javascript that collapses the boxes in the first place, you could temporarily disable javascript, which would have the effect of making the boxes display open (and uncollapsible). - -sche (discuss) 19:15, 11 June 2013 (UTC)

What's strange top me is that in principal namespace it works fine, but not in User, Appendix, and Wiktionary spaces. How would JS become inoperable, 1., by mistake, and/or 2., only in some namespaces? DCDuring TALK 19:57, 11 June 2013 (UTC)

It happens to me on Chrome to, but only when I am logged in, not as an anon. That seems to be a diagnostic help. DCDuring TALK 20:02, 11 June 2013 (UTC)

"Doctor, whenever I use the monobook skin (both in Firefox and Chrome), I can't use rel-top. What should I do?"

"Stop using monobook."

It's an old joke. Was I the last one using monobook? DCDuring TALK 20:25, 11 June 2013 (UTC)

For the purposes of this thread, I just switched to Monobook, and I am still able to open the rel-top in this thread. You and I seem to be using the same system (Monobook, Firefox 21, Windows 7). I'm stumped. - -sche (discuss) 00:08, 13 June 2013 (UTC)

I still have the problem in Monobook, not Vector. I have no skin-specific JS. I assume that the problems is somewhere in the JS created by the selection of preferences for gadgets, in the interaction with some feature of the Monobook skin, which may not have been as thoroughly tested. DCDuring TALK 01:31, 13 June 2013 (UTC)

It seems to have had to do with selecting "translate sidebar interwiki links into English" in gadgets for Monobook, but not Vector. I really do prefer Monobook. DCDuring TALK 02:57, 13 June 2013 (UTC)

Watchlist not working[edit]

My watchlist seems to be now permanently broken: it always times out (since several weeks ago). Perhaps this is because of a large number of bot edits recently? What can I do about it? I would even consider wiping the entire list back to nothing, if this can be done. Please respond by talk page since I cannot watch this page. Equinox ◑ 12:09, 12 June 2013 (UTC)

Okay, hiding bot edits seems to have fixed it (for now?). Equinox ◑ 12:40, 12 June 2013 (UTC)

If you ever do want to wipe your watchlist clean, the quickest way to do it is to go to Special:EditWatchlist/raw, select all, and delete. —An gr 12:54, 12 June 2013 (UTC)

Actually, that page times out too, and did so long before my actual watchlist started timing out. Equinox ◑ 12:57, 12 June 2013 (UTC)

Well, that sucks. How many pages you got on there? Does the nonraw Special:EditWatchlist work? 'Cause if you can't access either of those pages, the only way I know of to reduce the number of pages on your watchlist is one by one (slightly faster if you're using pop-ups than if you open each page separately). —An gr 13:02, 12 June 2013 (UTC)

Is this worth a bug report? I find the watchlist to be hard to manage in a way that enables me to keep track of what I'd like to and not too much else. It is easy to forget to watch individual pages and watching every page one edits by default leads to glut. If high-volume contributors don't watch pages, that places even more burden on recent-change patrollers.

Also, doesn't this connect to #One-click patrolling gone away? Ruakh made changes and refers to Special:Watchlist as possibly being adversely affected. DCDuring TALK 13:10, 12 June 2013 (UTC)

No — I meant only that the use-case of one-click patrolling at Special:Watchlist is adversely affected by recent MediaWiki changes, in that even after my compensatory changes to the Gadget, some unpatrolled edits on Special:Watchlist will continue to have the red exclamation point instead of the blue button. —Ruakh_TALK 14:43, 12 June 2013 (UTC)

[1] — does this page time out too? If not, there is a possibility you can wipe your watchlist with mw:API:Watch. Keφr 18:15, 12 June 2013 (UTC)

Vote for this bug at bugzilla. DCDuring TALK 22:55, 12 June 2013 (UTC)

template for 'approbative'?[edit]

Hi, I don't know if a discussion has already been had on this, but I think we need a template for approbative. We already have {{pejorative}}, but not its antonym. I'm happy to make the template if one doesn't already exist under some name that I haven't already looked for. Thanks! --Person12 (talk) 23:38, 14 June 2013 (UTC)

What kind of words would it be used for? There is {{politically correct}}. — Ungoliant ^(Falai) 23:58, 14 June 2013 (UTC)

E.g. awesome (adj) sense 2, cool (adj) senses 6&7, hot (adj) senses 6&10, positive (adj) sense 18, and many others. "Politically correct" wouldn't work at all: for one thing, it's such a subjective and loaded term, and for another, it's not the grammatical opposite of pejorative, which, I believe, is "approbative".--Person12 (talk) 00:26, 15 June 2013 (UTC)

I see. In that case, would an approbative label really be necessary? Isn't the fact that the relevant definitions of awesome, cool, etc. are approbative made clear by the definition (unlike pejorative, which is not obvious in cases like gringo)? — Ungoliant ^(Falai) 00:42, 15 June 2013 (UTC)

I think an approbative label would still be really helpful. I don't think the definitions necessarily make it clear enough for all possible readers, and I think it would be worth having the associated category/list (I'm assuming a category is automatically created when a label is used - is that right?). --Person12 (talk) 10:07, 15 June 2013 (UTC)

Yes, as long as you create the template and it has poscat= parameter. — Ungoliant ^(Falai) 11:19, 15 June 2013 (UTC)

We do not label words like bad or evil as "pejorative". Why would we label good as "approbative"? Why would we label any adjective more-or-less synonymous with good as "approbative"?

Furthermore, approbative is not a word I would want to be subjecting our users to. Many would probably have some trouble with pejorative. Approbative is used less than 0.5% as often as pejorative in BNC+COCA.

If we are going to do something like this, we should probably start with an Appendix of such terms to iron out the conceptual problems before rolling it out. DCDuring TALK 14:22, 15 June 2013 (UTC)

Great, the Appendix idea sounds fine.

Labelling certain words 'approbative' would make it clear that the word is being used to express approval when that might not be sufficiently clear otherwise. E.g. the (New Age jargon sense) of positive could (in my opinion) benefit from another label to further distinguish its (much more subjective) usage from the (much more objective) scientific senses/usages.

As for those who personally dislike the words 'approbative' and 'pejorative', they are more than free to express their opposition. In the case of the latter, though, wouldn't that suggest starting a discussion here?

(p.s. You ask "why would we label good as "approbative"?" I actually didn't suggest labelling 'good' as 'approbative', or 'bad' and 'evil' as 'pejorative', for that matter. Just for the record.)--Person12 (talk) 03:47, 16 June 2013 (UTC)

I don't intend for the Appendix to necessarily be the exclusive home for these permanently. Marshall some examples, spanning the range of possibilities. Provide some rationale for selection or for exclusion of words that a naive observer might believe should be so labeled, eg, like good, youthful, energetic. As far as I'm concerned, give a month for objections or a week after comments negative or qualifying comments stop flowing in and start rolling it out into entries.

An additional question is whether these words should be categorized. I believe not, at least if you do not intend to include in the category all words that are "approbative", which would at least arguably include good. To me categories always imply that the goal is to include all terms that have meet the criteria or have the attribute. DCDuring TALK 08:27, 16 June 2013 (UTC)

These three entries have errors because the language uses a script code that we don't actually have, Jurc and Lina. This should probably be fixed somehow, either by creating these codes or by changing the script for these languages. —CodeCa t 23:39, 14 June 2013 (UTC)

The entries are in Latin script, so I guess their languages' script should be changed to Latn until the actual script is included in Unicode. — Ungoliant ^(Falai) 23:56, 14 June 2013 (UTC)

Indeed. Mglovesfun (talk) 10:58, 15 June 2013 (UTC)

I'm not able to edit these entries. I can view them, but when I make an edit, I get a wikimedia error when I save it. Is anyone else able to? —CodeCa t 21:24, 15 June 2013 (UTC)

I can't either. Is your bot able to edit them? DTLHS (talk) 21:26, 15 June 2013 (UTC)

Both pages begin with U+FEFF (ZERO WIDTH NO-BREAK SPACE). Unfortunately even if I remove this character in a text editor I still can't save the pages. DTLHS (talk) 21:34, 15 June 2013 (UTC)

My bot isn't able to either, it gets an error. —CodeCa t 21:52, 15 June 2013 (UTC)

I tried moving it around, didn't fix the problem. Oddly enough, I got the error message when moving, but the page was moved anyway. — Ungoliant ^(Falai) 22:06, 15 June 2013 (UTC)

I was able to revert to a version from 2008 (the latest I could view in the history). I still can't view any of the diffs from then until now. DTLHS (talk) 22:06, 15 June 2013 (UTC)

These entries working fine in my mirror (from the latest dump). — Ungoliant ^(Falai) 22:11, 15 June 2013 (UTC)

Actually no. I added one character and the diff says +1,761 bytes! — Ungoliant ^(Falai) 22:14, 15 June 2013 (UTC)

If I copy the content of [[rebut]] as it was at 03:07, 10 February 2013 into another page, I can edit that page, and save it, and edit it some more... but I can't edit [[rebut]] itself. - -sche (discuss) 22:56, 15 June 2013 (UTC)

OK, I just updated the page. If you compare these diffs, you'll notice the dismal nesting of {{term}} that I fixed (thanks to Ungoliant for the assist). - -sche (discuss) 23:08, 15 June 2013 (UTC)

Nesting of another template inside {{term}} seems to have also been responsible for breaking the Hebrew page. - -sche (discuss) 23:09, 15 June 2013 (UTC)

The bad formatting was introduced by Doremítzwr in this diff (you can view the diff if you turn "do not show page content below diffs" on in your preferences), but the page was often edited after that, so it must be only a recent change to {{term}} or to MediaWiki software that causes such bad formatting / nesting to actually break the page. - -sche (discuss) 23:24, 15 June 2013 (UTC)

Is all nesting inside {{term}} a problem? I may have inserted some instances of {{taxlink}} in {{term}}.

Is the problem due to recent changes in {{term}} or something {{term}} uses? DCDuring TALK 23:27, 15 June 2013 (UTC)

Might be a result of Luaisation. My mirror has the latest MediaWiki and no Scribunto, and these entries are working fine (the byte amount bug was unrelated.) — Ungoliant ^(Falai) 23:34, 15 June 2013 (UTC)

This apparently depends on namespace- I can't reproduce the bug on my own sandbox. DTLHS (talk) 00:07, 16 June 2013 (UTC)

So one minimal way to reproduce the error is {{term||{{various templates}}}}. Templates that fail in this context include {{asdfg}}, {{test}}, {{term}}, {{soplink}}, {{lang}}, {{diff}}. Templates that do not fail include {{temp}} and all language templates. DTLHS (talk) 00:32, 16 June 2013 (UTC)

Pretty sure it fails simply if the offending template directly calls any other templates. DTLHS (talk) 00:38, 16 June 2013 (UTC)

Hi all. I saw this earlier today and didn't respond then because you all were able to work around it. But now that I'm back on my computer, could I ask one of you to report this as a bug so we can take a look at it? Our bugtracker and mw:How to report a bug. Thanks! Greg (WMF) (talk) 05:04, 16 June 2013 (UTC)

Bug reported here. DTLHS (talk) 19:28, 16 June 2013 (UTC)

The problem lies with Module:term cleanup, probably specifically to the containsRange function and with mw.ustring.gcodepoint. DTLHS (talk) 17:50, 16 June 2013 (UTC)

{{taxlink}}, probably because it is extremely simple-minded, apparently does not have a problem when used in the second parameter of {{term}}. Of course, it conspicuously fails in the first parameter. DCDuring TALK 18:35, 16 June 2013 (UTC)

Language section linking for requests[edit]

As we specify language for templates like {{rfv}} and {{rfv-sense}}, can we not have the section header on WT:RFV link back to the right language section on the entry? Or, better, the location of the RfV tag (or the first RfV tag) with the right language? DCDuring TALK 01:15, 18 June 2013 (UTC)

BTW, it wouldn't hurt to display the language of the RfV in the header, especially for non-English terms. DCDuring TALK 01:17, 18 June 2013 (UTC)

Sure, though I'm not strongly in favor of it either. Mglovesfun (talk) 10:21, 18 June 2013 (UTC)

Done for {{rfv}}. Is there a specific reason you requested that and {{rfv-sense}} but not the other templates ({{rfd}}, {{rfd-sense}}, {{rfd-redundant}}, {{rfc}}, {{rfc-sense}}, {{rft}}, {{rft-sense}}, {{rfv-etymology}}, any others I've missed)?—msh210℠ (talk) 17:28, 18 June 2013 (UTC)

Oh, you said "templates like". Sorry.—msh210℠ (talk) 17:29, 18 June 2013 (UTC)

Done for {{rfv}}, {{rfv-sense}}, {{rfv-etymology}}, {{rfd}}, {{rfd-sense}}, and {{rfd-redundant}}.—msh210℠ (talk) 18:03, 18 June 2013 (UTC)

There probably are other templates that would benefit, but none more than these. Thanks. I hope others find it as useful as I do. DCDuring TALK 02:26, 21 June 2013 (UTC)

Conrad.Bot not building indexes[edit]

I see that Conrad.Bot hasn't run to rebuild language indexes for over a year. Does anyone have the time/expertise to take over this really useful task? SemperBlotto (talk) 14:53, 18 June 2013 (UTC)

MW tech proposal to enable better watchlist[edit]

There is a proposal to add two fields to the watchlist database, one a timestamp, the other a hundred characters for input by user, which could support customized to-do-list-like watchlists. The second might enable a user to express a preference for watching only one or more section(s) of the entry (eg, language sections !!!), which preference might be used by some enhanced watchlist software to serve up only entries that have such changes to one watchlist page. The timestamp could facilitate editing one's watchlist based on when one started watching, in addition to whatever was in the 100 character field.

There might be some momentum because this is a change to support "editor engagement", which seems to be a strategic thrust at MW: They are trying to do things to get/keep editors involved in the basic work at all the projects. I've made some comments, but more technically proficient folks should weigh in at MW. We don't have to have a united front at this stage, so feel free to disagree. DCDuring TALK 02:22, 21 June 2013 (UTC)

Invisible login[edit]

Hi,

Does someone know why the first user who had suppress this page hasn't name?

Thanks by advance, Automatik (talk) 14:59, 23 June 2013 (UTC)

If you look at the page history, the move was done by the conversion script that implemented the change from all upper case to lower case for entry names. From User:Conversion script, it would seem that it's a special type of account that doesn't show up in some logs- but I have no clue as to the technical details. Chuck Entz (talk) 15:33, 23 June 2013 (UTC)

That was way back in '05. I wonder how many technically adept folks remain who were here then. DCDuring TALK 15:39, 23 June 2013 (UTC)

Paul G. seems to have made the same move later in the same year, but if you are an admin and you view the delete revisions, there's only one, the one by Paul G. I have no idea but it also doesn't matter so it's purely an exercise in satisfying our own curiosity. Mglovesfun (talk) 15:45, 23 June 2013 (UTC)

As Chuck says, the first move was made by the Conversion script, which was not a user or even an account in the usual way, but a script that was run (by the developers? directly on the database?) when the decision was made to make Wiktionary case-sensitive (and it was realised that it was easiest for all pages to be moved to lowercase and the few capitalised words to be moved back, than to try to decapitalise all the appropriate words by hand for the sake of not erroneously moving [[Germany]] to [[germany]]). Prior to that, pagetitles were automatically capitalised, as they are on Wikipedia. - -sche (discuss) 17:05, 23 June 2013 (UTC)

Interesting. Thank you all for your answers :) Automatik (talk) 21:42, 23 June 2013 (UTC)

Would someone less intimidated by template syntax than I am please edit Template:inflected form of so that it accepts the lang= parameter in the usual way, i.e. so that it links to the specific language section of the page in question? Thanks! —An gr 15:46, 23 June 2013 (UTC)

Will m:User:Remember_the_dot/Syntax_highlighter help with your anxiety? I would have done it, but that would probably need some editing of {{wlink}}, which I cannot do, and I am actually unsure if that matches the intention of whoever made that template. Keφr 16:43, 23 June 2013 (UTC)

Probably not, no. Keeping track of closing brackets is the least of my problems. Maybe someone else can do it? —An gr 17:11, 23 June 2013 (UTC)

Done. I did not add script support, however.—msh210℠ (talk) 21:22, 24 June 2013 (UTC)

Undone. What I did should have worked AFAICT but added an uncalled-for linebreak, breaking things (besides lines).—msh210℠ (talk) 21:27, 24 June 2013 (UTC)

Redone, including script support. Nothing seems to break. Keφr 12:16, 26 June 2013 (UTC)

I want to try to convert the form-of templates to Lua and make a single common module for them. Then issues like this should no longer happen because they share the same code. —CodeCa t 12:20, 26 June 2013 (UTC)

etymtree script error[edit]

There's a great concept behind Template:etymtree, but something goes wrong on this page: Appendix:Proto-Balto-Slavic/wandō. - -sche (discuss) 18:50, 23 June 2013 (UTC)

Looks fine to me. What's the problem? —An gr 21:24, 23 June 2013 (UTC)

It was only showing up as a script error, but Yair fixed my erroneous invocation of it. - -sche (discuss) 21:37, 23 June 2013 (UTC)

Failures of our Search feature[edit]

I've been chewing for a while on the issue of discoverability, and by extension, of whether to go about creating entries for the various inflected forms of Japanese terms. I tried searching for 誓って (chikatte), the conjunctive inflection of verb 誓う (chikau, "to swear, to make an oath"). Our Search feature comes up with nothing. I click through to the 誓う page and expand the Conjugation section, and there it is, 誓って, staring me in the face.

This leads me to my questions:

Why is Search not finding 誓って? Is it because this form is supplied by a template, and is not actually present in the wikitext of the page itself? Is there any way of fixing how Search works to also find strings supplied by templates?
Somewhere along the way, I came by the understanding that we shouldn't be adding in entries for inflected forms in Japanese. (I cannot recall how or where I gained this impression, and I'm perfectly happy to change my m.o. in this regard.) I see, however, that we do have entries of inflected forms in other languages, such as quiero or isst or amat, or apples or tāngata or kerkje. Given the failures of the Search feature, should we likewise create entries for inflected forms of Japanese terms?

I look forward to your insights and advice. -- Eiríkr Útlendi │ Tala við mig 19:29, 23 June 2013 (UTC)

I don't see why we shouldn't have Japanese inflected forms, regardless of whether the search is fixed. —CodeCa t 19:36, 23 June 2013 (UTC)

Indeed the search only parses the source and doesn't take templates into account at all. But you can use Google Search for that. -- Liliana • 19:43, 23 June 2013 (UTC)

It should really parse the wikitext after applying templates and modules. If it's not able to find inflected forms listed in template-generated tables then that is a rather serious drawback, given how many templates are used on Wiktionary. —CodeCa t 20:02, 23 June 2013 (UTC)

If so, then a bug report should be filed. DCDuring TALK 20:37, 23 June 2013 (UTC)

It's bugzilla:18861.—msh210℠ (talk) 21:32, 24 June 2013 (UTC)

A four year old bug? That is rather sad... —CodeCa t 22:39, 24 June 2013 (UTC)

If your inflection tables create links (which {{ja-go-u}} doesn't, but many others do), then the second thing you can try is Special:WhatLinksHere to see if you can find the desired term in some other term's inflection table. But if the inflection table doesn't create links, of course you can't. —An gr 21:22, 23 June 2013 (UTC)

I also got the impression somewhere that pages for inflections were discouraged, but I don't know where, and I see no reason for not having them. If somebody added them, I think that would be great. I've thought of trying it myself at some point. In the meantime we have the answer to the question in the title, and indeed Google will eventually a good place to make such searches, once WT makes the first page (it doesn't show up when searching for "誓って" right now.) The day will come. It might show up if there were a page specifically for that inflection... I'll make that page now and we'll see what happens. 誓って is by the way what I imagine such a page should look like, so please say if you approve.

If we did have links to inflections, if understand correctly, that would mean adding thousands of link to verbs from their nominal counterparts. For example, see the second sense of 誓い which I have just added. Actually though I would kind of prefer that to using {{ja-see-also}} (why should I see it? why is it related?) which is often not used now anyway. --Haplology (talk) 17:30, 24 June 2013 (UTC)

If you know you want to search within Wiktionary, you can search Google for: site:en.wiktionary.org 誓って, which will restrict Google's search to our site. When you do that, 誓い is the first hit. —An gr 19:37, 24 June 2013 (UTC)

As an addendum:

When talking about discoverability, I think it's important to note that we should be assessing how easy it is for a newbie user to find things on Wiktionary. As such, more advanced tricks like Special:WhatLinksHere and site:en.wiktionary.org should be considered out of scope, unless we add text to the Search feature landing page that points new users to such techniques. A new user is more likely to see the search box in the upper right and try that, or to use the Look up field on our front page, and if the Search feature doesn't find it, the natural assumption is that Wiktionary doesn't have it. This is the shortcoming I'm hoping to explore and address. -- Eiríkr Útlendi │ Tala við mig 20:18, 24 June 2013 (UTC)

I do think it would be a good idea to add such features to our "unsuccessful search" page. Currently it just says "There were no results matching the query" and then below that, "You may create the page hjkl on a blank page, request its creation or create it using the New Entry Creator!" It would be good to have some options below "There were no results matching the query", such as "See if anything links to this query" and "Try a Google search of Wiktionary for this query". —An gr 21:05, 24 June 2013 (UTC)

Yes, I agree wholeheartedly -- offering additional options for finding things is a very good idea, especially when our own Search feature is known to be pretty horribly inadequate (I just read through the bug report at bugzilla:18861 that msh210 linked to above). How would we implement such a change? And what specific additional links should we offer? -- Eiríkr Útlendi │ Tala við mig 22:26, 24 June 2013 (UTC)

[e/c] I've added a bit to that page. See what you think. (It's at [[mediawiki:Searchmenu-new]].)—msh210℠ (talk) 22:43, 24 June 2013 (UTC)

This seems like the right direct for useful improvements to enhance the chances that Wiktionary will survive: We needed a steady stream of newbies who hang around, improve the place, and make it look as if we are doing some good in the world (while we amuse ourselves). DCDuring TALK 22:39, 24 June 2013 (UTC)

Msh210, thanks for making the edit! But your links fail on multi-word searches. I just searched for en plein essor and the WhatLinksHere and Google searches will serach only for the first word. —An gr 16:42, 25 June 2013 (UTC)

I dunno if someone's made some changes in the meantime, but I just tried it for the same string (here), and I see that the initial "en" is missing from the search string as described on the page ("See whether plein essor another page links to en plein essor. Or, see whether plein essor Google can find it for you"), but that both of the links (for Special:WhatLinksHere and for Google) do in fact just search for "en", with "plein essor" completely missing. Somethin' ain't right, that's for sure. -- Eiríkr Útlendi │ Tala við mig 17:16, 25 June 2013 (UTC)

(And re Angr.) Sorry about that. Now fixed, I think.—msh210℠ (talk) 19:01, 25 June 2013 (UTC)

Looks good. What do we need to make this change go live? -- Eiríkr Útlendi │ Tala við mig 19:08, 25 June 2013 (UTC)

It's live. Should the Google search put quotation marks around the term? It doesn't now.—msh210℠ (talk) 19:25, 25 June 2013 (UTC)

No quotes -- doing so restricts Google's results in a way that excludes likely typo fixes. Compare google:site:en.wiktionary.org "cowtow" versus google:site:en.wiktionary.org cowtow. (This misspelling showed up recently when a frustrated user posted on WT:Feedback -- see WT:Feedback#Special:Search_4 or search the page for cowtow.) -- Eiríkr Útlendi │ Tala við mig 19:47, 25 June 2013 (UTC)

abuse filter request: block pagetitles containing soft hyphens[edit]

I suggest that we use an abuse filter to block the creation of new pages with titles that contain soft hyphens. Several users have somehow accidentally created pages with titles that contain soft hyphens (see WT:RFM#pages_with_titles_which_contain_soft_hyphens); this would stop that. We could also block the addition of soft hyphens anywhere, but there might be legitimate reasons for soft hyphens to be used in pages, e.g. if texts were copied from usenet posts that used it. - -sche (discuss) 03:21, 24 June 2013 (UTC)

The better way is just removing the characters by MediaWiki software when the user is trying to create or search for a string that contains them. There are also other characters that should be removed, ZWJ, ZWNJ, etc. when they are at the initial or final position. The software currently removes only white spaces AFAIK. --Z 16:54, 24 June 2013 (UTC)

I have created this module to validate any IPA string passed to it (currently just based on invalid characters, but this could be made more sophisticated if desired). Currently there's only one character in the badchars table (ʦ). Thoughts? DTLHS (talk) 05:06, 25 June 2013 (UTC)

A list of valid characters would be better in the end, because there are more invalid ones than valid ones. —CodeCa t 11:42, 25 June 2013 (UTC)

Agree with above, you can do all of this just by one line, if mw.ustring.find(IPA_text, '[^a-zɐ-ʢ]') then error('invalid character') end (but diacritics should also be added). --Z 12:27, 25 June 2013 (UTC)

That won't work, because IPA uses a few characters from the Greek block as well. -- Liliana • 14:05, 25 June 2013 (UTC)
addendum: if you really want to go down that route, check Appendix:IPA characters first. I created that page for a reason. -- Liliana • 14:06, 25 June 2013 (UTC)

Yes, I just wanted to say which way is the correct approach.

What is the source of that list? is ¡ really used in IPA? --Z 14:18, 25 June 2013 (UTC)

Symbols are taken from various sources. Yes, the inverted exclamation mark is used in IPA (but it's extraordinarily rare). -- Liliana • 15:41, 25 June 2013 (UTC)

So rare it's not listed on any official IPA chart I've ever seen. What sound is it supposed to represent? —An gr 16:44, 25 June 2013 (UTC)

It's supposed to be the "sucking tongue" sound, or, in phonetics-speak, the sublaminal lower alveolar click. -- Liliana • 16:48, 25 June 2013 (UTC)

Maybe it's better to comment Appendix:IPA characters so people know what the symbols are for, no? -- Liliana • 18:51, 26 June 2013 (UTC)

See also Module:IPA – I manually created the table from the IPA articles in Wikipedia and elsewhere. —Michael Z. 2013-06-25 14:43 z

Lets merge "validate IPA" to Module:IPA. --Z 14:46, 25 June 2013 (UTC)

Yes, of course. —Michael Z. 2013-06-25 15:05 z

I agree that listing all valid IPA characters is easier/better than listing invalid ons, but if you're interested, here is a list of the invalid characters I've seen people use. Note that it is sometimes useful/correct to use non-IPA characters inside {{IPA}}, however: namely, it's useful to use <ref name="whatever">some reference for this specific pronunciation as opposed to the next four which also have refs</ref>, as in [[eschew]]. (If all of the references were put outside the template, it would be unclear which refs supported which pronunciations, and if each referenced pronunciation was put in a separate invocation of {{IPA}}...that'd duplicate "IPA:" in the displayed text a lot...) - -sche (discuss) 15:46, 25 June 2013 (UTC)

We could also add n1=, n2=, n3= to {{IPA}}, in the same way we do for {{compound}}. That would solve other problems as well. —CodeCa t 15:53, 25 June 2013 (UTC)

That's an incorrect usage, {{IPAchar}} should be used directly instead IMO with the refs just after the template (instead of being in input). Firstly because the input is tagged with IPA class and lang="" attribute (which is undesired for refs), and secondly, commas should be before refs. --Z 15:57, 25 June 2013 (UTC)

Yes, the reference markers should be outside of the template. —Michael Z. 2013-06-25 16:41 z

Template/pages cross reference[edit]

Hi, is there a way to get a list of pages using a given template ? I searched in special pages but didn't find it ? Thanks a lot. Unsui (talk) 08:09, 25 June 2013 (UTC)

Special:Whatlinkshere. Keφr 08:11, 25 June 2013 (UTC)

Ok. Thanks again. Unsui (talk) 08:14, 25 June 2013 (UTC)

AutoWikiBrowser can give you a usable list of all of them, if you like. Mglovesfun (talk) 12:46, 25 June 2013 (UTC)

I have just added the reference template {{R:lv:LEV}} to this word. Now, even though this template automatically places the word in Category:Latvian etymologies from LEV (it is indeed listed there), I don't see a link to this category at the end of the page; this is apparently because I have the 'tabbed languages' gadget on. If I turn it off, the category does appear at the end of the page. With 'tabbed languages' on, Category:Latvian etymologies from LEV does not appear under the Latvian tab, but, surprisingly, under the Italian tab (probably because Italian is the first language on that page). Is this perhaps a glitch in the tabbed languages gadget? Should the person who takes care of gadgets here (who is s/he?) be informed, so that s/he can try to fix it? --Pereru (talk) 20:42, 25 June 2013 (UTC)

Annoying delay in "citations" tab appearance[edit]

When I visit an entry, the "tabs" along the top of the page are Entry, Discussion, Edit, History, Move, Watch. About 1-2 seconds later, Citations pops up. If I'm moving the mouse in order to click one of the tabs, this often makes me click the wrong thing, since the latecomer Citations shifts other tabs to the right. Can we fix this somehow, e.g. put a fixed-width placeholder where Citations is due to be placed, so it doesn't move anything? Equinox ◑ 22:25, 25 June 2013 (UTC)

Currently, the headword line of [[s'more]] looks like this:

s'more (plural s'mores)

I.e., the plural is just black, it isn't blue — it isn't linked to. This seems to be the case for all entries in the above category which contain apostrophes. The headword line of entries which contain hyphens are even more broken, e.g. [[avant-coureur]] looks like this:

avant-coureur m (plural [[avant-coureurs#French|avant-coureurs]])

(Notice that the link doesn't lead to the plural form [[avant-coureurs]], but to [[avant]]-[[coureurs]]!)

Entries which use both apostrophes and hyphens suffer from the same problem as entries which contain only apostrophes. - -sche (discuss) 00:10, 27 June 2013 (UTC)

The problem with apostrophes is sort of a known problem. I don't remember how to fix it, I think Ruakh does. The problem with avant-coureur is because {{fr-noun}} is badly coded. It uses {{{head}}} as the base form for the plural, which does not work when it is overridden to provide links. —CodeCa t 00:18, 27 June 2013 (UTC)

Oh, is it related/similar to the problem with asterisks? If so, perhaps it can be fixed the way [[*nix]] was fixed. Incidentally, AFAICT all this edit to *nix did was remove the (proper) bolding from the plural forms...? - -sche (discuss) 00:31, 27 June 2013 (UTC)

In that particular case I wonder why the bolding is not provided by the template, like it should. Removing it from the entry seems sensible. —CodeCa t 00:55, 27 June 2013 (UTC)

You are receiving this email because you subscribed to this feed at blogtrottr.com.

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

Wealth Maker

Wednesday, June 26, 2013

Wiktionary - Recent changes [en]: Wiktionary:Grease pit/2013/June