"We" is the WT:BP. But it looks like it's been improved since we had that conversation. Was there any discussion to reinstate this functionality? --WikiTiki8918:53, 4 October 2017 (UTC)[reply]
It would be fine, but on my old computer it's too slow to load all that script. I went to my Preferences, Beta features tab, but it's already unticked there. Saving didn't help. Equinox◑18:37, 5 October 2017 (UTC)[reply]
I wish it didn't have to load, but was just available as soon as the rest of the page. All these gadgets with their own load delays annoy me. —Rua (mew) 18:48, 5 October 2017 (UTC)[reply]
When an admin blocks a user, we now get a new page with lots of white space that we have to scroll down.
It doesn't seem to add any new function and is annoying.
Is there any way we can get rid of it? SemperBlotto (talk) 05:43, 6 October 2017 (UTC)[reply]
Try adding these rules to your common.css: #blockiptext { display: none; } and .oo-ui-fieldLayout.oo-ui-labelElement, .oo-ui-fieldLayout.oo-ui-fieldLayout-align-inline { margin-top: .01em; }DTLHS (talk) 06:16, 6 October 2017 (UTC)[reply]
OK. I didn't have one of those. Created it with ONLY the above code. Seems to be better. It won't be long before I use it for real. Thanks. SemperBlotto (talk) 06:26, 6 October 2017 (UTC)[reply]
Gratuitous white space is modern and sexy. The scrolling is worth it. (but seriously why are these redesigns so damn ugly in Monobook) —suzukaze (t・c) 06:55, 6 October 2017 (UTC)[reply]
While useful, it might be hard to find out which of them is unmatched on a long page. So I would suggest that the dump also includes an excerpt from the wikicode which highlights exactly which bracket is missing a pair. —Rua (mew) 10:38, 6 October 2017 (UTC)[reply]
On Wikipedia, w:User:BracketBot used to do something somewhat similar, but it hasn't been active since July 2016. I believe there used to be a Toolserver page that allowed users to find pages with unpaired brackets and highlighted the brackets in question, but I don't know if anything similar currently exists. —Granger (talk·contribs) 11:28, 6 October 2017 (UTC)[reply]
I noticed that {{m+}} is not linking the language to the Wikipedia article, unlike other similar templates. This is inconsistent. Can someone fix this, please? If no one does, I may try doing it by myself.
Examples:
{{m+|fr|qwerty}} = French qwerty (currently does not link to the Wikipedia article)
{{cog|fr|qwerty}} = Frenchqwerty (currently links to the Wikipedia article)
{{m+}} was created in a discussion in July, and @Florian Blaschke requested that the language name be unlinked by default, because in many cases the language is well-known and the link isn't all that useful. I find that sort of convincing, but I recognize that it is somewhat confusing for the behavior of {{cog}} and {{noncog}} to be different from that of {{m+}}.
It is easy to change the default behavior in Module:links/templates, but note that there's currently a parameter that turns Wikipedia links on, so if the behavior of the template changes, current instances of the template should probably have the no-Wikipedia-link parameter added so that their display doesn't change. Or it could be resolved that the language name should always be linked. — Eru·tuon22:14, 7 October 2017 (UTC)[reply]
Arguably, all languages should be linked by default in {{noncog}} and {{m+}} because that's what all other templates do: {{der}}, {{bor}}, {{inh}} and even the deprecated ,{{temp|etyl}}. We could say this is the status quo. We are free to discuss and change that, of course, but I'd like any changes to be reflected in the other templates as well.
All those other templates are used in etymologies though, where people are likely to encounter languages they're not familiar with. Can the same be said for {{m+}}? Also, it is worth considering that years ago, we had a rule to link some languages in translations but not others. We eventually decided to make it consistent and not link any of the languages. Perhaps the same should be done here. —Rua (mew) 22:56, 7 October 2017 (UTC)[reply]
I prefer to use {{m+}} in etymologies when the language has already been mentioned. That way, the link appears only at the first mention of the language, but not at subsequent mentions, which would be annoying. —Aɴɢʀ (talk) 15:06, 8 October 2017 (UTC)[reply]
What's with the new editor? This is appearing since last week. Everything is harder to do -- it loads slower, it sometimes grabs the wrong section for editing, lots of things are hidden now, and everything except typing takes more clicks than before.
As there are two different suffixes -ment (verb → noun vs. adjective → adverb), I've split this category in two (I'm not terribly satisfied of the naming, so I'm open to suggestions):
Would it be possible to run a bot that would assign all the entries using the POS header ===Noun=== to the first one, and the ones using ===Adverb=== to the second? --Barytonesis (talk) 17:22, 8 October 2017 (UTC)[reply]
This seems to me a desirable change, though it might need BP discussion.
What would have to be done to provide pull-down listings of reasons for reversion or undoing of contributions? As to content the pulldown listing of reasons for entry deletion would be a start. DCDuring (talk) 19:06, 8 October 2017 (UTC)[reply]
The pull-down menu would be useful to facilitate actually providing a reason, without typing, especially for reversion/undoing of contributions by newbies, anons etc. DCDuring (talk) 19:24, 8 October 2017 (UTC)[reply]
The Wiktionary search 'incategory:"English noun plural forms" incategory:"English third-person singular forms" -"Etymology 2"' found 4,791 such entries with no second Etymology. This would be an underestimate of the size of the total problem. DCDuring (talk) 18:47, 11 October 2017 (UTC)[reply]
I agree. It's a particularly high priority when one form has an alternative spelling (in this case, catalyzes) that the other form doesn't have. When only the pronunciation is different, the solution at houses is adequate IMO. —Aɴɢʀ (talk) 19:11, 11 October 2017 (UTC)[reply]
Ah, thanks. It's a pity that they downgraded it from high priority. I miss the pingable days; I feel people tend to be more active when they can see others have pung them at various places. Wyang (talk) 07:03, 12 October 2017 (UTC)[reply]
No, of course not. I said it as a joke. (But pung is only the past participle; the past tense would of course be pang.) It would also be possible to model it on bring and have ping – pought – pought. —Aɴɢʀ (talk) 08:36, 12 October 2017 (UTC)[reply]
Try to updated yours preferences saving some change and then saving it back. It worked for me. On Special:Preferences#mw-prefsection-echo I changed to mention->email, I received a ping by email, I restored preferences back to "web" and now it is working fine onwiki. Of course, it won't work for pinging others, but for receiving pings to you. --Vriullop (talk) 16:05, 12 October 2017 (UTC)[reply]
In this case you want to format them like Turduli (q.v.), as und-xnu and und-xbi or whatever three letters make sense to you. (Unless Xianbei is so clearly Mongolic that you'll want to be deriving terms back to Proto-Mongolic, in which case the code should begin with xgn-.) —Μετάknowledgediscuss/deeds17:52, 15 October 2017 (UTC)[reply]
If they're etymology-only languages, they need a parent language (i.e. the language that they're considered a "dialect" of). That can be und, as it is for Turfuli, but in that case Xianbei probably shouldn't be given a code starting with xgn-. —Aɴɢʀ (talk) 19:58, 15 October 2017 (UTC)[reply]
Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributed about two-three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have an idea for a task and could you imagine mentoring that task? For example, do you have something on mind that needs documentation, research, some gadget or template issues on your "To do" list but you never had the time, and can imagine enjoying mentoring such a task to help a new contributor? If yes, please check out mw:Google Code-in/2017 and become a mentor! Thanks in advance! --AKlapper (WMF) (talk) 19:55, 16 October 2017 (UTC)[reply]
I am an Admin from Turkish Wiktionary and have been working on some extensions lately to improve Turkish Wiktionary in a level which English Wiktionary reached at this point. I updated the Commons.js file few days ago; this was inevitable, because we had to use "the show/hide" feature on translitions template. I managed to translate this feature with the "Visibility" title that shown on sidebar. But as you can see on this page, it doesn't work on mobile pages. We should do an extra change for that? If anyone can help, that would be nice. Thanks! HastaLaVi2 (talk) 08:46, 17 October 2017 (UTC)[reply]
In what module is the code that shows transcriptions automatically when writing a non-latin scripted word in {{m}} or {{l}} etc.? We intend to use it at sv.wikt.Jonteemil (talk) 21:00, 17 October 2017 (UTC)[reply]
The code that handles these templates is in Module:links, but this module calls on a function in Module:languages to create a transliteration, where it gets forwarded to the language's transliteration module. Different languages have different transliteration modules. —Rua (mew) 21:02, 17 October 2017 (UTC)[reply]
It barely has any translations so that's not the problem. One possibility is splitting the page into language subpages (this is not currently possible, since many templates rely on the page name). DTLHS (talk) 06:08, 20 October 2017 (UTC)[reply]
Commenting out {{R:M&A}} frees up enough memory (~5 MB) to temporarily postpone the problem. It's odd that e failed but a doesn't. e has fewer languages (69) than a (99), transcludes fewer modules (94 vs. 150), and is shorter in terms of bytes. (And it's not at the beginning of the alphabet.) Unfortunately, there's no way to look at the memory usage of each module that is transcluded. I do think removing all the alphabet navigation templates would help. @Rua advocates getting rid of letter entries altogether, which would help even more. — Eru·tuon09:32, 20 October 2017 (UTC)[reply]
I have managed to free up 7% of the Lua memory usage and a more than double as much significant amount of CPU usage i.e. page loading time by on one hand removing {{gloss}}, {{sense}}, {{qualifier}}, {{also}}, which has removed the most memory, and removing clutterings links of words like “and”, “his”, “but” on the other hand, which helped the CPU usage. Note that {{also}} takes 1 MB Lua memory while it is not even needed as on the translingual sections there are always the variants listed; thus I judge that the usage of {{also}} should be removed in letter pages. Palaestrator verborum (loquier) 11:02, 20 October 2017 (UTC)[reply]
Of course. Preferably, the Translingual entry would contain a list of all languages that use the letter, with Appendix links. —Rua (mew) 15:30, 20 October 2017 (UTC)[reply]
I've noticed a number of edits over the past year or so like this one, where the diff highlights changes to strings that look identical in both the before and after versions.
In that particular edit, I noticed that the change maintained a typo I'd made earlier, where I'd accidentally entered a double-g and didn't notice. So I opened the page in the editor to fix it, and hit Ctrl+F in my browser and entered gg. Chrome found nothing.
Closer inspection revealed that the diff changed out regular ASCII g at U+0067 for the IPA Extensions ɡ at U+0261.
What utility is there in making this change? The IPA Extensions glyph appears to be visually identical. However, it is impossible for me to enter using my US 101 keyboard layout.
How many other glyphs are there in use in Wiktionary IPA contexts that are visually identical to ASCII characters?
What objections does anyone have to using the standard ASCII characters? These are both easier to enter, and easier to search for.
Addendum: U+0067 g and U+0261 ɡ are rendered distinctly in Chome when using a monospace font, such as when wrapped in <code> tags above or in the Editor view when configured to use a monospace font. However, when simply displayed on the page in Wiktionary's default font, they look the same to me: g vs. ɡ. ‑‑ Eiríkr Útlendi │Tala við mig15:51, 20 October 2017 (UTC)[reply]
@Eirikr: As you noticed, g and ɡ are not visually identical in all fonts. If you paste them into a word processor like Microsoft Word and view them in Times New Roman, you'll see the difference. U+0261 is a valid letter of the IPA, U+0067 isn't, so we use U+0261 in IPA transcriptions here. It's no different from using Cyrillic А and Greek Α correctly even though they're both visually identical to Latin A. As for other IPA letters that can be mistaken for regular Latin letters, depending on your font, the IPA letter ɑ may look identical to a, the IPA letters ǀ and ǃ may look identical to the punctuation marks | and !, and the IPA letters ɛ, ɸ, and ʋ make look identical to the Greek letters ε, φ, and υ. —Aɴɢʀ (talk) 16:34, 20 October 2017 (UTC)[reply]
I understand the basic point. However, IPA characters are hard to input (I can't seem to find U+0261 in the IPA and enPR quick-insert list in the Editor view), and graphically ambiguous. As noted on the WP page for the voiced velar stop /ɡ/, the regular "g" coded by U+0067 is an acceptable alternative that is visually identical in some fonts, and on some systems, U+0261 confusingly appears as something closer to ɣ (gamma).
Which brings me back to my first question: is there utility in using U+0261? I.e., is it useful? Or is this glyph technically correct, at the hazard of introducing more user confusion and processing difficulties? ‑‑ Eiríkr Útlendi │Tala við mig19:27, 20 October 2017 (UTC)[reply]
U+0261 is in the "IPA and enPR" quick-insert list toward the end of the "Pulmonic consonants" section, after ɧ and before ɫ. The templates {{x2i}} and {{X2IPA}} make inputting easy because they let you type XSAMPA characters (all of which are simple ASCII characters) and get IPA characters output. The pros to using U+0261 in my opinion are (1) it's the correct character and (2) it's the character people will be expecting us to use. U+0067 is an acceptable alternative when it appears as an open-tail g (if you're writing a book in a font where U+0067 is open-tail, no one is going to notice, let alone, complain, if you use U+0067 to indicate a voiced velar stop), but is at best grudgingly accepted by phoneticians (less grudgingly by phonologists) when it appears as a loop-tail g. And if we were to switch over to using U+0067 consistently, I can almost guarantee you we would get complaints from know-it-all newbies and occasional editors saying that we're using the wrong character – and attempts from them to correct the character back to U+0261, but only sporadically in some entries and not others, leading to an inconsistent mess – and we would have to have this whole conversation over and over again. —Aɴɢʀ (talk) 20:01, 20 October 2017 (UTC)[reply]
There is an IPA keyboard layout that is pending for merge in xkeyboard-config, i.e. all keyboard layouts of free desktop, @Eirikr. The creator has also posted it on GithubGist so one can use it pre-release. It does also include the ASCII g though because the rest of the first level key points are ASCII-compatible, so you have to press Shift+Caps+g to explicitly write ɡ U+0261 LATIN SMALL LETTER SCRIPT G with that layout selected. If you have not switched to Linux yet, such custom layouts are surely a reason to do. I have not thought about the usage of it here yet, but for me it is a matter of course to use Linux as an editor here, and you might be interested because of the different input methods there, writing Japanese. Palaestrator verborum (loquier) 21:03, 20 October 2017 (UTC)[reply]
Thank you all for your input, and for your suggested workarounds.
@Aɴɢʀ, thank you for where to look -- I saw the version of U+0261 with the over-circle, but in scanning the list, I didn't see the other plain one further along. Any insight into how that list is ordered? I'm scratching my head about that. :) And thanks too for the template pointers, I didn't know those even existed.
@Palaestrator verborum, justin(r)leung, I've used Linux in the past, and for a while I was on Mac, but due to work needs, I'm on Win 10 anymore. FWIW, I've found WinCompose (https://github.com/samhocevar/wincompose) an indispensable tool for multi-script support outside of the usual MS keyboard or IME framework. I will have to peruse the config (based on the old XOrg compose files) to see if the IPA extensions are lurking in there somewhere; if not, I'll add them to my setup.
I realize it's been deprecated and even nominated for deletion, but Template:def is producing random numbers at the ends of definitions (see here for an example). As long as it's still being used, it should at least work properly. Esszet (talk) 03:16, 21 October 2017 (UTC)[reply]
Not just recently: they've been doing it for a long time, all the while leaving clues so we'll know it's the same person. I think they want to be seen as the merry trickster leaving the stodgy old authority figure shaking his fist and sputtering "Curse you, Masked Bandit! Oooh, if I ever get my hands on you...".
Of course, the shows they're imitating have better writers, and the authority figures in them are cartoonish buffoons designed to set up the gags rather than unpaid volunteers who are just trying to help out.
I find the best approach is to block them, quietly clean up the mess and forget about them until their next lame attempt- it's not possible to shut them down completely, and making a big deal out of it just feeds into their mental Wile E. Coyote/Roadrunner narrative. Low-key strategies like abuse filters that slow them down and increase the hassle seem to work better- the Tar Baby vs. Brer Rabbit approach. Chuck Entz (talk) 22:36, 21 October 2017 (UTC)[reply]
Cross-references should default to current language
I'll pick an example of a problem I've seen many times in multiple languages.
The Swedish word kämpa has kamp in the "Related words" subsection. The link text is kamp rather than kamp#Swedish so it goes to the top of the kamp page. I have to scroll down to find the the Swedish word that was meant to be linked.
Is Wiktionary software smart enough to know a link is in a Derived terms or Related terms section and add the current language if it is missing? Alternatively, are there any bots smart enough to fix up all the missing languages in cross-references? (But not in definitions, because those tend to link to English words.)
Vox Sciurorum (talk) 00:29, 22 October 2017 (UTC)[reply]
If you write {{l|sv|kamp}} instead of [[kamp]] then it will work. It would be nicer to default the simple-style links to the current language as you suggest, but I don't believe it is possible. Equinox◑00:37, 22 October 2017 (UTC)[reply]
@DTLHS: The bot messed up all plainlinked translingual terms that it touched, inasmuch as it made the links orange for those that have the Orange links box checked on the gadgets page. The simplistic logic was apparently that any plainlinked terms ("term") not in the etymology section would be reformatted as {{l|langcode|term}}. DCDuring (talk) 20:29, 27 October 2017 (UTC)[reply]
I imagine JavaScript could make links in derived or related terms sections (or synonyms, antonyms) go to the language of the first level-2 header above them. But that would be done in your browser, not the Wiktionary server. — Eru·tuon01:33, 22 October 2017 (UTC)[reply]
It seems that Greek-alphabet entries at one point needed to use DEFAULTSORT to ensure that vowels with a tonos (a mark that shows which syllable is stressed) are treated the same as unmarked vowels for the purposes of alphabetical sorting. Apparently this is no longer required. Many Greek entries still have the DEFAULTSORT code included which should be removed: an ideal job for a bot.
A possible algorithm to use:
For each Greek-language page (it should be sufficient to trawl through all pages listed in Category:Greek language and all subcategories):
Check whether the page includes {{DEFAULTSORT:...}} (ignoring capitalisation). If it does:
Work out what the page name would be without diacritical marks. A sample substitution table of characters: (I was initially going for just the tonos, but why not cover everything, eh?)
If the contents of the {{DEFAULTSORT:...}} code matches the page name without marks (ignoring capitalisation):
Remove the {{DEFAULTSORT:...}} code entirely. If it's the only thing on that line, remove that line entirely.
Allow for line breaks: if there is a blank line both before and after the {{DEFAULTSORT:...}} then collapse these down into a single blank line.
I don't know, but it's possible that the same issue affects pages in other scripts. So an alternative might be to extend the mapping table above to cover lots more scripts, and to instead search for all pages containing {{DEFAULTSORT:...}}. Extending the bot for other scripts can be done as a later enhancement.
@Stelio: It should be fine to remove the DEFAULTSORT in all cases, because sortkeys are automatically generated by the makeSortKey function in Module:languages. (If there are any errors in that function or the data that it uses, they can be fixed in the appropriate module, rather than on the page where the error occurs.) However, if there are any bare categories ([[Category:Greek autological terms]]), they will have to be converted to the corresponding category template ({{cln|el|autological terms}}), or the sortkey will be the unmodified root page name. I believe @DTLHS has a category-templatizing script. — Eru·tuon21:40, 23 October 2017 (UTC)[reply]
I have occasionally/recently added DEFAULTSORT to overcome the problem summed up in the 1st sentence above - if automatic sorting in category's is achieved I see no reason why that line shouldn't be removed from entries. — Saltmarsh. 05:09, 24 October 2017 (UTC)[reply]
Our translation tables are invalid HTML 5 because they have dl (definition list) elements that contain dd (definition) but no dt (associated term being defined). Is this a simple fix? Equinox◑12:11, 24 October 2017 (UTC)[reply]
This is a problem with Wikicode rather than with our translation tables. Wikicode allows you to use dd without dt, and everyone uses dd to indent their posts, like I did. We could disallow the use of : for indentation, but enforcing it would be like herding cats. —Rua (mew) 14:29, 24 October 2017 (UTC)[reply]
Whenever I use the pharyngealization mark ˤ in شنطة, I get an erroneous error message saying invalid IPA characters (ˤ), replace ˤ with ˁ when I demostrate a preview of my edit. I don't get it, I'm using the correct symbol, why do I get that notice? The error could be from module:IPA/templates. --Mahmudmasri (talk) 14:13, 25 October 2017 (UTC)[reply]
You're not using the correct symbol. U+02C1 (MODIFIER LETTER REVERSED GLOTTAL STOP) is different from U+02E4 (MODIFIER LETTER SMALL REVERSED GLOTTAL STOP). Note that this error will only show up in the preview- you can still save the page. DTLHS (talk) 16:07, 25 October 2017 (UTC)[reply]
See Module:IPA/data/symbols for the symbols that are considered valid and the suggestions that are displayed when one uses a symbol that isn't in the list ("suggestions"). As DTLHS says, sometimes the symbols look identical but are actually different codepoints. But it's best to choose one codepoint so that transcriptions are consistent (and you can search for a codepoint and find all the instances of a particular IPA symbol). There was a previous discussion on the reasons for choosing the one we did. — Eru·tuon18:35, 25 October 2017 (UTC)[reply]
It should be noted that we have this character the wrong way around; U+02E4 is apparently the correct IPA symbol. I posted this in the previous discussion you linked, but perhaps too late for anyone to see it: According to Unicode, U+02C1 is a ‘typographical alternate for U+02BF’, i.e. ʿ, whereas U+02E4 canonically decomposes to a superscript U+0295, i.e. ʕ. The official IPA website also has a link labeled ‘IPA and Unicode’ that leads here, where U+02E4 is given as the hex code for ‘pharyngealized’. — Vorziblix (talk · contribs) 21:14, 25 October 2017 (UTC)[reply]
Regardless of which is correct, shouldn't we have {{IPA}} convert the wrong ones to the right ones automatically instead? Similarly we will always get people (including me, when I forget) putting g in IPA rather than the proper ɡ. But it wouldn't be hard to fix that without bothering the editor. —Μετάknowledgediscuss/deeds23:04, 25 October 2017 (UTC)[reply]
What do you mean "convert automatically"? The template can't change what the user types. And I already periodically fix common IPA character mistakes with my bot. DTLHS (talk) 23:08, 25 October 2017 (UTC)[reply]
What might be useful is to distinguish characters that are indubitably wrong for IPA, versus those (such as g and ˤ) that are simply easy to confuse with similar looking characters, and only display the error message for the former. DTLHS (talk) 23:18, 25 October 2017 (UTC)[reply]
@Metaknowledge: Module:IPA could display the correct characters, but the wrong ones would still be there in the wikitext.
@DTLHS: I like the idea of restricting the error message to visually distinct characters (like δ and ð), and letting bots handle those that are identical in many fonts. — Eru·tuon23:37, 25 October 2017 (UTC)[reply]
Yes, that's what I was talking about. Who cares what's in the wikitext — now that the search looks at template output, readers would only see the correct characters if we did that (and we could still do bot runs to clean up the wikitext every so often). —Μετάknowledgediscuss/deeds18:35, 26 October 2017 (UTC)[reply]
Why not two-staged? Some things can be displayed as errors, others give warnings. A classic. And I would like to see a warning for using “g“ from ASCII in IPA sections, as I can easily type in “ɡ” from the IPA extensions. Palaestrator verborum (loquier) 20:32, 26 October 2017 (UTC)[reply]
Just as Kanji entries do, the HSK level of the words' meanings could also be easily added automatically. Apparently, some words do have such a tag (see 不僅). --Backinstadiums (talk) 08:37, 27 October 2017 (UTC)[reply]
@Justinrleung: just for that? As many tags do, a link would redirect to the Appendix where the precise info. is developed. Lexicographically, the improvement that having them entails is greater than the unlikely confusion you mention. That same consideration doesn't seem to have been taken into account for the several dialects of Japanese. --Backinstadiums (talk) 02:38, 30 October 2017 (UTC)[reply]
@Backinstadiums: For HSK, it is labelled as "X Mandarin", which makes it look like it's only Mandarin. Japanese would not have this problem, since it's not "X Tokyo" or something like that. This is the problem that I see, but I can't recall if it was the original reason for removing these tags @Wyang, Atitarev, Tooironic. — justin(r)leung{ (t...) | c=› }02:46, 30 October 2017 (UTC)[reply]
I support removing the labels from the code and handling these centrally and automatically using data modules. It will be much easier to maintain and update and is resistant to errors. Perhaps {{zh-forms}} is a good carrier (not necessarily displayer) for such information. Maybe the HSK category should be made more obvious, but I can't think of a good place to put it. Directly underneath the language headers and to the right may work, with some JS magic. Wyang (talk) 06:09, 30 October 2017 (UTC)[reply]
@Backinstadiums The above was only my envisagement - I don't know if it's feasible as my JavaScript is poor. You can request it here or on a more specific page, but you need to ping all the Chinese editors for their opinions on this change first. Wyang (talk) 09:27, 1 November 2017 (UTC)[reply]
@Backinstadiums Atitarev, Bumm13, Dine2016, Dokurrat, Hongthay, Jamesjiao, Justinrleung, kc_kennylau, Mar vin kaiser, Suzukaze-c, Tooironic. You can request it on any page. I'd suggest you make sure the proposed format is technically feasible, and that there is someone willing to implement it, though. Wyang (talk) 10:06, 1 November 2017 (UTC)[reply]
Good news, everyone! Thanks chiefly to Daniel Carrero (though of course many people helped!) {{term}} is no longer used at all in the main, Appendix, or Reconstruction namespaces, or on instruction pages in the Wiktionary namespace. It's only used on talk pages and in archives of old discussions in Wiktionary namespace. I've added it to CAT:Successfully deprecated templates and marked it with class="deprecated" so uses of it appear green. @Rua: could you (or anyone else who's good at editing modules) edit Module:term cleanup so it no longer sorts usages according to script? That seems unnecessary now; sorting according to namespace is probably sufficient, and even that might not really be necessary. —Aɴɢʀ (talk) 16:35, 27 October 2017 (UTC)[reply]
I believe the reason you said is correct. Fortunately, it seems easy to change all instances of {{term|foo|lang=zz}} into {{m|zz|foo}} by bot. I believe Rua did this once. Can someone use a bot to do that again, perhaps for all namespaces, not just the main namespace? (again, just the instances of {{term}} that already have the language code) --Daniel Carrero (talk) 01:57, 28 October 2017 (UTC)[reply]
I would like it if any mainspace pages using {{term}} were categorized into CAT:Pages using deprecated templates, but if I simply <includeonly> the category name into the page, it will categorize all pages transcluding {{term}}. How do I restrict it so only mainspace pages (or better yet, mainspace, Appendix: and Reconstruction:) are categorized, while talk pages and the like aren't? —Aɴɢʀ (talk) 16:37, 30 October 2017 (UTC)[reply]
Oh right, that annoying issue. You can also use {{#switch:{{NAMESPACE}}||Appendix|Reconstruction=[[Category:something]]}} —Rua (mew) 18:54, 30 October 2017 (UTC)[reply]
What I did was {{categorize|{{{lang|und}}}|Pages using deprecated templates}} and when I tested it in preview mode it seemed to work okay. Come to think of it, simply {{categorize|und|Pages using deprecated templates}} ought to work too, since there's no language-specific categorization going on anyway. —Aɴɢʀ (talk) 19:00, 30 October 2017 (UTC)[reply]
I've tried again using #switch: as you recommended and that seems to work. I suppose it'll take a few hours for the category to empty again. —Aɴɢʀ (talk) 22:09, 30 October 2017 (UTC)[reply]
It's because Talk is in the list of namespaces in which Module:utilities adds categories. See Module:utilities/data. Perhaps there's some template that uses Module:utilities to add categories in the Talk namespace, and hence it's in the list. For many, that's not the case. For instance, etymology templates use the module to add categories, but should only add categories in entry namespaces. — Eru·tuon23:54, 30 October 2017 (UTC)[reply]
@DTLHS: I mean, will I get emailed everytime any page on my watchlist is edited, or can I choose among my watchlist the ones I want email notifications about? IOW, once I enable the email notifications, do I have to remove a page from my watchlist if I don't want to get emailed about that specific entry? --2A02:2788:A4:F44:F0B0:D1E7:E066:EEF417:19, 31 October 2017 (UTC)[reply]
The former. You could set up an email filter, or create a separate account with a watchlist of only the pages you want notifications about. DTLHS (talk) 17:21, 31 October 2017 (UTC)[reply]
Done —Aɴɢʀ (talk) 17:34, 11 October 2017 (UTC)