text:
Wiktionary:Grease pit/2021/October

for
I  but was reverted by  with comment. This is true but sometimes there might be multiple sources of a borrowing or so and I think this parameter would be useful (maybe not as much as the parameter). Why should this not be added? Svartava2 (talk) 03:53, 2 October 2021 (UTC)

 * also pinging who  the module: why shouldn't this be added? Svartava2 (talk) 03:14, 7 October 2021 (UTC)
 * Please give examples of entries that you'd use this in. — Eru·tuon 14:56, 7 October 2021 (UTC)

Template:ja-pron for "mixed pitch accent"
I don't know if there is a special term for it: sometimes there is more than one type of pitch accent in a word. For example:

 * 意気投合
 * きと  (Atamadaka + Heiban – [1]-[0])

 * 青息吐息
 * あきと  (Nakadakagata + Heiban – [3]-[0])
 * あきいき  (Nakadakagata + Atamadaka – [3]-[1])

It does not seem that Template:ja-pron can handle this type of pitch accent. If possible, the parameter should accept more than one number and show the mixed pitch accents above, but I have no idea how to implement it. --TongcyDai (talk) 07:30, 2 October 2021 (UTC)

Resolved: produces strange instrumental plural of яйцо́
Sorry, I see I was looking at the Belarussian lemma, not the Russian. PJTraill (talk) 16:24, 10 October 2021 (UTC)
 * At I see a strange instrumental plural, namely я́йцамі, where  is correct (according to the latter lemma and Russian Wiktionary). This is produced by . The genitive plural also disagrees with Russian Wiktionary, and I cannot make out anything there about a “count form яйцы́” to be used where a genitive singular would be normal (*xy, x mod 10 ≠ 1, y mod 10 ∊ {2,3,4}. Could someone please fix this? The documentation of this template also fails to state when it should be used. PJTraill (talk) 15:19, 10 October 2021 (UTC)

Using Special:RandomInCategory with en: categories
I would like to use Special:RandomInCategory to get random terms from Category:en:Anatomy. But all of my attempts have returned categories of the form "Category: :Anatomy", eg Category:bnn:Anatomy. I've tried: The categories returned are subcategories of Category:Anatomy, not Category:en:Anatomy. Is this a known issue? Is this something that an editor like me might be able to fix? I have no idea where to start, since special pages don't have talk pages or obvious documentation like templates do. - excarnateSojourner (talk|contrib) 19:25, 10 October 2021 (UTC)
 * Visiting Special:RandomInCategory/en:Anatomy.
 * Visiting Special:RandomInCategory/en%3AAnatomy.
 * Typing in "en:Anatomy" at Special:RandomInCategory.
 * Special:RandomInCategory/Category:en:Anatomy. Vox Sciurorum (talk) 19:29, 10 October 2021 (UTC)
 * Ah, great. Thank you. - excarnateSojourner (talk|contrib) 23:42, 10 October 2021 (UTC)

I am unable to add information to discussion page
This page: https://en.wiktionary.org/wiki/outher contains question if we can find word "outher" in Chaucer works. I found few of them, but I am not sure how to properly cite them in the main page, so I wanted to add them to discussion page, so somebody with better knowledge about wikitionary customs could do it.

Unfortunately I am unable to do my edit on https://en.wiktionary.org/w/index.php?title=Talk:outher&action=edit&redlink=1

I fill following content:

--- Occurrences of outher in Chaucer works:

---
 * verses 931 and 1136 here: https://chaucer.fas.harvard.edu/pages/man-laws-introduction-prologue-tale-and-epilogue
 * verses 1485, 1593, 1645 and 2556 here: https://sacred-texts.com/neu/eng/mect/mect01.htm

And when I try to publish the discussion page I receive following message:

--- Error: information 	Warning: This action has been automatically identified as harmful.

Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it.

A brief description of the abuse rule which your action matched is: various specific spammer habits. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit. ---
 * The problem is that you posted basically nothing but a couple of links. The abuse filter isn't smart enough to tell whether you're linking to a legitimate website, so it looks at whether you have a history of other edits (the system doesn't keep edit counts for anonymous/IP editors, so they always show as having 0 edits), and whether it's formatted like there's more to the edit than displaying links. If not, it blocks the edit just to be safe. I go through the logs for that filter every day, and you would be amazed at the sheer volume of spam that gets attempted all the time. Either it's bots that are trying to improve a site's search engine page rank by having as many different sites linking to it as possible, or website owners who are trying to post ads without paying for them. Nine times out of ten, the edits the filter blocks are dishonest garbage.

 * My advice is to create an account. There's a lot that people can learn from your IP address (here's a sample of what just one site knows about you) Or add more text, or remove things like the " https:// " that makes a clickable link out of it. Chuck Entz (talk) 03:26, 13 October 2021 (UTC)

 * The problem is that I was not able to get through this filter even after hitting submit again! BTW I have static IP and I am not worried about information leaks due to this (and I know how to use proxy or Tor) --- I just believe in the idea of wiki being editable ad hoc by anyone without any red tape like account creation, hence I am not going to create one. 80.53.20.242 16:43, 17 October 2021 (UTC)

Latin verb facio, alternative conjugations
I don't have any Lua coding facility, so I don't exactly know how to do this. I would like to add certain less-used forms of the Latin verb facio (to make; to do) to the conjugation table, rather than having them in explanatory notes or nowhere at all. In particular, under indicative future perfect, I want faxo, faxis, faxit, faxīmus, faxītis, faxint, under subjunctive perfect, I want faxim, faxis, faxit, faximus, faxitis, faxint, under indicative active pluperfect, I want feficeram, feficeras, feficerat, feficeramus, feficeratis, feficerant, under indicative future pluperfect, I want feficero, feficeris, feficerit, feficerimus, feficeritis, feficerint, under indicative active perfect, I want fefici, feficisti, feficit, feficimus, feficistis, feficerunt, under subjunctive active perfect, I want feficerim, feficeris, feficerit, feficerimus, feficeritis, feficerint, and under subjunctive active pluperfect, I want feficissem, feficisses, feficisset, feficissemus, feficissetis, feficissent.

Compared to what is used to-day, these are somewhat archaic alternatives, and certainly obsolescent if not obsolete, but they do fit established paradigms (see pedo, cado, and other Category:Latin_reduplicative_verbs), as well as facio dictionary entry and Google book, Latin grammar). For those looking for that pre-Classical style, having them presented in a table, as alternatives, would be invaluable.

Red links and blue links for coloured emoji?
Looking at Requested_entries_(Translingual) I note that it's impossible to tell whether a coloured emoji character has an article or not, since its colours override the normal red or blue link colour. This feels like a shortcoming. Can anything be done? Equinox ◑ 04:13, 17 October 2021 (UTC)
 * You can do it with this CSS. Possibly this would have unintended side effects. DTLHS (talk) 04:30, 17 October 2021 (UTC)

