Wiktionary:Grease pit/2024/December

If a qualifier is used but not for the preceding form, it is added to the wrong form; e.g., if |mpqual= and |mpqual3= are used but not |mpqual2=, |mpqual3= is added to the second plural (|mp2=). J3133 (talk) 07:47, 1 December 2024 (UTC)Reply

E.g. see gōian. I don't think this is ideal formatting, is it? I tried putting the reference inside the template to avoid this, but that breaks the link, so it isn't a valid solution. Urszag (talk) 11:06, 2 December 2024 (UTC)Reply

@Urszag I had a go at fixing this at . Of course, as with any CSS change, I may have introduced a new bug somewhere else, so it will be something to keep an eye on. This, that and the other (talk) 22:58, 2 December 2024 (UTC)Reply

What is the rationale for Anglian appearing below rather than on the inflection line? DCDuring (talk) 15:13, 3 December 2024 (UTC)Reply

The following content should be added to Category:Request templates § Deletion and verification.

• {{derogatory|date=DATE|rfd=|rfv=}} – Request deletion of an uncited derogatory term unless quotations are promptly added

There is another edit request at Category talk:Request templates § Edit request: RFM templates that I also support. Daask (talk) 17:42, 2 December 2024 (UTC)Reply

@Daask I reduced the protection level to autoconfirmed, so you should be able to edit it now. This, that and the other (talk) 22:25, 2 December 2024 (UTC)Reply

MediaWiki message delivery 22:23, 2 December 2024 (UTC)Reply

the sound of messages recieved 160.2.117.67 01:37, 3 December 2024 (UTC)Reply

See Wiktionary:Criteria for inclusion. —Justin (koavf)❤T☮C☺M☯ 01:44, 3 December 2024 (UTC)Reply

I need to add some information there so that categories I created show up on the category tree. I’d appreciate it if someone could either tweak permissions so I can edit the page or paste the information I need to add in my stead. Ping @Benwing2 so he can be aware I made this post.

Below is the code I need added.

raw_categories = {
    description = "The following terms were officially used in Brazilian Portuguese — but not European Portuguese — until December 2015, when the period of transition between the previous spelling standard and the ] ended.",
    parents = {
        {name = "Portuguese forms superseded by AO1990", is_label = true, lang = pt},
        {name = "Brazilian Portuguese forms", raw = true},
    },
}

raw_categories = {
    description = "The following terms were officially used in European Portuguese — but not Brazilian Portuguese — until October 2015, when the period of transition between the previous spelling reform and the ] ended in Cape Verde. Portugal’s transition period ended in May 2015.",
    parents = {
        {name = "Portuguese forms superseded by AO1990", is_label = true, lang = pt},
        {name = "European Portuguese forms", raw = true},
    },
}

Polomo47 (talk) 07:13, 3 December 2024 (UTC)Reply

I've been pondering - for at least Polish, the Further reading section can get very full - each template however is often used for something on a page, be it to support something such as Middle Polish or dialectal pronunciations/definitions, or obsolete definitions, etc., and also it's generally all the most commonly referenced material within Polish linguistics. This can become unwieldy, so I was thinking, what if we had a template such as {{bibliography}} that had some similar features of {{reflist}}, i.e. it can control the size of the references and such, but also local grouping, i.e. I could create categories "Middle Polish" and have the appropriate templates nested under that, or "Dialectal:" and then a subgrouping "Masovian", etc. etc. Vininn126 (talk) 09:58, 5 December 2024 (UTC)Reply

The Module:gender and number currently gives a large array of possible ways of specifying gender (such as m or f by sense), while it seems to disallow any class specification more complex than class foo. For many languages with noun classes, this is enough I guess, but there are cases where I’d like to give more information (such as in Swahili).

One issue is that there are different conventions, and they’re horribly confusing. The pan-Bantu convention, for example, is to number all classes, singular and plural separately. So *kɪ̀- and its descendants is class 7, *bì- is class 8, etc. In some modern Bantu languages the classes neatly pair up in singular and plural, so for example in Luganda, those two are jointly called class IV (see here for example).

I don’t think there’s a set convention for roman vs. arabic numerals. Our Appendix:Swahili noun classes uses roman numerals for the Proto-Bantu classes, for one. This means that any drive-by user who sees something labeled class IV can’t know whether that’s Proto-Bantu class 4, or some language-specific conflated class or other, or something else entirely.

One solution is using noun prefixes: class ki- etc. But that can be ambiguous. Or we could write class ki-(VII) and the like, but that gets clunky. Another is to put links to the appendix, as {{sw-noun}} currently does. This is not possible using the {{head}} template, I think. ({{sw-noun}} is currently hard-coded, no Lua, no {{head}} for inflections or class specifications, etc. I’ve started working on a version using our current infrastructure.)

To me the best solution would be more informative mouseovers: so we write class VII, and on mouseover instead of the rather unhelpful “noun class VII”, we’d see “class ki- (VII)”, or something of the like. But that would require modifying Module:gender and number in ways that go way beyond my abilities. Add to this the existence of Swahili nouns that have different class agreement by sense, and I hope you understand my pickle. ☺ MuDavid 栘𩿠 (talk) 03:05, 6 December 2024 (UTC)Reply

@MuDavid This would require adding language-specific info to Module:gender and number, but there is precedent for doing this as there are other modules with lang-specific info attached. To handle Swahili nouns with different class agreement by sense, you'd create multiple headwords, one per class agreement (they don't have to be in separate Etymology sections if it doesn't make sense to do so). Benwing2 (talk) 21:49, 7 December 2024 (UTC)Reply

Given there’s many languages with class agreement, and they tend to have many classes, I guess the lang-specific info had better go into separate data pages, no? MuDavid 栘𩿠 (talk) 02:45, 9 December 2024 (UTC)Reply

Yes, there would be one module per language. Benwing2 (talk) 05:11, 11 December 2024 (UTC)Reply

Today I discovered there are words that can take two different agreement classes without any change in meaning, apparently based on whim of the speaker. I think I could hack together a solution in Module:sw-utilities, but I also think extended functionality in Module:gender and number would be better. MuDavid 栘𩿠 (talk) 03:43, 13 December 2024 (UTC)Reply

@MuDavid Headwords support multiple genders, so this wouldn't be a problem. As for adding language-specific classes, can you give me a list of the Swahili noun classes and how you want them to appear? Keep in mind that mouseovers/tooltips don't work on mobile, so we might want a different display for phones. Benwing2 (talk) 03:53, 13 December 2024 (UTC)Reply

The left column in this table is a almost full list. There’s some words with mixed agreement m_(I)/n_(IX), such as rafiki.

I feared you’d bring up mobile at some point. @tbm, do you have any ideas?

On desktop I think my preferred version would be to show the roman numeral (as is currently the case), and give a mouseover with extra information, such as “agreement in ki class_(VII)” for example (but without the link/markup as that doesn’t work?).

Is a completely different display on phones possible? If so, something like “ki_(VII)” would be my preferred output (removing the word “class” to reduce clutter as a tradeoff for showing the prefix as well). If not, I’d vote for what I described for desktop above (to be consistent with other Bantu languages in look); if our convention isn’t clear, visitors can look up the adjective they need to decline to see it all, like: if you open the inflection table at -angu, there’s a full list with the roman numerals given. The extra information from the mouseover isn’t vital.

– MuDavid 栘𩿠 (talk) 09:15, 13 December 2024 (UTC)Reply

@MuDavid Yes, it should be possible to display different content on mobile phones. @Ioaxxere @Surjection sorry for the ping again; it looks like the way to do this is to conditionalize on the screen width, per and . Different sets recommend a max width of 800-1000 pixels for the mobile cutoff. For some reason we don't have nice CSS classes already provided to make this easy; any objections to me adding this, or other thoughts? Benwing2 (talk) 09:33, 13 December 2024 (UTC)Reply

I'm not sure why we are talking about viewport width when MediaWiki has a fully separate mobile site/frontend/skin which you can easily check via CSS or any similar means. However, I'm not very fond of the idea of showing different text on mobile than on desktop. I've always considered it disappointing that mobile browsers never implemented any way to show tooltips. — SURJECTION ^{/ T / C / L /} 10:29, 13 December 2024 (UTC)Reply

