Wiktionary:Grease pit/2017/March

From Wiktionary, the free dictionary
Jump to navigation Jump to search

Edit request to Module:headword[edit]

Please add "interjection forms" to the list of non-lemma POSs. —CodeCat 20:00, 1 March 2017 (UTC)[reply]

@CodeCat: done. —JohnC5 20:26, 1 March 2017 (UTC)[reply]

Etym templates choking on Viennese German[edit]

{{bor|hu|VG.}}, for example, is throwing up a Lua error "attempt to index local 'parent' (a nil value)" (cf. diff). Strangely enough {{etyl|VG.|hu}} still works without problems. --Tropylium (talk) 21:29, 2 March 2017 (UTC)[reply]

@Tropylium: I think it's because the parent, de-AT, is itself in Module:etymology languages/data, and thus the parent language object cannot be accessed through Module:languages or Module:families, the two modules that Module:etymology is attempting to use in lines 144 and 145. I will see if I can fix it. — Eru·tuon 21:51, 2 March 2017 (UTC)[reply]
@Tropylium: Forgot to give an update. It's fixed. The module now iterates through parents till it finds one that isn't an etymology-only language. — Eru·tuon 22:34, 1 April 2017 (UTC)[reply]

Problem with aWa[edit]

Why won't the aWa gadget (A Wonderfool Archiver) work on WT:RFC? —Μετάknowledgediscuss/deeds 06:59, 5 March 2017 (UTC)[reply]

Requested addition to Template:place[edit]

@Daniel Carrero, Ungoliant MMDCCLXIV This is currently missing a classification for the constituent countries of the UK. These are commonly called countries, but they're countries within a country so a more specific term like "constituent country" is probably needed. Entries should be categorised in Category:xx:Countries of the United Kingdom, or perhaps Constituent countries, if that makes more sense. —CodeCat 00:39, 7 March 2017 (UTC)[reply]

Automating rhymes[edit]

