Wiktionary:Grease pit/2019/May

---

On my user page, not all of the {{rel}} tables I'm using are working. Any idea why that might be? Is there another table I can use instead to avoid the problem? Andrew Sheedy (talk) 04:19, 1 May 2019 (UTC)[reply]

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·tuon 05:30, 1 May 2019 (UTC)[reply]

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

Interesting, thanks! That explains why some were working and some weren't. Andrew Sheedy (talk) 14:31, 1 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

@Mihia Sorry, my fault. Fixed. Benwing2 (talk) 03:31, 3 May 2019 (UTC)[reply]

@Benwing2: Hi, thanks for looking at that. Mihia (talk) 20:48, 7 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

Thanks, I hadn't noticed that the preview included categories at the very bottom--Urszag (talk) 18:03, 3 May 2019 (UTC)[reply]

All categories are added using [[Category:...]] 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: [[Category:English lemmas|WORD]][[Category:English nouns|WORD]].

Category:Latin second conjugation verbs with perfect in -s- or -x- is added by Module:la-verb. I'll see if I can figure out why it's not being added to eluceo. — Eru·tuon 17:59, 3 May 2019 (UTC)[reply]

Okay, so Category:Latin second conjugation verbs with perfect in -s- or -x- isn't being added to eluceo because the present stem is given as ēlūc with long ū while the perfect stem is given as ēlux with a short u. If you add the macron to the perfect stem, the category will be added. I don't know if the module should ignore macrons or not, but if so, I could code that. — Eru·tuon 18:06, 3 May 2019 (UTC)[reply]

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)[reply]

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·tuon 18:15, 3 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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·tuon 18:36, 3 May 2019 (UTC)[reply]

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)[reply]

@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·tuon 19:17, 3 May 2019 (UTC)[reply]

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)[reply]

I thought I saw some exceptions. But here's a list based on that and a module for testing different rules. — Eru·tuon 20:01, 3 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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 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·tuon 20:17, 3 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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·tuon 20:28, 3 May 2019 (UTC)[reply]

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[1])" "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)[reply]

The rules for "perfects in -s- or -x-" just look at the present and perfect active stems, nothing else. I'm just asking about the |type= parameter so that I can remove junk from the list of present and perfect active stems. — Eru·tuon 21:17, 3 May 2019 (UTC)[reply]

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)[reply]

(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·tuon 21:27, 3 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Yes, that's what you'd use {{lb|en|uncomparable}} for. —Rua (mew) 20:54, 4 May 2019 (UTC)[reply]

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)[reply]

I understand your problem, maybe some way of inserting {{q|also uncomparable}} is possible. DonnanZ (talk) 10:04, 5 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

@SemperBlotto, Metaknowledge, Rua I am thinking of replacing calls to {{inflected form of}} and {{de-inflected form of}} in German non-lemma forms to use proper calls to {{inflection of}}. The original concern expressed in Wiktionary:Requests_for_deletion/Others#Template:de-inflected_form_of was that you'd need to list an excessive number of inflections to handle some of the forms, esp. those ending in -en, but I figured out how to do it in <= 5 inflections each. See User:Benwing2/billigen for how I propose to make the inflections look. Benwing2 (talk) 15:55, 5 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

@Rua What about using en dashes instead of "and" to join values along a syncretized axis? See User:Benwing2/billigen2 for how this would look in this case. Benwing2 (talk) 16:18, 5 May 2019 (UTC)[reply]

For reference, User:Benwing2/billigen-one-axis-only is the equivalent using "and" that syncretizes along only one axis at a time, and User:Benwing2/billigen2-one-axis-only is the equivalent using en-dashes that syncretizes along only one axis at a time. Benwing2 (talk) 16:42, 5 May 2019 (UTC)[reply]

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)[reply]

@-sche User: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):

1. dative and ablative masculine, feminine, and neuter plural of omnis
2. dative–ablative masculine–feminine–neuter plural of omnis
3. dative/ablative masculine/feminine/neuter plural of omnis

03:20, 12 May 2019 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ OK, I finally managed to get rid of all uses of {{de-inflected form of}}. Benwing2 (talk) 03:50, 13 May 2019 (UTC)[reply]

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[2 or 3]. 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)[reply]

@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·tuon 18:18, 5 May 2019 (UTC)[reply]

