Module:number_list/data/la has now been extended beyond one million, which caused the Roman numerals automatically generated by Module:foreign numerals to get out of hand. Wikipedia represents 1,000,000,000 in Roman numerals as M with two lines over it; I don't know where it comes from, but that is at least more likely to have ever been used than repeating M̅ a thousand times. Urszag (talk) 22:19, 1 October 2024 (UTC)Reply

I don't generally use QQ for searching, since I am often searching books.google for specific date ranges, looking for earliest and latest cites, or looking for uses of rare senses, eg currently the noun sense of scarper, which I was unaware of until I read it in the Guardian, following which I had to look through about 130 bg quotes to find two more uses. (I couldn't use QQ because, even when it hasn't reached what seems to be its daily quota, it seems to stop after around 20 hits, and anyway, there is sometimes insufficient context in the snippet it shows to know whether the cite is using the word in the sense I'm searching for.) I'm not expecting that to change anytime soon -- I believe I'm using sufficiently fuzzy skills that it will take a while yet for AI to catch up with me, and at the same time, I read slowly enough that Google knows I'm not a machine, so they don't shut me down.

BUT, having found my cites, I then spend ages filling out the details into the template -- often longer than it took me to do the search. Would it be possible to modify QQ (or some other gadget) to take an input of a particular bg page, rather than searching for it itself, and format the cite from that? Hopefully, that would be easy, since it must do something very similar at present, after users click on the cite they want to use. --Enginear 01:54, 3 October 2024 (UTC)Reply

phab:T376361, itself caused by a bungled fix to phab:T375876...

What even is integration testing? Ioaxxere (talk) 02:39, 3 October 2024 (UTC)Reply

This is a {{ja-see}} issue; 辨へ is the old kana form of 辨え, the kyūjitai form of 弁え, which is an alternate form of わきまえ (which has the old kana form わきまへ). All of the other forms work, but not 辨へ. TE(æ)A,ea. (talk) 02:42, 4 October 2024 (UTC)Reply

@TE(æ)A,ea.: Seems the template lacks a default way of handling alternative kyūjitai forms. Thankfully, it accepts custom fields. Binarystep (talk) 05:31, 24 October 2024 (UTC)Reply

bodkin isn't showing up in the Category:English terms suffixed with -kin (diminutive). Can someone explain why it's happening and/or show me how to fix it? Thanks! Katya0133 (talk) 04:26, 4 October 2024 (UTC)Reply

@Katya0133 It was using {{m}} instead of {{af}}. Anyways, that part should ideally be covered under Middle English. Catonif (talk) 12:21, 4 October 2024 (UTC)Reply

Please add the additional attributes to m["hnn"] at Module:languages/data/3/h:

m["hnn"] = {
    "Hanunoo",
    35435,
    "phi",
    "Hano, Latn",
    translit = {Hano = "hnn-translit"},
    override_translit = true,
    entry_name = {Latn = {remove_diacritics = c.grave .. c.acute .. c.circ}},
    standardChars = {
        Latn = "AaBbKkDdEeGgHhIiLlMmNnOoPpRrSsTtUuWwYy",
        c.punc
    },
    sort_key = {
        Latn = "tl-sortkey",
    },
}

Thanks! 𝄽 ysrael214 (talk) 11:06, 4 October 2024 (UTC)Reply

Tested the translit module and   Done. Catonif (talk) 12:46, 4 October 2024 (UTC)Reply

@Catonif Hi can you also add "hnn" to data.hyphen_not_multiword_sep at Module:headword/data? 𝄽 ysrael214 (talk) 14:56, 4 October 2024 (UTC)Reply

Following this discussion. There is currently an issue with the display of hieroglyphs not supported by WikiHiero, as {{egy-h}} has to treat them separately (traditionally this was done manually via egy-glyph), which leads the final result to go to a new line when those glyphs are encountered if the window is too small. For example, check the quotation under hrm and decrease your window size (or access it from your cellphone, where the width is insufficient already) and notice the unwanted line breaks. This can be solved via a JS snippet, currently at User:Catonif/hierotables.js (I know modifying raw HTML with regexes is usually considered forbidden practice, but handling this with JQuery seemed to get too lengthy and bug-prone), which also solves another issue, this time intrinsic to WikiHiero, about even more unwanted wrapping in complex hieroglyphs groups.

Given that we already have a JS script running on Common.js for WikiHiero, MediaWiki:WikiHieroTempFix.js (this makes WikiHiero results display inline with the text rather than displaying block), launched whenever WikiHiero calls are detected, I believe the content of hierotables.js snippet could be simply incorporated in it.

The second issue is that this WikiHieroTempFix.js I just mentioned is not called on MediaWiki:Mobile.js, but only on MediaWiki:Common.js, which means that if I access pages such as ⲑⲱⲟⲩⲧ from my cellphone (weirdly enough, not if I access it in mobile mode from the PC however), the hieroglyphs in the etymology rather messily do not display inline with the text. I don't know whether we're planning to merge Common.js and Mobile.js, as @Ioaxxere recently finally did for their .css counterparts, which would get rid of this issue, but as long as that's not the case I call for WikiHieroTempFix.js to be run also by Mobile.js.

CC: @Vorziblix. Catonif (talk) 12:18, 4 October 2024 (UTC)Reply

If no one has any objections, I support putting all of User:Catonif’s suggestions into operation. This JS snippet resolves some very longstanding issues with WikiHiero and should make mobile browsing of relevant entries much less messy. — Vorziblix (talk · contribs) 23:41, 7 October 2024 (UTC)Reply

Not sure when this went bad, but attempting to process table entries thorugh the linkify_entry function no longer correctly creates links to reconstructed entries. Instead, an input like *jptwj creates a link to Reconstruction:[language name]/Unsupported titles/Reconstruction:[language name]/jptwj; see the links at {{Egyptian demonstratives}} for a number of examples. This only happens when the asterisk comes at the start of the input; inputs like jptw, *jptwj, where multiple entries are listed and the reconstructed one doesn't come at the beginning, are processed fine. Anyone know how to fix it? — Vorziblix (talk · contribs) 14:32, 4 October 2024 (UTC)Reply

@Vorziblix This is caused by {{lang}}, not by Module:table tools, and is due to something in embedded_language_links in Module:links. I've asked User:Theknightwho to look into it. Benwing2 (talk) 00:08, 5 October 2024 (UTC)Reply

also: JPEG artefact

• JPEG artifact: compression-induced image distortion

188.4.61.73 21:35, 4 October 2024 (UTC)Reply

It's not clear what you are saying. — Sgconlaw (talk) 21:48, 4 October 2024 (UTC)Reply

@Sgconlaw context-free posts to the GP can often be elucidated by checking the user's abuse log. In this case I think the abuse filter is not set up properly, as the user did provide a definition, even though they failed to remove the rfdef template. This, that and the other (talk) 04:15, 5 October 2024 (UTC)Reply

I've been going through these, and I'm finding a few common types of false positives:

