Wiktionary:Grease pit/2021/January

Combining diacritics edit

@DannyS712 brought a very strange redirect page to my attention. It's for a combining diacritic that puts a double dot under a letter, as in "x" vs. "x̤". This indicates murmured voicing, and is pretty much equivalent to the letter it redirects to, ʱ. I have a few questions:

What do we do with combining diacritics? While it's technically possible to search for this character, as a practical matter it's very difficult to copy it from anywhere using the normal user interface. We have it in the edit tools at the bottom of the edit window (under "IPA and enPR"), but if you run into it use somewhere combined with another character, I don't know of any way to select it in order to copypaste it without selecting the other character. I also have my doubts as to whether one can link to it using wikisyntax. The usual method, [[̤]], displays it, but there's no hyperlink.

Assuming someone knows how to isolate the character and get it into the search box, is it a good idea to have this as a redirect to a free-standing character that looks nothing like it? Should we put an character info box for its code point at the target page? Or is this a case for "Unsupported titles"? Chuck Entz (talk) 09:52, 1 January 2021 (UTC)[reply]

For the record, there is actually a link above in the example of the normal wikisyntax, its probably just too tiny to click on manually. The Linkclump chrome extension can be used, or you can check the dom manually DannyS712 (talk) 09:57, 1 January 2021 (UTC)[reply]
Specialized IPA keyboards should be able to create a standalone combining diacritic. —Suzukaze-c (talk) 10:08, 1 January 2021 (UTC)[reply]
As I said, it's technically possible to do all the normal things, but as a practical matter, if you know enough to figure out how to search for it, you probably already know what it means. Chuck Entz (talk) 10:15, 1 January 2021 (UTC)[reply]
  • Isn't this what U+25CC dotted circle is for? If we want to have a separate entry for U+0324 com­bi­ning diaeresis below (as opposed to redirecting to ʱ, since the latter really isn't used for breathy-voiced vowels), couldn't/shouldn't it be at ◌̤? —Mahāgaja · talk 10:24, 1 January 2021 (UTC)[reply]
    Yeah, I'm inclined to think the content (and hence, redirect target) should either be at ◌̤ or at an Unsupported Title, rather than just redirecting to a different character, and ◌̤ has the advantage of being a regular, mainspace entry. What we really need to consider, if we're trying to make this findable / reachable, is creating redirects or see-also links from any characters it appears under, like Chuck's example of . - -sche (discuss) 17:34, 4 January 2021 (UTC)[reply]

WOTD “yesterday” link edit

It should link to “Wiktionary:Word of the day/2020/December 31”, not “Wiktionary:Word of the day/2021/December 31” (Wiktionary:Main Page). J3133 (talk)

The same thing happened on Dec 31, when "tomorrow" linked to 1 Jan 2020, instead of 2021. The right word, new dawn, has appeared today however. DonnanZ (talk) 23:54, 1 January 2021 (UTC)[reply]

Discussion Monthly Pages edit

@Rua I move-protected all the discussion forums after a page-move vandal hit some of them, which makes the usual method of creating these using a bot more complicated. Just to be on the safe side, I did my best guess at an imitation of the technique (move the last page of the previous year to the name for the new monthly page, move it back, move the redirect at the name for the new page to the name for the next page, move that to the next page name, etc, then replace the contents of the string of redirects with {{discussion month}}).

I'm pretty sure the desired effect of adding new months to everybody's watchlists was accomplished for the January pages, but beyond that, I'm not so sure. Since my account settings add pages I create to my watchlist, I have no way to check- they would be added to my watchlist either way. Given the importance of having all the monthly discussion pages on everybody's watchlists, this should be checked, and, if need be, fixed. Chuck Entz (talk) 17:18, 1 January 2021 (UTC)[reply]

@Chuck Entz: All 2021 pages are on my watchlist. J3133 (talk) 17:27, 1 January 2021 (UTC)[reply]

Message: Lua error: not enough memory. It may be a temporary error. DonnanZ (talk) 23:58, 1 January 2021 (UTC)[reply]

It's OK now. DonnanZ (talk) 06:12, 2 January 2021 (UTC)[reply]

The category contains many terms which aren't multiword terms.
Most compounds and derivatives (Category:German compound words; Category:German words by prefix, Category:German words by suffix) aren't multiword terms, and a hyphen inside of a compound or derivative doesn't make it a multiword term.
See and compare:

--Der Zeitmeister (talk) 10:26, 2 January 2021 (UTC)[reply]

