Wiktionary:Grease pit/2023/August

@-sche, Hk5183, Abenaki entries are using ô, ȣ, and 8 all for the same character. Can we convert them to ô or ȣ with a bot? --{{victar|talk}} 00:46, 1 August 2023 (UTC)

@-sche, Hk5183, victar We could, but we shouldn't. According to Wikipedia, they belong to different writing systems. --RichardW57m (talk) 13:04, 1 August 2023 (UTC)

Ummm, yep, thanks, that's why we should choose one. Many NA languages have multiple transcription systems. --{{victar|talk}} 15:41, 1 August 2023 (UTC)

No way. We can prioritise one, and treat the others as alternative forms, but we shouldn't collapse them into a single entry. Moreover, what you were proposing would create forms that do not belong in either (or possibly any) orthography. Given the number of Abenaki lemmas we have, it looks like a manual job for someone who understands the writing systems. --RichardW57m (talk) 16:08, 1 August 2023 (UTC)

Woof. @-sche, please take over whatever 🫲 *this* 🫱 is. --{{victar|talk}} 20:11, 1 August 2023 (UTC)

The symbols I've seen the most in modern books and on the web are ô (used by the Nulhegan Abenaki tribe's website, various modern books, and also Laurent's old native dictionary) and 8 (used by the online Western Abenaki Dictionary and the Cowasuck tribe's site); I have not seen ȣ much (and mostly, but not exclusively, in older works). Since 8 is obviously hacky, my instinct would be to standardize on ô (unless you want to make a case for ȣ?), and this indeed seems to be the most-used symbol on Wiktionary, too.
It would be reasonable to let people create "alternative spelling of..." soft-redirects from the other spellings to the main spellings (at least in cases where they are actually attested, like we have some soft redirects for actually-attested non-normalized Norse). And some older works may use spellings that require more normalization than just "replace ȣ with ô". I think those two things are what Richard was pointing out.(?) Fortunately, we seem to only have two entries with ȣ in their titles and ten that use it in their bodies, and none of them seem to require any other changes apart from ô/ȣ/8. I will try to look over the entries which use 8; the 17 which use it in their titles seem like they could be moved with no other issues.
We could also consider systematically invisibly displaying the other orthographies (perhaps in the headwords of the lemmatized entries?) so that searches for those other spellings find the relevant entries, in the manner discussed for Arabic here (Ctrl-F "non-displaying span"). - -sche (discuss) 03:08, 2 August 2023 (UTC)

@-sche: ô is fine with me. There a few handfuls of Abenaki links with 8 and some ȣ that need converting too, which is why some swift bot-action would be nice. --{{victar|talk}} 03:45, 2 August 2023 (UTC)

@victar, -sche: Those were the two things of concern. A third, which I realised later, is that not only would any merely obvious bot action obliterate the existing spelling , it would also falsify the references. Does victar not care about this? I did notice that many entries by -sche lack any backing from references or quotation; one could clean up by eliminating them via {{rfv}}, but I think that would be disruptive and actually leave Wiktionary in a worse state. One would hope that {{rfv}} would induce -sche to supply the references, but it is not something I would want to rely on. --RichardW57 (talk) 08:04, 2 August 2023 (UTC)

@victar, -sche, RichardW57: This was interesting to look into. Chief Sozap Lolô's "Abenakis Alphabet" can be seen here (unexpectedly, ô's upper-case equivalent is not Ô, but O’). Henry Lorne Masta uses 8 throughout his 1932 Abenaki Indian Legends, Grammar and Place Names; his Abenaki Indian Grammar starts here. I also found Fr Sebastian Rasles' post-1691 A Dictionary of the Abnaki Language, in North America, which uses Ȣ and ȣ (including, notably, ȣ̑); see here for John Pickering's analysis of Rasles' orthography (from Memoirs of the American Academy of Arts and Sciences, second series, volume I (1833), pages 370–574). Finally, Philippe Charland says here that "he sign '8' is a vowel sound that…occurs a lot in the language, and is sometimes written as 'ô'". My guess is that 8 is used because it's easier to input than ȣ (or ô, for that matter). 0D foam (talk) 12:04, 2 August 2023 (UTC)

Ah, but one can claim that the upper case is Ô, but it just looks like O’ in appropriate fonts. Seriously, Unicode acknowledges a lot of distortion in the diacritics on upper case letters. --RichardW57m (talk) 16:11, 2 August 2023 (UTC).

@RichardW57m: I think it's more of a character-height issue. Printers of French used to omit diacritics from capitals (or so I'm told) and you'll find some German texts that use ä, ö, ü for the lower case, but Ae, Oe, Ue for the upper case (AE, OE, UE in all-caps), such as this 1882 book. It's a bit of a stretch to invoke Unicode for an orthography devised in 1884! 0DF (talk) 03:27, 23 December 2023 (UTC)

Yes, I am sure that the usage of 8 for ȣ is because, outside of Ivy League schools (and to some extent the church) the Byzantine Greek ȣ ligature was (and is) a character that is rare and is unavailable for printing or typing. I think it may be a good idea to use a bot to default entries to ô, including a softlinked alternative spelling using ȣ or even 8. (I don't believe there are any lemmas using 8 or ȣ with references which would be falsified.) Hk5183 (talk) 23:08, 2 August 2023 (UTC)

Are you talking about font-licensing issues? On recent machines, that open-topped character seems to be reasonably well supported for display in the guise of LATIN CAPITAL/SMALL LETTER OU. For typing on Windows, the owner of the machine may have to agree to the use of Abenaki. --RichardW57m (talk) 09:31, 3 August 2023 (UTC)

I'm going through and updating entries which use the other characters. Only a few have turned out to need other changes besides just to this character. It would probably be a good idea to have an edit filter that tracks (a) the addition of ==Abenaki== L2s to pages with ȣ or 8 in the title (if we could exclude cases where the contents include {{altspell}} / {{altform}} so we don't catch creations of valid soft redirects, all the better), or (b) the addition of new links to Abenaki words (e.g. via {{l|abe}}, {{m|abe}}, or {{t|abe}} or variants thereof) spelled with ȣ or 8.
Some links in other languages such as Loup continue to use ȣ. - -sche (discuss) 01:56, 3 August 2023 (UTC)

@-sche: I was never super-comfortable with the arbitrariness of this decision, so I've come back to it. There would be practical value in using the orthography that would lead to more instances of homography with terms in other Eastern Algonquian languages, since this would allow convenient comparison with probable cognates. Accordingly, I looked into which of those languages use one of or both ô and ȣ. Abenaki uses them for /ɔ̃/; inferring from ȣichiȣam in the translations section of English wigwam and amisȣl (“boat, canoe”) in the etymology section of Munsee amoxool, Loup A uses ȣ for /u/; Massachusett uses ô for /ã/ and ȣ for /uː/; Mi'kmaq uses ô for /o/ and /oː/, though only in its rather defective Pacifique orthography; Mohegan-Pequot uses ô for /ɔ̃ː/~/ɔː/; I'm unsure whether Piscataway uses either "standardly", but I found one instance of ô in the lacunaceous word xowizxawazamô here, but I don't know what sound it represents; and Quiripi uses ô for /ʌ̃/. Now the question is whether the Abenaki phoneme /ɔ̃/ is "cognate" with any of Loup A /u/, Massachusett /ã/ or /uː/, Mi'kmaq /o/ or /oː/, Mohegan-Pequot /ɔ̃ː/~/ɔː/, and Quiripi /ʌ̃/. Do you know the answer, by any chance? 0DF (talk) 03:27, 23 December 2023 (UTC)

I'm not sure I follow you... if you want to use the same symbol as other languages use, we're doing that by using ô, since few other languages use ȣ or hacky 8. As of the last database dump I have, there were no entries in any language using ȣ apart from the entries on the character itself. (The differences are in other letters, like Abenaki kôgw corresponds (and yes, is cognate) to Mohegan kôq.) - -sche (discuss) 00:02, 27 December 2023 (UTC)

@-sche: I wouldn't want to use ô to represent /ɔ̃/ because it's more common (globally or just among the Eastern Algonquian languages); rather, I would want to use the character that Abenaki's cognate languages use to represent their equivalent phoneme. (I don't know if this usage is correct, but I would say that I would want the same grapheme to represent the same Eastern Algonquian diaphoneme in all of that family's languages.) If that's ô, then great! — there's no need to change anything. My issue wasn't with the particular character being used, but rather with the reason (or rather lack of reason) for using it. Does that make sense? 0DF (talk) 01:30, 28 December 2023 (UTC)

@-sche: FWIW, what I've done on some Munsee entries was have the entry at the common spelling, chiikhiikan, the stressed form in {{head|head=chiikhíikan}}, and the alternative (academic) spelling in {{head|tr=či·khí·kan}}. If kept this way, I should probably create a custom {{head}} template to automate it. --{{victar|talk}} 06:11, 3 August 2023 (UTC)

@Quercus solaris. Various entries include a list of "colored boxes", e.g. purple box. This list has been copied manually from entry to entry. I have just created orange box and do not want to copy it everywhere. Could somebody please simplify things with a reusable template? Equinox ◑ 13:02, 1 August 2023 (UTC)

Hi, I have never made a template before, but I should try to learn. Will plan to start. If anyone else beats me to it on this instance (colored boxes), godspeed and thank you. Also I acknowledge here (to all) that Wiktionary doesn't necessarily have to show (as coordinate terms) a contrast set of cardinal notions of colored boxes, but I think it's worthwhile on balance. Thanks all. Quercus solaris (talk) 14:47, 1 August 2023 (UTC)

I was going to suggest moving {{colored boxes}} to the "Template:list:en:" naming scheme, but I notice it's not the only English list template that just has a generic name. My inclination would be to rename all the outliers. BTW Template:en-compass weirdly displays both English and Catalan everywhere it's used. - -sche (discuss) 03:15, 2 August 2023 (UTC)

@-sche I agree that we should rename all the non-conforming templates. All of them appear to be old (created 10+ years ago by User:Visviva, User:Doremítzwr or User:Daniel Carrero, none of whom are active currently). Benwing2 (talk) 23:26, 2 August 2023 (UTC)

@-sche I renamed all the non-conforming templates. I deleted {{en-compass}} in favor of existing {{list:compass points/en}}. Benwing2 (talk) 03:49, 4 August 2023 (UTC)

{{timeline}} and {{en-timeline}} (and probably other timeline templates) are not smart enough to give good displays. Citations:voluntell illustrate the low value of the display at present. The years are not even actually displayed. Subintervals are stacked up in a crude summary of the more useful bold years starting the citations lines themselves. Not good use of graphics. We may as well not have the timeline template at all in such cases.

I don't think a box-and-whiskers plot display is suitable for our citation-date data, at least not for cases with fewer than 10 citations. In addition it may be a bit much for our users. But a smarter template would adjust the width of the display intervals and the first and last intervals to what was actually present. It would also display all the dates. {{en-timeline}} appears on 14,184 pages in Citations space. DCDuring (talk) 16:22, 1 August 2023 (UTC)

I feel like this should be a default feature of citation pages, to be honest... Vininn126 (talk) 16:34, 1 August 2023 (UTC)

It's not worth displaying a timeline in cases where:

1. we don't have all our citations for the definitions being displayed on the citations page OR
2. there are, say, three or fewer citations to be displayed.

DCDuring (talk) 16:39, 1 August 2023 (UTC)

(moved to Wiktionary:Beer parlour/2023/August)

The |time= parameter of Template:quote-av's currently broken; instead of displaying the full time entered, it displays only the seconds portion of said time. Example of this behavior: the quote for verb sense 1 of dodge, where "|time=26:48" but the rendered template shows "48 from the start" instead of "26:48 from the start". Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 08:47, 2 August 2023 (UTC)

@Whoop whoop pull up Should be fixed. Benwing2 (talk) 23:09, 2 August 2023 (UTC)

Thanx! Any idea what begat this bit of borkage? Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 00:11, 3 August 2023 (UTC)

@Whoop whoop pull up It's a bit complicated. I implemented language prefixes in various params such as |title=, where you can now say e.g. |title=ar:عُنْوَان<t:Title> to indicate that the title is in Arabic (and in this case has a translation "Title" in English). This processing is also done on the |section= param, and currently {{quote-av}} sticks the value of |time= into the underlying |section= param. Formerly, the code to parse language prefixes in Module:parse utilities would wrongly (a) include numbers in the pattern checking for prefixes and (b) silently ignore and truncate bad language prefixes (rather than e.g. including them in the text itself). I fixed the code that checks for language prefixes to only recognize things that actually look like language codes (otherwise leaving the prefix untouched), and to throw an error if the language code is unrecognized. Benwing2 (talk) 00:40, 3 August 2023 (UTC)

Ahhhh, that makes sense. Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 00:47, 3 August 2023 (UTC)

Hello, on и#Bulgarian, I went and added ѝ as a homophone, but our current treatment (somewhere in the pipeline) of the diacritic on this letter results in the link getting emboldened, presumably to suggest it's trying to link to и instead. Although ѝ is not a separate letter in Bulgarian, this single word is the only case in which it's distinguished from the no-diacritic version. Where can we change it so that this works as expected? Kiril kovachev (talk・contribs) 19:10, 2 August 2023 (UTC)

Done. 0D foam (talk) 22:01, 2 August 2023 (UTC)

@Kiril kovachev The data in Module:languages/data/2 for Bulgarian (line 250, under entry_name) causes acute and grave accents to be removed from entry names, which is why you're seeing this. It's probably possible to make an exception for the entry ѝ specifically. This stuff has been changed a lot in the last few months by User:Theknightwho, can you answer how hard it is to make an exception for ѝ? Does this require that we have a special entry_name module, or is there a simple setting for it? Benwing2 (talk) 23:14, 2 August 2023 (UTC)

@Benwing2 Very easy - there's a remove_exceptions field designed for precisely this purpose. It is documented, but it's probably easier to just take a look at Serbo-Croatian to see how it works. Theknightwho (talk) 23:39, 2 August 2023 (UTC)

Actually, that being said, it's not possible to exclude individual entries. We might have to do something special for it in that case. Theknightwho (talk) 23:42, 2 August 2023 (UTC)