1. Zero affixes like ∅- and -∅ have entries in various L2s and are included in etymologies.
2. Combining diacritics with a dummy character as a holder, such as ◌́, ◌̂, ◌̈, ◌̀, etc.
3. Links to Wikipedias and other Wiktionaries. Wikimedia sites can have entry names in any language, so links to their entries should not be treated as text in a specific language. For instance, all the Cyrillic characters have entries on English Wikipedia with Cyrillic titles, but the links to those entries in {{wikipedia}} or {{pedia}} are not English terms in Cyrillic. Likewise, a Wikipedia in a non-Latin script will have articles on organisms and their taxa under their taxonomic names, but links to those are not terms in the language of the Wikipedia in Latin script.
4. Languages with no script specified. What's the point of putting the entire language in an entry-maintenance category?
5. Obsolete or rare orthographies like Belarusian Łacinka, or Arabic script for various languages in the Philippines, Indonesia, South Asia, Eastern Europe, etc. I realize that these have to be handled on a case-by-case basis, but I thought I would mention them, to be thorough.
6. Multilingual symbols such as mathematical or scientific notation, signs for gods, astrology and alchemy terms. Here again, this is probably case-by-case.

Some common mistakes. I'm not sure there's a technical fix for these:

1. Transcriptions copied from comparative literature by people who don't know or care that they're in the wrong script.
2. Bad language codes
3. Wrong templates: people using {{l}} instead of {{lb}} for labels is probably the most common (there was even someone who used {{l|lb}}, which made them into Limburgish).
4. Errors in template syntax: for instance, not putting the right number of pipes between positional parameters, so a translation or transliteration is treated as a display form.

One special case worth mentioning: Hindi and Urdu headword templates have links to the equivalent term in the other language. If someone uses {{head}} instead, they try to reproduce this by having fields for "Urdu spelling" or "Hindi spelling", but these are tagged as the language of the headword rather than as another language. There may be a way to work around this, but I haven't found it yet.

I hope I haven't overloaded this topic. I was afraid that I would never get around to posting this if I had to decide how many individual posts to break it into. Thanks! Chuck Entz (talk) 17:31, 5 October 2024 (UTC)Reply

I tried to solve false positive type 3 in Special:Diff/82308974 and 4 in Special:Diff/82309298, but it might take a while to filter through. As for 6 (multilingual symbols), we shouldn't be writing {{syn|en|❤️}} or whatever. I guess it should be {{syn|en|mul:❤️}}. This, that and the other (talk) 11:41, 7 October 2024 (UTC)Reply

@Theknightwho reverted the second change, pointing out that this is a useful way of keeping track of which languages need script codes added to their language data. TKW might also be able to help fix false positive types 1 and 2 by making the relevant code ignore the ∅ and (presumably) ◌ characters. This, that and the other (talk) 23:37, 7 October 2024 (UTC)Reply

In five#Translations it seems usages of Template:tt are broken and only show "true" or "true, true" Xie1995 (talk) 19:04, 5 October 2024 (UTC)Reply

This looks to be fixed. Benwing2 (talk) 21:03, 5 October 2024 (UTC)Reply

Is there a particular reason for it to appear always in italic when it's linked? Sérgio R R Santos (talk) 11:37, 7 October 2024 (UTC)Reply