It seems to me that with the recent addition of mod:syllables functionality, we can entirely automate the rhyming functionality through {{IPA}}. Am I crazy? We could generate hidden categories of the type [[Rhymes:English/ɛf/<number of syllables>]] and then just transclude them. @CodeCat (I don't know whom to ping about rhyme stuff. Does anyone work on this?) —JohnC5 03:33, 7 March 2017 (UTC)[reply]

It's a good idea, but the difficulty, for English at least, would be the variety of phonemic transcription systems currently in use. There are the different English dialects, and the different ways of transcribing the phonemes of each dialect. There would have to be a way to mark the ones that correspond to the transcription system used on the rhymes pages, so that, for example, the module does not try to add a category for the Southern Hemisphere English transcription /hæo/ at how. Currently, all English IPA transcriptions are only marked with |lang=en, nothing more specific. And there are some pages with just one transcription that is probably UK or US but is not marked even with {{a}}. So, the solution would be to come up with some way to pass a parameter through the IPA template that will tell the module whether it can add a rhyme category. Several ways I can think of to do this: explicitly (by adding a rhyme-related parameter) or by adding a dialect parameter, or an addition to the |lang= parameter (perhaps a nation code such as -US, -UK, etc., though that would not be specific enough). — Eru·tuon 05:02, 7 March 2017 (UTC)[reply]
I was honestly thinking first for the automated pronunciation modules first (Catalan, for example, or Latin if that makes any sense). —JohnC5 05:30, 7 March 2017 (UTC)[reply]
Oh, okay. That should be pretty easy to do, I would think. — Eru·tuon 05:47, 7 March 2017 (UTC)[reply]
As for Catalan it is done on ca.wikt: ca:Categoria:Rimes en català. First step is to choose the transcription used for defining the rhymes, usually Valencian. Second, only two corrections are needed comparing Central Catalan and Valencian: separate -ar and -a(r), or always -e-, always -Ɛ-, alternating -e/Ɛ-. --Vriullop (talk) 19:06, 7 March 2017 (UTC)[reply]
The problem with automating the rhymes language-wide is that it's not selective. Right now, we create rhymes pages when we have rhymes, and we don't bother with words like orange, anthrax, width, length, breadth, depth, warmth, scorpion, obfuscate, stethoscope, bathyscaphe, etc. Then there are declensions and conjugations in many languages where just about everything rhymes (for instance, Category:Spanish verbs ending in -ar), or common suffixes like -phobia that always take the accent. Think of all the hidden comments in the rhymes pages asking not to add words with suffixes that are the same as the last syllable of the rhyme, because that combination would overwhelm the true occurrences of the rhyme. Chuck Entz (talk) 08:37, 7 March 2017 (UTC)[reply]
I'm not sure that I agree with such a concern. That truth is that all words in -phobia do rhyme and that does not make them inferior. —JohnC5 15:15, 7 March 2017 (UTC)[reply]
I think I agree with you (John). It depends on how users want to use this. A poet certainly would appreciate verb-form rhymes. In theory we could allow rhymes of certain types to be collapsed/hidden, too, but it would be silly to do that kind of work unless real users request it. Equinox ◑ 00:34, 8 March 2017 (UTC)[reply]

Cleanup request[edit]

Most results in [1]. Thanks! Wyang (talk) 23:42, 7 March 2017 (UTC)[reply]

@DTLHS, are you interested? —Μετάknowledgediscuss/deeds 00:20, 8 March 2017 (UTC)[reply]
Can anyone think of any potential errors that would arise with an automatic replacement? DTLHS (talk) 00:23, 8 March 2017 (UTC)[reply]
Obviously the general fix is to replace " ," with "," but there are some less common cases: ", ," needs to become "," (e.g. make, where there is an extra comma with no item between the commas), and ": ," needs to become ": " (e.g. path, which has a translation line that begins "Estonian: ,"). Equinox ◑ 00:31, 8 March 2017 (UTC)[reply]
@Metaknowledge I've done a test run of a few hundred entries- I didn't notice any obvious errors this replacement would cause but I'll review the diffs carefully before doing the remaining edits (a lot of pages). DTLHS (talk) 03:33, 11 March 2017 (UTC)[reply]
@DTLHS: Thank you. I think you know this, but your cleanup work is really invaluable. —Μετάknowledgediscuss/deeds 03:37, 11 March 2017 (UTC)[reply]

Copulative does not always apply to verbs[edit]

At הוא and ניהו, the label {{lb|arc|copulative}} adds the category Category:Aramaic copulative verbs, but these are pronouns, not verbs. How should this be fixed? --WikiTiki89 20:28, 8 March 2017 (UTC)[reply]

Copulative is not a context, so this is just a misuse of the label. —CodeCat 21:05, 8 March 2017 (UTC)[reply]
There are many labels that are not contexts: for instance, the very common "transitive" and "intransitive". Being a context is not required of a label. — Eru·tuon 21:12, 8 March 2017 (UTC)[reply]
Those are contexts, because they specify senses that occur only when the verb is used transitively or intransitively. —CodeCat 21:53, 8 March 2017 (UTC)[reply]
That seems to me an odd interpretation of the word "context". But to redirect back to the topic, how is "copulative" not also a context in the same sense: the context being "when the pronoun is used copulatively"? — Eru·tuon 22:11, 8 March 2017 (UTC)[reply]
Personally, when I see the label {{lb|en|transitive}}, I think it means not "when the verb is used transitively", but "this sense is transitive". — Eru·tuon 22:12, 8 March 2017 (UTC)[reply]
The whole reason we deprecated {{context}} in favor of {{label}} is that these labels are not always contexts. As for this case, I don't understand how a pronoun can be copulative anyway. —Aɴɢʀ (talk) 20:08, 10 March 2017 (UTC)[reply]
@Angr: I think it's because third-person pronouns in Semitic languages can be used where English would use a copulative verb: أَحْمَدٌ هُوَ قَصِيرٌ. (ʔaḥmadun huwa qaṣīrun.) “Ahmad is short.” (literally, “Ahmad he short”). — Eru·tuon 20:21, 10 March 2017 (UTC)[reply]
But that's not a lexical property of the individual pronouns, that's just a fact of Semitic syntax. הוא in both Aramaic and Hebrew is just a pronoun meaning "he, it". It doesn't mean "is", even if it's used in the same position of the sentence as the English verb "is". —Aɴɢʀ (talk) 20:25, 10 March 2017 (UTC)[reply]
I am inclined to agree, but I am not sure how this would typically be analyzed by linguists: if they would consider the pronoun to have changed its part of speech. The Chinese copula 是 (shì) developed in a similar way (as I recall learning in a historical linguistics course), but the entry does not say whether it is considered to be a verb. — Eru·tuon 20:31, 10 March 2017 (UTC)[reply]
The "Definitions" header is nonstandard and should be changed. —CodeCat 20:39, 10 March 2017 (UTC)[reply]
I disagree, these prnouns do mean "is/are/am". Russian has the same construction with the word это (eto). In fact, in JBA, ניהו and its forms are only used for this purpose (i.e. as a copula). Additionally, in Hebrew and Aramaic (not sure about Arabic) these third person pronouns can serve as copulas even for a first or second person subject (as in אנא הוא מלכא (“I am the king”, literally “I he king”)). --WikiTiki89 20:45, 10 March 2017 (UTC)[reply]
It seems to me they should be considered verbs then, not pronouns. If they were pronouns, they would be standing in for a noun, but they are not. — Eru·tuon 20:48, 10 March 2017 (UTC)[reply]
But they are not verbs, because they don't share any properties with verbs. They don't have tenses, unless you consider them to be a suppletive present tense of the verb "to be", which would be a bit strange in my mind. --WikiTiki89 20:58, 10 March 2017 (UTC)[reply]
In Hebrew, the negative copula אין behaves like a preposition when it comes to pronominal subjects, as in אינני בקרבכם (“I am not among you”, literally “no-me among-you”). Not everything that functions as a copula can be sensibly called a verb. --WikiTiki89 21:15, 10 March 2017 (UTC)[reply]
Well, they don't seem to be pronouns either, since they don't refer to nouns, so perhaps they are an entirely different part of speech. — Eru·tuon 21:27, 10 March 2017 (UTC)[reply]
This seems more like a zero copula, like in Russian. —CodeCat 21:30, 10 March 2017 (UTC)[reply]
In أَحْمَدُ قَصِيرٌ (ʔaḥmadu qaṣīrun, “Ahmad is short”), you have a zero copula, but in أَحْمَدُ هُوَ قَصِيرٌ (ʔaḥmadu huwa qaṣīrun, “Ahmad is short”), هُوَ (huwa) is serving as a copula, so it's no longer a zero copula. This is a relatively common phenomenon that develops in languages with a zero copula, including in Russian as I mentioned above. --WikiTiki89 20:46, 15 March 2017 (UTC)[reply]
The Irish copula is/ba isn't a verb either, though it is usually glossed "is"/"was". Neither is it a pronoun. It's just a particle; maybe that's what these Semitic forms are. —Aɴɢʀ (talk) 21:36, 10 March 2017 (UTC)[reply]
Wait, what? It's a direct descendant of Proto-Indo-European *h₁ésti. How is it not a verb? —CodeCat 21:42, 10 March 2017 (UTC)[reply]
It was a verb as recently as Old Irish, but not anymore. For one thing, it takes the disjunctive form of pronouns, while verbs take the conjunctive form (is é vs. tá sé); for another, it's followed by the predicate (when the predicate is indefinite) with the subject at the end (is múinteoir é Seán "Seán is a teacher"), while verbs are followed by the subject with the predicate at the end (tá Seán ina mhúinteoir "Seán is a teacher"). See this paper and the references it cites. —Aɴɢʀ (talk) 22:31, 10 March 2017 (UTC)[reply]
Particle is essentially a cover term for anything that doesn't have a real name, but it would probably be the best term to use. (So-called subjunctive particles, for instance, are actually conjunctions.) — Eru·tuon 21:46, 10 March 2017 (UTC)[reply]
Usually particles are unchangeable; so if there gender and number agreement, it feels weird to call them particles. But even if we call them particles, we still have the original problem I brought up in this thread regarding automatic categorization. --WikiTiki89 20:33, 15 March 2017 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Two possible solutions: change the label used for the Semitic copulative words, or change the label for copulative verbs. The former would probably be easier, since I imagine there are far more copulative verbs marked with {{lb|xx|copulative}} than there are Semitic copulative words. — Eru·tuon 20:49, 15 March 2017 (UTC)[reply]

Template:cite-web ignores title= parameter.[edit]

I get an error message saying "(Please provide the title of the work)" even when the parameter is provided. —CodeCat 23:08, 8 March 2017 (UTC)[reply]

Added the parameter. It wasn't included as an option, but I see no reason why it should not be. — Eru·tuon 23:19, 8 March 2017 (UTC)[reply]
Oops, {{cite-web}} already uses the parameter |title= for the page title (which is passed to the |chapter= parameter of {{cite-meta}}). The |title= parameter in {{cite-meta}} is, counterintuitively, set by the |blog=, |site=, |work= parameters of {{cite-book}}. — Eru·tuon 19:28, 9 March 2017 (UTC)[reply]
Probably not a good idea. Parameters with the same name in different templates should have the same function too. —CodeCat 19:39, 9 March 2017 (UTC)[reply]
I agree, but I'm not sure how to fix the problem. — Eru·tuon 22:48, 9 March 2017 (UTC)[reply]
This was done to ensure backward compatibility for the template. (Note that {{cite-journal}} is the same, as well as {{quote-journal}} and {{quote-web}}.) I suppose we could change the parameter names, and then have a bot to update all existing uses. Do we wish to do this? — SMUconlaw (talk) 18:00, 11 March 2017 (UTC)[reply]

Unicode 10.0.0 Beta[edit]

Unicode version 10.0.0 beta is available if you are interested. [2] Focusing on characters, the significant change is that the addition of lots of Nushu, Hentaigana, CJK block F (and also 21 new characters in CJK main block), and some emojis [3]. The final version will be released in June. See you soon. --Octahedron80 (talk) 04:59, 10 March 2017 (UTC)[reply]

Thank God, finally an emoji for broccoli. Equinox ◑ 22:08, 10 March 2017 (UTC)[reply]
Not only that, but also some Sawndip and chữ Nôm. Besides, the characters of CJK Unified Ideographs Extension F look tempting to write. --Lo Ximiendo (talk) 05:58, 11 March 2017 (UTC)[reply]
Also, I didn't know, that there is also the Persian zodiac! --Lo Ximiendo (talk) 06:25, 11 March 2017 (UTC)[reply]

Changes to Module:links[edit]

Hello, I'm currently working to improve Module:links. Let me know if there are any problems, and I will do my best to fix them immediately. — Eru·tuon 20:32, 11 March 2017 (UTC)[reply]

Initialism template inserts unwanted space[edit]

See UQ; note the full-stop (period) after the definition has a space before it, which is not in the markup. This didn't use to happen. Equinox ◑ 18:56, 11 March 2017 (UTC)[reply]

It appears that some edit has affected many templates: see {{fr-noun}} at qwerty. (And even {{m}}, used in the preceding sentence!) @Erutuon, any idea? — SMUconlaw (talk) 19:14, 11 March 2017 (UTC)[reply]
@Equinox, Smuconlaw: Oh yes, it was my fault; fixed. Thanks for noticing! — Eru·tuon 19:20, 11 March 2017 (UTC)[reply]
Thank you! — SMUconlaw (talk) 19:21, 11 March 2017 (UTC)[reply]

Terms with redundant transliterations[edit]

All the "Terms with redundant transliteration" categories are suddenly being populated even though the terms don't have redundant transliterations. For example, there are now more than a thousand entries in Category:Terms with redundant transliterations/ar, but most if not all of them are false positives. —Aɴɢʀ (talk) 20:10, 11 March 2017 (UTC)[reply]

@Angr: Ahh, that was a result of my modification of the if-statements governing the addition of those categories. I think I have fixed the problem. It should begin to work correctly again, as the server updates the pages. — Eru·tuon 20:25, 11 March 2017 (UTC)[reply]
Now that we're editing Module:links, can we also finally get rid of the silly phonetic_extraction that's in it? —CodeCat 20:31, 11 March 2017 (UTC)[reply]
I don't know. What is it? — Eru·tuon 20:40, 11 March 2017 (UTC)[reply]
The reason both CodeCat and Wyang are currently both not admins at the moment. —suzukaze (t・c) 22:02, 11 March 2017 (UTC)[reply]

incomprehensible postcatboiler template documentation[edit]

https://en.wiktionary.org/wiki/Category:Finnish_intransitive_change_morphological_derivatives

The automatically-generated contents of this category has errors. The label given to the poscatboiler template is not valid. You may have mistyped it, or it simply has not been created yet. To add a new label, please consult the documentation of the template.

I'm trying to fix the chaos in the categories and descriptions of Finnish verbs, but most of my time is being wasted by trying to understand template documentation and https://www.mediawiki.org/wiki/Help:Categories that is so badly written or missing info that is so essential that i can't figure out what to do. The problems must be pretty big because i've got lots of experience editing Wiktionary and Wikipedia and this has included quite many edits dealing with more than text editing, some of it quite technical in nature. --Espoo (talk) 21:37, 11 March 2017 (UTC)[reply]

poscatboiler is implemented by Module:category tree and its submodule Module:category tree/poscatboiler. A label needs to be defined in Module:category_tree/poscatboiler/data or a subpage before it can be used. But you really don't need to use a template for specialized language-specific categories such as this one- just add the description and parent categories manually. DTLHS (talk) 21:43, 11 March 2017 (UTC)[reply]
Also the label needs to match the category page title. DTLHS (talk) 21:53, 11 March 2017 (UTC)[reply]
@Espoo: Or you could just remove {{poscatboiler}} and edit these Finnish categories normally using wikitext. Using that template makes sense for a lot of categories that have the same description and parent categories across thousands of languages, like "Category:<language> nouns" (Category:English nouns, Category:Portuguese nouns, Category:Japanese nouns, etc.) but if you want to edit, say, Category:Finnish intransitive change morphological derivatives, and we won't have a lot of other categories named "Category:<language> intransitive change morphological derivatives" then using {{poscatboiler}} for that category is possible but maybe low priority if you can do the same work with wikitext. If you clean up the Finnish categories using just wikitext, we can migrate the categories to {{poscatboiler}} eventually anyway. --Daniel Carrero (talk) 15:17, 12 March 2017 (UTC)[reply]

Problem with "American spelling" entries[edit]

See e.g. 100 meters. "American spelling" failed RFD, but this and many other entries still have red links. Mass bot fix? Equinox ◑ 00:32, 12 March 2017 (UTC)[reply]

Module:labels/data/regional says that "American spelling" should link to w:American and British English spelling differences, but for some reason it dosn't seem to be working. At any rate, it looks like something in a module needs to be fixed, rather than having a bot fix a bunch of entries. —Aɴɢʀ (talk) 15:46, 12 March 2017 (UTC).[reply]
Apparently the relevant module is Module:labels/data/subvarieties. I'm not sure about the status of Module:labels/data/regional- someone who knows should add a comment to it so people don't waste their time. Chuck Entz (talk) 16:12, 12 March 2017 (UTC)[reply]
@Erutuon, this seems to be your business again. —Μετάknowledgediscuss/deeds 17:11, 13 March 2017 (UTC)[reply]
@Chuck Entz, Metaknowledge: Module:labels/data/regional is still functional, but the labels in it will get overwritten by the labels in Module:labels/data/subvarieties, if they are spelled identically, because of the way in which Module:labels/data adds the subvariety labels. This can be changed, but I think it would be best to have the "American spelling" label in the subvarieties module since it relates to a single language. — Eru·tuon 17:18, 13 March 2017 (UTC)[reply]

span class="mention"[edit]

At "in the ballpark", I noticed some HTML/CSS stuff in the wikicode, using <span class="mention">. Is there a better or preferred way to achieve whatever is being done there? Equinox ◑ 15:09, 12 March 2017 (UTC)[reply]

Done. —CodeCat 15:13, 12 March 2017 (UTC)[reply]
That's the class added by Module:script utilities (see Module:script utilities/documentation#tag_text), which is used by Module:links and {{m}}. It should always be added by the template {{m}}, and not be visible in the wikitext. — Eru·tuon 20:31, 12 March 2017 (UTC)[reply]

template:cog[edit]

Documentation says that second parameter is needed/mandatory, or otherwise would be requested, but example ride shows in =Etym section[cognates] that can be used for only state the language name. Is this correct? Sobreira ►〓 (parlez) 18:46, 12 March 2017 (UTC)[reply]

If the language code is a language family, like ine = Indo-European, then the second parameter must not be present, otherwise a module error will occur. If the language code is a specific language (whether attested or reconstructed), then the second parameter must be present, but it can be simply |- if you don't want to mention a term. —Aɴɢʀ (talk) 20:17, 12 March 2017 (UTC)[reply]
Actually, at the moment, there isn't an error if you don't add a term: {{cog|en}} → English [Term?]. I haven't sorted out when there should be an error and when there shouldn't. But the second parameter should generally be supplied. — Eru·tuon 20:36, 12 March 2017 (UTC)[reply]
@Erutuon: I believe at some point in your recent edits you removed the ability of these templates to show [term?] and place entries in categories like Category:English term requests. I believe I was able to restore it now. The [term?] and category should appear when you don't type any term (parameter 3 for {{der}}, {{inh}} or {{bor}}; parameter 2 for {{cog}}) and the current code is a language or dialect, not a family. --Daniel Carrero (talk) 17:57, 13 March 2017 (UTC)[reply]
@Daniel Carrero: Oh, hm, you're right. I'm not sure how that happened, since the old module code is hard to read, but thanks for fixing it. — Eru·tuon 18:48, 13 March 2017 (UTC)[reply]
You're welcome. :) --Daniel Carrero (talk) 18:51, 13 March 2017 (UTC)[reply]
@Daniel Carrero, Erutuon: I don't know whose edit it was, but now etymology templates are choking on languages with no scripts, such as "und" or "pregrc". Chuck Entz (talk) 03:42, 14 March 2017 (UTC)[reply]
@Chuck Entz: I'm puzzled. It seems to also be generating an error for language families, but that ought to have been avoided by the code that adds an empty term - for language families. Frustratingly, it is difficult to sort out the logical progression and get the problem dealt with, in the current form of the module. — Eru·tuon 07:33, 14 March 2017 (UTC)[reply]
Okay, I just switched the order of two functions and it seems to clear up this problem. I'm not sure if it won't cause other problems. We'll see. — Eru·tuon 08:08, 14 March 2017 (UTC)[reply]
It should behave the same as {{m|en}}, and add a term request, at the very least. I'm not sure what the point is of allowing - as the second parameter. If you're using a template to show a cognate but then don't show the cognate, what's the point? —CodeCat 20:59, 12 March 2017 (UTC)[reply]
I've seen it used in cases where a cognate word has the same form in two different languages: for instance, in free, where the Danish and Norwegian cognates have the same spelling. — Eru·tuon 21:16, 12 March 2017 (UTC)[reply]
Then you need to list them both, because {{cog}} links to the sections of the languages. Furthermore, although the spelling is the same, the pronunciation is not. The language tagging affects the pronunciation used by screen readers, so if you only include a Danish link then it will only say the word in a Danish pronunciation. —CodeCat 21:18, 12 March 2017 (UTC)[reply]
Well, that makes sense, but it will require editing a lot of pages. Perhaps a bot could do it. — Eru·tuon 21:20, 12 March 2017 (UTC)[reply]
Sometimes {{cog}} doesn't list a term because an editor wants to insert a word in between the language name and the term, e.g. "the {{cog|sa|-}} root {{m|sa|गम्}}". —Aɴɢʀ (talk) 12:45, 13 March 2017 (UTC)[reply]
Do you even need to use {{cog}} then? —CodeCat 16:40, 13 March 2017 (UTC)[reply]
@CodeCat: I think it would be best to use {{cog}} in all cases where one is mentioning the language name of a cognate term. That way, if we want to make changes to the way cognates are formatted or handled (say, by adding a class for language names of cognates, or by adding categories for terms with cognates in particular languages), it can be done relatively easily, by changing the output of the template. — Eru·tuon 18:36, 13 March 2017 (UTC)[reply]
I agree with Erutuon. Also, by using {{cog}}, we can easily keep track of changes in language names... If we wanted to change, say, "Old English" to "Anglo-Saxon" (which is very unlikely, but other language name changes do happen), we could make the new language name appear in all instances of {{cog}} at once. --Daniel Carrero (talk) 18:41, 13 March 2017 (UTC)[reply]

Please comment on adding pronunciation assessment[edit]

Please endorse or critique meta:Grants:Project/Intelligibility transcriptions or both.

Under what conditions would you want to put microphone inputs in the pronunciation sections in Wiktionaries? Here's an example, adapted from read#Pronunciation, using square brackets to mock up buttons:

Noun, and verb's present tense
  • enPR: rēd, IPA(key): /ɹiːd/
  • Audio (UK)(file)
    Try saying: [Record 🔴] [Stop ⬛] [Play ▶️] [Evaluate ❓] [Say in phrase 🔗]
  • Audio (US)(file)
    Try saying: [Record 🔴] [Stop ⬛] [Play ▶️] [Evaluate ❓] [Say in phrase 🔗]
  • Rhymes: -iːd
  • Homophones: reed, rede
Verb's past tense and past participle

Ideally, the "Evaluate" button will produce audio feedback with an option to also view pertinent visual information. The link to say the word in a phrase may use OAuth or other registration to keep track of the user's word and diphone proficiency for adaptive instruction in general vocabulary. There is likely to be a small audio level meter between the Record and Stop buttons.

If you are interested in topical vocabulary, please see this glossary from 1978. James Salsman (talk) 23:19, 14 March 2017 (UTC)[reply]

"Terms with redundant transliterations" categories[edit]

Anyone know what the "Terms with redundant transliterations" categories popping up are for? I see "Category:Terms with redundant transliterations/yi" and "Category:Terms with redundant transliterations/bg" at the radish entry and have no idea why. — SMUconlaw (talk) 08:20, 14 March 2017 (UTC)[reply]

Those are added by the {{t}} template in the Translations section. Those categories used to only be added for a small set of languages, but now they are added for any language with transliteration. They're just for tracking. They should be hidden. Add {{auto cat}} to the category pages if you would like to help hide them. (Though I suppose a bot could do it more efficiently.) — Eru·tuon 08:25, 14 March 2017 (UTC)[reply]
Oh, I see. But why are the transliterations "redundant"? — SMUconlaw (talk) 08:44, 14 March 2017 (UTC)[reply]
Ohh, right, didn't explain that. It means the transliteration supplied in the |tr= parameter is the same as the one generated by the transliteration module. — Eru·tuon 09:43, 14 March 2017 (UTC)[reply]
Ah, OK ... not really following, but never mind ... ;-) — SMUconlaw (talk) 09:51, 14 March 2017 (UTC)[reply]
@Smuconlaw: Heh. I will try to explain further. The transliteration modules for particular languages are found in Category:Transliteration modules. Say you put a non-Latin alphabet into a linking template: for instance, Ancient Greek {{m|grc|γένος}} → γένος (génos). The transliteration module for Ancient Greek (Module:grc-translit) automatically generates a transliteration, génos, and the links module displays it in parentheses after the link. If you copy that transliteration and put it in the |tr= parameter of the linking template – {{m|grc|γένος|tr=génos}} → γένος (génos) – the redundant transliterations category will be added. (Or it should be. It seems not to be added in this case, and I don't know why.) — Eru·tuon 19:00, 14 March 2017 (UTC)[reply]
Ah, I see! Thanks. — SMUconlaw (talk) 19:18, 14 March 2017 (UTC)[reply]

Blasphemy categories[edit]

Would it be possible to incorporate Category:en:Blasphemy and Category:cs:Blasphemy into the tree of automatically generated categories? Thanks! --Jan Kameníček (talk) 17:17, 14 March 2017 (UTC)[reply]

Blasphemy according to who? —CodeCat 17:36, 14 March 2017 (UTC)[reply]
I think general categorization without further subdivision would be OK. --Jan Kameníček (talk) 18:05, 14 March 2017 (UTC)[reply]
Reading your contribution again I got an idea that you had not asked because of the categorization, but because you wanted to suggest that the topic category is subjective. That's quite possible, I did not think about this. I just saw the en:category which has been existing for several years, founded the same category for cs: and asked to incorporate them into the category tree. If you think they are redundant, feel free to suggest their deletion. But if they are not deleted, they should be incorporated into the tree. --Jan Kameníček (talk) 18:35, 14 March 2017 (UTC)[reply]
Now I have noticed that the English category has already survived rfd. --Jan Kameníček (talk) 18:39, 14 March 2017 (UTC)[reply]
Maybe it's time for another RFDO. Lingo Bingo Dingo (talk) 10:25, 15 March 2017 (UTC)[reply]
I am quite neutral about the stay x delete possibilities, but if it stays, it should be included into the tree. If it is not worth included into the tree, it should not stay. --Jan Kameníček (talk) 10:35, 15 March 2017 (UTC)[reply]
This seems at least as subjective as the "politically correct" category that was being mooted for removal. Equinox ◑ 19:24, 15 March 2017 (UTC)[reply]

Category:en:Towns in England[edit]

I have obviously done something wrong, as it shows "Categories with invalid label". I used auto cat first, but changed it to topic cat. DonnanZ (talk) 19:00, 15 March 2017 (UTC)[reply]

@DonnanZ: The category simply hasn't been created yet. Once it has been added to the relevant module, either the template {{auto cat}} or {{topic cat}} can be used to create the category. The category module to which the category would be added is probably Module:category tree/topic cat/data/Place names old or Module:category tree/topic cat/data/Place names. I am not sure what the difference between the two is, though one seems to use "towns" in its category names and the other uses "municipalities". — Eru·tuon 22:55, 15 March 2017 (UTC)[reply]
The category has been created and now has over 60 entries. I possibly have done things the wrong way round, not creating a red link first (with the name of the category) before creating the actual category. DonnanZ (talk) 23:14, 15 March 2017 (UTC)[reply]
Why do you think this is a useful category to have when we already have Category:en:Cities in England? DTLHS (talk) 23:28, 15 March 2017 (UTC)[reply]
Towns don't have city status, so they can't be classified as such; there are officially only 50 or so cities in England, and some very large towns which don't have city status. There are categories for Towns in the United States of America, Canada, Pennsylvania, New York, Maine, Ontario, British Columbia and possibly others. Also Category:en:London, which covers towns within Greater London, and Category:en:Place names of England, which is empty. It was prompted by a user classifying Stourbridge as a city, which it certainly isn't. DonnanZ (talk) 23:57, 15 March 2017 (UTC)[reply]

Why does "Move page" have a stupid crippled button?[edit]

When you go to move a page, the actual "Move page" button on the form is this weird blue button, not a normal form button, therefore it cannot be activated normally using the keyboard (e.g. Tab to focus it, Space to press it). What on Earth is the point of that? Very bad for usability. Equinox ◑ 22:49, 15 March 2017 (UTC)[reply]

I'm not seeing the same thing. I can use tab to focus it and space to press it. — Eru·tuon 22:50, 15 March 2017 (UTC)[reply]
I second Erutuon. It's a weird blue button alright, but I can still use tab and space with it. --WikiTiki89 22:56, 15 March 2017 (UTC)[reply]
Since a fairly recent change alt-shift-m immediately summons the move form, which seems pretty good and consistent with the various other keyboard shortcuts implemented at the same time. DCDuring TALK 22:58, 15 March 2017 (UTC)[reply]
Hmm, well, in Chrome, when I tab to the button and press Space, it does a sort of page-down scroll operation, which is what Chrome usually does if you press Space without any interactive UI element focused. Equinox ◑ 23:40, 15 March 2017 (UTC)[reply]
I was using Chrome on Windows 7. --WikiTiki89 11:39, 16 March 2017 (UTC)[reply]
I got the same behavior as Equinox and Wikitiki did, but on FF 52.0. DCDuring TALK 11:54, 16 March 2017 (UTC)[reply]

etytree, a graphical and multilingual etymology dictionary based on Wiktionary: feedback and endorsement[edit]

Hi all!

I have now completed the first phase of the project and I’m asking for a renewal and for your feedback! Pls add your comment at the end of page Renewal.

A link to the demo is demo, while a link to the first release is tools.wmflabs.org/etytree.

Looking forward to your comments on the grant page! Epantaleo (talk) 14:24, 16 March 2017 (UTC)[reply]

Categories en:Currency and en:Currencies[edit]

There are 97 currencies in the category Category:en:Currencies and 211 in the category Category:en:Currency. I think we should have only one category for English names of currencies. --Hekaheka (talk) 17:59, 16 March 2017 (UTC)[reply]

There is only one category, Category:en:Currencies. Category:en:Currency is for terms related to currency. —CodeCat 18:15, 16 March 2017 (UTC)[reply]
AFAIK, there are many currencies under Category:en:Currency. --Hekaheka (talk) 17:46, 11 April 2017 (UTC)[reply]
Feel free to move them. —CodeCat 18:07, 11 April 2017 (UTC)[reply]
Maybe the text at the top of the categories should be made even clearer regarding what goes where, with a link from each category to the other. (But when I edit the page I just get auto cat, no text to edit.) Equinox ◑ 18:41, 11 April 2017 (UTC)[reply]
There's a big edit link at the top right. —CodeCat 20:07, 11 April 2017 (UTC)[reply]

Language data edit[edit]

Please add this to bnt-ngu-pro: 

	sort_key = {
		from = {"[àáâǎ]", "[èéêě]", "[ìíîǐ]", "[òóôǒ]", "[ùúûǔ]", "ḿ", "[ǹńň]", ACUTE, GRAVE, CIRC, CARON},
		to   = {"a"     , "e"     , "i"     , "o"     , "u"     , "m", "n"    }},

—CodeCat 16:12, 17 March 2017 (UTC)[reply]

@CodeCat: Done. —JohnC5 17:02, 17 March 2017 (UTC)[reply]

Parts of speech[edit]

For a non-profit endeavor, I am looking for wordlists broken into parts of speech. Can anyone help me figure out how to extract wordlists from Wiktionary into verbs, adverbs, nouns and adjectives? I'd also love to be able to subdivide nouns into singular vs. plural, and verbs into verb tense, but it is not necessary. — This unsigned comment was added by Crossword.guy (talk • contribs) at 14:45, 18 March 2017 (UTC).[reply]

You can visit (for example) Category:English nouns: it's split across many pages, because there are so many words. If you want to generate a complete list then you will need to download one of the periodic dumps of entry titles (several gigabytes of XML!) and process it with software of some kind. Equinox ◑ 14:50, 18 March 2017 (UTC)[reply]
You can also use the category API to download all titles in a particular category. DTLHS (talk) 15:57, 18 March 2017 (UTC)[reply]

Autobalancing translation tables[edit]

Can someone modify {{trans-top}} so that it autobalances the columns the way {{col-top}} does? That way we wouldn't have to keep balancing the columns manually. —Aɴɢʀ (talk) 17:36, 18 March 2017 (UTC)[reply]

But there's still {{trans-mid}}. If we are going to remove that, then we'll have to modify the translation script as well.
Also, some time ago I proposed moving the favourite translations from the header into the body of the table, but visible when the table is collapsed, like the inflection of openen. Can this also be implemented as well, while we're at it? —CodeCat 17:43, 18 March 2017 (UTC)[reply]
What does that have to do with Angr's proposal? Can we try to do one thing at a time? DTLHS (talk) 18:05, 18 March 2017 (UTC)[reply]
Because they both require modifying the script, and it's easier to do it right the first time. —CodeCat 18:12, 18 March 2017 (UTC)[reply]
At the same time that {{trans-top}} becomes self-balancing, all content can be deleted from {{trans-mid}}, so its presence has no effect on anything. Then a bot can go through and remove it, but in the meantime it does no harm. As for the other suggestion, I don't have "favorites" implemented on translation tables, so I have no opinion, but I do think the two things could be done separately from each other. —Aɴɢʀ (talk) 18:16, 18 March 2017 (UTC)[reply]

Firefox and Javascript[edit]

In FF 52.0.2, but not MS Edge [or Chrome 00:02, 21 March 2017 (UTC)] , two bits of functionality delivered, I think, via JS are not available to me. One is the tab display of Preferences. The other is the "Regex editor" that appears on the left of Wiktionary windows when the edit frame is opened. I am hoping not to have to abandon FF for Chrome, which I hope doesn't have this problem. (Edge doesn't seem to interact well with Wiktionary.) DCDuring TALK 00:51, 20 March 2017 (UTC)[reply]

