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? DCDuringTALK01:41, 3 March 2014 (UTC)[reply]
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:
Comments at the proposal's talk section. Don't be shy! Ask what you want to know. Comment about what you concerns. No activity means no one is interested.
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.
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)[reply]
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)[reply]
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. —CodeCat02:12, 12 March 2014 (UTC)[reply]
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. —CodeCat03:34, 13 March 2014 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. --WikiTiki8922:19, 17 March 2014 (UTC)[reply]
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)[reply]
Formatted Arabic on iPad is displayed with disconnected lettersedit
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)[reply]
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? --WikiTiki8921:18, 20 March 2014 (UTC)[reply]
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)[reply]
(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.
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)[reply]
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. --WikiTiki8900:58, 21 March 2014 (UTC)[reply]
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)[reply]
I see all letters connected on Safari/iPad/iOS 5. Fonts and rendering vary on Safari/Mac OS X 10.9.2 (see screenshot).Screen shot of https://en.wiktionary.org/wiki/عربي—MichaelZ. 2014-03-21 01:00 z
Then we can rule out the fonts, because number 6 uses the same fonts as the CSS, but explicitly. Try these:
عربي (my expectation: working)
عربي (my expectation: working)
عربي (my expectation: working)
عربي (my expectation: no idea, particularly interested in this)
عربي (my expectation: no idea, particularly interested in this)
عربي (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. --WikiTiki8917:57, 21 March 2014 (UTC)[reply]
Then I'm stumped. It seems to be the "Arab" class itself that's causing the problem, and not the properties defined in it. --WikiTiki8900:53, 22 March 2014 (UTC)[reply]
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. --WikiTiki8906:06, 22 March 2014 (UTC)[reply]
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:
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)[reply]
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 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)[reply]
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:die→de: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)[reply]
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)[reply]
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. —CodeCat13:25, 25 March 2014 (UTC)[reply]
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. —CodeCat18:21, 25 March 2014 (UTC)[reply]
@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)[reply]
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. —CodeCat21:54, 25 March 2014 (UTC)[reply]
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)[reply]
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:
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)[reply]
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. :) —CodeCat23:10, 25 March 2014 (UTC)[reply]
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)[reply]
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§ion=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>
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
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. —CodeCat01:43, 26 March 2014 (UTC)[reply]
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)[reply]
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. —CodeCat19:25, 28 March 2014 (UTC)[reply]
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). —CodeCat19:27, 28 March 2014 (UTC)[reply]
We can keep the original name around as a redirect, but we should convert existing entries to use the new names. —CodeCat22:50, 28 March 2014 (UTC)[reply]
(@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)[reply]
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)[reply]
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)[reply]
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φr06:24, 4 April 2014 (UTC)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
Problem with display of Russian verb conjugationsedit
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 (talk • contribs).
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 (talk • contribs).
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·e17:04, 28 March 2014 (UTC)[reply]
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. —CodeCat17:59, 28 March 2014 (UTC)[reply]
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).
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·e22:52, 28 March 2014 (UTC)[reply]
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φr06:42, 29 March 2014 (UTC)[reply]
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·e18:11, 29 March 2014 (UTC)[reply]
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).
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. —CodeCat17:29, 29 March 2014 (UTC)[reply]
Use {{label}}. Quicker to type, even when compared to {{cx}}, and still descriptive, especially when compared to {{cx}}.
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.
{{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. --Z18:46, 29 March 2014 (UTC)[reply]
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... —CodeCat03:07, 31 March 2014 (UTC)[reply]
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)[reply]
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". —CodeCat03:25, 31 March 2014 (UTC)[reply]
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)[reply]
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.
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.
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?
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.
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. —CodeCat20:24, 8 April 2014 (UTC)[reply]
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. —CodeCat00:04, 1 April 2014 (UTC)[reply]
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)[reply]
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)[reply]
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. —CodeCat02:55, 8 April 2014 (UTC)[reply]
(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)[reply]
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)[reply]
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)[reply]
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. —CodeCat17:47, 8 April 2014 (UTC)[reply]
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)[reply]
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)