@Theknightwho Yeah that's what I figured; we'd have to create a special module for this purpose. Benwing2 (talk) 23:43, 2 August 2023 (UTC)

@Benwing2 Actually, I think it could be done with a bit of modification to the logic. remove_exceptions doesn't support patterns at the moment, but ideally we could put "^ѝ$" to exclude only this entry. Theknightwho (talk) 23:48, 2 August 2023 (UTC)

@Benwing2 @Kiril kovachev This was actually very straightforward to do (and was also the impetus for refactoring the remove_exceptions code, which is now a lot more efficient). Links to ѝ (ì) now work as intended, but in any other contexts ѝ will have the diacritic stripped from the link (e.g. ѝѝѝ (ììì)). Theknightwho (talk) 00:24, 3 August 2023 (UTC)

Great, thanks! Benwing2 (talk) 00:58, 3 August 2023 (UTC)

@0D foam @Theknightwho @Benwing2: thanks a lot, this is great. I do want to correct what I said earlier, though, which is that the word "ѝ" itself is distinguished from "и", which means if there's a multiword phrase or something like that which were to feature this word, the link would still be broken. E.g., in книгата ѝ (knigata ì, “her book”), this should link to книгата ѝ and not книгата и. Sorry that I didn't explain that very well originally. Fortunately I think there aren't any such cases in our entries, and I couldn't find any entry like this in the dictionaries, so we should be fine for now. I believe a more suitable pattern (in regex) would be \bѝ\b, the only issue being I don't think Lua supports this. Kiril kovachev (talk・contribs) 10:01, 3 August 2023 (UTC)

@Kiril kovachev Unfortunately Lua doesn’t support regex, but the equivalent would be %fѝ%f. Theknightwho (talk) 13:11, 3 August 2023 (UTC)

@Theknightwho That looks good, would it be possible to substitute that in place of the current pattern? Kiril kovachev (talk・contribs) 13:19, 3 August 2023 (UTC)

@Kiril kovachev Yep - done! Was on my phone when I posted the earlier comment, and it's awkward to edit Lua modules on mobile. Theknightwho (talk) 13:32, 3 August 2023 (UTC)

Thanks, nice one! книгата ѝ (knigata ì) @Theknightwho Kiril kovachev (talk・contribs) 13:34, 3 August 2023 (UTC)

WOTD for 8/3/23; two misspellings. Rigamarole was spelled rigmarole (which is correct in the UK, but not the U.S. as per https://www.oxfordlearnersdictionaries.com/us/definition/english/rigamarole#:~:text=%2F%CB%88r%C9%AA%C9%A1%C9%99m%C9%99r%C9%99%CA%8Al%2F-,%2F%CB%88r%C9%AA%C9%A1%C9%99m%C9%99r%C9%99%CA%8Al%2F,is%20annoying%20and%20seems%20unnecessary), and conman should be con man (in the U.S., as per https://www.merriam-webster.com/dictionary/con%20man).

Thanks! :) Tanscribingmama (talk) 16:08, 3 August 2023 (UTC)

@Tanscribingmama: The Oxford Learners Dictionary entry you linked states that rigmarole is both British and North American, and it's about 3x more common than rigamarole in the New York Times archive. The Merriam-Webster link doesn't say anything about conman, it's less common than con man but looks well-attested too. —Al-Muqanna المقنع (talk) 16:17, 3 August 2023 (UTC)

Thank you for this! Everywhere I've seen it spelled has had it spelled rigamarole. I could've just seen it written strangely of course, but here are a few more sources for everyone to decide on. "Rigamarole." Vocabulary.com Dictionary, Vocabulary.com, https://www.vocabulary.com/dictionary/rigamarole. Accessed 03 Aug. 2023. Interestingly, I found this article which states slightly different definitions depending on spelling, though it says both are correct: https://thecontentauthority.com/blog/rigamarole-vs-rigmarole.

Con man seems more correct simply because you call it a "con." I see documented instances of both as well, but here is Cambridge's answer (which you are correct, simply states both are fine): https://dictionary.cambridge.org/us/dictionary/english/con-man Tanscribingmama (talk) 16:33, 3 August 2023 (UTC)