@Surjection Sorry, how do you check for the MediaWiki mobile site/frontend/skin via CSS? Benwing2 (talk) 11:04, 13 December 2024 (UTC)Reply

One option is to check for body.mw-mf. — SURJECTION ^{/ T / C / L /} 12:29, 13 December 2024 (UTC)Reply

@Surjection I was able to get desktop-only using templatestyles in conjunction with Template:Benwing2/nomobile.css, but (a) I can't figure out the corresponding mobile-only settings (see Template:Benwing2/mobileonly.css and User:Benwing2/test-mobile, which doesn't work), and (b) this seems overly complex. Is there a simple way of checking without having to create special templatestyles CSS files? If not, can we just put some CSS in MediaWiki:Mobile.css and MediaWiki:Common.css to make this easier? Benwing2 (talk) 20:45, 13 December 2024 (UTC)Reply

One would probably want to define something like (untested)

body .mobile-only { display: none; }

body.mw-mf .mobile-only { display: unset; }

body.mw-mf .desktop-only { display: none; }

— SURJECTION ^{/ T / C / L /} 21:09, 13 December 2024 (UTC)Reply

Something else I noticed: if a gender is missing, the entry goes into the category “Requests for gender in lang entries”. But if it’s a class that’s missing (through |g=c?) then it isn’t. I for one think it should. @Tbm, do you agree? MuDavid 栘𩿠 (talk) 03:38, 11 December 2024 (UTC)Reply

Yes, that would be nice! tbm (talk) 05:01, 11 December 2024 (UTC)Reply

That’s been implemented. Thanks @Benwing2! MuDavid 栘𩿠 (talk) 06:32, 11 December 2024 (UTC)Reply

The template {{bnt-verb}} seems to have a problem with infinitive generation: it only gives “*kʊ̀ ”. See here for example; it should be “*kʊ̀béeka” (I think). It used to work, and no edits to the template were made since then, so the problem must be “backstage”, and I don’t know how to figure this out or solve it myself. MuDavid 栘𩿠 (talk) 03:10, 6 December 2024 (UTC)Reply

At WT:LOL/E, at the bottom of the page, it reads

Lua error in Module:languages at line 1896: attempt to index local 'parent' (a nil value)

I found this while looking for something else and am not sure its important, but if it is, can we fix it? Thanks. —Soap— 19:06, 6 December 2024 (UTC)Reply

It was a known bug that was fixed within 35 minutes but involved potentially thousands of entries, so it may take a while to clear comppletely. Chuck Entz (talk) 20:15, 6 December 2024 (UTC)Reply

What does insert pages into Category:Pages with entries and its subcats? Is there a documentation of the system somewhere? Taylor 49 (talk) 19:37, 6 December 2024 (UTC)Reply

@Taylor 49 it's done at Module:headword/page#L-884--L-885. Not sure what documentation is needed - it seems self-explanatory. Initially I was sceptical that the system was of any value, but it turns out to be essential for tracking entries with missing headword lines. This, that and the other (talk) 00:04, 7 December 2024 (UTC)Reply

There seems to be about 20000 pages which should be in the category but aren't. 115.188.72.131 11:33, 7 December 2024 (UTC)Reply

Thanks.

local content = raw_title:getContent()

Does the page "read itself" on every template calling Module:headword, ie again for every word class for every language? Taylor 49 (talk) 15:37, 7 December 2024 (UTC)Reply

@Taylor 49 No. There are multiple levels of caching, so that the page reads and processes itself only once per page. You should ask @Theknightwho, who knows more about how this works. Benwing2 (talk) 21:42, 7 December 2024 (UTC)Reply

@Taylor 49 @Benwing2 Even after a few months, the category is still populating, because those pages haven't been refreshed in the cache yet. I suspect pages are prioritised by the server based on daily/monthly page views, which will be 0 for many non-lemma pages. You can find all pages which aren't yet in the category with the search -incategory:"Pages with entries", selecting the mainspace and Reconstruction namespace (note the hyphen at the beginning, which makes it a negative search). Searching that just now gives 23,649 pages. Theknightwho (talk) 21:58, 7 December 2024 (UTC)Reply

Good pickup by the IP - these are entries that only use archaic headword-line templates like {{lt-adv}} that don't call into the module. This, that and the other (talk) 21:47, 7 December 2024 (UTC)Reply

Yuck, I didn't realize there were still headword templates coded like that but it makes sense, there are a lot of dusty corners in Wiktionary. Benwing2 (talk) 21:52, 7 December 2024 (UTC)Reply

@Benwing2 I found a few more if you have time and inclination: {{art-nav-noun}} {{ast-num-card}} {{blk-pron}} {{br-pron}} {{ca-adj-sup}} {{ch-adj}} {{ff-root}} {{gel-noun}} {{ins-interj}} {{io-part}} {{io-pron}} {{ja-altread}} {{kkh-verb}} {{ko-syllable-hanja}} {{ksd-pron}} {{ml-con}} {{sq-personal pronoun}} {{sq-poss-adj}} {{syl-beng-noun}} {{tr-pron}} {{txb-noun-decl}}. I will do some if I have time.

Also most of the sign language headword templates, which are terribly unloved. This, that and the other (talk) 12:06, 8 December 2024 (UTC)Reply

Actually a number of these are simply unused and can probably be deleted. I also found a bunch of unused Norwegian headword templates which I didn't list above... This, that and the other (talk) 12:10, 8 December 2024 (UTC)Reply

I can see that 5 of the listed "dusty" templates are already deleted, after only 6 hours. @Theknightwho: Where is the caching implemented? To me it looks like that the page reads, parses and categorizes itself on every word class for every language, that can be over 100 times for some words. What ensures that this task is done only one time per page? AFAIK mw:Extension:Variables is banned on WMF wikis. Taylor 49 (talk) 19:43, 8 December 2024 (UTC)Reply

@Taylor 49 Calls to getContent() are cached automatically in MediaWiki, so the actual database call happens only once per page. Furthermore, the heavy-duty page parsing is loaded using mw.loadData() through Module:headword/data, and data loaded this way is cached and executed only once per page. The code on line 749 of Module:headword only calls process_page() if the pagename is specified using the `pagename` field and isn't the same as the actual pagename (which generally only happens on test and documentation pages); otherwise it simply uses the precomputed processed page. There are probably other levels of caching as well that @Theknightwho knows more about. Benwing2 (talk) 20:23, 8 December 2024 (UTC)Reply

@This, that and the other I converted or deleted most of them. There are 4 left that aren't deleted or crossed out. Benwing2 (talk) 22:26, 8 December 2024 (UTC)Reply

@Benwing2 @IP 115 @Theknightwho I did some systematic purging, fixed the sign language headword templates (admittedly somewhat crudely), and added an invocation of {{head}} inside {{cuns}}. This has reduced the number of pages in the search from >20,000 to <100.

Once this filters through to the Toolforge replicas, I will adjust WT:Todo/Lists/Entries with missing headword lines to capture these pages and any future pages that are not in Cat:Pages with entries. This, that and the other (talk) 11:13, 10 December 2024 (UTC)Reply

local function process_page(...)
		process_page = require(headword_page_module).process_page
		return process_page(...)
end

local function get_data()
		m_data = load_data(headword_data_module)
		return m_data
end

Yeah I can see that Module:headword/page containing expensive

local content = raw_title:getContent()

is imported at least 2 times, once via "require" and once via "loaddata" indirectly via Module:headword/data. Taylor 49 (talk) 20:41, 8 December 2024 (UTC)Reply

@Taylor 49 process_page is only run directly by Module:headword if the |pagename= is set, which is almost never the case in mainspace, so raw_title:getContent() is still only being run once per page in the vast majority of cases. Theknightwho (talk) 21:12, 8 December 2024 (UTC)Reply

Is "pagename=" intended exclusively for testing? I use "pagenameoverridetestonly=" for such cases. ;-) Taylor 49 (talk) 21:17, 8 December 2024 (UTC)Reply

It's for testing and documentation pages. Benwing2 (talk) 21:20, 8 December 2024 (UTC)Reply

I suggest to drop the usage of the old Template:el-form-of-nounadj that is clearly redundant to Template:inflection of. Bots can help to change them. Octahedron80 (talk) 00:46, 7 December 2024 (UTC)Reply

Yes, indeed. This is a question for WT:RFDO really, but it is redundant.

