Wiktionary:Grease pit/2022/November

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

.Hani font should be changed to use fonts same as .Hant[edit]

Please see MediaWiki talk:Common.css#.Hani font for details. – Wpi31 (talk) 13:49, 1 November 2022 (UTC)[reply]

Improvements the Categories footer[edit]

I think some layout changes would be beneficial because the categories are right now a wall of text. I don't know how taxing tree traversals can be. Apart from this, separate rows per language headed by the name as a link to the language's parent node would be neat. Other wikis have the language header be a link, which is a bit intrusive, color wise.

Should I take to the WT:BP? 2A00:20:608F:6ECC:AB47:EF08:8CC2:AA5C 19:43, 1 November 2022 (UTC)[reply]

Definitely the layout of the whole site could be improved. I think the best approach here is to see if you can implement a prototype in CSS or whatever, and then post in the Beer Parlour asking what people think. If you just ask someone else to implement something you probably won't get too far, esp. since most of the tech-savvy editors around here don't know CSS or JavaScript very well (I for one). User:Erutuon and IP 98.whatever seem the most knowledgeable. Benwing2 (talk) 02:52, 2 November 2022 (UTC)[reply]
tech-savvy editors around here don't know CSS or JavaScript very well I felt that :) — Fytcha〈 T | L | C 〉 04:29, 2 November 2022 (UTC)[reply]
@Fytcha My apologies, I did not intend at all to call you out. This was just my impression that we seem to have more back-end than front-end programmers around here; maybe I'm just generalizing based on my own experience. Benwing2 (talk) 03:18, 7 November 2022 (UTC)[reply]
@Benwing2: Oh, no need to apologize, I was just jokingly including myself in your statement as it was just too perfectly relatable. By the way, I share your impression, fewer front-end-savvy people here than expected. — Fytcha〈 T | L | C 〉 03:25, 7 November 2022 (UTC)[reply]
Could you try this JavaScript which intends to separate categories on a per-language basis? [1] You can even just copy it into the clipboard, go to a page like robot with several language sections, and paste the code into the developer console. It's not polished; it's just a proof of concept, and it can definitely be improved if there's interest. MediaWiki:Gadget-TabbedLanguages.js also contains code to accomplish a similar task. As for styling or CSS, do you have specific suggestions? 98.170.164.88 04:06, 2 November 2022 (UTC)[reply]
I suggest you use the wonderful MediaWiki:Gadget-TabbedLanguages.js gadget (can be turned on in the preferences). It groups the (non-hidden) categories by language and only shows you those belonging to the language whose tab you're currently on. — Fytcha〈 T | L | C 〉 04:27, 2 November 2022 (UTC)[reply]

Template:top3 etc. not working properly[edit]

Using FF 106.0.4 (and Windows 10), items appear in one column. Using {{top4}} items appear in 3 columns. Using {{top2}} items appear correctly, in 2 columns.

Using Chrome 107.0.5304.88, {{top4}} displays only 3 columns, but the other templates seem to work correctly.

Can the work done on column display for {{trans-top}} be applied to these templates? DCDuring (talk) 15:13, 3 November 2022 (UTC)[reply]

