Wiktionary:Grease pit/2014/March

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
discussion rooms: Tea roomEtym. scr.Info deskBeer parlourGrease pit ← February 2014 · March 2014 · April 2014 → · (current)

Projectlinks[edit]

Something's gone wrong with the display of Template:projectlinks: it's showing some module invocation code instead of the correct link text. This, that and the other (talk) 10:31, 1 March 2014 (UTC)

Fixed, seemingly by Kephir. This, that and the other (talk) 09:19, 4 March 2014 (UTC)

quotations JS[edit]

At eye#Noun, I noticed that the JS that suppresses the display of quotations makes the "quotations" display control appear nicely at the end of each definition, unless there is a usage example (whether or not {{usex}} is used) immediately after the definition, in which case it appears on a separate line. A better appearance results from placing all the quotations for a definition immediately after the definition with the usage example after the quotations.

Would it be possible to amend the JS so that the little blue "quotations" display control always appeared on the definition line? DCDuring TALK 01:41, 3 March 2014 (UTC)

Done. --Yair rand (talk) 11:14, 3 March 2014 (UTC)
Thanks. That looks much better. I hope we don't discover any bad side-effects. DCDuring TALK 11:34, 3 March 2014 (UTC)

Accelerating Template:ast-adj[edit]

Hi. Kenny was kind enough to ACCELerate Template:ast-adj, but apparently it isn't yet fully ACCELerated. He says to do that, the "rules" need to be changed. I have a request at User talk:Conrad.Irwin/creationrules.js, and would appreciate it if an admin could make the necessary changes as explained there. Thanks in advance. --Back on the list (talk) 13:12, 4 March 2014 (UTC)

Done. —CodeCat 13:59, 4 March 2014 (UTC)
Thanks kitty! Love you! --Back on the list (talk) 14:42, 4 March 2014 (UTC)
Well, the neuter singular ACCEL doesn't actually work. Any suggestions? --Back on the list (talk) 18:02, 9 March 2014 (UTC)
Try again. Keφr 19:12, 9 March 2014 (UTC)

Pronunciation Recording[edit]

Visual workflow draft for pronunciation recording gadget; If you have trouble watching this video here, watch it on vimeo. A more extensive/explanative version is available.

Dear Wiktionary community!

About me
My name is Rainer Rillke, and I have been volunteering at Wikimedia Commons for 3 years now, gathering experience around media files. I've been always interested in how things work and how one could improve them.
The idea
One idea that appeared last Summer was allowing the recording of small chunks of speech, uploading that to Wikimedia Commons in the background and including this into a Wiktionary entry without having the hassle doing everything by hand or installing additional software. That idea led to the foundation of MediaWiki extension PronunciationRecording during the Google Summer of Code. However, this was not completed; instead development is stale for over 5 months now.
My proposal
To make this going to work, so Wiktionary has an immediate benefit of this feature, I would like to provide the work done so far as a gadget and add some more work in regard to usability. You can see my plan at m:Grants:IEG/Finish Pronunciation Recording. And more importantly, you can give me a hand, if you are interested.
Looking for volunteers and 2 consultants
Often, software projects that are not aligned to the community's needs produce vapourware. Recently, that happened to a $ 15,000 grant. I don't want to write vapourware, I need your advice! Without community support, I cannot and will not continue this project. So here is what I am looking for:

Don't forget to comment. Thanks and kind regards -- Rillke (talk) 18:28, 6 March 2014 (UTC)

Hey guys, I got so excited by this project that I decided to join it. From personal experience, I see how uploading an audio file can be irritating. This project will make it a lot easier to do so, encouraging even casual users to upload audio pronunciations.
Wiktionary already has a decent coverage of IPA pronunciations, but we are still lacking in audio pronunciations. I know that for most of us IPA is sufficient, but, as evidenced by feedbackers every now and then, there are many users for whom IPA is nothing more than incomprehensible clutter.
If you agree, I ask that you post your support here. If not, tell us why. — Ungoliant (falai) 01:19, 7 March 2014 (UTC)
Thanks for the video. This seems like it would be a very useful gadget. I have left an encouraging comment here. - -sche (discuss) 00:05, 14 March 2014 (UTC)

ACCEL broken[edit]

A recent edit to User:Conrad.Irwin/creation.js seems to have broken it: you can see this on silver foil where silver foils is a red link with broken green underlining. If someone creates silver foils, you can just go to a gibberish pagetitle such as h@aw and preview the page with {{en-noun}} added. - -sche (discuss) 23:59, 8 March 2014 (UTC)

I have undone the edit in question until a bug-free version of it can be implemented. - -sche (discuss) 00:38, 9 March 2014 (UTC)

Recent changes - format gone haywire[edit]

We now have <span class="minifont">Show new changes starting from 22:05, 11 March 2014 | Current number of entries: <b>3,688,346</b></span> being displayed. Anyone owning up? SemperBlotto (talk) 22:08, 11 March 2014 (UTC)

Looks like it was caused by Mediawiki:Rclistfrom being changed to be inside a link instead of containing it in this change, associated with the MW1.23wmf17 deployment. I suspect this was not intentional. --Yair rand (talk) 22:18, 11 March 2014 (UTC)
You still need to remove the bolding. DTLHS (talk) 22:20, 11 March 2014 (UTC)
And we've now lost the "number of entries". SemperBlotto (talk) 09:20, 12 March 2014 (UTC)
I've added it back. It is linked like the rest of the line, but that seems tolerable. - -sche (discuss) 19:45, 30 March 2014 (UTC)

Lua replacement for Langrev[edit]

What is the Lua replacement for Langrev? That is to say, if I know the canonical name of a language, what code tells me the language's code? (If I know the code, I can find the canonical name by typing {{#invoke:languages/templates|lookup|en|names}}. Usefully, this is subst:able. It would be great if the code that turned canonical names into codes were also subst:able.) - -sche (discuss) 01:09, 12 March 2014 (UTC)

There is a pair of functions for it in Module:languages, but they're still a bit unoptimised. There's also no way to use them from a template yet, although that could be fixed fairly easily by adding that to Module:languages/templates. The main obstacle in migrating right now is deciding which of the two functions to use. The first only returns the canonical name, so it can't be used to look up alternative names, but it does always give a single unique result. The second searches alternative names too, but could give more than one possible answer. Our {{langrev}} template is a bit of a hybrid between these... it returns some alternative names, but doesn't handle conflicts, it just uses whichever one had its name added first. —CodeCat 02:12, 12 March 2014 (UTC)

Can't add translations at urea[edit]