I distinctly remember that {{{alts}}} used to grab whatever qualifiers were in {{alt}} and print them in {{desc}}, did something change? (An example of a lack of this would be the Belarusian descendent at Reconstruction:Proto-Slavic/slimakъ. Vininn126 (talk) 17:01, 3 August 2023 (UTC)

@Vininn126 Are you sure about this? I rewrote this code last November, but I checked the code from 2020 and it ignored dialect tags (i.e. anything after a double pipe), just like it does now. I can implement this, but how should they display? For ideas, see Template:synonyms/documentation#Dialect tags; {{syn}} etc. supports both overall and term-specific dialect tags, displaying the former after an en-dash (should be an em-dash BTW) and the latter in brackets. Benwing2 (talk) 00:14, 4 August 2023 (UTC)

@Benwing2 I'm just curious why, I suppose. I personally feel it would be useful to have i.e. "Middle Polish" displayed among the forms. Vininn126 (talk) 07:07, 4 August 2023 (UTC)

@Vininn126 Should it display in brackets similar to dialect tags for synonyms? Benwing2 (talk) 07:08, 4 August 2023 (UTC)

@Benwing2 Yeah, I think so. Vininn126 (talk) 07:14, 4 August 2023 (UTC)

@Benwing2: I don't think the brackets look good, nor is it consistent with how we normally format qualifiers, with parentheses, per |q= and |qq=. --{{victar|talk}} 03:52, 5 August 2023 (UTC)

@Victar Blah. The brackets are also what is done with {{syn}} et al.; see the documentation there. I did this because with parens you get two sets of parens when there's translit (as in the case that User:Vininn126 gave), which IMO looks worse than brackets. Benwing2 (talk) 04:03, 5 August 2023 (UTC)

@Benwing2: then put it before, as in |q=. We did it that way for the same reason before {{desc}}. --{{victar|talk}} 04:10, 5 August 2023 (UTC)

I'm going to wait to see if there are other opinions. Benwing2 (talk) 04:13, 5 August 2023 (UTC)

The current approach looks spammy. See Reconstruction:Proto-Kartvelian/ḳerčx- for instance. The dialect tag should be printed once before the terms, I see no point in repeating the tag for each alt. კვარია (talk) 08:19, 5 August 2023 (UTC)

@კვარია Let me see what I can do; I did this because of the way it is combining multiple sets of terms, where the dialect tags apply to only some of them, but I see your point. Benwing2 (talk) 04:27, 7 August 2023 (UTC)

Cool. Also, a small inconsistency: if the first alt's tags/qualifiers don't match that of the main entry, it should be separated with a semicolon rather than a comma. კვარია (talk) 06:37, 7 August 2023 (UTC)

I would not wish for that. --{{victar|talk}} 06:51, 7 August 2023 (UTC)

All commas then? Currently it's not consistent.

main-term COMMA alt-term-list SEMICOLON alt-term-list SEMICOLON ... etc

Though I'm sure nobody actually pays attention to that except for weirdos such as myself. კვარია (talk) 09:12, 7 August 2023 (UTC)

All commas would be my preference, with the qualifier in front. --{{victar|talk}} 15:38, 7 August 2023 (UTC)

@Benwing2, it's been a week. Thoughts? --{{victar|talk}} 18:09, 15 August 2023 (UTC)

@Victar @კვარია Sorry, I started on fixing this and got bogged down by the fact that {{desc}} already supports both overall and per-term dialect tags, with per-term dialect tags displayed before the term as a qualifier, and the overall tags displayed after all terms in brackets. Since I don't think this support is documented, I may just remove it since I suspect it's not used. In any case I will work on this tonight. My plan was to use semicolons as necessary for grouping in cases where you have several terms, some of which have a dialect tag and some don't. IMO there's no way around using semicolons unless you want to tag every term with its associated dialect tags, which I agree is overkill. Benwing2 (talk) 18:22, 15 August 2023 (UTC)

@Benwing2: We've gotten around using brackets and semicolons by putting the qualifier in front, indicating everything beyond it falls under that qualifier, ex. English: term1, (dialectal) term2, term3, (archaic) term4. --{{victar|talk}} 19:01, 15 August 2023 (UTC)

@Benwing2: In the meantime, can we turn it off? Right now, it's super janky, making it harder to read. --{{victar|talk}} 00:25, 17 August 2023 (UTC)

@Victar Yeah I will turn it off. I've gotten at least 50 messages in the last 24 hours and it's a lot of work responding to them all, so I don't always have time to work on fixing stuff like this. I should add though in terms of comma-only, that (a) this is ambiguous, (b) it doesn't work at all if e.g. term4 should not have the dialectal tag but term2 and term3 should. Benwing2 (talk) 02:21, 17 August 2023 (UTC)

Pace victar, I also consider the comma-only requirement problematic. 0DF (talk) 10:46, 17 August 2023 (UTC)

For the record, |alts= never grabbed qualifiers from {{alt}}. While you're there, can you get {{desc}} to also search for the header ====Alternative reconstructions====? --{{victar|talk}} 08:14, 4 August 2023 (UTC)

@Victar Sure, doesn't sound hard. Benwing2 (talk) 19:22, 4 August 2023 (UTC)

@Benwing2: Quick idea independent of the current discussion about what to label "ecclesiastical" pronunciation. It would be nice to be able to manually specify separate pronunciations in {{la-IPA}} for the two versions presented atm. So far I've just used the janky workaround of separate |eccl=no and |classical=no lines, as at -cumque recently. —Al-Muqanna المقنع (talk) 14:53, 4 August 2023 (UTC)

@Al-Muqanna Yup this is a good idea. It's a bit similar to how we can specify separate pronunciations for different Portuguese dialects (esp. Brazilian vs. European). Benwing2 (talk) 19:23, 4 August 2023 (UTC)

The lack of the word "dictionary" apperaring no where in the definition pages causes Wiktionary to rank very low when searched on google and other search engines. See example https://www.google.com/search?q=cat+dictionary. 85.246.37.185 01:37, 6 August 2023 (UTC)

I suggest to change “random entry” in the sidebar to “random dictionary entry”, if this is not too long. Fay Freak (talk) 02:45, 6 August 2023 (UTC)

I think it would be better to add a tag like <meta name="title" content="cat – Wiktionary, the free dictionary"> in the HTML <head> tag. However, doing so requires asking the developers, who are not interested in this project. — SURJECTION ^{/ T / C / L /} 08:13, 6 August 2023 (UTC)

Or alternatively make something like that the new <title> and use JavaScript to replace it with the current format where the title is only followed by - Wiktionary. — SURJECTION ^{/ T / C / L /} 08:17, 6 August 2023 (UTC)

In fact, we can control the page title ourselves without troubling developers, using MediaWiki:Pagetitle. (Moreover, search engines probably don't pick up JavaScript-based page title changes.) @Surjection how about we change it to "$1 - Wiktionary, the free dictionary"?

We could also add the word "dictionary" to MediaWiki:Wikimedia-copyright, which appears in the footer of each page. The prefix "Text is available..." could be altered to "The text of Wiktionary, the free dictionary, is available..."

These very small and unobtrusive SEO tweaks might have a real impact, especially on non-Google search engines. This, that and the other (talk) 11:31, 6 August 2023 (UTC)

I thought of another idea. Wikipedia displays MediaWiki:Tagline for logged out users under the page title. Maybe we could do the same. — SURJECTION ^{/ T / C / L /} 11:57, 6 August 2023 (UTC)

Not an option, it seems - Google indexes the mobile versions of the pages which never displays the text. — SURJECTION ^{/ T / C / L /} 13:50, 6 August 2023 (UTC)

The appropriate message is MediaWiki:Pagetitle. This is the title shown by Google. See w:ca:MediaWiki:Pagetitle after the same discussion on cawiki. Vriullop (talk) 06:15, 7 August 2023 (UTC)

I've changed MediaWiki:Pagetitle to "$1 - Wiktionary, the free dictionary" just to see what happens. Happy to revert it if there are objections. This, that and the other (talk) 00:35, 8 August 2023 (UTC)

Hi, that is better but can you change it to "- Definition from Wiktionary, the free dictionary"? Like how it already is in a div that is not displayed (which has no effect to SEO if i'm not mistaken) <div id="siteSub" class="noprint" style="display:none">. I swear the only reason people are using other online dictionaries instead of Wiktionary is because of Wiktionary's poor ranking, I swear the definitions are better and more expansive in Wiktionary. --ModernDaySlavery (talk) 03:18, 8 August 2023 (UTC)

We shouldn't have "definition from" in the page title. On the contrary, we should remove "definition" from the tagline, which I have now done. — SURJECTION ^{/ T / C / L /} 04:13, 8 August 2023 (UTC)

But the keywords "define" and "definition" is used even more than "dictionary". --ModernDaySlavery (talk) 05:50, 8 August 2023 (UTC)

Agreed. "Define" and/or "definition" should be included somehow. Andrew Sheedy (talk) 02:02, 18 August 2023 (UTC)

Why "$1"? User:CitationsFreak (talk) 04:06, 18 August 2023 (UTC)

@CitationsFreak: That's how MediaWiki does variables in system messages. Without it, the title for this page would be just " - Wiktionary, the free dictionary" instead of "Wiktionary:Grease pit/2023/August - Wiktionary, the free dictionary" Chuck Entz (talk) 04:40, 18 August 2023 (UTC)

Ah. cf (talk) 05:03, 18 August 2023 (UTC)

Maybe we could also add "define" and "definition" somewhere too. I do hundred percent agree that the main reason people not using wiktionary but use dictionary.com, merriamwebster, cambridge dictionary and collins is that wiktionary ranks lower than those in google searches regularly --ModernDaySlavery (talk) 22:12, 6 August 2023 (UTC)

Regardless where we add it we have to add it somewhere, it's the golden rule of SEO if a word doesnt exist in a page it wont be shown in the results, how do we contact the developers User:Surjection? --39.109.192.209 10:53, 6 August 2023 (UTC)

The developers would be contacted through Phabricator. — SURJECTION ^{/ T / C / L /} 14:08, 6 August 2023 (UTC)

Our logo image says "Wiktionary, the free dictionary", so just give it the appropriate alt text, which it should have in any case for accessibility for the blind. Equinox ◑ 13:28, 6 August 2023 (UTC)

Tim Starling, a long standing developer, has stated that the site logo is purely decorative and should not carry alt text. This, that and the other (talk) 00:33, 8 August 2023 (UTC)

Which seems like an ill-advised opinion with respect (or in this case, disrespect) to accessibility. -_-
- -sche (discuss) 01:06, 8 August 2023 (UTC)

I support making changes to this effect, such as the one TTO made to MediaWiki:Pagetitle; IMO it would be good to also have the word appear in the body text somewhere, not just the title. For desktop users, we could also change the "About Wiktionary" link in the footer to "About Wiktionary, the free dictionary" (and maybe update that page: I have gotten feedback from a couple people over the years that when they were looking at a Wiktionary entry, and wanted to find out more about our 'editorial stance' and what we included vs didn't include, that's the link they clicked on). But that text / link doesn't seem to be loaded on mobile. There is, however, a bare "Wiktionary" by itself at the bottom of every mobile page, in between the "Last edited N ago by X" and the "Content is available under..." : could we expand that to say "Wiktionary, the free dictionary" too? - -sche (discuss) 01:06, 8 August 2023 (UTC)

I also support this. We could ask for the WikiSEO extension to be installed, which is designed for exactly this kind of thing. It would enable the {{#seo}} parser function, which would allow us to add a bunch of things to pages. This could probably be done via the headword module in Lua. Theknightwho (talk) 04:40, 8 August 2023 (UTC)

I would support this. What's the process for installing an extension? Ioaxxere (talk) 15:48, 8 August 2023 (UTC)

@Ioaxxere Our best bet is to have a vote on it, and then go to the Phabricator requesting it. WikiSEO does seem to be well-maintained, which makes it more likely we'll get approval.

@Surjection Are you familiar with the process at all? Theknightwho (talk) 20:55, 8 August 2023 (UTC)

@Theknightwho here's the vote. Ioaxxere (talk) 21:12, 9 August 2023 (UTC)

FWIW, this prompted me to search for google:"Wiktionary defines" vs. google:"Merriam-Webster defines" to see how we compare in who cites us and for what: results are here. Probably more informative is that in Google Books' Ngram Viewer, "Wiktionary defines" has climbed to about 1/5th as common as "Merriam-Webster defines", which is not bad; M-W is itself about 1/5th as common as "the OED defines". Having even a bare minimum of SEO now should help, since we do in my experience turn up dead last in searches for "definition of foobar", except when foobar is such an obscure word other dictionaries don't define it. - -sche (discuss) 12:45, 8 August 2023 (UTC)

How about adding "definitions" to the copyright messages on both desktop and mobile? e.g. changing desktop "Text is available..." to "Definitions and other text is available..." and mobile "Content is available" to "Definitions and other content..." — SURJECTION ^{/ T / C / L /} 14:11, 8 August 2023 (UTC)

("Definitions and other text are available!") Equinox ◑ 14:37, 8 August 2023 (UTC)

Should've proofread my own comments... — SURJECTION ^{/ T / C / L /} 14:54, 8 August 2023 (UTC)

Sounds like a fine idea. (I wonder why the desktop version has "Text is available..." while the mobile version has "Content is available..."; just different people writing them at different times?) - -sche (discuss) 15:19, 8 August 2023 (UTC)

If anyone else wants to institute this (as in if another interface admin agrees with this idea), the desktop text is at MediaWiki:Wikimedia-copyright and the mobile one at MediaWiki:Mobile-frontend-copyright. — SURJECTION ^{/ T / C / L /} 18:58, 8 August 2023 (UTC)

(I wonder if those support namespace-specific wording?...) — SURJECTION ^{/ T / C / L /} 19:47, 8 August 2023 (UTC)

Special:Permalink/75586872 (MediaWiki), Special:Permalink/75586716 (last two lines to add to Common.css) appears to work. — SURJECTION ^{/ T / C / L /} 20:40, 8 August 2023 (UTC)

I've added the simple version; if someone else can double-check that the code for the NS-specific version looks good, we could add that. Is MediaWiki:Aboutsite the page that makes the "About Wiktionary" text at the bottom of the (desktop) page in between "Privacy policy" and "Disclaimers"? I'm wondering if it might help to change it to "About Wiktionary, the free dictionary" so that "dictionary" is on every page and not just in the title. Alternatively, We could stick "dictionary" into the copyright notice too, as TTO suggested; that way it be in the body (not just the header) of pages even on the mobile site, which someone said above is the one Google indexes. - -sche (discuss) 22:27, 8 August 2023 (UTC)

It doesn't necessarily have to be in the body of the page if it's already in the page title. — SURJECTION ^{/ T / C / L /} 11:08, 9 August 2023 (UTC)

BTW Wiktionary is even outranked by sites that copy it. See for example https://www.google.com/search?q=%22But+patent+applications+are+increasingly+accompanied+by+volumes+and+volumes+of+data+on+DVD%2C+which+taxes+the+resources+of+the+patent+office%22&sca_esv=555356848&ei=JGnUZOnKGZW5qtsP_6WwgA4&ved=0ahUKEwjp7N-KotGAAxWVnGoFHf8SDOAQ4dUDCBA&uact=5&oq=%22But+patent+applications+are+increasingly+accompanied+by+volumes+and+volumes+of+data+on+DVD%2C+which+taxes+the+resources+of+the+patent+office%22&gs_lp=Egxnd3Mtd2l6LXNlcnAijAEiQnV0IHBhdGVudCBhcHBsaWNhdGlvbnMgYXJlIGluY3JlYXNpbmdseSBhY2NvbXBhbmllZCBieSB2b2x1bWVzIGFuZCB2b2x1bWVzIG9mIGRhdGEgb24gRFZELCB3aGljaCB0YXhlcyB0aGUgcmVzb3VyY2VzIG9mIHRoZSBwYXRlbnQgb2ZmaWNlIkgAUABYAHAAeAGQAQCYAQCgAQCqAQC4AQPIAQD4AQHiAwQYACBB&sclient=gws-wiz-serp with a quote from an IBM blog that is no longer online; Wiktionary ranks 3rd behind two sites that copy it. Benwing2 (talk) 04:38, 10 August 2023 (UTC)

Here is an example where a Wiktionary copy site appears first and Wiktionary doesn't appear at all. Benwing2 (talk) 07:45, 10 August 2023 (UTC)

I see Wiktionary as #2 on the search today. DCDuring (talk) 01:50, 18 August 2023 (UTC)

@Ioaxxere I'm late to the party, and let me know if you'd rather I ask this on the vote page you created. How high should Wiktionary entries rank in search results? I understand the passion and dedication of Wiktionary editors, and I'm trying to be a helpful one myself, but do we have any quality metrics around how good we are, overall? I'm not well-versed in SEO, so I don't know how much of a boost the proposed use of WikiSEO would give us, but if our results were to bubble up next to the Merriam-Websters of the world (to pick an example), would that be a "good thing"? Chernorizets (talk) 06:45, 17 August 2023 (UTC)

There is zero chance of being able to determine exactly where we fall in Google rankings. Given that a large number of Wiktionary English entries are unambiguously better than their M-W counterparts I wouldn't care about it anyway. —Al-Muqanna المقنع (talk) 08:29, 17 August 2023 (UTC)

For what it's worth, our French equivalent, Wiktionnaire, seems to rank pretty high when I look for words and is much more widely used within the French-speaking world than Wiktionary is in the English-speaking world. Their entries are higher quality in some ways, but overall, our quality is pretty comparable. If we ranked higher, we'd also attract more editors, who would help to resolve some of the quality issues. Personally, I find Wiktionary better (clearer layout, no distracting ads, often better definitions) and more comprehensive than any other free online dictionary. Andrew Sheedy (talk) 19:41, 17 August 2023 (UTC)

@Andrew Sheedy I like the idea of higher visibility attracting more editors. Both you and @Al-Muqanna have made statements about Wiktionary's quality compared to other resources available online - I don't have data to disagree, but I also do believe it's fundamentally a data-driven question. I think it would be hugely beneficial to Wiktionary to periodically perform well-scoped, well-defined studies to qualitatively and quantitatively determine how well we're doing compared to professional lexicographers. The Wikipedia article about Wiktionary mentions its use in academia, so some high-level quality indicators might already be available from projects and institutions. Chernorizets (talk) 20:59, 17 August 2023 (UTC)

In my experience the quality of Wiktionnaire's French entries is just on another level relative to our English entries. They have rich collections of usage examples, collocations and quotations for every sense of common words. On the other hand, many of our English entries are languishing in Webster-1913-land and don't have anything beyond a definition, and maybe a dodgy usage example or synonym if you're lucky. Still, some of our more obscure English entries rank highly in Google search results, as do (to take one example) our Latin entries. This, that and the other (talk) 23:13, 17 August 2023 (UTC)

For common words, it’s true, but we are catching up, and English Wiktionary has provided more value all the time because of its seamless coverage of the most fringe registers of a language, even if it has been achieved by dodgy transitions and redundancies of senses: underrated, whereas common words have inherent difficulties and one edits them randomly and slowly in connection with specialized vocabulary, for any great ideas should invite caution of the editor who would desire the big picture, and of the reader who understands that ideal conditions for the bulk of commonplace words cannot be expected to be found in an online dictionary yet.

And even in that we have acutely become better by luring in the internet through accurate coverage of recent internet coinage on which no reliable or reputable source reports. The ordinary has less potential to excite and thus make a dictionary stand out from the crowd, though it is not to be denied from an objective standpoint that for everyday terms it must also be helpful.

It’s also an old schism of taste between dictionarians, deeply rooted in personalities engendering diverse work approaches. Some have a penchant to recover the rareties and by their help perhaps make novel comparison points; others pursue romantic ideas of basic vocabularies, like Swadesh lists, and in them find copious distinction by gradually further digressing into the realm of idioms and subtlety; both efforts are of equal productivity and ultimately connect to each other, Nöldeke’s attestation dictionary for the most sought words and Ullmann’s dictionary of the classical Arabic language as practical complement each other while leaving out about as much, then again the less controlled ones like Wehr and Freytag are indispensable, because no man can have first-hand introspection of a whole culture language’s vocabulary; wrong are only those who are blithely unaware of frequencies and other-than-glossed language description altogether and treat languages as doculects. Ultimately Wiktionary will be better than all because all checks and considerations of a nation of intellectuals, philologic and linguistic and other scientific and artisanal thought collectives, are combined. Meanwhile, English Wiktionary has been most impressive and least ridiculous, although certainly also as a function of the domination of the English language on the internet, in science and in programming, which created a peculiar network effect. On French Wiktionary, I can barely rely that they identify a term as French correctly, rather than say a French transcription, and a hapax legomenon, like trasciner, where they were disinclined to recognize its singular context, without some secondary source evidently supporting them, so they will always stay secondary. Who is on which level? It’s like these two dictionaries levelled their skill-trees varyingly. Fay Freak (talk) 00:44, 18 August 2023 (UTC)

• This link to an archived discussion thread refers to one or two different site indexes which do not seem to be done automatically, but which Google (and others?) uses somehow. Are these being done for en.wikt? DCDuring (talk) 01:46, 18 August 2023 (UTC)

  @DCDuring Probably not, as the lack of indexing is a serious issue. Some of my (comprehensive, well-organized) entries have yet to be shown by Google even months after their creation. After we install the extension, we need to make an inquiry on Phabricator to figure out what's going on. Ioaxxere (talk) 04:38, 18 August 2023 (UTC)

  As might be expected there is some discussion at Phabricator. It even reached a wiki-tech mailing list, which is how I heard. DCDuring (talk) 12:20, 18 August 2023 (UTC)

Can we change it so that the page for this word refers to the actual word, "acquainted"? 185.80.221.235 06:20, 6 August 2023 (UTC)

Wikipedia is irrelevant. This is Wiktionary. Wiktionary is a descriptive dictionary based on usage, so if enough people use it in English in running text to convey meaning, we have an English entry covering it. That makes it a word, as far as Wiktionary is concerned. We may label it as rare, proscribed or nonstandard, but we don't close our eyes and pretend it doesn't exist. Chuck Entz (talk) 06:34, 6 August 2023 (UTC)

I've RfVed it. DCDuring (talk) 14:21, 6 August 2023 (UTC)

Template {{outdent}} and the '' button don't play nicely. Put at its simplest, the code implementing the reply button doesn't understand {{outdent}}, with strange to disruptive effects in long, forked discussions. --RichardW57m (talk) 08:41, 8 August 2023 (UTC)

I'd be nice to get normalizations for quotes in Latf (Fraktur) as Latn (normal Latin script), either by adding a |normsc= parameter or doing so automatically. {{lang}} isn't really an option, because it causes different script classes to be nested, and that cannot be nicely dealt with in CSS when adding fonts. — SURJECTION ^{/ T / C / L /} 15:30, 8 August 2023 (UTC)

@Surjection There is in fact a |normsc= param. It might not yet be supported for {{quote-book}} specifically, but all the other quote-* templates support it. Let me know and I'll get {{quote-book}} to support it. Benwing2 (talk) 07:44, 9 August 2023 (UTC)

Is there a way I can see the meaning of a word without clicking at it? 130.43.71.251 14:40, 9 August 2023 (UTC)

I would imagine there would be a problem with links generating without an ID. If there's a linked ID, it might be possible. Vininn126 (talk) 16:54, 9 August 2023 (UTC)

I suppose the IP is referring to tooltips? Wikipedia seems to have functionality where if you hover over a link, it shows a snippet of the page in question. Anyone know how this works? User:Vininn126 what do you mean without an ID? I imagine the JavaScript code that implements the tooltip could parse the {{m}} or {{l}} call, call full_link() and fetch text from the right section of the resulting page. Benwing2 (talk) 18:40, 9 August 2023 (UTC)

@Benwing2 I'm just wondering what text would be previewed from a link using only ]'s with multiple definitions or even L2's. Vininn126 (talk) 19:16, 9 August 2023 (UTC)

@Vininn126, Benwing2 My ideas—

For a bare link with multiple languages, list the first few languages.

]

box has definitions in English, Czech, and 12 other languages.

Alternatively, treat ] as ] or whatever the first L2 header is and follow the example shown below.

For a bare link with a single language or a link to a language section, list the first few definitions.

{{l|en|box}}

English definitions of box:

1. Senses relating to a three-dimensional object or space.
   1. A cuboid space; a cuboid container, often with a hinged lid.
   2. A cuboid container and its contents; as much as fills such a container. (and 47 other definitions)

Or, use a more sophisticated algorithm that prioritizes covering as many sections as possible.

English definitions of box:

1. A cuboid space; a cuboid container, often with a hinged lid.
2. To place inside a box; to pack in one or more boxes.
3. Any of various evergreen shrubs or trees of genus Buxus, especially common box, European box, or boxwood (Buxus sempervirens) which is often used for making hedges and topiary. (and 47 other definitions)

And with the same idea for linking to sections within an entry.

]

English definitions of box at § Etymology 3:

1. A blow with the fist.
2. To strike with the fists; to punch.
3. To fight against (a person) in a boxing match. (and 1 other definition)

I don't think we need to need to worry about confusion from mixing parts of speech as it should be obvious from the definition.

Ioaxxere (talk) 23:56, 9 August 2023 (UTC)

@Ioaxxere, Vininn126 Yes, this seems solvable. I think a bare link should show only the English section if one exists, since most bare links show up in definitions and are intended for English words. Benwing2 (talk) 00:42, 10 August 2023 (UTC)

Seems reasonable. Vininn126 (talk) 09:39, 10 August 2023 (UTC)

@Benwing2 @Ioaxxere I think we need to be careful in assuming that. While it's probably true in a general sense, there are quite a lot of small languages where most/all of their entries have bare links due to being edited by one person for a few months who didn't really know what they were doing (from a technical perspective). While we should obviously aim to clear them up, many of them have sat like that for years. Theknightwho (talk) 22:02, 15 August 2023 (UTC)

@Theknightwho Most of these will have no English section, and will fall back to displaying all languages. If they do happen to have an English section, they probably have a lot of other languages, too, so showing all languages is unlikely to be helpful. We can try to make this smarter by (for example) assuming that bare links in lists in certain sections (Related terms, Derived terms, etc.) are more likely to be of the language of the section they're in, rather than English; in fact I have a script fix_links.py that I've run various times on various languages that makes more or less exactly these assumptions in order to clean up bare links. But in this case the perfect is clearly the enemy of the good; have you taken a look at the JavaScript gadget linked below by User:-sche (in particular, all 7,285 lines of it)? Benwing2 (talk) 06:03, 16 August 2023 (UTC)

What to do when there is a "Translingual" section? Still show the "English" one? JWBTH (talk) 17:28, 28 August 2023 (UTC)

@Ioaxxere: The first idea feels racist! What have you got against the Welsh? --RichardW57m (talk) 10:26, 10 August 2023 (UTC)

You can turn on MediaWiki:Gadget-popups.js (currently called "navigation popups", historically called "Lupin popups") in your Preferences; it is also what Wikipedia uses. Some other users wrote some code I implemented last year, so it now shows more useful content more often (but for some pages, fails to show anything), but it would be great if someone could either figure out how to make it pull the language and definitions as proposed above consistently, or code a new popup/tooltip to do that. I agree with Benwing that a ] link should show some definitions (whether English-only or more), since we intend for people to use such links in definitions to link to English words. Ideally we should retain the useful functionality that you can currently also hover over a "diff" link in e.g. your watchlist and see the changes. - -sche (discuss) 11:30, 10 August 2023 (UTC)