Same deal in Proto-Eskimo. I don't know what a hyphen indicates in Proto-Eskimo, but these words aren't indicated to be polymorphemic.__Gamren (talk) 18:41, 2 January 2021 (UTC)[reply]
Even in English, G-d isn't a multiword term. —Mahāgaja · talk 18:56, 2 January 2021 (UTC)[reply]
@Mahagaja, Gamren, Der Zeitmeister The algorithm isn't very smart about handling hyphens. You can add a language to data.hyphen_not_multiword_sep in Module:headword/data to disable adding a term to 'multiword terms' if it has a hyphen in it, but I'm not sure how to make it smart enough to handle all the cases above. Maybe it should be conservative and not add a page to 'multiword terms' based only on a hyphen. What do people think? Benwing2 (talk) 02:27, 4 January 2021 (UTC)[reply]
I think it would be better to err on the side of exclusion from the category. It's much easier to add {{cln|de|multiword terms}} manually to an entry that requires it than to remove it from one to which it's added automatically. —Mahāgaja · talk 07:58, 4 January 2021 (UTC)[reply]
@Mahagaja, Gamren, Der Zeitmeister OK, I added German and Proto-Eskimo to data.hyphen_not_multiword_sep, and added a flag |nomultiwordcat= to {{head}} to disable the category on a case-by-case basis. (There was already |noposcat=; I also added |nogendercat= to disable auto-addition of gender-based categories such as Category:German masculine nouns.) I think it makes sense at least for English to have Category:English multiword terms added based on hyphens, since the vast majority of hyphenated words are in fact multiword terms. However, if all this is still insufficient, there are some other things that could be done: (1) have the code check to make sure all hyphenated components exist as words; (2) reverse the sense of data.hyphen_not_multiword_sep so it functions as an inclusion list rather than an exclusion list. Note that (1) wouldn't catch G-d, but it would catch cases like g-ddamn. Benwing2 (talk) 02:45, 5 January 2021 (UTC)[reply]
Some other languages where this is an issue are being discussed at Wiktionary:Information desk/2021/March#Non-compounding_hyphen. - -sche (discuss) 22:27, 7 March 2021 (UTC)[reply]

The relevant Lua code needs to be updated to get rid of the module error that currently occurs when attempting to create this category with {{auto cat}}. I'm not familiar with any of the Lua code on this site so I don't know how to resolve this problem myself at the moment. User: The Ice Mage talk to meh 17:58, 3 January 2021 (UTC)[reply]

@The Ice Mage: No Lua work necessary. The error message said to add the name of a country, and I put in {{auto cat|the United States}} and it worked. — Eru·tuon 18:05, 3 January 2021 (UTC)[reply]

Wikipedia lists the family as Guamo–Chapakuran with a question mark...would someone be able to add data for that language family to Wiktionary, or is it better not to due to uncertainty or something? User: The Ice Mage talk to meh 20:10, 3 January 2021 (UTC)[reply]

I also have a different question relating to Guamo: I can see it's an extinct language, so I'm wondering how do I get the category page to say that? User: The Ice Mage talk to meh 20:50, 3 January 2021 (UTC)[reply]

@The Ice Mage: Add |extinct=1 to {{auto cat}}. —Mahāgaja · talk 21:28, 3 January 2021 (UTC)[reply]

Another thing I found on Special:WantedCategories for which data is apparently not set up yet. Wikipedia says it's a subfamily of Macro-Jê languages. User: The Ice Mage talk to meh 20:22, 3 January 2021 (UTC)[reply]

When trying to create this using {{auto cat}} it gives an error that references {{topic cat}}...does anyone know how to fix this? User: The Ice Mage talk to meh 16:30, 4 January 2021 (UTC)[reply]

@The Ice Mage: The error occurs because our canonical spelling of the language name is Ulukwumi. So either the category needs to be renamed CAT:Ulukwumi language or the canonical name needs to be changed at Module:languages/data3/u. —Mahāgaja · talk 17:35, 4 January 2021 (UTC)[reply]

Not enough memory edit

Well...a. What do we do with a page where it starts in entry 97? Esszet (talk) 01:27, 5 January 2021 (UTC)[reply]

Does anyone know what to do? This is a huge problem for the page. Esszet (talk) 02:13, 9 January 2021 (UTC)[reply]
Yes, there are a handful of pages like this (and there will only be more in the future). One solution is to create separate pages (messy but it works) and the other is to have someone working on the backend fix it (cf. phab:T188492). —Justin (koavf)TCM 04:31, 10 January 2021 (UTC)[reply]
According to Aklapper, it needs to be fixed here. Esszet (talk) 00:45, 12 January 2021 (UTC)[reply]
Isn't splitting pages according to language only a messy solution because it breaks with our established format? What if we moved all our entries to a new namespace, say Word: or Dictionary:, with the same pagename scheme as reconstructions, and then keep mainspace as disambiguation pages?__Gamren (talk) 21:59, 29 March 2021 (UTC)[reply]

This page has been cluttering up Category:ParserFunction errors since mid-November. Is there any way to control what shows up in that category like there is with Category:Pages with module errors? Or do we need to edit this to get rid of the test cases? Chuck Entz (talk) 15:24, 5 January 2021 (UTC)[reply]

Invalid ISBN edit