When I try, I get an error saying "Could not find translation table for 'nl:ureum'. Glosses should be unique". I suspect that it might be because of the subscripts in the gloss. —CodeCat 03:34, 13 March 2014 (UTC)

  • Yes. I removed the subscripts and could then add a German translation. (I would be surprised if the translations for the two senses were ever different). SemperBlotto (talk) 08:00, 13 March 2014 (UTC)

Old Church Slavonic transliteration[edit]

What module is responsible for the automatic transliteration of Old Church Slavonic (cu)? I wanted to tell it to transliterate Ѿ and ѿ as Otŭ and otŭ respectively, but there is no Module:cu-translit. This should probably be done for Old East Slavic (orv) as well. —Aɴɢʀ (talk) 19:00, 17 March 2014 (UTC)

You can look it up in Module:languages/data2. It's Module:Cyrs-Glag-translit. —CodeCat 19:04, 17 March 2014 (UTC)
(E/C) Module:Cyrs-Glag-translit. But before you do that, think about whether it is true in all cases. I would ideally transliterate it as ot or something to that effect. --WikiTiki89 19:06, 17 March 2014 (UTC)
If we really want to get fancy we can transliterate it oͭ. Does it have a conventional scholarly transliteration other than otŭ? Part of the point of automated transliterations is that they shouldn't be context-dependent. —Aɴɢʀ (talk) 19:27, 17 March 2014 (UTC)
But is otŭ a scholarly transliteration, or just a scholarly normalization? --WikiTiki89 21:45, 17 March 2014 (UTC)
What is the letter used for? —CodeCat 22:10, 17 March 2014 (UTC)
It is used as a sort of abbreviation of "от(ъ)", having a similar origin to German umlaut (ä, ö) and to Spanish/Portuguese tilde (ñ, ã, õ). I have only seen it representing the word отъ ‎(otŭ) and as the corresponding prefix, but it may have other uses. I don't read Old Slavic texts all that much. --WikiTiki89 22:19, 17 March 2014 (UTC)
Then whatever transliteration we choose, it should be obvious enough that it represents that word. —CodeCat 22:29, 17 March 2014 (UTC)
I've added it as Otŭ and otŭ for now; if we decide later to transcribe it differently, we can change it then. —Aɴɢʀ (talk) 00:08, 18 March 2014 (UTC)

Formatted Arabic on iPad is displayed with disconnected letters[edit]

iPad supports Arabic input and display but Wiktionary entries using formatted entries currently show right-to-left (as expected) but letters are not connected to each other, e.g. عربي looks like ع‌ر‌ب‌ي (added ZWNJ). By contrast, Persian looks okey. Not able to test right now, if somebody changes the fonts but I will check later, when I get to my iPad. --Anatoli (обсудить/вклад) 01:03, 20 March 2014 (UTC)

Can the iPad's browser show you the HTML source code of a webpage? --WikiTiki89 02:47, 20 March 2014 (UTC)
Yes, it can. I will check tonight. --Anatoli (обсудить/вклад) 03:06, 20 March 2014 (UTC)
It appears the latest versions of OS don't allow to view the source code. --Anatoli (обсудить/вклад) 20:49, 20 March 2014 (UTC)
It looks fine on my iPhone. Just to clarify the issue, do you see it incorrectly on this page or only on the entry itself? --WikiTiki89 21:18, 20 March 2014 (UTC)
Yeah, iPhone is fine. Any unformatted string like عربي looks fine (here and on the Internet) but when it's formatted with any template that uses MediaWiki:Common.css then it's disconnected. So, the previous attempts to fix something else broke the display for iPad (possibly Mac as well, which also use Safari browser). --Anatoli (обсудить/вклад) 22:46, 20 March 2014 (UTC)
How do the following look:
  1. عربي (my expectation: broken)
  2. عربي (my expectation: broken)
  3. عربي (my expectation: working)
  4. عربي (my expectation: broken)
  5. عربي (my expectation: no idea)
  6. عربي (my expectation: no idea)
--WikiTiki89 23:15, 20 March 2014 (UTC)
I see examples 1,2,4 and 5 in different fonts from examples 3 and 6. (OSX, Chrome) --Catsidhe (verba, facta) 00:24, 21 March 2014 (UTC)
(E./C.)@Wikitiki89. Thank you. Hope it's alright to have quite long delays on this discussion. I only use our family iPad at home. So, I will check when I can and post here. There are other issues with the latest version of Safari, like inability to search on page or no support for some media files.
@Catsidhe. Fonts are probably OK, as long as Arabic letters are not disconnected, like in my first post. --Anatoli (обсудить/вклад) 00:31, 21 March 2014 (UTC)
Actually, looking at it more closely, example 5 is a third font, which is different again from 3,6 and 1,2,4. They all look connected to me, but maybe the equivalent on your iPad doesn't have the correct ligatures. --Catsidhe (verba, facta) 00:48, 21 March 2014 (UTC)
I am well aware of the style differences. And actually, they should all be the same font except number 5. 3 and 6 should just be a smaller size. On the iPad, the sizes may or may not be normalized. BTW, these are not "ligatures", because you can have an infinite string of connected letters: ههههههههههههههههههههههههههههههههههههههههههههههههههههههههههه. Arabic does also have ligatures such as لا, but they are implemented differently from connected letters. --WikiTiki89 00:58, 21 March 2014 (UTC)
Context dependant joined forms, then. Taking #5 out of the equation, from what I see, the two fonts have different letter shapes. More the point, when I look at it through Developer Tools, it says that 1,2,4 are in Arial Unicode MS, where 3,6 are in Geeza Pro. This may be relevant when Anatoli has a chance to look at it on the problematic device. I've taken a screenshot, but can't for the life of me figure out how to put it up here. --Catsidhe (verba, facta) 01:17, 21 March 2014 (UTC)
I see all letters connected on Safari/iPad/iOS 5. Fonts and rendering vary on Safari/Mac OS X 10.9.2 (see screenshot).  Michael Z. 2014-03-21 01:00 z
Thanks. I needed to know if Safari/Mac is affected. @Mzajac What's the quick way to upload files to Wiktionary? --Anatoli (обсудить/вклад) 01:04, 21 March 2014 (UTC)
I just hit the Upload File link in the tools sidebar on this page, on the Mac. Haven’t tried it on the iPad. Michael Z. 2014-03-21 13:46 z
Upload them to the commons:Main Page. If you're on an iPad, there's even an app for that. --WikiTiki89 01:19, 21 March 2014 (UTC)
Thanks, I never tried. --Anatoli (обсудить/вклад) 01:40, 21 March 2014 (UTC)

