Wiktionary:Grease pit/2021/November

From Wiktionary, the free dictionary
Jump to navigation Jump to search

Automatically add translations template?[edit]

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

I'm strongly opposed to this motion for two principal reasons:
  1. 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
  2. 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)[reply]
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)[reply]
"or why they should end up in translation request category by default." Because people correctly add {{t-needed}} for major languages, see e.g. Special:Contributions/Hippietrail. Fytcha (talk) 10:26, 2 November 2021 (UTC)[reply]
Oppose per Fytcha. PUC – 13:19, 2 November 2021 (UTC)[reply]
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)[reply]
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)[reply]

Category:Klamath language[edit]

I tried to create this with the wikicode {{auto cat|the United States|extinct=1}} but it throws an error referring to {{topic cat}}. What needs to be done to fix this? User: The Ice Mage talk to meh 19:03, 5 November 2021 (UTC)[reply]

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

Disentangling translation sections[edit]

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

If there isn't any code for it, it sounds pretty trivial -- get all lines between {{trans-top}} and {{trans-bottom}}, sort them alphabetically (dealing with nested lines if necessary) and, if there is a {{trans-mid}}, place it in the middle. — surjection ⟨??⟩ 21:21, 9 November 2021 (UTC)[reply]
Well, the same routine can also check if "French:" is followed by {{t|fi|...}} 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)[reply]

fiddling with dates[edit]

It would be pretty cool to get a list of all entries with quotations from a certain year, fiddling with {{quote-book}}. MooreDoor (talk) 22:25, 7 November 2021 (UTC)[reply]

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

Icon for pdf links[edit]

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

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)[reply]
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)[reply]
It is indeed. — surjection ⟨??⟩ 21:34, 9 November 2021 (UTC)[reply]

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

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

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

Semicolon is an invalid title[edit]

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

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)[reply]
See also Wiktionary:Grease pit/2021/June § can't get to talk:; (semicolon) (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 {{punctuation}}). The other URL works (e.g., https://en.wiktionary.org/w/index.php?title=;”). J3133 (talk) 07:39, 10 November 2021 (UTC)[reply]
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)[reply]

Etymology template proposal[edit]

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:

kaboom: Derived through {{metathesis|en}} from Proto-Germanic *bakoom.

=> (adds glossary link and category)

kaboom: Derived through {{glossary|metathesis}}[[Category:English words derived through metathesis]] from Proto-Germanic *bakoom.

=> (displayed result)

kaboom: Derived through metathesis from Proto-Germanic *bakoom.

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 {{metathesis|en|metathesized}} => metathesized, 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)[reply]

On wrapping entire definitions in {{l|en}}[edit]

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 {{l}} as in zaagitować? Looking for feedback. DTLHS (talk) 16:13, 12 November 2021 (UTC)[reply]

Why would one want to do that? The documentation for {{l}} specifically excludes its use in running text. I wouldn't have thought any use of {{l}} is appropriate inside a definition, which is supposed to use exclusively terms considered English. DCDuring (talk) 17:18, 12 November 2021 (UTC)[reply]
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 {{non-gloss}} ({{n-g}}). DCDuring (talk) 17:21, 12 November 2021 (UTC)[reply]
The reason me, along with other editors is 1) I wasn't aware we shouldn't be wrapping multiple [[]]'s in one {{l}}. 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 {{l}}'s would be fine. Vininn126 (talk) 18:17, 12 November 2021 (UTC)[reply]
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)[reply]
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 {{senseid}}. Template {{l}} offers no shortcut to achieve those results. DCDuring (talk) 21:55, 12 November 2021 (UTC)[reply]
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)[reply]
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)[reply]
I meant when people do this in the English section (not uncommon). Equinox ◑ 22:25, 12 November 2021 (UTC)[reply]
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)[reply]

nocat=1 in {{com}}[edit]

Why are Galician esfachar and Old French esfacier 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)[reply]

@Akletos: Because of the {{inh|*|VL.}} present in both. inherited is a subcategory of derived. Fytcha (talk) 18:54, 13 November 2021 (UTC)[reply]
That's the source of the "Galician terms derived from Vulgar Latin", but "Latin terms derived from Vulgar Latin" came from {{com|la|ex-|*facia|lang2=VL.|nocat=1|t2=face}}. — Eru·tuon 19:16, 13 November 2021 (UTC)[reply]
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)[reply]
|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)[reply]
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)[reply]
Is this and this the way to solve this problem? Akletos (talk) 10:54, 18 November 2021 (UTC)[reply]
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)[reply]
@Erutuon 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)[reply]
@Akletos: Possibly, but it's not as straightforward because my files list the templates without the headers. — Eru·tuon 03:25, 27 November 2021 (UTC)[reply]
New list here, but I didn't try to do the header thing. — Eru·tuon 20:41, 29 November 2021 (UTC)[reply]
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)[reply]

Category Trees[edit]

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 Chukchi ӄораӈы 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)[reply]

An update on IP Masking implementation[edit]

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

Modifying Template:ws to accept separately linked parts[edit]

Currently, the phrase "big-dicked" is listed at Thesaurus:macrophallic. The code used is {{ws|[[big]]-[[dicked]]}} 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)[reply]

Macedonian terms with red link in their headword lines - not populating[edit]

Hello,

I tried to create the category Category:Macedonian terms with red links in their headword lines with {{auto cat}} 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)[reply]

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