The Reconstruction namespace is defined in Module:links, once on line 73 and again on line 173. There are also a few occurrences in Module:headword, if you decide to copy that. —Rua (mew) 18:54, 5 May 2019 (UTC)[reply]

Yay. I never thought the fix would be simple. Thank you very much! RXerself (talk) 19:14, 5 May 2019 (UTC)[reply]

@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)[reply]

@RXerself: You have to post a request on Phabricator; see the post requesting the Reconstruction namespace here on English Wiktionary (by Rua incidentally). — Eru·tuon 19:26, 5 May 2019 (UTC)[reply]

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)[reply]

I was trying to create a page for the surname Blower and I got this message:

[XM9OMgpAICgAAINzZL0AAAAM] 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)[reply]

I don't know why, but {{also|Blower}} should be added to blower. DonnanZ (talk) 21:17, 5 May 2019 (UTC)[reply]

No, you've found some kind of bug. I've never seen that error message before and users aren't supposed to see it. Equinox ◑ 21:21, 5 May 2019 (UTC)[reply]

Yeah, I'm seeing it too. DonnanZ (talk) 21:34, 5 May 2019 (UTC)[reply]

I can't find a pattern. A lot of English (potential) pages are affected, but I found some in other languages too: Manzana (es), Pêche (fr), Takkola (Alabama), Omena (fi). Julia ☺ ☆ 21:40, 5 May 2019 (UTC)[reply]

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)[reply]

That definitely happened with Manzana - diff DonnanZ (talk) 11:55, 6 May 2019 (UTC)[reply]

All those are upper case single words, I tried Bollocks to Brexit (a message I saw from the train into Waterloo), I think I could have entered it. DonnanZ (talk) 22:09, 5 May 2019 (UTC)[reply]

Peter Bowman started a Phabricator ticket for this bug (T222462). — Eru·tuon 23:16, 5 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

I restored the deleted entry and then edited it. See comment above by Mofvanes. DCDuring (talk) 13:56, 6 May 2019 (UTC)[reply]

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)[reply]

Geek seems fine now. DCDuring (talk) 22:10, 8 May 2019 (UTC)[reply]

I get this error in a diff page Special:Diff/52758887, unrelated with the conversion script. --Vriullop (talk) 09:36, 12 May 2019 (UTC)[reply]

@Vriullop: Yeah, that's a separate bug due to the /**/ in the edit summary; it's being tracked in phab:T222857 or phab:T222628 and should be fixed soon. — Eru·tuon 18:03, 12 May 2019 (UTC)[reply]

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)[reply]

@Sistemx: You can try visiting this category: Category:Requests for translations into Spanish. Note that some people like to carpet request translations, LOL, so just fill the requests for important, common terms or interesting ones. --Anatoli T. ^{(обсудить}/^вклад) 07:08, 7 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

User:Ungoliant MMDCCLXIV/missing translations, not updated in several years, but maybe it could be regenerated if you ask. DTLHS (talk) 16:04, 7 May 2019 (UTC)[reply]

I tried editing 迁#Japanese, but it was flagged as “vandalism” even though I just tried to add a definition and source. 2600:387:5:803:0:0:0:8B 00:13, 8 May 2019 (UTC)[reply]

@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. - TheDaveRoss 00:24, 8 May 2019 (UTC)[reply]

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)[reply]

It indicates that you added a part-of-speach header without a (necessary) headword-line template such as {{la-adj-3rd-1E}} or {{head|la|adjective}} under it. - -sche (discuss) 07:26, 8 May 2019 (UTC)[reply]

Oh, thanks for the explanation! Is there a way to add something about this to the Special:Tags page?--Urszag (talk) 08:21, 8 May 2019 (UTC)[reply]

Or in this case, {{la-adj-form}}, which I just added. Chuck Entz (talk) 07:37, 8 May 2019 (UTC)[reply]

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)[reply]

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? – Jberkel 20:10, 8 May 2019 (UTC)[reply]

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)[reply]

I added a description. As far as I know all Special/MediaWiki pages can only be edited by administrators, . - TheDaveRoss 22:51, 8 May 2019 (UTC)[reply]

Interface administrators can edit MediaWiki pages. — Eru·tuon 02:20, 9 May 2019 (UTC)[reply]