Hi, here on enwiktionary, {{bn-noun}} gives বই • (boi) (see বই#Noun). On bnwiktionary, we don't need the translit part for Bengali word (in this example, the (boi) part). So, i comment out translit part from languages/data module. But the template still says "Transliteration required". How can we remove it? (We still want "Transliteration required" for other languages but not for Bengali language.) আফতাবুজ্জামান (talk) 17:28, 7 October 2024 (UTC)Reply

@আফতাবুজ্জামান Hey it looks like you should undo your change and instead add "bn" to the list here: Module:headword/data#L-434. Benwing2 (talk) 21:55, 8 October 2024 (UTC)Reply

Is it possible to update {{IPAchar}} so that it does not allow a line break after a slash (/), to avoid a result like what is simulated below?

In German schon is pronounced /

ʃoːn/.

I tried inserting a zero-width no-break code after the slash when using the template, but this causes it to throw a "unrecognized character" error. — Sgconlaw (talk) 16:44, 8 October 2024 (UTC)Reply

We could add word joiners after opening and before closing at Module:IPA#L-538. It looks as though this would solve the problem. (Using CSS would too, but then IPA pronunciations would never wrap, which is not correct behaviour.) Would the word joiners cause trouble on any known system, or with copy-pasting? This, that and the other (talk) 09:09, 9 October 2024 (UTC)Reply

Change the link m:Help:Page name#Restrictions to mw:Manual:Page naming#Page title restrictions. Also while you're at it you may want to consider adding a similar message to MediaWiki:Title-invalid-characters which is more likely to be seen. * Pppery * _{it has begun...} 23:35, 8 October 2024 (UTC)Reply

@Pppery:   Done — would it make sense for MediaWiki:Title-invalid-characters to be an exact copy? Ioaxxere (talk) 01:40, 9 October 2024 (UTC)Reply

Suggested code:

<div class="plainlinks" style="background-color:#FFE7DD;border: 1px dashed #884444;width:90%;margin:auto;text-align:left;text-align:center;margin-bottom: 10px">
Sorry, titles containing the character $1 are [[mw:Manual:Page naming#Page title restrictions|not supported by our software]]. It is possible that the entry you are looking for is below; if not, please [[WT:RE|request]] it or [{{fullurl:Appendix:Unsupported titles|action=edit}} add it] yourself.
</div>
{{Appendix:Unsupported titles}}
{{Appendix:List of protologisms/Long words}}

Almost an exact copy, but I modified the first sentence a little to include the specific invalid character. Some more advanced logic could in theory be added but that already exists in MediaWiki:Gadget-UnsupportedTitles.js so I wouldn't bother. * Pppery * _{it has begun...} 01:42, 9 October 2024 (UTC)Reply

Done, I also tweaked the CSS a little. Ioaxxere (talk) 02:28, 9 October 2024 (UTC)Reply

https://en.wiktionary.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&search=insource%3A%22NavFrame%22 Ioaxxere (talk) 03:20, 9 October 2024 (UTC)Reply

Your post is wildly obscure, so I have to tease out what you're trying to tell us, but it seems like, e.g. ორომს has a declension table that was inserted as HTML rather than MediaWiki syntax. Looking at {{lzz-conj-table}}, it is very different from the conjugation table in this entry, so I suppose that User:Gubazes inserted it by hand deliberately. Maybe he can tell us more about what happened there? And maybe you can elaborate on what you're trying to tell us with this thread or if you have a proposal for what to do? —Justin (koavf)❤T☮C☺M☯ 05:48, 9 October 2024 (UTC)Reply

Right, let's get to the point. The first, tables are different because it represents intransitive and transitive verbs, whereas ორომს (oroms) is bitransitive (they are conjugated for both the subject and the object). It's irregular, that's why it's been insterted by hand. I tried to create a Laz conjugation table for the template so people could see what the conjugation looks like, but I failed. I couldn't figure out how to represent tenses, which to include and which to not, how to determine root, preverbs and so on. I think the template page needs to be deleted until someone with more experience with Wiktionary templates can create a better script. Gubazes (talk) 13:34, 16 October 2024 (UTC)Reply

The current alphabetical order on Pannonian Rusyn (in Category:Pannonian Rusyn lemmas and so on) is wrong. I've copied the correct one into T:list:Cyrillic script letters/rsk, and I can also confirm it's correct because it's the one used by the 2010 dictionary (T:R:rsk:RSS) which I use as my main reference, and publications from the 70s are listed on the Wikipedia page which state the standardized orthography. Can someone more technologically savvy than myself fix the order? Thanks. Insaneguy1083 (talk) 09:57, 9 October 2024 (UTC)Reply

@Insaneguy1083: Done: diff. It might take a while for everything to update itself to the new order. — Vorziblix (talk · contribs) 21:29, 9 October 2024 (UTC)Reply

Thanks! Insaneguy1083 (talk) 21:32, 9 October 2024 (UTC)Reply

@Vorziblix: actually, I think you did it wrong? Г and Ґ are treated as separate letters, as are И and Ї and Е and Є. They're not meant to be collated together. Insaneguy1083 (talk) 21:35, 9 October 2024 (UTC)Reply

@Insaneguy1083: They are not collated as if they are the same letter—Ґ will always come after Г, and so forth. The sorting itself should be correct. Unfortunately the headings in the category pages will treat them as the same letter, but there’s no way around that—it’s the same situation we have in Ukrainian, etc. — Vorziblix (talk · contribs) 21:42, 9 October 2024 (UTC)Reply

@Vorziblix: Hmm. Curious. Well, thanks a lot for updating the sorting anyway. If there's any updates on being able to separate Г and Ґ etc. in Ukrainian/Carpathian Rusyn, do let me know. Insaneguy1083 (talk) 21:49, 9 October 2024 (UTC)Reply

There is a way around that these days - we have a gadget for this very purpose. — SURJECTION ^{/ T / C / L /} 19:23, 13 October 2024 (UTC)Reply

This changed just recently. I assume it's a wiktionary thing, because control-x, c and v for 'cut', 'copy' and 'paste' still work properly on this page, in the url window, and in edit windows on WP.

Currently, in the edit window of a wikt article, if I hit control-x I get bold formatting, with control-c I get italic, and with control-v I get superscript. Presumably this has something to do with me using a dvorak keyboard (dvorak x and c correspond to qwerty b and i), but other commands are not affected. E.g. control-z and -y are still 'undo' and 'redo', despite corresponding to the qwerty keys for t and /. Also, as noted, this page is not affected: All keys work properly right now in this edit window.

Can I do something with my css to override this behaviour? kwami (talk) 02:12, 10 October 2024 (UTC)Reply

Which skin are you using? —Justin (koavf)❤T☮C☺M☯ 05:42, 10 October 2024 (UTC)Reply

Vector 2022. I just switched to Vector legacy, and the behaviour is the same. kwami (talk) 06:26, 10 October 2024 (UTC)Reply

The same thing is now happening on WP, so I'll ask there as well.

BTW, it occurs here if I edit the thread, but not if I 'respond' to a comment, opening a new window. kwami (talk) 00:13, 14 October 2024 (UTC)Reply

Update: On WP they said that the patch that broke this has been reverted, and will be going out on thursday. Meanwhile, for anyone reading, the syntax highlighter breaks this function and can be used as a temp fix. kwami (talk) 01:28, 14 October 2024 (UTC)Reply

Hi all! I've been adding photos to plant family name definitions, and I'd love to be able to use the photo montage template from Wikipedia; it'd be ideal to show more of the taxon's range of diversity, rather than just the type species, and this would be much faster than creating and uploading an individual collage image for each family.

Is there any equivalent template on Wiktionary, something that'll take a few Commons images and arrange them in the space of one thumbnail? If that doesn't already exist here, is there any reason I can't or shouldn't just copy and paste the module code from Wiki -- citing the source, of course? Can templates be ported that easily? ("That's not how any of this works" is an extremely valid answer, especially seeing as I've never written a Mediawiki template before! I'm willing to learn, though.)

Thanks for your time. --Photosynthetic430 (talk) 18:56, 11 October 2024 (UTC)Reply

@Photosynthetic430 you're more than welcome to give it a go. As this template is Lua-based, you'd need to copy w:Module:photo montage too. That module does not appear to have any dependencies, so it should copy across cleanly. This, that and the other (talk) 03:20, 14 October 2024 (UTC)Reply

On it, then! I'll report back if it works, haha. -- Photosynthetic430 (talk) 20:52, 14 October 2024 (UTC)Reply

Looks like it works! Now to finish removing the 'pedia-specific bits of the documentation. -- Photosynthetic430 (talk) 21:22, 14 October 2024 (UTC)Reply

In e.g. Category:Old English lemmas, the TOC is "A B C... Z", "aa... ba... ca... ... zz", with no "þ" AFAICT, so it's not obvious how to navigate to where the entries starting with thorn are. In fact, trying to manually change the URL to reach them, I notice that they aren't sorted under either thorn or th. I eventually tracked down that they, and eth, are sorted after tz; whether this makes sense I don't know, but it'd be useful to add to the TOC a thorn anchor pointing to where they are. (I have forgotten offhand where the TOC is generated from.) - -sche (discuss) 00:50, 13 October 2024 (UTC)Reply

@-sche I think you have to make {{ang-categoryTOC/full}}, noting that {{ang-categoryTOC}} exists for categories with between 200 and 2500 entries. We could also do with {{is-categoryTOC/full}}. This, that and the other (talk) 04:37, 17 October 2024 (UTC)Reply

Is there a working French lookup extension for French Firefox? Ineuw (talk) 04:33, 13 October 2024 (UTC)Reply

@Ineuw: You click onto the loupe in your search bar when on the French Wiktionary mainpage, click its icon for “adding French Wiktionary”, and Bob’s your uncle. Ctrl + K focuses the search bar. Fay Freak (talk) 09:01, 15 October 2024 (UTC)Reply

I've listed myself as mzs-1 on my user page, but the message for that (i.e. "This user has basic knowledge" blah blah blah) is in English. Where can I go to write these messages for Macanese? Insaneguy1083 (talk) 10:07, 13 October 2024 (UTC)Reply

They are known as infoboxes or userboxes. Look at my collection of infoboxes and if you have questions, post back here.Ineuw (talk) 18:28, 13 October 2024 (UTC)Reply

Insert code like:

{{#babel:en|pt-3|mzs-1|de-1}}

etc. Let me know if that's confusing. —Justin (koavf)❤T☮C☺M☯ 18:33, 13 October 2024 (UTC)Reply

I already did that. That's not the issue - the issue is that the message is in English, because no one's written a personalized one for Macanese yet, and I was wondering where I could do that. Insaneguy1083 (talk) 18:35, 13 October 2024 (UTC)Reply

Oh, I see. translatewiki: is where these messages are translated. —Justin (koavf)❤T☮C☺M☯ 18:36, 13 October 2024 (UTC)Reply

While going through WT:Todo/Lists/Broken links to Wikipedia, I noticed a number under Aragonese. These are governed by Module:labels/data/lang/an, and I saw that the bad links were only from those labels that had { } tables in their Wikipedia parameter. From the documentation, I would have expected these to generate a link to the first of the values in the list:

labels["Belsetán"] = {

Wikipedia = {"es:Aragonés belsetano", "Bielsa"},

regional_categories = true,

should link to w:es:Aragonés belsetano. Instead it links to w:Belsetán- a behavior the documentation says should happen when Wikipedia = true

Am I missing something, or is this an undocumented bug/feature? (I should add that the linking on the category pages such as Category:Belsetán Aragonese seems to work as described, so something would be lost by simplifying it to :Wikipedia = "es:Aragonés belsetano"},). Chuck Entz (talk) 21:41, 14 October 2024 (UTC)Reply

This sounds like a bug. I'll take a look. Benwing2 (talk) 22:17, 14 October 2024 (UTC)Reply

Fresh out of QQ (but with underlining added), a cite often looks like:

• 2016 April 28, Andrew Picard, Myk Habets, Theology and the Experience of Disability: Interdisciplinary Perspectives from Voices Down Under, Routledge, →ISBN, page 51:

  ... the saltland for its dwelling place ? It scorns the tumult of the city ; it does not hear the shouts of the driver . It ranges the mountains as its pasture , and it searches after every green thing . ( Job 39 : 5-8 ) Yahweh assigns […]

Could QQ be made slightly smarter, to remove the extraneous spaces? (This has been suggested before.) - -sche (discuss) 23:13, 15 October 2024 (UTC)Reply

These terms, such as татуируя (tatuiruja), should be in Cat:Russian non-lemma forms but are not for some reason. I note that Russian present active/passive participles do appear to be properly categorised. Can anyone advise? This, that and the other (talk) 06:02, 16 October 2024 (UTC)Reply

Is it really as simple as this? I searched module space for the singular form (mod:"present passive participle") but I guess I should have looked for the plural. This, that and the other (talk) 06:35, 16 October 2024 (UTC)Reply

Yeah that should be all you have to do. Benwing2 (talk) 05:45, 17 October 2024 (UTC)Reply

I wish to request new templates for creating links to thesaurus and appendices more easily. similarly to the templates such as {{temp}} (creates a link to templates) and {{w}} (to Wikipedia), these should exist so that we do not need to tediously type the whole link. examples below:

{{thes|en|good}} gives [[Thesaurus:good#English]]

{{snowclone|en|X with a capital Y}} gives [[Appendix:Snowclones/X with a capital Y#English]]

there are likely other usecases that I haven't thought about, please feel free to reply with some. Juwan (talk) 08:27, 19 October 2024 (UTC)Reply

Is there a reason why these need language parameters? I don't know that we have a lot of multilingual appendices or thesaurus entries... —Justin (koavf)❤T☮C☺M☯ 12:01, 19 October 2024 (UTC)Reply

{{thes}} exists now. —Justin (koavf)❤T☮C☺M☯ 12:07, 19 October 2024 (UTC)Reply

thank you very much! I would prefer them (at least the thesaurus one and other specialised templates) to have a language parameter, because 1. it is useful for the few entries that are multilingual, 2. it is already required that all thesaurus pages must have a language header, so why not make use of it, and 3. these can bring some help for accessbility for screen readers reading the title (if that implemented in the future). the last one is a whole can of worms to itself but I digress. Juwan (talk) 12:42, 19 October 2024 (UTC)Reply

@JnpoJuwan why do you want this? When inlining synonyms (as we should be doing) using the {{syn}} template, you can write {{syn|en|...|Thesaurus:happy}} to get

Synonyms: ...; see also Thesaurus:happy

This, that and the other (talk) 21:54, 19 October 2024 (UTC)Reply

@This, that and the other it's used outside of {{syn}}! a big example is under the see also header in the thesaurus namespace or when mentioning it in talks. Juwan (talk) 23:23, 19 October 2024 (UTC)Reply

If anything, a more generic Appendix link would maybe be useful for typing, like {{ap}}. —Justin (koavf)❤T☮C☺M☯ 12:10, 19 October 2024 (UTC)Reply

that's true! but why not both? that was just one example appendix among many that I could have chosen. Juwan (talk) 12:43, 19 October 2024 (UTC)Reply

I thought these were errors that would need to be fixed one at a time, until I noticed that there are "/testcases/" pages in CAT:Pages with module errors/hidden. Would it be possible to make all documentation pages of hidden pages also hidden? Pinging @Theknightwho. Chuck Entz (talk) 21:31, 19 October 2024 (UTC)Reply

I request to change the entry of Peranakan Indonesian as follow.

m["pea"] = { "Peranakan Indonesian", 653415, "poz-mly", "Latn", ancestors = "ms", } Xbypass (talk) 00:20, 20 October 2024 (UTC)Reply

Trying out Vector 2022 dark mode, I notice that QQ still has a light background; could it be given a dark-mode-compatible version? - -sche (discuss) 19:26, 21 October 2024 (UTC)Reply

@-sche:   Done Ioaxxere (talk) 03:15, 26 October 2024 (UTC)Reply

Hello everyone, I previously wrote on the 27th September to advise that the Wikidata item sitelink will change places in the sidebar menu, moving from the General section into the In Other Projects section. The scheduled rollout date of 04.10.2024 was delayed due to a necessary request for Mobile/MinervaNeue skin. I am happy to inform that the global rollout can now proceed and will occur later today, 22.10.2024 at 15:00 UTC-2. Please let us know if you notice any problems or bugs after this change. There should be no need for null-edits or purging cache for the changes to occur. Kind regards, -Danny Benjafield (WMDE) 11:28, 22 October 2024 (UTC)Reply

I wish to request that the following list of templates be deprecated and replaced with the template {{head}} in all appendix entries. toki pona, as an isolating language, does not have any type of inflection, making these templates simply redundant.

• {{tok-adj}} (adjectives)
• {{tok-adv}} (adverbs)
• {{tok-cardinal}} (cardinal numbers)
• {{tok-conj}} (conjunctions)
• {{tok-noun}} (nouns)
• {{tok-part}} (particles)
• {{tok-prep}} (prepositions)
• {{tok-pron}} (pronouns)
• {{tok-verb}} (verbs)

hope I didn't miss any, that'd be silly. Juwan (talk) 18:51, 22 October 2024 (UTC)Reply

This is normally dealt with at WT:RFDO, but I agree that these hand-coded headword templates need to be done away with. This, that and the other (talk) 01:29, 23 October 2024 (UTC)Reply

@This, that and the other I didn't know, sorry! moving discussion there. Juwan (talk) 08:14, 23 October 2024 (UTC)Reply

in my opinion these could possibly be replaced by content words and particles, though i don’t know БудетЛучше (talk) 11:19, 10 November 2024 (UTC)Reply

Per MediaWiki talk:Gadget-CodeLinks.js, I'm going to undefault CodeLinks.js and save our readers some bandwidth. Anyone who still wants the Wiktionary-specific features can reenable the gadget in their preferences. Ioaxxere (talk) 04:46, 24 October 2024 (UTC)Reply

While going through Category:Greek terms in nonstandard scripts, I found a number of entries where the second positional parameter (originally the third) was a transliteration rather than the expected plural. This is because of changes (including a move and a change to a redirect target) starting a bit over a decade ago that converted things so the behavior of that parameter was completely different, but without updating a number of the entries.

There seem to be dozens of these, so I'm bringing it here to see how best to remedy this. There are well over a thousand entries in Special:WhatLinksHere/Template:el-noun-proper, so simply changing the parameter to match a minority of old uses doesn't look like a good idea- besides which, all the ones I've checked so far have a transliteration that's redundant to the automated one.

As I see it, there are two options:

1. Have a bot go through and remove all the transliterations from the second (or third?) parameter
2. Add a named parameter for the transliteration, then have a bot go through and convert the positional parameters with transliterations to the named parameter.

Either way, if the bot detects a transliteration by the presence of Latin script, there are a couple of Latin-script keywords that are used instead of the Greek-script plural for indeclinable and uncountable proper nouns- so those will have to be allowed for.

Pinging Greek editors for their opinions and insights- (Notifying Saltmarsh, Sarri.greek, Rossyxan, FocalPoint): Chuck Entz (talk) 14:59, 24 October 2024 (UTC)Reply

@Chuck Entz hello. Could you please indicate two-three examples? This will help me in understanding the issue. FocalPoint (talk) 16:31, 24 October 2024 (UTC)Reply

M @Chuck Entz, if you are in a hurry to clean up, either way is fine. Cat:Greek proper nouns was at my 'to do' list (1899 reviews, most of them have a plural to be added, +ipa), after I finish the pending corrections (approx.1000) at WT:LTR#plan for Medieval Greek. PS May I ask, about Categories. Sometimes Subcategory members are fully indexed at a supracategory, sometimes they are not (they are different, extra members). Is this indicated in some way? Thank you ‑‑Sarri.greek ^♫ I 16:45, 24 October 2024 (UTC)Reply

On second check, @Chuck Entz, I need to do Category:Greek terms in nonstandard scripts by hand. The English ones are ok, The Greek are less than 180, and probably need more attention. ‑‑Sarri.greek ^♫ I 19:52, 24 October 2024 (UTC)Reply

I wanted to add customer-side to customer#Derived_terms, but this was seen as harmful. 81.217.68.78 14:36, 25 October 2024 (UTC)Reply

Unfortunately this is a global abuse filter, managed on Meta-Wiki, and we can't do anything about it here. The best way to avoid this type of issue is to simply create an account. This, that and the other (talk) 08:17, 27 October 2024 (UTC)Reply

Hello! I was attempting to add a detailed, factual description for the African beaked snake (Rhamphiophis oxyrhynchus) but was blocked by an automated filter. My goal was to contribute additional information on the species' appearance, habitat, behavior, diet, reproduction, and interactions with humans, presented in an informative, neutral tone. I believe this content would enhance understanding of the species for readers.

If there’s a specific part that triggered the filter or needs revision, please let me know, and I’d be happy to adjust the submission accordingly. Thank you for reviewing this! PrajinExplores (talk) 17:32, 27 October 2024 (UTC)Reply

Wiktionary is a dictionary. "[A]dditional information on the species' appearance, habitat, behavior, diet, reproduction, and interactions with humans" does not belong in a dictionary. — SURJECTION ^{/ T / C / L /} 17:43, 27 October 2024 (UTC)Reply

@PrajinExplores: You tried to create a long article that mostly didn't match Wiktionary formatting, and it was detected by a filter that was created to prevent people from posting long articles about themselves. The fact that you were doing it without an account probably didn't help. Really, the first few lines were all that would make sense for a dictionary entry, plus a single-sentence definition line.

What I saw in the filter log wouldn't be bad as a Wikipedia article, without the first few lines (they would only make sense in a Wiktionary entry) and with the addition of references and the standard Wikipedia templates. You might want to create a user page at Wikipedia, and submit the article as a draft. Chuck Entz (talk) 23:29, 27 October 2024 (UTC)Reply

The second parameter should not default to {{{1}}}. This should be fixed; apparently, this is not the first time this has happened. -BRAINULATOR9 (TALK) 23:20, 27 October 2024 (UTC)Reply

@Babr: who edited it fairly recently. —Justin (koavf)❤T☮C☺M☯ 00:56, 28 October 2024 (UTC)Reply

It looks like @Almanbet Janışev is the one who edited the relevant part of the template a month ago, and they have a history of breaking things. Chuck Entz (talk) 02:48, 28 October 2024 (UTC)Reply

MediaWiki message delivery 20:56, 28 October 2024 (UTC)Reply

Hi, is there an Android app for Wiktionary? How does it work? I have been advised that there is no infrastructure for push notifications for Android apps for sister wikis and I would be interested to know more. Related: phab:T378545. Thanks! Gryllida 23:13, 29 October 2024 (UTC)Reply

@Gryllida Others may be able to comment more, but I don't know of any mobile app for Wiktionary on any platform. Instead there is just the mobile website, which leaves a lot to be desired (but for which there are active efforts by editors like @Ioaxxere, @Surjection and others to improve its appearance). Benwing2 (talk) 05:49, 1 November 2024 (UTC)Reply

There was a Wiktionary Android app on the Google Play store back in the day; I had it on my old phone. I think it's the one mentioned here: mw:Wiktionary Mobile. It was good enough for basic browsing but the Android UI of the app felt outdated even 10 years ago, so it's no surprise it was retired. This, that and the other (talk) 09:20, 2 November 2024 (UTC)Reply

@Gryllida: The app English Dictionary - Offline uses Wiktionary for its data but unfortunately only covers English (the same company has versions in a couple other langauges as well). I wished for dedicated Wiktionary app as well but if no one steps up I guess I'll have to create it myself... Ioaxxere (talk) 02:46, 2 November 2024 (UTC)Reply

I wonder if this would be a useful template for anyone else. for non-English languages, there should be a template where you may pass parameters and it would output a definition line regarding the pronoun, similarly to templates such as {{place}} and {{demonym-noun}}. this would be good for standardisation and harmonisation between entries and possibly helpful for categorisation.

{{pronoun|pt|1|sg}}

First-person, singular pronoun; I, me

{{pronoun|es|2|pl|f|inf}}

Informal, feminine, second-person, plural pronoun; you, you all

{{pronoun|pt|3|obj|clitic}}

Oblique, third-person, clitic pronoun; him, her, it, them

Juwan (talk) 14:56, 31 October 2024 (UTC)Reply

@JnpoJuwan IMO this is a good idea, although I'm not sure how easy it is to automate the generation of the English-equivalent glosses. The way I imagine it, any arbitrary {{infl of}} tags could be supplied to {{pronoun}}, which would make it hard to come up with a generic algorithm to convert these tags into English-equivalent pronouns. This would be especially problematic, for example, with second-person pronouns, where English has only "you" and various dialectal plural forms (you all, you guys, y'all, yinz, etc.). For example, given the wealth of ways of saying "you" in European Portuguese (tu; archaic vós; você, vocês; o senhor, a senhora, os senhores, as senhoras; plus object variants te, ti, vos), any auto-generated English-equivalent gloss would be highly misleading. Instead you'd need a custom non-gloss definition following the output of {{pronoun}}. Japanese, among others, would be similar. Benwing2 (talk) 05:46, 1 November 2024 (UTC)Reply

@Benwing2 I believe that the English glosses being "lossy" in detail is not a critical issue. these to me serve as a way for others to have a basic idea of what pronoun is roughly equivalent in English. all the variants of "you" in Portuguese glossed as "you" is okay, as the rest of the non-gloss serves to disambiguate what is different. this is how glosses already work in some way right now. the template having a dedicate gloss template to override the automatic gloss would be a good compromise to me. Juwan (talk) 18:50, 1 November 2024 (UTC)Reply

in many terms that I have edited for anti-LGBTQ terms, I am in need of a better category to describe their usage than simply "derogatory", such as that these are used by broadly right-wing and alt-right groups to discredit LGBTQ people. currently many of these are tagged with the labels right-wing (no link or category) and alt-right, but following Wiktionary's category policy, they shouldn't as they are not related to right-wing ideas themselves but are used by their followers.

in this discussion, I am asking for advice on how to categorise these. talking on Discord and with GLAAD, I have proposed and been proposed these terms, with my opinions on them:

• conservatism: possibly too broad, and it was likely created for philosophical and economical terms.
• alt-right: too narrow for all terms.
• US conservatism: too narrow, the UK has coined many horrible terms, especially related to transphobia, these past few years.
• reactionary populism: possible. even though that would include a lot more terms, populists that are only homophobic but not transphobic are rare due the "philosophy" of the movement itself.
• anti-LGBTQ: possible, most direct! homophobia and transphobia should be aliases.

I prefer the latter two plus alt-right (for certain terms), but would like to see other's ideas. Juwan (talk) 15:42, 2 November 2024 (UTC)Reply

Re "right-wing": on the contrary, it's correct to use a {{label}} to label terms that are used by some set of people (such as the right wing), just like our "US" label and "American" category is for terms used by Americans (whether they relate to the topic of America or not). Using a label to indicate that the term merely relates to a topic (but is used by everyone) is generally substandard, because that should be indicated in the definition and categorized using topic categories, though it is a persistent practice. It might be useful to double-categorize terms also into a user-agnostic catch-all category for all anti-LGBTQ terms (or perhaps it wouldn't? we got rid of the "Racist names for countries" category, moving it to a type-of-discrimination-agnostic "Derogatory names for countries" category, to which the parallel would be not "Anti-LGBTQ terms" but "Derogatory terms for people"), but we should keep labelling (and categorizing) who uses the terms as well. - -sche (discuss) 17:33, 2 November 2024 (UTC)Reply

@-sche re re "right-wing": your knowledge is good to have yet this label still has the problem of being a bit vague in scope. how should we categorise the people that use these terms? re end. if we implement the category "derogatory terms for people", it makes sense to me to specify the type of discrimination. as people (or groups of people) are most commonly the target of discrimination, there is a way bigger number of terms that could be subcategorised. Juwan (talk) 19:38, 2 November 2024 (UTC)Reply

@JnpoJuwan I am inclined to agree with you that right-wing is a bit vague, and on top of that I'm sure there exist right-wingers who aren't homophobic (the Cheneys?). I like the idea of a poscat category Category:English homophobic slurs or Category:English anti-LGBTQ slurs (or similar) to hold these terms. IMO it should be a poscat category, not a topic category; compare Category:English ethnic slurs and Category:English military slang. As for the "who uses the terms", if the answer is "anyone who's homophobic/transphobic/etc.", then IMO the term doesn't need such a characterization, although it should have some indication on the definition line itself that it's a slur (compare the n-word, used by racists of all stripes and given several such labels). I think the most useful cases where it makes sense to characterize a term by its users is when it's specific to a community such as the alt-right or 4chan. Benwing2 (talk) 20:43, 2 November 2024 (UTC)Reply

I am fine with categorizing anti-LGBTQ slurs; to clarify, my parenthetical "or perhaps it wouldn't?" was only meant to express my uncertainty over whether others would agree that it was a good idea, because I noticed we seemed to be moving away from collecting terms based on type of discrimination when it came to "Racist names for..." categories (which were broadened to generic "Derogatory names for..."). You are right to point out we still have an "ethnic slurs" cat. (But "military slang" is categorizing who uses it again, isn't it, not who it's used towards?) I agree with your last point as well, that if "who uses it?" is "basically everyone who's trying to be derogatory to X" it doesn't need categorizing, but many terms are characteristically associated with specific subgroups of people (even if those subgroups are as broad as "US" or "right-wing"). - -sche (discuss) 20:58, 2 November 2024 (UTC)Reply

@Benwing2 I   support this. in short, for anti-LGBTQ (or any anti-X) terms:

• these are categorised under a dedicated poscat
• extreme or group-specific words are categorised in the group's related-to cat

Juwan (talk) 21:02, 2 November 2024 (UTC)Reply

@JnpoJuwan OK sounds good. What should the category name be? Should we have a single Category:English anti-LGBTQ slurs or separate Category:English homophobic slurs and Category:English transphobic slurs? Benwing2 (talk) 21:06, 2 November 2024 (UTC)Reply

@Benwing2 please create the wider LGBTQ one for now. if needed, I can split them into two or more later. Juwan (talk) 23:21, 2 November 2024 (UTC)Reply

I think "anti-LGBTQ" is the best name for this. I don't like using the terms "homophobic" or "transphobic" in a Wiki context, because I think it's less neutral. Many people who could be labelled as homophobic would not self-identify as such, but would be comfortable calling themselves anti-LGBTQ. In addition, words like "homophobic" or "Islamophobic" seem less like descriptors of the words than of the motivation for using them. But maybe that's splitting hairs. Andrew Sheedy (talk) 18:58, 4 November 2024 (UTC)Reply

Upon further thought, although I still prefer "anti-LGBTQ", I think I may be splitting hairs when talking about using the label "homophobic." Those who do not accept gay marriage for religious or other reasons but still avoid disrespecting or discriminating against gay people are typically not going around using slurs, so the distinction I was trying to make doesn't necessarily apply to the case at hand. Andrew Sheedy (talk) 19:16, 4 November 2024 (UTC)Reply

currently, text marked in a language that doesn’t use the latin script has special css for it. this is good for languages, where font support is scarce, faulty or just unreliable, however some major orthographies (cyrillic, greek etc) also have these styles, which are, on most viewports, very ugly. the default font for cyrillic is arial/helvetica, which are good fonts by themselves, but they’re too overused. in the case of cyrillic, modern built-in fonts (noto sans, roboto, sf pro, freesans, even unifont!) already have good cyrillic support, not even counting arial or helvetica. the same can be said about modern (but not ancient) greek, however unlike cyrillic, greek is not a script i use on a daily basis.

this seems to be caused by the -webkit-locale property, and i am sure there is a way to not use it without breaking the whole wiktionary. this changes the font in chrome, but not in firefox.

however, this is what happens if you disable the default styles gadget. if it is enabled (as it is for most users), the font rules are in load.php. and that thing is working as it should (even though it still is ugly).

see also:

• message in the discord server by JnpoJuwan

БудетЛучше (talk) 17:10, 2 November 2024 (UTC)Reply

I'm not quite sure what your request is. Benwing2 (talk) 20:49, 2 November 2024 (UTC)Reply

my request is to make the “disable default styles” work properly in chrome. (because currently it disregards wiktionary styles in favor of chromium styles. the ideal behavior would be to use neither.) БудетЛучше (talk) 10:36, 3 November 2024 (UTC)Reply

A fix (but a bad one):

* {
  -webkit-locale: "";
}

БудетЛучше (talk) 11:17, 10 November 2024 (UTC)Reply

I created a new sandbox module at Module:User:Tc14Hd/utilities/templates. However, as you can see by the formatting of the page, it is not recognized as a module but rather as regular wikitext. Maybe this has something to do with the fact that I first created it in the wrong namespace and only later moved it to the Module: namespace. Is there a way to fix this? Tc14Hd (aka Marc) (talk) 19:33, 2 November 2024 (UTC)Reply

It looks like you were right. I created a test copy with your code, which looked okay, so I copied it over your original and undeleted the earlier revisions. The last 2 steps required admin rights, though you could have created the copy yourself under a slightly different name and made those steps unnecessary. Chuck Entz (talk) 19:56, 2 November 2024 (UTC)Reply

Yes, I have encountered this issue before: a page created outside of the Module: namespace will not become a Module if moved, it has to be created in Module:-space. (I am tempted now to check what happens if a page is created in Module:-space and then moved out.) - -sche (discuss) 20:45, 2 November 2024 (UTC)Reply

Thank you! I already assumed that the only way of fixing it would be deleting the page and creating it again. Tc14Hd (aka Marc) (talk) 21:38, 2 November 2024 (UTC)Reply

@Chuck Entz @-sche For future reference, if you click on "Page information" in the sidebar, you'll see a "change" button next to the page content model in the table, which is for situations like this. You can only convert pages into (proper) modules in the Module namespace, though. I have a feeling only admins can do this, too. Theknightwho (talk) 14:42, 3 November 2024 (UTC)Reply

How can I prevent a template from crossing over into another language (level 2 headings)? For example, the Template:number box, when used on this page तीन in the section तीन#Marathi crosses over into the next language. This looks weird (see screenshot). I would ideally like to contain it within the language it was meant for.

Siddhant (talk) 01:47, 3 November 2024 (UTC)Reply

You can use {{-}}. It could be inserted directly into the template, but that is likely to cause issues that you don't want. Instead, you could put it into the entry's page at whatever points you find it necessary. —Justin (koavf)❤T☮C☺M☯ 01:58, 3 November 2024 (UTC)Reply

Thanks! That worked exactly how I intended. But I would really like this to be fixed everywhere. I can see 4 levels on how this should be fixed:

1. one-time usage on this page - Done
2. fix this specific template
3. fix all such language specific templates
4. fix how L2 headings are styled in general - we should have a {{-}} called before every L2 heading.

I'm not an experienced template/CSS-style editor, but I'm happy to learn if someone can guide me. Siddhant (talk) 06:00, 3 November 2024 (UTC)Reply

I was looking for a show-hide template and found this one, created 14 years ago. I have used it at Corinth for a long list of places, although it works OK, it won't work if I place # in front of it, to give the number 3 in the list. It's all a question of appearance, the template may not have been created for this purpose. DonnanZ (talk) 10:26, 3 November 2024 (UTC)Reply

@Donnanz I'm sympathetic to the idea of hiding long lists of places in definitions, but I'm going to remove the box for now due to the formatting issues, as it looks really bizarre on my laptop. We can reinstate it once we've worked out the best way to do it. Theknightwho (talk) 10:33, 3 November 2024 (UTC)Reply

It starts with a div, so it can't be in the middle of a list. I agree that it should probably be removed. —Justin (koavf)❤T☮C☺M☯ 10:35, 3 November 2024 (UTC)Reply

OK, I wasn't completely happy with it, I hope a satisfactory solution can be found. There's other place entries with the same problem. DonnanZ (talk) 10:58, 3 November 2024 (UTC)Reply

To be clear, you're stating that the problem is that the entries are too long? I disagree: an entry that has "a place in the United States" with a list of 20 or so localities is not really that unreadable. —Justin (koavf)❤T☮C☺M☯ 10:46, 4 November 2024 (UTC)Reply

Yes, I am. I agree that 20 or so isn't too bad, but Corinth has 49, so, unless you use the TOC, you have to wade through them all to get to Derived terms etc. Other examples are Washington (36), Lincoln (30 + 12 in Wisconsin), Franklin (39), Washington County (31). There are possibly others that escape me at the moment, but Corinth may be the most popular place name in the US for some reason. DonnanZ (talk) 12:12, 4 November 2024 (UTC)Reply

I will grant you that 49 is substantially more than 20-some (in fact, it's double that), but I still don't think it's an actual issue, since this isn't a print dictionary and scrolling with the space bar is pretty trivial. —Justin (koavf)❤T☮C☺M☯ 15:21, 4 November 2024 (UTC)Reply

Hmm, I doubt that every user would be impressed by that attitude. DonnanZ (talk) 23:55, 4 November 2024 (UTC)Reply

I also doubt that every single user would feel the same way about virtually any issue. If you have some proposal that "if >x entries, then use a collapsible box", I'm all ears. If not, it's just matters of personal preference and "I think this is too much for me" stuff, which is not particularly helpful across the dictionary. —Justin (koavf)❤T☮C☺M☯ 00:02, 5 November 2024 (UTC)Reply

If we can show and hide quotations, where #* and sometimes ##* is placed in front of each quote, it shouldn't be too difficult for a template writer to work something out for a long list of places. #* can't be used, that's only good for quotes. DonnanZ (talk) 14:50, 5 November 2024 (UTC)Reply

Agreed that on a technical level, it should be possible, but there's a difference between the definitional entries, which are the basic core of a dictionary versus illustrative quotations or other secondary material. —Justin (koavf)❤T☮C☺M☯ 20:22, 5 November 2024 (UTC)Reply

We can also show and hide translations. DonnanZ (talk) 15:13, 6 November 2024 (UTC)Reply

"Or other secondary material", yes. It's not the primary function of a dictionary to give translations into other languages, but it is the primary function to define words. —Justin (koavf)❤T☮C☺M☯ 02:52, 8 November 2024 (UTC)Reply

It could be argued that it's not a primary function to list quotes either, but we do and I have added loads over the years. Similarly with an excess of places with the same name, which probably won't interest every user. I have employed a few hide/show lists on my user page, including a US counties index. Do you remember deleting that? Feel free to browse it. DonnanZ (talk) 11:44, 8 November 2024 (UTC)Reply

I do. I don't see how it's germane here. —Justin (koavf)❤T☮C☺M☯ 11:47, 8 November 2024 (UTC)Reply

It is germane, as you put it, as my index employs hide/show. DonnanZ (talk) 12:09, 8 November 2024 (UTC)Reply

If it was included in mainspace, I could remove it from my user page @Benwing2. DonnanZ (talk) 19:08, 8 November 2024 (UTC)Reply

If others think that definitional entries should be hidden by default or in collapsible boxes, then I will support that as a consensus. I find it unlikely that others will think that is a good idea. —Justin (koavf)❤T☮C☺M☯ 12:10, 8 November 2024 (UTC)Reply

I would like to hear from other editors, especially template editors. DonnanZ (talk) 13:59, 8 November 2024 (UTC)Reply

it's saying my thing might be harmful, it's an abbreviation known as TND i've seen alot on fringe alt-right communities and it's seen to be known as Total n-word Death here is an example [here]https://soyjak.party/soy/thread/9005613.html#9005651 ... there are more and i have seen definitions for other words on here which is slightly more rare such as thoughbeit and they originate from that community Ptlrsyltursytuyrsl (talk) 19:51, 3 November 2024 (UTC)Reply

@Ptlrsyltursytuyrsl: please only add the definition if it complies with WT:DEROGATORY. Thanks. — Sgconlaw (talk) 19:08, 4 November 2024 (UTC)Reply

MediaWiki message delivery 20:50, 4 November 2024 (UTC)Reply

Why do so many pages link to {{ko-l}}? I was checking out "xx-l" templates and I saw that this one is linked to by countless pages with no mention of Korean. E.g. yttrandefrihet and grudzień. Ultimateria (talk) 01:17, 5 November 2024 (UTC)Reply

@Ultimateria I think this may be a remnant of when we were seeing lots of additional false "transclusions" for technical reasons that have now been rectified, but they still haven't all filtered through yet. After doing a null edit on both those pages, neither shows {{ko-l}} being transluded anymore. Theknightwho (talk) 20:37, 5 November 2024 (UTC)Reply

Wait, no, I'm wrong: [7]. Those aren't transclusions, so that is very strange. I'll investigate. Theknightwho (talk) 20:39, 5 November 2024 (UTC)Reply

It's something with {{inh+}} and {{der+}} specifically, but not {{bor+}}, suggesting that it's something to do with the way the first two are crude wrappers around other templates, since {{bor+}} isn't (as I re-implemented it properly a while ago). I can't remember the specifics, but there was a reason why it wasn't straightforward to do that with the other two, which is why I didn't do that at the time, but I'll investigate what's actually causing it, since it could be causing this issue with other templates as well. Theknightwho (talk) 20:52, 5 November 2024 (UTC)Reply

Okay, it's actually {{glossary}} (which is used inside {{inh+}} and {{der+}} but not {{bor+}}), and it's to do with the fact that the glossary template works out what all the possible valid glossary links are and puts them in Module:glossary/data, which involves scanning Appendix:Glossary. For technical reasons that aren't worth explaining, the fact that {{ko-l}} is on the glossary page means that this counts as a "link". However, it doesn't count as a transclusion, so I think this is probably okay, since links to non-content namespaces like templates are generally easy to filter out. Theknightwho (talk) 21:14, 5 November 2024 (UTC)Reply

Weird. Thanks for explaining. Ultimateria (talk) 02:18, 6 November 2024 (UTC)Reply

I think this needs to be modified to either ignore the Thesaurus and Citations namespaces, or allow a wider range of characters in them. Using {{ws sense|en|foo}} in headers seems to be standard in the Thesaurus namespace, but gets flagged, and using [[links, sometimes piped]] and labels: colons, then "quotation marks around gloss" seems to be standard/common on Citations pages. Valid edits in these two namespaces constitute a significant part of what the filter is currently catching. - -sche (discuss) 04:46, 5 November 2024 (UTC)Reply

@-sche I've removed the Thesaurus and Citation namespaces for now. I'll re-add them with a more appropriate regexes at some point, which account for the differences. Theknightwho (talk) 20:59, 5 November 2024 (UTC)Reply

On pl.wikt there are gadgets that influence how categories are displayed. The first one makes the category box appear below each language section, before the heading of the next language section (see voda). This makes searching categories easier, since we don't have 200 categories in one box; we could also remove ---- being placed before every new section with that. The second one makes most of the categories hidden, they can be displayed by clicking once. This makes it so that people uninterested in categories don't have to scroll through unnecessary content. The third one shows 60 entries from the category after pressing (↓). I think these would be usefull addition for en.wikt. I think modifing hide button to group categories would be even better, I made simple visualisation how it would look for English Mars:

Before clicking:

After clicking:

Sławobóg (talk) 20:57, 5 November 2024 (UTC)Reply

Practically impossible, even just the part about splitting the category list by language. How is a script supposed to know that Category:Helsinki slang is a Finnish category, for example? — SURJECTION ^{/ T / C / L /} 08:49, 6 November 2024 (UTC)Reply

But it works on pl.wikt. I think it just works like <references/> and prints categories ivnoked in a section by templates, and they are in the same order as templates. Sławobóg (talk) 08:57, 6 November 2024 (UTC)Reply

Very nice & useful idea M @Sławobóg to split Cats by language, perhaps with some half-line separator to help the eye. I think splitting for all sections is a bit too much. But i would like it with all categories at the very bottom (not at every language sector's end). Plus, needing a link on top #see Categories (like at {{minitoc}} or Example: salep#Categories to work automatically, would be nice. Also, at el.wikt, we place links for Categories directly at Language titles (see Wiktionary:Beer_parlour/2024/March#Language_titles_with_category) also at all labels {{label}}, so that readers can go immediately at the Category without scrolling down (e.g. try clicking labels at wikt:el:salep). But en.wiktionary never looks at little ideas coming from small wiktionaries. ‑‑Sarri.greek ^♫ I 09:44, 6 November 2024 (UTC)Reply

<references/> works on the backend, not on the frontend (as a gadget). That is a big difference. — SURJECTION ^{/ T / C / L /} 12:54, 6 November 2024 (UTC)Reply

@Surjection: Splitting categories by language also works with Tabbed Languages, which is a gadget. I can’t pretend to know the technical details, however. Maybe I’m wildly off-base somewhere. — Vorziblix (talk · contribs) 17:36, 6 November 2024 (UTC)Reply

TL's category splitting, like everything else in TL, is highly technically rudimentary and likely to break. — SURJECTION ^{/ T / C / L /} 18:19, 6 November 2024 (UTC)Reply

@Surjection we can tell the software that "Helsinki slang" is a Finnish category. how technically difficult is it really to add data on the connections between categories? I find this a very nice suggestion for organising catgeories that would be very welcomed, but of course I don't know the entire of process to implement it. Juwan (talk) 12:29, 6 November 2024 (UTC)Reply

It's not practical to add every single category to some massive blob of data that the gadget would use. There are quite a few of these categories too that aren't even part of the category tree system, so we cannot use that either. — SURJECTION ^{/ T / C / L /} 12:54, 6 November 2024 (UTC)Reply

A problem with precise links {{l|table|fr}} table#French is that we lose visibility of the See also line on top. Could this line become fixed? Thank you ‑‑Sarri.greek ^♫ I 10:46, 6 November 2024 (UTC)Reply

My understanding is that the purpose of {{also}} is to help people who search for entries using the search box. Direct links using {{l}} should already point to the right entry, so there's no need for the {{also}}. What use case are you thinking of, Sarri.greek? This, that and the other (talk) 03:48, 7 November 2024 (UTC)Reply

It has variaties (with accents etc) as in French, Greek, other. e.g. amo#Latin, ἁμαρτάνω#Ancient_Greek. Of course, one can scroll up and find them. Thank you M @This, that and the other. For a little moment, I can see it (desktop view), and then the text moves to its target. I thought it might be sticky, but then, if one does not need it, it might be irritating. ‑‑Sarri.greek ^♫ I 06:21, 7 November 2024 (UTC)Reply

I have started experiencing problems viewing hiragana in various places, for example, in translation tables and in usernames. All I see is a glyph consisting of a circle inside a square. Is anyone else experiencing this issue? I am using Mozilla Firefox 131.0.3. — Sgconlaw (talk) 22:31, 6 November 2024 (UTC)Reply

Updating to 132.0.1 seems to have solved the issue. — Sgconlaw (talk) 22:58, 6 November 2024 (UTC)Reply

I just saw someone add "further" to the adverb template at apart, so now it says "more or further". What about "farther"? When you can say "further/est" you can always say "farther/est", so the template should show both. 2A00:23C5:FE1C:3701:F4E8:32FB:F63A:C6A4 11:37, 8 November 2024 (UTC)Reply

A problem with <t:[[w:|]]> that is included in quote templates for translations of authors' names. The example from двустволка: #*

.

The translation of the name not visible although <t:Anton Chekhov> included in this quote-book. Now the name translations are gone in all ru quote-books. К.Артём.1 (talk) 19:20, 10 November 2024 (UTC)Reply