Hello, you have come here looking for the meaning of the word Wiktionary:Grease pit/2019/May. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Grease pit/2019/May, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Grease pit/2019/May in singular and plural. Everything you need to know about the word Wiktionary:Grease pit/2019/May you have here. The definition of the word Wiktionary:Grease pit/2019/May will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Grease pit/2019/May, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
I don't know why, but when I change the level 4 header ("Terms (or senses of terms) I've come across while reading") to a level 3 header, the toggle buttons show up again and the lists in that section can be shown and hidden. — Eru·tuon05:30, 1 May 2019 (UTC)
I noticed that too. My guess is that there's some kind of interference that's blocked when the rels are enclosed in the section that the L3 header creates. If you put an L3 header in between the rels, the ones before it are bad, but the ones after it are ok. If you remove the following header the rels after it are bad up until the next L2 or L3 header
"Translations missing" on an entry with no quotations
the Appendix:Capital Letters is linked to by the Category:German usage examples with the translation missing even though it's German section doesn't have any (untranslated) Usage Examples that I could find. Could someone explain how and why?
Anatol Rath (talk) 17:57, 2 May 2019 (UTC)
There's a German usage example of the capitalization of the Tetragrammaton in the Translingual section. The English example above it already means the same thing. Is there a way to tell the template that no translation is needed? (I was going to just move the English example to the translation section, but then I realized that it would be odd, given that it's illustrating capitalization, not a German word.) Andrew Sheedy (talk) 22:39, 3 May 2019 (UTC)
"attributive form of" template
Something has gone wrong with this template. {{attributive form of|en|blah blah}} expands to "attributive formal of blah blah" -- it says "formal" rather than "form". I don't understand templates, so someone else will need to look at it. Mihia (talk) 22:07, 2 May 2019 (UTC)
I'm confused about how categories work. I know that at the basic level, they can be added manually to a page by editing in "Category:(category name)" in double square brackets. But some pages seem to get added to categories automatically somehow. I think it may have to do with templates, but I don't know how to find out which template is responsible for adding which category. For example, there is a category Latin second conjugation verbs with perfect in -s- or -x-; the pages adhaereo and polluceo seem to be included in this category automatically, but the page eluceo was not (I added the category to this page manually). I can't figure out why eluceo behaves differently: all three pages use the la-conj-2nd template, which includes an argument for the stem of the perfect. --Urszag (talk) 17:37, 3 May 2019 (UTC)
You can experiment by removing templates and seeing what categories are removed along with them (in the preview). In this case the category is added by {{la-conj-2nd|adhaer|adhaes|adhaes|type=nopass}}DTLHS (talk) 17:43, 3 May 2019 (UTC)
All categories are added using ] links. Some of these links are in the output of templates, some in the wikitext of the entry. For instance, if you view the output of {{head|en|noun}} by entering {{head|en|noun}} in the "input wikitext" box in Special:ExpandTemplates after adding "word" in the "context title" box and then click the "ok" button, you'll see category links in the "result" box: ]].
Yes, I think the module should ignore macrons. I shouldn't add a macron to the perfect stem because I don't know that the vowel is long: it's possible in principle for the present stem and the perfect stem of a Latin verb to have different vowel quantities. (In fact, the reason why I was originally looking through this category was to see how we had marked vowel quantities in these kinds of perfects.) --Urszag (talk) 18:09, 3 May 2019 (UTC)
Another verb that isn't in this category is stringo (perfect strīnxī). The module strips the final consonants from string (stri) and then adds x (strix) and compares that to the perfect stem. I could implement a more sophisticated check or simply have the module add the category in all cases in which the perfect stem ends in s or x. The latter is probably not such a good idea. — Eru·tuon18:15, 3 May 2019 (UTC)
The distinction that seems to currently be set up between categories for "irregular perfects" and "perfects in -s- or -x-" does seem odd to me. I think of these as overlapping categories: for example, the verb iubeo has the perfect iussi, which is "irregular" (from a certain point of view) but which also fairly clearly contains an -s- element. I feel like it is not that easy or useful to distinguish "irregular" s/x perfects from other kinds of perfects. I agree that it might be an error to just look at the last letter of the perfect stem, but maybe the check could be for whether there is an s or x in the perfect stem that does not exist in the present stem--Urszag (talk) 18:18, 3 May 2019 (UTC)
That is to say, I guess I'd be in favor of a more sophisticated check. I'll go over the examples of verbs with perfects like this that I know of and get back to you later today with a more thought-out idea for a test that would give more comprehensive coverage of different kinds of perfects ending in -si and -xi.--Urszag (talk) 18:22, 3 May 2019 (UTC)
In the meantime, I added a fairly decent check. Remove the s or x from the perfect stem, check if the result (ignoring macrons) is a prefix of the present stem. This does add lūceō and stringō to the "perfect in -s- or -x-" categories, though it may have false positives. I suppose it would be a good idea if I got all present and perfect stems from the dump and applied this algorithm to see if it is sometimes inaccurate. — Eru·tuon18:36, 3 May 2019 (UTC)
What about if you checked if the perfect ends in s or x, and then check if the present has the same final consonant as the perfect? Would that result in any false positives/negatives? It's better and more straightforward than trying to find all possible perfect stems and comparing them all to the given one. —Rua (mew) 18:43, 3 May 2019 (UTC)
@Rua: That's a good idea. I gathered all Latin conjugation templates so that to generate a list of all pairs of present and perfect active stems for testing. Trouble is, I can't find documentation for the parameters of Latin conjugation templates that explains in which circumstances the first and second parameters are the present and perfect active stems: if there's no |type= parameter certainly at least. — Eru·tuon19:17, 3 May 2019 (UTC)
Hmm, don't all the templates take the same basic set of parameters, indicating three principal parts, with the template's inherent conjugation providing the fourth? —Rua (mew) 19:22, 3 May 2019 (UTC)
One class of perfects that the current system misses (that I think should be counted as s-perfects) are perfects in -ssi such as jussi, gessi, ussi from jubeo, gero, uro. These are currently categorized as "irregular" perfect forms (as I mentioned earlier), but to me it makes sense to list them as s perfects since that is their historical origin, and even if irregular on a synchronic level they do still have a perfect stem ending in an s that is absent from the present stem.--Urszag (talk) 20:17, 3 May 2019 (UTC)
The rule I proposed above would correctly identify these as s-perfects. The perfect stem ends in -s while the present stem does not, so they are considered s-perfects. —Rua (mew) 20:22, 3 May 2019 (UTC)
In fact, after looking at some descriptions of the Latin perfect system, I think that simply looking at whether the perfect ends in s or x would be an OK system. The form of the perfect stem seems to be fairly restricted; it wouldn't count as a a s/x perfect if it ends in u/v, and unsuffixed perfects seem to very rarely end in the sound /s/. The only verb I've found that might be an exception is viso, visi; but if the module checks for suffixless perfects before checking for s-perfects, I think that would take care of any other verbs that conjugate like that.--Urszag (talk) 20:04, 3 May 2019 (UTC)
This module shows which verb stems would be put in the category by the current rule (1) and by the rule you're proposing (2), which is the same as similar to the one Rua proposed above. Your rule catches some cases that the current rule does not, like adcēdō, adcessī and dīrigō, dīrexī. — Eru·tuon20:17, 3 May 2019 (UTC)
Thanks! I think rule (2) is best, then--I didn't see anything that I would categorize as a false positive.--Urszag (talk) 20:22, 3 May 2019 (UTC)
Whoops, I spoke too soon! For praegaudeo, rule 2 incorrectly picks up the deponent perfect active form "praegāvīsus sum" as a perfect stem. It's actually built on a supine/participle stem. I think more work has to be done to account for verbs with periphrastic conjugation in the perfect tense.--Urszag (talk) 20:24, 3 May 2019 (UTC)
Oh, that's a separate issue; it doesn't have to do with the rules but with the method that I used to extract the list of present and perfect active stems from the Latin conjugation templates. Do you happen to know how to determine whether the second parameter is a perfect active stem as opposed to something else? Particular values of |type=? — Eru·tuon20:28, 3 May 2019 (UTC)
I'm not sure that I know a comprehensive list of types, but praegaudeo has type=semi-depon. Verbs with type=depon also form a periphrastic perfect. The module has the following lines that seem relevant: "typeinfo.subtype:find("depon") then" "typeinfo.pres_stem = if_not_empty(args)" "typeinfo.perf_stem = nil" (sorry for the messy formatting; I couldn't see line numbers on that page) Would it be possible for a rule to check for the perfect stem directly rather than using types? --Urszag (talk) 20:43, 3 May 2019 (UTC)
Is there a place where I can see a list of all of the possible values of the type parameter? Aside from defective and semi-defective verbs, the only other type of verb that I can think of that wouldn't have a paired present stem and perfect active stem is ones like memini and coepi.--Urszag (talk) 21:26, 3 May 2019 (UTC)
(edit conflict) Ahh, thanks, that line was indeed the place where the present and perfect active stems were assigned. So basically the second parameter is the perfect active stem when the verb is not a deponent (and not irregular). Seems quite obvious now. — Eru·tuon21:27, 3 May 2019 (UTC)
Since the new rule relies on the present not having the same s/x as the perfect, and s-presents don't exist in Latin, if the present also has s/x it is an inherent part of the stem and not a suffix for forming the perfect. But we have to consider what the s-perfect would look like for such verbs, too, if they had one. I can imagine that the present might have a single s, which becomes double in the perfect. Such a case would be an s-perfect too, so the rule has to be extended to detect such cases. Such verbs are admittedly rare if they exist at all, because single s normally appears as r in Latin instead. But there may be exceptions. The potential of an s-perfect to a present ending in x or ss also needs to be considered. I believe that in such cases the additional s of the perfect would be entirely absorbed, so that we are not able to see whether it's an s-perfect or not. I think it's ok if we consider them as non-s-perfects. —Rua (mew) 20:30, 3 May 2019 (UTC)
Yes, I agree with what you say about considering any x/ss perfect stems that are identical to a present stem as non-s-perfects. I don't think it would be possible to tell whether a "hidden" s suffix exists in such a case, any more than in the viso/visi case. I think a rule that checks for simple identity of the perfect and present stems first, and only then (if they are different in form) goes on to check whether the perfect stem ends in s or x, will catch all of the cases that you mentioned.--Urszag (talk) 20:36, 3 May 2019 (UTC)
Using {{en-adj}} with words that are both comparable and not comparable
The template {{en-adj}} does not seem to work well with words that have both comparable and uncomparable senses (for example, martial). Can it be updated so that there is a way to display the message "comparable and not comparable"? (I also tried using {{head}} but there didn't seem to be a way to make it display that message.) — SGconlaw (talk) 20:20, 4 May 2019 (UTC)
I would rather suggest that {{en-adj}} concern itself with only whether there are comparative forms or not, and leave the comparability to the individual senses. The same could be done for countability in {{en-noun}} too. —Rua (mew) 20:24, 4 May 2019 (UTC)
Shouldn't there be an indication that a particular adjective is both comparable and not comparable, just as {{en-noun|~}} indicates that a term is both countable and uncountable? Otherwise, the header suggests that the adjective/noun is always comparable/countable, which is then inconsistent with some individual senses being marked uncountable/not comparable. — SGconlaw (talk) 20:29, 4 May 2019 (UTC)
That's what I'm proposing to get rid of. It's more useful to say which specific senses are comparable/uncomparable or countable/uncountable, than to put a rather unspecific statement in the headword line. The headword line doesn't give you enough information to say when it's comparable and when not, so you have to put it next to each sense regardless. And at that point, putting it also in the headword line just duplicates the information for no apparent reason, in a less accurate way to boot. —Rua (mew) 20:39, 4 May 2019 (UTC)
I’m suggesting the reason is not to mislead a reader into thinking that, say, an adjective is always comparable when it is comparable in some cases and not comparable in others. — SGconlaw (talk) 20:53, 4 May 2019 (UTC)
I feel you’re not understanding me. I agree with labelling senses as comparable and not comparable where needed. But if the headword line only shows the comparative and superlative inflections, this may mislead a reader into thinking that the headword is always comparable. — SGconlaw (talk) 02:46, 5 May 2019 (UTC)
I agree from a pure database-schematic standpoint, but I think this needs some "intelligence", e.g. if every sense of a noun is countable then we should prefer "countable" once shown for the whole noun over having it repeated identically on every single sense line. Sadly we don't have a true database schema for the word senses so I would err on the side of readability/simplicity over uniformity. Equinox◑21:12, 4 May 2019 (UTC)
We could decide to label only the uncountable senses, since the presence of a plural already makes countability the default. —Rua (mew) 10:22, 5 May 2019 (UTC)
How are we doing on making sure that every sense of every English noun has been checked for (un)countability? Nowadays it is hard to find an abstract noun that is not used both uncountably (normal usage) and countably ("scholarly" usage). An example is the very word uncountability. If we are to document this, we have a lot of work ahead of us. If we can't even get this done, perhaps we should try to simplify rather than complexify. DCDuring (talk) 21:40, 4 May 2019 (UTC)
I think in general it looks good. For clarity, I would not try to syncretise more than one axis at a time. So something like "weak and mixed genitive and dative all-gender singular" could be split into two lines by weak/mixed or by genitive/dative, with the latter having my preference. Same for "strong and mixed nominative and accusative feminine singular". —Rua (mew) 16:12, 5 May 2019 (UTC)
Go for it. My bot is not running at the moment (since some change in Wiki software made it stop working) but if I ever get it working again, I'll modify the German forms accordingly. SemperBlotto (talk) 16:15, 5 May 2019 (UTC)
I dislike the versions with dashes, to me they make it seem like "weak–mixed genitive–dative" (etc) is a (name for a) form, like a "Hertzsprung–Russell diagram" is a specific diagram and not the combination of a Hertzsprung diagram and a Russell diagram. I doubt it'd be clear to the uninitiated that they're intended instead to separate forms which are merely being combined with each other because they're homographic (especially given that they're still separated from other forms they're also homographic with). I'm not sure why we need to make such incomplete combinations in the first place. The main effect I foresee of any of these proposals, btw, is certain IPs trying to RFV specific forms and/or code custom templates to suppress specific forms because "only the weak masculine and feminine dative singulars are attested, and the strong neuter genitive singular, but not the weak neuter dative singular! it's purveying incorrect information!!"... - -sche(discuss)00:42, 9 May 2019 (UTC)
@-scheUser:Rua suggested slashes, which I agree are even better than en-dashes. Here's a comparison of the same multipart inflection with comma/"and", en-dash and slash (for the word omnibus):
Need help for etymology templates in other Wiktionary
Hello. I'm mostly a contributor in the Indonesian Wiktionary. Several months ago, I tried to copy {{inherited}} and other etymology templates from here in order to use it for etymology sections in id.wikt. I succeeded to make them work but at the end I noticed that the link to Wikipedia in a language name is still in English even though I have translated its name in languages/data. Example of the problem can be found here. You can see that although the text says "bahasa Proto-Jermanik", its link is w:id:Proto-Germanic language instead of w:id:bahasa Proto-Jermanik. I have searched "Proto-Germanic language" in id.wikt to find whether there was any other templates or modules that I need to translate but I found nothing. It seems to me that the modules are getting the names by the language codes from another data but I don't know where and how (I'm not very fluent in modules). Another problem is that the link for reconstructed terms is "Reconstruction:" but I want it to be "Rekonstruksi:". I have also asked this question to the community there but it's small and less active and since the question is technical I thought I would ask here also. Can anyone help me to fix it? Thank you very much. RXerself (talk) 18:02, 5 May 2019 (UTC)
@RXerself: Fixed with this edit. The getWikipediaArticle function is used to get the name of page in the link. In this case, it was getting it from Wikidata, and was returning the name of the article on the English Wikipedia rather than the Indonesian Wikipedia. — Eru·tuon18:18, 5 May 2019 (UTC)
@RXerself I notice that the Indonesian Wiktionary doesn't currently have its own "Rekonstruksi" namespace. You need to have that created first, otherwise it won't work properly. I'm not entirely sure what the process is for creating new namespaces, but I know that you can't do it within Wiktionary itself. Someone on the Wikimedia server admin team has to do it for you. —Rua (mew) 19:19, 5 May 2019 (UTC)
@RXerself: You have to post a request on Phabricator; see the post requesting the Reconstruction namespace here on English Wiktionary (by Rua incidentally). — Eru·tuon19:26, 5 May 2019 (UTC)
Yes. The last newest namespace (Lampiran) also needed community's approval to be created. I'll look for it when it's ready. But right now I'm still very early in my personal project filling etymological information there. I was trying to prepare and tidy up possible templates/modules that I might need so I don't run into a problem. RXerself (talk) 19:33, 5 May 2019 (UTC)
Can't create certain pages
I was trying to create a page for the surname Blower and I got this message:
2019-05-05 20:57:22: Fatal exception of type "Wikimedia\Assert\ParameterAssertionException"
I'm assuming this is to prevent people to create pages starting with an uppercase letter (when there's already a lowercase equivalent). But I do need a way to circumvent it, does anyone know how/can anyone give me permission to make this page? Julia☺☆21:13, 5 May 2019 (UTC)
It seems to only affect pages where there used to be an uppercase version, which was then moved and deleted when Wiktionary became case-sensitive. i.e: Geek ( < geek ) returns this error, but Myiasis does not Mofvanes (talk) 06:31, 6 May 2019 (UTC)
So, one could restore the deleted entry and edit it. Can only admins restore such entries? If so, one could create a list an ask an admin to restore the entries a few at a time or with some suitable stub content. I did that with Blower. DCDuring (talk) 12:13, 6 May 2019 (UTC)
I see you were able to create Blower from the redlink I created yesterday at blower (which is still red). I was getting the error message yesterday when I clicked on the created redlink. Is there a time delay? DonnanZ (talk) 12:23, 6 May 2019 (UTC)
The Phabricator ticket mentioned above was merged into phab:T222529, which in turn has been closed as "resolved". So, try creating some more pages (that were moved by the conversion script) and see if it works... - -sche(discuss)21:45, 8 May 2019 (UTC)
Find terms by misssing translation. Or making a page that finds terms for you to translate.
I can speak Spanish, and I understand English. In wiktionary when you search for an english term, on the english section, you get to see translation boxes for every "meaning", and I find that absolutely amazing, except that it is not paid so much attention to it. Furthermore adding new translations is a bit hard.
How hard would it be to make an interface where it asks you for certain translations and you can fill them easily? Sistemx (talk) 06:58, 7 May 2019 (UTC)
Thank you. However, what I want to do is to fill the translation glossaries (at least for spanish) more quickly. And I thought there was a gadget/javascript that already existed that could find which terms have no spanish translations as of now. I think the category of requests for translations into spanish is nice, but people will have to add this category first won't it? So there will be many entries that won't have the category of missing translations because you need someone to add the category in the first place. But, I didn't know about the category, so that will keep me busy, thank you! Sistemx (talk) 07:21, 7 May 2019 (UTC)
A translation into Spanish has wikitext that looks like this: '* Spanish: {{temp|{{t+|es|rosal|m}}}}'. If you wanted to find entries that had English adjectives and had no Spanish translations you could search for 'incategory:"English adjectives" -insource:/\{\{t\|es/ -insource:/\{\{t\+\|es/'. You could further restrict the search by using topic categories. The search can be quite server-intensive, so the more indexed restrictions you place on it the better. Note that such searches are far from complete and far from accurate. For example, the search would miss pages that had pages in the adjective category with no adjective translations if there was a single instance on the page of {{t}}, say in a verb or noun PoS section. DCDuring (talk) 10:21, 7 May 2019 (UTC)
@2600:387:5:803:0:0:0:8B: Sorry that your edits were blocked, in order to prevent common types of vandalism there are certain actions which new and unregistered users are prevented from taking. Adding links is one of those, as is adding what I am assuming was accidental text directly from the GUI edit buttons. If you would like to register an account you will be able to add links, it is free and pretty easy. Wiktionary:Why create an account? has some information on that. If you would prefer not to register an account you can request that others make the edits you propose on the talk page of the entries. - TheDaveRoss00:24, 8 May 2019 (UTC)
What does the tag "no head temp" mean?
My recent edit to add an adjective definition to the Latin entry for the word facile got tagged "no head temp". Why, and what does it mean? Special:Tags has no description of its meaning.--Urszag (talk) 07:14, 8 May 2019 (UTC)
Thanks. I guessed that I had left out something that was required, but I couldn't figure out what it was.--Urszag (talk) 08:21, 8 May 2019 (UTC)
There are a few other cryptic ones (I finally looked up lede, can't get more jargony). Perhaps MediaWiki could link directly to the entry in Special:Tags? – Jberkel20:10, 8 May 2019 (UTC)
That doesn't really help though if the "Full description of meaning" column in Special:Tags? is empty, which was the case for this tag. I don't see an edit button for the Special:Tags page: how do the descriptions get there in the first place? Do you need special privileges to edit it?--Urszag (talk) 21:06, 8 May 2019 (UTC)
I added a description. As far as I know all Special/MediaWiki pages can only be edited by administrators, . - TheDaveRoss22:51, 8 May 2019 (UTC)
@Ultimateria There was an attempt to devise a rule for the prepositions, but that didn't go very far and in hindsight it was probably too convoluted. I would support making all categories of this kind use the same preposition, if proposed. —Rua (mew) 16:25, 8 May 2019 (UTC)
There are some cases like in the etymology of Abderhalden reaction or alles anderes ist Menschenwerk, where two or more adjacent calls to {{m}} are used for what is essentially a single term. Since they form a single term, they should be a single argument wrapped in a single language tag, thus {{m|de|] ]}} and {{m|de|] ] ] ]}} (in this case, it can be argued that Abderhaldensche Reaktion should have its own entry, but ignore that for the moment). I'd like to do this kind of replacement with a bot, but it hinges the assumption that such a replacement is valid in all cases. I can't think of any cases where this is legitimate; if there are really two separate terms they're separated by punctuation, not only by a space. Misformatting is perhaps the only false positive I can think of, but that seems nearly impossible to find. Are there cases I haven't thought of?
Secondly, a bot would need a list of these cases to work with, and such a list may perhaps be useful even if we decide it's too risky to let a bot do it. Could someone (e.g. User:DTLHS) make a list of all cases of {{m}}, separated from another {{m}} only by a space? A list for equivalent cases of {{l}} could perhaps also be made. There may even be cases of two of these templates next to each other without any intervening text at all, but that is almost definitely a formatting error. A list of those would also be useful, but we should fix those manually. —Rua (mew) 16:19, 8 May 2019 (UTC)
Here's a list of sequences of {{m}} and {{l}} that are separated by zero or more ASCII whitespace characters from mainspace, Reconstruction, and Appendix pages. It might be a little off because of the custom PEG I used to parse the dump pages, but it should be mostly correct. — Eru·tuon18:34, 8 May 2019 (UTC)
@Erutuon Thank you! I think there's a few mistakes in there, like aberrant (ironically). Those are list items. I also think, looking through, that there may be some cases separated by a hyphen rather than a space. More annoyingly, though, are all the cases where {{l}} is used in definitions to link individual words. That's a misuse of the template, but it's on a lot of pages and it's giving a lot of noise for a bot to work around. I think I'd rather fix such cases separately first with another bot run. So in the meantime, the cases with {{l}} are probably unusable/bogus for a bot and we should focus on {{m}} only. Could you rerun the script with only {{m}}, including also any cases separated by hyphens, and fix the issue with list items being erroneously included? —Rua (mew) 18:42, 8 May 2019 (UTC)
@Rua: Actually, I just fixed aberrant; it originally had individual words at the beginning of lines with no list syntax – unless you mean I should filter out such cases. I'll re-run it to only find {{m}} and add a hyphen as an option in the separator part of the pattern. — Eru·tuon18:46, 8 May 2019 (UTC)
I'm concerned only with spaces for the moment; not line breaks, which are a whole different story. —Rua (mew) 18:49, 8 May 2019 (UTC)
The bot would have to check that all language codes are the same, and that all but the last do not have any annotations. For instance, something like {{m|hu|pénzügyi|'''P'''énzügyi|financial}} {{m|hu|ellenőrzési|'''E'''llenőrzési|auditing}} {{m|hu|hivatal|'''H'''ivatal|office}} in APEH has to be left alone by the bot because it has glosses after each word (even though it could be changed by an editor). I could add the first check to my script; that might save your bot a bit of effort, though it seems less common for {{m}} to have different language codes in consecutive templates than {{l}}. — Eru·tuon19:09, 8 May 2019 (UTC)
The bot has to check anyway so it's not very important. Regarding APEH, I considered just concatenating the glosses, but that probably wouldn't give the right result because the order of the linked words isn't guaranteed to give sensible English. Thank you for thinking with me. —Rua (mew) 19:26, 8 May 2019 (UTC)
It occurs to me that another thing to look for would be other linking templates, like etymology templates, followed by {{l}} or {{m}}. — Eru·tuon19:38, 8 May 2019 (UTC)
Actually, all the bot needs is a list of pages to look at. It will do the rest itself. —Rua (mew) 20:17, 8 May 2019 (UTC)
Here is the same list with sequences that begin with {{der}}, {{inh}}, {{bor}} added. Looks like quite a few of them can be corrected pretty easily. — Eru·tuon02:57, 9 May 2019 (UTC)
Do you think you could provide the list as a simple newline-separated list of page names? The bot only needs the names, the specific cases needing to be fixed are only interesting to humans. —Rua (mew) 11:33, 9 May 2019 (UTC)
On a separate but perhaps related topic, I've been wondering if {{glossary}} can be tweaked so that we could specify something like {{glossary|present|active|infinitive}} and have it link properly to the separate entries in "Appendix:Glossary" rather than have to type {{glossary|present}} {{glossary|active}} {{glossary|infinitive}}. — SGconlaw (talk) 10:29, 9 May 2019 (UTC)
We could, but I don't think this would be user-friendly (3 separate links to navigate, to look up a single concept). Which reminds me that glossary links should really display as popovers. – Jberkel12:02, 9 May 2019 (UTC)
Well, it’s no different from the current situation where one has to use multiple {{glossary}} templates. As to popovers, I’ve no objection in general, but we have to ensure that it works with screen readers for accessibility, and on mobile devices. For example, I note that text that is supposed to appear as a mouseover when {{...}} and {{nb...}} are used doesn’t appear on mobile devices. — SGconlaw (talk) 13:38, 9 May 2019 (UTC)
How can I list multiple inflected forms of a Latin noun in a single table?
For a number of Latin entries that I edit, I feel like it would be simple and compact to list multiple variant inflected forms in a single declension table. For example, a fair number of third-declension nouns seem to show variability between a genitive plural form ending in -ium and a genitive plural form ending in -um; an example is dos, where sources that I have found say the genitive plural can be dotum or dotium. It seems excessive to add two separate tables where everything but the genitive plural is identical.
But I don't know of a way to add a second form to a box when I am using a Latin noun declension template. I noticed that the Latin entry for the name Hercules has what I want, but the editor of that page seems to have accomplished it by calling the la-decl-noun-table-single template directly and bypassing the usual declension templates, which is apparently not the intended use.
As far as I can tell, to show multiple forms through a declension template, I would have to create a new template, which would in turn require edits to some module in order to work correctly. This seems to be a rather complicated process, and it would only work for one particular kind of variation. But maybe it would be a good idea after all, since as I mentioned, variability between -ium and -um genitive plural forms does seem to exist for more than just a few nouns.
Am I missing some option for manually adding alternative forms within the existing templates? Is it best for me to get a new template made after all for each type of noun that can have multiple forms? Or should I as a general rule show only one form in the table, and mention the other form in a note (I don't like that option as much, because I think in some cases it isn't clear which form is more frequent or more primary)?
I know that the general inflection tables support parameters like gen_pl=. It shouldn't be too hard to add additional ones with numbers, e.g. gen_pl2= (with list = true passed to Module:parameters). Pinging @JohnC5 who is the main editor for the Latin templates. —Rua (mew) 23:42, 8 May 2019 (UTC)
@Rua, Urszag: This functionality already exists except you use / to separate form (e.g. |gen_pl=dotum/dotium or the tables at requiēs). This functionality of the Latin templates was designed before Module:parameters was fully in use. —*i̯óh₁n̥C02:52, 9 May 2019 (UTC)
@JohnC5 Do you think you could add support for numbered parameters as an alternative? They're much more prevalent across Wiktionary so it's what people are probably led to expect here too (as I was). —Rua (mew) 10:06, 9 May 2019 (UTC)
@Rua: I would generally agree with you that we should make them all consistent, but two things prevent me from changing this behavior at the moment. First, it would take a bunch of work to refactor the module into an intermediate state that allowed both formats, track down all the ones that use / syntax to change them over, and then change it refactor again to only allow the list format. The other reason is that Module:la-verb, Module:grc-decl, Module:de-noun, and Module:sa-decl all use the same syntax as well (It does not escape the author's notice that he either created or worked heavily on all of these modules as well). I'm not opposed to changing it over, but I don't have the time to undertake such an endeavor right now, unfortunately. Perhaps @Erutuon would be more amenable? —*i̯óh₁n̥C18:43, 9 May 2019 (UTC)
@JohnC5, Rua: I suppose it would be consistent to allow |gen_pl1=, |gen_pl2= and so on (though it would be |GP1=, |GP2= in {{grc-decl}}), but like Benwing2 I find the slash or comma syntax more convenient and there are other more urgent things in the Module:grc-decl that I have been putting off working on. — Eru·tuon03:40, 12 May 2019 (UTC)
fleeting "Error: invalid time" in today's WOTD
When I came to the main page (not yet logged in), the bottom of today's WOTD was displaying "Error: invalid time" in red in the links it tried to generate to the previous and next WOTD: ] | About Word of the Day • Archive • Nominate a word • Leave feedback | ]. This error persisted after I logged in, and after I hard-refreshed the page, but disappeared when I did a null edit on the page. I performed a few more null edits (because I know that with memory errors, problems sometimes re-arise or change the point on the page at which they start if one does null edits like that), and the issue has not re-occured, but I'm still reporting it here in case anyone else sees it or wants to speculate on what caused it. - -sche(discuss)21:34, 8 May 2019 (UTC)
Nah, spacetime fluctuation. Noticed this as well. The template, while messy, looks correct. Maybe {{CURRENTMONTHNAME}} or {{CURRENTDAY}} sometimes return weird/empty values? The documentation mentions that these get cached and not always return the current value. – Jberkel22:38, 8 May 2019 (UTC)
Modern Greek font
The font used for Modern Greek has just (5:25 UTC) changed to a smaller more "curvaceous" one (it now looks more like the one used for Ancient Greek). Can it be increased in size? The l/c characters are now 3/4 the size of the English font? (Or the change reverted?) — Saltmarsh. 05:35, 9 May 2019 (UTC)
@Saltmarsh: I did just now make a change to MediaWiki:Common.css (the diff for which is currently unviewable due to a MediaWiki bug) removing font-family /**/:inherit; from the CSS rule for Greek (.Grek). I wouldn't have expected this to have any effect, but apparently it did. I guess that beforehand Greek displayed in the default font and now it displays in the custom fonts specified in the CSS rule (which I have been seeing for quite a while).
Perhaps as a result of this your browser is now selecting a font family that looks shorter than the default font family. If this is true, unfortunately, it's not a good idea to set a font size for everyone based on the height of a particular font family. There's no guarantee that other people have the same font and need the same font size. But you can enter .Grek { font-family: inherit; } in your common.css to remove the font family (so that Greek is displayed in the default font), or change the font size with .Grek { font-size: 133%; } (adjust the percentage to what looks good to you). — Eru·tuon05:51, 9 May 2019 (UTC)
@Saltmarsh: I'm not sure which font you're seeing. It is probably one of the ones in the style rule for Greek, .Grek,.polytonic{font-family:Athena,Gentium,'Gentium Plus','Palatino Linotype','Arial Unicode MS','Lucida Sans Unicode','Lucida Grande','Code2000',sans-serif;}, but which one your browser chooses depends on which fonts you have installed. — Eru·tuon14:50, 9 May 2019 (UTC)
This probably should be in RFD (Other), but if there are any empty categories for no (Norwegian) they can be removed - replaced by nb and nn. DonnanZ (talk) 09:56, 9 May 2019 (UTC)
They can be deleted without any issue. They can always be recreated when needed. A lot of those -ology categories were formerly populated by things like "Mammals" for "Mammalology", but I removed this categorisation because, as you can see, tons of languages end up with useless "Mammalology" categories that only contain "Mammals" (and thus end up empty when that category is removed; they never contained any entries). Relatively few languages have science-related jargon compared to how many have terms for the things studied. So the thing being studied should not have the scientific field studying it as its parent, to avoid things like this. For the vast majority of languages, the Mammalology category will never contain any entries, in particular dead languages. So it seems like a good idea to not have Mammals go in Mammalology. The same for all the others. —Rua (mew) 10:31, 9 May 2019 (UTC)
Care is needed, some empty categories are parents of subcategories, so deleting those is probably not advisable. DonnanZ (talk) 11:22, 9 May 2019 (UTC)
But then they aren't empty, are they? A bot should always check if the category is actually empty immediately before deleting, as the categorisation can be slow to update. —Rua (mew) 11:26, 9 May 2019 (UTC)
Well, your bot has just given hundreds of Norwegian inflections backwards wording, so I don't have much faith in it. DonnanZ (talk) 12:50, 9 May 2019 (UTC)
Unwarranted, in my opinion. What use is an empty category, especially one that can be recreated easily with {{auto cat}}? —Rua (mew) 18:32, 9 May 2019 (UTC)
I'm definitely opposed to deleting maintenance categories that happen to be empty. It's a pain in the ass to re-create them every time something new needs to be added to them. For semantic sorting categories (the kind that get implemented by {{C}}/{{topics}}, if they're empty, delete 'em. —Mahāgaja · talk15:57, 17 May 2019 (UTC)
Yes, I meant change both the title of the template and the wording. I suspect the creator isn't fully conversant in English. DonnanZ (talk) 16:28, 9 May 2019 (UTC)
I think you should just go ahead. The template can be moved to {{definite singular of}} and then modified it to show the correct wording, and then a bot owner (maybe Benwing2) can replace the old template name with the new one in entries. — Eru·tuon19:34, 9 May 2019 (UTC)
-sche's statistics show that the current name is actually the more common one, though. Should we really be moving it? —Rua (mew) 20:02, 9 May 2019 (UTC)
I'm not sure if the Google Ngrams statistic is very clean evidence; it might include phrases like "masculine singular definite article" and things unrelated to grammar like "a singular definite description" (from this Google Books search), as well as genuine examples of "singular definite" being applied to noun forms. It would be better evidence if the statistics were derived only from books on North Germanic languages, or other languages with definite singular noun forms. Like DonnanZ, I feel that "definite singular" sounds better than "singular definite". — Eru·tuon20:38, 9 May 2019 (UTC)
I agree with Erutuon and DonnanZ; it should be "definite singular". I looked through the first 3 pages (30 hits) of Google references to "singular definite" and "definite singular". Most references to "singular definite" are indeed to "singular definite article"; 4 refer to Swedish or Norwegian, while there are many more Nordic language references under "definite singular". I am going to go ahead and rename the template to "definite singular of", along with {{plural definite of}} and {{plural indefinite of}} (for whatever reason there's no {{singular indefinite of}}). Benwing2 (talk) 00:11, 10 May 2019 (UTC)
Thankyou all, I don't mind having my watchlist flooded by bot edits this time. Actually, there is no need for "indefinite singular of", that is the lemma from which the other inflections stem. DonnanZ (talk) 09:18, 10 May 2019 (UTC)
There's an option in the preferences to hide bot edits by default. That stops the flooding. —Rua (mew) 11:33, 10 May 2019 (UTC)
@Donnanz I fixed the Danish noun headword and declension templates so they pass standard accelerator forms like indef|gen|p, which get directly converted into calls to {{inflection of}} by the language-independent rules, and then removed the special rules in Module:accel/da for nouns. I did the same for Norwegian and Old Norse (in the latter case, accelerators weren't present but I added them). So there should be no references any more to {{genitive singular definite of}} or similar in any modules or templates. Benwing2 (talk) 15:52, 10 May 2019 (UTC)
OK, I don't know all the technical stuff, but I have been reminded there is still some unfinished business converting old Norwegian lemmas and inflections to Bokmål and Nynorsk. DonnanZ (talk) 16:05, 10 May 2019 (UTC)
@Rua If there is agreement among the editors of the various Scandinavian languages, I can rename the "genitive" tag to "possessive" or remove the forms entirely. Benwing2 (talk) 15:07, 14 May 2019 (UTC)
"Invalid time" error
Recently I've been seeing a lot of this on the home page:
I don't know what happened, but clearing the cache (pressing "refresh" on the top right of the WotD box) removed the error. — Eru·tuon20:30, 10 May 2019 (UTC)
I noticed this as well (#fleeting_"Error:_invalid_time"_in_today's_WOTD). A null edit made it go away then too, but it would be nice to figure out why (or if?) it's only recently started happening. It doesn't seem to be something we changed(?) in our modules, but it seems to be a module or Lua error: did something in the functionality of Scribunto/Lua change? Should we file a phabricator ticket? (But it's not entirely replicatable...) - -sche(discuss)20:32, 10 May 2019 (UTC)
Yeah, it seems not to be replicable or consistent. Sometimes I see the errors, then next time I load the home page everything's OK, for no apparent reason. Mihia (talk) 20:38, 10 May 2019 (UTC)
Ah, you're right; I had gotten used to these red error messages signalling Lua erors, but they're used by other things, too. - -sche(discuss)20:48, 10 May 2019 (UTC)
Moving the logic into a module would probably help, or at least make it easier to debug. The error message should include the string which is deemed invalid. – Jberkel08:39, 11 May 2019 (UTC)
I don't think we have a template for the Concise Scots Dictionary / Dictionary of the Scots Language , . I bought the hard copy, but it would be nice to have a template for the online version. DonnanZ (talk) 09:53, 12 May 2019 (UTC)
Half of MediaWiki:Common.css actually has to do with language script styling. I'm wondering if it shouldn't be moved to Module:scripts/style.css and called up using @import. That would declutter Common.css and perhaps allow template editors the ability to make changes to it as well. --{{victar|talk}}11:56, 12 May 2019 (UTC)
Two questions: whether the @import statement will be optimized well and whether all the rules used for the various script classes will be accepted in a sanitized CSS page. If so, sounds like it might be a good idea. — Eru·tuon19:37, 12 May 2019 (UTC)
Yeah, it looks like there would be no difficulty importing a sanitized CSS file because it's just importing a URL and not using server-internal functions. I thought there might be a special process in ResourceLoader to optimize imports, but there only seems to be one for image URLs (a way to tell ResourceLoader inline the image data in base64 encoding while loading the CSS page). — Eru·tuon20:44, 12 May 2019 (UTC)
The trouble with allowing template editors to edit portions of the site's CSS is that it invalidates the purpose of the interface administrator group: now administrators and template editors can also edit CSS. — Eru·tuon20:03, 12 May 2019 (UTC)
This currently doesn't have a parameter to specify the language of the term the way {{l}} does. As a result, the terms are not wrapped in language and script tags, aren't stripped of optional diacritics, and don't link to the correct language section on the target page. Can this be fixed? —Rua (mew) 19:24, 12 May 2019 (UTC)
Yeah, we'll have to add lang= support, defaulting to en, and then eventually use a bot to add it everywhere so it can be made mandatory and support for lang in 1= added. Benwing2 (talk) 22:09, 12 May 2019 (UTC)
I don't think en as default is appropriate, because there are uses for languages other than English. und is a better default. —Rua (mew) 22:16, 12 May 2019 (UTC)
Rhymes tool adding duplicate rhymes
When you use the rhymes tool to add rhymes to the rhymes pages, it also adds the rhyme to the page being added. But it doesn't check to see if the rhyme is already there, leading to errors like diff and diff. The person editing the rhyme page isn't aware that other pages are silently being edited, let alone that they are being edited incorrectly, so they are not encouraged to check these automatic edits in any way. Can this be fixed? —Rua (mew) 17:21, 13 May 2019 (UTC)
@Rua: Okay, now the gadget will not modify the entry if it finds the rhyme there already. The method for checking for the rhyme should be accurate even if there are multiple rhymes listed because it actually parses the rhyme templates. — Eru·tuon05:03, 16 May 2019 (UTC)
Finnish noun from ACCEL links are kinda broken, what happened?
They used to use {{fi-form of}} but now they use {{inflection of}}...I'm wondering why that is the case, but that's not the main problem. The nominative and accusative forms of nouns and adjectives are one and the same and thus I previously asked for someone to modify the code related to the ACCEL creation so that these form of entries would be defined as both nominative and accusative plural of X. However, now when I click on the link for nominative or accusative plural the entry that's created only has one definition: "nominative plural of X"...When was this changed and why? It was perfectly fine when it was generating the two definitions as described above. User: The Ice Magetalk to meh21:30, 13 May 2019 (UTC)
@The Ice Mage Should be fixed now. Clicking on the nominative plural now should use the tags nom//acc|p, which currently displays as "nominative and accusative plural". Benwing2 (talk) 23:49, 13 May 2019 (UTC)
@Benwing2 Just a thought, while I guess it's not a huge deal, would it be possible to have it as it was before as in 2 definition lines, one for nom. one for acc? I feel like this is something that probably needs to be standardised across various languages too because like, IIRC while many languages have multiple definition lines when one word has multiple inflectional meanings, I've seen some Polish noun and/or adjective forms where the multiple meanings are put into "subdefinitions" instead. It's not the end of the world of course, but it would be nice to have the format standardised across all relevant languages. User: The Ice Magetalk to meh16:37, 14 May 2019 (UTC)
@The Ice Mage It can be made to have two subdefinitions of one definition line, but it's trickier to make it have two definition lines. In any case the modern preference is to use subdefinitions rather than separate definitions. Benwing2 (talk) 00:39, 15 May 2019 (UTC)
Any chance someone can update the rhyme-adding tool so that it inserts {{rhymes|en|ɒlədʒi}} into entries rather than {{rhymes|ɒlədʒi|lang=en}}? (Pinging @Erutuon as I see you responded to a rhyme-related query earlier.) — SGconlaw (talk) 19:07, 14 May 2019 (UTC)
Bot request: clean up incorrect uses of {{inh}} with roots
Can someone a bot, just once or regularly, that changes all instances of {{inh}} to {{der}} if the linked term is a Proto-Indo-European root? The bot can tell if something is a root if it's in Category:Proto-Indo-European roots, or redirects to one of those pages. For cases where there is no PIE page yet, the bot can choose to either skip them or analyse them by their shape to determine if they qualify as roots. —Rua (mew) 16:26, 16 May 2019 (UTC)
@Rua: Here's a list of such instances from the latest dump. The method treats as a root any Proto-Indo-European term whose page contains {{ine-root}} because all terms in Category:Proto-Indo-European roots have that template. I excluded {{inh}} with an alt parameter (|4= or |alt=) because the alt is often a word derived from a root. However, in cases like {{inh|lt|ine-pro|*bʰerH-|*bʰorH-}} in barti, the alt just a different grade of the root. Probably the method could be improved. — Eru·tuon17:20, 16 May 2019 (UTC)
If you or someone else with a bot would clean up the 1176 or so cases in the list above, I'm willing to clean up instances that show up after that. — Eru·tuon00:33, 18 May 2019 (UTC)
Etym only languages with family as parent language
Ran into an issue with Suevic: {{desc|gem-sue}} shows me this error: Lua error in Module:script_utilities at line 270: The language "gmw" does not have the method getScripts. It may be unwritten.. Suevic's parent language is gmw, and changing this would solve the problem I'm pretty sure, but what should the parent be then? Julia☺☆18:56, 16 May 2019 (UTC)
@Julia: I've added a more helpful error message. The actual problem is that gem-sue is the code for a variety of a language family (gmw, West Germanic) and {{desc}} requires a code for a language that can have entries or a variety of such a language. — Eru·tuon19:15, 16 May 2019 (UTC)
Editing quotations with VisualEditor
This seems to be completely broken at the moment. I reported it as phab:T223572. Most of you probably don't use VE but it would be great to have this fixed, especially contributions by casual editors often end up badly formatted, and I suspect it's related to VE not working. – Jberkel11:39, 17 May 2019 (UTC)
It's related to our CSS, which hides the quotes by default. @Erutuon, could you take a look? Somebody replied on phabricator with recommendations on how to solve it, with changes to the gadget and CSS file. – Jberkel16:04, 17 May 2019 (UTC)
Creation of a new vote
When I go to https://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Votes and click "Start a new vote!", I get taken to a form titled "Creating Wiktionary:Votes/2019-05/Title of vote". Obviously I do not want to literally create a page called "Title of vote". The first line of the boilerplate text reads "=== {{subst:SUBPAGENAME}} ===". Am I supposed to replace "{{subst:SUBPAGENAME}}" with the actual title? Or does "{{subst:SUBPAGENAME}}" pick up the title from somewhere else, and if so, where? How do I enter it? I don't know if I am missing something obvious, but it seems confusing. Mihia (talk) 13:58, 17 May 2019 (UTC)
@Mihia: You have to edit the title in the "search bar" (it's not a search bar, but I don't know how else to call it) before you click on the button "Start a new vote!". Canonicalization (talk) 14:04, 17 May 2019 (UTC)
@Canonicalization: Thank you! Finally I have found the field that you are referring to. I didn't even realise that that text was editable. I think the layout is very unclear. I may try to add a note to the page. Mihia (talk) 17:26, 17 May 2019 (UTC)
entry template for present participles
When using the entry template for present participles, it might be helpful to add a "nocat=1' parameter to it, otherwise it will categorise to Category: English present participles, which appears to not/no longer exist. Leasnam (talk) 23:08, 17 May 2019 (UTC)
It would be simpler and less error-prone if categorization in that template could just be disabled for English altogether. — Eru·tuon23:47, 17 May 2019 (UTC)
Correct. I didn't put it in, it automatically put 'present participle'. Here, do this: type "daredeviling" into the 'Search' and hit Enter. Then create the page using the 'Participle' button. It will create the page with 'present participle' in it. Leasnam (talk) 21:56, 18 May 2019 (UTC)
The Declension tables are not expanding at *beall. They seem to be working fine at terms that are not fronted by an asterisk (*term) Leasnam (talk) 03:14, 20 May 2019 (UTC)
(edit conflict) I think I've narrowed it down to some kind of interaction with punctuation characters in the preceding header. I tried previewing with various parts commented out, but there was no effect until I commented out the L4 headers- and the collapsable headers worked fine. Experimenting further, I found that removing the parentheses removed the problem, and adding a variety of punctuation characters (just about every one on the keyboard) caused the problem to return. Also, this only applies to L4, L5 and L6 headers. I'm not sure whether the problem is in the CSS or the JS, or some interaction between the two, or whether it's the system or our JS/CSS, but I think this might give more clues to those who know more than I do to work on figuring out what's going on. Chuck Entz (talk) 04:17, 20 May 2019 (UTC)
Creating templates and how they are used
I'm a complete newcomer here. I hope this isn't misplaced.
I'm trying to work with Tigrinya language entries for the English Wiktionary, and there's only relatively so much that has been done already (I'm glad that someone's started!).
So I was just trying to create a page for a verb in the language, and I am overwhelmed by maybe absolutely everything, but I wanted to ask here specifically about creating templates.
For Tigrinya only the ti-noun template exists and it seems natural that I create a template for verbs.
But in my search for trying how to do that I was directed here. (I think so that I could ask someone else to create the template for me?)
2. But also? I really tried to search around and understand, but... what are the advantages of having a template like Template:ti-verb? For example, I just created the page ሰበረ, how will the verb template change things? Could someone explain?
3. I would be very grateful if someone could create the ti-verb template for me, but I'll probably have to create more templates in the future. Maybe a lot more (since there's only one right now--yikes). Where/how can I get familiarized with the process of making templates?
In the case of ሰበረ(säbärä), a special template wouldn't add anything. That's why we also have generic templates like {{head}}. If someone were to create {{ti-verb}}, what is it supposed to do? —Rua (mew) 13:56, 20 May 2019 (UTC)
Hello Corbariano! (When posting on talk pages like this one, you add a signature at the end of your post by typing four tildes, or clicking the signature button to the right of the italics button in the formatting bar.) I'm also new, so I've been figuring out some of the same things as you recently. As Rua mentioned, a language-specific template only has advantages if there is something special about verbs in the language that it would be useful to record. For example, in Latin entries, the verb template includes parameters for the principal parts of the verb. The other thing that templates do is add categories to an entry, but the generic head template does that also. You can see how it works if you look at the edit SemperBlotto made to the entry for ሰበረ after you created it. Because of the line {{head|ti|verb}}, the entry is now in the categories "Category:Tigrinya lemmas" and "Category:Tigrinya verbs" (listed at the bottom of the page). The part-of-speech templates that I have seen so far rely on programming that is put in modules. This seems to be a fairly complicated system, and I haven't seen any introductions so far to the technical way it works.--Urszag (talk) 17:43, 20 May 2019 (UTC)
Ossetian ӕ
@DTLHS, do you think you could run your bot to replace Latin Small Letter AE (æ) with Cyrillic Capital Ligature A IE (ӕ) in both page titles and links for Ossetian (os) entries? It would also be nice it they could be moved with no redirect. Really appreciated. --{{victar|talk}}04:05, 21 May 2019 (UTC)
@DTLHS: Even though Ossetian exclusively written in Cyrillic these days, some archaic words might only be found written in Georgian and, technically, a Latin alphabet was proposed, but it never caught on. I can verify though that we have no entries or links that should be written in either of the latter two. --{{victar|talk}}17:23, 21 May 2019 (UTC)
For what it's worth, here's the list of many of the Ossetian links with Latin characters. What I did with my semi-automatic Python script was to go through all the templates that do not consist only of Latin characters (^+$ in the regex library) and no Latin characters and replace the Latin æ with Cyrillic ӕ. — Eru·tuon18:08, 21 May 2019 (UTC)
@Erutuon: Please run your magic and fix non-Cyrillic letters in Ossetian terms. You can safely assume that Ossetian is written in Cyrillic only for this exercise.
I was wondering, why do alephs and Ayins swap when publishing a page. When I write an aleph, and I publish my changes, it is changed for an ayin. Is there a reason for this? I'll leave these to show what I mean: Aleph=ʾ, Ayin=ʿ. – Tom 144 (𒄩𒇻𒅗𒀸) 21:58, 21 May 2019 (UTC)
Maybe is something particular to my computer, but when editing, I see them switched, with the aleph equating to an ayin and so on. – Tom 144 (𒄩𒇻𒅗𒀸) 22:20, 21 May 2019 (UTC)
Very strange. They look the same in the preview as in the edit box for me. Perhaps your browser is using a faulty font. — Eru·tuon22:22, 21 May 2019 (UTC)
Redundant or incorrect transliterations for Bulgarian, Ukrainian, Belarusian and Macedonian
Would someone be willing to finally address redundant or incorrect transliterations for Bulgarian, Ukrainian, Belarusian and Macedonian?
It has been raised several times. Please preserve the stress mark in the Cyrillic spelling if it's required for Bulgarian, Ukrainian, Belarusian. Macedonian only needs it if the stress is not on the penultimateantepenultimate syllable but don't ask me if the stress is correct. Ask User:Martin123xyz.
I have been going through translations from English but Bulgarian entries need a really good clean-up, "tr=" should be replaced with "head=" or modules rewritten. Casual users still continue to use "tr=" with transliterations.
Acute accents are fine everywhere but I have been using grave with Bulgarian ъ(ǎ): ъ̀. There is no strict rule as such. Bulgarian dictionaries use either acute or grave accents, if at all but ъ́(ǎ́) looks more readable.
@Atitarev: I'll look into this. It shouldn't be hard to do this in link templates, but for language-specific headword-line templates the template behavior has to be worked out.
As a sample, here are Bulgarian instances of {{m}}, {{l}}, {{t}} with the |tr= parameter. There are 1226 pages with those alone, quite a lot to do by hand even without including more linking templates, or the rest of the languages.
So, my impression is that transliterations should be deleted if they do not contain an accented vowel ({{t|bg|Ахерон|m|tr=Aheron}} → {{t|bg|Ахерон|m}}); if they do, the accent mark should be transferred to the Cyrillic and then the transliteration can be deleted ({{t|bg|аберация|f|sc=Cyrl|tr=aberácija}} → {{t|bg|абера́ция|f|sc=Cyrl}}; here |sc=Cyrl should be deleted too: {{t|bg|абера́ция|f}}). But for Macedonian, the accent mark should only be transferred to the Cyrillic if it is not on the antepenultimate syllable in a word of three or more syllables (or penultimate syllable in a two-syllable word presumably?).
Perhaps a bot operator could delete transliterations that don't contain an accented vowel (here might have to account for the possibility of Cyrillic letters in place of Latin), and for the rest, I could write a script to help transfer the accent mark to the Cyrillic. This requires rules for whether or when to use a grave or acute in Bulgarian and Macedonian. I'm not sure if a bot can reliably do the latter task. I can generate separate lists of linking templates with unaccented and accented transliterations to make this task easier. — Eru·tuon05:05, 27 May 2019 (UTC)
@Erutuon: Thank you. This task is long overdue, so it's OK to do it in stages. Your plan sounds good. The grave accent can only be applicable to Bulgarian but this is a policy I made myself (based on existing entries and almost complete lack of participation from others). Basically, I applied grave accent only to letter ъ(ǎ). This rule couldn't be confirmed elsewhere. There is no solid rule for accent marks - I have asked native speakers at some stage. In Bulgarian entries tr= should be replaced with head= where accent is required (more than one syllable) or module rewritten, so that head= is not required like e.g. Russian entries. --Anatoli T.(обсудить/вклад)05:22, 27 May 2019 (UTC)
If the acute/grave accent makes the task too completed, it's OK to just use the acute accent everywhere, including Bulgarian. (No solid rule but ideally it's as in WT:BG TR, which can be rewritten).
@Atitarev: I've written a first draft of a function to transfer the accent from the transliteration to the Cyrillic, demonstrated here for the list of Bulgarian links. Roughly speaking, the function counts through the vowels in each word of the transliteration and finds which vowel has an acute or grave. Then it counts through the vowels in the each word of the Cyrillic and adds an accent on the corresponding vowel in the corresponding word. That seems to work in most cases.
Some of the transliterations use y in place of j. That isn't a problem for Bulgarian, which doesn't have a vowel transliterated y, but it may be for Belarusian, Russian, and Ukrainian. I will also have to figure out a way to deal with links in the Cyrillic, alt parameters, and multiple accents. — Eru·tuon23:58, 27 May 2019 (UTC)
@Erutuon: Thanks for that. You example looks very good! You probably don't have to work with Russian, as mistransliterations and redundancies have been addressed by User:Benwing2 and there are many cases where "tr=" is required. I don't know if new bad cases are introduced, though. My request is primarily for the four languages I mentioned. Yes, use of y in place of j will cause the problem and Belarusian may also have "i" for "j" as in this revision. Here Беласнежка(Bielasniežka) would need to be replaced with Беласне́жка(Bjelasnjéžka). (Just an example, I've done it already). --Anatoli T.(обсудить/вклад)00:31, 28 May 2019 (UTC)
@Erutuon Are you able to use the acute accent throughout (if it makes it easier) or the grave accent only after the Bulgarian letter ъ(ǎ), just looking at your example: "Ска̀рлет Skàrlet Ска̀рлет". I suggest to use "Ска́рлет" instead, even if the grave accent is used in the translit. --Anatoli T.(обсудить/вклад)00:40, 28 May 2019 (UTC)
@Atitarev: Ah, the function just didn't modify that example because it already had an accent. I could make another script to replace graves with acutes except on ъ(ǎ). — Eru·tuon02:42, 28 May 2019 (UTC)
@Erutuon, Atitarev Thanks, Erutuon, for looking into this! I did this sort of work for Russian, also for transferring macrons from translit to original script in Ancient Greek, and did something similar for transferring vowels from transliteration to Arabic-script text and for converting Russian raw IPA to calls to {{ru-IPA}}. I actually went letter by letter trying to match up the translit and the original script, with tables indicating the various matches allowed and additional complexity for mismatches where one original-script letter matched multiple translit letters. My code for Russian is quite complex because there were so many different transliteration schemes being used. Your approach of matching vowels sounds fine to me but I'd have it (a) make sure there are the same number of vowels, and (b) ideally make sure the vowels themselves actually match, and don't do any accent transferring if they don't. (Not sure if you're already doing this.) The end goal is to transfer the accents and then remove the redundant translit, including cases where e.g. a 'y' is used when a 'j' should be used (but not remove non-redundant translit, if such stuff exists for Bulgarian). I can help with this but it may take me a few days as I also have some RL stuff I'm busy with now. (I also have code that goes through and applies a function such as accent transfer, vocalization, or "auto-accenting", i.e. looking up the appropriate accents to be added to unaccented Russian text, to all the templates where it might be useful, such as links, alt text, etc. I can share all this code with you, Erutuon, but it's in Python so it might not be so useful to you.) Benwing2 (talk) 15:11, 28 May 2019 (UTC)
@Benwing2, Erutuon: Thank you. I forgot to mention that Macedonian terms are sometimes stressed on the consonant letter р(r), e.g. жр́тва(žŕtva). I haven't seen any recent examples. Also, I don't want this to be too hard. Transliterations without accents could be simply removed first. If there are remaining cases that require manual editing, then, please make a list, I will gradually go through it. Hopefully, it will be heavily reduced by then. --22:47, 28 May 2019 (UTC)
Tibetan ་ shouldn't separate words in headword lines
Module:headword and its allies automatically provide separate links for headwords that contain a space (e.g. at ice cream, {{head|en|noun}} would output ] ]). This also happens across some punctuation marks, but not others (e.g. at hexa-2,4-dienal, {{head|en|noun}} outputs ],] since the comma is treated as a separator but the hyphen as a nonseparator). At the moment, the Tibetan syllable separator ་ is one of the punctuation marks that causes separate links to be shown, so every polysyllabic word in any language that uses the Tibetan script has a link to each individual syllable, which is silly (e.g. ནེ་ལོན(ne lon, “nylon”), with separate links for each syllable). Can someone who knows how please edit Module:headword or whatever else to prevent this behavior? Thanks! —Mahāgaja · talk10:04, 23 May 2019 (UTC)
@Mahagaja: Module:headword automatically excludes most punctuation and whitespace characters from links when adding links in the headword, but has a list of punctuation characters that can appear inside of words. I've added the Tibetan syllable separator and made the code a little clearer; the word-internal punctuation characters are called wordPunc. — Eru·tuon18:58, 23 May 2019 (UTC)
Vietnamese syllable separation should stay as is, IMO. Mostly they have separate meanings like Chinese characters and syllables. The headword is regularly modified by editors if a different etymological breakup is required. —Anatoli T.(обсудить/вклад)20:35, 23 May 2019 (UTC)
@Suzukaze-c, Mahagaja: I don’t think they are uncommon. I think this change to the Tibetan headwords needs to be reverted, sorry @Erutuon. We don’t have people with the knowledge of Tibetan but we can override the default behaviour in headwords for European loanwords as a start. Anatoli T.(обсудить/вклад)08:12, 27 May 2019 (UTC)
@Atitarev: I think it should stay the way it is. It looks to me like Tibetan ་ functions a lot like the "syllable killer" ် of Burmese, except that the Tibetan symbol occurs after all word-internal syllables rather than after all closed syllables. And just as I don't think Burmese compounds should generally have their component parts linked in the headword line (an issue you and I have disagreed on in the past), I also don't think Tibetan compounds should generally have their component parts linked in the headword line. So it's not just loanwords that shouldn't have their syllables linked separately; in my opinion even compounds shouldn't either. That's what the Etymology section is for. Also, to judge from w:Standard Tibetan and w:Modern Standard Tibetan grammar, Tibetan isn't as monosyllabic a language as Chinese and Vietnamese are, either: it seems to have case endings on noun phrases and tense/mood endings on verbs. —Mahāgaja · talk12:18, 27 May 2019 (UTC)
@Mahagaja: OK, thanks, I take your point regarding Tibetan but I still think it's a good idea to link components for some complex scripts. I find the use of templates {{zh-usex}}, {{th-usex}}, {{km-usex}} really helpful.
prík pèt krai hâi pèt · chǎn dai · nǎam yɔ̂m lɛ̌ɛm eeng krai · sîiam hâi · jan grìt-sà-nǎa chà-nǎi · krai òp · hɔ̌ɔm rʉʉ · wong hɛ̀ng nák-bpràat dâai · prɔ́ dûai chà-làat eeng
Just like chillies hot without anyone ordering them to be hot, thorns are sharp by themselves without having been sharpened by anyone. Has anybody scented sandalwood or lign aloes with perfume? The race of scholars is knowledgeable because of the intelligence themselves.
with this: พริกเผ็ดใครให้เผ็ด ฉันใด หนามย่อมแหลมเองใคร เซี่ยมให้ จันทน์กฤษณาไฉน ใครอบ หอมฤๅ วงศ์แห่งนักปราชญ์ได้ เพราะด้วยฉลาดเอง for readability for someone who is less than intermediate in Thai.
BTW, I have stopped adding components to the headers in Burmese, Thai, Khmer but adding them to etymologies instead. One reason was your opposition, the other - Burmese fonts don't always handle this well. --Anatoli T.(обсудить/вклад)22:49, 27 May 2019 (UTC)
IIRC, linking in headline templates was just added to make it easy for users to visit entries for component parts without someone having to create etymologies and/or add linking code to lots and lots of entries. IMO getting it to work for every single language isn't a priority, especially in cases like this where coding for it is probably more trouble than it's worth. Chuck Entz (talk) 23:57, 27 May 2019 (UTC)
@Chuck Entz: Yes, that's why I like linking even for languages where space is either not used at all or very rare or is used only to separate clauses. In this case (Tibetan), work needed to be done to REMOVE the linking. I think we should have option to implement both if there is a demand. The implementation of Chinese, Thai and Khmer usexes is a success (not to mention Chinese character boxes), we could use it in cases to make it easier to find word boundaries and get to individual words or components. I favour using the same approach for Tibetan even if I know very little about it. Russian is highly inflected but linking to individual words in collocations, usage examples, etc. is a good thing. Good electronic dictionaries do that. Pls take a look at уже́(užé). --Anatoli T.(обсудить/вклад)04:30, 29 May 2019 (UTC)
I always thought that the Tibetan separation was purposeful; although it looks bad and is genuinely silly with loanwords, Tibetan does operate on the level of the syllable somewhat like Vietnamese. That said, I think we're better off without it, and our etymology sections should cover compounding anyway. —Μετάknowledgediscuss/deeds20:51, 23 May 2019 (UTC)
You’re right. I don’t know if it was intentional but yes, separate syllables have meanings since Tibetan is originally a monosyllabic language, which can form new words by combining syllables and those can form new words again like Chinese or Vietnamese. The correct syllable breakup would require manual intervention. --Anatoli T.(обсудить/вклад)21:55, 23 May 2019 (UTC)
Going to delete a lot of bad Latin forms, esp. in -esco verbs
(Notifying Metaknowledge, Fay Freak): @SemperBlotto The current state of -ēsco verbs is pretty poor. A lot of them have incorrect principal parts and most of them incorrectly have the passive forms created. I have gone through all the -ēsco verbs and figured out which ones are transitive vs. intransitive (it's listed in Gaffiot's dictionary), and I'm going to delete all the bad forms. I have a script that does this deletion correctly, e.g. if there is a non-Latin entry on the page it only removes the Latin rather than deleting the whole page; if there is a Latin entry for a different lemma it only deletes the portion for the lemma in question and leaves the rest; if there is a Latin entry for the same lemma but a non-bad form, that gets left too; etc. As an example, just from the first few entries on my list out of 200+, I have:
delete passive of accrēscō, adcrēscō, adincrēscō
delete supine incrētum from incrēscō
delete passive of succrēscō
delete passive of olēscō, adolēscō, exolēscō, but leave adultus and exolētus
delete passive of exsolēscō, plus perfect exsolēvī and supine exsolētum
delete perfect acēvī of acēscō and delete supine acētum
@Metaknowledge, Fay Freak, JohnC5 Can someone with knowledge of Latin syntax answer a question for me? Does the "gerundive" exist for intransitive verbs? For example, olēscō(“to grow”) and crēscō(“to increase, to grow”) are intransitive, and passive forms like *olēscor and *crēscor don't exist. But do olēscendus -a -um and crēscendus -a -um exist in general? I'm talking about gerundives aka future passive participles, not the gerunds like olēscendum/olēscendī/olēscendō, which should in fact exist. I'm asking because SemperBlotto's bot wrongly created a lot of passive forms of intransitive verbs, including many -endus participles, and I'm wondering whether they should be deleted. Benwing2 (talk) 04:07, 29 May 2019 (UTC)
@Benwing2: Allen & Greenough say, "The gerundive, being passive in meaning, is found only in transitive verbs, or intransitive verbs used impersonally" and give moriendum est omnibus(“all must die”) as an example of a gerundive of an intransitive verb. Now, that's in a section about deponent verbs, but I assume it applies to non-deponent verbs as well. —Mahāgaja · talk06:17, 29 May 2019 (UTC)
Ah, I have the beta editor active, it doesn't work there, the preview just shows the content area. – Jberkel00:26, 31 May 2019 (UTC)
Heading font
By default in Vector<h1> and <h2> are styled with font-family:'Linux Libertine','Georgia','Times',serif, and in most cases, this means rendered with the typeface Georgia. Georgia, however, does a very poor job of displaying diacritics, as demonstrated here:
I'd like to suggest that the default be changed simply to serif (or at least 'Times' be placed before 'Georgia'), which, on most machines, would render in Times New Roman, as seen bellow:
Interestingly, I see barely any difference between the two fonts on my system, it really comes down to individual pixels. So if Times works better, then that's the way to go. —Rua (mew) 08:58, 31 May 2019 (UTC)
I forced Georgia on my system (OSX) and it rendered fine, but there are many other factors. For some of the free core fonts it might make sense to have the browser load them automatically instead of assuming that they are already installed locally. – Jberkel13:17, 31 May 2019 (UTC)
Victar and I figured out that Linux Libertine is also bad at combining diacritics, though unlike Georgia it plasters the acute accent on the háček instead of showing the diacritics as spacing characters. For me, setting the font to Times doesn't improve things, but setting it to Times New Roman causes my browser to use Tinos, which displays the diacritics well. But my experience is probably not representative of many users, because I use Linux. — Eru·tuon00:19, 1 June 2019 (UTC)
So would just changing it to serif rather than specifying particular fonts be good (as Victar suggested above)? Or should we set it to try Times and fall back on serif? - -sche(discuss)03:10, 1 June 2019 (UTC)
FWIW, I also got a bad rendering (diacritics over empty space to the right of the plain Latin character) in Firefox 66.0.5/Windows 10. DCDuring (talk) 03:15, 1 June 2019 (UTC)
@-sche: Not for me. That just sets it to the font that the header would have without my personal CSS. Of the font families that the Vector skin applies to the top-level header, 'Linux Libertine', 'Georgia', 'Times', serif, the first three aren't installed, so serif applies and my browser uses DejaVu Serif (which displays diacritics in the same way as Linux Libertine). So changing the font family list to serif wouldn't have any effect for me. — Eru·tuon03:34, 1 June 2019 (UTC)
I guess using serif would improve the situation for other people if several things are true: if the people are using Vector, if they have Linux Libertine, Georgia, or Times or an equivalent installed, if it does not display diacritics well, and if the default serif font does handle diacritics well.
Changing to serif would change the look of some of the non-Vector skins. Modern, Monobook, and Cologne Blue skins use various sans-serif fonts; Minerva, Timeless, and Vector use various serif fonts. The header displays well for me in Cologne Blue and Timeless. This is just by happenstance I guess because I doubt that the skins were designed with display of diacritics in mind. And one skin that displays the header well is serif and the other is sans-serif. — Eru·tuon03:48, 1 June 2019 (UTC)
Ah. So should we not change anything, then; is the issue too dependent on what fonts and skin (and brwoser/OS) each user has installed? FWIW, if I click on the images above and go to the actual page, the header displays fine for me in the current font (Windows 10) . (I recall from a previous discussion that certain characters display differently for different users even in the same fonts, e.g. a user there hs screenshots showing that in Times New Roman a character has a long tail for them, whereas on my computer in Times New Roman it had a short tail.) - -sche(discuss)04:23, 1 June 2019 (UTC)
If Linux Libertine is a poor choice for displaying diacritics we should remove it. Perhaps we could specify a font designed for multiple scripts, such as Noto Serif, and include it via CSS font loading. That would produce consistent results on modern browsers (in the absence of OS/browser font rendering bugs). – Jberkel08:32, 1 June 2019 (UTC)
@-sche: Setting the header to serifmight fix things for a significant number of people, but that hasn't been clearly established, though the fact that it works for several people using Chrome on Windows is promising. Using particular serif fonts that have good support for diacritics and are likely to be available to many users would be a more reliable method. I would apply this only the Vector skin (MediaWiki:Vector.css) or maybe to other skins that use serif fonts in the top-level headers, to avoid changing the look of the skins that use sans-serif fonts in headers. We could come up with a list of sans-serif fonts for the other skins.
Another idea: apply the Latinx class to the whole header in Reconstruction:Proto-Shughni-Yazghulami/ǧ́æwærs, and then apply various font families to .firstHeading .Latinx taking the style of the skin into account, and other fonts to .Latinx in general, so that {{l|ira-shy-pro|*ǧ́æwærs}} (*ǧ́æwærs) displays well too. — Eru·tuon16:59, 1 June 2019 (UTC)
I'd support something like font-family:'Times New Roman','Times','Baskerville','Georgia',serif.
.Latinx is a sans-serif class whereas <h1> and <h2> should be in serif, and yeah, I wouldn't be a fan of having two different fonts in the header when they don't need to be.
We could also base the font choice on the OS of the user, but that's considered pretty hacky.
.Latinx isn't sans-serif (it has no font families specified), but inherits from the surrounding elements. In the h1 header of Reconstruction:Proto-Shughni-Yazghulami/ǧ́æwærs (<h1id="firstHeading"class="firstHeading"lang="en">Reconstruction:Proto-Shughni-Yazghulami/<spanclass="Latinx"lang="ira-shy-pro">ǧ́æwærs</span></h1> in Vector, it displays in a serif font. In entries, it's usually in a sans-serif font. — Eru·tuon17:40, 1 June 2019 (UTC)
No, but I am interested as well. This looks really useful, and according to the docs "is designed to be easily portable to other wikis". – Jberkel17:41, 1 June 2019 (UTC)
So for this to work we need to add "template data" sections to our citation template documentation pages, which include a mapping from whatever the API returns to the parameters used by our templates. WP example w:Template:Cite_book/TemplateData, look for the citoid key under "maps" in the source. Then we need to create a map from native citoid types to template names. See w:MediaWiki:Citoid-template-type-map.json for an example. – Jberkel14:45, 2 June 2019 (UTC)
I gather the Template Data pages would be pretty similar to those on Wikipedia but who can edit/create MediaWiki pages? ─ ReconditeRodent « talk · contribs »