In Chrome, I tried turning on the regex-editor the other day and nothing appeared in my left-hand panel. Dunno if that's a caching issue or something. Didn't try hard. Equinox ◑ 00:14, 21 March 2017 (UTC)[reply]
I find that sometimes the regex editor and my TemplateScript scripts show up on the sidebar, and sometimes they don't. Similarly, sometimes the code editor for Module pages shows up and sometimes it doesn't. Reloading (ctrl-r) or clearing cache and reloading (ctrl-shift-r) fixes the problem. — Eru·tuon 01:19, 21 March 2017 (UTC)[reply]
Thanks, but those don't work for me. I wonder if the reloading is defeated by caching on the part of my ISP or further up the network. DCDuring TALK 12:13, 21 March 2017 (UTC)[reply]
AFAICT I'm not getting any JS functionality, eg, show-hide of translations and derived and related terms and selective display of extended characters, as well the items mentioned above. The problem seems to apply to all 3 browsers I've tried, but seems to be Wiktionary-specific. Why might this be happening? Any ideas about how to fix or where to go for help. DCDuring TALK 23:07, 21 March 2017 (UTC)[reply]
Problem seems specific to one of my computers. Maybe reboot would help. DCDuring (talk) 03:10, 22 March 2017 (UTC)[reply]
Reboot didn't help with Firefox. It is as if FF has lost it JS capability. DCDuring (talk) 16:17, 22 March 2017 (UTC)[reply]
Does using incognito mode have any effect? DTLHS (talk) 16:19, 22 March 2017 (UTC)[reply]
Thanks for the response. I have just discovered the source of the problem: a FF add-on called YesScript which I had forgotten that I had installed. I will look into it a bit to see if YesScript can be configured to not give me the problem and whether it is worth the trouble to have it. DCDuring (talk) 17:03, 22 March 2017 (UTC)[reply]