Currently, roots are categorised as lemmas in all Semitic languages, which is completely false. I understand that in some languages (like Proto-Indo-European) words are lemmatised at the root, but that shouldn't be the general behaviour. Is it possible to modify the infrastructure to handle roots as lemma or non-lemma depending on the language? @Benwing2, Theknightwho — Fenakhay ^{(حيطي · مساهماتي)} 16:33, 9 August 2023 (UTC)

Does it really make sense to group roots in with inflections? It might be worth splitting the category called "non-lemmas" up, which may address some of the other issues we've had with (e.g.) alternative forms. Theknightwho (talk) 17:30, 9 August 2023 (UTC)

@Benwing2, Theknightwho, Fenakhay, Fay Freak: In general, referring a root to a single lemma will not be adequate, and it generally makes sense to see the root as more basic than the word-level lemma. (Not all word-level citation forms are words, though.) --RichardW57m (talk) 09:32, 10 August 2023 (UTC)

I needed to think a few minutes why Fenakhay reckons it wrong: Apparently it is because the “roots” aren’t the citation forms of anything. While e.g. in Sanskrit they they apparently are. This may exemplify another layer of polysemy of the linguistic term of a “root”—we use it in POS headers in two meanings thus. Fay Freak (talk) 18:27, 9 August 2023 (UTC)

Yeah either splitting "root" into two terms (although I don't know what it'd be called) or (more radically) splitting non-lemmas is possible (although again I don't know what the resulting groups would be). Benwing2 (talk) 18:29, 9 August 2023 (UTC)

I think you'll find it's the Sanskrit verbs which show a tendency to lemmatise at the root, with a competing tendency to lemmatise at a 3s of the present tense. At Wiktionary, the Sanskrit present tense forms seem to have more senses than the Sanskrit roots. The problem is that there may be multiple stems for the present tense, with a potential for different stems to have different meanings. That sort of thing has been called out for Classical Greek perfect tenses (ablaut v. -ka). That sort of split has even been claimed for English past tenses with alternative forms in -t and -ed. Calling on the Sanskrit editors for comments - (Notifying AryamanA, Bhagadatta, Svartava, JohnC5, Kutchkutch, Inqilābī, Getsnoopy, Rishabhbhat): . With Sanskrit, not all finite verb forms are made from a present stem, increasing the tendency to refer meanings to the root rather than present tense citation form.

I'm not sure that there is a systematic difference between the types of verbal roots - it's more what groups of editors have chosen to do, probably largely based on the dictionaries they're copying. --RichardW57m (talk) 10:18, 10 August 2023 (UTC)

What are these? The terms turn up in inline documentation of form-of modules. Where should I have found the definitions? My first thought is that invocation params are ones that are supplied when invoking a template and that the 'template params' are the ones in the module invocation that define the functionality of one template as opposed to another, but the descriptions then don't make sense. Pinging @Rua, Benwing2, Erutuon, Theknightwho as the likeliest to know or supply good mnemonics. It might be the other way round, as there are warning messages around that a page needs an inflection template, when what it usually needs is the invocation of a pre-existing inflection template. --RichardW57m (talk) 14:46, 11 August 2023 (UTC)

@RichardW57 Where is this mentioned exactly? I'll clean this up. "Invocation params" are the params passed in when you call {{#invoke:...}} and "template params" are the params of the template whose definition involves calling {{#invoke:...}}. Invocation params are retrieved using frame.args and template params are retrieved using frame:getParent().args. Benwing2 (talk) 21:58, 11 August 2023 (UTC)

Thank you. The terms are found in Module:form_of/templates. --RichardW57 (talk) 08:37, 12 August 2023 (UTC)

Is there a good way of setting up a permanent test of a template intended to perform categorisation, e.g. in a 'testcases' module file? The problem I see is that some categorisation templates seem only to work when invoked from a page in main space. An typical example would be invoking {{causative of}}. --RichardW57m (talk) 14:54, 11 August 2023 (UTC)

@RichardW57 Many modules have a force_cat setting at the top of the module for this purpose; set it to true (without saving the module) and preview the testcases page. Module:form of has this, right at the top of the module. (The template editor protection on the module might be an issue; let me know if this is the case.) Alternatively, sometimes the template itself has a |force_cat= param; the advantage of this is you don't have to do the module editing business, but the disadvantage is you need to add |force_cat=1 to every template in your testcases page. It doesn't look like the form-of templates have this method set up. Benwing2 (talk) 22:05, 11 August 2023 (UTC)

it seems that the Minerva skin (default mobile skin) ignores most of the CSS formatting and just puts the examples above the definitions, as if they were definitions themselves. it also adds a header that doesnt close, so if anything it looks like the definitions are part of the examples section. not the biggest issue to worry about right now, since it still is perfectly legible and all that, but i wonder if it could at least have a box around it so it stands out from the definitions more. Thanks, —Soap— 17:10, 11 August 2023 (UTC)

@This, that and the other Wonder if you can help? This template adds a toccolours CSS class but I don't see it referenced in MediaWiki:Common.css. Maybe the box is coming from the -moz-box-sizing: content-box; inline setting; is there a mobile (or non-Mozilla) equivalent of this? Benwing2 (talk) 22:10, 11 August 2023 (UTC)

Styling templates should better be done using mw:Extension:TemplateStyles, see the manual. MediaWiki:Common.css is extraordinarily large (and all of that is loaded to every visitor), 5 times larger than w:MediaWiki:Common.css. A lot of that could be moved to per-template stylesheets.
You could easily add rules for small screens there as well, e.g. with a rule

@media (max-width: 36em) {
	/* rules */
}

(I have been working at styles for {{uxi}} on mobiles, will post soon.) JWBTH (talk) 03:58, 12 August 2023 (UTC)

This wiki seems to have had a real shortage of users with frontend CSS skills, which is part of the reason why our Common.css languishes in such a state and mobile view is missing so much formatting...

In this case, however, there is little motivation for mucking around with TemplateStyles, since the template will as a rule appear no more than once on per page. I'll try and fix the formatting on mobile using inline styles. This, that and the other (talk) 11:57, 12 August 2023 (UTC)

Need to do something with {{wikipedia}} too, see the screenshot. You can also see the effect of bigger image margins at https://en.m.wiktionary.orghttps://dictious.com/en/proper_noun. The reason is the default browser style for <figure> (these tags have become used for images in MediaWiki a month ago). JWBTH (talk) 03:44, 12 August 2023 (UTC)

I fixed it to be slightly less terrible. But the "proper noun" entry is a great showcase for all that is wrong with our mobile site styling. The font sizes and box paddings are all over the shop. Plus, on a larger device (e.g. tablet), having all the elements in sequence, rather than floating to the side like they do on desktop, really kills the flow of the page. This, that and the other (talk) 13:31, 12 August 2023 (UTC)

@This, that and the other Thanks! Yeah I really don't know shit about CSS and I think that's the case with a lot of the tech people here; I have always been a backend coder. Benwing2 (talk) 21:07, 12 August 2023 (UTC)

Many pages for our languages use trees, such as Proto-Indo-European, to show the family origin. However, I can't collapse individual branches. This is a pain if I just wanna look like a single branch or two, like the Germanic and Italic branches only for PIE. I think we should have the collapse button for every single element in all the language trees. cf (talk) 03:32, 13 August 2023 (UTC)

The LDL language Nyunga has a handful of templates intended for use inside the "References" section, but they're all named "RQ:" instead of "R:". Is it better to rename them to "R:" or "R:nys:"? JeffDoozan (talk) 14:18, 13 August 2023 (UTC)

They may have been intended as a source for quotations, in which case keep 'RQ:'. To make the judgement, one needs to look at the book. If you can't access the book, stick with what we have - winding up with a chain of redirects is bad. --RichardW57m (talk) 12:50, 14 August 2023 (UTC)

@JeffDoozan Contrary to Richard they do appear to be References templates, not quotation templates, in which case they should begin with R:nys:. Benwing2 (talk) 21:01, 14 August 2023 (UTC)

If you look at 鸭绿, you'll see "For pronunciation and definitions of 鸭绿 – see 鴨綠 (“Yalu

I don't think {{zh-see}} supports {{place}}. — Fenakhay ^{(حيطي · مساهماتي)} 16:31, 13 August 2023 (UTC)

Not solved --Geographyinitiative (talk) 00:26, 21 August 2023 (UTC)

All I can say is that if this shows up in just a few cases, it might be best to manually enter the meanings. Right now there is an argument 3= that can be passed to the template, so typing 3=Yalu River would solve the problem for this one page. —Soap— 14:18, 8 September 2023 (UTC)

@Soap, Geographyinitiative The problem here is that there are a zillion things to fix and they seem to all fall on me. Please add this to User:Benwing2/todo but I can't guarantee when I'll get to it; at least having it documented means either I or someone else will eventually do it. Benwing2 (talk) 21:43, 8 September 2023 (UTC)

@Benwing2, Soap, Geographyinitiative: Fixed. Module:zh/extract was splitting parameters of {{place}} on |, which split the link ] (in the most recent version of the entry 鴨綠, after this thread was posted) in half, so I made it use Module:templateparser to properly parse the template together with embedded links. — Eru·tuon 04:02, 9 September 2023 (UTC)

@Erutuon Thank you! Benwing2 (talk) 04:28, 9 September 2023 (UTC)

In ό,τι κι αν (ó,ti ki an) the template “alternative form of” is broken. This entry is supposed to be an alternative form of ό,τι και να (ó,ti kai na), but due to the comma, the phrase is split into two parts *ό (ó) and *τι και να (ti kai na). OosakaNoOusama (talk) 04:44, 14 August 2023 (UTC)

@OosakaNoOusama: I found a workaround, but there should be a more straightforward way to get it to ignore the comma. Chuck Entz (talk) 05:33, 14 August 2023 (UTC)

@Chuck Entz The comma is ignored if there's a space following it. This is a strange term without a following space. @OosakaNoOusama Is it common to have Modern Greek terms with embedded commas without a following space? Benwing2 (talk) 07:39, 14 August 2023 (UTC)

As far as I can tell, the comma without a space is only used in the term ό,τι (ó,ti), where the comma is supposed to represent the hypodiastole. I have not yet discovered any other such terms. OosakaNoOusama (talk) 07:50, 14 August 2023 (UTC)

@Benwing2: Whatever, there is a lot of broken documentation. Or are editors expected to read and understand the source code of Module:links? --10:06, 14 August 2023 (UTC) RichardW57m (talk) 10:06, 14 August 2023 (UTC)