If you go to the 烏魯木齊乌鲁木齐 (Wūlǔmùqí) page, I have added an example sentence under the definition for Etymology 1 under the Chinese header. (Put aside whether this is a good example sentence for the moment- I plan to use this book elsewhere anyway.) There's a message there that says "Invalid ISBN". According the book itself, the ISBN of the book is 7-80053-740. The ISBN can be seen here: [1] [2]. There is no guidance at Template:ISBN for what I should do. The link on the Template:ISBN page to the ISBN Converter no longer works. I found an online resource that says that the ISBN for this book is not 7-80053-740 but is instead 7-80053-740-1. Should I trust that source or the book itself? Seeking guidance generally. --Geographyinitiative (talk) 11:02, 9 January 2021 (UTC)[reply]

@Geographyinitiative: An ISBN has only 10 or 13 digits (one introduced ISBN-13 after finding out 10 digits is too little for all books in the world). The last digit of either an ISBN-10 or ISBN-13 is a check digit calculated from the other digits, serving for computers to calculate whether and display if there might be a typo. Therefore the first ISBN you write here is an incomplete ISBN whereas only the latter can be perfect. Fay Freak (talk) 11:51, 9 January 2021 (UTC)[reply]
@Fay Freak Thank you for your informative response. Based on what you have said, is the nine digit ISBN I'm looking at here "wrong"? Did the publishers of this book make a "mistake"? Or did they omit something that is obvious? What should I do if I run into nine digit ISBNs in the future? Should some kind of note be added to Template:ISBN? --Geographyinitiative (talk) 11:55, 9 January 2021 (UTC)[reply]
 @Geographyinitiative: It’s not your fault in any case if an ISBN given by the book publisher is invalid, so there is nothing to worry. Although you can brute-force check the digits 0-9 to whether they validate. (In ISBN-10 the check digit is not only 0-9 but also possibly X.) Fay Freak (talk) 12:00, 9 January 2021 (UTC)[reply]
Corrected per WorldCat. —Suzukaze-c (talk) 12:02, 9 January 2021 (UTC)[reply]

@Fay Freak, Suzukaze-c I am learning a lot about ISBNs. You can see some more of my bad work at Category:Pages with ISBN errors. I would like to solve all these problems somehow and create a note on Template:ISBN that gives guidance for what to do when you get "Invalid ISBN" (maybe as simple as "go to Wiktionary Grease Pit" or "look it up at xxx database") --Geographyinitiative (talk) 12:09, 9 January 2021 (UTC)[reply]

Question about 2 language categories from WantedCategories edit

I have found 2 instances where Wiktionary is using one name for a language, but Wikipedia is using another, with the one used by Wiktionary just being a redirect.

Does anyone have opinions on which names we should use on Wiktionary? User: The Ice Mage talk to meh 16:51, 9 January 2021 (UTC)[reply]

Incidentally, I just noticed that Wiktionary is already using the name Western Karaboro for a related language. User: The Ice Mage talk to meh 16:53, 9 January 2021 (UTC)[reply]

swapping Recht haben and recht haben possibly with their history edit

In Duden online, the recommended form is the lowercase one, so the uppercase form should be the "Alternative form" and the lowercase form, the primary entry.

Due to the swapping, I don't know how moving could be done (unless I use a temporary third pagename, which is deleted afterwards). Obviously, a copy-paste wouldn't be very elegant, and the history of the two pages should be preserved. I'd like to ask someone with the right authorization to do it more professionally. Thank you in advance. Adam78 (talk) 17:41, 9 January 2021 (UTC)[reply]

I don't think they should be swapped. The only thing changing is the definition and possibly the etymology- the conjugation tables are the same. Chuck Entz (talk) 18:02, 9 January 2021 (UTC)[reply]
According to korrekturen.de "Recht haben" was the single prescribed form from 1996 (1st Rechtschreibreform) till 2004/2006. On the other hand, "recht haben" is the standard form since ages. Possible this info should be in the entries in some way, but possible better sourced and with 2004 or 2006 instead of "2004/2006". --46.91.98.89 11:57, 11 January 2021 (UTC)[reply]

Label modules are driving me up the wall edit

I am trying to add Category:Extremaduran Spanish to entries via a label, such as {{lb|es|Andalusia|Canary Islands|Extremadura}} at lavija. I would think that it should be added to Module:labels/data/subvarieties but note that labels "Andalusia" and "Canary Islands" are not at this module: instead, they are at Module:labels/data/regional. I added it there but there is no category that is created, nor is it linked in the label. What do I do to fix this? I have been running around trying to find what turns "{{lb|es|Canary Islands}} into a valid label that creates a link and adds an entry to Category:Canarian Spanish but I can't find it to save my life. Help, please. —Justin (koavf)TCM 04:30, 10 January 2021 (UTC)[reply]