More cleanup request[edit]

Entries with Etymology 2 but not Etymology 1. Thanks! Wyang (talk) 04:39, 21 March 2017 (UTC)[reply]

User:DTLHS/cleanup/numbered etymology errors. DTLHS (talk) 21:02, 22 March 2017 (UTC)[reply]

Language data edit[edit]

Please add the following for the codes nd, nr, ss and xh: 

	entry_name = {
                from = {"[āàáâǎ]", "[ēèéêě]", "[īìíîǐ]", "[ōòóôǒ]", "[ūùúûǔ]", "ḿ", "[ǹńň]", MACRON, ACUTE, GRAVE, CIRC, CARON},
                to   = {"a"      , "e"      , "i"      , "o"      , "u"      , "m", "n"    }},

and the following for bnt-phu: 

	entry_name = {
                from = {"[àá]", "[èé]", "[ìí]", "[òó]", "[ùú]", "ḿ", "[ǹń]", ACUTE, GRAVE},
                to   = {"a"   , "e"   , "i"   , "o"   , "u"   , "m", "n"   }},

—CodeCat 01:24, 22 March 2017 (UTC)[reply]

 Done - -sche (discuss) 03:05, 22 March 2017 (UTC)[reply]

Two needed IDS's[edit]

Sorry if this does not really relate to Wiktionary. For anyone who is potential to propose new characters to Unicode. I want to introduce two needed IDS's I hope someone would help. At the moment, I will use arrows ↔ and ↷ to present their operations. --Octahedron80 (talk) 05:29, 22 March 2017 (UTC)[reply]