Numbers 3, 5 and 6 look okey, the others are broken --Anatoli (обсудить/вклад) 13:19, 21 March 2014 (UTC)

Formatted Urdu is also disconnected. --Anatoli (обсудить/вклад) 13:22, 21 March 2014 (UTC)
Then we can rule out the fonts, because number 6 uses the same fonts as the CSS, but explicitly. Try these:
  1. عربي (my expectation: working)
  2. عربي (my expectation: working)
  3. عربي (my expectation: working)
  4. عربي (my expectation: no idea, particularly interested in this)
  5. عربي (my expectation: no idea, particularly interested in this)
  6. عربي (my expectation: no idea, particularly interested in this)
The latter three, which I am particularly interested in, test the CSS unicode-bidi property; I don't know much about it, but it is definitely related to how right-to-left languages are displayed, and is basically the only thing left in MediaWiki:Common.css that could possibly be causing this. --WikiTiki89 17:57, 21 March 2014 (UTC)
All 6 are working! --Anatoli (обсудить/вклад) 20:46, 21 March 2014 (UTC)
Then I'm stumped. It seems to be the "Arab" class itself that's causing the problem, and not the properties defined in it. --WikiTiki89 00:53, 22 March 2014 (UTC)
Thanks for trying, anyway. :) --Anatoli (обсудить/вклад) 01:46, 22 March 2014 (UTC)
It might still help if you could figure out how to view the HTML source. A secondary solution would be to fake-view the source code like this, which might also help. --WikiTiki89 06:06, 22 March 2014 (UTC)
Thanks. That worked, although the source the source looks messier than in other browsers and there's no search in the latest Safari on iPad:
<p><strong class="Arab headword" lang="ar" xml:lang="ar">عَرَبِي</strong> <a href="/wiki/Wiktionary:Arabic_transliteration" title="Wiktionary:Arabic transliteration" class="mw-redirect">•</a> (<span lang="" xml:lang="">ʿarabī</span>) <span class="gender"><abbr title="masculine gender">m</abbr></span>, <b><span class="Arab" lang="ar" xml:lang="ar">عَرَبِيَّة</span></b> (ʿarabíyya) <span class="gender"><abbr title="feminine gender">f</abbr></span>, <b><span class="Arab" lang="ar" xml:lang="ar">عَرَب</span></b> (ʿarab) <span class="gender"><abbr title="plural number">pl</abbr></span></p>
--Anatoli (обсудить/вклад) 07:11, 22 March 2014 (UTC)

Lua Regex[edit]

I was wondering if anyone knows whether there is any access to a proper regex in our Scribunto. My research points to no, but I thought I'd check. -Atelaes λάλει ἐμοί 05:21, 20 March 2014 (UTC)

What do you need to do that can't be done with Lua patterns? --WikiTiki89 05:22, 20 March 2014 (UTC)
"Or" and "And" that can be applied to groups of characters. -Atelaes λάλει ἐμοί 08:31, 20 March 2014 (UTC)

CirrusSearch[edit]

I see that the Italian Wiktionary now uses CirrusSearch instead of the old LuceneSearch. Are we planning on doing the same? SemperBlotto (talk) 08:34, 20 March 2014 (UTC)

We have it as a beta feature. Keφr 09:26, 20 March 2014 (UTC)
It is outstanding. Is it past beta now? DCDuring TALK 15:19, 11 November 2014 (UTC)
Apparently, yes. Keφr 18:00, 11 November 2014 (UTC)

Template:en-plural noun[edit]

Appears to unintentionally bold "plural" when a term is formatted to be both countable and uncountable. See Mallwart for a current example. -Cloudcuckoolander (talk) 21:51, 21 March 2014 (UTC)

Did you mean {{en-proper noun}}? Fixed. Keφr 07:25, 22 March 2014 (UTC)
Yes, sorry. Thanks for taking care of the issue. -Cloudcuckoolander (talk) 11:35, 24 March 2014 (UTC)

Linking Pages Between Languages[edit]