Also Category:Huelvan Spanish and this edit. —Justin (koavf)TCM 04:47, 10 January 2021 (UTC)[reply]
Also Category:Riojano Spanish; I didn't even bother adding it to a module this time because there's no point in going far off track. —Justin (koavf)TCM 04:58, 10 January 2021 (UTC)[reply]
Category:Belizean Spanish works! Caramba. —Justin (koavf)TCM 07:21, 10 January 2021 (UTC)[reply]
To add: Category:Leonese Spanish, Category:Palencian Spanish, Category:Zamoran Spanish, Category:Cantabrian Spanish. —Justin (koavf)TCM 09:17, 10 January 2021 (UTC)[reply]
Category:Rioplatense Spanish and if I can find attestable terms, Category:Brazilian Spanish and Category:Saharan Spanish. Any help? —Justin (koavf)TCM 03:48, 14 January 2021 (UTC)[reply]
Maybe also Category:Equatoguinean Spanish. – Jberkel 11:04, 9 February 2021 (UTC)[reply]
IIRC one of the two modules named above doesn't actually do anything / get called on(?). (My impression is that they should be combined.) - -sche (discuss) 09:40, 9 February 2021 (UTC)[reply]

Template:R:fa:Gazophylacium edit

{{R:fa:Gazophylacium}} links to the wrong page because the pages in the book run backwards. See یڭیچری for example. The link to page 297 generates a Google Books URL with pg=PA297 which links to the page numbered 220. The correct URL contains pg=PA220 to link to page 297. I think this is impractical to do right with templates alone, but maybe somebody here has an idea. (@Vahagn Petrosyan) Vox Sciurorum (talk) 20:03, 10 January 2021 (UTC)[reply]

@Vox Sciurorum: I linked the archive.org version instead where the book does not run backwards. --Vahag (talk) 06:16, 11 January 2021 (UTC)[reply]

Gëzuar Vitin e Ri and its links that don't work edit

The entry in the title shows the expression with a link under each word, namely Gëzuar Vitin e Ri. Now, the entries Gëzuar and Vitin don't exist, because Gëzuar is capitalized and the entry is gëzuar without the capital, and vitin is an inflected form of vit (and also it's capitalized, vitin exists). As for Ri, it should link to ri. I would correct that myself, but I find myself confronted by an opaque template, namely { { head|sq|interjection } } outputting January. What can we do to fix this? MGorrone (talk) 14:17, 11 January 2021 (UTC)[reply]

Also, why does that template output the expression with links at the entry, but this bold "January" here in the GP? MGorrone (talk) 14:17, 11 January 2021 (UTC)[reply]

  • I fixed the links. {{head|sq|interjection}} without an explicit head argument takes the name of the current page (here, January) and formats it by the default method of breaking the word at spaces and linking the components. If you add a head argument you can control the formatting yourself. Vox Sciurorum (talk) 14:20, 11 January 2021 (UTC)[reply]

Someone has to update the relevant Lua modules so that this category can be like all other topical categories, being set up by simply using {{auto cat}}. I would do it, but I couldn't quite figure out what module to edit...I think the description "<langname> terms related to dictionaries." would be fine, and we should keep its parent categories as they are right now. User: The Ice Mage talk to meh 15:39, 11 January 2021 (UTC)[reply]

Esperanto terms spelled with Ĥ edit

The basic Esperanto alphabet contains the letter Ĥ. It is the most uncommon letter of the alphabet. I think it would be a good idea to automatically populate the category Category:Esperanto terms spelled with Ĥ with words that contain the letter. This can be acomplished by adding the following piece of code the line 136 of the module Module:eo-headword. The page is protected, so I cannot add or test this proposal myself.

if mw.ustring.match(PAGENAME, "[ĥĤ]") then
    table.insert(tracking_categories, "Esperanto terms spelled with Ĥ")

Robin van der Vliet (talk) (contribs) 22:39, 12 January 2021 (UTC)[reply]

You should edit Module:languages/data2. I have added the standard characters A-PRSTUVa-pRSTUVĉĈĝĜĵĴŝŜŭŬ. DTLHS (talk) 22:44, 12 January 2021 (UTC)[reply]
I also found that location, but I was unsure if that is the right location, since Ĥ is a standard character of Esperanto, it is not like Æ in English. Robin van der Vliet (talk) (contribs) 23:15, 12 January 2021 (UTC)[reply]
I think the letter Ĥ should be included among the standard characters at Module:languages/data2, because is part of the standard alphabet in Esperanto. --Rajzin (talk) 23:21, 12 January 2021 (UTC)[reply]
It doesn't matter. The only thing this field is used for is to populate these categories. DTLHS (talk) 23:26, 12 January 2021 (UTC)[reply]
Can you also add 0-9 to the standard characters? Robin van der Vliet (talk) (contribs) 02:40, 13 January 2021 (UTC)[reply]
Added. DTLHS (talk) 02:42, 13 January 2021 (UTC)[reply]
I agree that the proposal is probably worth implementing. Ĥ may not be a nonstandard character in Esperanto, but it is subject to some controversy in the Esperanto community - you can more or less divide Esperanto speakers into people that use Ĥ and people that don't.
Ĥ is the rarest letter by far and considered by some to be difficult to pronounce, making some Esperanto speakers advocate avoiding its use whenever possible (usually by changing Ĥ to K), leading to a whole class of alternative forms. (ĥemio vs. kemio, teĥniko vs. tekniko, etc.) Other speakers don't agree, and actively support keeping the letter alive.
So in my opinion there is real practical use to having an exhaustive list of Esperanto words on Wiktionary that contain Ĥ. --Rajzin (talk) 23:21, 12 January 2021 (UTC)[reply]