Ken Lunde on Twitter is fairly responsive to questions. —suzukaze (t・c) 05:43, 22 March 2017 (UTC)[reply]
I sent the picture to him. --Octahedron80 (talk) 05:51, 22 March 2017 (UTC)[reply]
@Octahedron80, Suzukaze-c: I don't think we should be using these symbols for the IDSs yet, like at 𠄏. — justin(r)leung { (t...) | c=› } 10:24, 22 March 2017 (UTC)[reply]
All right. --Octahedron80 (talk) 00:04, 23 March 2017 (UTC)[reply]
@Octahedron80: [5] —suzukaze (t・c) 03:53, 14 January 2018 (UTC)[reply]
Added commented-out code to Module:zh-sortkey that can be used if the characters are added. — Eru·tuon 05:24, 14 January 2018 (UTC)[reply]

Handling of English transliterations by {{der}}[edit]

The {{der}} template is not handling some Greek transliterations properly. For example, {{der|en|el|ῥηματικός||[[verbal]], pertaining to [[verb]]s}} (at rhematic) does not render the ῥ as rh:

Greek ῥηματικός (rhēmatikós, “verbal, pertaining to verbs”)

— SMUconlaw (talk) 05:37, 22 March 2017 (UTC)[reply]

@Smuconlaw: The templates are working fine, someone just used the wrong language code. —Μετάknowledgediscuss/deeds 05:43, 22 March 2017 (UTC)[reply]
Perhaps change el to grc instead? --Octahedron80 (talk) 06:03, 22 March 2017 (UTC)[reply]
Ancient Greek ῥηματικός (rhēmatikós, “verbal, pertaining to verbs”)
Ah, I see! Thanks, will fix that. [Already fixed by Metaknowledge!] — SMUconlaw (talk) 10:30, 22 March 2017 (UTC)[reply]
@Metaknowledge, Octahedron80: Actually, I notice that "el" is the correct code for Modern Greek. Why doesn't it work properly in {{der}}? — SMUconlaw (talk) 17:29, 25 March 2017 (UTC)[reply]
"ῥ" is not a character used in modern Greek. DTLHS (talk) 17:33, 25 March 2017 (UTC)[reply]
Oh, I see. Thanks. — SMUconlaw (talk) 17:37, 25 March 2017 (UTC)[reply]

man[edit]

This page is taking ~70.25 MB of Lua memory, which highly exceeds the limit of 50 MB. As a result, it has been having errors of not enough memory. The English section alone takes 41.62 MB of memory, with the translations taking 34.21 MB. How could we solve this problem? --kc_kennylau (talk) 09:09, 22 March 2017 (UTC)[reply]

These Lua memory errors are fickle. I wonder what caused the problem to appear this time. One thing that might help is using {{t-simple}} for some of the languages in the Translations section. — Eru·tuon 09:18, 22 March 2017 (UTC)[reply]
Do problems also occur on woman, which also has a lot of translations (second only to water, I think)? If it persists I suppose more thorough testing is in order, e.g. taking out all languages with auto-transliteration, then putting them back and taking out all languages like Chinese that invoke big central modules containing lots of characters, ... - -sche (discuss) 16:32, 22 March 2017 (UTC)[reply]

Standard Estonian[edit]

Just FYI, there is a "Lua error" when attempting to add translations using ISO 639-3 EKK (Standard/North Estonian). It should redirect to ISO 639-1 ET (Estonian). Nicole Sharp (talk) 10:15, 22 March 2017 (UTC)[reply]

We don't do redirects/aliases for language codes. —CodeCat 13:41, 22 March 2017 (UTC)[reply]
We don't always do redirects/aliases, but User:Conrad.Irwin/editor.js does actually have the capacity for it, used on some codes like act, and guj to gu. I've updated it to also convert ekk to et. Somewhat orthogonal, but relevant if we ever try to convert that script to use only the Lua data modules without losing functionality (we especially would benefit from retaining its ability to recognize [at least unique] non-canonical names), it would seem that in the case of most language mergers, where one code is subsumed into only one other code, that data could be added to the modules, similar to how "parents" were added to the module. (Some mergers and splits would be harder to encode, and impossible to use in the translation-adder, because a few codes like ghc are merged context-dependently into two other codes.) - -sche (discuss) 16:17, 22 March 2017 (UTC)[reply]
And to be absolutely clear, this "alias" (ekk→et) only works when adding translations using User:Conrad.Irwin/editor.js; ekk cannot be used in other contexts, because as CodeCat correctly notes, we don't do redirects for language codes. But if we added information about "subsumed codes" to the language-data modules, perhaps we could, but we'd have to discuss whether or not it'd be desirable. - -sche (discuss) 16:20, 22 March 2017 (UTC)[reply]
We'd need redirects for all template names too. Probably not worth the trouble. —CodeCat 16:23, 22 March 2017 (UTC)[reply]

Edit request[edit]

Please add 

translit_module = "shn-translit",

to m["shn"] in Module:languages/data3/s. Thanks. Wyang (talk) 11:52, 23 March 2017 (UTC)[reply]