Could someone add the following to the entry for Purepecha (pua) at Module:languages/data3/p?

	sort_key = {
		from = {"á", "é", "í", "ó", "ú"},
		to   = {"a", "e", "i", "o", "u"}},

--Lvovmauro (talk) 08:53, 8 May 2019 (UTC)[reply]

@Lvovmauro: Done. — Eru·tuon 15:13, 8 May 2019 (UTC)[reply]

Can someone edit the category tree module so categories such as Category:en:Regions of China, Category:en:Regions in Asia, and Category:en:Regions in the world nest in each other? I also believe they should use the same preposition, but at least they'll link to each other. Ultimateria (talk) 15:26, 8 May 2019 (UTC)[reply]

@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)[reply]

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|[[Abderhaldensche]] [[Reaktion]]}} and {{m|de|[[alles]] [[andere]] [[sein|ist]] [[Menschenwerk]]}} (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)[reply]

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·tuon 18:34, 8 May 2019 (UTC)[reply]

@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)[reply]

@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. [Edit: result.] — Eru·tuon 18:46, 8 May 2019 (UTC)[reply]

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)[reply]

@Erutuon Thank you again, that looks good. Now to decide if this is safe enough to do with a bot... —Rua (mew) 18:59, 8 May 2019 (UTC)[reply]

This version removes newlines as a separator. — Eru·tuon 19:01, 8 May 2019 (UTC)[reply]

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·tuon 19:09, 8 May 2019 (UTC)[reply]

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)[reply]

It occurs to me that another thing to look for would be other linking templates, like etymology templates, followed by {{l}} or {{m}}. — Eru·tuon 19:38, 8 May 2019 (UTC)[reply]

jsonl format might be easier for the bot to eat. — Eru·tuon 19:52, 8 May 2019 (UTC)[reply]

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)[reply]

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·tuon 02:57, 9 May 2019 (UTC)[reply]

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)[reply]

@Rua: Here you go. — Eru·tuon 14:35, 9 May 2019 (UTC)[reply]

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)[reply]

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. – Jberkel 12:02, 9 May 2019 (UTC)[reply]

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)[reply]

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^[1]. 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)?

--Urszag (talk) 21:28, 8 May 2019 (UTC)[reply]

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)[reply]

@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̥C^[5] 02:52, 9 May 2019 (UTC)[reply]

@JohnC5: Thanks! That's exactly what I was looking for.--Urszag (talk) 04:03, 9 May 2019 (UTC)[reply]

@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)[reply]

@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̥C^[5] 18:43, 9 May 2019 (UTC)[reply]

I kind of like the / format; shorter and easier to type than numbered params. Benwing2 (talk) 00:13, 10 May 2019 (UTC)[reply]

@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·tuon 03:40, 12 May 2019 (UTC)[reply]

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: [[Wiktionary:Word of the day/Error: Invalid time.|← yesterday]] | About Word of the Day • Archive • Nominate a word • Leave feedback | [[Wiktionary:Word of the day/Error: Invalid time.|tomorrow →]]. 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)[reply]

Could it be the waning gibbous Moon? DCDuring (talk) 22:14, 8 May 2019 (UTC)[reply]

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. – Jberkel 22:38, 8 May 2019 (UTC)[reply]

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)[reply]

@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·tuon 05:51, 9 May 2019 (UTC)[reply]

@Erutuon: thanks for the quick response - I'll experiment. — Saltmarsh. 05:56, 9 May 2019 (UTC)[reply]

@Erutuon: thanks again, both produce a good result - please can you tell me the name of that "curvaceous" font. — Saltmarsh. 06:03, 9 May 2019 (UTC)[reply]

@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·tuon 14:50, 9 May 2019 (UTC)[reply]

There are over 4,400 categories in Category:Empty categories. Should we delete them? SemperBlotto (talk) 09:00, 9 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

As long as you are aware, before you start deleting categories willy-nilly. DonnanZ (talk) 11:52, 9 May 2019 (UTC)[reply]

I've run a bot to delete empty categories before, and I still have the script. —Rua (mew) 12:09, 9 May 2019 (UTC)[reply]

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)[reply]

User:Wyang deleted them in the past and some folks made a ruckus. —Suzukaze-c◇◇ 18:29, 9 May 2019 (UTC)[reply]

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)[reply]