@RichardW57 Please no snark here. We are doing the best we can, there is a lot to document. The code that handles the comma here and allows for multiple lemmas (and inline modifiers) is actually in Module:form of/templates. I documented this in Template:inflection of/documentation#Multiple lemmas and inline modifiers but it needs to be added to the general form-of documentation in Module:form of doc so it shows for all form-of templates. Benwing2 (talk) 21:27, 14 August 2023 (UTC)

How should one display the language of a quotation supporting a translingual sense? For example, I am minded to add some Thai quotes to support senses for the comma, so I would most likely use {{quote-book}} plus {{th-usex}}, but how does one state to the reader that the language was Thai as opposed to Pali or Northern Khmer? --RichardW57m (talk) 10:52, 14 August 2023 (UTC)

@RichardW57 I don't quite understand your question. The quote-* templates support three different concepts of language: The language(s) of the quote itself (specified using |1= and can be a comma-separated list), the language(s) of the work the quote is within (specified using |worklang= and can be a comma-separated list) and the language of the term being illustrated (specified using |termlang= and should be a single language). Generally you only use the latter two if they differ from |1=. Benwing2 (talk) 19:49, 14 August 2023 (UTC)

@Benwing2: As far as I am aware, |1= and |termlang= don't display, and the latter would be 'Translingual' anyway. Now, in this case, |worklang=th would half work because I would probably take the Thai quote from a work in Thai, but I want to say that the quotation is in Thai. It would work by the reader misinterpreting the display! It wouldn't work for a Pali quotation from a work in Thai showing a translingual term, such as exhibiting a sentence-terminating full stop in Thai-script Pali, or a sentence-terminating comma in (Tai) Tham script Pali in a work in pre-reform Lao-script Lao. Perhaps @Al-Muqanna has some thoughts on what he would hope to see once the moratorium on editing such pages is lifted. --RichardW57 (talk) 21:12, 14 August 2023 (UTC)

@RichardW57 Once again I have no idea what you're saying. Can you rephrase it with an example, and state what your desired outcome is? The algorithm for handling |worklang= and |termlang= is as follows:

1. If |worklang= is given, display "(in WORKLANG)".
2. Otherwise, if |termlang= is given and is different from |1=, display "(in LANG)" using the LANG of |1= (the quotation language).
3. Otherwise display nothing.

There's a comment that gives the example text "(in German; quote in Nauruan)", which suggests that the intention in case all three are different is to display both the work lang and quote lang. That doesn't currently happen but I can fix this if that will help you. Benwing2 (talk) 21:20, 14 August 2023 (UTC)

As for the moratorium, you're referring to single-character entries? I had hoped the issues would be resolved by now. What is the current state? I know the issue is mainly between you and Kwami, and Kwami said awhile back he had some real-life issues to deal with and might be away from editing for a little while, but I don't know where things currently stand. Benwing2 (talk) 21:23, 14 August 2023 (UTC)

@Kwamikagami Benwing2 (talk) 21:23, 14 August 2023 (UTC)

I'm all for adding attestation and usage to translingual entries. My reason for RfD was because many entries contained no information apart from the Unicode def, which could easily be wrong or misleading if we do not have confirmation. In many cases, I would search for info, including from the docs submitted to Unicode to justify the character, and if I couldn't find a language that used it, to be able to create a functional definition myself, I would RfD because we were pretending we had an article when effectively we didn't. In some cases Richard was able to provide attestation for the character, which was great.

My problem with many of Richard's edits was what I took to be a Fascist promotion of certain languages (mostly Burmese, but also potentially Thai) over others, because the Burmese Army can shoot people in the head, which makes Burmese superior to other languages. If he claims that the translingual pronunciation is Burmese (or Thai), or similarly narrows any other aspect down to usage by a particular language -- that is, if he claims that Burmese, Thai etc. are "translingual" rather than Burmese or Thai, then I would argue that his addition is prejudicial and should be moved to a Burmese or Thai section.

I rather doubt Richard intends to create Burmese and Thai sections for the usage of letters or symbols in those languages, as he still seems to be pushing for Burmese domination. But if he really is willing to add translingual attestation to a translingual section, then I have no objection to him doing so. kwami (talk) 22:00, 14 August 2023 (UTC)

@Kwamikagami: You still seem not to understand that with one exception I was simply reverting impermissible deletions; I confess I restricted myself to restoring defensible entries. The exception was when I started to tackle the misleading implication that Burmese pronunciations not clearly labelled as such were representative of the whole range of use, and realised that our labelling policy did not work for pronunciation differences by language rather than geographical area. Look at the history to see who added Burmese pronunciations to translingual letters.

The relevant feature of the Burmese army was that they regularly defeated other armies, even if it was concluded that it was cheaper to pay tribute to the Chinese than to slaughter their forces. Thus, foreigners ended up dealing with the Burmese, and Mon reportedly (a Mon admission) became inadequate for talking about politics. --RichardW57m (talk) 12:35, 15 August 2023 (UTC)

@Kwamikagami I tend to give the benefit of the doubt when it comes to accusations of racism. In this case unfortunately I don't understand the essence of what Richard is saying, or why who paid tribute to who has anything to do with creating a dictionary. In any case I disagree that the Unicode definition of a given character is irrelevant or useless information and that we should delete characters whose only definition is based on Unicode. I'm pretty sure this view is the consensus. Benwing2 (talk) 00:37, 16 August 2023 (UTC)

The history is why, if we ignore the Unicode catalogue of characters, descriptions of the Burmese alphabet provide reasonable definitions of the Burmese script characters that are in the Burmese alphabet. (I'm not sure though that the proposition that ဉ and ည are different letters of the Burmese alphabet is accepted widely enough to use.) --RichardW57 (talk) 07:47, 16 August 2023 (UTC)

@Benwing2: We're currently waiting for me to beef up the text for อ‍ย so that we can pipe clean the use of {{rfm}} to change the language from translingual, which should properly be raised by @Kwamikagami - unless he's happy that it is translingual. There is a high risk that only @Octahedron80, Noktonissian and I have the relevant books for the letter; possibly only I have them. The only usage I have evidence for it shows it being used in what may be seen as a transliteration (as opposed to transcription) of Tai Tham Northern Thai into the Thai script in books whose language is Siamese. Being a ligature, rather than a single character, it is not subject to the moratorium. In particular, I need to work out/remember how to make usable and lawful images of the letter's various glyphs. (Printing in black and transparent as opposed to black and white is not as easy as one might think.) --RichardW57m (talk) 12:06, 15 August 2023 (UTC)

A mock-up of a simple 3-language case is

{{quote-book|th|termlang=mul|title=Rhubarb|worklang=fr|year=2023}}

{{th-x|หมา , แมว|dog, cat}}

yielding

2023, Rhubarb (quotation in Thai; overall work in French):

หมา, แมว

mǎa , · mɛɛo

dog, cat

I don't entirely trust {{th-x}} to embolden the comma when on the page, but emboldening punctuation is unreliable anyway. Now, if I omit |worklang=fr, I get

2023, Rhubarb (in Thai):

หมา, แมว

mǎa , · mɛɛo

dog, cat

The only problem with this is that it claims that the language of the cited work is Thai.

I was actually expecting an answer such as, "Just stick emboldened 'Thai: ' in front of the quotation, yielding for example:

2023, Rhubarb (quotation in Thai; overall work in French):

Thai: หมา, แมว

mǎa , · mɛɛo

dog, cat

This is, after all, rather an unusual case. --RichardW57m (talk) 11:38, 15 August 2023 (UTC)

I think the work language should always be displayed if given explicitly.

If the quote language (|1=) differs from the term language (|1=), I think the quote language should also be given.

There may be different considerations if the term language is not the language of the language section - the documentation of |brackets= suggests that this may be possible in some esoteric cases. I think the logic would be easier if we knew the language of the language section. RichardW57m (talk) 13:05, 15 August 2023 (UTC)

@RichardW57 All right. As usual I have difficulties making sense of what you've said (you're almost as impenetrable as Fay Freak) but I think you're asking for both the quote language and work language to be displayed explicitly if they are different from each other and the term language, which I can implement. Benwing2 (talk) 20:50, 16 August 2023 (UTC)

I'll restate the corrected garbled first sentence - "If the quote language (|1=) differs from the term language (|termlang=), I think the quote language should also be displayed."

I think the quote language should be displayed if different from the term language.

In your understanding, do work language and term language always exist, or do they only exist if respectively parameters |worklang= and |termlang= are supplied? I think I need to draw up a logic table (@RichardW57). The user will normally expect the term language to be the language of the language section, but this expectation may be wrong for bracketed 'quotations'. --RichardW57m (talk) 09:17, 17 August 2023 (UTC)

@RichardW57m: See what I've done with the German and Latin quotations supporting Ancient Greek terms at Citations:Φρεαττώ. Is that the kind of solution you're looking for? 0DF (talk) 10:47, 17 August 2023 (UTC)

{re|0DF}} These do argue that one doesn't need to display the quote language separately from the work language if they're the same. A better example along these lines would be a Latin statement about a Greek word inside a German book. --11:53, 17 August 2023 (UTC)

Incidentally, I think you should have |brackets=on for these quotations, because they're mentions, not uses. RichardW57m (talk) 11:53, 17 August 2023 (UTC)

@RichardW57m: Done. Could you explain why the |worklang= matters, please? I'm not seeing the point of it. 0DF (talk) 12:06, 18 August 2023 (UTC)

Generally it's of secondary importance; it is a relatively recent addition. I see it as a guide to the reader of the difficulty of navigating the work and understanding the context. For example, I found what at first looked like some mentions of weird Tai Tham-script Pali spellings in a Thai-language book on Northern Thai. I had to study the text hard to decide that they were probably borrowed terms rather than actual Pali. If I had accepted them as Pali, someone who can't read Thai at all shouldn't even bother to try to verify that I had interpreted the text correctly. The book seems to be out-of-print, so getting hold of a copy may be hard. (It seemed widely available 15 years ago - I even saw it on sale at a service station.) Note that an inscription is a valid quotation for CFI even if verification requires someone to visit it in order to verify it. --RichardW57m (talk) 13:04, 18 August 2023 (UTC)

@RichardW57m: OK, yeah; that makes sense. 0DF (talk) 23:38, 18 August 2023 (UTC)

@RichardW57 I'm not sure what you mean by "do they always exist". There is always a work language (i.e. the work is always in some language), which is assumed to be the same as the quote language in |1= if not specified; same for the term language. Benwing2 (talk) 18:34, 17 August 2023 (UTC)

@Benwing2: One might distinguish between having |worklang= specified and not having it specified. The same goes for |termlang=. Your answer means that presence and absence of the parameter are not distinguished, but rather that the code works with 'resolved' values. I will draw up the table with that in mind. --RichardW57m (talk) 09:47, 18 August 2023 (UTC)

@RichardW57 I changed the algorithm for handling |worklang= and |termlang=. See the bottom of User:Benwing2/test-quote for some examples and let me know what you think. Benwing2 (talk) 05:48, 19 August 2023 (UTC)

@Benwing2: A quibble: Such cases should show "quotation in ", rather than "quote in ", IMO. 0DF (talk) 12:03, 19 August 2023 (UTC)

@Benwing2: They work. --RichardW57 (talk) 20:34, 19 August 2023 (UTC)

I've finally put a logic table together, at User:RichardW57/quote-lang. The examples have highlighted an issue with what may be legacy templates from before the advent of |worklang=. There are English-language works being quoted from which need to be tagged as such. It's a shame the quotations will then look worse. --RichardW57 (talk) 20:34, 19 August 2023 (UTC)

I haven't addressed what should be done when |termlang= is not the language addressed by the language section. --RichardW57 (talk) 20:34, 19 August 2023 (UTC)

The Wikifunctions project has recently gone live.

Wikifunctions is a Wikimedia project for everyone to collaboratively create and maintain a library of code functions to support the Wikimedia projects and beyond, in the world's natural and programming languages.
A "function" is a sequence of programming instructions that makes a calculation based on data you provide. Functions can answer questions, such as how many days have passed between two dates, or the distance between two cities.

Is there any possible application for these functions on Wiktionary? Ioaxxere (talk) 03:57, 15 August 2023 (UTC)

It sounds like what we are currently achieving using modules like “Module:string” and “Module:roman numerals”. — Sgconlaw (talk) 05:55, 15 August 2023 (UTC)

@Ioaxxere @Sgconlaw The purview of such a project is extremely broad, and as a result who knows what it will end up amounting to. As Sgconlaw points out, we already have modules to do lots of things, and a lot of the modules we have or need are fairly specialized to Wiktionary so won't be found in Wikifunctions (for example, we could definitely do with a generic headword-processing module; it's something I've thought of writing at various points). I think the only possible benefit is if you're looking for an implementation of some well-known algorithm like Levenshtein distance; in most such cases, however, you can already find implementations in Wikipedia or Stack Overflow, and if not, I wouldn't necessarily trust Wikifunctions to have high-quality code. Benwing2 (talk) 20:05, 15 August 2023 (UTC)

That's broadly where I stand as well. We need to generalise where it makes sense for us to generalise, but still tailor things for Wiktionary's specialist needs wherever possible. Theknightwho (talk) 21:57, 15 August 2023 (UTC)

@Theknightwho, Benwing2, J3133 and anyone else who knows: Why does {{auto cat}} work on Category:Places in the Roman Empire and its language-specific subcats but not on Category:Cities in the Roman Empire and its subcats? —Mahāgaja · talk 08:33, 15 August 2023 (UTC)

I'm not them, but the answer can seemingly be found in point 2 under the "Polities" heading at Module:place/shared-data:

former states such as Persia, East Germany, the Soviet Union and the Roman Empire should have their cities, towns, rivers and such listed under the current entities occupying the same area.

But this makes me wonder why we have these former-place cats in the first place. What is meant to be in them? This, that and the other (talk) 11:20, 15 August 2023 (UTC)

@Mahagaja@This, that and the other The problem here is we don't have a clear policy about how to handle such situations. For example, Moscow is a "city in the Soviet Union" but I don't think classifying it this way is helpful. We could potentially classify a city like Stalingrad that existed only in the Soviet Union as such but I think it's better to define it as a former name of Volgograd, and put it as a city in Russia. When creating such a policy, we have several cases to consider:

1. Larger entities like provinces don't make sense outside their particular polity, so should be classified e.g. in CAT:Provinces of the Roman Empire.
2. For cities and towns, there are at least three cases: (1) Cities in recently extinct entities (East Germany, Czechoslovakia, the Soviet Union, etc.) which generally have continuity with modern cities, but possibly different names. (2) Cities in ancient entities, where the city still exists (e.g. Rome, London, Antioch); arguably there is continuity with the modern entity but sometimes it is fuzzy. (3) Cities in ancient entities that no longer exist. I'm not quite sure what the best policy is for each case, but note that we have Category:Historical settlements, which is defined as "names of cities, towns and villages that no longer exist or have been merged or reclassified". This is perhaps sufficient for (3) and for the cases under (2) that don't have historical continuity. Note that if you use <<former city>>, <<ancient city>>, <<historical city>> or the like, you get classification into Category:Historical settlements automatically.
3. Rivers in ancient polities generally still exist, possibly with different names, so should be treated as case (2) above for cities and towns. The only tricky case is where the ancient definition of a river covers a different stretch of water than the modern definition, but I don't think this warrants a category like Category:Rivers in the Roman Empire.

Note that this still doesn't answer the question of why there's a category Category:Places in the Roman Empire that contains cities (cf. Italian Costantinopoli, which is defined using <<historical capital>> and gets classified automatically into Category:it:Historical capitals, Category:it:Historical settlements and Category:it:Places in the Roman Empire. Probably this shouldn't happen, and it's even more dicey with a category like Category:Places in Czechoslovakia (which contains only two terms, English Prague and Pardubický kraj, both of which still exist with the same name in the modern Czech Republic). Benwing2 (talk) 23:28, 15 August 2023 (UTC)

The Roman Empire categories (except provinces) are I think not obviously helpful and probably should not exist. My understanding has been that places should be categorised into the present-day country, and settlements that no longer exist should likewise be categorised into the present-day country but marked as historical settlements. There are in any case, for example, only 7 entries in Category:la:Places in the Roman Empire (compare 258 in Category:la:Places in Italy alone). That was my understanding from existing practice, and I've not felt it to be unclear until this came up. With regard to provinces, I agree those pertain to polity and need to be treated accordingly. —Al-Muqanna المقنع (talk) 23:58, 15 August 2023 (UTC)

@Al-Muqanna Yeah I agree with you and I think I'm making it more complex that it needs to be; what you're describing is indeed the existing practice that I codified into Module:place except for the Category:Places in FORMER POLITY, which I agree should not exist. Benwing2 (talk) 00:06, 16 August 2023 (UTC)

Hmm - I’m not sure I fully agree with the idea that historical settlements should be categorised by the modern country. It feels much more natural to say that Londinium and Aquae Sulis were historical settlements in Britannia than it does to say they’re historical settlements in the United Kingdom, for example. The continuity between modern cities and their ancient counterparts is often very loose, to the point where they have really quite distinct identities. This particularly applies when historical records became very sparse for hundreds of years, as they did in Britain. Theknightwho (talk) 01:20, 16 August 2023 (UTC)

@Theknightwho They are not categorized as "historical settlements in the United Kingdom" (or "... England") but merely as Category:Historical settlements. Currently whether they end up as Category:Places in the Roman Empire or Category:Places in England depends on the definition using {{place}}. You're touching on case #2 above for historical settlements, where sometimes the continuity is questionable, but I would argue that Londinium is still a place in England, because that's where it's physically located. Benwing2 (talk) 01:34, 16 August 2023 (UTC)

Like Königsberg is a place in Russia? Also, Londinium is or Londinium was? --RichardW57 (talk) 07:58, 16 August 2023 (UTC)

My usual practice has been to write both in the entry itself, but the categorisation should follow the modern country—otherwise it would quickly become very tedious to use. (I don't remember one I did off the top of my head, but it's the same sort of thing as at Complutum.) Also in practice you would probably put historical settlement in modern England, which seems fairly natural to me, not just the UK: see Category:la:Cities in England. —Al-Muqanna المقنع (talk) 08:20, 16 August 2023 (UTC)

Usefulness of categorisation may vary by language. I'm sure it would be more useful to categorise Alcalá de Henares in CAT:es:Places in Spain, but I'm also sure that it would be more useful to categorise Complūtum in CAT:la:Places in the Roman Empire. 0DF (talk) 12:22, 16 August 2023 (UTC)

Er, why would it be more useful to put it in different categories per language? Bear in mind, too, that Latin place names for settlements continued to be used in Medieval Latin and New Latin. Then we have cities like Dura-Europus that changed hands regularly between various polities, including the Roman Empire, in ancient times—categorising as a place in Syria makes sense, as a place in the Roman Empire, not so much. Categorising such names separately and pedantically into every polity their referents were ever part of would be completely pointless, and if I want to know, say, Latin names for places in Spain or Italy, all of them being dumped into a Roman Empire category would also be totally unhelpful. The existing system works well. —Al-Muqanna المقنع (talk) 12:52, 16 August 2023 (UTC)

Yes, I'm inclined to agree (although I still think there's a certain difference between modern cases like Königsberg/Kaliningrad and ancient cases like Complutum/Alcalá de Henares). The alternative, for example, would be to try and categorize Königsberg as a place in "Germany" when the "Germany" that it was a part of no longer exists and a different Germany now has the same name. We could potentially add a category such as Category:de:Former names of settlements for former names; maybe that would help. Benwing2 (talk) 20:47, 16 August 2023 (UTC)

@Al-Muqanna, Benwing2: Why not categorise both ways? And if "Places in the Roman Empire" is too broad (yeah, probably), why not also CAT:la:Places in the Hispania Tarraconensis? As for Königsberg, what about Category:de:Places in Prussia? 0DF (talk) 00:07, 17 August 2023 (UTC)

We're a dictionary, not a historical gazetteer. I'm not convinced that this kind of detailed historical categorisation is of any lexicographical benefit. This, that and the other (talk) 00:27, 17 August 2023 (UTC)

@0DF, This, that and the other: Königsberg would also belong in cat:Places in Prussia. The advantage of detailed historical categorisation lies in the hope that it will include the categorisations of interest. The disadvantage is the burden imposed by shifting borders. --RichardW57m (talk) 09:53, 17 August 2023 (UTC)

@This, that and the other: What is the intended lexicographical benefit of any of these "Places in " categories? @RichardW57m: And I'd think that any problems with proliferating categorisation would be pretty minimal, given that the category names are all at the bottom of pages. 0DF (talk) 10:52, 17 August 2023 (UTC)

The problems are not minimal since they would need to be both maintained and consistent. Categorisation by fixed geographical regions corresponding to the modern borders benefits ordinary readers who'd e.g. want to see what Latin names are available for places they might be familiar with, and for diachronic linguistics it's also somewhat useful to be able to track placenames by fixed region. In general it seems obvious to me that listing "Roma" as the Latin name for a city in Italy is helpful in a way that categorising it as a city in the Roman Kingdom, a city in the Roman Republic (classical), a city in the Roman Empire, a city in the Exarchate of Ravenna, a city in the Papal States, a city in the Roman Republic of 1848, a city in the Kingdom of Italy, etc., is not. —Al-Muqanna المقنع (talk) 11:04, 17 August 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I've opened an RFD at Wiktionary:Requests for deletion/Others#Roman Empire toponym categories. —Al-Muqanna المقنع (talk) 11:35, 17 August 2023 (UTC)

@Al-Muqanna: OK, I've responded there. 0DF (talk) 12:27, 18 August 2023 (UTC)

having worked on a page for the last some hours, I've noticed that template:label seems to be by far the most common template that seems to not have a respective -lite version for dealing with Lua memory errors. Is this due to a technical limitation of some sort? QuakDucc (talk) 21:08, 16 August 2023 (UTC)

It's not realistic to make a -lite version of this template. The categorisation, linking, etc. functionality is too complex to replicate outside Lua. I suppose we could create special -lite versions of the absolute most common labels, like (transitive) and (obsolete), if needed. And of course, sui-generis labels like (of a person) can be created using {{q-lite}}. This, that and the other (talk) 00:22, 17 August 2023 (UTC)

Also pinging @Hythonia There's a problem with achnąć where the term was used by thieves, however, the label "thieves cant" links and refers to specifically English thieves' cant. What can we do? Vininn126 (talk) 13:49, 17 August 2023 (UTC)

Note there's a pending split request to divide thieves' cant per language. In the literature I can see uses of terms like "Russian thieves' cant" so that might be one solution, though the decision there has apparently been to use "criminal slang" for other languages, which also works. —Al-Muqanna المقنع (talk) 13:59, 17 August 2023 (UTC)

Commented there. Vininn126 (talk) 14:02, 17 August 2023 (UTC)

Hi,

temple

nose pad

rim

or

eyewire

(left) lens

hinge

endpiece

screw

temple tip

nose bridge

Eyeglasses parts

I’ve been exploring a modest proof of concept to present terms in a visual way, much like visual dictionaries. It’s not new, and has been implemented here by the picdic template for instance. I propose to use traditional callouts with thin lines to link a visual element to its term. It works pretty well on mobile, desktop and print versions, even when zooming in and out. Ideally, a user could create these labels graphically in a small GUI external to Wiktionary, which would yield wikicode that they would then paste into the edit box. For the test I propose on the right, I created an SVG image with callouts in Inkscape, then converted it semi-automatically in Python to produce wikicode. This could be done in Lua of course.

I like the fact that labeling these pictures may reveal some missing terms.

This concept is not entirely farfetched, but I would really appreciate it if I could have your impressions about it. It may be out of scope for this project, the wikicode could be too ugly, and so on. I am not sure because I am a bit new at this. I also don't know how much time it would take to implement this elegantly in a module for instance.

Thank you.

Edit: This figure would appear in eyeglasses. Jeran Renz (talk) 19:26, 17 August 2023 (UTC)

@Jeran Renz This looks great, thank you! We need more of this. WT:PICDIC is severely underdeveloped, but I think such diagrams are very helpful (and I like the design of yours much better than anything already in the picture dictionary). They're common in many print dictionaries and encyclopedias. As possible ideas for getting started, I might mention, in no particular order: parts of (1) a horse, (2) a bird, (3) a car, (4) a train, (5) a house, (6) various rooms in a house, (7), a computer, (8) a camera, (9) a tree, or (10) a flower. I suggest starting with more common items, especially ones where the terms are relatively well known, since this is extremely helpful for English learners. I look forward to seeing what you come up with! Andrew Sheedy (talk) 19:51, 17 August 2023 (UTC)

I second Andrew's comments. Looks great on my laptop and my phone too. —Al-Muqanna المقنع (talk) 20:40, 17 August 2023 (UTC)

@Jeran Renz: This looks lovely. Yes, the voluminous code would be a bit much in an entry, but I assume it could be housed elsewhere and then the result transcluded into the entry. 0DF (talk) 11:56, 18 August 2023 (UTC)

Yes, that would be the best approach. If you make these into a template, it would allow for including the image not just in the eyeglasses entry, but also at nose pad, endpiece, eyewire, etc., since it serves to illustrate those as well. Andrew Sheedy (talk) 17:37, 18 August 2023 (UTC)

Looks really nice! — Sgconlaw (talk) 17:55, 18 August 2023 (UTC)

Thank you for your constructive feedback. @Andrew Sheedy: Would a module be as acceptable as a template? The template language looks very unwieldy. --Jeran Renz (talk) 18:20, 18 August 2023 (UTC)

Unfortunately, I'm pretty ignorant when it comes to the technical side of things. I'm sure someone who knows better will weigh in. However you decide to implement this, I think it will add a lot to the entries. Andrew Sheedy (talk) 18:22, 18 August 2023 (UTC)

@Jeran Renz Modules are totally fine. Keep in mind that by convention we usually wrap a module using a template. It is fine to put the wikicode for a given diagram in either a module (wrapped in the appropriate template) or directly in a template and invoke it from the pages that need it (e.g. for this diagram, eyeglasses, nose pad, endpiece, etc.). One thing you might consider is generating the actual wikicode using a module along with a spec that just specifies the terms, positions and images. That way if people need to edit the spec manually, it's at least somewhat possible to do this, whereas editing the wikicode directly is more painful. Benwing2 (talk) 19:36, 18 August 2023 (UTC)

One thing to bear in mind as well is that ideally it should be fairly straightforward to create foreign-language versions of your diagrams. Andrew Sheedy (talk) 19:44, 18 August 2023 (UTC)

Thank you so much, I'll follow your recommendations! --Jeran Renz (talk) 00:17, 19 August 2023 (UTC)

@Benwing2 @Andrew Sheedy I have finished a first version of a module which turns annotation specs into a full-fledged annotated diagram. The module is called visual-dict. You can see an example output on my sandbox here, as well as a few desiderata. My code is open for all to review, and comments are welcome. Thanks! --Jeran Renz (talk) 20:45, 25 August 2023 (UTC)

I can't comment on the code, but I'm excited about what you have planned for it! This would really add a lot to Wiktionary if it becomes widely used. Andrew Sheedy (talk) 21:35, 25 August 2023 (UTC)

@Jeran Renz Your code looks good. A few minor comments:

1. I would document more clearly what the annotation format is and how the main entry point works; you can put this in a comment at the top of the main entry point in the code itself.
2. You might consider simplifying the specification of links to English terms. One possible way is to use a format like this in the annotation spec: <<rim>> or <<lens|left lens>> (if you need to specify separate link and display terms).
3. You might consider using Module:parameters to parse the arguments to the main entry point; see Module:form of/templates#L-509 for an example of how to do this.
4. By convention we tend to use spaces instead of hyphens in module names; hence Module:visual dict would be a slightly better name.

Benwing2 (talk) 22:24, 25 August 2023 (UTC)

How should we handle these?

I added a quotation at ☉ that included a vertical fraction. To enable that, I imported the template Template:sfrac from WP. User:Fenakhay deleted the template with a comment that templates should not be imported from WP. They then altered the quote to 1/3☉, which is the opposite of what was intended. I fixed it by adding parentheses, (1/3)☉, but that means there are now parentheses in our quotation that aren't in the original. I know trivial changes to quotations are allowed, but adding parentheses to a mathematical equation (even a simple one) doesn't strike me as trivial. So, how should this be handled? kwami (talk) 11:07, 18 August 2023 (UTC)