There is one issue: Greek comparative adjective forms tend to be presented as non-lemma forms of the positive adjective, instead of non-lemma forms of the comparative adjective. Compare:

• Latin seniorem:
  • accusative masculine/feminine singular of senior
• Ancient Greek ἐγκυκλιωτέραις (enkukliōtérais):
  • feminine dative plural of ἐγκῠκλῐώτερος (enkukliṓteros)
• Greek λιγότερε (ligótere):
  • (deprecated template usage) Vocative masculine singular, comparative form of λίγος (lígos).
    instead of
    vocative masculine singular of λιγότερος (ligóteros)

I have to admit the nonstandard approach taken by {{el-form-of-nounadaj}} does seem somewhat more useful to the reader! (Even more useful would be something like "vocative masculine singular of λιγότερος (ligóteros), comparative degree of λίγος (lígos)".) But this is not something that is properly supported by {{inflection of}}. This, that and the other (talk) 01:07, 7 December 2024 (UTC)Reply

@This, that and the other Actually it is. See 𐌱𐌻𐌴𐌹𐌸𐌾𐌰𐌽𐌳𐌰𐌽𐍃 for an example of this in action. Language-specific support is specified in Module:form of/lang-data/got. Benwing2 (talk) 09:17, 7 December 2024 (UTC)Reply

@Benwing2 my apologies - I should have known you would think of it - you think of everything! Well there is certainly no reason to keep {{el-form-of-nounadj}} as it is then. It could be made into a wrapper for {{inflection of}} initially (@Octahedron80). This, that and the other (talk) 09:55, 7 December 2024 (UTC)Reply

@This, that and the other In order to convert to the "even more useful" form you mentioned above, the bot would have to determine what the comparative adjective lemma is, which isn't currently specified in the call to {{el-form-of-nounadj}}. Do you know how hard that is? Can it be inferred from the term pagetitle itself? Benwing2 (talk) 21:45, 7 December 2024 (UTC)Reply

@Benwing2 it is derivable by adding ος to the |compstem= parameter of the {{el-decl-adj}} template. This, that and the other (talk) 09:11, 8 December 2024 (UTC)Reply

@Octahedron80 @This, that and the other @Saltmarsh I have a script ready to convert {{el-form-of-nounadj}} to {{infl of|el}}. I found it easier to derive the comparative/superlative base lemma directly from the non-lemma pagetitle by chopping off the ending and replacing it with -ος. Saltmarsh, in almost all cases the resulting text is shorter and easier to type. For example:

# {{el-form-of-nounadj|μόνος|g=m|c=gen|n=s}}
# {{el-form-of-nounadj|μόνος|g=n|c=gen|n=s}}

becomes

# {{infl of|el|μόνος||gen|m|s}}
# {{infl of|el|μόνος||gen|n|s}}

and can further be compressed to

# {{infl of|el|μόνος||gen|m//n|s}}

(I have a separate script to do this compression.)

The script automatically adds the |comp-of= or |asup-of= params as needed. For example on μεγαλύτερου (megalýterou),

# {{el-form-of-nounadj|μεγάλος|g=n|c=gen|n=s|d=c}}

becomes

# {{infl of|el|μεγαλύτερος||gen|n|s|comp-of=μεγάλος}}

which displays as

1. genitive neuter singular of μεγαλύτερος (megalýteros), the comparative degree of μεγάλος (megálos)

I am planning to run this script tomorrow. Benwing2 (talk) 08:52, 10 December 2024 (UTC)Reply