Add Italian standardChars at Module:languages/data2 edit

In order to make Category:Italian terms by their individual characters automatic. J3133 (talk) 08:57, 13 January 2021 (UTC)[reply]

Added. DTLHS (talk) 03:52, 14 January 2021 (UTC)[reply]

Requesting a new parameter in template "inflection of" edit

I'd like to request the addition of a new parameter in {{inflection of}}. The name of the parameter might be 2p or 2po, the displayed text should be second-person-object form and the entire text should be linked to Appendix:Glossary#second-person-object form. An example entry would be látlak. A discussion about this parameter is here: Template talk:hu-conj-unified/doWork. Thank you. Panda10 (talk) 18:48, 14 January 2021 (UTC)[reply]

@Panda10 I think Module:form_of/data and/or Module:form of/data2 need to be extended. I don't have the permission to edit them. If we check their history, we can find people who are authorized and whom we might personally contact. Adam78 (talk) 13:59, 15 January 2021 (UTC)[reply]

@Adam78 I added it to Module:form of/data2 and I updated látlak. It worked. Panda10 (talk) 18:29, 15 January 2021 (UTC)[reply]

@Panda10 Great! Thank you! :) Adam78 (talk) 18:38, 15 January 2021 (UTC)[reply]

Add Category:Terms spelled with * (by language) edit

E.g., “Category:Terms spelled with K (by language)” would contain the subcategories Category:Chinese terms spelled with K, Category:Irish terms spelled with K, Category:Italian terms spelled with K, Category:Latin terms spelled with K, Category:Portuguese terms spelled with K, Category:Spanish terms spelled with K, and Category:Welsh terms spelled with K. J3133 (talk) 08:48, 15 January 2021 (UTC)[reply]

Here, I presume: Module:category tree/poscatboiler/data/characters @Benwing2. J3133 (talk) 10:45, 16 January 2021 (UTC)[reply]

@J3133 I fixed up your code. The original reason for not having an umbrella category like this is because of Japanese kanji character categories like Category:Japanese terms spelled with 守; we'd end up with thousands of new umbrella categories, each holding a single Japanese category. I made it so that Japanese and Okinawan categories don't have an umbrella category, and other languages do. In general, all you need to do to add an umbrella category is to remove umbrella = false and add umbrella_parents = "Terms by their original characters subcategories by language" or similar (and add a raw entry for "Terms by their original characters subcategories by language"). In this case, it was trickier because the existing code assumed that there was a language in the category and used it to italicize and link the character in the description, breadcrumb and title. I changed it to use Translingual as the language for this purpose for the umbrella categories. Benwing2 (talk) 19:18, 17 January 2021 (UTC)[reply]

Question on customized acceleration layout and form creation with a bot edit

Are the language subpages to Module:accel for specific customization for a language? For Hungarian Module:accel/hu was recently deleted because I assume the standard code handled it. What type of customization is allowed? Whatever can be achieved with Lua? I'd like to understand it because the new conjugation acceleration added to {{hu-conj-unified/doWork}} would need some adjustments. Discussion about the current issues can be found in the Acceleration testing section on Template talk:hu-conj-unified/doWork. If we wanted to create the verb forms with a bot, would it be connected to the acceleration function or the bot works entirely separately? Panda10 (talk) 00:40, 16 January 2021 (UTC)[reply]

Bookmarklets edit

Wiktionary:Bookmarklets and Help:Tips and tricks/Bookmarklets are two rather old pages providing some bookmarklets. Do these still work at all? WP's article on bookmarklet explains that increased browser security now tends to prevent this technique from working. Should the pages be retired or updated in some way? Equinox 10:01, 16 January 2021 (UTC)[reply]

Not enough memory II edit

According to the people at the Phabricator, the memory issues we're having (see a and i) need to fixed here. Esszet (talk) 16:51, 17 January 2021 (UTC)[reply]

Ya. "50 MB ought to be enough for anybody." – Jberkel 16:59, 17 January 2021 (UTC)[reply]
So now what? Esszet (talk) 17:28, 17 January 2021 (UTC)[reply]
No solution for the foreseeable future, except forking the website and doing things our way. PUC17:31, 17 January 2021 (UTC)[reply]
Really? There's nowhere we can request more memory? Esszet (talk) 21:15, 17 January 2021 (UTC)[reply]
We requested. The answer was no. We should plan on splitting the page into parts. Vox Sciurorum (talk) 15:14, 18 January 2021 (UTC)[reply]
Or use fewer modules on big pages... e.g., tolerate subst:ing more templates on such big pages... - -sche (discuss) 09:42, 9 February 2021 (UTC)[reply]

Old Slavic font size edit

