Wiktionary:Grease pit/2020/August

Templates not working with an Old Prussian word

Despite the page kīsman existing, some templates don't link to the word: Old Prussian kīsman, kīsman, kīsman. However, Template:t-simple works. - Sarilho1 (talk) 21:30, 1 August 2020 (UTC)[reply]

@Sarilho1: The language data for Old Prussian is currently set up so that module-based link templates will remove macrons (entry_name = {remove_diacritics = MACRON}): {{m|prg|kīsman}} links to kisman. But there are lots of entry names with macrons in Category:Old Prussian lemmas. This is inconsistent, so either the entries need to be moved or the language data needs to leave the macrons. The decision should be made by those who know Prussian (I don't). — Eru·tuon 22:03, 1 August 2020 (UTC)[reply]

I see, that explains it, then. Well, I don't know anything about the language either, but it's good to know it wasn't a mistake on my part. Thank you for answering. - Sarilho1 (talk) 22:28, 1 August 2020 (UTC)[reply]

Perusing Old Prussian language and the websites listed at the bottom of that page that provide texts, I get the impression that diacritic marks are very rare in Old Prussian. The only letters with diacritics I noticed are ê and ů, though there may be a few more. I didn't notice a single instance of ī. Unfortunately Ivan Štambuk, who created the entry, is no longer active at Wiktionary. —Mahāgaja · talk 00:04, 2 August 2020 (UTC)[reply]

This is a matter of normalisation. Original Old Prussian texts spell long i as any of <i y ie>, and scholars are able to reconstruct vowel length as a result. A community decision needs to be made about the presentation of normalised vs original orthography, as must be done with all such languages. —Μετάknowledge^{discuss/deeds} 00:10, 2 August 2020 (UTC)[reply]

If original Old Prussian texts never (or very rarely) use ī, then we shouldn't use it in entry names, though of course it can still be used in headword lines and mentions, since diacritic stripping is already activated. —Mahāgaja · talk 00:20, 2 August 2020 (UTC)[reply]

Category:English terms with multiple etymologies

Would it be possible to cause this category to be automatically populated instead of having to be manually added to entry pages? — SGconlaw (talk) 13:54, 2 August 2020 (UTC)[reply]

@Sgconlaw It's possible for Lua code to access the entire page text, which is what is required to implement this, but it's considered an "expensive" operation so I'm not sure it would be advisable to add it. Benwing2 (talk) 23:43, 2 August 2020 (UTC)[reply]

OK, no worries. Was just wondering if it would save some effort. — SGconlaw (talk) 04:36, 3 August 2020 (UTC)[reply]

There are only 11,813 pages with English L2 sections that have "Etymology 2" somewhere on the same page, but are not in your desired category (using search string 'incategory:"English lemmas" -incategory:"English terms with multiple etymologies" insource:/Etymology\ \2/'). So probably around 10,000 pages would need hard categorization. Dump processing could produce the list of English L2s with "Etymology 2" headers and perhaps AWB or some other tool could do the actual updating. It seems like the kind of thing that would be worth doing annually rather than in real time. DCDuring (talk) 10:20, 3 August 2020 (UTC)[reply]

I guess we could also ask whether this is a useful category to maintain (I'm not sure). I just happened to notice it had been added to some entries. — SGconlaw (talk) 16:32, 3 August 2020 (UTC)[reply]

Assisted rhyme ("Add new rhyme") not working properly

The "+Add new rhyme" feature isn't working properly. See [1] (an older version of this page, which I have now cleaned up), where a user recently added several rhymes using this feature. They were tacked on to the end of their respective sections instead of being put in the right places.

The problem is partly (or wholly) because the feature creates entries of the form {{l|en|word}} while most of the manually entered rhymes are formatted as [[word]]. The updated list of words is then sorted and the new entry ends up getting put at the end of the list instead of in its correct position. Given that the English section is at the top of the pages linked to anyway, is there any benefit in using this formatting rather than just the simple links? (The alternative would be to write a bot to reformat all of the links to the {{l|...} format, but that would need to be done with great care. Some links are followed by qualifiers, some have variations of the same word on a single line, and some links are to Wikipedia entries (most of which are gradually being changed to link to Wiktionary entries instead).) — Paul G (talk) 15:49, 2 August 2020 (UTC)[reply]

That the gadget would not place rhymes in the correct order is not at all related to {{l}} usage. It is rather due to the gadget not knowing about {{rhyme list begin}}. This gadget has always had this kind of problems and pretty sure will continue to have unless we standardize rhymes layout. I suggest we require sections use {{rhyme list begin}}/end templates if assisted adding of rhymes is desired. Any objections? Dixtosa (talk) 18:05, 2 August 2020 (UTC)[reply]

One small objection: that template seems to use a fixed number of columns (two, I think). Some sections of the rhymes pages have very many entries and look better with more columns. At the moment I make a judgement and use the topX and bottom (where X = 2, 3, 4 or 5) templates as appropriate. I'm more than happy to use the "rhyme list begin/end" templates if they can be updated to split a list automatically into more or fewer columns for longer or shorter lists. Would that be possible? — Paul G (talk) 08:47, 16 August 2020 (UTC)[reply]

@Paul G: I have now updated rhyme's gadget to only allow adding rhymes to the sections marked with the template I mentioned. I have also taken your issue into consideration and added an unnamed parameter to the template. See example [[here Dixtosa (talk) 20:02, 22 August 2020 (UTC)[reply]

moving compound nouns to their own category (out of compound words)

I've just finished removing about 1,300 non-noun (and not excusively noun) entries from Category:Hungarian compound words. The remaining ~4,500 entries are solely nouns. Could you please help me moving them to Category:Hungarian compound nouns by replacing "}}" with "|pos=noun}}"? (It doesn't matter if it's at the end of a "{{compound}}" or an "{{af}}" template.) It's usually the very first instance within the "Hungarian" section, given under "Etymology". There are less than a dozen cases with a preceding "Alternative forms" section, which should be left intact; I can even handle them manually. Adam78 (talk) 11:22, 3 August 2020 (UTC)[reply]

@Benwing2, do you think you might be able to do this with the help of your bot? Adam78 (talk) 22:25, 4 August 2020 (UTC)[reply]

@Adam78 I can do this. Benwing2 (talk) 00:35, 5 August 2020 (UTC)[reply]

Done. I left the words with "Alternative forms" sections. Note that the pronunciation for pólóing appears wrong, with a stray [ʲ]. Benwing2 (talk) 02:36, 5 August 2020 (UTC)[reply]

@Benwing2, thanks a LOT! I'll deal with the remaining handful. The epenthetic, non-phonemic [ʲ] is inserted automatically between a back and a front vowel by the pronunciation template, but we'll think it over if it's actually justified there. I tend to think it is, at least in average (not very formal) pronunciation; I'll confirm with @Panda10. Thank you so much once again! Adam78 (talk) 08:16, 5 August 2020 (UTC)[reply]

@Adam78 If [ʲ] is supposed to represent an actual glide between vowels, it should be [j]. [ʲ] is only intended as a consonant modifier to indicate that the consonant is palatalized. Benwing2 (talk) 02:05, 6 August 2020 (UTC)[reply]

@Adam78, Benwing2 It is not the same as the Hungarian [j]. It's much weaker. A distinction is necessary to avoid confusion. Appendix:Hungarian pronunciation explains the IPA symbols the way they are used in Hungarian terms in this project. But if there is another IPA symbol that would work better here, we can certainly change it. Panda10 (talk) 16:51, 6 August 2020 (UTC)[reply]

@Panda10 The standard IPA symbol for that would be [j̞], i.e. a [j] with a lowering diacritic to indicate the weakened pronunciation. Benwing2 (talk) 02:41, 7 August 2020 (UTC)[reply]

@Panda10 Also, I wonder if what you think of as [j] is actually [ʝ], i.e. a palatal fricative. Benwing2 (talk) 02:42, 7 August 2020 (UTC)[reply]

Wikipedia indicates the weak glide as [j̆], which appears a non-standard use of IPA. Benwing2 (talk) 02:46, 7 August 2020 (UTC)[reply]

@Benwing2 Thanks for thinking about this. We are trying to research the options. It is not [ʝ], though. That symbol is already used for [j] at the end of the word after b, v, g, r, m, as in szomj, fürj, etc. Panda10 (talk) 17:47, 7 August 2020 (UTC)[reply]

@Benwing2: [j̆] is standard IPA: the breve is used to indicate an ultrashort pronunciation. (Note that the symbol is not [ǰ] with a hacek, which in IPA could only mean [j] with a rising tone.) Using the lowering diacritic wouldn't necessarily indicate a weakened pronunciation, merely a more open one, which would correspond to a nonsyllabic [ɪ̯] or even [e̯]. —Mahāgaja · talk 08:56, 8 August 2020 (UTC)[reply]

Here is the conclusion for those of you who followed this thread. Based on research, the decision is to use [j] for both the regular consonant and the glide variant. Even though there is a time difference in pronunciation, it's very short, an average of 10 ms. Thank you all who added comments and thoughts to this topic. Panda10 (talk) 16:31, 8 August 2020 (UTC)[reply]

auto cat not working in some categories; or without alphabetical sorting in some others

{{auto cat}} doesn't work in categories Hungarian compound adverbs, determiners, interjections, numerals, particles, postpositions, pronouns, suffixes, conjunctions, and verbs. Could someone please add these to the right module or template? (I added the necessary categories manually to each, but now they are not listed at the head of the parent category Hungarian compound words.) If you wish, you can also create the relevant global categories like "Category:Compound adverbs/determiners/interjections/numerals/particles/postpositions/pronouns/suffixes/verbs by language".

On the other hand, the Category:Hungarian compound adjectives and Hungarian compound nouns work almost all right, except for the alphabetical sorting in Hungarian compound words, since both of them are located at "C", instead of A(djectives) and N(ouns). Could it be fixed? (The above issue should also be possibly fixed with this in mind.) Thank you all in advance. Adam78 (talk) 13:06, 5 August 2020 (UTC)[reply]

@Adam78 Fixed. Benwing2 (talk) 02:04, 6 August 2020 (UTC)[reply]

@Benwing2 Thank you very much! Adam78 (talk) 11:57, 6 August 2020 (UTC)[reply]

Information desk purged

When I went to WT:ID, it finished with WT:ID#Category:Chinese_lemmas, and didn't contain my answer to the previous post. When I went to WT:Information desk/2020/August, it had my reply, and a further two sections. I fixed this by purging the page. Is something broken, or is it normal to have to do this? --ColinFine (talk) 16:48, 5 August 2020 (UTC)[reply]

Template:RQ:Undertale

That template should probably use {{quote-video game}} instead. Glades12 (talk) 14:38, 7 August 2020 (UTC)[reply]

Done. It was easy. --Kriss Barnes (talk) 23:45, 12 August 2020 (UTC)[reply]

`{{ca-adj}}`

I can't specify a |mpl= parameter, but the masculine plural of adjectives in -gen is -`gens. E.g. for endogen it's endògens and not the automated *endogens. Ultimateria (talk) 07:19, 8 August 2020 (UTC)[reply]

@Ultimateria I looked at the code, and the |pl= parameter should work for this purpose, despite the documentation. Benwing2 (talk) 16:57, 8 August 2020 (UTC)[reply]

Old Saxon, Old Swedish, and Macedonian links to —

Some inflection templates are linking to —, the — entity. If you click the link you are prompted to create a page &mdash without a semicolon. Examples:

{{mk-conj-и-impersonal|impf|студ|noap=1}} (in студи (studi)) (also {{mk-conj-а-impersonal}}, {{mk-conj-е-impersonal}})
{{osx-decl-table|mūs|mūs|musi|musi|musi|musi|mūsiō|mūsium|head=mūs}} (in mus) (also {{osx-decl-noun}} and variants)
{{gmq-osw-decl-noun-a-n|ētr|acc_sg=ēter|gen_sg=ēters|nom_sg=ēter|nopl=1}} (in eter)

If the inflection table entry is — it should not be a link. Vox Sciurorum (talk) 17:05, 8 August 2020 (UTC)[reply]

@Vosx Sciurorum I fixed Old Saxon. Each of these cases has to be handled individually. Benwing2 (talk) 22:28, 8 August 2020 (UTC)[reply]

@Vox Sciurorum Benwing2 (talk) 22:28, 8 August 2020 (UTC)[reply]

I fixed the Macedonian templates. — Eru·tuon 18:42, 9 August 2020 (UTC)[reply]

Edit notice in language data modules

I've added an edit notice to the regular language data modules (Module:languages/data2, Module:languages/data3/a, etc.). It pops up when you edit the modules. It's basically an abbreviated version of the documentation page and it explains the various data items. It's still a bit long, so language data editors, let me know if that's annoying. And any suggestions for improvements would be welcome. — Eru·tuon 23:15, 8 August 2020 (UTC)[reply]

It's great! I edit those modules rather frequently, and I didn't even know that otherNames was deprecated. —Μετάknowledge^{discuss/deeds} 23:34, 8 August 2020 (UTC)[reply]

Edit notice in label data modules

I've added an edit notice to Module:labels/data, Module:labels/data/regional, Module:labels/data/subvarieties, Module:labels/data/topical that explains the data keys. These modules provide label data for {{label}} ({{lb}}) and {{term-label}} ({{tlb}}). The notice displays when you edit the module. Suggestions for improvements are welcome. — Eru·tuon 21:12, 10 August 2020 (UTC)[reply]

Error message when trying to use advanced search features.

I often will search for words only in a specific category, but today, after I had been searching that way for a while, when going on to the next list of word results that was going to follow, I got this message:

"A warning has occurred while searching: Deep category query returned too many categories"

An absurd message, as I was only searching one category (Category:English lemmas). Moreover, I search that category all of the time.

Now I seem blocked for the time being from using the advanced search features, because if I do (no matter what I put in) it spits out that error message. Tharthan (talk) 05:46, 11 August 2020 (UTC)[reply]

@Tharthan: I guess you mean a query like deepcategory:"English lemmas". I get the same error message. (I had never used the feature before.) Maybe someone has added more subcategories of Category:English lemmas recently, but I don't see any in RecentChanges. It's probably something none of us admins can fix (unless by deleting categories?); it would be worth asking the folks at #wikimedia-tech on Freenode though. — Eru·tuon 07:47, 11 August 2020 (UTC)[reply]

Oh, good. I'm an IRC person, so I'd be glad to do that. Tharthan (talk) 08:13, 11 August 2020 (UTC)[reply]

I submitted a Phabricator task, after a discussion with one of the folks at #wikimedia-tech. I can link that here if desired, or not. It's up to you (plural). Tharthan (talk) 15:43, 11 August 2020 (UTC)[reply]

I don't know why one wouldn't link to Phabricator; I always do when I submit a task. But I found your task: phab:T260152. — Eru·tuon 18:39, 11 August 2020 (UTC)[reply]

Problem with Tea Room page

The bottom of WT:TR only shows a single discussion in August. Clicking on the August 2020 link takes one to the August 2020 subpage. I'm not one to be trusted to fix that, no matter how trivial it may be. DCDuring (talk) 23:59, 11 August 2020 (UTC)[reply]

Fixed now. I must have been looking at the page in the middle of a technical correction. DCDuring (talk) 00:01, 12 August 2020 (UTC)[reply]

I had a similar problem on the Info Desk last week, @DCDuring:, and it only went away when I purged the page. I asked (above) whether this was normal or a fault, but nobody replied. --ColinFine (talk) 17:47, 13 August 2020 (UTC)[reply]

I may have caused both problems. I was trying to insert missing months headers using the old anybody-who-knows-wikitext-can-do-it method. I didn't realize that most discussion pages with their new, improved structure need monthly updating using new methods, which I wouldn't even know where to look to learn. The upshot is that, when I notice missing months headers, all I have to do and all I can do is whine about it. DCDuring (talk) 01:04, 14 August 2020 (UTC)[reply]

Module:th-pron

Generates badly formed HTML. Namely it's putting a DIV outside of the TD that should wrap it.

Suggestions on how a contributor is SUPPOSED to repair it when there's virtually NO documentation on how it SHOULD be done? Thanks? ShakespeareFan00 (talk) 23:13, 12 August 2020 (UTC)[reply]

This was mentioned over 2 years ago and nothing happened Wiktionary:Grease_pit/2018/December#Template:th-pron ? ShakespeareFan00 (talk) 12:39, 13 August 2020 (UTC)[reply]

Looking at the code in a sandbox it seems the 'problem' is that the code used to generate the rows of the relevant table, doesn't apparently generate the tags in the right sequence, or certain code is getting moved by a flawed 'tidy' up. ShakespeareFan00 (talk) 12:42, 13 August 2020 (UTC)[reply]

There is a now a sandbox version, that does not generate the LintErrors. If someone couldswap it in?ShakespeareFan00 (talk) 15:13, 13 August 2020 (UTC)[reply]

Lua error: not enough memory

Hello, if you look towards the later part of 紅, the templates seem to be erroring out. Opencooper (talk) 02:16, 17 August 2020 (UTC)[reply]

Yes, there are currently about 30 entries in Category:Pages with module errors that we haven't been able to do anything about. There may be a few that we can fix, but the Chinese character entries use some very memory-intensive templates that are hard to to do without. Chuck Entz (talk) 02:56, 17 August 2020 (UTC)[reply]

@Chuck Entz: don't we have a practice of moving some parts of such pages to subpages, with a link on the main page? We could create a template for displaying on the main entry page to explain the situation. — SGconlaw (talk) 07:28, 17 August 2020 (UTC)[reply]

@Sgconlaw: So far we only do that for translations of English entries, as least as far as I know. —Mahāgaja · talk 14:30, 17 August 2020 (UTC)[reply]

@Chuck Entz, Mahagaja: it seems quite weird to have some entries replete with error messages and do nothing about it. The best stopgap solution seems to be to shift some content to one or more subpages and have a message on the main entry page explaining why this has been done. I would suggest that the language headings (in the above case, "Japanese", "Korean", "Old Japanese", and "Vietnamese") remain on the main page so that readers are aware that there are entries for these languages, and the substantive content be moved to subpages called "紅/Japanese", "紅/Korean", and so on. — SGconlaw (talk) 14:40, 17 August 2020 (UTC)[reply]

In fact, just moving the Japanese section to a subpage may suffice. — SGconlaw (talk) 14:43, 17 August 2020 (UTC)[reply]

@Sgconlaw: One of the difficulties is that multiple templates rely on the title. So if you move the Japanese section of 紅 to 紅/Japanese, 紅/Japanese will be used in multiple places where 紅 is expected, most notably displayed in the headword-line templates. (There are other invisible places; for instance, some of the templates insert /Japanese into category sortkeys, as you can see with Special:ExpandTemplates.) There might be a workaround for all the headword templates (a |head= or |pagename= parameter), but I don't know all the places where the title is used, and whether they can get by using the title with /Japanese appended. So it's hard to be sure that something won't break invisibly. — Eru·tuon 19:24, 17 August 2020 (UTC)[reply]

@Erutuon: maybe we should try copying the Japanese section to 紅/Japanese (i.e., not deleting it from the entry page yet), and see what issues crop up with the subpage. — SGconlaw (talk) 19:35, 17 August 2020 (UTC)[reply]

@Sgconlaw I can guarantee that it will break some things. The problem with our CJKV templates is that they get a lot of information from entry wikitext- basic things like transliteration. If you move the wikitext, you would have to change the code to be able to find it. Also, I know of at least one template that checks header levels on its own page and will throw a module error if anything isn't right- even in other language sections. If you ask me, some of the code is a bit too dependent on programming tricks- but I'm not sure how to change anything without wreaking havoc on a lot more pages than the few that have problems now. If you preview one of these pages with the module errors, you'll see an enormous list of transclusions: data modules, submodules, etc., but also a long list of entry names. Any time a module loads the wikitext from an entry, it shows as a transclusion on the list (it says "templates used in this entry", but it's really any kind of transclusion).

At any rate, I don't edit the CJKV pages except to fix obvious general problems, so it's not for me to say what should be done. You would have to ask people like @Justinrleung, Eirikr or @Suzukaze-c who actually work with all of these templates. These may be memory- and processor-hogs, but they do stuff that the CJKV communities depend on. Chuck Entz (talk) 04:19, 18 August 2020 (UTC)[reply]

Oh dear. I don't edit these pages either, but it seems quite strange that nothing can be done to solve this problem. It means that the efforts made by editors in maintaining these entries is fruitless, because most of the entry pages cannot be read. Perhaps those who work on the CJKV templates can look into adjusting them so that they ignore everything after the oblique ("/") in the pagename, which would enable them to be used on subpages? — SGconlaw (talk) 13:01, 18 August 2020 (UTC)[reply]

I believe most of the memory consumption comes from the section "Derived terms" (or sometimes named "Compounds"). You can try moving only these sections to a subpage, which should be easy and not error-prone. -- Huhu9001 (talk) 20:00, 21 August 2020 (UTC)[reply]

Well, I was wrong. Only a small part of the memory consumption comes from "Derived terms". But my suggestion seems working. See 一/derived terms. -- Huhu9001 (talk) 09:58, 22 August 2020 (UTC)[reply]

i encountered this problem looking for the Spanish word i. i mistakenly thought i had at least skimmed this section of the grease pit, but here it is, a lot of technical talk i don't understand. Nevertheless, here's what i posted to Talk:i, where i thought a "sandbox" might help diagnose the problem and/or trial run a solution.
Posting this to Talk:i and Wiktionary:Grease_pit#Lua_error:_not_enough_memory
i used CTRL+F to search the i article for "Lua error: not enough memory". Besides the "Requests for cleanup" header, the first search result i got was in Rapa Nui. i clicked "Edit" on the i article and used copy-paste on Rapa Nui and everything below it to "mirror" it on Talk:i. Looks like maybe splitting one page into two pages (or two tabs) might give each page enough memory to work? Maybe make i redirect to something like i/languages with names A-P with a hatnote like, "For i in other languages, see i/in languages with names R-Z"? --96.244.220.178 23:06, 19 September 2020 (UTC)[reply]

Cognate finder tool

https://www.reddit.com/r/linguistics/comments/ibqwtz/cognate_finder/ —Justin (koavf)❤T☮C☺M☯ 10:35, 18 August 2020 (UTC)[reply]

Interesting. This is a Python script that creates lists of words derived from a word in a common ancestor, and gets quite a few accurate results, using the HTML (not the most efficient method).

The method yields some false positives. The script looks for a link to the Wikipedia article for the common ancestor of the two languages (as in {{inh}}) and reports the next link as the ancestor word. Sometimes the link immediately following is not an ancestor (as in {{cog}}) or there is text intervening. This is why "Arabic" is reported as the Proto-Semitic ancestor of Amharic አለም (ʾäläm) and of Arabic م (m) and why there is a nonsensical link in the Amharic–Arabic cognates; both pages have a link to the Wikipedia article on Proto-Semitic, then some text, then a link to the Wikipedia article on Arabic. I didn't look for any false positives because of {{cog}}, but there might be some, depending on the languages you're looking at.

The intervening text thing might be fixable, but there will still be false positives because the HTML for {{inh}} and {{cog}} and {{noncog}} and {{der}} and {{bor}} is identical. To weed out {{cog}} and {{noncog}}, which definitely don't indicate ancestors, you have to look at the wikitext instead of the HTML, which requires rewriting the entire script. (Or we could make the HTML output of these templates distinct in some way.) — Eru·tuon 19:13, 18 August 2020 (UTC)[reply]

#* #*

I believe we have, or at least had, a list of all entries containing #* #*. Such crappy formatting usually came about from Wonderfool errors, but even DCDuring (talk • contribs) has been known to be guilty of such a misdemeanour. Can we generate a list or something? WT:Todo/Double hash star would be a fine name... --Kriss Barnes (talk) 18:16, 18 August 2020 (UTC)[reply]

@Kriss Barnes: Created. I regret to report that the list is very short. ☹️ — Eru·tuon 19:56, 18 August 2020 (UTC)[reply]

Great. All cleaned up in less than a minute! How about a list of templates that start with RQ: and that include #*, like Template:RQ:Wonder Fool? I have a feeling I may have created a couple of these a while ago... --Kriss Barnes (talk) 20:01, 18 August 2020 (UTC)[reply]

Huh, excluding documentation pages, only four results in the whole template namespace: Template:Buyla-inscription, Template:nquote, Template:vote-checkuser-intro, Template:vote-sysop-intro. Apparently you didn't. — Eru·tuon 21:03, 18 August 2020 (UTC)[reply]

Removing symbols.

I'm a bit new with wiktionary. I decided to add a definition on the word 'armour plate' as it had none yet. I couldn't seem to remove visible '[ ]' symbols without getting a warning. — This unsigned comment was added by 197.245.108.209 (talk).

You can see the changes needed to fix formatting at Special:diff/60120778. As for the content, if it is no more than the sum of armour and plate we generally don't create "sums of parts" entries. Vox Sciurorum (talk) 22:52, 21 August 2020 (UTC)[reply]

Old English verb conjugation (inflection) template of slēpan 'to sleep'.

I shaped my own verbal inflection template for the Anglian vaariant of 'to sleep' in Old English, which, when i tried to submit it, was immediately flagged as "abusive". There's a 'request for inflection' on the page, so have i missed something? If so, what? Is that verb somehow barred from receiving an inflection template, and if so why that verb, why not slāpan as well (one can make a case for it being Far less common). As Ringe (2014) points out that everywhere except in Wessex was long æ reared to ē. He also states that in Wessex the change of long æ to ā in many words but was quickly reverted to it's æ sound by the West-Saxons—and our modern form of the word comes from slēpan, so couldn't it be beneficial having an inflection table for the verb which is the etymon for the contemporary descendent? — This unsigned comment was added by 2602:306:CF6F:520:BC0F:CA63:53D6:B460 (talk) at 16:38, 23 August 2020 (UTC).[reply]

The reason an abuse filter rejected your edit was that it contained triple braces ({{{), which would retrieve template parameters. They shouldn't be used in an entry. I see that just copying the conjugation template from slæpan and changing the infinitive doesn't work. User:Benwing2, is there a way to use {{ang-conj}} for slēpan? — Eru·tuon 16:54, 23 August 2020 (UTC)[reply]

@Erutuon I can change the module to support slēpan and potentially other Anglian forms. How are they conjugated? The West Saxon conjugation as implemented in the module has past sg/pl slēp or slǣpte, past part slǣpen. Would the Anglian equivalent have an ē throughout? Other possible Anglian variants are e.g. faldan, fallan, walcan etc. in place of WS fealdan, feallan, wealcan etc. WS has past ēo in these verbs but Anglian might smooth it to ē. Wikipedia under Anglian smoothing says it should occur in walcan (wēlc not #wēolc) but not in the others, although I can't verify this. Note that the module handles class 7 strong verbs as a large number of special cases rather than a unified verb class, because there are so many exceptions and variants. Benwing2 (talk) 21:06, 23 August 2020 (UTC)[reply]

Regexes in Lua

Are there any regex libraries for Modules that can be used? Or are we constrained by Lua's limited Patterns? Kritixilithos (talk) 15:37, 25 August 2020 (UTC)[reply]

@Kritixilithos: No, nothing built into the Scribunto extension at least, which is the only way to get a regular expression library like PCRE written in an efficient language such as C. Someone posted a request on Phabricator, but it was declined. And we haven't used any regular expression libraries written in Lua either, which is probably a good thing because they are likely to be inefficient in memory usage and cause even more module errors. — Eru·tuon 17:05, 25 August 2020 (UTC)[reply]

Oh well, can't even use alternation, I will have to come up with a work-around. Thank you for your reply. Kritixilithos (talk) 18:05, 25 August 2020 (UTC)[reply]

@Kritixilithos I have gotten used to using Lua patterns for the various conjugation/declension modules I've written. It's true there is no alternation, but I haven't found that to be as limiting as you might think. If you have a case where you really need alternants, you just have to use multiple pattern matches, but most of the time either it doesn't come up or there are ways to rewrite it. Benwing2 (talk) 08:18, 27 August 2020 (UTC)[reply]

Request change to `{{R:pt:Infopédia}}`

Hi! I would like to request, if no one opposes it, the addition of a new optional parameter to {{R:pt:Infopédia}}, where, if activated, the root of the url would change from https://www.infopedia.pt/dicionarios/lingua-portuguesa/ to https://www.infopedia.pt/dicionarios/toponimia/. This would be quite useful to source toponyms, and I don't think creating an entirely new template is worth it. - Sarilho1 (talk) 21:02, 28 August 2020 (UTC)[reply]

fixing the continent of East Timor

Would someone with access please fix the parent category of East Timor in Module:place/shared-data, changing it from Africa to Asia? (Cf. CIA Factbook for reference.) Thank you. Adam78 (talk) 17:01, 30 August 2020 (UTC)[reply]

Done —Μετάknowledge^{discuss/deeds} 18:47, 30 August 2020 (UTC)[reply]

Thank you. One more thing: Kazakhstan is basically considered more of an Asian country than a European one (even if it's transcontinental, see reference), its category should be moved to Asia in the navigation tree/path (that starts from Fundamental). Adam78 (talk) 00:43, 31 August 2020 (UTC)[reply]

I don't know how to do that. I tried flipping the order, in case that works, but I doubt it will. —Μετάknowledge^{discuss/deeds} 04:01, 31 August 2020 (UTC)[reply]

It seems it did work! Category:en:Kazakhstan Thanks! Adam78 (talk) 11:23, 31 August 2020 (UTC)[reply]