• @Sarri.greek, Benwing2 Can I stress that in spite of my resistance I am not adverse to change. Common formats will bring a unified feel to Wiktionary.
  Nevertheless {{el-form-of-nounadj}} and similar language specific templates have the advantage of speeding up data entry, and more importantly making editing easier for new editors (one look at the Documentation for {{inflection of}}, which refers onward to modules etc, puts me off and it certainly do it for newbies. Experienced editors cannot see how things look to newcomers, and life here has become much more technical since I started. Some of this could be overcome by rewriting Wiktionary:About Greek - a job I could do without.

One question which my look at the documentation hasn't helped me with. Can {{inflection of}} accomplish mixed cases and genders as {{el-form-of-nounadj}} does?

    # {{el-form-of-nounadj|μικρός|g=n|c=nav|n=s}}
  gives:
    1. Nominative, accusative and vocative neuter singular form of μικρός (mikrós).

If I have a problem (or lack the patience) reading the documentation new editors certainly will.

With good will !   — Saltmarsh^☮ 10:52, 10 December 2024 (UTC)Reply

Dear @Saltmarsh, the Wiktionary:About Greek is ok, I do not see anything that needs correcting. The universal system for writing heads, inflections etc covers everything, I think. Now, the robots are doing what we used to do manually in the earlier days of wiktionary, so, please do not worry. ‑‑Sarri.greek ^♫ I 12:55, 10 December 2024 (UTC)Reply

PS to @WingerBot, Benwing, notifying my admin @Saltmarsh. Whatttt is this? στήριξα in ancient and modern Greek?? The way things are written are different in grc and el? The point is to make them similar? Why is grc like that? Why should an editor have to learn 2 or even 3 ways to write one and the same thing? Please unify them. If not unified, what is the point of changing only one of them? ‑‑Sarri.greek ^♫ I 15:55, 10 December 2024 (UTC)Reply

@Saltmarsh The equivalent of {{el-form-of-nounadj|μικρός|g=n|c=nav|n=s}} using {{infl of}} is {{infl of|el|μικρός||nom//acc//voc|n|s}}. I assume this is what you mean by "mixed cases and genders"; you just put the different cases and genders together and separate by //. In general, if you are not sure how something works, check out the examples first; Example 2 under {{inflection of}} demonstrates exactly this usage. As for having a separate way of doing things for every language, that simply won't work; it leads to siloed language communities, making it hard or impossible for new users to contribute, and you get a non-unified look that makes the whole site look amateurish. Greek in fact is particularly bad because there's a whole ecosystem of weird templates like {{el-example}} that do general things in a Greek-specific way and really aren't necessary. Furthermore, documentation for individual-language-specific templates tends to be worse, and worse-maintained, that the language-agnostic documentation. For example, the documentation for WT:About Greek doesn't actually say anything about Greek templates, and the documentation at Wiktionary:Greek_headword-line_templates was completely out-of-date until I fixed it up to some extent last night.

@Benwing2 Thanks — I'm sure that we shall manage !   — Saltmarsh^☮ 10:34, 11 December 2024 (UTC)Reply

@Sarri.greek I assume you are referring to the headword templates. Ancient Greek is already using {{inflection of}} for its definition lines and will be unified with Modern Greek as soon as I make the change to obsolete {{el-form-of-nounadj}}. I will do the Ancient Greek headword templates next; they are no more necessary than the Modern Greek ones we just eliminated.

Respectfuly, Benwing2 (talk) 08:09, 11 December 2024 (UTC)Reply

@Saltmarsh @Sarri.greek I have deprecated {{el-form-of-nounadj}}. I am planning on doing the same to {{el-form-of-verb}}, and then I'll tackle the Ancient Greek headwords. Benwing2 (talk) 08:09, 13 December 2024 (UTC)Reply

This gadget is on by default for everyone. However, I can't tell what it actually does. I tried comparing a few pages relating to the revision deletion log with it turned on and off and never noticed a difference. Is it nonfunctional? Ioaxxere (talk) 01:53, 8 December 2024 (UTC)Reply

Based on Kephir's edit summary when creating it ("display revdel log on inaccessible revision/diff pages") and its description ("Display excerpts from the revision deletion log when trying to view deleted revisions and diffs between them"), I gather it pulled the relevant revision deletion event (who suppressed the text, edit summary, or username of a given revision) out of the log and displayed it when someone tried to view a revision or diff which had been hidden, to prevent people being confused like this about a situation where information is missing like the username here. (We still have a gadget which does something vaguely similar, pulling up a more informative excerpt of the block log on blocked users' contrib pages.) As far as I can tell, it doesn't work anymore; probably some MW change broke it. In theory it'd be useful, but it might no longer be possible to make it work: which admins have deleted any revisions of a given page is logged publicly, but does anything let non-admins see which admins deleted which exact revisions? - -sche (discuss) 06:05, 9 December 2024 (UTC)Reply

I believe the info is extractable from the API, for example . In the first log ID listed at the present moment (logid 53474838), we can see that Surjection hid the edit summary of revisions 82802609 and 82802607. This API response looks identical when I open it in an incognito window as a logged-out user. This, that and the other (talk) 10:17, 9 December 2024 (UTC)Reply

Neat. Well, if someone wants to make a version of this gadget that works, I would say it'd be "somewhat useful, but not necessary enough to be a priority". (In the meantime, to Ioaxxere's point, it seems like we could turn this gadget off, since it doesn't seem to do anything at all...?) - -sche (discuss) 17:59, 9 December 2024 (UTC)Reply

@-sche: Good to know — in that case I'll remove it from the list of default gadgets and if there's no interest in fixing it after some time then we might want to remove it entirely. Ioaxxere (talk) 05:50, 11 December 2024 (UTC)Reply

This is an old template that shows up in Wiktionary:Todo/Lists/Template language code does not match header because it's not just used in Crimean Tatar entries. It's very simple: it takes positional parameters that are the endings for 5 cases (genitive, dative, accusative, locative, and ablative), and displays {{lang|crh|{{PAGENAME}}}} labeled as the nominative, and the other cases consisting of the same followed by the relevant positional parameter. It doesn't categorize, and it doesn't link to anything (except for "{{m|crh||{{PAGENAME}}}}" in the header, which of course doesn't do anything).

It's used in Turkish, Tatar, and Zazaki entries as well as Crimean Tatar ones, with what looks like 641 transclusions (there's at least one false positive due to {{desctree}}). Is this a problem? Or should we just add it to the excluded-template page for the Todo list? Chuck Entz (talk) 01:40, 9 December 2024 (UTC)Reply

@Chuck Entz This should be split into language-specific variants. For one thing, it (now) has actual links in it that use the crh code, meaning it will link to the wrong language for any other language. Benwing2 (talk) 08:07, 13 December 2024 (UTC)Reply

As part of the rollout of Temporary Accounts, we are working to ensure that tools, gadgets, bots, user scripts, AbuseFilters, and any other community-owned code continue to work smoothly.

What are Temporary Accounts?

Temporary accounts are a new type of account for unregistered editors. Instead of showing IP addresses publicly, these accounts will assign temporary user IDs to logged-out editors. Tools that rely on IP addresses or workflows for logged-out users might need updates to function correctly. Temporary accounts are already live on some pilot wikis, with more pilot deployments planned for February and full rollout on all wikis in May.

How you can help

• Check if code (whether on Toolforge or on wiki, that is: tools, gadgets, bots, or user scripts) you created or frequently use works on the wikis where temporary accounts are already active. Here is the list of content wikis, and here is the list of beta cluster and test wikis with temporary accounts.
• If you notice a tool that might be impacted, we encourage you to try updating it based on our developer documentation guide.
• Do add the tools you see as impacted on this page. We want to monitor them to make sure that everything is working as expected.
• Take a look at Abuse Filters used on your wiki. Any filter using IPs via user_name will no longer be able to do so. Those filters need to be updated to use user_unnamed_ip instead. A comment from our engineers: "The main use case should be if you try something like ip_in_range(s). Things that map to usernames should be broadly ok, as they’ll continue to map to temporary account names." If you have more questions about AbuseFilter, you may add a comment on the Phabricator ticket T369611.
• If you find any issues or have comments or questions, let us know on the project talk page. You can also join the dedicated Discord thread for support and to share feedback to the team.

By helping test and report, you will ensure important tools work smoothly with this update. Thanks for your support! Udehb-WMF (talk) 07:51, 9 December 2024 (UTC)Reply

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• Technical documentation contributors can find updated resources, and new ways to connect with each other and the Wikimedia Technical Documentation Team, at the Documentation hub on MediaWiki.org. This page links to: resources for writing and improving documentation, a new #wikimedia-techdocs IRC channel on libera.chat, a listing of past and upcoming documentation events, and ways to request a documentation consultation or review. If you have any feedback or ideas for improvements to the documentation ecosystem, please contact the Technical Documentation Team.

Updates for editors

• Later this week, Edit Check will be relocated to a sidebar on desktop. Edit check is the feature for new editors to help them follow policies and guidelines. This layout change creates space to present people with new Checks that appear while they are typing. The initial results show newcomers encountering Edit Check are 2.2 times more likely to publish a new content edit that includes a reference and is not reverted.
• The Chart extension, which enables editors to create data visualizations, was successfully made available on MediaWiki.org and three pilot wikis (Italian, Swedish, and Hebrew Wikipedias). You can see a working examples on Testwiki and read the November project update for more details.
• Translators in wikis where the mobile experience of Content Translation is available, can now discover articles in Wikiproject campaigns of their interest from the "All collection" category in the articles suggestion feature. Wikiproject Campaign organizers can use this feature, to help translators to discover articles of interest, by adding the <page-collection> </page-collection> tag to their campaign article list page on Meta-wiki. This will make those articles discoverable in the Content Translation tool. For more detailed information on how to use the tool and tag, please refer to the step-by-step guide.
• The Nuke feature, which enables administrators to mass delete pages, now has a multiselect filter for namespace selection. This enables users to select multiple specific namespaces, instead of only one or all, when fetching pages for deletion.
• The Nuke feature also now provides links to the userpage of the user whose pages were deleted, and to the pages which were not selected for deletion, after page deletions are queued. This enables easier follow-up admin-actions. Thanks to Chlod and the Moderator Tools team for both of these improvements.
• The Editing Team is working on making it easier to populate citations from archive.org using the Citoid tool, the auto-filled citation generator. They are asking communities to add two parameters preemptively, archiveUrl and archiveDate, within the TemplateData for each citation template using Citoid. You can see an example of a change in a template, and a list of all relevant templates.
• One new wiki has been created: a Wikivoyage in Indonesian (voy:id:)
• Last week, all wikis had problems serving pages to logged-in users and some logged-out users for 30–45 minutes. This was caused by a database problem, and investigation is ongoing.
• View all 19 community-submitted tasks that were resolved last week. For example, a bug in the Add Link feature has been fixed. Previously, the list of sections which are excluded from Add Link was partially ignored in certain cases.

Updates for technical contributors

• Codex, the design system for Wikimedia, now has an early-stage implementation in PHP. It is available for general use in MediaWiki extensions and Toolforge apps through Composer, with use in MediaWiki core coming soon. More information is available in the documentation. Thanks to Doğu for the inspiration and many contributions to the library.
• Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. On December 4, the MediaWiki Interfaces team began rerouting page/revision metadata and rendered HTML content endpoints on testwiki from RESTbase to comparable MediaWiki REST API endpoints. The team encourages active users of these endpoints to verify their tool's behavior on testwiki and raise any concerns on the related Phabricator ticket before the end of the year, as they intend to roll out the same change across all Wikimedia projects in early January. These changes are part of the work to replace the outdated RESTBase system.
• The 2024 Developer Satisfaction Survey is seeking the opinions of the Wikimedia developer community. Please take the survey if you have any role in developing software for the Wikimedia ecosystem. The survey is open until 3 January 2025, and has an associated privacy statement.
• There is no new MediaWiki version this week.

Meetings and events

• The next meeting in the series of Wikimedia Foundation discussions with the Wikimedia Commons community will take place on December 12 at 8:00 UTC and at 16:00 UTC. The topic of this call is new media and new contributors. Contributors from all wikis are welcome to attend.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 22:16, 9 December 2024 (UTC)Reply

I recently tried to use the book creation function to compile a list of entries for personal use and was shocked to find out it isn't saved across sessions. Can i ask what the rational for this is?

If there is no underlying obstacle to this, i'd kindly request allowing users to compile and manage any number of books they desire. I've invested an ungodly amount of my time searching for this exact functionality across platforms and this is the only one that actually works as i intend. It's such a shame to see it ruined by such an apparently simple defect. 1ifemare (talk) 06:06, 10 December 2024 (UTC)Reply

@1ifemare I'm sorry to hear you had a bad experience with the book creator. When you're ready to save your book, you can click "Show book" and save the book into your userspace. I just saved a test book at User:This, that and the other/Books/test.

Unfortunately the book creator is an old piece of software that is not maintained, so there is no possibility of auto-save functionality being added to it. This, that and the other (talk) 06:20, 10 December 2024 (UTC)Reply

@This, that and the other Thank you so much for replying.

That's the tragedy. It was the absolute best experience i had with a tool capable of creating a custom online personal dictionary - out of dozens of others i scoured the web for and thoroughly tested, just to find they all have crippling limitations, or just outright don't offer the desired functionality.

I tried saving a book, but there doesn't seem to be a away to re-open it as a book inside the creator software. There also doesn't see to be a way to delete saved books, unless i missed something. 1ifemare (talk) 13:47, 10 December 2024 (UTC)Reply

On social media, I saw someone complaining that we were mistaken to list distinto as the short past participle of Portuguese distinguir, and in the process of looking into that, I noticed that all the conjugation tables on that page are bright-on-bright and could stand to be palettized, so I'm reporting that for tracking purposes. (Do we have a page or category for tracking "things that need to be palettized"?) - -sche (discuss) 09:12, 10 December 2024 (UTC)Reply

@-sche I don't know of any central place for tracking these. If there is such a place, @Ioaxxere would know. I took a whack at palettizing the Spanish table; in the process the colors got a little more saturated and less pastel. Dunno if anyone will complain. I posted before and after side-by-side comparisons on Discord in the #general channel, but AFAIK you're not on Discord and I don't know how to post the pictures here at Wiktionary. Benwing2 (talk) 07:56, 11 December 2024 (UTC)Reply

@-sche @Ioaxxere Ugh, I managed to palettize all the major Romance languages + Latin (not yet Proto-Romance though) as well as all the minor ones up through R. There are so many minor Romance languages out there, each with their own slightly different table. Ioaxxere, all the tables go 100% across the screen, which might not be ideal. Please take a look at Module:roa-verb/style.css; maybe there is a fairly simple way of fixing this. Unfortunately I don't understand the nuances of CSS well enough to know what to do here. Benwing2 (talk) 10:00, 12 December 2024 (UTC)Reply

What does palettize mean in this context? The sole sense in our entry for the term doesn't seem to apply. DCDuring (talk) 15:36, 12 December 2024 (UTC)Reply

It means using colors from MediaWiki:Gadget-Palette.css so that they are varied between light and dark mode.

Stujul (talk) 16:02, 12 December 2024 (UTC)Reply

So it's ad hoc wikijargon, not worth including in palettize? DCDuring (talk) 18:17, 12 December 2024 (UTC)Reply

Probably not, no

Stujul (talk) 20:53, 12 December 2024 (UTC)Reply

@Benwing2: The closest thing to what you're describing is the report generated by MediaWiki:Gadget-AutoContrastFixer.js on a page load. It looks like this: https://imgur.com/a/auto-contrast-report-J9UovAe (in this example, the conjugation table at da#Bavarian as well as a couple other languages was adjusted). There's no central place that tracks all of the fixes.

As for the second point, NavFrames go all the way across the screen by default, but you can limit it with max-width: 40em or something like that. But that would make the Romance conjugation tables extremely cramped so I don't think there's any reason to do that. Ioaxxere (talk) 00:56, 15 December 2024 (UTC)Reply

Thanks for converting the templates, and apologies for using an opaque term, respectively. (It was shorter than ~"convert to using Palette.css colors".) - -sche (discuss) 22:19, 12 December 2024 (UTC)Reply

I guessed at a meaning like that, but there's always the risk that GP discussions with consequences to the less tech savvy will be opaque to them. BTW, I didn't find use in Google Books of palettize/ise except a modest amount possibly in the sense in our entry and as many as a misspelling of palletize/ise. DCDuring (talk) 23:45, 12 December 2024 (UTC)Reply

Subject: For languages, where _1. the written words in books are without diacritics and _2. they are also presented in wiktionary and other dictionaries with extra diacritics.
At the moment, en.wiktionary presents the word type_1 at the title of the page. But only type_2 as headword, Template:head. This is very confusing for people who are not aquainted with a particular language: what is the word they should use and copypaste? e.g. italian with added accents, russian with added accents, ancient greek with added prosodies (breve and long), arabic (with vowel diacritics) etc. I think the head should be clearly presented both in its pure spelling as we see it in printed books and in parenthesis with its altered/auxiliary/fiddled spelling+tooltip (with added diacritics / with added so-and-so diacritics). Whenever I need to copy a word, I have to go to the title to copypaste it. For languages I do not speak, I never know how it is supposed to be written. Please help. Thank you. ‑‑Sarri.greek ^♫ I 16:29, 10 December 2024 (UTC)Reply

I think that this could be pretty convenient. For example, if the word "ABO blood group" was first used in 1949, just have it have a category called "1949". Angrythewikipedian (talk) 16:59, 10 December 2024 (UTC)Reply

It could be, if the editorial certainty about first uses were good. But categories would nudge us to shoehorn our adequately vague datings into them. And none might even apply to non-European languages even if we tried earnestly with the effort I consider disproportionate; I believe that we won’t get together a handful in Arabic, which I edit; people from the censored Chinese internet should voice their opinion about what they typically know about the creation ranges of non-artificial terms, if this isn’t verboten at their location as well, and whether this would be useful there. We shouldn’t base such a decision solely on English, and many American even admins around here are competent to see other languages. Fay Freak (talk) 17:40, 10 December 2024 (UTC)Reply

I just don't think we have the data for most of our entries for this to be useful. — Sgconlaw (talk) 17:54, 10 December 2024 (UTC)Reply

@Angrythewikipedian For reference, @Vininn126 wants to add something similar based on {{etydate}}, but (a) per-language and (b) based on ranges of a century or so, not individual years (which are much harder to attest and are "slippery" because it's common to find a quote that pushes back the earliest attestation from what it was previously thought to be). Benwing2 (talk) 08:00, 13 December 2024 (UTC)Reply

Commenting to subscribe. Vininn126 (talk) 09:22, 13 December 2024 (UTC)Reply

The following language codes and corresponding should be added as they currently don't appear in many places despite having valid ISO codes: 'bfw' => 'Bonda/Remosam/ବଣ୍ଡା', 'gju' => 'गुज्जरी/Gujari/Gojri', 'hoc' => 'Ho/𑢹𑣉𑣉 𑣎𑣋𑣜', 'kgg' => 'Kusunda/Gemehaq gipan' 70.55.18.30 03:38, 11 December 2024 (UTC)Reply

That's not what Module:wikimedia languages/data is used for. It's for mapping Wiktionary language codes to Wikimedia language codes, which are used to e.g. name project domains. — SURJECTION ^{/ T / C / L /} 07:17, 11 December 2024 (UTC)Reply

I tried to fix a language problem on Help:Interwiki linking, but the corrected paragraph still doesn't explain what to do when interwiki linking isn't working automatically e.g. the Swedish Wiktionary's "Lika barn leka bäst." and our "lika barn leka bäst". I checked that at least some other and perhaps all other Swedish proverbs in the Swedish Wiktionary aren't connected with the same proverbs in the English Wiktionary or the German Wiktionary, e.g. aller guten Dinge sind drei and https://sv.wiktionary.orghttps://dictious.com/en/Aller_guten_Dinge_sind_drei. (Interestingly, that correct URL doesn't even work, even when adding a slash "/" after the period.) -- Espoo (talk) 08:40, 11 December 2024 (UTC)Reply

I suspect that if both wikis want these to be crosslinked, they would both need to create redirects from the other's form. (We used to have to do this to accommodate fr.Wikt and en.Wikt using different apostrophes; that is now handled by considering the different forms of apostrophe interchangeable in the automatic linking function itself, but I don't think the same can be done for capital vs lowercase letters.) So sv.Wikt would create a redirect at ] (to ]), as they appear to have already done years ago, and we would do the reverse, creating a redirect at ]. I would hope that if official sv.Wikt policy is to capitalize and include punctuation, everyone here would be fine with allowing redirects from sv.Wikt's forms, to enable interwiki linking, but perhaps others can speak up. - -sche (discuss) 16:15, 11 December 2024 (UTC)Reply