Yes several of us have noted this bug on the discord server. It seems that {{hcol|3}} works as a replacement. Still would be nice to sort out the core issue. Nicodene (talk) 16:17, 3 November 2022 (UTC)[reply]
The apparent worst offender, {{top4}}, is transcluded on more than 3K pages; {{top3}} is transcluded on more than 6K pages. It is possibly useful to note that {{top2}} seems to work properly. DCDuring (talk) 16:50, 3 November 2022 (UTC)[reply]
The above counts do not include usage via redirects from {{der3}} etc., which is more abundant. DCDuring (talk) 17:00, 3 November 2022 (UTC)[reply]
Could you give examples? I've fixed the example on Template:top4/documentation (the {{mid4}} template messes things up by splitting up the lists in the HTML) and it has 4 columns. — Eru·tuon 23:02, 3 November 2022 (UTC)[reply]
{{top3}} doesn't work for me even in the documentation example. DCDuring (talk) 23:19, 3 November 2022 (UTC)[reply]
@DCDuring: Ah yeah, somebody temporarily reverted it because bad CSS was causing the browser rendering to be too slow, and the problem is solved but I forgot to fix it. Now I have fixed it and it should show with 3 columns now. — Eru·tuon 23:38, 3 November 2022 (UTC)[reply]
Excellent. Are all the multicolumn-table templates good to use? If not, how could one detect possible problems? For example, are templates last edited before a certain date highly likely to not use the proper CSS? DCDuring (talk) 01:11, 4 November 2022 (UTC)[reply]
@DCDuring: Most of them should be working if the list doesn't have mid templates in it. Mid templates should be removed so that the list is not broken into pieces. I changed all the ones I could find with a search for "column-count" in templates. {{top4}} was just changed back temporarily. — Eru·tuon 03:19, 4 November 2022 (UTC)[reply]
Thanks again. Are there any cases that you know of where {{mid}} or any relative thereof should remain? DCDuring (talk) 14:31, 4 November 2022 (UTC)[reply]
@DCDuring: If the column template contains {{#invoke:columns|display}} or class="... ul-column-count" or style="... column-count: ...;" or style="... column-width: ...;", then it doesn't need {{mid}}. I think that's true of most of them now. — Eru·tuon 21:48, 13 November 2022 (UTC)[reply]
Thanks. DCDuring (talk) 03:18, 14 November 2022 (UTC)[reply]
I'm still removing {{mid}} templates to counteract weird column behaviour, like gaps. DonnanZ (talk) 22:51, 20 November 2022 (UTC)[reply]

Error with tabbed languages + vector 2022[edit]

Hi. The tabbed languages gadget is mostly compatible with the new vector skin, except that it leaves a redundant content bar on the left-hand side, as can be seen in this screenshot. This gets a bit annoying. Is there a way to make the content bar hidden by default? Nicodene (talk) 16:16, 3 November 2022 (UTC)[reply]

Module:cmn-pron edit request[edit]

Please implement this edit.

The point of this is to fix capitalization of proper nouns containing words whose pinyin starts with an accented letter. Some examples of how the module currently works:

  • {{zh-pron|m=Àoyītuō Gélākè}} => Gwoyeu Romatzyh: awituo Gerlhakeh, Tongyong Pinyin: àoyituo Gélakè, Wade–Giles: ao4-i1-tʻo1 Ko2-la1-kʻo4
  • {{zh-pron|m=Zēngmǔ Ànshā}} => Gwoyeu Romatzyh: Tzengmuu annsha, Tongyong Pinyin: Zengmǔ ànsha, Wade–Giles: Tsêng1-mu3 an4-sha1

And how it will work after the edit is performed:

  • {{zh-pron/sandbox|m=Àoyītuō Gélākè}} => Gwoyeu Romatzyh: Awituo Gerlhakeh, Tongyong Pinyin: Àoyituo Gélakè, Wade–Giles: Ao4-i1-tʻo1 Ko2-la1-kʻo4
  • {{zh-pron/sandbox|m=Zēngmǔ Ànshā}} => Gwoyeu Romatzyh: Tzengmuu Annsha, Tongyong Pinyin: Zengmǔ Ànsha, Wade–Giles: Tsêng1-mu3 An4-sha1

98.170.164.88 00:59, 4 November 2022 (UTC)[reply]

Thanks for the fix. There are other places that wrongly use the non-Unicode string pattern functions, e.g. lines 476, 477, 520, 521, 554, 589, etc. Would you mind fixing those? I would recommend just using the Unicode variants everywhere; the slowdown from using them is extremely small and trying to use the non-Unicode variants to make things faster is a classic example of premature optimization. Benwing2 (talk) 04:36, 7 November 2022 (UTC)[reply]

Problematic parameter in {{quote-newsgroup}}[edit]

|trans-title displays its argument twice, first in its proper place and then at the very end of the quotation block. See mierli#Romanian to see what I mean. —Biolongvistul (talk) 19:30, 5 November 2022 (UTC)[reply]

Adding a blank |trans-title = parameter to the Module:quote invocation will fix this. See Special:Diff/69667855. 98.170.164.88 02:57, 6 November 2022 (UTC)[reply]

inline modifiers[edit]

Just FYI, I added support for inline modifiers to {{affix}}/{{suffix}}/{{prefix}}/etc. as well as {{affixusex}}/{{suffixusex}}/{{prefixusex}} (also known as {{afex}}/{{prefex}}/{{sufex}}). The documentation for {{affix}} and {{affixusex}} now reflects this. They also work for all the other templates implemented using Module:compound/templates, although the documentation hasn't yet caught up. (I'm thinking the best solution for this is to refer all the multi-component etymology templates to {{affix}} for documentation on inline modifiers and per-term parameters, rather than duplicate the information on all the documentation pages.) Inline modifiers should work for at least the following templates:

Benwing2 (talk) 03:36, 7 November 2022 (UTC)[reply]

Excellent, I was really looking for something like this. Thanks! Vininn126 (talk) 11:06, 7 November 2022 (UTC)[reply]
@Benwing2: Could you add inline modifiers support to {{alter}} as well? Thanks! — Fenakhay (حيطي · مساهماتي) 18:11, 8 November 2022 (UTC)[reply]
@Fenakhay Yup, it will happen shortly. Benwing2 (talk) 05:13, 9 November 2022 (UTC)[reply]
This is great! 98.170.164.88 05:14, 9 November 2022 (UTC)[reply]
@Fenakhay I implemented inline modifiers for {{alt}}. There's also existing support in {{rhyme}}, {{hyph}} and {{it-pr}}, which I've noted above in the list. Benwing2 (talk) 07:51, 10 November 2022 (UTC)[reply]
Thanks a lot! I think {{desc}} and {{desctree}} cannot parse {{alter}} inline modifiers. — Fenakhay (حيطي · مساهماتي) 09:59, 10 November 2022 (UTC)[reply]
@Fenakhay Hmm, I imagine you are right. Can you give me an example or two? I'll see if I can fix it tomorrow or the next day. Benwing2 (talk) 10:02, 10 November 2022 (UTC)[reply]
χάρτης (khártēs) and قُرْطَاس (qurṭās) — Fenakhay (حيطي · مساهماتي) 10:05, 10 November 2022 (UTC)[reply]
@Fenakhay Thanks. Should be fixed now. The former code did the parsing of the {{alt}} template manually (and not very robustly) and tried to format the arguments itself (and not very well); now we use the dedicated template parser in Module:templateparser to parse the template, and call into Module:alternative forms itself to format the arguments, so that future changes to this module will automatically be tracked. Benwing2 (talk) 03:04, 13 November 2022 (UTC)[reply]
BTW I tried to ping you in the change to Module:descendants tree but misspelled your username (oops). Benwing2 (talk) 03:05, 13 November 2022 (UTC)[reply]
@Benwing2: speaking of which: at the moment there's a problem at Old English synful resulting from all but one of the Middle English terms in the parameters of {{desctree}} having been converted to alt-form entries and their descendants removed. The module was changed a while back to not throw a module error for mainspace and Reconstruction entries, but to add a maintenance category and display the descendants having no descendants the way the {{desc}} template would. This has resulted in two sets of those terms: one set generated from the parameters, and one set extracted from the Alternative forms section of the Middle English form that still has descendants- which happens to be spelled the same as the Old English term. When I remove the redundant parameters, all the alt-forms go away and only Middle English synful is displayed (at least in preview). I spot-checked a few other Old English entries with descendants that have multiple alt-forms, and some aren't showing any alts, either. The same holds for {{desc}} with |alts=1. I have a hunch that the bug has something to do with the two entries sharing the same spelling, but I haven't had time to check enough entries to be sure. At any rate, the template works fine here:
Middle English: synful, senful, sinful, sunfol, sunful, sunvol, sunvul, synffol, synfull; cynfulle, sinfull, symful, synfle, synneful; senvul, zenvol
  • English: sinful
  • Scots: sinfu
Chuck Entz (talk) 03:58, 13 November 2022 (UTC)[reply]
@Chuck Entz Apologies, I couldn't quite follow what the issue is. The wikitext at the end of your message displays the same for me as the Old English descendants of the synful page (i.e. both have alternative forms in them). When you preview the page itself, for some reason I don't see any alternative forms (and I do see some big red maintenance messages), but when you preview the page using Module:descendants tree, the alternative forms do appear, same as on the page when not previewed. Benwing2 (talk) 06:14, 13 November 2022 (UTC)[reply]
False alarm due to a quirk of preview: when I cleaned out the redundant parameters and saved the edit, the alts that didn't show in preview magically appeared. Chuck Entz (talk) 06:50, 13 November 2022 (UTC)[reply]

is there a list of languages for which the IPA module automatically...[edit]

lists the pronunciation of the word, given what's on the page? Two months ago I found Wiktionary:Tea_room/2022/September#Reconstruction:Proto-Germanic/ramō and now I see the same problem on Reconstruction:Proto-Germanic/apô where the template doesnt automatically generate the pronunciation and so we need to rely on a manually entered pronunciation that in this case doesnt match the spelling of the word. But since Proto-Germanic is rendered phonetically, this should never be needed. Is it simply that we make a few mistakes here and there, and that it's okay to assume the pronunciation of apô should have a trimoraic vowel, just as it turned out that ramō was not supposed to have one?

Also, since this might come up over and over again, is there a list of languages for which the IPA template is supposed to be able to calculate the proper pronunciation, so that I can know when it's safe to delete the manually entered pronunciation entirely? Assuming that when I see them, they may be left over from a time in which it was always necessary.

Thanks,

—Soap— 11:26, 7 November 2022 (UTC)[reply]

The conclusions you want to draw should generally be implicit in the language's maintenance categories - start at cat:<language name>_language and start looking. However, I couldn't actually find any examples! The automatically generated pronunciation and its presentation are usually generated by template <language code>-pron. Often you can get an idea of its performance from Module:<language code>-pron/testcases. If the template and module exist, but the testcases do not, distrust it. For truly written and still spoken languages, one probably cannot rely on the module to get it right. It's disconcerting that {{rfp}} only requires a knowledge of IPA to make an entry - one really wants contributors for pronunciations to have some knowledge of the language!
Names can differ, and some language's modules rely on phonetic respelling to a greater or lesser extent. There's not much standardisation. --RichardW57m (talk) 14:49, 7 November 2022 (UTC)[reply]
@Soap: {{IPA}} never adds the IPA automatically (which, I suppose, is what you're asking considering this edit: diff). For some languages, there are automatic IPA or even pronunciation section templates (usually following the naming scheme of {{fi-IPA}}/{{fi-p}}), the category for which is Category:Pronunciation templates. But please, never add an automatic template if you don't have the knowledge required to judge whether the generated IPA is correct or not. I don't want to have to revert even more wrong automatic IPA templates than I already have to. — Fytcha〈 T | L | C 〉 17:35, 7 November 2022 (UTC)[reply]
I have written several of the pronunciation modules and I completely agree with User:Fytcha that you should never ever add a pronunciation template without having a good understanding of the language in question. Some editors are guilty of doing this and it creates a big mess. All non-reconstructed languages have cases where respelling is needed and for some languages a great deal of respelling is needed. Even for reconstructed languages I would not advocate blithely adding pronunciation templates to their entries. Benwing2 (talk) 02:19, 8 November 2022 (UTC)[reply]
Okay thank you. Well, in the specific case of proto-Germanic, we have 4,469 entries that have the pronunciation templates on, out of about 5,000 words in total. So I'd say Proto-Germanic is essentially fully covered (more than English is, in fact) with pronunciation templates, and I don't think anyone would want to go through and remove 4,500 pronunciation templates. As well, I'd assume whoever put all those templates in there in the first place, even assuming they used a script to automate it, must have known what they were doing, and I respect their knowledge and the work they put into it. And since proto-Germanic was unwritten, the established spelling tradition is for all practical purposes a phonemic orthography, and I would think there wouldn't be any exceptions to worry about. It seems a tiny number of errors must have crept in, but those are apparently human errors and not exceptions to the proto-Germanic spelling system. I still think it's theoretically possible we could create a Lua module that would convert the spelling letter by letter into a pronunciation like we do with Greek. But I'll hold off on asking for that unless I notice there are a lot more errors than I realized. —Soap— 00:53, 13 November 2022 (UTC)[reply]

Genericized Trademark Etymology template[edit]

I think the title should be self-explanatory, I think a template linking to a glossary page and and adding a category would be helpful. Thoughts? Vininn126 (talk) 12:34, 8 November 2022 (UTC)[reply]

I'd be in favor. — Fytcha〈 T | L | C 〉 12:45, 8 November 2022 (UTC)[reply]
Perhaps it could take a parameter linking to the trademark's Wikipedia page. Vininn126 (talk) 12:49, 8 November 2022 (UTC)[reply]
That would be useful. — Fenakhay (حيطي · مساهماتي) 13:01, 8 November 2022 (UTC)[reply]
Well {{genericized trademark}} has been made with a shortcut. Wikipedia linking within the template seems undoable. Vininn126 (talk) 14:09, 8 November 2022 (UTC)[reply]

Sorting lists before saving[edit]

If I edit a page like bil#Swedish that contains a long list {{der4|sv|akutbil|bila|bilaccis|...|radiobil|terrängbil}}, is there any way that I can make sure that list is sorted before I save the page? I would like to mark/highlight the text from akutbil to terrängbil and click a "sort" button in the editor. -- LA2 (talk) 21:27, 8 November 2022 (UTC)[reply]

It should automatically sort, shouldn't it? Theknightwho (talk) 21:32, 8 November 2022 (UTC)[reply]
  • @LA2 Yes, {{der4}} should (and does, for me) automatically sort by default. I've been adding (English) derived terms recently and am of the opinion that it is better to chuck them in in whatever order is easiest and let the template do the sorting. (The only downside I see to this is it makes it harder to see if a particular term is in the list by visually scanning the source, but Ctrl + F already solves that problem.) - excarnateSojourner (talk | contrib) 21:54, 8 November 2022 (UTC)[reply]
Yes, der4 does the sorting. But similar templates on other languages of Wiktionary don't. And I would still like to have the list sorted in the source code. --LA2 (talk) 21:58, 8 November 2022 (UTC)[reply]
The only way to do that is to convert those lists to a template like {{der4}} (or one of the other variants), really. There can be all kinds of reasons why entries have something else, but it's usually because the lists pre-date the sorting templates (and no-one's got round to converting them yet), or a newbie editor didn't realise there were better options available when they made it. Theknightwho (talk) 00:38, 9 November 2022 (UTC)[reply]

Why does the template hcol create extra whitespace?[edit]

I noticed that the entry furunculus has had a ton of extra blank space in the Descendants section ever since this revision which switched from using {{top3}} to {{hcol}}. Is that a bug? The documentation of the later says it should produce results the "Same as {{top2}} but without using {{bottom}}". Urszag (talk) 01:57, 11 November 2022 (UTC)[reply]

@Urszag I am not familiar with {{hcol}}. It looks to be created by User:Useigor. I suspect it's a half-implemented experiment we should not be using. Benwing2 (talk) 15:12, 13 November 2022 (UTC)[reply]
Thank you. I just noticed, this seems to depend on which browser is used--I get the extra space with Safari 15.6.1, but not with Firefox 106.0.5. --Urszag (talk) 04:19, 15 November 2022 (UTC)[reply]
{{hrow}} has similar problem. I think it misses way to wrap around the objects or something. And we use that template in Proto-Slavic a lot. Sławobóg (talk) 18:53, 13 November 2022 (UTC)[reply]

Automatic import from another dictionary[edit]

The largest open machine-readable dictionary for Palestinian Arabic [ajp] will be released on December 8th (read the paper). With 36k entries from 17k lemmas, and 3.7k roots, it is probably the largest dictionary ever made for any Arabic variety. All entries include diacritized Arabic orthography, phonological transcription and English glosses. The author (Shahd Dibas, Oxford) told me that "the license is supposed to be CC BY 4.0". If that's the case, how can we upload all this content to Wiktionary? What about Wikidata? A455bcd9 (talk) 10:25, 12 November 2022 (UTC)[reply]

  • Not legally possible for Wikidata, which is licensed under CC0 1.0, which is essentially a public domain dedication that waives all copyright, with explicit legalese backups for jurisdictions where you can't just do that. CC BY requires attribution, which CC0 doesn't, so they're not compatible.
  • Probably legally possible for Wiktionary, since our license is CC BY-SA 3.0. Basically, CC BY requires attribution; CC BY-SA requires attribution and that all derivatives must also be under CC BY-SA or a compatible license. But there's nothing in CC BY that prevents you from adding such a restriction when you reuse a work; in fact it's designed for this to be possible. We'd just need to add a statement like "This entry was imported from the [blah blah database], licensed under CC BY 4.0" to any affected entries. Compare Template:NIKL and Template:Webster 1913 (the latter of which is not legally required due to the source being PD, but is still good to have for other reasons). I don't think the difference in Creative Commons license versions (3.0 vs. 4.0) is a problem either. After all, you can even use a CC BY-licensed image in a book that is otherwise copyrighted, "all rights reserved", as long as you give attribution for the image.
  • Besides legal concerns, there are also practical concerns about how we would want to use the data, e.g. whether we want to automatically import the data, merely adapting it to our formatting (as you seem to be implying), or want to use it as the basis of entries but with further manual oversight. If the database is of mediocre quality, or not in a format that can be converted neatly into ours, then we probably wouldn't want any kind of auto-importing. I haven't examined the preprint. I'd encourage input from South Levantine Arabic editors like SarahFatimaK and AdrianAbdulBaha. 98.170.164.88 01:06, 13 November 2022 (UTC)[reply]
    Thanks for your inputs.
    Regarding Wikidata, it's possible to add a reference under each entry, so I don't see why we couldn't add content there.
    I know Sarah and Adrian. They're not contributing on Wiktionary regarding Levantine anymore unfortunately; so I'm afraid they cannot help.
    Who else could help with the technical aspects of importing/adapting the data? I had early access to the dictionary and it's of high quality. A455bcd9 (talk) 08:11, 13 November 2022 (UTC)[reply]
    Sure, you can add references to claims in Wikidata, or have a property linking to external resources, etc. But the license of Wikidata implies that anyone can use any part of it without any attribution or referencing, which is incompatible with CC BY. See d:Wikidata:Licensing: "Other than public-domain data and CC0 data, no other data license or designation is compatible with Wikidata's copyright requirements". That page even explicitly says to avoid data licensed under "any Creative Commons license other than CC0". 98.170.164.88 08:20, 13 November 2022 (UTC)[reply]
    Yes but this page isn't super clear because it also says: "Wikidata contributors sometimes avoid uploading data when someone has made any of the following kinds of copyright claims on the data: [...] any Creative Commons license other than CC0. This includes Creative Commons Attribution, the very permissive license accepted on other Wikimedia projects." A455bcd9 (talk) 08:40, 13 November 2022 (UTC)[reply]
    We can back up and read the previous paragraph for context. The reason for "sometimes" is that the article is questioning the validity of copyright claims on datasets. If the copyright claims are invalid (e.g., because the work doesn't meet the threshold of originality, or doesn't really belong to the claimed author), that may be a different story. Dictionaries can definitely be under copyright, though. There are plenty of court cases that will back this up. So mass-importing every entry from a non-public-domain dictionary, even one licensed permissively under CC BY, onto a CC0 project, is probably not legally sound. But IANAL. 98.170.164.88 08:57, 13 November 2022 (UTC)[reply]
    OK got it thanks! A455bcd9 (talk) 09:04, 13 November 2022 (UTC)[reply]
    As for the more technical rather than legal questions, do you have any sense of how much processing would need to be done to import it onto Wiktionary? Would it be as simple as throwing the headword template with the right part of speech, {{ajp-root}} with the root, adding the English gloss, etc.? I imagine fitting verb conjugations and such into our templates might be tricky but I haven't really looked into how {{ajp-conj}} works. I also notice right off the bat that they make heavy use of tashkil whereas we present South Levantine Arabic without vowel marks, apparently only including vowels in transliterations. (This differs from our handling of Classical/MS Arabic.) I'm sure there are lots of other things that would need to be handled. 98.170.164.88 08:59, 13 November 2022 (UTC)[reply]
    Great questions. I guess we have to wait until the whole dictionary is released to answer these questions... A455bcd9 (talk) 09:05, 13 November 2022 (UTC)[reply]

Wrong deltas, phis, etc[edit]

As described at Wiktionary:Todo#Erroneous_Greek_characters, there is a recurring problem of people using various wrong characters for Greek letters, like ϕ in place of φ; we need to make another pass to clean up entries since there are dozens of instances again, but I wonder: could we catch/block this with an edit filter, e.g. check for occurrences of ϕ, ϑ, etc in {{l|grc| / {{l|el|| / {{m|grc| / {{m|el| and/or screen for instances of these characters occurring in space-delineated words consisting of Greek letters? - -sche (discuss) 11:36, 12 November 2022 (UTC)[reply]

Please don't. A lot of new editors, having a hard time just getting the symbols in, are just going to find that a slap in the face. Why are we so fussy, anyway? Our IPA template even complains if the user types the wrong "g":
IPA(key): g replace g with ɡ, invalid IPA characters (g). [edited to note, apparently the red error message that shows up in preview does not show up on the live page.]
Is it not possible to just have whatever templates, scripts, and modules we're relying on tolerate the use of the two variant forms of those letters? And if not, can a bot come through and clean them up once a year? I don't want to make more work for people who are already doing hard work. Best regards, —Soap— 00:57, 13 November 2022 (UTC)[reply]
We already have tracking links added by Module:script utilities: wrong-theta, wrong-kappa, wrong-rho, wrong-phi. Adding an edit filter would be possible, maybe something like the following: 
badchars:="\{\{(l|m|(der|bor|inh)\|[-a-z]+)\|(grc|el)\|[^}]*[ϑϰϱϕ]|\p{Greek}[ϑϰϱϕ]|[ϑϰϱϕ]\p{Greek}";
added_lines rlike badchars & !(removed_lines rlike badchars)
98.170.164.88 06:39, 13 November 2022 (UTC)[reply]
@Soap If you enter the wrong Unicode char you likely get a broken link. It's not always that easy to try to automatically correct this, e.g. people sometimes enter Latin characters in place of equivalent-looking Cyrillic characters but occasionally a Russian word will legitimately have a Latin character in it. Benwing2 (talk) 15:09, 13 November 2022 (UTC)[reply]
I've added two filters, one intended to catch only clearly incorrect uses (so it can ultimately be set to warn or prevent them), and one intended to catch and tag all uses (to catch misuses the first filter misses, at the cost of also catching false positives). - -sche (discuss) 09:42, 21 April 2023 (UTC)[reply]

Bot job: moving everything out of CAT:English acronyms for organizations and CAT:English initialisms for organizations[edit]

Hello - could somebody with a bot please do the following mass category changes? These two categories have been RFD deleted, and the pages in them were all removed from the parent categories when added to them in the first place - which we need to undo.

  1. Everything in CAT:English acronyms for organizations into CAT:English acronyms and CAT:en:Organizations.
  2. Everything in CAT:English initialisms for organizations into CAT:English initialisms and CAT:en:Organizations.

Theknightwho (talk) 17:14, 15 November 2022 (UTC)[reply]

@Theknightwho Done. Benwing2 (talk) 22:45, 20 November 2022 (UTC)[reply]

Category:Warumungu_language[edit]

Can someone add the missing data (family and script) to the relevant language data module for this please? I would do it myself but I don't have the necessary rights on this alt account of mine. Acolyte of Ice (talk) 13:06, 16 November 2022 (UTC)[reply]

Done. I just put it in aus-pam for now, pending further info on classification (if any exists). This, that and the other (talk) 01:50, 19 November 2022 (UTC)[reply]

Add support for twice-borrowed terms to Template:dercat[edit]

{{dercat|en|en}} should generate [[Category:English twice-borrowed terms]], as you would expect from the behavior of {{der|en|en}}. At present it instead generates [[Category:English terms derived from English]]. Special:Diff/69868639 should fix this. 98.170.164.88 08:00, 18 November 2022 (UTC)[reply]

Done. Benwing2 (talk) 22:45, 20 November 2022 (UTC)[reply]

Automatic English IPA template[edit]

Is there a reason why we can't write a module that converts enPR into English IPA (both phonemic and phonetic)? It seems that this would be preferable to manually maintaining any changes in our notation of phonemes and phones per dialect (cf. the recent discussions on Beer Parlour) as well as more useful as phonetic pronunciation could be generated automatically, and since we already try to include enPR in our pages, might as well use it for the IPA.

Pinging some English editors: @Equinox, The Editor's Apprentice, Whoop whoop pull up, Sgconlaw, Theknightwho, Soap, please feel free to ping others as I'm not completely familiar with the English editor base. Thadh (talk) 22:49, 19 November 2022 (UTC)[reply]

The idea of an English pronunciation module has been being discussed recently :) although it may make more sense for it to take IPA (the precise, primary pronunciation-indication method) as input and output enPR from that. (Why doesn't {{IPA|en}} already take care of outputting en-PR?) Another advantage besides not having to type both IPA and en-PR is that it could automatically include lines for things like the cot-caught merger (once we stop using /ɔ/ for things other than /ɔ/, so it can know that every /ɔ/ gets a second line showing that cot-caught merging speakers have /ɑ/ instead, where at present it wouldn't be able to reliably guess which /ɔ/s secretly mean /o/ and so aren't involved in the merger). - -sche (discuss) 01:17, 20 November 2022 (UTC)[reply]
My understanding is that enPR was designed for a simplified version of GenAm and glosses over a lot of the mergers, splits and other regional variation that are making it so hard for us to arrive at standards for IPA, but I don't deal with enPR myself. Pinging @Mahagaja, who probably knows more about enPR than he would like... Chuck Entz (talk) 02:26, 20 November 2022 (UTC)[reply]
I am not so sure that IPA will be easier to work with, although ultimately it's just a question of convenience. The very precision of IPA could make it a bit harder to standardize which symbols to use; e.g. ă ŭ ŏ are fairly obvious representations of TRAP STRUT LOT, but in IPA it's often necessary to decide between a more conventional and conservative option such as [æ ʌ ɒ] or an alternative option argued to be more phonetically accurate (for some accent or another) such as TRAP = [a], STRUT = [ə] (or [ɐ], or [a]), LOT = [ɔ]. Also, IPA is usually used for phonetic or phonemic transcriptions, whereas the input for a conversion process should probably be a diaphonemic transcription (unless that is considered too complicated to use).--Urszag (talk) 02:38, 20 November 2022 (UTC)[reply]
@Thadh I am planning on starting on an English pronunciation module soon. I have written such modules for several languages. My plan is to use an approximation of actual English spelling as the respelling, with some diacritics added to denote things like primary and secondary stress. This is what I do currently e.g. for Portuguese (see {{pt-IPA}}), and it's what I did for German (the German module is not yet released but you can see lots of testcases along with the current output at Module:User:Benwing2/de-pron/testcases/prefixes, Module:User:Benwing2/de-pron/testcases/suffixes and Module:User:Benwing2/de-pron/testcases/misc). I don't want to use IPA for the respelling because that is likely to lead to inconsistencies, as noted by User:Urszag. The first thing I will do is create a page with a bunch of testcases, similar to the German testcases just mentioned; this should help refine the particular respelling conventions. Note also that the module will not allow all possible respellings, but will throw errors for certain combinations, e.g. the use of 'ough' in respelling, as well as short vowels followed by single consonants (except in certain circumstances) is likely to result in an error since these combinations are too ambiguous to reliably interpret. Hence the beginning of the Gettysburg address might be respelled something like 'fore score and sevvan years ago, our fahdhars braught forth on this continènt a new naition, canceeved in Libbarty, and déddicàited to the pròppazítion that aull men are creeáited eequal'. Here, 'a' is used for schwa; acute accents indicate primary stress when it doesn't follow the standard third-from-the-end rule or can be inferred from the occurrences of schwas (which never bear stress); grave accents indicate secondary stress; the module knows how to handle certain common words like 'the', 'a' 'is', 'are', etc.; the module knows about final -tion, -y and various other suffixes; etc. The respelling should be abstract enough that all major English accents can be generated from it. Benwing2 (talk) 04:36, 20 November 2022 (UTC)[reply]
I guess it depends on how “regular” English spelling is at reflecting the pronunciations of terms. I’m under the impression that it isn’t regular enough, but maybe we can try creating a template that would generate the IPA in straightforward cases, and continue indicating the IPA manually where the spelling is irregular. — Sgconlaw (talk) 05:35, 20 November 2022 (UTC)[reply]
@Sgconlaw This shouldn't be needed; in cases where the spelling is irregular, you just use phonetic respelling, e.g. diaphragm might be respelled 'dieaphràem', or maybe 'dīaphrằm' if it's preferred to use macrons for "long" vowels and breves for "short" vowels (the only issue with the latter approach is that you sometimes get two diacritics stacked on top of each other, as in the example I just gave). Phonetic respelling is definitely possible in English; it's true that English spelling has lots of irregularities but in practice that just means there are fewer words like the actual spelling of the word suffices for the respelling. Benwing2 (talk) 06:07, 20 November 2022 (UTC)[reply]
@Benwing2: ah, I see. — Sgconlaw (talk) 09:18, 20 November 2022 (UTC)[reply]
@Benwing2: thanks for handling the technical part of it and for the explanation. I personally think a unified imput (so basically either enPR or another similar standardised and documented respelling system) may be preferable, but the English editing community ought to decide on that. Thadh (talk) 09:32, 20 November 2022 (UTC)[reply]
I think this is a very interesting and valuable discussion. I full heartedly support the creation of a template/module that generates IPA pronunciations for multiple dialects of English. I think an important thing to consider is that there are notable dialects of English, such as Indian and Nigerian, that have pronunciations influenced by spelling and/or careful pronunciations of words. In the case of vowels, this include "full"/non-reduced vowels where other dialects, such as US and UK, would have reduced vowels. I think any template/module should at least support US, UK, Indian, and Philippine English since their respective countries have some of the most numerically large and culturally significant populations of English speakers (per David Crystal's English as a Global Language, admittedly from 2003). Additionally, there are also some dialects which have innovative splits, like South African English's split with the KIT vowel. Whether a respelling scheme like Benwing's or something like enPR can best handle these and other factors, I am unsure. —The Editor's Apprentice (talk) 20:34, 20 November 2022 (UTC)[reply]
Pinging @AG202, @Equinox, @Jodi1729, @Donnanz who may be interested in this discussion. —The Editor's Apprentice (talk) 20:45, 20 November 2022 (UTC)[reply]
@The Editor's Apprentice IMO it's going to get too complicated to try and cater to various foreign-influenced dialects of English in the main respelling. It will be complex enough to handle GA and RP in a single respelling, and some words will require separate GA vs. RP respellings, but it would get much more complicated to account for accents without vowel reduction that use spelling pronunciations. I think the best that can be done is to provide separate parameters that allow for e.g. Nigerian English respellings, where if provided, a line will be generated containing the appropriate pronunciation, but by default something like Nigerian English won't have a generated pronunciation. This is similar to the issues we've run into accounting for both Brazilian and European Portuguese in a single respelling in {{pt-IPA}}; we haven't even tried to account for Mozambican or Angolan Portuguese or nonstandard Brazilian dialects. On top of this, it's IMO doubtful that there are enough linguistic resources out there on the Internet describing things like Indian and Nigerian English in enough detail that I could write a pronunciation module for them. Benwing2 (talk) 23:01, 20 November 2022 (UTC)[reply]
@The Editor's Apprentice Thx, TEA. I don't know how any of this works. Would this be like the Chinese regional dialect module? Jodi1729 (talk) 23:32, 20 November 2022 (UTC)[reply]
Agree that it should support other dialects, but they should not be generated if not specified. For some context, I partly work on Hong Kong English, which has quite some variation in pronunciation, so I usually just omit it when the pronunciation is inferable from RP (and sometimes GenAm/CAE), and provide a phonemic transcription where there are exceptions. There're a few occasions when I don't know what to put in as the IPA as BrE/AmE uses different transcriptions for the same vowel, so it would be beneficial to have some template for accepting phonemes and outputting the corresponding IPA symbols.
I agree with Benwing on having optional parameters for these outer dialects. My idea would be these can accept respellings (and output it according to the respelling rules), references to the IPA in BrE/AmE (to avoid duplication and clutter, e.g. something like |India=@UK1 in schedule), and /phonemic IPA/ or [phonetic IPA] when the module does not support it. I think the module also should map the variation when these are straightforward (which is the case for HKE with the exception of the realisation of the CUTE vowel, L-vocalisation, non-reduction of schwas and stress position), and raise errors when users try to get the module to output non-straightforward pronunciations. Of course the most important part of this work would be the inner Anglosphere, so the infrastructure for the outer dialects can be done later as long as the code leaves some leeway for making such changes (e.g. not reducing the schwas even though both BrE/AmE has them reduced, as TEA has mentioned). – Wpi31 (talk) 13:26, 22 November 2022 (UTC)[reply]
FWIW, my rationale for IPA input was: introducing a third notation system seems like adding the drawbacks of another competing standard, while people who think a word has /a/ not /æ/ will probably still either try to figure out which respelling gives them the "correct" IPA, or think the module is faulty for outputting "wrong" IPA and use manual {{IPA}} instead. (Will speakers who use the same vowel in both syllables of "murder" or "London" realize they're meant to use different vowels in respelling those words so dialects that distinguish the vowels can do so, or are they gonna respell both as "uh"?) But I know this isn't introducing a new issue, we have this already with people inputting /ə/s that should be /ɪ/, /ɛ/, etc, and I know we use respelling on other (more regular) languages, so I'm all for trying it here if that's what you want to do.
As long as Nigerians can provide Nigerian (etc) pronunciations as separate * {{a|Nigeria}} {{IPA|en|...}} lines, or separate (IPA or respelling) parameters, I agree with Wpi31 it's not a big issue if the main respelling only works for the "inner Anglosphere". Perhaps over time we could develop the module to where we could input some (optional, secondary, intended for adepts only?) maximally-disambiguatory respelling parameter that does make historical distinctions, e.g. the meat-meet or pane-pain distinction only a few dialects (and none of the national standards) still make, and modern innovations like South Africa's kit split, and the module can generate all those things from that. And for dialects that use spelling pronunciations, might it be possible for the module to generate them by considering the page title + the US/UK respelling? - -sche (discuss) 20:38, 22 November 2022 (UTC)[reply]

User:Fytcha/TranscludeTranslationSubpages.js[edit]

Seeing that we use {{see translation subpage}} more and more, I wrote a script that transcludes these translation subpages onto the main page because I hate having information spread out to multiple pages (you can enable it by adding this line to your common.js). However, it currently doesn't work as expected because MediaWiki:Gadget-TranslationAdder.js#L-1378 is executed before the subpages are transcluded. Does anybody know how I can re-run the translation gadget on my inserted translation boxes? — Fytcha〈 T | L | C 〉 18:24, 20 November 2022 (UTC)[reply]

All languages are expanded, after a search. This is very bad UX on mobile[edit]

I often study french on my cellphone, and I really like Wiktionary's quality

But if you open https://en.wiktionary.org/wiki/jeton on Firefox on android, what I see is all languages expanded. Either I have to scroll a lot, or to click to close each language.

I think this is bad UX, since users will rarely want to see more than one language.

Perhaps English could be expanded, but the other languages should all be collapsed

(is this the right place to discuss this?)

Note that there are solutions for a user (such as going to https://en.wiktionary.org/wiki/jeton#French, which can be configured as a search in Firefox). But ideally I'd like to help the problem go away for all users (and for me as well, if using another browser) Josinalvo (talk) 17:17, 21 November 2022 (UTC)[reply]

This is a known issue that the MediaWiki developers have zero interest in fixing. — SURJECTION / T / C / L / 17:34, 21 November 2022 (UTC)[reply]
lol ―Biolongvistul (talk) 18:31, 21 November 2022 (UTC)[reply]
Is there another bug reporter, or some rejected issue explaining why? Josinalvo (talk) 17:33, 22 November 2022 (UTC)[reply]
[2], [3], and if anyone else opens a ticket, I can only see it being closed as nobody will work on it anyway. — SURJECTION / T / C / L / 19:04, 22 November 2022 (UTC)[reply]
It cannot be fixed with CSS and probably not easily even with JavaScript. — SURJECTION / T / C / L / 19:04, 22 November 2022 (UTC)[reply]
I am quite sure I can write javascript to fix it. If there is a consensus/people want to use it, just let me know and I'll try Josinalvo (talk) 14:53, 23 November 2022 (UTC)[reply]
(as long as we can control when the javascript runs... That is not a given, though) Josinalvo (talk) 14:55, 23 November 2022 (UTC)[reply]

Help! It's not allowing me to make "ᵆ".[edit]

It says I'm a spammer! I'm not! When I try again, it says it's an unsupported language! — This unsigned comment was added by Atarilynx999 (talk • contribs) at 07:53, 22 November 2022.

What page are you trying to create? ᵆ? Theknightwho (talk) 18:43, 23 November 2022 (UTC)[reply]
@Theknightwho you can view the abuse filter logs from their contributions page. @Atarilynx999: you can't just create stub pages without headers or definitions. See WT:EL, and also compare what we do in other similar entries. That's the kind of thing vandals tend to do, so the abuse filter was programmed to look for that. Chuck Entz (talk) 20:10, 23 November 2022 (UTC)[reply]
Thanks. Theknightwho (talk) 20:13, 23 November 2022 (UTC)[reply]

Thank you! I've made the page now. ᵆ Atarilynx999 (talk) 06:01, 30 November 2022 (UTC)[reply]

zlw-slv-decl-noun[edit]

How do I make this table remove the accent from the words, as it happens in other templates (Module:zlw-slv-entry name)? See zìe̯mjă. Also, why is that template so wide in χlʉ̀ɵ̯p? Sławobóg (talk) 13:29, 23 November 2022 (UTC)[reply]

Yet more unsupported titles displaying incorrectly[edit]

The following fourteen lines need to be added to MediaWiki:UnsupportedTitles.js to account for a bunch of currently-incorrectly-displayed unsupported titles (can't do it myself, since I'm not an admin):

  • 'Colon_hyphen_slash': ':-/',
  • 'Colon_capital_D': ':D',
  • 'Colon_hyphen_capital_D': ':-D',
  • 'Colon_small_d': ':d',
  • 'Colon_hyphen_capital_P': ':-P',
  • 'Colon_hyphen_small_p': ':-p',
  • 'Colon_hyphen_left_curly_bracket': ':-{',
  • 'Colon_hyphen_capital_thorn': ':-Þ',
  • 'Colon_hyphen_lowercase_thorn': ':-þ',
  • 'Semicolon': ';',
  • 'Nine_low_line_nine': '9_9',
  • 'MeToos': '#MeToos',
  • 'MeTooing': '#MeTooing',
  • 'MeTooed': '#MeTooed',

Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 19:13, 23 November 2022 (UTC)[reply]

Make that fifteen:
  • 'End_s_tag': '</s>'
Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 05:13, 25 November 2022 (UTC)[reply]
Added. (Now, if we could update the script so it could also change pagetitles in mainspace, to address this, that'd be neat.) - -sche (discuss) 08:53, 25 November 2022 (UTC)[reply]
@-sche - Thanx for the effort, but the unsupported-title display-substitution seems to've stopped working completely - aw, carp. Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 15:07, 25 November 2022 (UTC)[reply]
Aha, there was a comma missing. I think I've fixed it. - -sche (discuss) 21:36, 25 November 2022 (UTC)[reply]
Working now. Arigato! Whoop whoop pull up Bitching Betty ⚧️ Averted crashes 23:46, 25 November 2022 (UTC)[reply]

Zulu level in User page[edit]

«Lomsebenzisi akanalo noluncane ulwazi lwesiNgisi (okanye kunzima kakhulu ukusiqondisisa).»
This user does not know English (or understands it with great difficulty).

Or something like that anyway. Why does it say English in the output of User-zulu-0? It should say lwesiZulu, not lwesiNgisi. MGorrone (talk) 10:41, 24 November 2022 (UTC)[reply]

It's not specific to Wiktionary; if you were to write {{#babel:zu-0}} on en.wikipedia, or for that matter fr.wikiquote, the output would be the same. Blame translatewiki.net. See translatewiki:MediaWiki:Babel-0-n/zu. 98.170.164.88 09:08, 25 November 2022 (UTC)[reply]
So those Babel templates werent written by us? I was wondering earlier if the surprisingly literal translations of "with great difficulty" into many languages were Englishisms .... English doesnt have a good antonym for easily since hardly has undergone semantic shift .... but figured that if the translations were wrong or even subpar, we would have changed them by now. —Soap— 00:35, 27 November 2022 (UTC)[reply]
We do have our own Babel templates like Template:User zu which display the correct text, but if someone uses the Mediawiki babel extension instead, then it loads the (incorrect) central text. (Anyone have contact with the translatewiki folks?) - -sche (discuss) 00:51, 27 November 2022 (UTC)[reply]
Okay thank you. I was still working on a second reply before I saw this .... where I said that I tried joining the site to fix the error, but it seems that they require new users to pass a test of sorts before they can fix even such an obvious error such as this. Hopefully there's some kind of back channel we can go through to get the Zulu template fixed quickly. In the meantime, it's good to know that we have our own version of the Babel template that is under our control, where we can fix obvious errors and, if necessary, also debate finer points of translation. —Soap— 00:53, 27 November 2022 (UTC)[reply]
So, does anyone else agree with me that the wording of some templates is too narrowly based on the English, and that we could replace, for example, con mucha dificultad with something like difícilmente? its certainly possible that Im wrong, but it seems that English is the odd one out, not having a good antonym for easily, where other languages dont have this gap and dont need to use a multiple-word expression. —Soap— 17:22, 30 November 2022 (UTC)[reply]

Quebec not linked from template:lb|fr[edit]

On pages like chien chaud, the lack of a link to Quebec really stands out. The template seems to be working properly, since the word is categorized as part of Category:Quebec French. But it seems odd that we would link nearly everything else except that. Should we change it? I dont know how and it's most likely buried in a module somewhere that I wouldnt have access to in any case. Thanks, —Soap— 18:56, 26 November 2022 (UTC)[reply]

Done. Theknightwho (talk) 19:34, 26 November 2022 (UTC)[reply]

Check for various IPA errors[edit]

I've seen some recurring IPA errors or nonstandard notations, if anyone wants to generate cleanup lists:

  1. some dictionaries like Dictionary.com misuse the vowel sign /y/ to mean /j/ (even in their "IPA"!), so people copying from or thinking of them sometimes put /y/ into English entries' IPA where they should put /j/; unless there's a dialect that really has the vowel /y/, any English entry's IPA containing /y/ is this should-be-/j/ error
  2. people notate diphthongs in nonstandard ways, e.g. /ei/ in place of /eɪ/ (if we want to change how we notate diphthongs, as proposed in the BP, that's one thing, but for now we should be consistent)
  3. check for English plurals or third-person verb forms where the pagetitle ends in rs but the IPA ends in /-s/ (should be /-z/); likewise for other combinations that should produce /-z/ but have /-s/; this is a surprisingly common error, e.g. abductors, abhors (which I've fixed), abhorrers, absorptions, ...

- -sche (discuss) 09:55, 27 November 2022 (UTC)[reply]

I remember hearing a recording many years ago of a woman from Tennessee who said spoon as /spy:n/ with a spike in the intonation of the first part of the syllable. Southern/Appalachian English has a lot of regional variation in vowels. It's quite localized, though, so I doubt we would see something like that in an entry. Chuck Entz (talk) 16:11, 27 November 2022 (UTC)[reply]
@-sche: Urban British English (and in lack of a better term “British” includes ”Irish” as before independence) regularly has /y:/ where standards have /u:/, so if you want to imply bottability you are wrong, given also that I added those with accent markers (like some are slang words I haven’t even heard from elsewhere), but you may of course mean “unless followed by ‘:’”.
I don’t think we can change how IPA is notated. Fay Freak (talk) 18:02, 27 November 2022 (UTC)[reply]
Oh, I'm not proposing to bot-change these entries, just that I'd like a list of them for humans to look over. If it turns out we have a lot of dialectal pronunciations with actual-vowel-/y/, let's filter out such instances (based on the line being tagged with the relevant label). - -sche (discuss) 22:18, 27 November 2022 (UTC)[reply]
Even if there are English speakers who use the phone [y] in words like spoon, this would not warrant using a transcription with /y/ unless there is a phonemic contrast for those speakers between this /y/ and a distinct phoneme /u/: phonetic changes like fronting (common for /u/ in many varieties of English, although often described as having a less-than-fully-front outcome like [ʉ]) do not alter the phonemic inventory of the language unless they cause a merger or split.--Urszag (talk) 23:09, 27 November 2022 (UTC)[reply]
Why should the symbol y be used only if there is a contrast? I think if someone wants to design or use a consistent phonemic transcription for a particular accent, it makes sense to choose the symbols that are best suited to the features of the vowel phonemes. Wiktionary doesn't have an obligation to stick to symbols similar to Received Pronunciation or General American. But I haven't seen such a system being widely used on Wiktionary. The nearest thing that I have seen is the use of /ʉ/ for the goose and full and cure vowels in Scottish English transcriptions, though some varieties of Scottish English might have [u] for the goat vowel, which would fulfill your criterion. — Eru·tuon 23:41, 27 November 2022 (UTC)[reply]

然う[edit]

Does anyone know how to fix this template loop involving {{ja-see}}? 98.170.164.88 21:53, 27 November 2022 (UTC)[reply]

Feature req: Useful hypertext dictionary interface[edit]

My ability to read Chinese characters is limited, and as they clump in words/phrases of variable length, looking up a longish section of characters I don't understand is difficult. For example, the following sentence, if one mouses over it, will be found to contain three two-character phrases and a single-character link:

桂林山水甲天下

You can imagine that if you had no idea what any of the characters meant, you might try to search the first four or three characters first, and take a lot of time to correctly break it down into component words. As it happens, the phrase is a conventional one and there is an entry on the entire thing:

桂林山水甲天下

With a paper dictionary, iterative entry-hunting is inevitable, but Wiktionary is hypertext. So, could anyone write an interface that would lighten this manual drudgery, by taking a string of characters and providing links to the entries on each of the characters, and then providing links to entries containing multi-character substrings of the original string? If it just displayed all the links, ideally stacked and aligned, it would be quick and easy for a human to parse and figure out which entries applied.

I'd be happy to help write such a thing, but wouldn't know where to start. I'm not even sure it doesn't already exist! But I'm familiar with regexes and coding and have played with the Mediawiki API; I could write algorithms. HLHJ (talk) 20:13, 28 November 2022 (UTC)[reply]

Feature request: make navigation popups more useful[edit]

This has been discussed before, but: navigation popups (also called Lupin popups) are useful on Wikipedia, where they load a snippet of the lead text of an article. On Wiktionary, they're useful when hovering over a link to a diff, but when hovering over a link to an entry, they just load the page's first L2 header. Not the content after that header, just the text of the header; they just load "Finnish" and nothing else. Could someone make them also load at least the first POS header (first L3 or L4 header that's not Alternative forms, Etymology or Pronunciation?), and ideally the first definition? Or even just the first (say) 500 characters of the page? (Without breaking the diff-link-previewing functionality.) - -sche (discuss) 09:00, 29 November 2022 (UTC)[reply]

Changing the default setting of popupPreviewCutHeadings from true to false would help, although you'll run into the issue that templatized links won't display. You could also change popupPreviewKillTemplates to false, which would make it display the raw template code. 98.170.164.88 19:06, 30 November 2022 (UTC)[reply]
I found that these settings make it more useful when I tested by hovering over page titles on Special:RecentChanges. Potentially could be tweaked:
pg.option['popupMaxPreviewCharacters'] = 1000;
pg.option['popupMaxPreviewSentences'] = 10;
pg.option['popupPreviewFirstParOnly'] = false;
pg.option['popupPreviewCutHeadings'] = false;
pg.option['popupPreviewKillTemplates'] = false;
Some links still don't display anything at all, and I'm not sure why. This includes links to specific language sections, but also various other links. 98.170.164.88 19:31, 30 November 2022 (UTC)[reply]
That's an improvement, thanks (I changed popupPreviewFirstParOnly and popupPreviewCutHeadings but not popupPreviewKillTemplates). It's interesting that some links (still) don't display anything, as you say. - -sche (discuss) 02:53, 1 December 2022 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2022/November&oldid=78297201"