A diligently maintained maintenance category is often empty. DCDuring (talk) 23:58, 9 May 2019 (UTC)[reply]

We could restrict the deletion to non-maintenance categories, then. —Rua (mew) 09:50, 10 May 2019 (UTC)[reply]

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 · talk 15:57, 17 May 2019 (UTC)[reply]

Can the wording of this template be reversed to "definite singular of"? It is backwards. DonnanZ (talk) 14:15, 9 May 2019 (UTC)[reply]

If the wording is changed, the canonical name of the template should be changed, too. To my surprise, the two terms seem to be almost equally common. - -sche (discuss) 16:17, 9 May 2019 (UTC)[reply]

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)[reply]

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·tuon 19:34, 9 May 2019 (UTC)[reply]

-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)[reply]

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·tuon 20:38, 9 May 2019 (UTC)[reply]

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)[reply]

I changed the wording of the three mentioned templates. I will do the bot renaming later tonight. Benwing2 (talk) 01:00, 10 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

Yes, I know. I still like to know of changes to pages I created. DonnanZ (talk) 12:13, 10 May 2019 (UTC)[reply]

I have superseded {{definite singular of}} for new pages with {{infl of|nb|term||def|s}} (for Bokmål, nn for Nynorsk), but there is no rush to convert the older ones now. DonnanZ (talk) 13:04, 10 May 2019 (UTC)[reply]

Note that Module:accel/no still uses {{singular definite of}}. —Rua (mew) 13:17, 10 May 2019 (UTC)[reply]

@Rua Thanks, fixed. 13:58, 10 May 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ There are still the four templates {{genitive singular definite of}}, {{genitive singular indefinite of}}, {{genitive plural definite of}}, {{genitive plural indefinite of}}. I fixed the wording on them so they now read "(in)definite genitive {singular/plural} of". Should we fix the template names as well? If so, I think we should just rewrite in terms of {{inflection of}} directly. Benwing2 (talk) 14:02, 10 May 2019 (UTC)[reply]

They're better replaced than fixed, I agree. —Rua (mew) 14:09, 10 May 2019 (UTC)[reply]

They are used in Danish, I think. Genitives are not recorded in Norwegian, thank goodness. DonnanZ (talk) 15:20, 10 May 2019 (UTC)[reply]

@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)[reply]

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)[reply]

The four templates {{genitive singular definite of}}, {{genitive singular indefinite of}}, {{genitive plural definite of}}, {{genitive plural indefinite of}} have been orphaned and deprecated. Benwing2 (talk) 03:58, 13 May 2019 (UTC)[reply]

@Benwing2 Note that there is no genitive case in the Scandinavian languages, so the uses of these templates were probably erroneous in the first place. See Wiktionary:Beer parlour/2018/September#Genitive case in the Scandinavian languages, where this issue was brought up but ignored. —Rua (mew) 17:26, 13 May 2019 (UTC)[reply]

@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)[reply]

Recently I've been seeing a lot of this on the home page:

Mihia (talk) 20:16, 10 May 2019 (UTC)[reply]

I don't know what happened, but clearing the cache (pressing "refresh" on the top right of the WotD box) removed the error. — Eru·tuon 20:30, 10 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

This has nothing to do with Lua. DTLHS (talk) 20:43, 10 May 2019 (UTC)[reply]

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)[reply]

Yes, it’s annoying. Not sure if we can do anything about it. — SGconlaw (talk) 00:36, 11 May 2019 (UTC)[reply]

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. – Jberkel 08:39, 11 May 2019 (UTC)[reply]

I think I fixed it. Jberkel 14:51, 14 May 2019 (UTC)[reply]

Can someone help me with this? --Shad Veyosiv (talk) 06:50, 12 May 2019 (UTC)[reply]

@Shad Veyosiv I have tried to fix it, please let me know if it works. Benwing2 (talk) 19:35, 12 May 2019 (UTC)[reply]

I don't think we have a template for the Concise Scots Dictionary [1] / Dictionary of the Scots Language [2], [3]. 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)[reply]

For references we have {{R:Dictionary of the Scots Language}} and {{R:DSL}} – take your pick. For quotations we have {{RQ:Dictionary of the Scottish Language}} to quote Jamieson’s original 1808 dictionary. — SGconlaw (talk) 12:42, 12 May 2019 (UTC)[reply]