I disagree with the term "linguistically incorrect habit" used at sv:Wiktionary:Bybrunnen#technical_problems_in_the_Swedish_Wiktionary. English wiktionary is undeniably biggest but has strange punctuation habits. On the page crack#Noun we can see

# {{lb|en|vulgar|slang}} The ].

(vulgar, slang) The vagina.

Why the article "The"? Why the capital letter "T"? "The vagina." is barely a full sentence, is it? And why the dot at the end?

"sv:Lika barn leka bäst."

is a full sentence, therefore it ends with a dot and begins with a capital letter. On the page sv:crack

(vardagligt) /rent/ kokain

is NOT a full sentence and therefore it does NOT end with a dot and does NOT begin with a capital letter.

There is a very sane and useful point with the Swedish system: a definition is a replacement of the word defined:

The train was hauled by an old locomotive.

Definition style of Swedish wiktionary:

locomotive -- rail vehicle equpipped with a motor intended to pull trains

After replacement:

The train was hauled by an old rail vehicle equpipped with a motor intended to pull trains. (works)

Definition style of English wiktionary:

locomotive -- A rail vehicle equpipped with a motor intended to pull trains.

After replacement:

The train was hauled by an old A rail vehicle equpipped with a motor intended to pull trains.. (broken)

Also, if uppercase and dot are to get dropped for the sake of simplicity, then the comma must get dropped too. Then an eye for an eye, a tooth for a tooth is a technically incorrect/dysfunctional URL and must be moved to an eye for an eye a tooth for a tooth. It is inconsequent and useless to keep commas and at same time drop dots in proverbs.