Ancient Greek adjectives in -υς
Hi! I noticed the adjectives in -υς (e.g. βαθύς, βαρύς) get a genitive in εως, while my textbook and dictionary suggest εος. Does anyone know if that's expected and if not, where to edit it?
 * I think it is ok now. Attn ! hopefully I did not damage something else at Module:grc-decl/decl/staticdata/paradigms ... ‑‑Sarri.greek ♫ |
 * I finally looked into this. The was meant for nouns like  and . Perhaps nobody noticed that it was wrong for adjectives before! I've edited the modules so that Module:grc-decl/decl/staticdata/paradigms handles the nouns once again, and Module:grc-decl/decl/data sets the genitive singular to  just for adjectives. It's a bit counterintuitive because the adjectives are much more common, but we generally put noun paradigms in the staticdata module and treat the adjectives as deviations from nouns. — Eru·tuon 20:38, 30 October 2021 (UTC)

 * thank you. isn't the genitive of πῆχυς@LOGEION also -εος? And of γόνυ, is γόνατος? Also, i have checked all the -πήχυς compounds (adj or nouns, the masc gen is the same) [as Smyth gives [[δίπηχυς]] as an example of proparoxytone - notes at Talk:ἀμφίβραχυς -  where a form -εως is given only at Bailly, and I wonder if it means something attic, or a genitive.
 * The Module:grc-decl/decl/staticdata/paradigms is very nice, it would be great if next to each thing, there is an example (so, checking is easier for people like us, who do not know where this section is applied. Thank you, ‑‑Sarri.greek ♫ | 20:55, 30 October 2021 (UTC)
 * We probably based it on Smyth's Greek Grammar, which shows only . I thought was Ionic and Epic, not Attic or Koine, but while the LSJ does give Ionic citations (Herodotus, Hippocrates), there are some from Attic (Aristotle and Plato) and Koine (the Septuagint), so perhaps we should give both forms. The LSJ has more citations for  than for, so maybe it's more common! I'm not sure how to investigate this further because I wasn't the one who added most of the dialectal information. — Eru·tuon 00:08, 31 October 2021 (UTC)
 * , thank you, I appreciate all your work for greek. It is complicated... ‑‑Sarri.greek ♫ | 00:30, 31 October 2021 (UTC)
 * True It is πήχεως with omega. Stamatakos Grammar says «The expected -εος at Herodotus». But he does not say, if the behavior of gen. is different in adjectives. or compounds.or later words. For adjectives he agrees with Smyth: the masc. & neu. infelct like nouns. So, ἀμφίβραχυς which is not an adjective has -εως at Bailly.
 * Possibly, my thought is that when we have a compound +noun (πῆχυς) like δίπηχυς (@LOGEION) as Smyth says, the genitive follows the -εως noun.gentive ( my schoolbook gives -εος, assumed wrong by Smyth and Stamatakos ).
 * but if it is a compound +adjective (βραχύς) like adj. δίβραχυς (Bailly gives it as a noun), then i suspect it follows the adjective.genitive -εος. ‑‑Sarri.greek ♫ | 02:10, 31 October 2021 (UTC)
 * @Erutuon and @Sarri.greek thanks a lot for looking into it! I'm currently studying for my (Ancient Greek) exams so I can't look into it myself so thanks for changing it! Willem640 (talk) 12:44, 31 October 2021 (UTC)

Coolest Tool Award 2021: Call for nominations
The third edition of the Coolest Tool Award is looking for nominations!

Tools play an essential role for the Wikimedia projects, and so do the many volunteer developers who experiment with new ideas and develop and maintain local and global solutions to support the Wikimedia communities. The Coolest Tool Award aims to recognize and celebrate the coolest tools in a variety of categories.

The awarded projects will be announced and showcased in a virtual ceremony in December. Deadline to submit nominations is October 27. More information: Coolest Tool Award. Thanks for your recommendations! -- SSethi (WMF) for the 2021 Coolest Tool Academy team 05:57, 19 October 2021 (UTC)

Spanish adverb list
Hi. I hear you guys are pretty good at making lists. Can someone generate one of all Spanish adverbs ending in -mente not appearing in Category:Spanish words suffixed with -mente? And/or another one for all entries in Category:Spanish words suffixed with -mente that are not linked-to by the corresponding adjective? Gracias de antemano QuickPhyxa (talk) 21:26, 20 October 2021 (UTC)
 * I did the second one for you using petscan - QuickPhyxa (talk) 08:29, 21 October 2021 (UTC)

 * Done them MooreDoor (talk) 22:15, 19 November 2021 (UTC)

Chakma Transliteration
I have created a transliteration module for the Chakma script, Module:Cakm-translit. It explicitly supports the Chakma (code ccp) and Pali (code pi) languages.

How do I advise the future 'community of Chakma editors' (I see no evidence of current existence, though I know has added Chakma words) that for transliteration, they should consider using it rather than creating a new module Module:ccp-translit? One possible method would be to create a hard redirect from the latter to the former. At present, it has the flaw that it cannot work out whether to transliterate 𑄃𑄧 U+11127 CHAKMA VOWEL SIGN A as 'a', 'o' or 'ô'. Current, manual transliterations also use 'o' for 𑄃𑄮 U+1112E CHAKMA VOWEL SIGN O. The testcases show the manual and calculated transliterations for all 59 word lemmas with manual transliterations. --RichardW57 (talk) 17:46, 21 October 2021 (UTC)

Adding for Proto-Hungarian to Module:etymology languages/data

 * I wonder if any of you could add  for Proto-Hungarian to Module:etymology languages/data (and maybe also to Module:languages/datax). This period in the history of Hungarian (between 1500/1000 BCE and 895 CE, i.e. after Proto-Ugric and before Old Hungarian) doesn't seem to be covered by any code, so currently it needs to be supplied in plain text whenever it's referenced (at the moment, in  as well as Reconstruction:Proto-Ugric/säptɜ and Reconstruction:Proto-Uralic/śerɜ, so it would be used e.g. in  and in ). It is not attested (the earliest attested records are from early Old Hungarian, except for  from 870) but many forms are reconstructed for this period (Zaicz’s etymology dictionary has 201 results for ). As far as its code is concerned, Proto-Mordvinic has "urj-mdv-pro", Proto-Permic has "urj-prm-pro", so I thought urj-hun-pro might be appropriate, though the format hun-pro may have some analogies as well. It could link to . Thank you. Adam78 (talk) 10:58, 26 October 2021 (UTC)
 * I can add it into the data if there's consensus that it should exist - I'm not sure what our convention is with protolanguages with only one descendant (unless we consider Hungarian dialects to be separate descendants, I suppose). — surjection ⟨??⟩ 11:05, 26 October 2021 (UTC)
 * I don't know anything about Ugric, and would appreciate 's input. In looking at the evidence here, I don't see anything compelling us to add it. We don't add every protolanguage that scholars have ever reconstructed, and not every term needs to be linked (after all, this is all internal comparison, to there will always be a Hungarian term to link to instead). —Μετάknowledge discuss/deeds 22:01, 26 October 2021 (UTC)
 * "Proto-Hungarian", in the usual early 1st millennium CE sense of this term in Hungarology, is kind of a misnomer / mistranslation and not the proto-language of the currently known Hungarian varieties (I believe the consensus is that all possible Old Hungarian era variants were levelled out by dialect mixing and the modern-day dialects show basically no divergences older than late medieval). If anything, it's the assumed proto-language of Hungarian and the unattested Volga Magyar, so I don't see us needing it anytime soon. A case like -p ~ fiú comes the closest but could just as well date already further back to circa Proto-Ugric; while the other cases mentioned by Adam seem to basically mean Old Hungarian and could be tagged as that if we ever wanted their redlink entries. --Tropylium (talk) 16:54, 29 October 2021 (UTC)

This Word Does Not Exist
If you're running out of ideas when writing entries: someone created ML-based dictionary definitions:, including made up usage examples. Apparently not using any Wiktionary data though. It would be fun to see this applied to etymologies as well. – Jberkel 20:33, 26 October 2021 (UTC)

 * Beer_parlour/2020/June! Equinox ◑ 20:43, 26 October 2021 (UTC)

Can somebody create these two useful R: templates for me?
I would do it myself but I don't know how and I believe one needs special permissions anyway.

One for the site berndeutsch.ch. URLs have the form.

One for pons.com. We already have but it links to the translation pages, not the German entry pages which sometimes have more information, see e.g.  vs this page. Fytcha (talk) 19:41, 27 October 2021 (UTC)

 * An R: template for de.thefreedictionary.com would also be useful. This one should be really simple to implement and it already exists on de.wikt. Fytcha (talk) 15:34, 28 October 2021 (UTC)
 * Ok, I'll take a look. – Jberkel 15:40, 28 October 2021 (UTC)
 * I've created and added a def parameter to, there is already   – Jberkel 22:29, 29 October 2021 (UTC)
 * Thank you a lot! As a last request, would it be possible to move to ? I should have pointed that out earlier but that site only concerns gsw. Fytcha (talk) 22:32, 29 October 2021 (UTC)
 * Thank you! Fytcha (talk) 22:41, 29 October 2021 (UTC)

Module errors in Module:tl-headword
After edited this module, a large number of entries using tl-noun with one or more empty parameters are in CAT:E with the message 'the parameter "2" is not used by this template'. I don't want to revert without understanding the code, but having 93 entries in CAT:E is simply unacceptable. For one thing, there were at least 3 entries with unrelated, easily fixable errors that were hiding in plain sight in among them. There may be more, but I don't have time right now to go through all of them (there's also a Korean entry that needs to look at). Before this happened, the category had about 15 or 16 entries with memory errors, so there are probably about 75 with this one.

Can someone who knows Lua determine whether this is a fixable bug? If the errors are due to empty parameters that shouldn't be there, can someone with a bot remove them? Thanks! Chuck Entz (talk) 05:15, 28 October 2021 (UTC)

 * I just fixed the error upon receiving your ping, which has something to do with my addition of support for feminine and masculine forms. -TagaSanPedroAko (talk) 05:56, 28 October 2021 (UTC)
 * @Chuck Entz Solved it, having moved the support for gendered forms to the noun functions (only nouns have that, especially Spanish-derived ones), plus changes to follow the coding used to handle Baybayin spellings, which worked. TagaSanPedroAko (talk) 07:23, 28 October 2021 (UTC)

Audio files, Lingua Libre, ogg
Other Macedonian users and I are talking about adding audio files to Macedonian entries and I was wondering whether the recordings have to be in .ogg format. Help:Audio_pronunciations says that Ogg Vorbis is the "format of choice", but doesn't explicitly exclude or even mention other formats, and it appears not to have been rigorously updated over the years. Furthermore, in section 1.5., it sort of recommends Lingua Libre, but all the words recorded on that site by another Macedonian user have ended up in .wav format. Can we add those to the corresponding Macedonian pages or do we have to convert them to .ogg first? I see that there are Polish entries like maczuga where the file is in .wav format and works even so. Martin123xyz (talk) 08:41, 28 October 2021 (UTC)

 * Ogg files are compressed audio files, and wavs are uncompressed so the size difference can be considerable: the wav for maczuga is 768k while the ogg files for hello are all ~100k (which still seems large to me). Luckily, it's easy to convert from wav to ogg, so it's not a problem to create a bunch of wav files using Lingua Libre and then later convert them to ogg. If you search for utilities to 'batch convert wav ogg' and you'll find lots of free options. JeffDoozan (talk) 13:03, 28 October 2021 (UTC)
 * MP3 is now patent-free and can be used as well on commons, so maybe the "format of choice" part should be updated. If possible the source format should be lossless, it will be transcoded automatically. – Jberkel 13:20, 28 October 2021 (UTC)
 * Thank you for the explanations. We will look into converting the .wav files into .ogg files. Martin123xyz (talk) 06:03, 29 October 2021 (UTC)

Translation Boxes and
Can we please have exactly the same parameters as for ? I.e. checkboxes for {m,f,n}x{s,p} and no double confirmation for capitalized translations. Fytcha (talk) 14:42, 28 October 2021 (UTC)
 * ✅ — surjection ⟨??⟩ 21:28, 9 November 2021 (UTC)
 * Thank you! I've just tested it and it works like a charm. Fytcha (talk) 21:35, 9 November 2021 (UTC)

Bug in tr.wiktionary gadget for adding translations
Turkish Wiktionary uses a javascript gadget to add translations, very much like English Wiktionary. But the new translations are not placed in correct alphabetic order. In particular, Chinese entries (Chinese is "Çince" in Turkish) are not put at "C/Ç" (between Bulgarca/Bulgarian and Danca/Danish), but at the end of the list, as if unicode position was used instead of alphabetic sorting order. Here are four examples of incorrect additions: 1, 2, 3, 4. I think the relevant code is tr:MediaWiki:Gadget-CeviriEkleyici.js (çeviri = translation, ekle = add). But perhaps the problem is not in the algorithm (since it does work for languages with other names), but in some website parameter for sorting order (LC_COLLATE)? Who can give clues? --LA2 (talk) 19:16, 29 October 2021 (UTC)

 * The bug has been mostly fixed now, by replacing "a < b" with "a.localeCompare(b, 'tr') < 0". Another part of the problem, related to sorting Chinese as a sublanguage, remains. --LA2 (talk) 15:24, 7 November 2021 (UTC)

and N-syllable categories
is a 2-syllable word but it is not added to the Category:German_2-syllable_words. Usually that categorization is taken care of by, however in this specific case, the use of a narrow transcription [] instead of a broad one // seems to make the difference. Is there any reason for why narrow transcriptions are not taken into consideration when categorizing for syllables? Fytcha (talk) 21:35, 29 October 2021 (UTC)

 * Same issue with . Alternatively (if that with won't change), can't we make it such that  also adds the N-syllable word category? Fytcha (talk) 21:45, 29 October 2021 (UTC)

Please help to address problematic behaviour (harassment, piracy, sockpuppetry) on other wiki

 * Resolve_massive_copyright_infringement_on_Wiktionary_in_Esperanto
 * I_need_to_solve_the_problem_that_I_consider_important_in_the_eo.wiktionary.org_project

The Esperanto wiktionary has a long history of poor quality, copyright infringements (promoted and committed by sysops) and mismanagement. The third RFC about more-or-less same subject was recently created. I am temporarily sysop there, the only one. The latest RFC was not created by me but a user "Vami". I was harassed by "Vami" for 3 weeks, then I dared to block for 24 hours. "Vami" overreacted (as expected) and started that RFC. The case comprises a mixture of problems and conflicts, among others following:
 * Harassment by "Vami" (an obviously very intelligent person) against me, including but not limited to:
 * calling me "nazi" (by creating a template "antinazi" and introducing a language code "antinazi" in another template, from the context undoubtedly targeting me)
 * sending me to school ("you must attend a school")
 * calling me "stupid" many times (mostly avoiding the most direct way "you are stupid" on my discussion page, instead burying the claim in subordinate clauses, questions, semi-vague hypotheses, edit comments, ...)
 * creating a post in the Beer Parlour beginning with "Particularly for idiots" (from the context undoubtedly targeting me)
 * persistently accusing me of vandalism, destruction, theft of time and more
 * I can immediately and permanently block this user, or could have done it one month ago ... yet the probem is that I do not want to be judge in my own case, and "Vami" is very deliberately exploiting this problem. In any other wiki, with this level of rudeness, "Vami" would have got blocked long ago for a long time. Shall I block, and for how long?

For the sake of completeness, I have to confirm that "Vami" also has made substantial contributions to that wiki. Taylor 49 (talk) 19:12, 30 October 2021 (UTC)
 * Massive copyright infringement (comitted long ago by a former, and formally still appointed sysop, NOT by "Vami")
 * I suspect that "Vami" is a new account of an old problem user blocked somewhere. Upon arrival at Esperanto wiktionary "Vami" had less than 200 global edits. But within just few weeks "Vami" advanced to sophisticated template edits and operating a bot. A behaviour very unususal for a newbie. I have no clue where to search for "bad old" accounts of "Vami", they can be anywhere. "Vami" is Russian and I do not understand that language.
 * I don't know what this has to do with en.wikt or why this is in the grease pit which is for technical discussions. — surjection ⟨??⟩ 21:26, 9 November 2021 (UTC)

Is it possible to blacklist certain characters from translation boxes?
in particular. Duden.de contains them on all their pages and I've just almost accidentally entered a term containing those characters into Wiktionary without noticing. Fytcha (talk) 20:32, 30 October 2021 (UTC)
 * Theoretically yes by using abuse filters, but if you use tradder, I don't know how that would react - it might just spit out a cryptic error. I guess it'd also be possible to mod tradder to warn about them or even remove soft hyphens automatically. — surjection ⟨??⟩ 21:25, 9 November 2021 (UTC)
 * I assume tradder is the translation box interface in non-editing mode? If so: Yes, removing soft hyphens automatically when entering a term there would be even better. I don't think there's ever a reason to want to have them there. Fytcha (talk) 21:49, 9 November 2021 (UTC)
 * I think writing  between lines 1907 and 1908 here would do the trick. Fytcha (talk) 00:59, 8 December 2021 (UTC)
 * I don't see how adding any code into the data module will help matters. It'd have to be added somewhere in the main module. — S URJECTION / T / C / L / 11:24, 8 December 2021 (UTC)

title: Wiktionary:Grease pit/2021/October


text:
Wiktionary:Grease pit/2021/November

Automatically add translations template?
Many English language entries are missing a translations template. If it was added, via a bot or otherwise, then it would be a good driver to increased translation contributions. What do you think? --Spiros71 (talk) 15:41, 1 November 2021 (UTC)

 * I'm strongly opposed to this motion for two principal reasons:
 * Wiktionary systematically suffers from redundant translation boxes, a pet peeve of mine. They only lead to more potential for mistakes and a lower overall quality because a user might not find his desired translation in box on article A even though it would be present in B and C. For the latest example of this, refer to: flip the bird, flick off, flip off, give the finger
 * Adding missing translation boxes by a bot instead of organically by interested editors will lead to tons of very rare and specialized English terms having a translation box (and then sooner or later appearing in the translation request category) which in turn means that non-English editors would spend their time translating very rare words even though there is a lot of more urgent and more useful work to be done at the moment.
 * --Fytcha (talk) 21:47, 1 November 2021 (UTC)
 * I don't see why anybody should be forced to spend one's time translating rare words when they do not want to do it or why they should end up in translation request category by default. On the other hand, I can see many people finding it easier to add a translation if there is a translation box there for them and a great benefit of having extra translations in the long run.
 * The only way to fix the issue (1) you mentioned is by means of a multilingual concept-based thesaurus (in a sense, this is already applied in a rudimentary form in a number of cases where the reader is referred to another synonymous entry for translations). Still, I find it more useful to be able to access some translations for any of these entries, rather than having no translations at all. Spiros71 (talk) 07:34, 2 November 2021 (UTC)
 * "or why they should end up in translation request category by default." Because people correctly add for major languages, see e.g. Special:Contributions/Hippietrail. Fytcha (talk) 10:26, 2 November 2021 (UTC)
 * per Fytcha. PUC – 13:19, 2 November 2021 (UTC)

 * as well. Humans adding a translations template to entries that they find interesting / useful is one thing -- doing this by human or by bot to everything would be an exceedingly foolish move.  ‑‑ Eiríkr Útlendi │Tala við mig 19:10, 5 November 2021 (UTC)

 * Swedish Wiktionary has a gadget for this: sv:MediaWiki:Gadget-translation editor add section.js. It makes the job a lot easier than having to manually copy-and-paste the code for a new translation section. If such a gadget was optional (not activated by default), it would not really disturb anybody. --LA2 (talk) 20:04, 6 November 2021 (UTC)
 * Instead of automating it, there should be a way for editors to add translation boxes more easily than by manually typing out the code. I've been planning something like that for a while now, but have never gotten around to designing how it should work, let alone implementing it... — surjection ⟨??⟩ 21:24, 9 November 2021 (UTC)
 * FWIW, I would support any such tool or gadget to make it easier for a human to add a translations section. ‑‑ Eiríkr Útlendi │Tala við mig 18:59, 12 November 2021 (UTC)

Category:Klamath language
I tried to create this with the wikicode but it throws an error referring to. What needs to be done to fix this? User: The Ice Mage talk to meh 19:03, 5 November 2021 (UTC)
 * The language isn't present in the language data and needs to be added there before automatic categorization starts to work. — surjection ⟨??⟩ 21:19, 9 November 2021 (UTC)

Disentangling translation sections
Between trans-top and trans-bottom, there should be an alphabetically sorted list of language names. But what if there isn't? Does anybody have a bot script to check and fix such things? I'm currently trying to improve the translation sections on Turkish Wiktionary. As far as I can see, pywikibot doesn't have any ready-made code for it. --LA2 (talk) 20:11, 6 November 2021 (UTC)
 * If there isn't any code for it, it sounds pretty trivial -- get all lines between and, sort them alphabetically (dealing with nested lines if necessary) and, if there is a , place it in the middle. — surjection ⟨??⟩ 21:21, 9 November 2021 (UTC)
 * Well, the same routine can also check if "French:" is followed by ... and similar inconsistencies, and before you know it the trivial code is quite complex. So perhaps someone already wrote that and I don't have to design and maintain it all? LA2 (talk) 10:01, 10 November 2021 (UTC)

fiddling with dates
It would be pretty cool to get a list of all entries with quotations from a certain year, fiddling with. MooreDoor (talk) 22:25, 7 November 2021 (UTC)
 * I have added many quotations with markup on the first line (date inside quotes to bold it) and quote on the second line. I do that when the contextual information does not fit well into the quote templates with date arguments.  If we get automatic collection of dates by year, give me a date or something along those lines that enters the date into the same processing machinery and displays it in the standard format.  Also relevant to citations pages with timelines, which I never enable.  Vox Sciurorum (talk) 23:17, 7 November 2021 (UTC)
 * The main problem is that there are lots and lots of different templates that feed into quote-book, and they use a wide variety of positional and named parameters, so getting the information via examination of the entries would be very complicated. As for using code in the module itself: you could easily extract the year, but what would you do with it? You wouldn't want to use it in the name of a category, and I'm not sure you would want to sort the existing categories by date. It's true that the year tends to be displayed in a specific position in the output, but there would have to be some detectable, but non-displayed indication that the output in question comes from quote-book. Chuck Entz (talk) 00:16, 8 November 2021 (UTC)
 * Perhaps it could be used to do some data quality checks (books from the future, Modern English from the < 1500s etc.) – Jberkel 10:36, 8 November 2021 (UTC)

Icon for pdf links
Hello! why links to a pdf file show a logo-icon at wikipedias, but at wiktionaries show a colourless icon? e.g. a pdf file External_links#Rich_media] says "MediaWiki software will provide small icons for several types of outgoing links, such as the PDF" Thank you! ‑‑Sarri.greek ♫ | 10:25, 8 November 2021 (UTC)
 * It's a CSS stylesheet feature (?) that appears to be exclusive to en.wp (and possibly other pedias?). If needed, it's probably possible to copy and port it over into en.wikt. — surjection ⟨??⟩ 21:23, 9 November 2021 (UTC)

 * It would be good to have it, as that PDF symbol is quite recognisable. (Isn't it an Adobe trademark though?) Equinox ◑ 21:26, 9 November 2021 (UTC)
 * It is indeed. — surjection ⟨??⟩ 21:34, 9 November 2021 (UTC)

Talk:aereus edit disallowed and flagged as apammer behavior, please reverse
Hello,

My edit on Talk:aereus

"https://en.wiktionary.org/wiki/aerius lists āereus as an alternative form (and it seems this is supported elsewhere https://logeion.uchicago.edu/aerius ), but there's no mention of āereus here."

was automatically flagged as spam. The interface told me to submit the edit again to affirm that it is not spam; I did so and it was reverted. The interface also told me to go to Grease pit to report the incorrect flagging, so I have done so. Please now permit the edit and quickly remove the spammer-behaviour flag from my account. You can review my linked WP profile if you need to reassure yourself that I am not a spammer.

--RW Dutton (talk) 21:03, 9 November 2021 (UTC)
 * The abuse filter doesn't like new users adding external links (those with http(s): on them) to new pages because spammers tend to do that. In this case it's pretty obvious that it wasn't spam, but the abuse filter doesn't have the acumen of a human after all. There is no "spammer-behaviour flag"; the abuse filter prevented the edits from going through and added an entry in the abuse log. It's not directly possible to scrub entries from the abuse log, but I wouldn't worry too much about it - pretty much every user has something in the abuse filter log. — surjection ⟨??⟩ 21:13, 9 November 2021 (UTC)

Semicolon is an invalid title
The semicolon ; https://en.wiktionary.org/wiki/%3B redirects to the main page and Talk:; is a "Bad title". The semicolon page should be moved to Unsupported titles/Semicolon if this is not a fixable issue. – Nixinova [T|C] 03:17, 10 November 2021 (UTC)
 * This seems to have been somewhat of an issue for at least a year (link) but has since completely stopped being accessible. – Nixinova [T|C] 03:29, 10 November 2021 (UTC)
 * See also (my response: “ See Phabricator (“Pages whose title ends with semicolon  are intermittently inaccessible (likely due to ATS)”). Our temporary kludge is using redirects from “﹔” (e.g., in ). The other URL works (e.g., https://en.wiktionary.org/w/index.php?title=; ”). J3133 (talk) 07:39, 10 November 2021 (UTC)
 * This is what the Unsupported_titles/ prefix is for then, right? It should be moved if its an issue. – Nixinova [T|C] 20:51, 11 November 2021 (UTC)

Etymology template proposal
From browsing discussion pages, I have seen that etymology-section templates can be quite a hot-button issue at times. I certainly do not wish to add fuel to the fire, but I think it might be convenient to have one that adds entries to "Category:$LANGUAGE words derived through metathesis". The way I imagine it working would be, using a fictional example:
 * Derived through from.

=> (adds glossary link and category)
 * Derived through  from.

=> (displayed result)
 * Derived through from.

If something like this already exists, I would be interested to see it. Also, this could be a bad idea for some reason I'm not seeing, so I'd appreciate criticism too. I notice that Category:Words derived through metathesis by language only has subcategories for a few languages at present, so maybe some languages' editing communities prefer not to classify words in this way; that is fine by me.

Since the desired term to display may not be exactly "metathesis", but "metathesized" or some other form of the word, the template could accept other arguments that control the textual output, e.g. I imagine =>, for example.

We could also have ones for assimilation, dissimilation, etc., if desired, but I don't think those categories exist already (possibly for good reason?). 70.175.192.217 09:39, 12 November 2021 (UTC)

On wrapping entire definitions in
I know in the past this was strongly discouraged (due to the bad HTML it generated? I don't remember exactly). Is this still the case? Is it still the case even when doing adding other additional templates inside as in ? Looking for feedback. DTLHS (talk) 16:13, 12 November 2021 (UTC)
 * Why would one want to do that? The documentation for specifically excludes its use in running text. I wouldn't have thought any use of  is appropriate inside a definition, which is supposed to use exclusively terms considered English. DCDuring (talk) 17:18, 12 November 2021 (UTC)
 * In the case of [[zaagitować]] it seems to me that there are items that should be in usage labels, under a usage notes header, or possibly enclosed in . DCDuring (talk) 17:21, 12 November 2021 (UTC)
 * The reason me, along with other editors is 1) I wasn't aware we shouldn't be wrapping multiple 's in one . I saw other editors do it, and thought it saved on memory. I'm not sure why some of the other Polish editors do that. I also prefer it over 's as it gives me more control over which part of a page I can link to, but I suppose using multiple separate 's would be fine. Vininn126 (talk) 18:17, 12 November 2021 (UTC)
 * To be clear I was more interested in whether there was some technical problem with this rather than aesthetic considerations. DTLHS (talk) 18:22, 12 November 2021 (UTC)
 * All definitions at English Wiktionary are supposed to be entirely in terms that are acceptable as English. The only sections that should be referred to from definitions are parts of the English L2 section, eg. the numbered etymology sections, and the PoS sections. Also specific definitions can be referenced using . Template offers no shortcut to achieve those results. DCDuring (talk) 21:55, 12 November 2021 (UTC)

 * I tend to remove this. If we need to force all entry text into an explicit English-language context, then merely doing the definitions isn't enough anyway: what about picture captions, Examples boxes, etc.? Equinox ◑ 21:58, 12 November 2021 (UTC)
 * I am not sure I understand what you mean.
 * Usage examples and citations in non-English L2s are supposed to be translated into English. It is easy to argue that the same should apply whenever usage-box contexts or images are less than self-explanatory for a level-1 (level-0?) student of the language. DCDuring (talk) 22:15, 12 November 2021 (UTC)

 * I meant when people do this in the English section (not uncommon). Equinox ◑ 22:25, 12 November 2021 (UTC)

 * The issue isn't putting words into English terms. This is a small, but say the lemma of the foreign word and the English word are the same, or perhaps the target page shares multiple languages. It's nice for the page to be automatically sent to the english section, rather than the top of the page. Vininn126 (talk) 22:23, 12 November 2021 (UTC)

nocat=1 in
Why are and  categorized as "Latin terms derived from Vulgar Latin" although I used the nocat-parameter in the com-template? --Akletos (talk) 09:58, 13 November 2021 (UTC)

 * Because of the * present in both. inherited is a subcategory of derived. Fytcha (talk) 18:54, 13 November 2021 (UTC)
 * That's the source of the "Galician terms derived from Vulgar Latin", but "Latin terms derived from Vulgar Latin" came from . — Eru·tuon 19:16, 13 November 2021 (UTC)
 * Oh my bad. I've missed that somehow, probably because you've fixed the articles already when I was looking for the "derived" categories in them. Fytcha (talk) 19:19, 13 November 2021 (UTC)
 * nocat doesn't disable derived-from categories. In this case I disabled the category by removing the "Vulgar Latin" label from one of the components because both are Vulgar Latin, but this problem may pop up elsewhere so I suppose it needs a solution... — Eru·tuon 18:57, 13 November 2021 (UTC)
 * A number of other cases in this list. (The name and parameters are listed in Lua syntax.) — Eru·tuon 19:17, 13 November 2021 (UTC)
 * Is this and this the way to solve this problem? Akletos (talk) 10:54, 18 November 2021 (UTC)
 * I finally looked at your links and it doesn't seem a good solution because the template shows the language name that the word is derived from, which should be implied. — Eru·tuon 20:25, 29 November 2021 (UTC)
 * Could you run another search with this specifics and search especially for pages where the 2nd-parameter-language differs from the L2-header? There were some false positives in your list, but I think I cleaned up the pages with wrong categorisations. Akletos (talk) 17:48, 25 November 2021 (UTC)
 * Possibly, but it's not as straightforward because my files list the templates without the headers. — Eru·tuon 03:25, 27 November 2021 (UTC)
 * New list here, but I didn't try to do the header thing. — Eru·tuon 20:41, 29 November 2021 (UTC)
 * I couldn't find any wrong categorisation in the list, so for now the problem seems to have been solved. Thanks for your help, @Erutuon. Akletos (talk) 14:42, 1 December 2021 (UTC)

Category Trees
Right now, if you want to add a topical category related to a node on the set category tree, you have to find a place for it on the topical category tree, which is organized completely differently. Just to see what would happen, I created the topical category Category:Flax and its language-specific category Category:en:Flax. There are lots of specialized terms related to flax farming, harvesting, and processing, as well as various things made out of flax, so I was able to fill it in no time.

I placed it under Category:Agriculture, but terms like linseed oil, linen and flax milk aren't really agricultural. If I created categories under Category:Tools, Category:Fibers, Category:Textiles, Category:Spinning, Category:Weaving, or even Category:Crafts, they would all have only a few members each, and the fact that these are all part of the path of a single organism from farm to factory to use gets lost.

I created three maize-related categories a while back: Category:Maize (plant), Category:Maize (food), and Category:Maize (crop), and they worked reasonably well for English- but maize has a huge and comprehensive vocabulary, which is why I chose it as a test case.

Likewise, if I placed Category:Flax in the set-category tree, I would be expected to limit it to terms for plants in the genus Linum, or perhaps the family Linaceae.

It seems to me that the problem stems from rigorous separation of the topical and set trees. I'm not saying that it's impossible to link topical and set categories to each other, or that, conversely, we should merge the topical and set trees. What I'm saying is that we should figure out some way to allow some topical categories to be part of the set-category tree instead of the topical-category tree.

As it is, we have a number of set categories that are being used as topical categories, even though they technically shouldn't. We also have cases like Category:Reindeers, which are failures as set categories (no language has more than 9 members, and most have only 1 or 2), but could be linked to lots of related terms. This one is particularly sad because it was added with the comment "Reindeers added, so that the ridiculous amount of reindeer-related vocabulary of Chukotkan can be covered", but seems to be the only example of such a term being in any of the subcategories. It's true that there aren't many words in all of Category:Chukchi lemmas, but Category:ckt:Reindeers has exactly the same number as Category:vi:Reindeers- which really shouldn't exist (Vietnam isn't known for the depth of its reindeer vocabulary).

Sorry for the wall of text, but I work a lot with categories, so it's hard to not get caught up in the details. Chuck Entz (talk) 02:27, 14 November 2021 (UTC)

An update on IP Masking implementation
Hello friends!

We have new information on IP Masking for you. Thank you for being patient as the project unfolds.

IP masking hides the IP addresses of unregistered editors on Wikimedia projects, fully or partially, from everyone except those who need access to fight spam, vandalism, harassment and disinformation.

So far, we have had conversations on why we are masking IPs and the tools you will need to continue fighting abuse. What is up next is, we want to share with you details about the implementation itself.

This update answers some likely questions you may have about who gets to view IP addresses and the various IP Masking implementation approaches and how each of them will impact the communities.

Please see this section for the latest information.

If you need a background on IP Masking, there’s a summary here for you.

–––

Best regards,

STei (WMF) (talk) 15:01, 15 November 2021 (UTC), on behalf of the Anti-Harassment Tools team.

Modifying Template:ws to accept separately linked parts
Currently, the phrase "big-dicked" is listed at Thesaurus:macrophallic. The code used is  and the outer square brackets are displayed. This is not what intended. Can someone modify the template so that the outer brackets do not display? Thanks and take care. —The Editor's Apprentice (talk) 06:48, 18 November 2021 (UTC)

Macedonian terms with red link in their headword lines - not populating
Hello,

I tried to create the category Category:Macedonian terms with red links in their headword lines with but it is empty, even though the Romanian and the Welsh equivalents, also created with that template, contain a great deal of pages. Could someone modify the relevant code so that the category gets populated? Thank you in advance. Martin123xyz (talk) 14:05, 18 November 2021 (UTC)
 * It looks like this type of category is added by the various language-specific headword templates (see this search for a list). I wonder if it would be worth the increased overhead to add this code to Module:headword (or whichever module handles the list of items after the headword) and have a list in a data module (Module:headword/data?) of languages to categorize this way. It seems like the code that does this is very similar across languages, so it would be easy to centralize. That way it wouldn't be restricted to just languages with their own headword modules, and it would require less programming to add this feature to new languages. Chuck Entz (talk) 15:22, 18 November 2021 (UTC)

Certain Wikt shortcut keys don't work in latest Chrome on Win10/64
These advertised shortcut keys work correctly:

 * Alt+Shift+E = edit.
 * Alt+Shift+D = delete.
 * Alt+Shift+M = move.
 * Alt+Shift+W = (un)watch.

These have no effect (I can't remember if they worked before):

 * Alt+Shift+H = history.
 * Alt+Shift+= = change protection.

Equinox ◑ 03:19, 20 November 2021 (UTC)

Label "misuse" for some Indonesian/Classical Malay terms
There seem to be certain Indonesian entries where the language code in lb is intentionally misused, e.g. cakrawati. I don't think we should do this; it should probably rather be id but that currently does not link nor categorize correctly. as the creator. Fytcha (talk) 23:06, 20 November 2021 (UTC)

 * Noted. The will be the ideal solution, but I have no knowledge to change the technical stuff. -- Xbypass (talk) 00:32, 21 November 2021 (UTC)
 * It's a bit confusing, though. If we're treating Indonesian as independent from Malay, then Classical Malay is a different language, something to be noted in the etymology. You would use a label to describe something different about this class of terms in Indonesian. What exactly is that difference? Chuck Entz (talk) 02:43, 21 November 2021 (UTC)
 * This is in indeed tricky. Indonesian has been developed out of Standard Malay and is basically the same thing, but has quite diverged lexically and slightly also structurally from the Standard Malay of Malaysia/Singapore/Brunei. Nevertheless, both major standards consider Classical Malay as their shared heritage. So the complete lexicon of Classical Malay has been integrated into the Indonesian lexicon and is listed in the Kamus Besar Bahasa Indonesia. The actual question however is: is the word cakrawati actually attested in Indonesian writing? If it is, "Classical Malay" is probably not the apt label, but rather usage- and style-related labels like "archaic", "literary" etc. WT has usage-related criteria for inclusion, so it's not enough when "young" languages (like Indonesian or Modern Standard Hindi) in theory incorporate the lexicon of an older literary canon (here: Classical Malay or Urdu), but do not make full use of it in attested practice. –Austronesier (talk) 17:41, 22 November 2021 (UTC)

Help needed with a translit module
When I asked on 's talk page about a module error at Luzon, they told me they had been unable to figure out what was wrong. The problem is at Module:tl-translit and the script is the Old Tagalog version of  (a simple abugida with vowel diacritics on consonants). It looks like it should be a simple fix, but I have no clue. Chuck Entz (talk) 15:22, 22 November 2021 (UTC)

 * @Chuck Entz I already fixed the module, the problem has something to do with the combining diacritics (I, U and virama marks) since I created the module on mobile. I finally fixed it from my desktop. TagaSanPedroAko (talk) 07:25, 23 November 2021 (UTC)

Italics in page titles
Wikipedia supports italics in page titles through Italic title or DISPLAYTITLE, but these do not exist at Wiktionary. Would it be possible to copy them over? I would like to use italics at dummy it, which ought to read dummy it, and others similar. While template DISPLAYTITLE apparently does not exist, DISPLAYTITLE:some text is recognised at Wiktionary but effectively not allowed, producing only the error message "Display title 'some text' was ignored since it is not equivalent to the page's actual title." Mihia (talk) 12:06, 24 November 2021 (UTC)
 * Sorry, scratch that request. Because DISPLAYTITLE:some text didn't work, I assumed the whole feature was switched off or disabled, but actually when I change it to DISPLAYTITLE:dummy it it does work, recognising this as the same as the page title apart from formatting, I suppose. Good. Mihia (talk) 16:13, 24 November 2021 (UTC)
 * How would this work in cases where there is a Translingual L2 (eg, a taxonomic genus name like Rosa) and, say, an English, German, or Latin L2? And in some cases a Latin word might be italicized when used as a specific epithet but not in normal Latin text. DCDuring (talk) 16:45, 24 November 2021 (UTC)
 * Where multiple uses exist, some italicised and others not, I guess the title would have to be in plain text. To some extent this is even true of "dummy it", where of course "dummy it" theoretically exists as "&lit", describing e.g. what a footballer might do. This did occur to me, but it seemed over-fussy to mention it. Mihia (talk) 18:43, 24 November 2021 (UTC)

 * We will have to encourage our "duuumb" users not to create italicised pages for "emphatic form of...", like "really". Equinox ◑ 17:18, 30 November 2021 (UTC)
 * It would be simpler to just forswear the use of for italics or much of anything else in principal namespace. DCDuring (talk) 17:27, 30 November 2021 (UTC)

Old Tagalog not an ancestor of Tagalog?
I've tried to do which didn't work because the module data didn't agree. As far as I understand the situation, Proto-Philippine evolved into Old Tagalog which evolved into Classical Tagalog which in turn evolved into Modern Tagalog. If this is the case, we should reflect this in our module data. See also this search query:  --Fytcha (talk) 18:52, 24 November 2021 (UTC)
 * Chuck Entz (talk) 19:58, 24 November 2021 (UTC)
 * I don't get what the difference between Old and Classical Tagalog is supposed to be. Pre-colonial Tagalog is not attested, but there's been a stubborn held folk belief that yet somewhere it is (e.g. in the Laguna Copperplate Inscription, which is however all Old Malay and only contains a handful of local toponyms with known modern Tagalog equivalents). There is something we might call "early" Tagalog, which is the language recorded by the Spanish friars in the 16th and 17th century. But this language is essentially the same as contemporary Tagalog, with a few archaic features in morphology, e.g. the infix which is AFAIK not found in any modern dialect, and a preference for certain southern dialectal features (e.g.  /ŋayˈʔon/ instead of northern=standard  /ŋaˈyon/. This is equivalent to early Modern English having things like -eth, non-auxiliary negation (thou knowest not) etc. Since we don't have a separate code for that period of English, I'd actually suggest to do same thing for Tagalog and simply deprecate Old and Classical Tagalog. Labels like "archaic" would also do.  –Austronesier (talk) 20:56, 24 November 2021 (UTC)
 * For Classical Tagalog, definitely. As far as I know, it was only that added Classical Tagalog in etymologies, but there's not much difference at all, like early modern English and modern English, still modern English. As for Old Tagalog, there's no attestation of it, so there seems to be no point in using it. --Mar vin kaiser (talk) 23:35, 24 November 2021 (UTC)
 * The Komisyon sa Wikang Filipino do use "Sinaunang Tagalog” (ST, or Ancient or Old Tagalog) in the etymology of entries in its official dictionary for Tagalog as well as the other languages of the Philippines, but I would second that except for vocabulary, I would agree doing away with Old and Classic Tagalog as just stages of the present language, making use of labels where appropriate. In regard to the earliest documented form of Tagalog such as those in the Vocabulario de la lengua tagala and Doctrina christiana, they're the nearest to something like Old Tagalog, but I would still think Tagalog could already been the present form – albeit with its prestige variety still being based on dialects spoken in the provinces of Batangas, Quezon and Marinduque – at the time of early contact of ancient Tagalog polities with Malay, Persian, Arab and Chinese maritime traders. In short, Tagalog split off the reconstructed Proto-Philippine language without even undergoing intermediate stages from a proto-language.-TagaSanPedroAko (talk) 01:00, 25 November 2021 (UTC)
 * I would be surprised if there weren't intermediate stages, but they weren't attested and with only the one descendent we can't use the comparative method to reconstruct anything. There's no point in mentioning something in etymologies that we know absolutely nothing about- not even how many intermediate lects there were.
 * As for the relationship between modern and Old Tagalog, one way to reflect this would be to make Old Tagalog an etymology-only language: if you try to link to it using a template like tl-old or tl-old or use use it in a headword template like tl-old, you'll get an error. You can, however, use it in etymology templates like tl, but as a synonym of the main language: it will display "Old Tagalog" and the categories will say "from Old Tagalog", but the template will link to the "Tagalog" section of the target entry, and the modules will in all other ways treat it just like you used a "tl" code. The only drawback is that you won't be able to use tl in Tagalog entries because we don't allow languages to inherit from themselves. Chuck Entz (talk) 02:16, 25 November 2021 (UTC)
 * Actually, there are two intermediate subgroups to which Tagalog belongs: Philippine > Greater Central Philippine (GCPh) > Central Philippine (CPh) > Tagalog. There is little or no debate surrounding these subgroups, and Proto-GCPh and Proto-CPh have been partially reconstructed. There's probably little need to introduce them here in the ancestor tree. The development from Proto-CPh to Tagalog only involved a few slight sound changes:
 * 1. *ə > i (or u in certain environments)
 * 2. Sporadic loss of *l
 * 3. *d > l in intervocalic position
 * 4. Loss of *ʔ before consonant with compensatory lengthening
 * Attested archaic Tagalog already had undergone all these sound changes. So if we define Old Tagalog as a reconstructed stage before the historical record sets in, it would be identical to Proto-CPh itself, unless we make speculative assumptions about the order of the sound changes and reconstruct a stage which only partially had undergone these sound changes. –Austronesier (talk) 11:12, 25 November 2021 (UTC)

Edit conflicts when adding translations?
See. Is it possible to implement some kind of mechanism to prevent edit conflicts when using the translation box interface?

Furthermore, as patrollers don't always check the contents of an edit as long as they come with an edit summary like (t+es: (Assisted)), can we implement an abuse filter if the edit contains more than just the addition of the translations in the summary? Something like translation-assisted-lier akin to typo-lier. Fytcha (talk) 15:57, 25 November 2021 (UTC)

 * Again:, , Fytcha (talk) 13:39, 5 January 2022 (UTC)
 * An abuse filter like translation-assisted-lier is a great idea; I do not check the contents of those edits with the translations summary unless it is pertaining to any language I know about. But, are there any instances of abuse of this edit summary for edits that are vandal/disruptive, so that we are sure we need this? —Svārtava [t•c•u•r] 15:20, 5 January 2022 (UTC)
 * I am not aware of any malicious uses of this, though all the aforementioned edit conflicts would trigger such a filter likewise (because other contents are being removed in the same edit that is only supposed to add translations). Fytcha (talk) 17:17, 5 January 2022 (UTC)

Module error caused by strange interaction of templates/modules
There are four Japanese entries (からかう, 巨人, 憂鬱, and 新案) that have module errors where w is used to provide the Japanese text in ja-usex or ja-usex-inline (mostly due to edits a couple of years ago by, but that's irrelevant to the problem itself). I went through the edit histories of the first three entries and of their entire transclusion lists, and the only change in the past week that seems to have any bearing is 's edit to w which added apparently empty <nowiki></nowiki> pairs at the beginning and end of the transcluded template code.

For example, at からかう, the wikitext:

displays this error message:

 * Lua error in Module:ja-ruby at line 590: Can not match "『'"`UNIQ--nowiki-00000000-QINU`"'からかい 上" and "『からかい じょう"

The "UNIQ--nowiki-00000000-QINU" seems to be some kind of test string, possibly generated by Javascript- I did a lot of previews with various things commented out, and the 8-digit number incremented several times.

 * I should also mention that I had to remove a couple of odd characters from the copypasted error message above to keep something from substituting snippets of wikitext for parts of the error message:

 * Lua error in Module:ja-ruby at line 590: Can not match "『 ... からかい 上" and "『からかい じょう"

 * I'm not sure if some of the odd display behavior is due to some gadget I have enabled, though the module errors wouldn't be in CAT:E if it were all due to a gadget. I'm guessing that this is at least partly due to something in the common.css that provides proper display of the kanji/ruby interlinear text, and possibly something normally active only during module tests

At any rate, Module:ja-ruby works by assembling an interlinear two-line display text from a kanji text parameter and a kana text parameter. Somewhere in the line of template and module calls here something is mis-parsing the output of the w template. If I comment out all of the w template syntax and leave just the text of w's display-text parameter, the error goes away- so it seems to be something added by the transclusion of the w template, not the text itself.

Obviously, I don't completely understand any of the templates, modules, css or javascript that are interacting here, so I could be entirely mistaken in any or all of my assumptions. All I know is that this started happening yesterday, and it needs to be fixed. Also pinging, who is familiar with the Japanese templates and modules in question, and , who are familiar with other parts of the infrastructure involved. Chuck Entz (talk) 22:32, 26 November 2021 (UTC)

Update: Searching for ja-usex|{{w|, ja-usex|『{{w| and ja-usex-inline|{{w| turns up 8 entries: 科学, 憂鬱, 仮名遣い, ウオッチ, 新案; からかう and 巨人, 守り人. All of these display the module error when you view the page, but not all can be seen on the CAT:E page- yet. Chuck Entz (talk) 01:31, 27 November 2021 (UTC)

 * I had requested the nowiki tag change, to improve the function of the template. For example when the w template was put inside square brackets, like  it wouldn't work; I intended to solve this through the nowiki tags. For now the error pages have been fixed, w replaced with  . —Svārtava [t•c•u•r] 02:23, 27 November 2021 (UTC)

 * {{re|Chuck Entz}} The UNIQ text is some MediaWiki feature (Strip marker) to prevent Lua code from mucking with nowiki contents unless the code specifically asks for its decoding (mw:Extension:Scribunto/Lua reference manual). —Suzukaze-c (talk) 03:14, 28 November 2021 (UTC)
 * Strip marker mentions that they're "available to Lua", so it looks like we need to make {{tl|ja-ruby}} strip the strip markers. Although I notice that it also says:

{{blockquote|text=Strip markers can be exposed when badly-formed code causes the parser to be reset, and lose its memory of which strip marker corresponds to which piece of special content. }}
 * Perhaps we need to look for something else wrong with w that messed up the parsing before the nowikis were added. The nowikis were added in the first place because something didn't seem to be working right, which should raise some red flags.
 * At any rate, the problem hasn't been fixed, it's just been bypassed by hand. There are still module errors due to other templates with w in parameters, and more will eventually crop up in the process of normal editing. Chuck Entz (talk) 06:17, 28 November 2021 (UTC)
 * Re: "it looks like we need to make {{temp|ja-ruby}} strip the strip markers": If by "strip" you mean "remove", then that has the downside that it would also strip any non-empty use of <nowiki>…</nowiki>. (Though maybe we just need to have the module ignore the strip markers when aligning the two strings, but have it still include them in the rendered result? That doesn't seem too hard.)
 * Do we know why {{user|Imetsia}} made this change to {{temp|w}}? I agree that it's worth looking into whether this is the right way to solve the underlying problem . . . but it's possible that it is the right way to solve the underlying problem; and really, as long as {{temp|ja-usex}} does this much parsing of wikitext, I think we can expect these sorts of problems to continue to crop up. :-/
 * —Ruakh <i >TALK</i > 03:51, 29 November 2021 (UTC)
 * Update: I did some more experimenting, to see the differences caused by the nowikis and the safesubst wrapped in noinclude tags:
 * [wikitable commented out because test templates were deleted, causing module errors]

 * 1) w is the current version, with both the nowikis and the safesubst wrapped in noinclude tags
 * 2) {{tl|w-test}} is a copy of the version of w before last week's edit, without the nowikis, but with the safesubst wrapped in noinclude tags.
 * 3) {{tl|w-test-1}} has both the nowikis and the safesubst wrapped in noinclude tags removed
 * 4) {{tl|w-test-2}} has the nowikis, but not the safesubst wrapped in noinclude tags
 * Before I did this, I was convinced that there was something wrong with the safesubst wrapped in noinclude tags syntax that was causing both the problems. I was wrong. Apparently the square brackets problem is simple the result of three square brackets: Transclusion] gives Transclusion], but [ w|Transclusion ] (with spaces) gives [ w|Transclusion ].

 * So, where does that leave us? We can't have all the Japanese templates with ruby support blowing up every time someone uses {{tl|w}} in one of its parameters. As I see it we have three options:

 * 1) Take out the nowikis. The three-square-bracket problem has been there for the past 16 years and we somehow managed to survive without wrapping a wikipedia link in single square brackets. In fact, any template that produces a simple wikilink will behave the same way when wrapped in single square brackets.
 * 2) Find some other way of preventing the dread three-square-bracket problem that ja-ruby won't choke on.
 * 3) Add code to ja-ruby that looks for and removes any substring that starts with a \127'"`UNIQ and ends with QINU`"'\127

 * This has gone on long enough. If it isn't resolved within a week, I'll do the only thing I know how to do myself, which is the first option. Chuck Entz (talk) 11:29, 30 November 2021 (UTC)
 * {{u|Chuck Entz}} Oh I see, the [] problem is nothing specific to this template. No page apparently starts with  so if it can be fixed, in Benwing2|Erutuon|Surjection}}: notifying interface admins) —<u style="color:#E21F1F; font-variant:small-caps; font-size:120%;">Svārtava <sup style="font-size:80%;">[[[m:wikt:User talk:Svartava2|t•c•u•r] 17:19, 1 December 2021 (UTC)

Redlinked form-of entries
Redlinked form-of entries are often left behind when entries fail RFV or RFD, or are otherwise reflective of incompleteness in the dictionary. Is there some kind of tracking category or template for these? And how about form-of entries where the linked entry does not have the correct language section? This, that and the other (talk) 04:02, 27 November 2021 (UTC)
 * I'm not exactly an expert on the system here, but I do know that running code on every page load to track things that only change every once in a while is poor practice. I doubt that checking for redlinks in a few templates is going to push anything over the expensive-parser-function limits, but I don't know of any way to check for missing language sections without loading stuff from the other entry into Lua memory- and we're already close to or over the memory limit on a number of pages. This sounds more like something to generate from the dumps every once in a long while. Of course, that's easy for me to say, since I won't be the one to do it. Chuck Entz (talk) 07:08, 28 November 2021 (UTC)
 * Between August 2010 and April of 2011, as you can read on user:LA2, I extracted from the XML dump all calls to Swedish inflection templates and deduced (offline) which form entries should exist (e.g. if page "bil" called template sv-noun-ar, form entries for "bilen" and "bilar" should exist, linking back to "bil"). Then I compared this list to existing form entries found in the same XML dump and the result was a to-do list, in part for a bot job, in part for manual edits. It was a lot of work and took several weeks. It felt good. But it was a craft and I've not heard of any standard tools for this. LA2 (talk) 10:01, 29 November 2021 (UTC)
 * To Chuck's point, the best place to do this would be on the Toolforge, where it could use replicas to periodically check for and report such orphaned pages. - TheDaveRoss  14:57, 29 November 2021 (UTC)
 * I'm not convinced Toolforge replicas can do it; after all, I'm looking for links generated by specific templates. I think Chuck is right, this looks like a dumps job. This, that and the other (talk) 08:38, 4 December 2021 (UTC)
 * The problem seems to result from admins not quite following process. At Page_deletion_guidelines, Pont 2, it says, "Click on [i]What links here[/i] and fix any links that are going to be broken. Remember not all red links are undesirable".  Or do we need to expand this part of the check list? --RichardW57m (talk) 14:23, 30 November 2021 (UTC)

Tool wanted for interwiki-linking subcategories
A typically case: On Swedish Wiktionary, I create a category for Turkish words for chemistry. It is a subcategory of chemistry, which is already interwiki-linked to English Wiktionary's Category:Chemistry, which has a subcategory Category:tr:Chemistry for Turkish words for Chemistry. That subcategory should now be interwiki-linked (through Wikidata) to the new category on Swedish Wiktionary. Is there any tool that can automate this task? Also, is there any tool that can check if all the language-specific subcategories to Chemistry are correctly interwiki-linked? --LA2 (talk) 23:09, 28 November 2021 (UTC)

like to know the procedure for uploading list of words
hi,

we are working in Tamil-English dictionary project. we like to upload the words in wiktionary for public use for free. our content has our one copy rights.

we try to upload the words one by one its taking more time, we have more then one lack words.

we like to know the procedure for uploading list of words in wiktionary.

Do the needful ASAP.

Thank you,

Massive Category-Error Overkill
Someone just added a label to one module that already existed in another. This caused module errors in what seems to be- literally- every single category. By the time I undid the edit, 33 minutes later, there were more than 4,800 categories in CAT:E, including cities, counties, villages, etc. in just about every place, art, birds, bodily fluids, conifers, Dieri language, East Slavic Languages, Esperanto phrasebook/Family, Requests for etymologies in Yosondúa Mixtec entries, greetings hunting, military, wind, etc. Perhaps not etymological or grammatical categories, but so many that there are still over 2,400 categories an hour after I undid the edit- and the number has even started to increase slightly.

At any rate, do we really want to display errors everywhere for something that involves only one category in two modules? The person who made the mistake would have seen no sign that anything was wrong, but someone looking for municipalities in Liechtenstein would be told that "Mass media" was defined in both Module:category tree/topic cat/data/Communication and Module:category tree/topic cat/data/Culture.

Granted, this is more of a problem with appearance than function, but we should be making our infrastructure robust, not so all of it it collapses into screaming hysterics over a single edit. Chuck Entz (talk) 15:58, 30 November 2021 (UTC)
 * I've added a bit of code to Module:documentation to display the error message on the topic cat module pages so that people will have better chance of noticing that they added a duplicate label and removing it. It might be worth disabling the error on category pages entirely and adding similar code on other category tree submodules. — Eru·tuon 17:26, 1 December 2021 (UTC)
 * It's important to throw an error so these problems get fixed, but I agree that maybe this could be made smarter so it throws an error e.g. on module pages but not on category pages, or something. Benwing2 (talk) 04:07, 2 December 2021 (UTC)

Tabs at the top of templates?
I've just created gsw-adverbs_of_place and now I want to include different dialects of gsw in this box. There is quite a bit of regional variance going on for these terms as can be seen in the alternative forms of e.g., so listing them all under each other in each cell is out of the question. I wanted to have tabs at the top of the table (similar to this but without changing pages) but I don't know how to do it. Is this technically possible? as an active gsw contributor.

Side remark: Please don't use this template for the time being and please don't create entries for the lemmas in the template (some things might still change, especially the spaces). Fytcha (talk) 18:31, 30 November 2021 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Wiktionary:Grease pit/2021/November


text:
ᎧᏬᎳᏕᎠ

Verb

 * 1) he/she/it is breathing

title: ᎧᏬᎳᏕᎠ