Oh, I missed seeing those. Thanks a lot. DonnanZ (talk) 13:18, 12 May 2019 (UTC)[reply]

— SGconlaw (talk) 14:33, 12 May 2019 (UTC)[reply]

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)[reply]

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·tuon 19:37, 12 May 2019 (UTC)[reply]

Actually, I wonder if Mediawiki:Common.css can even import a sanitized CSS page, given that the two have very different purposes. — Eru·tuon 19:42, 12 May 2019 (UTC)[reply]

@Erutuon: You can find @import being used in the meta.wiki Common.css without any issue. --{{victar|talk}} 20:19, 12 May 2019 (UTC)[reply]

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·tuon 20:44, 12 May 2019 (UTC)[reply]

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·tuon 20:03, 12 May 2019 (UTC)[reply]

@Erutuon: As a template editor, I could go blank out Module:languages and Module:scripts right now which would virtually take down the site. I don't see allowing the less than 20 template editors access to this being any more dangerous. --{{victar|talk}} 20:19, 12 May 2019 (UTC)[reply]

@Chuck Entz do you have any thoughts? --{{victar|talk}} 15:18, 13 May 2019 (UTC)[reply]

All the pings. @Stephen G. Brown, Vorziblix, Surjection, -sche, Metaknowledge --{{victar|talk}} 15:21, 23 May 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@Rua: I looked at MediaWiki:Gadget-RhymesAdder.js and I think I can fix this. — Eru·tuon 17:33, 13 May 2019 (UTC)[reply]

@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·tuon 05:03, 16 May 2019 (UTC)[reply]

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 Mage ^{talk to meh} 21:30, 13 May 2019 (UTC)[reply]

@The Ice Mage I am trying to eliminate language-specific templates like {{fi-form of}} that don't do anything that {{inflection of}} doesn't do. The change involving nominative/accusative plural wasn't intentional; let me look into it. Benwing2 (talk) 23:40, 13 May 2019 (UTC)[reply]

@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)[reply]

@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 Mage ^{talk to meh} 16:37, 14 May 2019 (UTC)[reply]

@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)[reply]

I agree. If you use {{inflection of}} twice, then you also repeat the lemma link twice, which is pretty pointless. —Rua (mew) 08:45, 15 May 2019 (UTC)[reply]

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)[reply]

@Sgconlaw: Done, I think. This is simpler than the task mentioned above. — Eru·tuon 02:23, 15 May 2019 (UTC)[reply]

Thanks! — SGconlaw (talk) 03:05, 15 May 2019 (UTC)[reply]

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)[reply]

@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·tuon 17:20, 16 May 2019 (UTC)[reply]

Yes, looks good. Can you change them all to {{der}}? —Rua (mew) 17:23, 16 May 2019 (UTC)[reply]

@Rua: Not very conveniently, as I don't have a bot. — Eru·tuon 17:30, 16 May 2019 (UTC)[reply]

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·tuon 00:33, 18 May 2019 (UTC)[reply]

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)[reply]

@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·tuon 19:15, 16 May 2019 (UTC)[reply]

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. – Jberkel 11:39, 17 May 2019 (UTC)[reply]

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. – Jberkel 16:04, 17 May 2019 (UTC)[reply]

When I go to https://en.wiktionary.org/wiki/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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

It would be simpler and less error-prone if categorization in that template could just be disabled for English altogether. — Eru·tuon 23:47, 17 May 2019 (UTC)[reply]

@Erutuon I implemented this in the template. Benwing2 (talk) 20:46, 18 May 2019 (UTC)[reply]

@Benwing2: Thanks! I wasn't sure of the best way to do it. — Eru·tuon 21:08, 18 May 2019 (UTC)[reply]

Thanks, all ! Leasnam (talk) 21:19, 18 May 2019 (UTC)[reply]

@Benwing, I just created daredevilling. It seems it's still categorising it into 'English present pariticples'. Leasnam (talk) 21:23, 18 May 2019 (UTC)[reply]

@Leasnam: I'm not seeing the category there. Oh, you put in {{head|en|present participle}} at first. That is expected to categorize in Category:English present participles. It doesn't automatically change the category to Category:English verb forms. — Eru·tuon 21:36, 18 May 2019 (UTC)[reply]

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)[reply]