Certain Wikt shortcut keys don't work in latest Chrome on Win10/64[edit]

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

Label "misuse" for some Indonesian/Classical Malay terms[edit]

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 {{lb|id|Classical Malay}} but that currently does not link nor categorize correctly. @Xbypass as the creator. Fytcha (talk) 23:06, 20 November 2021 (UTC)[reply]

Noted. The {{lb|id|Classical Malay}} will be the ideal solution, but I have no knowledge to change the technical stuff. --Xbypass (talk) 00:32, 21 November 2021 (UTC)[reply]
@Xbypass 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)[reply]
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)[reply]

Help needed with a translit module[edit]

When I asked on @TagaSanPedroAko'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 Baybayin (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)[reply]

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

Italics in page titles[edit]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
It would be simpler to just forswear the use of {{DISPLAYTITLE:*}} for italics or much of anything else in principal namespace. DCDuring (talk) 17:27, 30 November 2021 (UTC)[reply]

Old Tagalog not an ancestor of Tagalog?[edit]

I've tried to do this change 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: [1] @TagaSanPedroAko, Chuck Entz --Fytcha (talk) 18:52, 24 November 2021 (UTC)[reply]

@Austronesier Chuck Entz (talk) 19:58, 24 November 2021 (UTC)[reply]
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 -ungm- which is AFAIK not found in any modern dialect, and a preference for certain southern dialectal features (e.g. ngay-on /ŋayˈʔon/ instead of northern=standard ngayon /ŋ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. @Mar vin kaiser –Austronesier (talk) 20:56, 24 November 2021 (UTC)[reply]
For Classical Tagalog, definitely. As far as I know, it was only @Mlgc1998 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)[reply]
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)[reply]
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 {{l|tl-old}} or {{m|tl-old}} or use use it in a headword template like {{head|tl-old}}, you'll get an error. You can, however, use it in etymology templates like {{der|tl|tl-old}}, 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 {{inh|tl|tl-old}} in Tagalog entries because we don't allow languages to inherit from themselves. Chuck Entz (talk) 02:16, 25 November 2021 (UTC)[reply]
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)[reply]

Edit conflicts when adding translations?[edit]

See diff. 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:inconmovible (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)[reply]

Again: diff, diff, diff Fytcha (talk) 13:39, 5 January 2022 (UTC)[reply]
@Fytcha: 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)[reply]
@Svartava2: 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)[reply]

Module error caused by strange interaction of templates/modules[edit]

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 @Poketalker, 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 @Imetsia'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:

  • {{ja-usex|『{{w|lang=ja|からかい上手の高木さん|'''からかい''' 上%手 の 高%木さん}}』|『'''^からかい''' じょう%ず の たか%ぎ-さん』|rom={{w|Karakai Jozu no Takagi-san|'''Karakai''' Jōzu no Takagi-san}}|''Skilled '''Teaser''' Takagi-san''}}

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 "『{{t|fi|...}}からかい 上" 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 @Suzukaze-c, who is familiar with the Japanese templates and modules in question, and @Benwing2, Erutuon, who are familiar with other parts of the infrastructure involved. Chuck Entz (talk) 22:32, 26 November 2021 (UTC)[reply]

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

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 [{{w|Wikipedia}}] it wouldn't work; I intended to solve this through the nowiki tags. For now the error pages have been fixed, {{w}} replaced with [[w:]]. —Svārtava [t•c•u•r] 02:23, 27 November 2021 (UTC)[reply]
@Chuck Entz: The UNIQ text is some MediaWiki feature (mw: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#mw.text.unstripNoWiki). —Suzukaze-c (talk) 03:14, 28 November 2021 (UTC)[reply]
@Suzukaze-c mw:Strip marker mentions that they're "available to Lua", so it looks like we need to make {{ja-ruby}} strip the strip markers. Although I notice that it also says:

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)[reply]
Re: "it looks like we need to make {{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 Imetsia (talk • contribs) made this change to {{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 {{ja-usex}} does this much parsing of wikitext, I think we can expect these sorts of problems to continue to crop up. :-/
—RuakhTALK 03:51, 29 November 2021 (UTC)[reply]
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. {{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. {{w-test-1}} has both the nowikis and the safesubst wrapped in noinclude tags removed
  4. {{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: [[[w|Transclusion]]] gives [[[w|Transclusion]]], but [ [[w|Transclusion]] ] (with spaces) gives [ Transclusion ].
So, where does that leave us? We can't have all the Japanese templates with ruby support blowing up every time someone uses {{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)[reply]
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 [[[ the first brace is to be ignored. (Benwing2, Erutuon, Surjection: notifying interface admins) —Svārtava [t•c•u•r] 17:19, 1 December 2021 (UTC)[reply]

Redlinked form-of entries[edit]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
The problem seems to result from admins not quite following process. At Wiktionary:Page_deletion_guidelines#Notes to administrators, 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)[reply]

Tool wanted for interwiki-linking subcategories[edit]

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

like to know the procedure for uploading list of words[edit]

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, — This unsigned comment was added by CMR666 (talk • contribs) at 05:22, 30 November 2021 (UTC).[reply]

Massive Category-Error Overkill[edit]

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

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

Tabs at the top of templates?[edit]

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. dobe, 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? @Widsith 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)[reply]

Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2021/November&oldid=76113954"