I created a page for the Spanish word "bizquear" in the English Wiktionary (https://en.wiktionary.org/wiki/bizquear), and when I was searching for etymological information, I found out that there already existed a page in the Spanish, Polish, Malagasy, Dutch, and Mandarin Chinese Wiktionaries (https://es.wiktionary.org/wiki/bizquear). The page that I created was not automatically linked to the already existing pages (it doesn't not say English on the left column of them, and on mine it doesn't have the other languages). How can I link the entries? Is there a way to automatically search through all language Wiktionaries to find out of there is an entry in another language?

I think you're looking for Help:Interwiki linking. There should be a bot that handles this automatically (eventually). Equinox 21:34, 22 March 2014 (UTC)
I think there are several bots that do occasional runs; after a week or so the links would have been added by bot. But better yet, interwiki links should be handled automatically by Wikidata, as they are at Wikipedia. —Aɴɢʀ (talk) 16:57, 23 March 2014 (UTC)
My impression, based on numerous threads on wikidata:Wikidata talk:Wiktionary, is that the Wikidata-ers are not only not interested in handling Wiktionary's interwiki links, but are interested in not handling Wiktionary's interwiki links. Some Wikidata-ers periodically express an interest in creating elaborate systems to transclude definitions into multiple entries and such, and then people shoot those plans full of holes because words are almost never exactly synonymous across languages. But interwiki linking of en:diede:die, etc, which is the one thing Wikidata already possesses the technical capacity to do, and which is the one thing the majority of the Wiktionarians who've commented on that page have said they want, seems to be one thing Wikidata-ers aren't going to implement.
Please, chime in: wikidata:Wikidata talk:Wiktionary#Moving_inter-Wiktionary_links_to_Wikidata.2C_redux.
- -sche (discuss) 18:44, 23 March 2014 (UTC)

Bokmål/Nynorsk regional labels[edit]

Moved from Wiktionary talk:Votes/pl-2014-03/Unified Norwegian Is it possible to categorise Norwegian by Category:Norwegian Bokmål and Category:Norwegian Nynorsk by changing Module:labels/data. I have tried but the effect wasn't as desired, I was getting "Norwegian Bokmål Norwegian".

Test phrasebook entries with labels {{cx|Bokmål|lang=no}} and {{cx|Nynorsk|lang=no}}:

  1. jeg elsker deg/eg elskar deg
  2. jeg vet ikke/eg veit ikkje

--Anatoli (обсудить/вклад) 06:41, 25 March 2014 (UTC)

You should move this discussion to the Grease Pit, this has nothing to do with the vote. --WikiTiki89 06:44, 25 March 2014 (UTC)
It's a bit counter-intuitive; as you've now noticed, you have to use "plain_categories" ... it did take me a while to figure that out, back when I was trying to add an Oxford British spelling label. (What threw me off what that it says plain_categories "does not support language-specific categories". I think I'll try to clarify that documentation a bit...) - -sche (discuss) 06:49, 25 March 2014 (UTC)
Thanks for fixing it! --Anatoli (обсудить/вклад) 06:52, 25 March 2014 (UTC)
I do think that we should only use these labels if specific senses are used only in Bokmål/Nynorsk, not if the word as a whole is. —CodeCat 13:25, 25 March 2014 (UTC)
Why is that? --WikiTiki89 16:34, 25 March 2014 (UTC)
Because that's what context labels are for. They're for labelling senses. It hardly seems practical if we have to label all 10 senses of some word with the same "Bokmål" label. —CodeCat 18:21, 25 March 2014 (UTC)
@CodeCat. I don't see how we then can use the unified approach. The readers will assume that words are both Bokmål and Nynorsk. An additional parameter in the header would help. --Anatoli (обсудить/вклад) 21:49, 25 March 2014 (UTC)
I have nothing against putting a label in the headword line. In fact, I wonder if we shouldn't start doing that for more words generally. It would solve the problem we've had in the past of distinguishing archaic terms from terms with archaic senses, and other similar issues. If we assume that context labels always indicate sense-specific things, and the headword line is used to cover the term as a whole, then there is no ambiguity anymore. —CodeCat 21:54, 25 March 2014 (UTC)
I think we don't need a vote for putting a label in the headword line, since "Norwegian" ("no") is allowed. The parameter for the other form, e.g. Nynorsk on a Bokmål header would be useful. There's nothing new here, there's Cyrillic on Roman Serbo-Croatian, traditional on a simplified Chinese entry. I'm neutral on your other general suggestion. --Anatoli (обсудить/вклад) 22:26, 25 March 2014 (UTC)
The two Norwegian standards don't differ by script, so there may be terms where the basic form is the same in both standards, but they may have different inflected forms (I think genders too). Trying to put all that in one headword line would make it too cramped, so I propose that, if a term occurs in both standards with the same meaning, we show two headword lines: Bokmål first, then Nynorsk right below it. Something like this:
dag m ‎(Bokmål, inflections go here...)
dag m ‎(Nynorsk, inflections go here...)
How is that? —CodeCat 22:48, 25 March 2014 (UTC)
This looks OK to me but I don't know if autoformat will allow that (two header lines). What about words without inflected form, which are shared? Could we have "both" parameter or smth to show they are applicable to both Bokmål and Nynorsk to avoid two lines? --Anatoli (обсудить/вклад) 23:01, 25 March 2014 (UTC)
There isn't a reason why a single template couldn't display both headword lines. So both lines above could be displayed by a single call to {{no-noun}} (once we modify it). The parameters might get a little confusing, though, if we want to use numbered parameters. You might end up with something like {{no-noun|both|Bokmål gender|Nynorsk gender|Bokmål plural|Nynorsk plural|...}}. So we may want to use named parameters instead like: {{no-noun|both|g-nb=|g-nn=|pl-nb=|pl-nn=}}. Here, only the first numbered parameter does anything. Alternatively, we could use numbered parameters for Bokmål and additional named ones for Nynorsk. That's POV of course, but it's ok to be POV in template parameters. :) —CodeCat 23:10, 25 March 2014 (UTC)
Perhaps you need to make a few samples with various situations for people to see. I don't have a problem with your suggestion. --Anatoli (обсудить/вклад) 23:21, 25 March 2014 (UTC)
I'm not sure what else to show. Does my example not get the point across well? —CodeCat 23:23, 25 March 2014 (UTC)
Actually it does. I just think there will be many 100% identical forms, for which we won't need two lines - adverbs, proper nouns (same gender), numerals, preposition, etc. or when the variety is unknown, default to just "Norwegian" with a one-line header. --Anatoli (обсудить/вклад) 23:42, 25 March 2014 (UTC)

{{rfv-etymology}}[edit]

Please replace the current code with the following: {{#switch:{{NAMESPACE}}|<!--Main-->|Appendix|Template|Transwiki={{maintenance line|1=<span id="rfv-etymology-notice-{{{lang|}}}-{{{topic|}}}"/>Can [[Wiktionary:Etymology scriptorium#{{{fragment|{{{section|{{PAGENAME}}}}}}}}|this]]<!-- + Link --><sup class="plainlinks">([{{fullurl:Wiktionary:Etymology scriptorium/{{CURRENTYEAR}}/{{CURRENTMONTHNAME}}|action=edit&section=new&preload=Template:rfv-etymology/preload&preloadtitle=%5B%5B{{urlencode:{{FULLPAGENAME}}}}%23rfv-etymology-notice-{{{lang|}}}-{{{topic|}}}%7c{{urlencode:{{FULLPAGENAME}}}}%5D%5D}} +])</sup><!-- --> etymology be [[Wiktionary:References#Etymologies|sourced]]?}}}}</span><includeonly>{{#ifeq:{{NAMESPACE}}||{{#if:{{{lang|}}}|[[Category:Requests for etymology ({{#invoke:languages/templates|lookup|{{{lang}}}|names}})|{{{sort|{{PAGENAME}}}}}]]|[[Category:Requests for etymology|{{{sort|{{PAGENAME}}}}}]]}}}}</includeonly><!-- --><noinclude>{{documentation}}</noinclude>

--kc_kennylau (talk) 23:34, 25 March 2014 (UTC)

I strongly oppose. This would point to the wrong month when the next month starts. --WikiTiki89 23:38, 25 March 2014 (UTC)
@Wikitiki89 No, the edited area only affects the "plus" sign which should point to the current month. --kc_kennylau (talk) 08:54, 26 March 2014 (UTC)
Yes check.svg Done In the future please explain what the change does rather than just simply pasting a bunch of code. --WikiTiki89 09:03, 26 March 2014 (UTC)

A new Template:context-like template for use on the headword line[edit]

I think CodeCat is on to something when she observes above that "putting a label in the headword line [...] would [also] solve the problem we've had in the past of distinguishing archaic terms from terms with archaic senses". In particular, it seems to me that if we created a new {{context}}-like template for use on headword lines, and had it put entries into a different set of categories than sense-line {{context}} (perhaps by expanding Module:labels/data so that it knew which category to use when a label was used in {{context}}, and which to use when the label was used in the headword-context template), that would solve the problem. Then

==English==
===Noun===
{{en-noun}} {{headword-line-context-template|archaic}}
# A foobar.

could put entries into [[Category:English archaic terms]], while

==English==
===Noun===
{{en-noun}} 
# {{context|archaic}} A foobar. {{defdate|until the 18th century}}
# A whatsit. {{defdate|since the 17th century}}

could put entries into [[Category:English terms with archaic senses]]. And we could always make some categories the same in certain cases; for example, we could decide that both American spellings like academize and terms with senses specific to American English should go into [[Category:American English]] or not; this is just an example.
What do you think of this idea? What could the headword-line-context-template be called? - -sche (discuss) 00:53, 26 March 2014 (UTC)

I'm wondering if headword lines wouldn't become too long if we do it like this. We may want to consider placing them on the next line, but indented in some way?
As for implementation, we would have to look closely at which labels we use for which. There are probably labels that don't make much sense when generalised across a whole term, or vice versa. There is also the danger that if at some point we have an entry with a term-level label, someone may add a new sense for which the label doesn't apply, and forget to fix it. —CodeCat 01:43, 26 March 2014 (UTC)
Don't you think we'd be better off calling it {{template-used-similarly-to-context-templates-but-designed-specifically-for-the-headword-line}}? --WikiTiki89 05:12, 26 March 2014 (UTC)
What do you mean? —CodeCat 17:57, 28 March 2014 (UTC)
@CodeCat I was making a joke about what -sche called the template in the example above. --WikiTiki89 18:56, 28 March 2014 (UTC)
No, that would be too cryptic. How about {{template-designed-to-be-used-in-the-headword-line-specifying-context-in-which-the-word-is-used-also-please-remember-to-remove-it-when-a-sense-to-which-it-does-not-apply-is-added}}? Keφr 18:05, 28 March 2014 (UTC)
Um, ok? —CodeCat 18:12, 28 March 2014 (UTC)
How about {{head-context}}? Whatever we call it, I suggest {{hc}} as a shortcut, in the manner of {{cx}}. Is anyone interested in designing it? With my limited coding skills, I could copy the contents of {{context}} to {{head-context}} and modify it to call on a separate set of label-to-category correspondences stored in e.g. Module:labels/data/2, but I think it would be more elegant and simpler to update (add/remove labels, change categories, etc) if {{context}} and {{head-context}} both stored their label-to-category correspondences in Module:labels/data. I think that requires modifying Module:labels/data to have two sets of category values, perhaps called "sense_plain_categories" and "head_plain_categories" (or plain_category_correspondence_­for_the_template_­designed_to_be_used_­in_the_headword_line_­specifying_context_­in_which_the_word_is_used_­but_please_remember_to_remove_it_­when_adding_a_sense_­to_which_it_does_not_apply), and then modifying {{context}} to know that it calls the sense-line categories, while {{head-context}} calls the headword-line categories. - -sche (discuss) 18:42, 28 March 2014 (UTC)
That sounds fine. --WikiTiki89 18:56, 28 March 2014 (UTC)
What about something that matches {{label}} instead? —CodeCat 18:57, 28 March 2014 (UTC)
Created at {{head-label}}, with syntax identical to {{label}}; categories are pulled from keys suffixed with _head; they fall back to unsuffixed keys. Keφr 18:59, 28 March 2014 (UTC)
Way too premature. We haven't even decided how to name it yet, let alone how it's going to work. —CodeCat 19:10, 28 March 2014 (UTC)
Not only that, his edit broke Module:labels. This is a really, really bad way to make changes to modules that are depended on by hundreds of thousands or even millions of entries. Chuck Entz (talk) 19:22, 28 March 2014 (UTC)
I think that rather than having {{context}} and {{head-context}}, we should use {{sense-context}}/{{sense-label}} (the original) and {{term-context}}/{{term-label}} (the new one). That is, we name the templates after their purpose rather than after the place they go. Renaming the old template would also make it clearer. We can keep {{context}}, {{cx}} and {{label}} around as redirects, and we could probably create new ones too like {{scx}} and {{tcx}} if we want. —CodeCat 19:25, 28 March 2014 (UTC)
Actually, if we're going to rename them anyway, I propose we get rid of the old name "context" altogether and use "label" exclusively, along with its parameter format (1st parameter is language code). —CodeCat 19:27, 28 March 2014 (UTC)
Yes, I like the idea of a {{scx}}{{sense-context}} (and/or {{slb}}/{{slbl}}{{sense-label}}), {{tcx}}{{term-context}} (and/or {{tlb}}/{{tlbl}}{{term-label}}) parallel naming scheme. The question of whether the language code should be the first parameter or set by lang= is a separate question, which means that for now, if someone creates {{sense-context}} it should mimic {{context}}, and/or if someone creates {{sense-label}} it should mimic {{label}}, IMO. - -sche (discuss) 21:09, 28 March 2014 (UTC)
A lot of people will complain. We can have the old {{context}} templates redirect to the new {{sense-context}} templates. --WikiTiki89 22:38, 28 March 2014 (UTC)
We can keep the original name around as a redirect, but we should convert existing entries to use the new names. —CodeCat 22:50, 28 March 2014 (UTC)
(@Wikitiki:) Yes, of course {{context}} and {{cx}} should still work (as redirects). - -sche (discuss) 04:32, 29 March 2014 (UTC)
(@CodeCat:) We should be aware that some entries currently use {{context}} on the headword line (where we ultimately want {{tcx}}), and others use it in translations tables (where we want {{qualifier}}). I am cleaning up some of those misuses with AWB, by temporarily redirecting {{tcx}} to {{context}} [sic] and changing headword-line instances of {{context}} to {{tcx}}. My intention is that what the entries display and how they categories is not changed at this time, but they will all update automatically (as the job queue gets to them) once we create {{term-context}} and re-redirect {{tcx}} to it. - -sche (discuss) 06:24, 29 March 2014 (UTC)
A number of headword-line instances of {{context}} which I updated to {{tcx}} were instances of the template being used to impart transitivity or reflexivity information about Italian verbs. Reflexivity probably is an "all-term" (headword-line-worthy) feature, just like {{tcx|American spelling}}, but transitivity information should perhaps be moved en masse to the sense line at some point. - -sche (discuss) 03:20, 4 April 2014 (UTC)
Until Module:labels can be expanded to handle and distinguish sense-line ("sense-only") and headword-line ("all-term") templates and labels, I have set {{term-context}} (shortcut: {{tcx}}) to use Module:labels2, as I suggested above. You can now see it in action on a number of pages, like [[center of gravity]] and [[adrad]], as well as [[不著調]] and [[abolisht]]. Thinking about that last one: should we create a dedicated form of template à la {{obsolete spelling of}} for obsolete past tense forms, and third-person singular present tense forms, of verbs? - -sche (discuss) 03:20, 4 April 2014 (UTC)
It is already quite obvious that Module:labels can be expanded; we just have not agreed on how to do it. Whatever happened to entia non sunt multiplicanda præter necessitatem? Keφr 05:25, 4 April 2014 (UTC)
Now that I think about it: since the pattern for these categories seems to be "Legalese terms with X senses" vs "Legalese X terms", why not store only "X" in the data page? Keφr 06:24, 4 April 2014 (UTC)

selecting targeted languages[edit]

"selecting targeted languages" no longer works in my "Vector" skin - is it something I've done - does the new Beta option interfere? Saltmarsh (talk) 07:16, 26 March 2014 (UTC)

It’s working for me, but the icons that used to appear next to the language names are invisible. — Ungoliant (falai) 07:44, 26 March 2014 (UTC)
Well my previously selected languages no longer appeared in the table heading - and while the cursor changes to indicate something is where the icons should be, clicking seems to have no effect. Saltmarsh (talk) 14:29, 26 March 2014 (UTC)
Fixed (I think). --Yair rand (talk) 15:31, 26 March 2014 (UTC)
Working well - thanks Saltmarsh (talk) 18:51, 26 March 2014 (UTC)

Bot account needed for manual "form of" creation with AWB?[edit]

This is the AWB plugin that I'd like to use w:Wikipedia:CSVLoader/Walkthrough with CSV files that look like this User talk:Neitrāls vārds/CSV.

Wikipedia says that you need a bot account only in autosave mode (not when when you are manually clicking "save" or "skip") but it doesn't appear to be doing anything it just says "reattempting in 20 seconds," giving the impression that it's not allowed the privilege of creating a new page. So on Wiktionary you need a bot account for new page creation with AWB in all cases, is that right?

(Actually I did want a bot flagged account because even if I did it manually, in larger quantities recent changes would be seriously flooded.) Neitrāls vārds (talk) 09:21, 26 March 2014 (UTC)

I had the path to article wrong (in that it wasn't even supposed to be a path but just the new article's name) didn't quite solve the "reattempting" message but after playing with it some more something did (I'm not even sure what.) So, in manual mode you do can create new entries.
Sadly it appears to be forcing upper case (Wikipedia-style) to any newly created entries so for the time being I'm stuck with country and town names (although I do have quite a few of those.) I'll try to ask the plugin's author if he can make the pre-upper case version downloadable. Neitrāls vārds (talk) 11:09, 26 March 2014 (UTC)

Problem with display of Russian verb conjugations[edit]

Today we noticed that it is not possible to see the conjugations of Russian verbs in Wiktionary. Normally, a 'show' button appears, and you can click on that to see the full conjugations. However, the show button does not appear, and you cannot see the conjugations. This is in Safari, Firefox, and Google Chrome. It seems there must be a server problem. I use this with my students on a daily basis so if there is a way to fix it, that would be great! —This unsigned comment was added by Brooke2 (talkcontribs).

  • Works OK for me (Google Chrome) but I often have to scroll sideways to see it all. SemperBlotto (talk) 12:34, 28 March 2014 (UTC)


It still does not work for me in Safari, Chrome or Firefox. It worked on a couple of words, but most of the words have lost their link to declensions and conjugations. This is a huge problem for anyone studying Russian. My students use this function every day to look up conjugations of words. How do we ask someone to turn this function back on? It is very strange that is coming and going. (If you go to the right, there is no 'show' button as there used to be.) —This unsigned comment was added by Brooke2 (talkcontribs).

Fundamentally this is a problem with en.Wiktionary choosing to not use Mediawiki's default mw-collapsible mw-collapsed element classes. This project developed its own solutions before the rest of Mediawiki did (<1.18). Perhaps you can convince the local templaters to update, but it is a very large task you would be asking them to accomplish. - Amgine/ t·e 17:04, 28 March 2014 (UTC)
I agree it would be better if we used the standard method instead of our own. A major problem with our current solution is that it involves putting a table inside a div. This makes it impossible to scale the table according to its contents; all tables have to have a fixed width. The standard solution doesn't have this limitation as far as I know. —CodeCat 17:59, 28 March 2014 (UTC)

So what is the solution? This is a huge problem for people who have become dependent on Wiktionary as the source for Russian verb conjugations and declensions, and it is a huge loss of information. It was working fine just last week. —This unsigned comment was added by 96.4.165.223 (talk).

Fixed already. Clear your cache and see: купить ‎(kupitʹ). It was my careless coding while working on Wiktionary:Preferences/V2 which caused it. Keφr 18:36, 28 March 2014 (UTC)
Actually, not. The local collapsible solution does not work in several browsers depending on the additional security applied. (This is only a small reason why it should be replaced. The bigger reasons are standardization and maintenance.) - Amgine/ t·e 22:52, 28 March 2014 (UTC)
Collapsibles hide only when JavaScript is allowed to be run on Wiktionary. The button to uncollapse them is set up by MediaWiki:Common.js. What kind of schizophrenic security settings cause that? Keφr 06:42, 29 March 2014 (UTC)
If js were not running on Wiktionary, neither collapsible table would be collapsed. The mw-collapsible table also has a visible Expand button, while the Wiktionary collapsible does not. This is a fairly vanilla install of Tor Browser Bundle, better known as FireFox using Tor with maximum privacy settings except js enabled. - Amgine/ t·e 18:11, 29 March 2014 (UTC)

Thank you! I will not pretend to understand the issues with standardization and maintenance, but all of the words that did not work for me this morning do work now. Thank you SO much!!! —This unsigned comment was added by 75.64.165.216 (talk).

Template:context or Template:label?[edit]

Currently, we have two different templates for the same thing. The only difference is in the language parameter: {{context|label1|label2|lang=code}}, {{label|code|label1|label2}}. In the discussion about term-level context labels above, it wasn't really clear which of the two we should standardise on. So I'd like to ask about this now. This shouldn't depend on the outcome of the discussion above, so even if the proposal of using separate term-wide labels fails, this should still be considered on its own. But I do think we should decide this before carrying out that proposal, because otherwise it will cause a wide proliferation of label templates, we'd need at least 4 of them to cover all possibilities. —CodeCat 17:29, 29 March 2014 (UTC)

Use {{label}}. Quicker to type, even when compared to {{cx}}, and still descriptive, especially when compared to {{cx}}.
On a related note, when can we start deleting orphaned context label templates? Do we have to run it through the bureaucracy? Keφr 17:58, 29 March 2014 (UTC)
Um... you can delete them right now if you want to. I have been doing it for a while, off and on. There's just so many and it's not easy to automate it because not all of them are orphaned yet. There are still a lot of redirects among them that need to be converted into aliases in the data module.
As for being quicker to type, {{label}} also has the shortcuts {{lb}} and {{lbl}}. —CodeCat 18:04, 29 March 2014 (UTC)
Don't delete the regional context labels, unless you successfully amend template:eye dialect of and template:alternative spelling of, which use them, to do what they do by some other means. Thanks! (Pinging user:Kephir and user:CodeCat, since this is a late reply.)​—msh210 (talk) 06:16, 7 April 2014 (UTC)
{{whatever|code|label1|label2}} is obviously better than {{whatever|label1|label2|lang=code}}, and "label" is not a bad title, so {{label}} looks better. I don't like the shortcuts for {{label}}, "lb" reminds of something else, and "lbl" is just 2 letters shorter, let's keep it descriptive. --Z 18:46, 29 March 2014 (UTC)
Well, some editors (you know who I mean) whine about even one or two letters... —CodeCat 18:49, 29 March 2014 (UTC)

Module:labels/data again[edit]

I've made an innocent edit and got suddenly errors on line 1662. Who can fix it? Ignatus (talk) 18:42, 30 March 2014 (UTC)

It's not your fault. We have a certain clumsy editor who likes making changes without previewing the code, and who may be blocked if he continues to do so (let's hope he takes the hint). --WikiTiki89 19:22, 30 March 2014 (UTC)
In this case I don't think we can blame him. He's migrating over the remainder of our context labels, and occasionally a typo may slip through. To ask him to preview every single edit is going to frustrate it... —CodeCat 03:07, 31 March 2014 (UTC)

For editors only CSS[edit]

I seem to recall that some time ago someone had proposed a CSS class which only displayed to folks who opted in or only displayed in editing/preview mode. The idea was for notes, error messages and the like to be displayed to editors, but not to readers. Has something like this been implemented yet? If not, would someone be willing to craft it? My CSS is rubbish. -Atelaes λάλει ἐμοί 02:58, 31 March 2014 (UTC)

There have been a few small things like this already, but nothing that covers all mistakes. —CodeCat 03:05, 31 March 2014 (UTC)
Huh? Covers all mistakes? -Atelaes λάλει ἐμοί 03:10, 31 March 2014 (UTC)
Well, you're talking about a single CSS class. So presumably that single class would cover the display of all mistakes/problems in entries. Right now, the few classes we have for that purpose are targeted towards individual types of problems, like "foreign words lacking a language code". —CodeCat 03:25, 31 March 2014 (UTC)
The body element on every page has a class action-something, e.g. view, edit, or submit, matching the action in the query part of the URL. Thus you can style a box with some class, say editing, and use CSS like .action-view .editing {display:none}. (And JavaScript can be used to show it even on action=view but only to certain users (e.g., logged in, autoconfirmed, or admin), which IIRC is what we do with the "News for editors" link atop each page.) Note, though, that including something in a page and using CSS to hide it is poor Web design: better (for us, who can't control the server) would be to generate the box using JS only for such users as should see it.​—msh210 (talk) 06:13, 7 April 2014 (UTC)

A problem with Template:circumfix[edit]

Hello all. Please note this discussion between CodeCat and me, which I have copied from Thread:User talk:CodeCat/A problem with Template:circumfix:

Hi CodeCat. Currently, when {{circumfix}} is used, it generates three links, one for the circumfixed antecedent term, and one each for the preceding and following parts of the circumfix; this results in links to pages that may be utterly irrelevant or even non-existent. Take the example of the Georgian word უბრალო ‎(ubralo), in the entry for which {{circumfix|უ- -ო|უ|ბრალი|ო|lang=ka}} currently displays this:
*უ- (*u-) doesn't exist and -ო ‎(-o) contains nothing relevant; both the links on either side of ბრალი ‎(brali) should link to უ- -ო ‎(u- -o). {{circumfix|უ- -ო|უ|ბრალი|ო|lang=ka}} should display this:
Unless I'm missing something, all that should be necessary is to pipe the links for the first and third terms, so that they link to the proper page, for the circumfix. Would you be able and willing to edit {{circumfix}} to correct this bug, please? Thanks for your time.
 — I.S.M.E.T.A. 02:46, 31 March 2014 (UTC)
The template already has alt1= and alt3= parameters. What should be done with those?
CodeCat 02:48, 31 March 2014 (UTC)
I don't suppose that's a problem, or is it? They just change what's displayed, rather than the link, right?
 — I.S.M.E.T.A. 03:06, 31 March 2014 (UTC)
Currently, the template takes four main parameters: the circumfix itself, the first part, the middle word, and the second part. On top of that, it takes alt1, alt2 and alt3 parameters to override the display of each part. If I change the template so that it uses the first parameter to figure out what to link to, then the 2nd and 4th parameters only really change the display, and alt1 and alt3 parameters don't really have a distinct use anymore.
CodeCat 03:11, 31 March 2014 (UTC)
Oh, I see. So, should we get rid of them? I suppose before we do, we'd need to fix any current uses of them. Is there a way to find out which entries, if any, use either or both of these alt1 and alt3 parameters?
 — I.S.M.E.T.A. 03:16, 31 March 2014 (UTC)
What I'm more curious about is why there is that first parameter to begin with. It seems redundant to the 2nd and 4th, which could presumably be used to reconstruct the "whole" circumfix from its two parts.
But since this is a rather specific template that not many languages need, I can't really judge the merit of how it was made to work. Maybe you should ask at the GP, so that those who actually work with this template can explain.
CodeCat 03:19, 31 March 2014 (UTC)
My guess is that the first parameter is necessary for autogenerating the category name, which mentions the circumfix. I'll get to posting in the Grease Pit now.
 — I.S.M.E.T.A. 03:51, 31 March 2014 (UTC)

Is there some benefit to the current set-up that I'm not seeing? And if not, are there any objections to making the change I've described? — I.S.M.E.T.A. 03:53, 31 March 2014 (UTC)

I remembered this template as counterintuitive and hard to use when I created ketuanan. There's a redundant parameter 1, and strangely it doesn't link to it (the circumfix page), only to the prefix and suffix pages. Wyang (talk) 04:33, 31 March 2014 (UTC)
@Wyang: Do you believe that this (the linking "to the prefix and suffix pages") should be changed? — I.S.M.E.T.A. 05:03, 31 March 2014 (UTC)
Yes. Wyang (talk) 05:04, 31 March 2014 (UTC)
Template:circumfix is named and creates categories as if it were designed to be used when a circumfix has been applied to a word, but it creates links in a way that suggests it was designed to be used when a prefix and a suffix have simultaneously been applied to a word (which is properly the domain of Template:confix, I think). It's a strange template and I agree it needs to be cleaned up. - -sche (discuss) 05:36, 31 March 2014 (UTC)
Yes, AFAICT, except for categorising, {{circumfix}} and {{confix}} are virtually identical. It seems that there is general agreement in favour of making this change. Before we do that, is there anyone I should ping to chip in? — I.S.M.E.T.A. 01:24, 1 April 2014 (UTC)
Apparently not. - -sche (discuss) 03:31, 4 April 2014 (UTC)
First, we'd need to make sure that any cases where the first parameter does not equal what we intend to make it into, are tracked down and fixed. I know there are a few where the two parts are shown as a--b with no space between. —CodeCat 20:24, 8 April 2014 (UTC)
Ok, here is a list of entries where there is a mismatch. The category for these entries should presumably be renamed, to have a space between the two hyphens. abatatar, anoratana, isoratana, ividiana, keadaan, kejohanan, ketuanan, mengenai, pengovuman, perempuan, مڠناءي, ڤرمڤوان, ڤڠوۏومن. —CodeCat 20:53, 8 April 2014 (UTC)

"eye dialect" script errors[edit]

Can anyone figure out and fix whatever it is that has suddenly put dozens of entries with "{{context|eye dialect" in Category:Pages with script errors? Chuck Entz (talk) 23:38, 31 March 2014 (UTC)

This is one of the problems with the "old" context labels. Remember how we would always run into problems when labels conflicted with existing templates? Well that's what's happening here too. The context templates actually get transcluded by {{context}} to see if they are valid. But now that we have Lua, the template {{eye dialect}} triggers a script error when it's transcluded with the wrong parameters. And there you go... Luckily Kephir is working on deleting the last few remaining context templates, and then we can remove the transclusion code from the module. —CodeCat 00:04, 1 April 2014 (UTC)
Wait, what? Deleting regional context templates? How then will {{eye dialect of}} and {{alternative spelling of}} use the from parameters?​—msh210 (talk) 06:04, 7 April 2014 (UTC)
That would be part of fixing {{context labelcat}}, which we haven't done yet. But it hasn't been a high priority because it's not used that much. —CodeCat 12:51, 7 April 2014 (UTC)
Yeah... so we can't delete regional context templates at this point.—msh210℠ on a public computer 22:03, 7 April 2014 (UTC)
(In case this wasn't known,) there are some other templates besides alternative spelling of which take from= parameters in (apparently) the same way as alternative spelling of, such as {{standard spelling of}}. - -sche (discuss) 22:29, 7 April 2014 (UTC)
To expand on what CodeCat said: Template:eye dialect was (and is) a redirect to Template:eye dialect of, so when {{context}} looked there, it found something that wasn't a context label ... and Module:labels/data apparently did not contain "eye dialect" until I added it just now(?!), so when {{context}} looked there, it likewise did not find "eye dialect" to be a context label. But why that didn't cause script errors until now, I don't know. A separate issue is that some (and possibly all) uses of {{context|eye dialect}} should really be {{eye dialect of}}. I am looking over such uses now. - -sche (discuss) 00:13, 1 April 2014 (UTC)
I made some changes to {{eye dialect of}} recently, that would probably be it. There's nothing wrong with the template, it's {{context}} that's the problem. —CodeCat 00:18, 1 April 2014 (UTC)
The transclusion fallback can be deleted already. There are still some transclusions of context labels, but none are coming from Module:labels. And thanks User:Msh210 for mentioning {{eye dialect of}} and {{alternative spelling of}}, because I too have been wondering about these. Keφr 06:20, 7 April 2014 (UTC)
I wonder why these templates use context labels in the first place. It seems a bit like misuse to me. —CodeCat 23:38, 7 April 2014 (UTC)
Because regional context templates were created to match a list of regions whose dialects we consider, and that's a good match for these templates.​—msh210 (talk) 02:39, 8 April 2014 (UTC)
What's wrong with {{cx|region}} {{eye dialect of|word}}? --WikiTiki89 23:45, 7 April 2014 (UTC)
That'd indicate the spelling is used in that region. {{eye dialect of|word|from=region}} means the spelling represents the dialect of that region.​—msh210 (talk) 02:39, 8 April 2014 (UTC)
Then I don't see how context labels are going to be of any use there. All the regional labels we have are used to categorise terms used in specific dialects, not terms that imitate dialectal speech. We don't want a term used to imitate Scots to appear in Category:Scottish English. —CodeCat 02:55, 8 April 2014 (UTC)
(Even if not, we do want to use the regional context templates in {{standard spelling of}} and {{alternative spelling of}}. But) I think we do wish to so categorize eye-dialect entries. Massa is currently defined as "Eye dialect spelling of master, representing African American Vernacular English". In other words, the term is used by writers who write in any dialect, but in quoted speech where the speaker speaks AAVE (or pretends to). The quoted speech thus transcribed is indeed AAVE, so I think it makes sense to so categorize it.​—msh210 (talk) 05:24, 8 April 2014 (UTC)
So the kinds of things that white performers used to say in blackface are supposed to be categorized as AAVE? Pray tell, what dialect of "Injun" should we use to categorize "me smoke'um peace pipe"? Chuck Entz (talk) 06:07, 8 April 2014 (UTC)
I was thinking more of speech by AAVE-speaking characters in novels written by non-AAVE-speaking people. Do you not think they should be AAVE-categorized? Do you also think British speech in a novel by an American should not be British-categorized?​—msh210 (talk) 17:39, 8 April 2014 (UTC)
Something that is not attestable by an actual British speaker should not be treated as British. So if an American writer writes something in imitation of British speech, then that should not count as an attestation for British English usage. I mean, if I say some random jibberish and call it Hindi, that doesn't make it attestable Hindi. —CodeCat 17:47, 8 April 2014 (UTC)
Right, that's why we'd use # {{eye dialect of|foo|from=Wherever}} and not # {{context|Wherever}} [[foo]]. But I don't see anything wrong with categorizing it as Wherever. I recommend this be a BP discussion: whether to categorize eye dialect as the dialect. If not, {{eye dialect of}} can be emended.​—msh210 (talk) 03:47, 9 April 2014 (UTC)