It could just use Module:accel to generate the page nowadays. Then the format would stay up to date. —Rua (mew) 22:10, 18 May 2019 (UTC)[reply]

@Leasnam: Aha, that button is using Template:new en verb pres part. That template should be updated. (I remember seeing its text in nonsensical entries created by vandals.) — Eru·tuon 22:32, 18 May 2019 (UTC)[reply]

Cool. Thanks Leasnam (talk) 22:42, 18 May 2019 (UTC)[reply]

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)[reply]

Ok, seems resolved. Thanks ! Leasnam (talk) 03:54, 20 May 2019 (UTC)[reply]

(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)[reply]

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?)

So I guess I have three requests/questions:

1. Could someone create the template Template:ti-verb 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?

I appreciate your time. — This unsigned comment was added by Corbariano (talk • contribs) at 09:41, 20 May 2019.

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)[reply]

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)[reply]

@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)[reply]

@Victar: Are there any cases left? User:Erutuon has been handling this. --Anatoli T. ^{(обсудить}/^вклад) 05:16, 21 May 2019 (UTC)[reply]

@Atitarev: Actually, I didn't do Ossetian because it's not one of the only-Cyrillic languages. — Eru·tuon 05:44, 21 May 2019 (UTC)[reply]

@Victar Can you add a standardChars field for Ossetian in Module:languages/data2? DTLHS (talk) 17:01, 21 May 2019 (UTC)[reply]

@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)[reply]

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 (^[\p{Latin}\p{Inherited}\p{Common}]+$ in the regex library) and no Latin characters and replace the Latin æ with Cyrillic ӕ. — Eru·tuon 18:08, 21 May 2019 (UTC)[reply]

@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.

(Someone will have to do it in Wikipedia as well, then they start copying/pasting the right symbols). --Anatoli T. ^{(обсудить}/^вклад) 01:46, 23 May 2019 (UTC)[reply]

I was hoping a bot operator could do it, but I'll go ahead since at least I've figured out a method. — Eru·tuon 02:29, 23 May 2019 (UTC)[reply]

@Erutuon: Thanks a lot! --Anatoli T. ^{(обсудить}/^вклад) 02:56, 23 May 2019 (UTC)[reply]

@Atitarev: Cleaned up all the instances in the list. — Eru·tuon 04:21, 23 May 2019 (UTC)[reply]

@Erutuon: You're a champion! --Anatoli T. ^{(обсудить}/^вклад) 04:23, 23 May 2019 (UTC)[reply]

e.g. I created tabloid talk show, with explicit head=tabloid talk show. The auto-generated plural then had the wrong head (head=tabloid talk, missing the word show entirely). Equinox ◑ 11:08, 21 May 2019 (UTC)[reply]

I reported this back in November … — SGconlaw (talk) 12:31, 21 May 2019 (UTC)[reply]

I deleted your entry to make testing easier. - TheDaveRoss 15:58, 21 May 2019 (UTC)[reply]

@Equinox, Sgconlaw: Fixed, I think. The bug appeared when the page name had more than one space in it. — Eru·tuon 18:54, 21 May 2019 (UTC)[reply]

Great! Thanks. — SGconlaw (talk) 18:56, 21 May 2019 (UTC)[reply]

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)[reply]

Doesn't look like they got switched here. — Eru·tuon 22:06, 21 May 2019 (UTC)[reply]

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)[reply]

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·tuon 22:22, 21 May 2019 (UTC)[reply]

Maybe, I wonder if I'm the only one.– Tom 144 (𒄩𒇻𒅗𒀸) 22:25, 21 May 2019 (UTC)[reply]

Could someone please add Pali genders to MediaWiki:Gadget-TranslationAdder.js by default, similar to Sanskrit? I don't have access to edit it. --Anatoli T. ^{(обсудить}/^вклад) 00:35, 23 May 2019 (UTC)[reply]

@Atitarev: I've copied the Sanskrit genders over to Pali in MediaWiki:Gadget-TranslationAdder-Data.js. — Eru·tuon 00:48, 23 May 2019 (UTC)[reply]

@Erutuon: Thank you! --Anatoli T. ^{(обсудить}/^вклад) 00:50, 23 May 2019 (UTC)[reply]

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 penultimate antepenultimate 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.