@Kwamikagami: I'd just write "⅓☉" (precomposed fraction, no parentheses), personally. The vertical, as opposed to diagonal, arrangement is only really stylistic, anyway. Moreover, were you to copy something like "¹₃☉", you'd end up pasting "13☉", which is something very different semantically (a 39-fold increase in mass), and not just stylistically; copying and pasting "⅓☉" preserves its meaning. 0DF (talk) 11:42, 18 August 2023 (UTC)

"⅓☉" could be read as 1/3☉ rather than as 1☉/3. At best it's ambiguous, which is why diagonal fractions are not used in mathematical texts. To preserve the meaning, parentheses are needed. So, is that trivial enough a change to not worry about when quoting something? kwami (talk) 11:50, 18 August 2023 (UTC)

I think if it's a quote, it's much better to keep the original format. Yes, it's stylistic, but so are many uses of punctuation, spelling, and word choice, all of which we preserve as originally written. Andrew Sheedy (talk) 17:41, 18 August 2023 (UTC)

@Kwamikagami, Andrew Sheedy: The best thing would be if the vertical forms could be specified using a variation selector. Unfortunately, it appears that none of the precomposed fractions in Latin-1 Supplement and Number Forms or the fraction slash in General Punctuation have standardised variants defined for them. 0DF (talk) 01:35, 19 August 2023 (UTC)

Indeed, and Unicode really doesn't like VS's. It would be difficult to get them to accept new ones for fractions. kwami (talk) 06:54, 19 August 2023 (UTC)

Do we have a template for denoting fractions? If not, I'd support keeping {{sfrac}}, perhaps with some of the Wikipedianisms removed. @Fenakhay if what Kwami says is correct, this really should have gone to RFDO IMHO.

@Kwamikagami you can also use <math> notation, like <math>\textstyle\frac{1}{3}</math> = ${\displaystyle \textstyle {\frac {1}{3}}}$. This, that and the other (talk) 11:56, 18 August 2023 (UTC)

The math tag option seems best. —Al-Muqanna المقنع (talk) 17:42, 18 August 2023 (UTC)

Agreed. Importing templates from Wikipedia is often a bad idea, as they often have dependencies that we don't actually want because their functionality already exists under a different name. In this case, Kwamikagami also added Module:Unsubst, which pointlessly duplicated Module:unsubst. This has happened before, with Module:yesno being duplicated as Module:Yesno. Theknightwho (talk) 19:36, 18 August 2023 (UTC)

@0DF, Kwamikagami, Fenakhay: I'm not aware of any prohibition on taking templates from Wikipedia, though we need to be careful to comply with the Creative Commons Attribution-ShareAlike License, and in this case it seems that we would be importing a lot of machinery. In this case, I supported 0DF's suggestion - the style difference does not reach the character level, though I think @This, that and the other's solution works better. --RichardW57m (talk) 11:58, 18 August 2023 (UTC)

Just noting that we have {{frac}} but I suppose it doesn't produce the effect which @Al-Muqanna was seeking, in which case using math markup is better. — Sgconlaw (talk) 17:53, 18 August 2023 (UTC)

I took a look at {{sfrac}} in Wikipedia and it doesn't look like importing it is the worst possible thing, since it seems to have no dependencies except a CSS file. But using the <math> tag directly is also fine. Benwing2 (talk) 19:41, 18 August 2023 (UTC)

Okay, I'll use the 'math' tag. kwami (talk) 00:59, 19 August 2023 (UTC)

Heads up that on an different thread, there was some confusion about where to post edit requests for modules and others seemed to not understand that we can direct these requests to the Grease pit. I don't typically edit language modules, so I'm not familiar with standard practice, but I went ahead and edited MediaWiki:Protectedpagetext to direct all such requests to the Grease pit. If this is wrong, please let me know. —Justin (koavf)❤T☮C☺M☯ 23:04, 18 August 2023 (UTC)

On pages like Appendix:Variations of "daga", there is always introductory text like: "The word “daga” appears in many languages with many variations in the use of capitalization, punctuation, and use of diacritics." I think this should be done with a template, for easy updating and to avoid typos. Equinox ◑ 23:05, 19 August 2023 (UTC)

Sure, why not. cf (talk) 23:23, 19 August 2023 (UTC)

To be honest, the variations pages need an overhaul anyway. They're a bit of a mess. Theknightwho (talk) 00:51, 20 August 2023 (UTC)

That introductory text almost always includes a link to the corresponding Wikipedia page. I suggest including that in the template, but also a parameter |w= to specify the name of the Wikipedia page. —Mahāgaja · talk 08:59, 20 August 2023 (UTC)

@Equinox, Theknightwho, Mahagaja: In fact we already have a template {{variations}} that purports to do this, but it's (a) unused, (b) not usable in its current state as it displays all the sections (e.g. "Capitalization and punctuation", "Diacritics" and "Other scripts") without any way of customizing their output. I think it should be trimmed to only display the header, and maybe be renamed to {{variations header}} or {{variations nav}}. Benwing2 (talk) 23:45, 20 August 2023 (UTC)

@Equinox, Theknightwho, Mahagaja: Damn brackets. Benwing2 (talk) 23:46, 20 August 2023 (UTC)

@Benwing2 Thanks for this. How about we go the other way and bring it up to scratch by using a version of the column template? That would allow us to use sort, and would also address an issue I came up against the other day regarding unsupported titles, since there’s no language-neutral link template. Obviously it’s possible to do a bare link, but it’s not ideal - particularly when it comes to terms in non-Latin scripts. {{also}} uses plain_link in Module:links for a similar purpose, and we could incorporate it here as well. Theknightwho (talk) 00:05, 21 August 2023 (UTC)

@Theknightwho Can you clarify with an example? I'm not quite sure what you have in mind here by "using a version of the column template". Benwing2 (talk) 00:10, 21 August 2023 (UTC)

@Benwing2 Currently all the lists at (e.g.) Appendix:Variations of "a" are manually sorted bare links in a bulleted list, under headers such as {{top5}}. Unlike in mainspace, there’s no way to convert these to column templates at the moment (which would allow them to take advantage of things like sorting and script tagging), because the links need to be language-neutral in the same way {{also}} is. {{also}} uses plain_link for this purpose, so I think we should use a column template that does the same. Theknightwho (talk) 00:19, 21 August 2023 (UTC)

@Benwing2: I think {{variations}} is intended to be substed in when creating a new variations appendix. It creates the basic framework which the editor can then customize after hitting Save changes the first time. —Mahāgaja · talk 06:45, 21 August 2023 (UTC)

@Mahagaja I see, that makes sense. But IMO it's the wrong approach; something like what @Theknightwho proposes would be better. Benwing2 (talk) 07:13, 21 August 2023 (UTC)

We could have both, just replace the header text of {{variations}} with the new {{variations header}}. @BD2412: you created {{variations}} and a lot of the variations appendices, what do you think? —Mahāgaja · talk 07:59, 21 August 2023 (UTC)

I use {{variations}} to create pages by subst'ing, but I have no objection to just making it a template. One note, we would have to be able to toggle on and off the "and in other scripts" portion, as every appendicized term has variations in capitalization, punctuation, and diacritics, but many do not have script variations. If the template is made accordingly, I'll be glad to do the job of incorporating it into all of the pages. bd2412 T 13:18, 21 August 2023 (UTC)

Originally posted earlier this month at module talk:languages/data/3/p

m = {
	"Kapampangan",
	36121,
	"phi",
	"Latn", --also Kulitan, which lacks a code
	entry_name = {Latn = {remove_diacritics = c.grave .. c.acute .. c.circ}},
	standardChars = {
		Latn = "AaBbDdEeGgHhIiLlMmNnOoPpQqRrSsTtUuWwYyZz",
		c.punc
	},
	sort_key = {
		Latn = "tl-sortkey"
	},
}

Edit request will add typical characters for Kapampangan words as well as automatic accent stripping when a Kapampangan word with diacritics is provided to a link (e.g. amánu should link automatically to amanu without adding a second parameter). Proposed edit will also add sortation already used for Tagalog and some other Philippine languages (e.g. Cebuano, Ilocano, Hiligaynon, Waray-Waray) so Ñ and NG are handled as separate letters for sortation. TagaSanPedroAko (talk) 00:42, 21 August 2023 (UTC)

@TagaSanPedroAko OK, I added this. Let me know if anything goes wrong. Benwing2 (talk) 07:19, 21 August 2023 (UTC)

@Benwing2 all good, but I think I accidentally removed K from the list of typical letters. Here's a fix.

Latn = "AaBbDdEeGgHhIiKkLlMmNnOoPpQqRrSsTtUuWwYyZz",

TagaSanPedroAko (talk) 18:24, 21 August 2023 (UTC)

@Benwing2 Also should remove this other characters from typical letters: Q and Z. Those mostly occurs in spellings following the Bacolor norm and some proper nouns. TagaSanPedroAko (talk) 18:40, 23 August 2023 (UTC)

I attempted to add a section to a talk page but was not permitted with the following notice: "This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: probably vandalism". Uh, what? Redranger8402 (talk) 13:33, 21 August 2023 (UTC)

@Redranger8402 That filter looks for signs of vandals who randomly click buttons in the edit window and add lots of the same characters (among other things). I'm guessing what triggered it was the combination of "Italic text" and lots of apostrophes because you had lots of bold and italics in the markup. The filter looks only at edits by new accounts, so you won't have to worry about it for long. Chuck Entz (talk) 14:37, 21 August 2023 (UTC)

It's impressive how many edits that filter catches, and how obviously-garbage all the rest of them (apart from this) are. (And although many of them at first many of them look like unintentional edits akin to butt-dialing, it's interesting that users often try to re-add them, suggesting intentional vandalism after all.) As Chuck says, what triggered it is that you left an ''Italic text'' in your comment. BTW, you also initially added an unsigned comment directly onto the same line as another user's old comment, like this, which you noticed and corrected in subsequent attempts, and which I don't think any filter caught, but @other admins: should a filter catch that? It seems undesirable for new users to add text directly onto other people's old comments. - -sche (discuss) 14:55, 21 August 2023 (UTC)

Thanks, removed the 's and it was accepted. I understand what you mean regarding adding unsigned text to existing comments and will make sure to avoid doing so in the future. Redranger8402 (talk) 20:24, 25 August 2023 (UTC)

The last edit that abuse filter 82 caught was in January, and before that it was March 2021; it's only caught 32 edits ever. Do we still need it, or can we turn it off? (Its contribution towards the condition limit is small, but every little helps, and no reason to keep it on if it's not doing anything anymore.) BTW I also notice abuse filter 96 has only caught five edits by 2-3 users this year (two users in May, another in February). - -sche (discuss) 15:31, 21 August 2023 (UTC)

What are these filters for? JezperCrtp (talk) 22:13, 22 August 2023 (UTC)

Blocking certain common vandal actions before they can even be submitted. Equinox ◑ 22:16, 22 August 2023 (UTC)

Thanks to @Sgconlaw, {{R:OED Online}} has been updated to automatically generate the URL for the OED's new URL schema from the headword and POS. This is fine most of the time but it falls apart in some edge cases, e.g. multiword terms.

These are still predictable though with a few rules:

1. Capital letters → lower case
2. Apostrophes and initial hyphens are deleted
3. Spaces → hyphens
4. The POS comb. form becomes combform (the only problematic POS based on their glossary)

So "mauvais quart d'heure", n. is at /mauvais-quart-dheure_n; "Saxish", adj. is at /saxish_adj; "-sophy", comb. form is at /sophy_combform; "Low-Churchmanism", n. (with a hyphen in the middle) is at /low-churchmanism_n.

This should be a simple regex thing but my Lua is rudimentary so not sure how to handle it exactly. —Al-Muqanna المقنع (talk) 21:39, 21 August 2023 (UTC)

@Al-Muqanna:This should be straightforward in Lua. I’ve noticed diacritics are deleted (“mouton enragé”, n. is at mouton-enrage_n), but how are distinctions like naive and naïve handled? Theknightwho (talk) 14:31, 22 August 2023 (UTC)

@Theknightwho: There's no collision for that one but a comparable case is resume (to start again) vs. résumé (to summarize). In that case they are just distinguished by the numerical identifier: /resume_v1 and /resume_v2. (The same is also done in the headword, so it's "resume" v.¹ and "résumé" v.² even though they have different accenting.) Actually the numerical identifier in general (n.¹ and so on) probably needs to be a distinct parameter: at the moment it's handled by manually entering it into the POS field but now that it's used in the URL too it should probably be split out and formatted automatically. —Al-Muqanna المقنع (talk) 14:39, 22 August 2023 (UTC)

@Al-Muqanna Thanks. They also seem to delete final hyphens and brackets: see 401(k). I haven’t been able to find any other nonstandard characters. Theknightwho (talk) 15:06, 22 August 2023 (UTC)

I feel like we need a better way of handling certain definitions. I don't think anything will ever replace using a bare list of translations with a good gloss, however this isn't always enough. {{transclude sense}} can handle certain things, but it copies everything. This is indeed useful in some certain situations, like when two words are a perfect match, but I feel we need something in between. What if we had a template {{definition}} ({{def}} for short) that could handle most things on the definition line in a more elegant manner.

1. A param for the language {{{1}}}
2. For the definitions, perhaps multiple definitions could be given using {{{2}}}, {{{3}}}
3. Add a senseid to the definition, perhaps using {{{id}}}
4. Add labels and categories, probably using {{{lb}}}, {{{c}}}
5. Ideally it would be able to (but not necessarily have to) link to a specific English definition, perhaps using a parameter {{{enid1}}}, where the number matches the word entered in params 1-whatever etc?
   1. We could also potentially make this template obsolete {{transclude sense}} and have a parameter {{{transclude}}} and the English ID would be mandatory