@Wyang: Done. —JohnC5 15:02, 23 March 2017 (UTC)[reply]

Lua memory errors[edit]

de currently has a Lua memory error, as happens very often.

It may be because of my changes to Module:links allowing unsupported titles to be linked to, since that may have added a certain amount of memory to every instance of linking and etymology templates.

I also created a function in Module:letters to generate letter name lists in entries (such as {{list:Latin script letter names/la}}). I thought would lower memory usage, but it appears to have had the opposite effect.

I wish there were a more effective way to lower memory usage. I suspect much of the problem is the large language data modules, but I am not sure how much of their data is loaded in each instance of the linking and etymology templates, or how redundantly or repetitively the data is loaded. — Eru·tuon 22:23, 24 March 2017 (UTC)[reply]

I don't have time to see if this is an actual problem but one way to get memory usage down is to minimize string concatenation. DTLHS (talk) 22:25, 24 March 2017 (UTC)[reply]
@DTLHS: The language data modules do not seem to be the problem. {{R:M&A}} (powered by Module:R:M&A) are using a huge amount of memory: when I remove the template from the page, Lua memory usage goes from 50.14 MB all the way down to 34.58 MB, a difference of about 15 MB (!). It uses Module:data tables to retrieve its data from data submodules. Would you, or someone else (@Isomorphyc?), mind looking at these modules to see if there's a way to reduce the template's Lua memory usage? Its complexity is above my ability to understand. — Eru·tuon 23:43, 24 March 2017 (UTC)[reply]
The amount of memory being used by {{R:M&A}} is puzzling; the page lengths of the submodules of Module:data tables that de is listed as transcluding do not add up to 15 MB, by my calculation. — Eru·tuon 23:48, 24 March 2017 (UTC)[reply]
I know that Isomorphic worked a lot on these modules to reduce memory usage. I don't know how they work either. DTLHS (talk) 00:01, 25 March 2017 (UTC)[reply]
@Erutuon, DTLHS: Sorry I've been away so much more than intended. I will make a temporary fix in the next couple of days, but in the longer term I am beginning to feel that of the templates/modules supported by Module:data tables, the non-externally-linking dictionaries, {{R:M&A}} and {{R:Woodhouse}}, which consume >90% of the resources in Module:data tables should be moved in functionality to Wikimedia Tool Labs, because Wiktionary's infrastructure is not very compatible, and a more general solution would be helpful elsewhere. That said, it is likely my immediate fix will be to remove or special-case the R:M&A links in de and a few other extremely common words. It turns out these tables only have outrageously high memory usage in half a dozen or a dozen entries for common words requiring, as it were, a large number of separate headword lookups to build a full thesaurus entry. All these headword entries and their hash table collisions have to be loaded into memory to do this. Looking at some Greek entries it also appears that I need to take a look at some {{R:Middle Liddell}} module errors. Hope to see you all more actively very soon. Isomorphyc (talk) 00:05, 25 March 2017 (UTC)[reply]
@Isomorphyc: Ah, the {{R:Middle Liddell}} error was my fault. It's now fixed. — Eru·tuon 00:41, 25 March 2017 (UTC)[reply]
@Erutuon, DTLHS, Metaknowledge I made a special case for `de' in this file: Module:R:M&A/memory_special_cases. This can generally be done as needed, though if the special case file gets long, separate files should be made for each case. These are the 24 words with the longest lists of phrases: in: 602, ad: 261, de: 211, res: 203, et: 156, facio: 137, ex: 121, habeo: 102, a: 89, do: 86, cum: 86, ut: 84, animus: 76, dico: 72, verbum: 71, ab: 69, non: 67, tempus: 64, ago: 60, littera: 59, ratio: 56, sum: 55, hostis: 54. At this time, I haven't edited any of these other than `de.' OrphicBot did not add references to a few of these for various reasons, either I omitted them deliberately or the pages contained invalid wikitext. Initially, I was going to say that the list is not terribly useful to most people; in fact I hesitated to add it back, and I would not object if anyone still wanted to omit it. But given that preposition usage is subtle, and that I have more than a few usages to learn from the list, I thought it worth adding back preliminarily. It would be nice if there were a more relevant place to collect n-grams and phrases though; I might work on this later. Thanks to all for the attention to this. Isomorphyc (talk) 20:53, 26 March 2017 (UTC)[reply]

Blocked repeatedly from creating my user page[edit]

I'm being disallowed from making the first edit of my Wiktionary user page, the same edit I have currently on my Wikipedia Commons, by some automatic process.

It said to report it here.

Edit request to Module:pt-noun[edit]

Please replace line 107 with: 

return m_headword.full_headword({lang = lang, pos_category = "nouns", heads = {head}})

—CodeCat 14:11, 25 March 2017 (UTC)[reply]

@CodeCat: I inserted the following instead
return m_headword.full_headword({lang = lang, pos_category = "nouns", heads = {head}, categories = {}})
because otherwise on previewing centavo gives "Lua error in Module:headword at line 402: bad argument #1 to 'insert' (table expected, got nil)". --kc_kennylau (talk) 14:29, 25 March 2017 (UTC)[reply]
That works too, thanks. —CodeCat 14:33, 25 March 2017 (UTC)[reply]

Independent toggling for subtables[edit]

@Metaknowledge and I are working on a new table system for Swahili verbs (found here), and we wanted to have collapsed subtables. We'd like a way to make the main table expand without having the subtables expand. I asked @CodeCat for help fixing this problem in this discussion, but sysop permissions are required. I was wondering whether anyone else could help with this. —JohnC5 18:39, 25 March 2017 (UTC)[reply]

As a hint for whoever wants to give it a try, essentially the problem lies in lines 653 and 654 of MediaWiki:Gadget-legacy.js. These lines select the elements that are to be shown/hidden when the button is pressed. Currently, they select all subelements with the necessary CSS classes, but this includes the elements belonging to the subtable. To fix it, any subelement whose class is vsSwitcher, as well as any of its child elements, should be excluded from the selection. —CodeCat 18:45, 25 March 2017 (UTC)[reply]
@JohnC5 With some help from friends, I've come up with something that may work. For line 653, the code should become:
var elemsToHide = $(rootElement).find(".vsHide").not($(rootElement).find(".vsSwitcher").find(".vsHide"))
If I'm right, this should first find all child vsSwitcher elements, and then find vsHide elements that are children of that. Then, those are subtracted from the existing list of vsHide elements. Line 654 should be equivalent, but with Show instead, and line 657 should be equivalently replaced but with vsToggleElement. This code is untested, just as a warning. —CodeCat 16:31, 28 March 2017 (UTC)[reply]
Alternatively, the last find(".vsHide") can also be replaced with find("*"), which just selects all descendant elements of the vsSwitcher. Perhaps this could then even be saved in a variable so that it's reused 3 times, rather than doing the search three times. It would be faster that way. —CodeCat 16:47, 28 March 2017 (UTC)[reply]
@CodeCat: So should I just alter line 653 as indicated, or should I wait until this more efficientfind("*") solution is worked out? —JohnC5 17:23, 28 March 2017 (UTC)[reply]
Here's the full code, for clarity:
	var toSkip = $(rootElement).find(".vsSwitcher").find("*")
	var elemsToHide = $(rootElement).find(".vsHide").not(toSkip)
	var elemsToShow = $(rootElement).find(".vsShow").not(toSkip)
	
	// Find the element to place the toggle button in.
	var toggleElement = $(rootElement).find(".vsToggleElement").not(toSkip)