User:Benwing2 knows what I'm talking about. Please don't change manual translit for Russian for irregular pronunciations, though. Also calling @Erutuon, Rua. --Anatoli T. ^{(обсудить}/^вклад) 03:10, 23 May 2019 (UTC)[reply]

For Macedonian, stress is not marked if it falls on the antepenultimate (not penultimate) syllable in words of 3 or more syllables; see w:Macedonian language#Stress. —Mahāgaja · talk 09:56, 23 May 2019 (UTC)[reply]

@Mahagaja: Yes, certainly, I meant that but used the wrong word, LOL. —Anatoli T. ^{(обсудить}/^вклад) 10:50, 23 May 2019 (UTC)[reply]

@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·tuon 05:05, 27 May 2019 (UTC)[reply]

@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)[reply]

@Erutuon:

1. 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).
2. You can come across all types of weird/non-standard transliterations with or without accents, e.g. see Ukrainian in this revision or this revision (these don't have stresses), so it may require visual analysis. --Anatoli T. ^{(обсудить}/^вклад) 06:41, 27 May 2019 (UTC)[reply]

@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·tuon 23:58, 27 May 2019 (UTC)[reply]

@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)[reply]

@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)[reply]

@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·tuon 02:42, 28 May 2019 (UTC)[reply]

@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)[reply]

@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)

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 [[ice]] [[cream]]). This also happens across some punctuation marks, but not others (e.g. at hexa-2,4-dienal, {{head|en|noun}} outputs [[hexa-2]],[[4-dienal]] 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 · talk 10:04, 23 May 2019 (UTC)[reply]

@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·tuon 18:58, 23 May 2019 (UTC)[reply]

It may be "silly", but is this different from, say, Vietnamese? or Latinate phrases? —Suzukaze-c◇◇ 20:04, 23 May 2019 (UTC)[reply]

@Suzukaze-c: Not really, no. I don't know enough Vietnamese to do anything about those, but when I encounter things like [[fiat]] [[lux]] in an English headword line, I do edit it to remove the links. —Mahāgaja · talk 20:29, 23 May 2019 (UTC)[reply]

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)[reply]

@Mahagaja: Indeed, so the same can be done for Tibetan, no? Or are monosyllablic terms really that uncommon? —Suzukaze-c◇◇ 07:58, 26 May 2019 (UTC)[reply]

@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)[reply]

@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 · talk 12:18, 27 May 2019 (UTC)[reply]

@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.

For example, compare this usage: พริกเผ็ดใครให้เผ็ด ฉันใด หนามย่อมแหลมเองใคร เซี่ยมให้ จันทน์กฤษณาไฉน ใครอบ หอมฤๅ วงศ์แห่งนักปราชญ์ได้ เพราะด้วยฉลาดเอง

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 [that are] hot [by themselves] 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 [of these people] 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)[reply]

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)[reply]

@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)[reply]

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. —Μετάknowledge^{discuss/deeds} 20:51, 23 May 2019 (UTC)[reply]

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)[reply]

See this edit: [4]. No apparent effect. Is it wrong? Equinox ◑ 22:12, 26 May 2019 (UTC)[reply]

What do you mean? That module makes Category:en:Tiddlywinks work. Are you trying to do something else, like have {{lb|en|tiddlywinks}} add a category? [Edit: Spotted squop. Added label.] — Eru·tuon 22:35, 26 May 2019 (UTC)[reply]

(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ō [all intransitive]
• delete supine incrētum from incrēscō [not in dictionaries]
• delete passive of succrēscō [intransitive]
• delete passive of olēscō, adolēscō, exolēscō, but leave adultus and exolētus [intransitive]
• delete passive of exsolēscō, plus perfect exsolēvī and supine exsolētum [intransitive, and no perfect or supine attested in dictionaries; presence of perfect and supine probably due to confusion with exolēscō]
• delete perfect acēvī of acēscō and delete supine acētum [correct perfect is acuī, no supine attested in dictionaries]

[etc.] I want to make sure everyone is OK with this before I start. Benwing2 (talk) 15:28, 28 May 2019 (UTC)[reply]

• Go for it. SemperBlotto (talk) 15:31, 28 May 2019 (UTC)[reply]

@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)[reply]

@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 · talk 06:17, 29 May 2019 (UTC)[reply]