6. Add a gloss, {{{gloss}}}, {{{gl}}}
7. Add government? We never finalized a way to regularly add it, but in theory this could be added here as well.
8. Perhaps controversially a reference, {{{ref}}}, this may or may not be useful for LDL's or something.
9. I suppose in theory you could include {{rfeq}} as a parameter, but I'm not sure I see the value.
10. Probably a qualifier? {{{q}}} may or may not be useful.
11. Perhaps a way to deal with commas vs semicolons between translations if idea 1 is kept
12. I'm not sure how {{defdate}} and references for it would factor in.

Again, this template would not be mandatory, but I feel it would definitely fill a gap and also really reduce a lot noise. For example, one could take

{{senseid|pl|condition}} {{l|en|state|id=condition}} {{gl|set of circumstances}} ({{l}} is used for the id, very useful imo)

and change it into

{{def|pl|state|id=condition|enid=condition|gl=set of circumstances}}

The amount of space, keystrokes, and brackets saved only add on when we add things like labels, etc.

We would also need to consider how verbs are handled, as verb should use "to" or "I" in special cases.

Perhaps this is the result of personal preference, but I hate having to call tons of templates, it makes it difficult to read the definition line in the editor, and I find parameters easier. Another upside would be that it could help regularize definitions, things could appear in the proper order. Vininn126 (talk) 23:30, 21 August 2023 (UTC)

Sounds good. I think this could possibly wait until resources are a bit less tight, but it’s inevitably the way we’re going to have to go if we want to make things more structured. The amount of unnecessary duplication across entries is huge at the moment, and while we often want to show information in multiple places, it’s usually good to have a way to keep it all synchronised. Having a special definitions template would greatly assist in that, because it would make transcluding senses across entries much easier. Theknightwho (talk) 23:43, 21 August 2023 (UTC)

@Theknightwho This is why I wanted to include transclude as a parameter. Vininn126 (talk) 23:45, 21 August 2023 (UTC)

drab contains a private-use-area character in the wikicode, in {{zlw-opl-IPA}}, which causes it to be unreachable / uneditable in AutoWikiBrowser. I'm not sure why AWB can't open pages with PUA characters (which is explicitly what's going on, it throws up an error message saying so), but it also seems like we shouldn't be using PUA characters in mainspace, so changing it to a stable character would resolve everything. - -sche (discuss) 16:01, 22 August 2023 (UTC)

@-sche That module will be obsoleted soon-ish anyway~, so the tofu can be replaced. Vininn126 (talk) 16:18, 22 August 2023 (UTC)

I replaced the PUA with something else. Vininn126 (talk) 16:23, 22 August 2023 (UTC)

Thanks! - -sche (discuss) 17:42, 22 August 2023 (UTC)

As of one minute ago, there was no table of contents for the (lengthy) August 2023 page of the Etymology Scriptorium - is this a known issue?

Thanks,

Chernorizets (talk) 08:30, 23 August 2023 (UTC)

Fixed. Someone had added "__notoc__" to a thread, which removed the table of contents for the whole page. —Mahāgaja · talk 08:58, 23 August 2023 (UTC)

I think neighborhoods and districts aren't handled right in Module:category tree/topic cat/data/Places. They are subdivisions of a city, but are categorized in "Neighborhoods in State" and get all mixed up. For example, Neighborhoods in Santa Catarina, Brazil has three entries, two are from a city and one from another. Trooper57 (talk) 21:55, 23 August 2023 (UTC)

@Trooper57 Yeah, this needs some work. I'll get to it eventually; there are a lot of accumulated fixes needed for the {{place}} modules. Benwing2 (talk) 05:55, 25 August 2023 (UTC)

This template occasionally needs manual transliterations, which don't work as in {{ko-regional|나뭇잎|나무잎|tr=namunnip}}. See 나뭇잎 (namunnip) (manually transliterated "namunnip") and its North Korean equivalent 나무잎 (namu'ip). Anatoli T. ^{(обсудить}/^вклад) 23:20, 23 August 2023 (UTC)

Since no response, drawing some attention from: (Notifying TAKASUGI Shinji, HappyMidnight, Tibidibi, Quadmix77, Kaepoong, AG202): and @Benwing2, @Erutuon, @Theknightwho. Anatoli T. ^{(обсудить}/^вклад) 03:21, 29 August 2023 (UTC)

Fixed by @Benwing2. Thank you! Anatoli T. ^{(обсудить}/^вклад) 04:43, 29 August 2023 (UTC)

After Wiktionary:Votes/2021-07/Deleting the Index passed, the old Index namespace was emptied of pages, but it was never actually removed from the wiki. This has now been done. There is no longer an "Index" (number 104) or "Index talk" (number 105) namespace on this wiki. Update your bots, scripts, etc.

(If you don't know what I'm talking about, then you can safely ignore this announcement!) This, that and the other (talk) 07:25, 24 August 2023 (UTC)

@This, that and the other Thank you. My scripts don't hardcode the set of namespaces; this is handled by pywikibot AFAIK. Benwing2 (talk) 05:56, 25 August 2023 (UTC)

In a bot run today I see the |nocat= param was removed from quotations in Citations pages. Those pages are now categorised under "X terms with quotations". I'm not sure this is a good idea, because it means that non-existent entries with a citations page, either deleted by RFV or not yet ready to publish, are now categorised as entries. That's mainly why I was using |nocat=1 there. IMO the nocat parameter should either be restored or categorisation disabled on citations pages. @Benwing2 (sorry to bother again!) —Al-Muqanna المقنع (talk) 09:27, 24 August 2023 (UTC)

Perhaps a maintenance category of Citations pages would be useful instead. Vininn126 (talk) 09:43, 24 August 2023 (UTC)

That would also work. I do think it's odd, in general, that Citations pages and entries themselves are mixed together in the existing system, though it makes sense to indicate an existing entry where the quotations are on its Citations page. It might be pedantic but since it's not a hidden cat and the desc says it's for entries I do think there's potential for reader confusion. —Al-Muqanna المقنع (talk) 12:38, 24 August 2023 (UTC)

@Al-Muqanna There are a large number of Citations pages and only a few of them were using nocat=1. I didn't realize it was you adding them but as a general rule something like this shouldn't be done manually. Either Citations pages should or shouldn't be in the "X terms with quotations" categories, or maybe it should be done only for Citations pages where the corresponding mainspace page exists. But in any case it should be handled by the module, not manually. Benwing2 (talk) 05:54, 25 August 2023 (UTC)

@Benwing2: Yes I agree. Granted it's not usual atm though I don't think it's just me since I took it from somewhere originally—your last suggestion about only categorising them if the main entry actually exists seems like the most straightforward solution to this. —Al-Muqanna المقنع (talk) 07:39, 25 August 2023 (UTC)

@Al-Muqanna For reference, this should be fixed. If you see something wrong, let me know. Benwing2 (talk) 17:49, 27 August 2023 (UTC)

I notice that if you write {{homophones|en|}} or {{homophones|en||}}, it throws an error (as it should).
And if you write {{homophones|en|foo|}}, it just shows "Homophone: foo" and ignores the empty parameter.
But if you write {{homophones|en||foo}}, it doesn't throw an error or ignore the empty parameter, instead it displays "Homophones: term, foo" with the word term erroneously added to the list of homophones, and it doesn't seem to add any kind of error tracking category flagging that something's amiss, either.
And if you write {{homophones|en|||foo}}, it displays "Homophones: term, , foo".
Presumably it should do something to indicate something is amiss, whether by throwing a visible error or adding a tracking category for some bot to cleanup. - -sche (discuss) 06:52, 25 August 2023 (UTC)

@Benwing2, Sgconlaw: E.g., in {{RQ:Richardson Pamela}}, |publisher= Rivington]],{{nb...|in St. Paul’s Church Yard}}; and J. Osborn,{{nb...|in Pater-noster Row.}} results in “C Rivington, and and J. Osborn, ” instead of “C Rivington, ; and J. Osborn, ” because semicolons are automatically changed to “and”. Special:Search/"and and" shows many more examples of this issue. J3133 (talk) 11:24, 26 August 2023 (UTC)

@Benwing2: it probably shouldn’t operate as a form of markup in the |publisher= field. — Sgconlaw (talk) 12:18, 26 August 2023 (UTC)

@J3133 @Sgconlaw I will change this so that semicolons are displayed as semicolons in the |publisher= field; this allows multiple publishers with inline modifiers attached to each, but won't affect the display in cases like this. Benwing2 (talk) 19:19, 26 August 2023 (UTC)

@Benwing2: ah, I see. Thanks for making it “smart” then! — Sgconlaw (talk) 21:21, 26 August 2023 (UTC)

@Benwing2, Sgconlaw: Is “Boston, Mass.; New York, N.Y.:” supposed to change to “Boston, Mass., New York, N.Y.”? J3133 (talk) 18:19, 29 August 2023 (UTC)

@J3133: I don't think so. — Sgconlaw (talk) 18:22, 29 August 2023 (UTC)

@J3133 @Sgconlaw It does currently. Maybe it should use a semicolon, or maybe a semicolon only when there are embedded commas, as in this example. Or maybe it should use and, like "Boston, Mass. and New York, N.Y.". Not sure what is most standard in bibliographies. Benwing2 (talk) 18:39, 29 August 2023 (UTC)

@Benwing2: traditionally the International Standard Bibliographic Description used semicolons, I believe. — Sgconlaw (talk) 18:53, 29 August 2023 (UTC)

@Benwing2, Sgconlaw: This issue has still not been fixed; “London; New York, N.Y.” is changed automatically to “London, New York, N.Y.” J3133 (talk) 18:43, 22 December 2023 (UTC)

@J3133: Consider using slashes instead. 0DF (talk) 19:21, 22 December 2023 (UTC)

No, because that isn't in line with any bibliographic standard. — Sgconlaw (talk) 21:06, 22 December 2023 (UTC)

@Sgconlaw: It is in line with the consolidated style sheet (§ 3.2.1 and elsewhere) of the Refugee Survey Quarterly:
“When there are multiple publisher’s locations to be mentioned, they should be separated by a slash, e.g. Hague/London/New York.”
0DF (talk) 22:28, 22 December 2023 (UTC)

@0DF That sounds like a one-off house style; I've never seen that elsewhere. Benwing2 (talk) 22:44, 22 December 2023 (UTC)

@Benwing2: It's not a one-off, but it's probably not the commonest. I don't know where I saw it, but I adopted it back then as my default way of providing multiple publication locations. I could be persuaded to use a different method. There's a lot of variation in how style guides instruct on this issue. There's separating by commas, semi-colons, or slashes; there's listing with conjunctions (and or ampersands), with commas or polysyndeton for 3+ locations (with or without the serial comma); or there's the injunction to provide only one location (with various rules on how to choose among them) or to omit location information altogether. With regard to the last of those regulations, I am sympathetic to the view that location information if often of questionable value. 0DF (talk) 23:15, 22 December 2023 (UTC)

@J3133 All right, I'll get to this soon :) Benwing2 (talk) 22:45, 22 December 2023 (UTC)

For aesthetic allowance, I have used middle dot. It is obvious that all style guides are restricted by assumptions about keyboard layouts, pointlessly: Within xkeyboard-layout, and hence all free desktops, on us(intl) the interpunct is X (key <AB02>) + right alt, with de it is comma (key <AB08>) + right alt, etc. Of course semicolon makes since so we have it as with the authors and the templates can do it uniformly, but as for display, all of comma, semicolon and slashes, ampersands are ugly, clashing with what a typographist would do, no? Back when one had literal typographers, one would mostly omit multiple locations to save space anyway, unless publishing for bibliophiles or the like, I suppose. Fay Freak (talk) 23:41, 22 December 2023 (UTC)

@Fay Freak: Hmm. I quite like your interpunct idea. 0DF (talk) 00:51, 23 December 2023 (UTC)

Not sure where I am supposed to report this, but it seems that the Pinyin input method does not recognize "er" as a syllable and would not add the tone mark if a number is typed after "er". It works if you type "e", then tone number, then "r", though. Stormraiser (talk) 16:09, 26 August 2023 (UTC)

@Stormraiser welcome! Can you please advise what you are referring to by "Pinyin input method"? I don't believe Wiktionary provides such a thing; normally input methods are provided by your device's operating system. This, that and the other (talk) 09:28, 27 August 2023 (UTC)

It's a MediaWiki extension, I think https://www.mediawiki.orghttps://dictious.com/en/Help:Extension:UniversalLanguageSelector/Input_methods/zh-pinyin-transliteration

Apparently it is not enabled on Wikipedia as I've never seen it there Stormraiser (talk) 09:39, 27 August 2023 (UTC)

At quaint there are Talk:quaint (aka "Discussion") and Citations:quaint.

From Talk:quaint I cannot see a tab for Citations:quaint.

From Citations:quaint I cannot see a tab for the entry and I see a tab called "Discussion" that is a redlink.

These seem to me to be bugs, not features. Could this be fixed, please? — This unsigned comment was added by DCDuring (talk • contribs) at 17:43, 26 August 2023 (UTC).

All three tabs appear on all three pages for me. —Mahāgaja · talk 17:47, 26 August 2023 (UTC)

I've tried this on both new and old MonobookVector, with the same result. Have there been any recent changes that might have caused this and since been changed? I don't often shut down/restart my browser or close/reopen wiki windows, let alone reboot my PC. DCDuring (talk) 17:51, 26 August 2023 (UTC)

For the Talk and Citations pages what you're describing is what appears with Javascript off, but I don't know why the Citations tab would still appear on the main entry since that one is also loaded in by script. —Al-Muqanna المقنع (talk) 17:52, 26 August 2023 (UTC)

I misspoke above. The problem occurs in the two Vector skins. The Citations tab did appear under 'Tools', but there was a redlinked 'Discussion' tab.

Is this the kind of thing that is a symptom of technical debt?

It's OK with Monobook, to which I have now returned. DCDuring (talk) 17:59, 26 August 2023 (UTC)

Isle of Man: From {{af|en|]|of|]}}.: “From Isle + of +

"Halla Bol" ( a military charge accompanied by battle cries) is an event in Sikh martial festivals held annually in the month of March at several places in India . Please see video link https://www.facebook.com/watch/?v=213846446397495

.tr, .mention.Latn { white-space: nowrap }