Support redirects on both sides Eye for an eye, a tooth for a tooth. until a better solution is available. Taylor 49 (talk) 22:03, 20 December 2024 (UTC)Reply

List-based templates powered by Module:affix/templates such as {{suffixsee}}, {{prefixsee}}, etc. create lists where the entries don't link to the appropriate language subsection, but rather to the entire page. For example:

You would expect e.g. "spil" to link to spil#Dutch, but it just links to spil. Even further, you would expect it to link to the appropriate sense, as indicated by the id.

Stujul (talk) 15:38, 11 December 2024 (UTC)Reply

@Stujul The problem here is that the above list is not actually generated directly by the code in Module:affix/templates; rather, it's invoking the categorytree parser function, which is a special feature of MediaWiki itself that provides this functionality but unfortunately (AFAIK) doesn't support tweaking the generated links to include the appropriate anchros. I think we'd have to do this using a gadget (which should be fairly easy to write; pinging @Ioaxxere, @Surjection or @Erutuon if they happen to have time on their hands). Maybe alternatively we could generate the list ourselves and stick it in a NavBox or something; unfortunately I'm not sure we have dynamic access to the contents of a given category. (We do have access to the number of pages in a category, but that is a different ball of wax.) Benwing2 (talk) 07:58, 13 December 2024 (UTC)Reply

I don't think we can access category members. Implementing a gadget for this is doable, but needs some thought, since we wouldn't want to duplicate catfix code. — SURJECTION ^{/ T / C / L /} 10:30, 13 December 2024 (UTC)Reply

@Surjection: I think the catfix gadget should be extended to do this. I'm studying how it works now, but we'll need to simultaneously make changes to the modules behind {{suffixsee}} and co. Ioaxxere (talk) 01:26, 15 December 2024 (UTC)Reply

@Stujul:  Done Ioaxxere (talk) 04:17, 15 December 2024 (UTC)Reply

I can see why the entry creator wanted to do it this way, but our template infrastructure can't handle slashes in pagenames. Also pinging @Fay Freak as the only regular editor I can think of who might know anything about Proto-Cushitic. Chuck Entz (talk) 15:50, 11 December 2024 (UTC)Reply

FWIW, our Proto-Sino-Tibetan entries also use slashes, e.g. Reconstruction:Proto-Sino-Tibetan/s-b/m-ruːl, and tildes, Reconstruction:Proto-Sino-Tibetan/m-ljak ~ mrak ~ mruk, and both at once, Reconstruction:Proto-Sino-Tibetan/p(r)an/t ~ b(r)an/t. It causes issues there, too, e.g. Wiktionary:Grease_pit/2024/September#how_Proto-Sino-Tibetan_pages'_names_display_in_categories. Perhaps someone can think of either a better naming format or a way to accommodate the slashes. - -sche (discuss) 16:08, 11 December 2024 (UTC)Reply

Wildcards, V for the vowel. Fay Freak (talk) 17:01, 11 December 2024 (UTC)Reply

How can one make "shook" in the list https://en.wiktionary.orghttps://dictious.com/en/shake#Derived_terms link to the adjective? -- Espoo (talk) 13:23, 12 December 2024 (UTC)Reply

I was trying to create Template:R:grc:Tucker. Why would links to reliable journals like onlinelibrary.wiley.com be blocked? 172.97.141.219 17:33, 12 December 2024 (UTC)Reply

Because abuse filters have no way to tell whether an external link added by a new or anonymous user is to a reliable journal. They don't have access to templates or modules, and they can't afford complicated logic because they run every time any page is accessed anywhere on Wiktionary, so they have to be very fast. They also can't access any information about anonymous editors except for their IP addresses, so they have no way to tell you're not a one-time hit-and-run spambot- and trust me, they catch lots of spam edits all the time. It's a shame that they also stop a few occasional good edits in the process, but there's not much we can do about that. At any rate, I was able to see your attempted edit in the logs, so I went ahead and created the template for you. Chuck Entz (talk) 03:27, 13 December 2024 (UTC)Reply

On enwiki, I noticed good websites like Wiley are trusted by w:MediaWiki:Captcha-addurl-whitelist. Should we import the list into mediawikispace and the tripped abuse filter? 172.97.141.219 17:24, 13 December 2024 (UTC)Reply

Why should we spend our time maintaining such things when you can simply create an account for yourself and avoid all this trouble? This, that and the other (talk) 23:16, 13 December 2024 (UTC)Reply

Ive been working at the Module:ine-nominals a bit, hopefully nothing too offensive, adding a few Categories for previously not-recognized stem types (nouns of which types were classified as root nouns), but there remain a few entries in the root noun categories which are in fact formally indistinguishable from root nouns, like *h₃dónts (*h₃dent- would be a perfecly fine root afaik) and only morphological analysis tells us this contains a -ónts. Therefore I would like to request a new parameter stem type which primarily interacts with the table.insert(data.categories operator to override any erroneous placement in the else-category (that is, root nouns).
The reason I'm asking is because adding a parameter is above my technical competence, I hope someone with Lua-knowledge can easily solve this.
If you have problems understanding my request, do ask. Suryaratha03 (talk) 19:30, 13 December 2024 (UTC)Reply

1. Oh also the boilerplate module needs major reworking, whoever reads this might be interested in helping overhaul that. Suryaratha03 (talk) 20:27, 13 December 2024 (UTC)Reply

@Benwing2: see peevish—any idea why {{col3}} does not sort "{{l|en|impeevish}} {{qualifier|obsolete}}" before "{{l|en|impeevished}} {{qualifier|obsolete}}"? — Sgconlaw (talk) 22:46, 13 December 2024 (UTC)Reply

@Sgconlaw it appears to be ignoring punctuation and spaces, and sorting "impeevishedobsolete" before "impeevishobsolete". That's the "why"... as for a solution, that part would be more difficult. This, that and the other (talk) 01:00, 14 December 2024 (UTC)Reply

@This, that and the other: from what I understand, the template is supposed to ignore templates like {{l}} and {{vern}}, and markup like “]”, but an alphabetical sort should place “impeevishedobsolete” before “impeevishobsolete” so I’m wondering why that doesn’t happen. — Sgconlaw (talk) 04:44, 14 December 2024 (UTC)Reply

@Sgconlaw "impeevishedobsolete" before "impeevishobsolete". I think it would make a lot more sense for {{col3}} and friends to sort specifically by the output of the {{l}} template only, ignoring any qualifiers, plain text, etc. This, that and the other (talk) 05:05, 14 December 2024 (UTC)Reply

@This, that and the other: sorry, my mistake—I see what is happening now. The template is taking the qualifier “obsolete” into account when sorting, whereas if there were no qualifiers impeevish would appear before impeevished. I agree that qualifiers should be ignored when sorting. — Sgconlaw (talk) 05:17, 14 December 2024 (UTC)Reply

@Sgconlaw: I changed the template to {{col3-u}}, which does the trick. No idea why it didn't before. DonnanZ (talk) 16:47, 14 December 2024 (UTC)Reply