@Mahagaja Thanks. The gerundive used impersonally seems much like the gerund, and in any case the forms in -endus wouldn't exist. Benwing2 (talk) 06:45, 29 May 2019 (UTC)[reply]

@Benwing2: It seems to be possible, but very uncommon for an intransitive verb to have an attested gerundive form. The forms don't have to be singular neuter. I asked a question about nascendus on the Latin Stack Exchange site; the answers there mention some other examples, such as senescendorum. --Urszag (talk) 08:04, 29 May 2019 (UTC)[reply]

When I “look up” a redlink like θιγγάνω, the Languages section on the left-hand side is empty, yet there are el:θιγγάνω, fr:θιγγάνω, and mg:θιγγάνω. Would there be a way of getting these to show up?  --Lambiam 23:18, 30 May 2019 (UTC)[reply]

phab:T190210. not much activity unfortunately. – Jberkel 23:45, 30 May 2019 (UTC)[reply]

They show up if you preview the page. DTLHS (talk) 23:58, 30 May 2019 (UTC)[reply]

Really, where? – Jberkel 00:17, 31 May 2019 (UTC)[reply]

Just edit the page and then click "preview" below the edit box. — Eru·tuon 00:19, 31 May 2019 (UTC)[reply]

(edit conflict) 1) Open a red link in the edit mode 2) Click the large Show preview button at the bottom of the screen 3) Check intweriki links on the left. --Anatoli T. ^{(обсудить}/^вклад) 00:21, 31 May 2019 (UTC)[reply]

Ah, I have the beta editor active, it doesn't work there, the preview just shows the content area. – Jberkel 00:26, 31 May 2019 (UTC)[reply]

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:

Code used to generate this example:

.mw-body h1,
.mw-body-content h1,
.mw-body-content h2 {
	font-family: serif;
}

.mw-body h1,
.mw-body-content h1 {
	font-size: 2em;
}

.mw-body-content h2 {
	font-size: 1.66666667em;
}

Are there any uncounted for negatives to this? @Erutuon, Jberkel, Rua, -sche, Wikitiki89, Metaknowledge, JohnC5 --{{victar|talk}} 04:27, 31 May 2019 (UTC)[reply]

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)[reply]

Yes, the second is much better. The first is broken on my setup (Chrome / Windows). SemperBlotto (talk) 09:04, 31 May 2019 (UTC)[reply]

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. – Jberkel 13:17, 31 May 2019 (UTC)[reply]

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·tuon 00:19, 1 June 2019 (UTC)[reply]

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)[reply]

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)[reply]

@-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·tuon 03:34, 1 June 2019 (UTC)[reply]

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·tuon 03:48, 1 June 2019 (UTC)[reply]

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)[reply]

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). – Jberkel 08:32, 1 June 2019 (UTC)[reply]

@-sche: Setting the header to serif might 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 method for Reconstruction:Proto-Shughni-Yazghulami/ǧ́æwærs is to apply fonts to Latinx specifically, because the term in the header is already tagged as Latinx (this is done in Module:headword; search "displaytitle"). That would make ǧ́æwærs display differently from the rest of the header and Victar is against it. — Eru·tuon 16:49, 1 June 2019 (UTC)[reply]

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·tuon 16:59, 1 June 2019 (UTC)[reply]

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.

--{{victar|talk}} 17:35, 1 June 2019 (UTC)[reply]

.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 (<h1 id="firstHeading" class="firstHeading" lang="en">Reconstruction:Proto-Shughni-Yazghulami/<span class="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·tuon 17:40, 1 June 2019 (UTC)[reply]

Your proposed list of fonts works for me. (It makes the header display in Tinos.) — Eru·tuon 17:57, 1 June 2019 (UTC)[reply]

Does anyone know if it would be possible to repurpose the code from the auto Citation template maker on Wikipedia for quote templates here (T:ux, T:quote-book, T:quote-web, etc)? ─ ReconditeRodent « talk · contribs » 23:24, 31 May 2019 (UTC)[reply]

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". – Jberkel 17:41, 1 June 2019 (UTC)[reply]

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. – Jberkel 14:45, 2 June 2019 (UTC)[reply]

I gather the Template Data pages would be pretty similar to those on Wikipedia but who can edit/create MediaWiki pages? ─ ReconditeRodent « talk · contribs »