Hello, you have come here looking for the meaning of the word Wiktionary:Grease pit/2017/March. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Grease pit/2017/March, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Grease pit/2017/March in singular and plural. Everything you need to know about the word Wiktionary:Grease pit/2017/March you have here. The definition of the word Wiktionary:Grease pit/2017/March will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Grease pit/2017/March, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
{{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)
@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·tuon22:34, 1 April 2017 (UTC)
@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. —CodeCat00:39, 7 March 2017 (UTC)
Automating rhymes
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 ] and then just transclude them. @CodeCat (I don't know whom to ping about rhyme stuff. Does anyone work on this?) —JohnC503:33, 7 March 2017 (UTC)
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·tuon05:02, 7 March 2017 (UTC)
I was honestly thinking first for the automated pronunciation modules first (Catalan, for example, or Latin if that makes any sense). —JohnC505:30, 7 March 2017 (UTC)
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)
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)
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. —JohnC515:15, 7 March 2017 (UTC)
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)
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)
@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)
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·tuon21:12, 8 March 2017 (UTC)
Those are contexts, because they specify senses that occur only when the verb is used transitively or intransitively. —CodeCat21:53, 8 March 2017 (UTC)
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·tuon22:11, 8 March 2017 (UTC)
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·tuon22:12, 8 March 2017 (UTC)
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)
@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·tuon20:21, 10 March 2017 (UTC)
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)
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·tuon20:31, 10 March 2017 (UTC)
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”)). --WikiTiki8920:45, 10 March 2017 (UTC)
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·tuon20:48, 10 March 2017 (UTC)
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. --WikiTiki8920:58, 10 March 2017 (UTC)
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. --WikiTiki8921:15, 10 March 2017 (UTC)
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·tuon21:27, 10 March 2017 (UTC)
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. --WikiTiki8920:46, 15 March 2017 (UTC)
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)
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)
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·tuon21:46, 10 March 2017 (UTC)
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. --WikiTiki8920:33, 15 March 2017 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
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·tuon20:49, 15 March 2017 (UTC)
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)
Unicode 10.0.0 Beta
Unicode version 10.0.0 beta is available if you are interested. 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 . The final version will be released in June. See you soon. --Octahedron80 (talk) 04:59, 10 March 2017 (UTC)
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)
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)
@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·tuon20:25, 11 March 2017 (UTC)
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.orghttps://dictious.com/en/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)
@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)
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)
Documentation says that second parameter is needed/mandatory, or otherwise would be requested, but example ride shows in =Etym section that can be used for only state the language name. Is this correct? Sobreira ►〓 (parlez)18:46, 12 March 2017 (UTC)
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)
Actually, at the moment, there isn't an error if you don't add a term: {{cog|en}} → English . 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·tuon20:36, 12 March 2017 (UTC)
@Erutuon: I believe at some point in your recent edits you removed the ability of these templates to show and place entries in categories like Category:English term requests. I believe I was able to restore it now. The 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)
@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·tuon07:33, 14 March 2017 (UTC)
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·tuon08:08, 14 March 2017 (UTC)
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? —CodeCat20:59, 12 March 2017 (UTC)
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·tuon21:16, 12 March 2017 (UTC)
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. —CodeCat21:18, 12 March 2017 (UTC)
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)
@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·tuon18:36, 13 March 2017 (UTC)
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)
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:
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.
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·tuon08:25, 14 March 2017 (UTC)
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·tuon09:43, 14 March 2017 (UTC)
@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·tuon19:00, 14 March 2017 (UTC)
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)
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)
This seems at least as subjective as the "politically correct" category that was being mooted for removal. Equinox◑19:24, 15 March 2017 (UTC)
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)
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)
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)
Why does "Move page" have a stupid crippled button?
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)
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. DCDuringTALK22:58, 15 March 2017 (UTC)
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)
etytree, a graphical and multilingual etymology dictionary based on Wiktionary: feedback and endorsement
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.
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)
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)
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).
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)
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)
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? —CodeCat17:43, 18 March 2017 (UTC)
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)
In FF 52.0.2, but not MS Edge , 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.) DCDuringTALK00:51, 20 March 2017 (UTC)
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)
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·tuon01:19, 21 March 2017 (UTC)
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. DCDuringTALK12:13, 21 March 2017 (UTC)
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. DCDuringTALK23:07, 21 March 2017 (UTC)
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)
The last version of FF as of today is 52 0 1. Are you using pre-release version? Anyways make a screenshot of browser's console (by pressing F12)--Dixtosa (talk) 16:38, 22 March 2017 (UTC)
I am using FF 52.01. My lysdexia may have been acting up when I reported a different version. See above for the status of resolution. DCDuring (talk) 17:06, 22 March 2017 (UTC)
The problem: A little too easy to turn YesScript on (and off). I had accidentally blocked all JS scripts from running on Wiktionary. If I went to more weird sites it might be worth having the capability. DCDuring (talk) 20:01, 22 March 2017 (UTC)
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)
The {{der}} template is not handling some Greek transliterations properly. For example, {{der|en|el|ῥηματικός||], pertaining to ]s}} (at rhematic) does not render the ῥ as rh:
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)
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·tuon09:18, 22 March 2017 (UTC)
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)
Standard Estonian
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)
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 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)
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)
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·tuon22:23, 24 March 2017 (UTC)
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)
@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·tuon23:43, 24 March 2017 (UTC)
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)
@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)
@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)
I have seen this before. You are using a hyperlink instead of a wikilink. Some wikis block new users from creating pages with hyperlinks. Not sure if that is the same issue here or not. Nicole Sharp (talk) 14:04, 25 March 2017 (UTC)
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)
@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. —JohnC518:39, 25 March 2017 (UTC)
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. —CodeCat18:45, 25 March 2017 (UTC)
@JohnC5 With some help from friends, I've come up with something that may work. For line 653, the code should become:
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. —CodeCat16:31, 28 March 2017 (UTC)
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. —CodeCat16:47, 28 March 2017 (UTC)
@CodeCat: So should I just alter line 653 as indicated, or should I wait until this more efficientfind("*") solution is worked out? —JohnC517:23, 28 March 2017 (UTC)
Here's the full code, for clarity:
vartoSkip=$(rootElement).find(".vsSwitcher").find("*")varelemsToHide=$(rootElement).find(".vsHide").not(toSkip)varelemsToShow=$(rootElement).find(".vsShow").not(toSkip)// Find the element to place the toggle button in.vartoggleElement=$(rootElement).find(".vsToggleElement").not(toSkip)
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. —CodeCat17:37, 28 March 2017 (UTC)
@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. —JohnC522:22, 29 March 2017 (UTC)
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. --WikiTiki8914:45, 30 March 2017 (UTC)
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)
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·tuon00:34, 28 March 2017 (UTC)
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. - TheDaveRoss23:58, 30 March 2017 (UTC)
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·tuon04:13, 28 March 2017 (UTC)
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)
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)
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)
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)
The search "insource:quotations insource:/==\s*Quotations\s*==/" indicates that 4,156 have a quotations section, many of those have a {{seeCites}} template only. - TheDaveRoss12:27, 29 March 2017 (UTC)
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)
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)
I suggest creating a vote with two separate proposals:
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.
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)
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)
Read-only mode for 30 minutes on two days
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:
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)
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)
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)
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)
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)
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)
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)
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. --WikiTiki8920:55, 31 March 2017 (UTC)
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)
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)
@Smuconlaw: Only template editors and administrators can edit the template anyway. Smuconlaw did some alterations some months ago, but the problem existed before then. DonnanZ (talk) 22:17, 31 March 2017 (UTC)
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)
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)
"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)
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)
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)
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)
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)
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)
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)
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)
@-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)
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)
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)
Done DonnanZ (talk) 22:32, 30 March 2017 (UTC)
Done. - -sche (discuss) 19:24, 29 April 2017 (UTC)