@Donnanz: thanks. However, ideally {{col3}} and its relatives should be able to deal with this sort of situation without editors resorting to manual sorting. — Sgconlaw (talk) 16:59, 14 December 2024 (UTC)Reply

@Sgconlaw: Agreed, but {{col3-u}} comes in handy when all else fails. I have a problem with St for saint, which gets tangled up with everything else beginning with St when sorting. Our templates can't cope with that. DonnanZ (talk) 17:21, 14 December 2024 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Fenakhay has pointed out a useful solution, which is to type "impeevish<qq:obsolete>". It seems that tags in angle brackets are ignored by the template for sorting purposes. Thanks! — Sgconlaw (talk) 18:32, 15 December 2024 (UTC)Reply

I seem to have selected mobile view somehow by accident ( on Friday the 13th, of all days). I can enlarge the page text and the width, but everything else has shrunk, including images and search box. How can I reset it for my full screen? Wikipedia is OK, no problem. DonnanZ (talk) 15:06, 15 December 2024 (UTC)Reply

@Donnanz Do you see a Desktop link on the very bottom of the page? You should be able to switch between the two views. Panda10 (talk) 17:39, 15 December 2024 (UTC)Reply

Well, you can go to Mobile view and then switch back from that to Desktop. But I still get small text, which I can enlarge with the spectacle view at the top, as well as page size. But I didn't knowingly click on Mobile view, I probably clicked on Control by accident (instead of Shift) and a letter key. Editing this page has to be small text, not large, as before. DonnanZ (talk) 18:12, 15 December 2024 (UTC)Reply

@Donnanz: what device are you editing on? If on a Mac, you can usually increase or decrease the text size of a browser window by pressing Command+ or Command- (no need to also press the Shift key). On a PC the key corresponding to Command is either Ctrl or Alt—offhand I can't remember which. — Sgconlaw (talk) 18:30, 15 December 2024 (UTC)Reply

I have a PC built by my local computer shop years ago, now rebuilt by them with a solid state hard drive, and now with a wide screen, and with standard UK keyboard. I'm not sure if I have to press another key with Ctrl or Alt. DonnanZ (talk) 18:58, 15 December 2024 (UTC)Reply

Fixed it. Ctrl, Shift and +, all at the same time, three times to get the required size. I have enough fingers... DonnanZ (talk) 19:56, 15 December 2024 (UTC)Reply

@Donnanz: ah, so that's the keystroke. — Sgconlaw (talk) 20:19, 15 December 2024 (UTC)Reply

@Sgconlaw: I could have dispensed with Shift by using the + key on the right of the keyboard. Never mind. Thanks. DonnanZ (talk) 20:33, 15 December 2024 (UTC)Reply

Category pages such as Category:Proto-Italic lemmas now give a list of forms such as "Reconstruction:Proto-Italicad, Reconstruction:Proto-Italicad-" etc., where "Reconstruction:Proto-Italic" is smooshed together with the reconstructed term. This seems like a bug: for readability, I'd expect at least a "/" separating them, although probably in this context it would be reasonable to just leave out "Reconstruction:Proto-Italic/" altogether and use an asterisk in its place. Urszag (talk) 17:05, 15 December 2024 (UTC)Reply

Possibly related to the changes made here? A separate problem which would also be good to fix is that as described in September, a page like Reconstruction:Proto-Sino-Tibetan/t/duŋ shows up in Category:Proto-Sino-Tibetan_lemmas as just "Reconstruction:Proto-Sino-Tibetan/t" (now "Reconstruction:Proto-Sino-Tibetant") but is sorted under "d", which seems unhelpful two ways! - -sche (discuss) 17:34, 15 December 2024 (UTC)Reply

 Fixed Special:Diff/83052949. — Fenakhay ^{(حيطي · مساهماتي)} 18:24, 15 December 2024 (UTC)Reply

@Urszag: Sorry, the bug was in fact an oversight on my part. But I've just implemented your idea as an experiment so let's see what people think. Ioaxxere (talk) 00:50, 16 December 2024 (UTC)Reply

there are several words for Japanese concepts in English and other foreign languges that require categorisation or recategorisation, as they are mostly just found inside the general Category:Japan. below are some recommendations for labels and categories that should be created:

• {{lb|en|Japanese fiction}} — Category:Japanese fiction
• {{lb|en|Japanese food}} — Category:Japanese food
• {{lb|en|Japanese pornography}} — Category:Japanese porngraphy

other suggestions are (with examples):

• people (samurai, geisha)
• fashion (gakuran, sailor fuku)
  • street fashion (gyaru, lolita)
• art (shibui, wabi-sabi)
• culture (may be way too general)

if you have any more suggestions, please let me know. Juwan (talk) 04:21, 16 December 2024 (UTC)Reply

I have noticed that the menu list of languages on top of each search item has suddenly disappeared? What happened and why? Is there a technical problem? I'm quite devastated, as those listings are very helpful and time saving, that you get an overview of all languages involved and may easily go straight to your preferences instead of having to scroll through every single language in the list. I hope it's just a technical issue, that it's soon to be in place again? Bemland (talk) 08:07, 16 December 2024 (UTC)Reply

I'm using the new look, where they are listed in the top right-hand corner. E.g., sex says it's in 79 languages. DonnanZ (talk) 09:30, 16 December 2024 (UTC)Reply

I'm pretty sure they are talking about the table of contents as the interwikis were on the left (not the top) before going to the top right.

It's not a technical issue. This was forced on Wiktionary by the WMF some time ago. Not sure where the table of contents went after the switch but if you go to your user preferences (top right), you can switch back to the old skin (Vector 2010) and the table of contents will come back. 115.188.138.105 13:08, 16 December 2024 (UTC)Reply

The top right is for Wiktionary in other languages. On the left any other languages in English Wiktionary are listed (e.g. France), as long as you haven't hidden the Main menu and Contents. In addition, you can "Switch to old look" in the Main menu. DonnanZ (talk) 13:58, 16 December 2024 (UTC)Reply

Thank you both very much, it worked fine reversing the skin back to 2010 version and that list of content top left returned, grateful of that! Hard to understand why its considered better without that list, but good that it's reversible. Still, newcomers don't know about that option, so maybe one should give some short info on that? Best wishes to you! Bemland (talk) 21:58, 16 December 2024 (UTC)Reply