Why are Old East Slavic and Old Church Slavonic rendered in a larger font size? Looks like a bug to me, maybe a missing native script/font entry in a table somewhere? Compare Old East Slavic козакъ (kozakŭ) to Belarusian казак (kazak), Old Church Slavonic агода (agoda) to Russian ягода (jagoda). (Seen using Chrome on Chrome OS and Firefox on a Mac.) Vox Sciurorum (talk) 15:13, 18 January 2021 (UTC)[reply]

We treat Cyrillic and Old Cyrillic as two different scripts. On my computer, Old Cyrillic script is shown in a font that looks quite different from the modern Cyrillic script; it has the sort of uncial look shown in the "Image" column at w:Early Cyrillic alphabet#Alphabet. —Mahāgaja · talk 18:00, 18 January 2021 (UTC)[reply]
On my computer the scripts are almost identical except for size. Here are two letters to compare: {{m|orv|Д}} => Д (D) and {{m|ru|Д}}} => Д (D). The old form is taller than the Latin letters and almost identical in shape to the modern form (possibly very slightly more tapered, not triangular like the Wikipedia image). The modern form is the same height as Latin capital letters. Vox Sciurorum (talk) 18:55, 18 January 2021 (UTC)[reply]
@Vox Sciurorum:: Old Cyrillic script is set to 125% font size at MediaWiki:Common.css. This makes sense for most of the fonts specified there under .Cyrs, which cause the script to display in Uncial style and look clearer when displayed slightly larger. However, if you don’t have any of the first 11 fonts listed, you’ll end up with text in fallback fonts such as Code2000 or DejaVu Sans, which use the modern Civil Script style of Cyrillic, but unfortunately, it’ll still render in a larger size. — Vorziblix (talk · contribs) 15:36, 20 January 2021 (UTC)[reply]

How long does it take for all the transclusions of a template to update? edit

A fair proportion of https://en.wiktionary.org/wiki/Special:LintErrors/missing-end-tag?namespace=0 is down to one module which was fixed earlier today.

Manually purging 30,000 entries is time consuming. Can it be automated? ShakespeareFan00 (talk) 19:45, 18 January 2021 (UTC)[reply]

Multilingual Cuneiform font for usage in Wiktionary edit

Hello everybody in Ancient Oriental studies,

Although not a scientist, I would like to get in touch, thanks for your attention. I am a typeface designer and, in loose collaboration with researchers at several academic institutions in Germany, currently developing a new digital Cuneiform font family, which will be cross-checked and finalized in the course of 2021. The family will consist of the following fonts:

1. Neo-Assyrian forms, alongside Persian and Ugaritic Cuneiform

2. Neo-Babylonian forms

3. Old Babylonian forms as canonized by Unicode

4. Classical Sumerian forms (plus the most important archaic variants) for etymological purposes.

The idea is to develop one multilingual typeface family with a harmoneous design. Its main purpose is to bring together Old Babylonian forms and their Neo-Assyrian counterparts for better use in Dictionaries or sign lists such as on Wiktionary. The font family can be licensed for free. I would be excited if Wiktionary would use it as a webfont, if technically possible with your CMS. Then, characters could be displayed in ancient and more recent shapes, making study a richer experience. The design follows a lapidar style, while I regard cursive a domain of hand-rendering skills or photographic reproduction of existing tablets.

I am aware of a similar project already existing, maintained by German designer Johannes Bergerhausen, to whom I offered to add Neo-Assyrian glyph shapes to his “DecodeCuneiform” font, but however, there seem to be no resources currently.

The first chunk of work to be finished will be font (1) and (2) – Neo-Assyrian and Neo-Babylonian variants according to Rykle Borger and Henri Labat. Font (3) will mainly follow Unicode (Steve Tinney) and Catherine Mittermayer.

Unfortunately, I was not able to add an image for a first impression, much more I would be indeed excited to get in touch with the Cuneiform community on Wiktionary.

All the best from Berlin, Roman Wilhelm

http://www.roman946.de http://www.romantype.net — This unsigned comment was added by Roman R. Wilhelm (talkcontribs) at 11:48, 19 January 2021 (UTC).[reply]

Language tabs gadget - default language edit

I'd like to suggest that the languages tab gadget have a default language setting. When I'm looking up a word it's usually for the same language every time, but every time I go to a page I have to scroll/find the right language. To remove this, I've enabled the tab gadget and added a greasemonkey script that sets the anchor to the language I want. I've put a copy of the script on the gadget discussion page, but if when a user enabled the gadget it added a menu to the top bar providing a dropdown with a language selection, save that as a cookie, jump to that tab, would improve the UX I think. Discussion of this type of use has taken place before.

I'm happy to do this if someone's able to provide a bit of guidance, I've got no idea how to edit a gadget and have limited experience in JS.

Alwaysmpe (talk) 18:03, 19 January 2021 (UTC)[reply]

WT:ACCEL doesn't merge simple past and past participle edit

See [3]. It would be preferable for WT:ACCEL to recognise that bliked is both past forms, and generate only one line, as shown in my correcting edit that followed. Equinox 07:50, 20 January 2021 (UTC)[reply]