—CodeCat 17:26, 28 March 2017 (UTC)[reply]
@CodeCat: I've made the change. Do I need to clear my cache or something to see the effects? —JohnC5 17:34, 28 March 2017 (UTC)[reply]
Not sure. —CodeCat 17:36, 28 March 2017 (UTC)[reply]
Oh, I noticed I forgot the semicolons at the end of the line. Can you add those? I'm so used to Lua and Python, I don't think to add them anymore. —CodeCat 17:37, 28 March 2017 (UTC)[reply]
@CodeCat: That did the trick. Works like a charm. —JohnC5 17:40, 28 March 2017 (UTC)[reply]
@JohnC5: I don't understand what the problem was in the first place. Collapsed subtables have always been possible. See for example the conjugation of Yiddish זאָגן (zogn). --WikiTiki89 22:16, 29 March 2017 (UTC)[reply]
@Wikitiki89: Mod:yi-verb is using the <div class="NavFrame" style="width:56em"><div class="NavHead" style="background:#ccccff">{title}</div><div class="NavContent"> style table as opposed to the {| class="inflection-table vsSwitcher vsToggleCategory-inflection" type of togglable table which {{sw-conj/table}} uses. —JohnC5 22:22, 29 March 2017 (UTC)[reply]
@Wikitiki89: Speaking of Yiddish conjugation, do you have any interest in finishing the work on that any time soon? —Μετάknowledgediscuss/deeds 22:40, 29 March 2017 (UTC)[reply]
I have a lot of interest, but very little spare brain power. If it helps, I haven't forgotten about it and do indeed feel guilty about it at least once a week. --WikiTiki89 14:45, 30 March 2017 (UTC)[reply]
That's more often than I feel bothered by its lack, so I guess the situation is treating me better than you! —Μετάknowledgediscuss/deeds 15:16, 30 March 2017 (UTC)[reply]

Transwiki[edit]

Hey. We don't do Transwikiing anymore, do we? --G23r0f0i (talk) 19:39, 26 March 2017 (UTC)[reply]

Nah, not really. But Wikipedia still thinks we do. —Μετάknowledgediscuss/deeds 19:43, 26 March 2017 (UTC)[reply]

MediaWiki:Accesskey-ca-nstab-appendix[edit]

Could an admin add "c" to this page? That way one can press Alt+C when on an Appendix talk page, history page, etc, to get to the main page. Jon Harald Søby (talk) 09:29, 27 March 2017 (UTC)[reply]

 Done - -sche (discuss) 05:55, 28 March 2017 (UTC)[reply]

Message for template-protected pages[edit]

The template editor group was created on October 19 after a vote. But the message at the top of the edit window on template-protected pages (for instance, Module:headword) still says “This page has been locked so that only users with sysop privileges can edit it.” Can someone fix this? — Eru·tuon 00:34, 28 March 2017 (UTC)[reply]

All I found was MediaWiki:Protectedpagewarning- should it be changed to "sysops and template editors"? I don't know if it's possible to differentiate the two groups in the warning message. DTLHS (talk) 04:06, 28 March 2017 (UTC)[reply]
It is possible, you can use a switch statement on protection level. I made a change so that the template editor protection level indicates that template editors are able to edit, feel free to amend it as you see fit here. - TheDaveRoss 23:58, 30 March 2017 (UTC)[reply]
Looks better. Thanks! — Eru·tuon 00:17, 31 March 2017 (UTC)[reply]
@DTLHS, TheDaveRoss: Actually, there's a syntax error: the {{#switch:}} parser function isn't closed, so it causes the whole page to be bolded when you're in edit mode. — Eru·tuon 00:39, 31 March 2017 (UTC)[reply]
Fixed. DTLHS (talk) 00:41, 31 March 2017 (UTC)[reply]
Thanks to you both, this is why I can't have nice things. - TheDaveRoss 00:58, 31 March 2017 (UTC)[reply]

Problem with Module:en-headword?[edit]

I've been working on entries lately, and I noticed that every page I edited in the past hour or two lost CAT:English nouns from the bottom of the page and gained CAT:head tracking/unrecognized pos. I tried entries with other parts of speech, and the ones with a template that used Module:en-headword lost the cat for that POS, but those that used {{head}} weren't affected. If I'm not mistaken, it's only a matter of time before CAT:English nouns is empty and CAT:head tracking/unrecognized pos starts to look like CAT:English nouns. When I first looked at CAT:head tracking/unrecognized pos, it had 11,000 entries. It now has 19,000.

Something is seriously wrong. Chuck Entz (talk) 03:51, 28 March 2017 (UTC)[reply]

By looking at the subtemplates of Template:tracking being transcluded on the page, you can find out what the unrecognized POS is. Apparently in the case of aasvoel, it's "countable nouns". Apparently that is being passed as pos_category to Module:headword, but strangely I can see nothing in Module:en-headword that would do that. — Eru·tuon 04:13, 28 March 2017 (UTC)[reply]
The problem must be with Module:headword, because other languages are also losing members of their basic POS categories. — Eru·tuon 04:30, 28 March 2017 (UTC)[reply]
Yes, my edit history shows the problem started right after your series of edits to Module:headword about three hours ago. Chuck Entz (talk) 04:35, 28 March 2017 (UTC)[reply]
That seems to be correct. I am not sure how my edits caused the problem, but I think it's fixed now. — Eru·tuon 05:23, 28 March 2017 (UTC)[reply]
My edits aren't causing the category changes anymore, so I think it's fixed, too. Thanks! Chuck Entz (talk) 05:31, 28 March 2017 (UTC)[reply]

Widespread Lua errors[edit]

I am seeing widespread Lua errors apparently in {{der}} and {{etyl}}. Purging does not remove them. — Cheers, JackLee –talk– 04:42, 29 March 2017 (UTC)[reply]

They are @Erutuon's doing, but I assume they are being fixed. —JohnC5 04:44, 29 March 2017 (UTC)[reply]
Keep calm and do Wiktionary. 😇 --Octahedron80 (talk) 04:49, 29 March 2017 (UTC)[reply]
Fixed. It was a typo I made in the function for {{der}} and {{etyl}} in Module:etymology. — Eru·tuon 05:21, 29 March 2017 (UTC)[reply]
Thanks! — Cheers, JackLee –talk– 06:55, 29 March 2017 (UTC)[reply]

Hiding quotations[edit]

Sometimes quotations are given a separate section, like here at Lawrence. Can they be hidden, using templates like {{quote-top}} and {{quote-bottom}}, or should they be treated in the conventional manner, without a separate section? DonnanZ (talk) 09:37, 29 March 2017 (UTC)[reply]

I didn't mean to ruin your plan of using Lawrence as an entry example, but I moved all the quotations to the appropriate senses and deleted the "Quotations" header there. I believe this was discussed before: IMO, the correct course of action is doing this for all entries. If a given quotation is so ambiguous that you don't know what is the correct sense, it should probably be moved to the "Citations:" namespace because maybe it doesn't serve well the purpose of illustrating a sense in the first place. --Daniel Carrero (talk) 09:41, 29 March 2017 (UTC)[reply]
OK, that's much better, thanks. I didn't add the quotations, I just wasn't sure what the policy on separate quotations sections is. Obviously they shouldn't exist. DonnanZ (talk) 09:52, 29 March 2017 (UTC)[reply]
I believe we don't have a policy about the maintenance of separate Quotations sections other than the idea of just deleting them all eventually. (Wiktionary:Quotations is think tank and mostly deals with formatting)
Arguably, creating {{quote-top}} and {{quote-bottom}} at least has the advantage of being bottable: someone could probably create the templates and add them automatically in all entries, assuming we get consensus for the idea. A bot can't move the quotations to the respective senses. Naturally, moving the quotations to the senses also does the job of hiding the quotations.
When Wiktionary is "done", apparently we'll have deleted all quotations headers and those templates too, so at best they would be supposed to stay temporarily. --Daniel Carrero (talk) 10:09, 29 March 2017 (UTC)[reply]
Can it be determined how many entries have a "Quotations" header? DonnanZ (talk) 10:34, 29 March 2017 (UTC)[reply]
The search "insource:quotations insource:/==\s*Quotations\s*==/" indicates that 4,156 have a quotations section, many of those have a {{seeCites}} template only. - TheDaveRoss 12:27, 29 March 2017 (UTC)[reply]
In Wiktionary:Votes/2016-02/Removing "Quotations", last year, I suggested allowing bots to remove all instances of the "Quotations" header with {{seeCites}}. Result of the proposal: 9-7-1 (no consensus). I still think removing them all by bot would be a great idea, but it's OK that some people disagree.
Apparently, {{seeCites}} serves as the only way to reach the citations page if the reader is on mobile or lacks JavaScript, but I believe adding {{seeMoreCites}} under each sense when applicable does the job for these readers. Naturally, this requires editing the entries manually. --Daniel Carrero (talk) 12:41, 29 March 2017 (UTC)[reply]
Well, 4156 entries with quotations headers is more than I expected. The vote (which I missed, and apparently it has never been closed) shows no universal support for removal of the headers. I have no objection to the headers, providing the contents of the section can be hidden, so {{quote-top}} and {{quote-bottom}} templates seem like a good idea after all. But I never "go mobile", and I don't know how it would affect those that do. DonnanZ (talk) 13:46, 29 March 2017 (UTC)[reply]
Another (unmodified) example is at Douglas. The quotations take up a lot of space in a relatively big entry. DonnanZ (talk) 10:05, 30 March 2017 (UTC)[reply]
I suggest creating a vote with two separate proposals:
  1. Allowing the "Quotations" section to be deleted in all entries, -- I mean, manually, not by bot. The quotations found in that section can be moved to their respective senses.
  2. Allowing bots to add {{quote-top}} and {{quote-bottom}} to the "Quotations" section in all entries to hide the quotations.
I would probably support both options. I have this in mind: if both options pass, I would like to use these templates to populate a category named like Category:Quotations sections, to find out exactly which entries have that section to be deleted. --Daniel Carrero (talk) 10:20, 30 March 2017 (UTC)[reply]
I would support option 2, which would appear to be less "hard work", and give a more instantaneous result. DonnanZ (talk) 10:48, 30 March 2017 (UTC)[reply]

Read-only mode for 30 minutes on two days[edit]

The time for the server switch project has been confirmed. All of the wikis will be in read-only mode for 20 to 30 minutes on two days soon:

  • Wednesday, 19 April 2017, starting at 14:00 UTC
  • Wednesday, 3 May 2017 (two weeks later), starting at 14:00 UTC

If you are a MediaWiki hacker, then please note that the normal deployment schedule has been canceled during both of those weeks.

There is more information at m:Tech/Server switch 2017, including a link to the official schedule. Please leave a message on my user talk page or "ping" me if you have any questions. Whatamidoing (WMF) (talk) 22:05, 29 March 2017 (UTC)[reply]

Layout bug affecting IE and Edge browsers[edit]

The screenshot on the right (article trompe l'oeil) illustrates a common and long-standing Wiktionary layout problem affecting Microsoft browsers (IE and Edge), whereby a large amount of unwanted whitespace is left next to images. Mihia (talk) 21:01, 30 March 2017 (UTC)[reply]

It's the WOTD that causes the problem. It can be fixed by moving the image down a wee bit.  Done DonnanZ (talk) 22:32, 30 March 2017 (UTC)[reply]

There is a note in the documentation for {{was wotd}} "If you prefer the older layout with this template fixed in the upper right, ..." that has made me wonder whether the WOTD message is intended to appear on the left. On my IE browser it appears on the right as shown in the screenshot. This could be the root of the problem. DonnanZ (talk) 08:34, 31 March 2017 (UTC)[reply]

Thanks for fixing it. A quick check of some recent WOTDs shows that nearly all are like it. It would be better to fix the template if possible, rather than go through manually fixing potentially hundreds of pages. By "fix" the template I include the case of adjusting it to work around a bug in MS browers, if in fact it is the browsers that are at fault, not rendering the pages as they should. And/or the procedure for adding the template should be changed to incorporate the adjustment that you made. Mihia (talk) 10:17, 31 March 2017 (UTC)[reply]
It was suggested to me in a previous discussion that Microsoft should fix their bug, and we shouldn't have to do anything. But how on earth do you tell Microsoft? I think we have to find a solution ourselves. Besides that, adding images and {{wikipedia}} to an entry works fine until {{was wotd}} is added, so there's nothing wrong with those two functions. DonnanZ (talk) 12:08, 31 March 2017 (UTC)[reply]
Internet Explorer is a retired product and now receives only critical security patches. There will be no new version. Equinox ◑ 12:30, 31 March 2017 (UTC)[reply]
Mihia says it occurs on Edge as well, which is a new product. I will have to try and check that out. Maybe Chrome too. DonnanZ (talk) 12:43, 31 March 2017 (UTC)[reply]
Yes indeed, it affects Edge too. The problem does not occur for me in Chrome. I wouldn't hold out much hope of Microsoft ever fixing it, if indeed it is their bug. I think it is probably going to be down to Wiktionary to work around it, as you say. Mihia (talk) 13:32, 31 March 2017 (UTC)[reply]
It's that kind of attitude that leads Microsoft not to care enough to fix the bug. --WikiTiki89 19:42, 31 March 2017 (UTC)[reply]
OK, I'll leave it to you to sort it out with Microsoft then. Let me know when it's fixed. Mihia (talk) 20:48, 31 March 2017 (UTC)[reply]
We don't have to do anything. When people stop accommodating Microsoft's bugs, Microsoft's customers will become agitated enough and Microsoft will fix them. --WikiTiki89 20:55, 31 March 2017 (UTC)[reply]
In other words it will never be fixed, except by using the manual method by those that care. Great! One good reason to not nominate any WOTDs. DonnanZ (talk) 21:07, 31 March 2017 (UTC)[reply]
Or someone else will come up with horrible painful hacks to work around them, which then become adopted and force other browser makers to accommodate the hack. (Tantec Celik, I'm looking at you.) Equinox ◑ 21:06, 31 March 2017 (UTC)[reply]
I didn't make any formatting changes to the template, and am not sure what can be done to solve the problem. The template uses the markup "<div class="was-wotd floatright" style="padding-right: 1em">" to position the template, so perhaps there is something in that markup that Internet Explorer, etc., do not like. However, I can relocate the image in new WOTDs as DonnanZ has done, if you would like me to do that. (Seems like something Microsoft should fix, though. I use Mozilla Firefox and don't encounter the problem.) — SMUconlaw (talk) 22:46, 31 March 2017 (UTC)[reply]
Question: how does one set or edit a CSS class like "was-wotd floatright"? Seems like that might be the problem. — SMUconlaw (talk) 22:56, 31 March 2017 (UTC)[reply]
So where does the WOTD message appear on your browser. Left or right? DonnanZ (talk) 23:01, 31 March 2017 (UTC)[reply]
"floatright" was added by User:Bequw on 18 Sept 2011, and style="padding right: 1em" by User:Nbarth on 20 July 2013. I think "floatright" may be the problem, I tried it once before and it didn't have the desired result. DonnanZ (talk) 23:44, 31 March 2017 (UTC)[reply]
The WOTD message appears on the right on my browser. Perhaps we can remove the "floatright" and replace it with some simpler HTML markup, since I'm not sure how to edit our CSS style sheets. (Perhaps someone can advise on the latter?) — SMUconlaw (talk) 15:21, 1 April 2017 (UTC)[reply]
If it's meant to appear on the right, then it should position itself in the same way as {{wikipedia}} does, if that's any help. DonnanZ (talk) 16:16, 1 April 2017 (UTC)[reply]
I'm afraid it doesn't help me as I don't know how to program in Lua. — SMUconlaw (talk) 18:12, 1 April 2017 (UTC)[reply]
Both {{wikipedia}} and {{slim-wikipedia}} included floatright before being rewritten by CodeCat, but as they worked OK before it still doesn't explain why {{was wotd}} misbehaves. DonnanZ (talk) 09:26, 2 April 2017 (UTC)[reply]
Maybe "padding-right: 1em" can have "-right" removed, or should have a semi-colon (1em;"). Or maybe I haven't got a clue. DonnanZ (talk) 09:52, 2 April 2017 (UTC)[reply]
I tried changing class="floatright" to style="float:right;"; it made no difference so I reversed the edit. I'm afraid someone more familiar with CSS style sheets will have to look into the matter. — SMUconlaw (talk) 13:49, 2 April 2017 (UTC)[reply]
I don't have permission to edit the page, otherwise I would experiment. I did look here, which prompted the suggestions above diff. DonnanZ (talk) 14:04, 2 April 2017 (UTC)[reply]
You could create a sandbox at "Template:was wotd/sandbox" and experiment with that. — SMUconlaw (talk) 14:15, 2 April 2017 (UTC)[reply]
I haven't even used a sandbox before: I may try that later when I get my Internet WiFi sorted out (adapter problems, keeps switching off). DonnanZ (talk) 15:22, 2 April 2017 (UTC)[reply]
Great. Using a sandbox helps to avoid errors from affecting actual pages, and you can test the sandbox template by creating a testcases page like "Template:was wotd/testcases". — SMUconlaw (talk) 17:15, 2 April 2017 (UTC)[reply]

"Look up" field on Main Page[edit]

Is there any reason why the "Look up" field on the Main Page does not have a drop-down list of suggestions like the "Search Wiktionary" field does? Mihia (talk) 22:02, 30 March 2017 (UTC)[reply]

Module error at MediaWiki:Gadget-TranslationAdder.js[edit]

MediaWiki:Gadget-TranslationAdder.js has been in CAT:E for several days now, but I have no idea why. Anyone have an idea of what might be happening and how it can be fixed (that is, the page removed from the category)? — Eru·tuon 19:38, 31 March 2017 (UTC)[reply]

I think line 1533 is being parsed as wikitext. Try closing the nowiki from line 1. —suzukaze (t・c) 23:50, 31 March 2017 (UTC)[reply]
When I preview the page with a closing nowiki added as the last line, it is still in CAT:E, and likewise when I take out the "subst"s (just to check if they're the cause), so neither of those seems to be the culprit. Does the opening nowiki still need to be there? By the way, I suspect the module error is not new: but when the script was in userspace, it would have been in the "hidden" subcategory of CAT:E. - -sche (discuss) 04:20, 1 April 2017 (UTC)[reply]
@-sche: that's probably a bug. After the edit it won't be in the category (I tested it). So just go ahead and add the enclosing tag at the end. --Dixtosa (talk) 18:38, 29 April 2017 (UTC)[reply]
 Done. - -sche (discuss) 19:24, 29 April 2017 (UTC)[reply]
MediaWiki:Common.css needs nowiki tags too.--Dixtosa (talk) 19:46, 29 April 2017 (UTC)[reply]
@-sche: CSS does not support double slash comments. Use /**/.--Dixtosa (talk) 20:31, 29 April 2017 (UTC)[reply]
Aha, thanks for pointing that out. By the way, MediaWiki:Common.css was not in CAT:E as recently as when this thread was first opened, when the translation-adder was the only MediaWiki page I saw in there; I wonder what caused it to start being in the category. - -sche (discuss) 04:23, 30 April 2017 (UTC)[reply]
I don't know that it's a bug, but the section where it shows membership in hidden categories doesn't reflect anything in the previewed content. I see a lot of cases where the preview before a null edit that will clear a module error shows CAT:E in that section before I click "Publish changes". Also, if you preview with a module error in the wikitext (I just tried it with {{l|}}), it shows the module error in the preview, but it doesn't show CAT:E in that section. Chuck Entz (talk) 20:26, 29 April 2017 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2017/March&oldid=65118057"