As pointed out by Rua five years ago, the desctree template simply picks the first descendants section it can find, which can be wrong when there are multiple sections. One example (before I copy/pasted the correct descendants) was at Latin ferus for the Old French descendants tree, old version here. I've also noticed that desctree picks any alternative forms (using 'alt') it can find, also when this is in another etymology section than the descendants. Example at ferrum: Old French 'fier' is not an alternative form of "iron".
Just an idea, but would some interaction with (the id's of) the etymon template be possible? Exarchus (talk) 14:23, 16 December 2024 (UTC)Reply

@Exarchus: Yes, this is a situation I've predicted because no template can be smart enough to actually understand a complex entry like the one you linked. I was working towards integrating the descendant trees with {{etymon}} but there wasn't a ton of enthusiasm and it is very complex to implement. Ioaxxere (talk) 14:37, 16 December 2024 (UTC)Reply

I wish to request a method to create multiple inline examples in examples inside the {{ux}} and {{co}} templates. below is an example from time (permalink), where editors simply hacked it with non-breaking spaces. this is likely not great as it is a static width and may be not be understood semantically by screen readers.

1. {{ux|en|Roman '''times''';  the '''time''' of the dinosaurs;  how things were at that '''time''';  how things were in those '''times'''}}

   Roman times;  the time of the dinosaurs;  how things were at that time;  how things were in those times

please leave suggestions on a better way to denote this. Juwan (talk) 19:40, 16 December 2024 (UTC)Reply

We need a new template, which can be English-specific. Perhaps:

{{en-ux-multi|Roman times|the time of the dinosaurs|how things were at that time|how things were in those times}}

Roman times; the time of the dinosaurs; how things were at that time; how things were in those times

Any thoughts? This, that and the other (talk) 01:17, 18 December 2024 (UTC)Reply

TBH, I much prefer just keeping multiple examples like that on separate lines. Sure, it takes up more vertical space, but I think it looks cleaner and is far easier to skim and digest the different examples. Andrew Sheedy (talk) 22:34, 20 December 2024 (UTC)Reply

I don’t mind if several short collocations are placed on the same line as it saves space, but don’t think we should allow for, say, more than three, or allow a string of collocations that flows on to a second line. I have been doing this in some cases by adding three em spaces between the collocations. — Sgconlaw (talk) 20:05, 21 December 2024 (UTC)Reply

• Just do itTemporaryAccount6969 (talk) 23:48, 24 December 2024 (UTC)Reply

MediaWiki message delivery 22:24, 16 December 2024 (UTC)Reply

These are chronologically-based "families" that are used to get around near-complete lack of information on specific Iranian lects from these time periods. until sometime yesterday, the {{auto cat}} modules allowed derivation categories based on them, but now we have 51 of them in CAT:E. I would note that the etymology templates still accept them. Chuck Entz (talk) 14:41, 18 December 2024 (UTC)Reply

This was mostly my fault; I removed the entries from the canonical name-code mappings, because Module:data consistency check said these codes did not actually exist. Turns out that module just doesn't support the setup. I restored them some time ago and the errors are going away. — SURJECTION ^{/ T / C / L /} 22:18, 18 December 2024 (UTC)Reply

IMO we should just be using (perhaps "etymology-only") language codes for this, like we do for substrates, etc, particularly because we're de facto treating it as a language when we reconstruct terms in it and have entries say something is from "Middle Iranian *foobar". Cf this and the replies by others. - -sche (discuss) 06:27, 19 December 2024 (UTC)Reply

For some reason this edit got flagged for using triple braces. Maybe some bug because two spaces are used in the term? Exarchus (talk) 16:32, 19 December 2024 (UTC)Reply

Nevermind, the error is there because of a previous edit. Exarchus (talk) 16:37, 19 December 2024 (UTC)Reply

I am still experiencing this error—when editing "Appendix:Colors/Colour grouping" even though I did not add any triple braces in the edit. Any chance it can be fixed soon? — Sgconlaw (talk) 12:54, 21 December 2024 (UTC)Reply

If you look at the code there, there are several instances of triple braces to show either 'color' or 'colour', or 'gray'/'grey'. But I can't tell you more about how this should be fixed. Exarchus (talk) 13:56, 21 December 2024 (UTC)Reply

@Exarchus: ah, I see. Those were already in the page before I worked on it. It seems like they are supposed to allow for alternative displays of the spellings of certain words depending on readers' preferences, but I don't know if they actually work. Can someone confirm this? — Sgconlaw (talk) 16:05, 21 December 2024 (UTC)Reply

I couldn't make that structure work in my sandbox. I suspect that this may be something that works on other wikis and/or once worked here. Instances should probably be replaced by wikitext that function properly. DCDuring (talk) 18:28, 21 December 2024 (UTC)Reply

@DCDuring: thanks. I've removed the odd markup. — Sgconlaw (talk) 18:48, 21 December 2024 (UTC)Reply

It was a case where someone was improperly copying a template, {{gmh-decl-pronoun}}, into an entry. There should never be triple braced template arguments in entries because entries aren't transcluded as templates, and template arguments have no useful effect otherwise. I'm not sure why the template was copied into the entry. Ideally it would be used in the entry. — Eru·tuon 20:29, 21 December 2024 (UTC)Reply

Thanks. I hadn't realized that triple brackets only work in templates, though that's the only place I've intentionally used them. DCDuring (talk) 20:34, 21 December 2024 (UTC)Reply

@DCDuring They work everywhere, but there's not much point in them if the page isn't intended to be transcluded like a template. The reason they get flagged by the abuse filter is because they strongly suggest someone is blindly copying a template somewhere they shouldn't be (i.e. exactly what happened here). Theknightwho (talk) 21:26, 21 December 2024 (UTC)Reply

Well, they work in the sense that all parameters are empty, and syntax that provides a value when a parameter is empty will always provide that value. Of course, the parameter-empty value without all the template syntax produces exactly the same result and you don't need to know template code. With the colors appendix, the code was set to provide the UK variants if the parameters for the US variants were empty, so the code accomplished nothing: "Col{{{or|our}}}" is just a very complicated way way of writing "Colour". If you had a page in your userspace with the code "{{Appendix:Colors/Colour grouping|or=or}}", it would display "color" instead of "colour" in those places, but I'm not sure it's worth the unreadble wikitext on the appendix page. Chuck Entz (talk) 21:59, 21 December 2024 (UTC)Reply

Hi. Could someone take a peek at the column formatting on this appendix please. Whole sentences have been split rather than maintained in their correct column. Thanks. -- ALGRIF talk 11:10, 20 December 2024 (UTC)Reply

Edit: I think the column template used originally is deprecated. There should be two columns; one with the entry and the other with notes or special examples as needed. I cannot find how to do that now. Acceptable alternative would be simply to make the entries in 2 cols. Thanks. -- ALGRIF talk 12:15, 20 December 2024 (UTC)Reply

@Algrif: are you asking for guidance on wikitext table markup? — Sgconlaw (talk) 22:14, 27 December 2024 (UTC)Reply

@Sgconlaw: If I can fix the table format myself, I'm quite happy to do it. However, I do not clearly understand in the Templates how to go about it. Perhaps I'm looking in the wrong place. I dunno. Help of some sort is required, please. Thanks. -- ALGRIF talk 12:36, 28 December 2024 (UTC)Reply

Full context: Template_talk:ja-pron#Multiple_accent_phrases

I'm requesting permission to edit Module:ja-pron. To solve the issue of Japanese pitch accent in compound words, I've written a proof-of-concept template, Template:ja-acc-multi, that relies on ja-pron (similarly to how Module:ja-ojad relies on ja-pron), and right now its output looks like:

• 適者生存

• てきしゃせーぞん (Atamadaka + Heiban – -)

• 完全無欠

• かんぜんむけつ (Heiban + Heiban – -)

This solves the issue with users manually hardcoding pitch accent in these words. Shlyst (talk) 20:14, 22 December 2024 (UTC)Reply

@Surjection Good evening. Shlyst (talk) 17:15, 26 December 2024 (UTC)Reply

I don't know much about this topic. Theknightwho might know better. — SURJECTION ^{/ T / C / L /} 17:18, 26 December 2024 (UTC)Reply

@Theknightwho Shlyst (talk) 23:08, 26 December 2024 (UTC)Reply

there are some English headword forms that have some hyphenated quasi-productive combining forms not covered by the special prefix handling of the module, e.g. socio-political, phono-semantic, pico-farad, magneto-aerodynamics, ecto-blaster. in each of the cases above, the headword hyperlinks do not behave as they should: in socio-political, for instance, the links in the headword lead to socio and political, which is obviously incorrect-- it should be linked to socio- and political, or not linked anywhere else at all.

this is of course not a en-headword-exclusive issue: cf. gastro-intestinal and climato-sceptique in French, etc.

is there a preferred way of dealing with this at wiktionary? do we no-link it with |nolink=1, or do we do something like |head=]]? ragweed theater _{talk, user} 23:33, 23 December 2024 (UTC)Reply

With any headword template (I think) you can use "head=" to customize appearance and linking whenever there is a good reason to do so {{en-noun|head=socio- political}} might do what you want. (We wouldn't usually put in a space, but it does clarify matters a bit.) DCDuring (talk) 03:03, 24 December 2024 (UTC)Reply

I got the following message while editing where:

Warning: This page calls Template:l which causes a template loop (an infinite recursive call).

It sounds quite disastrous, but actually the page appears to edit and load normally. I don't know what the message refers to (I can't see any use of such a template) or how to fix it. Mihia (talk) 20:23, 26 December 2024 (UTC)Reply

Template:l The page is NOT broken. This type of error can apperar in some cases when editing and previewing a section, or you make the page transclude itself. It it not malicious until you really break a heavily-used template in that way ;-) Taylor 49 (talk) 21:39, 27 December 2024 (UTC)Reply

I imagine @Theknightwho would know more about this, and might be able to advise whether we can edit MediaWiki:template-loop-warning to be a little less scary. This, that and the other (talk) 22:57, 27 December 2024 (UTC)Reply

@This, that and the other It seems to be affecting a somewhat random small selection of pages (see Category:Pages with template loops). I'll have a look. Theknightwho (talk) 23:30, 27 December 2024 (UTC)Reply