@Equinox Agreed. This only happens because blike has alternative past tense forms different from the past participle forms; it wouldn't happen with a completely regular verb like open. I'll add this to my backlog of things to do. Benwing2 (talk) 02:47, 25 January 2021 (UTC)[reply]

Add nows parameter to Template:ws edit

In order to not add “[Ws]” after the term; e.g., at Thesaurus:body of water, run would use nows because its Thesaurus page is unrelated to water (note that the template is protected). J3133 (talk) 10:36, 21 January 2021 (UTC)[reply]

@J3133:   Done. nows=1 will hide the WS link. --Yair rand (talk) 06:36, 28 January 2021 (UTC)[reply]

Add / before {{{y}}} (where is {{#if:{{{m|}}}|{{{y}}}), because, e.g., {{tea room sense|m=August|y=2020}} links to “Wiktionary:Tea room2020/August” (the template is protected). J3133 (talk) 10:36, 22 January 2021 (UTC)[reply]

  Done Chuck Entz (talk) 20:04, 22 January 2021 (UTC)[reply]

Limiting characters in head edit

Is it possible to trigger a warning or error from {{head}} if I enter an Ottoman Turkish word that uses a character not in the set at Ottoman Turkish alphabet? In particular, I've made a couple mistakes where I used U+06A9 keheh when I meant U+0643 kaf. They are very similar in connected form. In English a similar mistake would result in the word being added to a category, words spelled with (some non-Latin letter). Vox Sciurorum (talk) 00:20, 23 January 2021 (UTC)[reply]

The easy way is to add a list of standard characters to Module:languages/data3/o. DTLHS (talk) 01:01, 23 January 2021 (UTC)[reply]

I was going to create this but I just want to confirm, should I set the countries for this as Colombia and Peru? That seems to be what w:Witotoan languages says. User: The Ice Mage talk to meh 21:01, 25 January 2021 (UTC)[reply]

We don't usually specify countries for proto-languages anyway; their urheimaten are not necessarily where their descendants are currently spoken. —Mahāgaja · talk 22:01, 25 January 2021 (UTC)[reply]
I see, that makes sense I guess. Can you show me what/how to edit so that this category will be created properly without any Lua errors..? User: The Ice Mage talk to meh 16:47, 26 January 2021 (UTC)[reply]
@The Ice Mage: The problem was that sai-hoc-pro wasn't actually marked as a reconstructed language at Module:languages/datax. I've remedied that now and created the category. —Mahāgaja · talk 18:00, 26 January 2021 (UTC)[reply]
@Mahagaja: I see, thanks. :) User: The Ice Mage talk to meh 21:27, 26 January 2021 (UTC)[reply]

Latin: stative and inchoative verbs category+usage note edit

There's a systematic relationship in Latin between these two types of verbs, the former almost invariably in -eō, the latter likewise invariably in -scō (some outliers include nōvī~nōscere, and there are pairless ones as well, like puer/llāscō "to attain boy/girlhood"). I've added a usage note to this extent to rubeō, and I think it would be beneficial to have a template that would substitute the same description and add the corresponding pair for both of these. Come to think of it, perhaps we'd need two templates, one for each type - unless we want a global template for many different verb types/aspects/Aktionsarten (such as factitive, iterative, durative, delimitative etc). I suspect there are other languages where this template could come in handy as well - it doesn't need to be Latin-only. Other languages could pair different aspects - Russian currently handles this in the headword, but doesn't explain the difference or precise type when there's more than one pair, as seen here, so could benefit from such a global template as well.

Currently all verbs in -scō seem to be automatically added to Template:cl (I'm guessing this is done by the la-conj template), but there isn't one for stative verbs. While it tentatively appears that every verb in -scō is inchoative, this isn't the case for -eō verbs like mordeō and moveō, and even videō is doubtful - an inchoative formed to it wouldn't make sense at any rate; so a stative category wouldn't simply double Template:cl, and in addition will be able to be applied to verbs of other conjugations. With this in mind, I suppose the stative category should be tied to the usage note, and not the conjugation template; and I also think it makes sense if the template adds the inchoative category too, thus allowing to bypass the conjugation template's autocategorisation.

Now to the practical part: firstly I wonder if anyone doesn't think this is a good idea; and secondly, since I'm programmingly-challenged and have no experience creating wiki templates or categories, I ask that somebody be so kind as to create these for me, or else offer me some guidance in doing that myself. Brutal Russian (talk) 04:14, 27 January 2021 (UTC)[reply]

A template specific for these Latin entries would be a useful addition. It is very simple to make, and requires zero programming knowledge; you can model it after {{U:la:stop+liquid poetic stress alteration}}, for example. A global template is probably a bad idea, as we have very different ways of linking these kinds of forms in different languages, and a one-size-fits-all approach just isn't appropriate. —Μετάknowledgediscuss/deeds 06:56, 27 January 2021 (UTC)[reply]

I attempted to create this but I get a Lua error:

Lua error in Module:category_tree/poscatboiler/data/families at line 167: attempt to concatenate a nil value

Does someone with better knowledge of the Wiktionary Lua code know how to fix this? User: The Ice Mage talk to meh 16:55, 27 January 2021 (UTC)[reply]

I figured it out. At Module:families/data, inc-ins had a line wikidata_item = "",, but if a family isn't in Wikidata, the line should be omitted completely rather than simply having nothing between the quotation marks. —Mahāgaja · talk 19:19, 27 January 2021 (UTC)[reply]
I've edited Module:data consistency check to check all modules for invalid Wikidata items (at least egregiously invalid ones like this), so this will be noticed and corrected more quickly next time. — Eru·tuon 19:57, 27 January 2021 (UTC)[reply]

Creating a redlinks category edit

I created Category:Ottoman Turkish redlinks and Category:Ottoman Turkish redlinks/m over a week ago. They are empty. What ritual do I need to perform to have them populated? Vox Sciurorum (talk) 13:29, 29 January 2021 (UTC)[reply]

The language code needs to be added to the list as {{redlink category}}, which requires an admin or a template editor. First, though, we need to consider whether it's a good idea: the redlink category module has been responsible for a number of "out of memory errors" over the years. That said, all of the entries in the exclusion list (over 300 in all) are in either Latin or Han characters (and ar for Arabic is one of the enabled codes), so I think we're okay. I added it. Chuck Entz (talk) 18:15, 29 January 2021 (UTC)[reply]
It will take quite a while for the system to update, since the template is transcluded in every entry that uses our templates for linking. I went through a few of the entries in Category:English terms derived from Ottoman Turkish to find a couple with redlinked translations and did null edits to confirm that it was working.
I noticed that redlinks in etymologies don't add the category- I'm guessing they bypass the more basic linking functions that call {{redlink category}}. On the one hand, adding the redlink category checking might increase the overall memory load, and etymologies have a rather high percentage of erroneous forms. On the other hand, terms in etymologies tend to have more interest to the general readership than translations in the same languages, since they're more likely to be from historical periods and languages that only specialists study. Chuck Entz (talk) 18:56, 29 January 2021 (UTC)[reply]
I've added Ottoman Turkish to User:Jberkel/lists/wanted/languages so that it will have a wanted entries list linked from User:Jberkel/lists/wanted/latest when the next batch is generated. User:Jberkel's wanted entries lists take from more link templates, including etymology templates, so they have some entries that the redlink categories miss. (See this search for the templates that use {{redlink category}}. Only a few, basically {{l}} and {{m}} and translation templates.) — Eru·tuon 21:37, 29 January 2021 (UTC)[reply]
These have now been generated: User:Jberkel/lists/wanted/20210401/ota. Sorry, list generation was a bit delayed because of memory issues. And apparently we'll have HTML dumps soon, so we'll be able to perform a more global analysis of missing entries. –Jberkel 08:15, 12 April 2021 (UTC)[reply]

How to link to the entry /me? edit

How can I fix the redlink at Appendix:Variations_of_"me"? Equinox 17:56, 29 January 2021 (UTC)[reply]

Using {{l}} instead of a bare link works. I don't know if there's a more elegant solution. —Mahāgaja · talk 20:01, 29 January 2021 (UTC)[reply]
Just use a colon: [[:/me]] produces /me. —Μετάknowledgediscuss/deeds 20:02, 29 January 2021 (UTC)[reply]

Quoting from an app edit

How should we quote from a language-teaching app in a foreign language? In this entry - 이시여 (isiyeo) I didn't use any quote template, I don't like it that way and it doesn't categorise. --Anatoli T. (обсудить/вклад) 11:22, 30 January 2021 (UTC)[reply]

Another rather awkward quotation from a program I've added today is at 折騰折腾 (zhēteng). --Anatoli T. (обсудить/вклад) 00:50, 3 February 2021 (UTC)[reply]
Another templateless quotation I added recently is at 倒轉倒转 (dàozhuǎn). --Anatoli T. (обсудить/вклад) 09:37, 14 February 2021 (UTC)[reply]
A corpus belonging to an app probably isn't durably archived. That, combined with the facts that it's not accessible to searching by the public and that it's artificially constructed in my opinion makes them unattractive for citing purposes. From CFI, [The "conveying meaning" criterion] filters out (...) made-up examples of how a word might be used, which arguably covers all material of this type.__Gamren (talk) 23:24, 29 March 2021 (UTC)[reply]

Spurious newlines edit

A "qualifier" template next to a "ux" template, e.g.:

{{qualifier|UK usage}} {{ux|en|He looks better '''for''' having lost weight.}}

for me, in both Edge and Chrome, produces this:

(UK usage)
He looks better for having lost weight.

Is there any way to suppress the unwanted line break while still using recommended templates? (Of course, I know it can be done by removing the templates.) Mihia (talk) 18:23, 1 February 2021 (UTC)[reply]

Template:ux has a "q" parameter. DTLHS (talk) 18:25, 1 February 2021 (UTC)[reply]
@DTLHS: Aha! Thank you! Mihia (talk) 18:48, 1 February 2021 (UTC)[reply]