Wiktionary:Beer parlour
Wiktionary > Discussion rooms > Beer parlour
Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance. |
Tea room start a new discussion | this month | archives Questions and discussions about specific words. |
Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words. |
Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements. |
Grease pit start a new discussion | this month | archives Technical questions, requests and discussions. |
All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5 |
Welcome to the Beer Parlour! This is the place where many a historic decision has been made, and where important discussions are being held daily. If you have a question about fundamental aspects of Wiktionary—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list below (click on Start a new discussion), and it will be considered. Please keep in mind the rules of discussion: remain civil, don’t make personal attacks, don’t change other people’s posts, and sign your comments with four tildes (~~~~), which produces your name with timestamp. Also keep in mind the purpose of this page and consider before posting here whether one of our other discussion rooms may be a more appropriate venue for your questions or concerns.
Sometimes discussions started here are moved to other pages for further development. In particular, changes to a major policy or guideline may be discussed on the corresponding talk page and “simple votes” (as opposed to drawn-out discussions) can be conducted on our votes page.
Questions and answers typically remain visible on this page for one to two months, but they can always be found in the appropriate monthly archive (based on the date discussion was initiated). While we make a point to preserve all discussions that were started here, talk that is clearly not appropriate for this page may be deleted. Enjoy the Beer parlour!
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Citations talk namespace
[edit]The citations talk namespace has only two pages: Citations talk:Frühgeburtskernikteri and Citations talk:Tai Ji Men. Maybe the namespace can be deleted with any discussions going to the entry's main talk page. Ioaxxere (talk) 05:56, 1 September 2024 (UTC)
- I don't think this is possible, is it? Doesn't every namespace need an equivalent talk namespace? Theknightwho (talk) 13:02, 1 September 2024 (UTC)
- @Theknightwho: If it isn't possible, we can discourage it by creating an edit filter and hiding the portlet link when you're at a Citations page (this is already the case). A bot could also be created to move all existing content from Citations talk to Citations on a regular basis as well. If we decide not to do this then the link should not be getting hidden in my opinion. Ioaxxere (talk) 15:21, 1 September 2024 (UTC)
- Whether or not it's possible, the RFD discussions mentioned on those pages should definitely go to the talk pages, as per our normal practice. They shouldn't be on a Citations talk page that most users won't know about, let alone think to look at. Andrew Sheedy (talk) 21:44, 1 September 2024 (UTC)
- It looks like we had an edit filter that stopped Citations talk pages from being created, but I don't know why it was turned off. Theknightwho (talk) 00:32, 2 September 2024 (UTC)
- Interesting: Erutuon turned it off on 17 August 2020, saying "Added entry in MediaWiki:Titleblacklist, so this filter is unnecessary." But the two pages mentioned above were both created after that, so either something went wrong with the title blacklist entry, or the issue is that both Citations-talk pages were created by sysops, who may have the rights to defy the blacklist (and because they were making the edit via a gadget, may not even have realized they were doing so). I see a few possible solutions, including editing aWa to automatically change "Citations talk:" to "Talk:", or re-enabling the edit filter (which would mean attempts to archive a discussion with aWa fail and require the user to manually go back and fetch the content and manually archive it, which is a faff...). - -sche (discuss) 06:04, 2 September 2024 (UTC)
- @-sche: Yes, it looks like those entries were created by admins using aWa, so that gadget should probably be set to archive things under the main talk page. Courtesy pinging @Erutuon, who also might be interested to work on this. Ioaxxere (talk) 06:57, 2 September 2024 (UTC)
- Interesting: Erutuon turned it off on 17 August 2020, saying "Added entry in MediaWiki:Titleblacklist, so this filter is unnecessary." But the two pages mentioned above were both created after that, so either something went wrong with the title blacklist entry, or the issue is that both Citations-talk pages were created by sysops, who may have the rights to defy the blacklist (and because they were making the edit via a gadget, may not even have realized they were doing so). I see a few possible solutions, including editing aWa to automatically change "Citations talk:" to "Talk:", or re-enabling the edit filter (which would mean attempts to archive a discussion with aWa fail and require the user to manually go back and fetch the content and manually archive it, which is a faff...). - -sche (discuss) 06:04, 2 September 2024 (UTC)
- It looks like we had an edit filter that stopped Citations talk pages from being created, but I don't know why it was turned off. Theknightwho (talk) 00:32, 2 September 2024 (UTC)
- Tangentially related — today I rewrote MediaWiki:Gadget-DocTabs.js and in the process encountered two more edge cases that are currently not handled correctly: template documentation talk (e.g. Template talk:pi-alt/documentation) and module documentation talk (e.g. Module talk:inc-pra-Brah-translit/documentation). I'm mentioning this here because the issue is caused by the same things that @-sche brought up above. Ioaxxere (talk) 06:57, 2 September 2024 (UTC)
Superstition category
[edit]I propose we add a Superstition related-to category placed under Folklore (as suggested by @Qwertygiy and @Theknightwho) on Discord). Vininn126 (talk) 12:26, 1 September 2024 (UTC)
Interwiki
[edit]- See also: #What should I do
May I create such interwiki? ПростаРечь (talk) 12:26, 1 September 2024 (UTC)
- I have no problem with this. Theknightwho (talk) 22:07, 5 September 2024 (UTC)
@PUC May I hear your opinion? ПростаРечь (talk) 06:24, 3 September 2024 (UTC)
Unnamed parameters in etymology templates
[edit]In the etymology templates like {{bor}}
, {{inh}}
, etc. all others and, I think it would be convenient if unnamed parameters (except the first, which is the lang code) are for more words, which would help avoid typing out, for example: {{inh|FOO|BAR|TERM1}}
, {{m|BAR|TERM2}}
, {{m|BAR|TERM3}}
which would be replaced by {{inh|FOO|BAR|TERM1|TERM2|TERM3}}
(and similarly for {{cog}}
, {{der}}
, etc.).
- This is similar to how the templates:
{{alt}}
and{{desc}}
function. - In this proposed pattern, meaning of the word(s) would stricly be entered using
|tN=
(t1, t2, t3, ... correspond to TERM1, TERM2, TERM3; for convenience,|t=
will be same as|t1=
). - Similarly, the term(s) to be displayed, if different from the term linked, would stricly be entered using
|altN=
. - Example:
{{cog|FOO|TERM1||MEANING1}}
,{{m|FOO|TERM2||MEANING1}}
→{{cog|FOO|TERM1|t1=MEANING1|TERM2|t2=MEANING2}}
- This would especially be very helpful when using typing aids since
subst:chars
would only have to be typed once. - For more convenience, we can possibly change
|altN=
to|aN=
,|dN=
(display), or|sN=
(show) thus minimizing the slight extra effort that will be needed if this proposal is to be implemented. - This proposal can also be extended to other linking templates like
{{m}}
and{{l}}
if there is consensus.
This was sometime ago raised on WT:Discord as well but the discussion died down without follow-up. Svartava (talk) 17:52, 1 September 2024 (UTC)
- I don't recall often having to list a word as being inherited from multiple lemmas per ancestor, or having multiple cognates in a single related language. What are some example entries where this would be useful?--Urszag (talk) 18:45, 1 September 2024 (UTC)
- I get that this varies with languages/families or editors, but I very often have to do this, e.g. 𑀮𑁄𑀡𑀺𑀬, 𑘄𑘡𑘿𑘮𑘰𑘯𑘰, इंदूर etc. When the ancestor or cognate has alternative forms, I always like to mention (as well as read) them whenever relevant. Svartava (talk) 18:58, 1 September 2024 (UTC)
- @Svartava It would be better to use
//
syntax (e.g.{{m|en|foo//bar}}
gives foo/bar), but we still need to work out how to handle transliterations with that format, since some languagse (e.g. Chinese) use slashes but only have one translit. Theknightwho (talk) 00:01, 2 September 2024 (UTC)- @Theknightwho: So in that case, would t1 and alt1 correspond to foo and t2 and alt2 to bar? Alternatively, this might also be workable:
{{m|LANG|foo<t:meaning><tr:xlit>}}
along with the original proposal, similar to{{desc}}
. Svartava (talk) 03:43, 2 September 2024 (UTC)- @Svartava I initiated the change to
{{desc}}
to the syntax you're proposing, but I'm not currently convinced this is needed for{{bor}}
,{{inh}}
, etc. since as User:Urszag noted it doesn't seem so common to have multiple ancestral lemmas of a given term in the same language. If we add support for this I'd propose allowing for comma-separated lemmas in a single param with inline modifiers, e.g. your example of इंदूर (indūr) would use something like{{inh+|mr|pra|*𑀇𑀁𑀤𑁅𑀭,*𑀇𑀁𑀤𑀯𑀼𑀭,𑀇𑀁𑀤𑀧𑀼𑀭}}
. This syntax is already supported for all form-of templates; to allow for embedded commas in a lemma, the comma is only recognized as a separator if not followed by a space and not preceded by a backslash. Benwing2 (talk) 03:45, 5 September 2024 (UTC)- @Benwing2 That looks like a nice idea. How do we provide the meanings and alternate display in the form-of templates? I don't see it by
|t=T1,T2
or|t1=T1
and|t2=T2
? Svartava (talk) 03:53, 5 September 2024 (UTC)- @Svartava Use inline modifiers. Benwing2 (talk) 03:54, 5 September 2024 (UTC)
- @Benwing2: Since this discussion has died down, is it possible for you add support for multiple terms using the form-of templates format, when you have time? Or would it have to be taken to a vote? Svartava (talk) 16:48, 6 October 2024 (UTC)
- @Svartava Use inline modifiers. Benwing2 (talk) 03:54, 5 September 2024 (UTC)
- @Benwing2 That looks like a nice idea. How do we provide the meanings and alternate display in the form-of templates? I don't see it by
- @Svartava I initiated the change to
- @Theknightwho: So in that case, would t1 and alt1 correspond to foo and t2 and alt2 to bar? Alternatively, this might also be workable:
- @Svartava It would be better to use
- I get that this varies with languages/families or editors, but I very often have to do this, e.g. 𑀮𑁄𑀡𑀺𑀬, 𑘄𑘡𑘿𑘮𑘰𑘯𑘰, इंदूर etc. When the ancestor or cognate has alternative forms, I always like to mention (as well as read) them whenever relevant. Svartava (talk) 18:58, 1 September 2024 (UTC)
- Personally I would support the original proposal. To me it seems tidiest and given how
{{desc}}
was made to work I think it'd be nice if all templates would work the same for the sake of consistency. I don't think this is rare by any means, I've had to write this a number of times and a quick searchinsource:/\{(der|inh|bor|cog)[^}]+\}\}, \{\{m\|/
reveals 35k hits throughout the project. However I'd also be happy with Benwing's solution. It does feel like extra syntax to be aware of, but it seems a good compromise with editors who'd prefer to continue using unnamed parameters for|alt=
and|t=
. As a separate note, I also liked the idea of shortening|alt=
to something like|d=
, all things aside. Catonif (talk) 10:46, 10 September 2024 (UTC) - While the possibility of specifying multiple parents in one template is entirely agreeable, I don’t think that unnamed parameters are the way to go. Upending the elegant, laconic and ubiquitous link-display-translation syntax in order to optimise this relatively uncommon situation is not worth it, and any other solution, whether parameter- or comma-based, is preferable. ―Biolongvistul (talk) 12:43, 10 September 2024 (UTC)
- I haven't seen any work on this yet but this is something needed for sure that I support. Juwan (talk) 18:19, 29 October 2024 (UTC)
- @JnpoJuwan @Svartava Hi, I will try to find time to implement the form-of format when I have a chance. Benwing2 (talk) 22:38, 29 October 2024 (UTC)
Creating Wiktionary Pages for Generation Z Slang
[edit]Hello,
Today I read a w:List of Generation Z slang on Wikipedia, and I created audio for a couple of slang terms. I did create audio on Lingua Libre for two slang terms that don't have English Wiktionary pages yet. Is Wikipedia's list of Generation Z slang sufficient evidence these terms exist, or do I need to further attest their existence by digging up quotes on the Internet?
bouncing on it: | (file) |
big yikes: | (file) |
Thank you Flame, not lame (talk) 00:14, 2 September 2024 (UTC)
- We do have a page about that actually: Appendix:Gen Z slang and there is a relevant discussion about deleting it which discusses some of the issues you mention. —Justin (koavf)❤T☮C☺M☯ 00:29, 2 September 2024 (UTC)
- I'll keep these question in Beer Parlour for one 'tis popularer, and the page you linked is not likely to get noticed. Flame, not lame (talk) 00:44, 2 September 2024 (UTC)
- Okay, so attestation requirements are the same for Gen Z slang as they are for any other words, so citing Wikipedia itself is not sufficient. Unfortunately, the nature of youth slang makes it so that you're less liable to find durable citations, but the good news is that requirements for what can be in the appendix namespace are much more lax (and not really codified), so if you wanted to add content there, it would be appreciated. —Justin (koavf)❤T☮C☺M☯ 00:56, 2 September 2024 (UTC)
- I'll keep these question in Beer Parlour for one 'tis popularer, and the page you linked is not likely to get noticed. Flame, not lame (talk) 00:44, 2 September 2024 (UTC)
(ab)use and other unusual portmanteau-like terms
[edit]In my recent research into various potential sources/concordances, I have stumbled across a class of terms as best I can understand do not have a linguistic term for(or at least those I have brought this up to about have also failed to recall one), and for which to my understanding we currently only have one, albeit partial in my opinion, example being (s)he, the terms being as followed:
- (ab)use - abuse + use
- (ab)using - abusing + using
- (mis)adventures - misadventures + adventures
- (mis)fortune - misfortune + fortune
- (un)holy - unholy + holy
- (un)lucky - unlucky + lucky
- (un)fortunate - unfortunate + fortunate
- (un)fortunately - unfortunately + fortunately
- (in)famous - infamous + famous
What is unusual about these is unlike a traditional portmanteau, these aren't blending meanings to form a new meaning, and basically are reliant on their on the sum of their parts. None of these terms can not be "synonymize" like (s)he can be(the singular they), of which I found two other examples of such:
These are also notable because unlike the above, these are not simple bracketing of a prefix.
I will also note two examples other examples of technically attestable terms I found of the same class but am unsure of the actual acceptance of said attestments but that is outside the scope of the topic I'm broaching here:
- (g)old - gold + old (I understand this as coming from the phrase "old but gold", probably "synomizeable" as under adj sense 2 of vintage )
- (nick)name - nickname + name (even with quote context the exact nature of the use of this eludes me)
currently I haven't been able to find any examples of such but I suspect that this kind of term isn't exclusive of prefixing, give the following hypothetical term as an example of what it could be like:
Basically I bring all this up because I'm unsure on if these are actually something that we "can" document, and more so how exactly we would go about actually documenting them, because describing them as just another blend/portmanteau seems inapt, as well as how one would go about actually defining these. Akaibu (talk) 03:54, 2 September 2024 (UTC)
- My understanding is that (mis)fortune, for example, could be defined as "fortune or misfortune, depending on one's perspective". — excarnateSojourner (ta·co) 04:24, 2 September 2024 (UTC)
- I'm not aware of a specific term for this either. A juxtaposition of perspectives, like the one that excarnateSojourner describes, occurs when the bracketed element is a negative or pejorative suffix. The result is often a bit cheeky; cf. (in)famous, (mis)adventures. Nicodene (talk) 04:53, 2 September 2024 (UTC)
- A juxtaposition of perspectives, again, isn't a requirement, as (wo)man shows, unless you go by the binary definition of gender which, yea lmao. It certainly seems like the most common though. Akaibu (talk) 05:51, 2 September 2024 (UTC)
- As I said: “when the bracketed element is a negative or pejorative suffix”. Nicodene (talk) 06:05, 2 September 2024 (UTC)
- A juxtaposition of perspectives, again, isn't a requirement, as (wo)man shows, unless you go by the binary definition of gender which, yea lmao. It certainly seems like the most common though. Akaibu (talk) 05:51, 2 September 2024 (UTC)
- I have also seen slashes used, as in dis/like, mis/fortune, and we do also have s/he and Latino/a. My initial reaction is that I'm not sure it makes sense to include just any term in this class, though, like (mis)fortune, mis/fortune, (wo)man, or e.g. person(s), which all seem relatively SOP—maybe we want to only include ones where the meaning is not obvious (maybe (g)old?) or where there are THUB translations? I don't know... I'm aware we include unspaced, unpunctuated single words regardless of whether they're SOP, but when punctuation clearly tells the reader what the 'parts' are that they need to look up, it seems like we take that into account, since we don't have e.g. North/South: we seem to rely on someone who sees North/South Dakota to know to fill in the missing part and look up North Dakota and South Dakota separately, and on the face of it, it seems like we could similarly rely on someone who sees mis/fortune or (mis)fortune or misfortune(s) to look up misfortune and fortune and misfortunes separately...? - -sche (discuss) 06:56, 2 September 2024 (UTC)
- @-sche I would say they aren't SOP because their use implies simultaneously meanings to an object, while your example of North/South Dakota is different because that would be a single term referring to multiple things you wouldn't expect someone to say "New York (City)", because that's that city and the state, where as with (mis)fortune and such, your only talking about one thing(someone's fortune or misfortune). Akaibu (talk) 16:40, 4 September 2024 (UTC)
- Re slashes: we also have wo/man, a form of the mentioned (wo)man. J3133 (talk) 16:55, 4 September 2024 (UTC)
- I suggest we call them parenthenyms. Denazz (talk) 22:11, 6 September 2024 (UTC)
Request for Old Parthian/Proto-Parthian
[edit]I would like to request for the creation of templates, modules and codes to enable supporting Old Parthian/Proto-Parthian on Wiktionary. Is this feasible? (Also, pinging @Victar here because they might have useful insights regarding this) Antiquistik (talk) 08:37, 2 September 2024 (UTC)
- To what ever end? --
{{victar|talk}}
05:09, 3 September 2024 (UTC)- @Victar To add the earlier (Old Iranian) forms of certain attested Parthian (Middle Iranian) lemmas. For example, if I were to create a page for Friyapat in Parthian, I would like to accompany it with an entry on the reconstructed older form, *Friyapatiš in Old/Proto-Parthian, where I can further explain its etymology.
- Besides, even on present Parthian entries, the only option now available is to have the terms' further etymologies be labelled as "Old Iranian," which is very flawed when the pre-Middle Iranian forms of these terms can be reconstructed.
- I did leave a message regarding this on your talk page, but it seems you might have missed it. Antiquistik (talk) 06:09, 3 September 2024 (UTC)
- I've been away for a few weeks.
- I would write the etymology of Parthian 𐭐𐭓𐭉𐭐𐭕 (prypt /Friyapāt/) as, "From earlier *Friyapatiš, whence Achaemenid Elamite [script needed] (pír-ri-ia-bat-ti-iš), Ancient Greek Φριαπίτης (Phriapítēs), from Proto-Iranian *FriHyápatiš, from Proto-Indo-Iranian *PriHyápatiš, from *priHyás (“beloved”) + *pátiš (“master”). Cognate with Sanskrit प्रियपति (priyápati)." --
{{victar|talk}}
19:09, 3 September 2024 (UTC)- @Victar Isn't this alternative a tad cumbersome though? And should I use the code for Parthian itself for the earlier form? Antiquistik (talk) 02:48, 4 September 2024 (UTC)
- Honestly, no more cumbersome than the next. --
{{victar|talk}}
07:55, 4 September 2024 (UTC)- @Victar And do I use the code for Parthian itself? Or does Wiktionary have a code for unlabelled languages similar to Wikipedia's
mis
? Antiquistik (talk) 08:38, 4 September 2024 (UTC) - The only reason for giving an earlier form to Parthian terms is if borrowings points to a more archaic form, like with 𐭐𐭓𐭉𐭐𐭕 (prypt /Friyapāt/). Otherwise, the inherited form should be Proto-Iranian. --
{{victar|talk}}
07:12, 12 September 2024 (UTC)
- @Victar And do I use the code for Parthian itself? Or does Wiktionary have a code for unlabelled languages similar to Wikipedia's
- Honestly, no more cumbersome than the next. --
- @Victar Isn't this alternative a tad cumbersome though? And should I use the code for Parthian itself for the earlier form? Antiquistik (talk) 02:48, 4 September 2024 (UTC)
Announcing the Universal Code of Conduct Coordinating Committee
[edit]- Original message at wikimedia-l. You can find this message translated into additional languages on Meta-wiki. Please help translate to your language
Hello all,
The scrutineers have finished reviewing the vote and the Elections Committee have certified the results for the Universal Code of Conduct Coordinating Committee (U4C) special election.
I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:
- North America (USA and Canada)
- Ajraddatz
The following seats were not filled during this special election:
- Latin America and Caribbean
- Central and East Europe (CEE)
- Sub-Saharan Africa
- South Asia
- The four remaining Community-At-Large seats
Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.
Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. You can follow their work on Meta-Wiki.
On behalf of the U4C and the Elections Committee,
RamzyM (WMF) 14:07, 2 September 2024 (UTC)
Have your say: Vote for the 2024 Board of Trustees!
[edit]Hello all,
The voting period for the 2024 Board of Trustees election is now open. There are twelve (12) candidates running for four (4) seats on the Board.
Learn more about the candidates by reading their statements and their answers to community questions.
When you are ready, go to the SecurePoll voting page to vote. The vote is open from September 3rd at 00:00 UTC to September 17th at 23:59 UTC.
To check your voter eligibility, please visit the voter eligibility page.
Best regards,
The Elections Committee and Board Selection Working Group
MediaWiki message delivery (talk) 12:15, 3 September 2024 (UTC)
tautological definitions
[edit]The following subscript letters are "defined" simply as subscript letters, with no other content. For example, U+2093 LATIN SUBSCRIPT SMALL LETTER X (ₓ) is defined only as "subscript x".
Graphical descriptions are not definitions. I added an actual definition to ₒ, but the rest IMO should be deleted, unless someone wants to go through and add some content. They are:
kwami (talk) 13:55, 3 September 2024 (UTC)
- Delete all that lack real definitions. I think this would fit better at WT:RFDN. — excarnateSojourner (ta·co) 20:53, 4 September 2024 (UTC)
Should we remove automated "more X" and "most X" from headers of English adjectives?
[edit]I'm here per the suggestion of user:Theknightwho.
There are many adjectives where we use the header {{en-adj|-}} because we haven't attested to comparative forms, and that creates the note "not comparable". But almost all of these are comparable, especially in poetry. This came up for Iapetian, where it's easy to see how it might be comparable even if there are no hits at GBooks. That took me to Japhetic, which we also claimed was not comparable, but where I found several instances of "more Japhetic" on GBooks ("some Japhetides are clearly more Japhetic than others"; "beyond the more Japhetic order of minstrelsy"), and possibly one of "most" (no preview on that one).
As Theknightwho pointed out, there are probably very few cases where an English adjective is truly not comparable, because combining an adjective with "more" and "most" is extremely productive -- it's not like countability, where some nouns truly aren't countable. I agree with Theknightwho that we probably shouldn't automatically list these forms: they don't add any information that "adjective" doesn't already. We wouldn't want to claim they exist if we can't attest to them (something like "most Iapetian" may have never been used in the history of English), yet we shouldn't make a positive claim that they can't exist either, unless we have a source to back up that claim.
For inflected comparatives (nicer, nicest), we'd want to continue to provide them in the header of course. But those are generally easy to attest.
In the few cases where that's inadequate, we can always expand on the header template, like we do at fun#Adjective, or add usage notes. kwami (talk) 01:07, 4 September 2024 (UTC)
- It sounds like the problem is not the more/most forms, but the text generated when someone suppresses them via
{{en-adj|-}}
. It sounds like what would solve the issue is to either add a ! parameter (like{{en-noun|!}}
has) to{{en-adj}}
, or just change the wording of{{en-adj|-}}
itself to say the forms are not attested rather than that they don't exist. It doesn't seem like removing the mention of more/most forms, when they're attested, would improve anything; indeed, IMO it would make things a bit worse, because if some entries list comparative/superlative forms (as entries like nice and ugly will need to, as you say), then not listing comparatives on other entries suggests they don't grade/inflect. (Granted, we could retain some mention like "inflects the usual way", but what's the usual way? Might as well go ahead and spell out "inflects using more/most"... and then we might as well just keep listing the forms, we're not short on ink.)
We have the same problem with{{en-noun}}
: most or all entries that currently use{{en-noun|-}}
should properly use{{en-noun|!}}
, because just like with the adjectives you mention, the issue is that the inflected forms aren't thrice-attested, not that they positively cannot exist. Comparing today's X to last century's, or this universe's X to a hypothetical mirror universe's, I can discuss how the Xs [plural] differ even if X is one of the nouns we claim are uncountable. Our whack-a-mole / cite-a-mole approach means we list e.g. "engagingness" as uncountable even though there are two cites of it. - -sche (discuss) 06:32, 4 September 2024 (UTC)- There is a distinct grammatical class (POS) of mass nouns, such as water and bread, that are uncountable with their default definition. (You can say at a restaurant "we'll have 2 waters", or "all the waters of the Earth", but those are distinct definitions and can be listed separately.)
- There is nothing comparable with adjectives. Whether they inflect is a matter of word length and lexicalization, not being a distinct POS. They're more like strong vs weak verbs.
- We can already suppress the comment with {{en-adj|?}} or {{head|en|adj}}; the problem is that those get converted to {{en-adj|-}} (as happened to Iapetian) and then make the claim that a comparative form does not exist.
- Unlike nouns and verbs in their inflections, all adjectives can form comparative phrases with 'more' and 'most', unless those would be redundant with existing inflected forms that we already mention. We don't mention which nouns can be pluralized with "some" (some water, some bread), or which verbs can be made past with did, so I don't see how not mentioning comparative forms with more, most is a problem. And do we even want to bother attesting them? But I agree that it would be better to say that such phrasing is not attested than to claim it cannot be. kwami (talk) 18:17, 4 September 2024 (UTC)
- I have taken to using {{en-adj|?}} recently, where I'm not sure. DonnanZ (talk) 17:37, 8 September 2024 (UTC)
At the risk of discussion creep, I feel like this is a persistent problem with virtually any instances where you have no information displayed or stored which is that it's not clear if there is no such value or if the value is just kind of obvious and what you'd intuit. To use a somewhat similar example, on d: if someone has no death date listed, that could be because he's not dead or it could be because we simply haven't added it to the database yet. Putting a death date of "no value" at least explicitly says "no death date applies here: he's still alive". I feel the same way here, where I as a native English speaker would probably not think that "Japhetianer" or "Japhetianest" are words and it's probably more likely that "more/most Japhetian" is the correct way to say this, have a few extra words in the entry that says "the more/most form is the correct one" really causes no harm and clarifies what could be confusing or an omission. So I think we should retain "more/most" in headings. —Justin (koavf)❤T☮C☺M☯ 18:49, 8 September 2024 (UTC)Actually, let me think this thru more... I'll retain this if anyone finds the direction I was headed meaningful. —Justin (koavf)❤T☮C☺M☯ 18:50, 8 September 2024 (UTC)- For me, redundant info is not the problem, or at least not important enough to worry about. It's our positive claim that the more/most forms don't exist that's the issue. I've also used DonnanZ's {en-adj|?} solution, or else {head|en|adj}, but people go through and change them all to {en-adj|-} even after I explain to them what I've done, because a search of GBooks does not come up with any tokens of the more/most forms. If GBooks doesn't have them, that's taken as proof that they do not exist and, more importantly, cannot exist. In their opinion, the solution is to change the wording produced by {en-adj|-}, and in the mean time they'll continue to make false claims on Wk. kwami (talk) 20:25, 8 September 2024 (UTC)
Hello,
I recently created a Wiktionary page for the neologism "ambonym." The term was coined in Human1011's YouTube video. [1] Etymology Nerd also covered this topic. How do I attest this new word? Perhaps I can use better word choices in the etymology and definition.
Thank you Flame, not lame (talk) 01:18, 4 September 2024 (UTC)
- I would say look it up in Google Books and Internet Archive, see if you find any work that uses the term. CitationsFreak (talk) 05:53, 4 September 2024 (UTC)
- I don't think the term meets our CFI. The only durably archived mention I find is a coinage of the same term but with a different meaning. And it doesn't appear widespread in online sources. Einstein2 (talk) 15:57, 4 September 2024 (UTC)
- I haven't thought too hard about it yet, but my initial thought is that any contranym can meet the definition of Human1011's proposed word. Am I wrong? Quercus solaris (talk) 21:33, 4 September 2024 (UTC)
- Not all contranyms are ambonyms, and Etymology Nerd did a pedantic essay on ambonyms, so let's go with Human1011's new word because he is a smart young man. Flame, not lame (talk) 21:35, 4 September 2024 (UTC)
- I just realized that yes, the ambonymy concept is about the relation of the contranym to others, not just about the contranymy alone. Quercus solaris (talk) 21:41, 4 September 2024 (UTC)
- If other people use it, then we can list it. We don't have a "smart young man" clause. CitationsFreak (talk) 23:32, 4 September 2024 (UTC)
- Not all contranyms are ambonyms, and Etymology Nerd did a pedantic essay on ambonyms, so let's go with Human1011's new word because he is a smart young man. Flame, not lame (talk) 21:35, 4 September 2024 (UTC)
- I haven't thought too hard about it yet, but my initial thought is that any contranym can meet the definition of Human1011's proposed word. Am I wrong? Quercus solaris (talk) 21:33, 4 September 2024 (UTC)
- I don't think the term meets our CFI. The only durably archived mention I find is a coinage of the same term but with a different meaning. And it doesn't appear widespread in online sources. Einstein2 (talk) 15:57, 4 September 2024 (UTC)
Arabic voiceless velar fricative notation
[edit]The Arabic voiceless velar fricative (خ) is currently rendered as ḵ on Wiktionary. I would however argue that, since this diacritic form is already used for begadkefat notation in Hebrew and Aramaic, the organic and non-begadkefat Arabic خ should instead be rendered using ḫ, just like how this phoneme is rendered for other Semitic languages like Old North Arabian, Old South Arabian and Akkadian, and for the non-Semitic but still Afroasiatic Ancient Egyptian language. Antiquistik (talk) 10:28, 4 September 2024 (UTC)
- @Antiquistik I oppose this. ḫ is too confusable with ḥ, the pharyngeal fricative. Benwing2 (talk) 03:37, 5 September 2024 (UTC)
- @Benwing2 We already use both ḫ and ḥ for, respectively, the velar and pharyngeal fricatives, for Old North Arabian, Old South Arabian and Ancient Egyptian without this causing issues so far, don't we? Antiquistik (talk) 06:52, 5 September 2024 (UTC)
- Oppose, consistently using an underline for fricatives is much more understandable. ḵ is the fricative equivalent of k, ḡ of g, ṯ of t and ḏ of d. Using diacritics in a consistent manner is preferable IMO and randomly using ḫ would be much less clear. — BABR・talk 01:39, 6 September 2024 (UTC)
- Agree, and I'll add that @Antiquistik's concern with "organic" vs. "begadkefat" variants across different languages runs into the same problem with ḡ, ṯ and ḏ, yet we aren't proposing replacing every one of those with some other random symbol. Benwing2 (talk) 04:43, 6 September 2024 (UTC)
- @Babr @Benwing2 I am sorry, but saying that I am proposing replacing ḵ with a random symbol comes across as disingenuous when ḫ is already the notation for the velar fricative in the standard Romanisation schemes for several Semitic languages like Old North Arabian, Old South Arabian, Akkadian, and it is also used as such in some Romanisation schemes for Arabic.
- In fact, in my opinion, the DIN 31635 scheme, which notes the velar fricative as ḫ, is among the better transliteration schemes for Arabic. It's a German transliteration scheme, so I doubt English Wiktionary would adopt it wholesale, but it is used widely enough in English literature on Arabic that I think we should consider it.
- Though I must note that the argument with regards to organic vs begadkefat was proposed by @Fay Freak in a previous discussion Wiktionary:Beer parlour/2024/May#Arabic and Hebrew transliteration
- I have no problem with disagreements with or opposition to my proposal per se, but it is not a random choice. Antiquistik (talk) 07:31, 6 September 2024 (UTC)
- @Antiquistik I did not say it was a random symbol, I meant it's usage would be random since it wouldn't match our otherwise consistent pattern for marking fricatives. I think using diacritics in simple and consistent manner is desirable as it makes transliterations more easily understood by readers. — BABR・talk 18:01, 6 September 2024 (UTC)
- @Babr That's fair. I suppose I should have argued for switching to the DIN 31635 transliteration scheme altogether, especially given that I think its other letters provide better consistency with the Wiktionary notations of languages with heavy loaning from Arabic, like the various registers of Hindustani. Antiquistik (talk) 12:34, 10 September 2024 (UTC)
- @Antiquistik I did not say it was a random symbol, I meant it's usage would be random since it wouldn't match our otherwise consistent pattern for marking fricatives. I think using diacritics in simple and consistent manner is desirable as it makes transliterations more easily understood by readers. — BABR・talk 18:01, 6 September 2024 (UTC)
- Agree, and I'll add that @Antiquistik's concern with "organic" vs. "begadkefat" variants across different languages runs into the same problem with ḡ, ṯ and ḏ, yet we aren't proposing replacing every one of those with some other random symbol. Benwing2 (talk) 04:43, 6 September 2024 (UTC)
- Oppose. — Fenakhay (حيطي · مساهماتي) 07:42, 6 September 2024 (UTC)
- I have no strong feelings for either scheme, but there are lots of casual readers and in particular native speakers without experience in Semitist tradition that do not participate in discussions but might be snubbed by ḫ. For now we at least have the advantage of there only being one diacritic variant of k and h each, ḵ and ḥ, which is as Benwing2 implies optically though not comparatively advantageous, and last but not least status quo bias and complete correspondence with the English edition of the Hans Wehr transliteration, only its rings made larger. Your, albeit excellent, centre of gravity in language comparison begs us here to “cause issues”, I am sorry. Fay Freak (talk) 16:20, 6 September 2024 (UTC)
What should I do
[edit]What should I do if my edits are reverted?
I left a message on PUC talk page.
I didn't get a response.
I left a message here.
I didn't get a response. ПростаРечь (talk) 18:30, 4 September 2024 (UTC)
- @ПростаРечь I don't know that I can give you a full answer as I don't work in the reconstruction namespace myself, but Wiktionary generally doesn't use manually-added interwiki links, because the title of an entry in the English Wiktionary will be the same as the title of the corresponding entry on any other Wiktionary. I do see that the Russian Wiktionary does not seem to have a dedicated namespace for reconstructed terms as we do here, but the way to solve this problem (if we see it as a problem at all) would probably be to change something at Wikidata, rather than manually adding interwiki links between all reconstructed terms in all Wiktionaries. — excarnateSojourner (ta·co) 21:31, 4 September 2024 (UTC)
Recategorizing quotation navigation templates by bot
[edit]We have a collection of templates such as {{Douglas Adams quotation templates}}
that are used on the documentation pages of quotation templates (such as Template:RQ:Adams Hitchhiker/documentation) to list other quotation templates for works by the same author. Currently these are categorized in cat:Navigation templates (and e.g. cat:English quotation templates), but they are shoved to the front by their sort keys rather than being listed under each letter.
I'm seeking consensus to create cat:Quotation template navigation templates (or cat:Quotation navigation templates if people prefer) as a subcategory of cat:Navigation templates, and use my bot account to recategorize these templates there. — excarnateSojourner (ta·co) 00:11, 5 September 2024 (UTC)
- Support This, that and the other (talk) 10:11, 5 September 2024 (UTC)
- No objection: perhaps the name should be "Category:English quotation navigation templates" which can then be a child category of both "Category:English quotation templates" and "Category:Navigation templates". Some of our quotation navigation templates are multilingual (for example,
{{Bible quotation templates}}
and{{Don Quixote quotation templates}}
), in which case they should also be child categories of "Category:French quotation navigation templates", "Category:Spanish quotation navigation templates", and so on. — Sgconlaw (talk) 12:15, 5 September 2024 (UTC)- Done: I've implemented Sgconlaw's suggestion. — excarnateSojourner (ta·co) 03:44, 15 September 2024 (UTC)
Request for extended mover right
[edit]I plan on enforcing the changes to the Ottoman Turkish encoding guidelines which were formalised into WT:AOTA (see disc) but never really put into practice. For doing so I would need to move and merge about ~300 ca. entries, and since I would rather not leave unwanted redirects behind, nor flood CAT:D for someone else to tediously go through, I request the extended mover right as to save both myself and others the hassle. Catonif (talk) 15:53, 5 September 2024 (UTC)
- Granted. More than trusted user. Vininn126 (talk) 16:38, 5 September 2024 (UTC)
- @Vininn126 Thank you! Catonif (talk) 17:02, 5 September 2024 (UTC)
Request for autopatroller rights
[edit]I wish to request autopatrolling rights as I plan on editing certain pages following my collaboration with GLAAD that are fully protected. I already have autopatroller rights on Commons and edit in good faith and good contributions, only with minor mistakes as I am still not a total expert on everything. Juwan (talk) 22:04, 6 September 2024 (UTC)
- I'm inclined to say yes, but I have a few thoughts. You are a cooperative editor and fast to learn, and your experience on Wikipedia has definitely helped you in learning the ropes. I'm hesitant, as I think there are still some fairly common ins and outs of the site you're not familiar with yet, and your edit count is just on the edge for many users (not that edit count is everything, but I feel in this particular case it's a useful metric). If no other admins have any qualms, then I think it's probably in order. I'd like to see what others say. Vininn126 (talk) 22:07, 6 September 2024 (UTC)
- if you have anything specific that you think that I should learn, please go ahead and mention it in my talk page on or the Discord server, not even for this particular request but in general I want to know! Juwan (talk) 22:14, 6 September 2024 (UTC)
- @JnpoJuwan IMO these terms need to be approached with a lot of care. I agree with @Vininn126 that it might make sense to make a list of the changes you propose and post this in the Tea Room. FWIW I am not an expert in these sorts of terms; I think User:-sche knows more. Benwing2 (talk) 03:19, 7 September 2024 (UTC)
- thanks for the advice! I will go ahead and do that. Juwan (talk) 13:11, 7 September 2024 (UTC)
- @JnpoJuwan IMO these terms need to be approached with a lot of care. I agree with @Vininn126 that it might make sense to make a list of the changes you propose and post this in the Tea Room. FWIW I am not an expert in these sorts of terms; I think User:-sche knows more. Benwing2 (talk) 03:19, 7 September 2024 (UTC)
- if you have anything specific that you think that I should learn, please go ahead and mention it in my talk page on or the Discord server, not even for this particular request but in general I want to know! Juwan (talk) 22:14, 6 September 2024 (UTC)
Reference bibliographies
[edit]Is there any central or per-language bibliography in Wiktionary?
The references and particularly ref templates make a treasure of sources on etymology, usage and other linguistic matters. BUt one usually encounters them under the random heading in this or that article. Is there a section of Wiktionary where you can find them grouped? In the language top categories I saw some "Category:<lang xx> reference templates". But untranscluded, they are completely opaque, and there is no telling the grand etymological dictionary from the note about a single word, the old from the new.
What I'm looking for (or propose) is more like Appendix:Bulgarian bibliography, that lists the major recuring sources, and possibly more works, by topic. Danny lost (talk) 22:04, 6 September 2024 (UTC)
- The category you mentioned is usually better. As far as transparency, this depends template to template, and if someone has written a documentation or not. It's also usually important to read the forward of the given dictionary and any reviews, which is often not given. So the answer is no, there usually is not a grand explanation of each source, unfortunately. Sometimes more details are provided on pages such as WT:About Bulgarian but not always. Vininn126 (talk) 22:09, 6 September 2024 (UTC)
- Actually what I asked for is found at Wiktionary:Reference templates / Wiktionary:REFT. Though it is a bit of a random selection at the moment. Danny lost (talk) 20:41, 9 September 2024 (UTC)
East Frisian
[edit]Anybody could know what code we could use for East Frisian dialects that are not Saterlandic? Like Upgant, Wangerooge, Harlingerland, and Wursten? That Northern Irish Historian (talk) 00:38, 7 September 2024 (UTC)
- It's been a while, but if memory serves, ISO messed things up by using East Frisian for a Low Saxon lect and leaving Saterland Frisian as the only linguistically Frisian eastern lect with a code. We made do by making all the Frisian East Frisian lects part of Saterland Frisian's code. Pinging @-sche who was more directly involved and @Theknightwho who might know more about the current state of the codes. I don't think anyone was happy with the way we left it back then, so it wouldn't hurt to revisit the whole mess. Chuck Entz (talk) 02:03, 7 September 2024 (UTC)
- So that means using stq for these dialects? That Northern Irish Historian (talk) 15:24, 8 September 2024 (UTC)
"the act of being"
[edit]There are 91 hits (enwikt entries), mostly in definitions, for this grammatically correct but IMHO semantically odd expression. Be is the ultimate stative verb, contrasting with a dynamic verb, which describes an action. "The act of being" makes for a good phrase for a poetic, spiritual, or motivational bit of writing or speech, but it seems completely out of place for definitions.
One simple change that might work for many of these definitions is to drop "The act of" and leave "Being". Another is to replace "act" with "condition" or "state" or, imitating other dictionaries, replace "act" with "condition, state, or quality" or similar.
Am I missing something? If I am not, this seems to show that we need to up our game to improve Wiktionary's most basic product, its definitions. I don't know what means there are might be to prevent or cure such inappropriate expressions in definitions. Prevention may be hopeless because almost all newbies and some no-so-new-bies are convinced that it is trivial to write a definition. ("Style guide? Style guide! We don't need no stinking style guide.") Perhaps the alternative is to record common phrases that are almost always wrong for a dictionary definition, scan the dictionary periodically for such expressions, and correct them. The correction could be simple (automatic or semiautomatic) replacement of the offending expression, but probably more extensive rewording would be better. DCDuring (talk) 02:57, 7 September 2024 (UTC)
- In most cases, "being" in this context is being used not as a stative verb, but as an auxiliary. E.g. "being dethroned" is not necessarily stative: it can refer to an action.--Urszag (talk) 03:09, 7 September 2024 (UTC)
- The OED, based on my quick look at it (specifically, "dis-...-ment" words), uses the wording "The act of ___ing, the fact of being ____ed." I think leaving off "The act of" could work. I don't think it's sufficient to replace "act" with "condition", "state", or "condition", as Urszag points out. "His dismemberment was swiftly accomplished" refers to an action of dismembering, of which the subject is the passive recipient. It is not a state or condition of being dismembered (though the definitions worded with "act" fail to capture the possibility of the word being used that way). That being said, note the way we actually do handle this at dismemberment with two definitions, by contrast with, say, "disenthronement," which uses "The act of being". Andrew Sheedy (talk) 03:12, 7 September 2024 (UTC)
- Nothing wrong with "the act of being" in our definitions, DCDuring. Denazz (talk) 16:01, 7 September 2024 (UTC)
Maybe a better way of looking at this is to divide the instances of "the act of being" into two categories:
- those of the form "act of being [ADJ]" in which be is a copula.
- those of the form "act of [present progressive passive verb] (=being [PAST PART.])" in which be is an auxiliary.
I don't think there are many other cases to distinguish.
I believe that all of the instances with be as a copula are simply wrong, as the English copula is stative.
The other case is one of the awkward and unjustified use of act when the purported actor/agent is actually a patient. DCDuring (talk) 21:39, 7 September 2024 (UTC)
- Icelandic útúrsnúningur (“the act of being intentionally obtuse”) and Hungarian foglalkozás (“the act of being occupied with something”) are both fine, I think. The former despite seeming to be a copulative phrase, the latter despite seeming to be a passive progressive phrase. In actual fact they're both durative non-passive actions and the word act positively contributes to the definition. On the other hand the definition of Swedish umgänge (“the act of being with people”) is indeed better off rephrased. It's a case-by-case question. —Caoimhin ceallach (talk) 19:37, 8 September 2024 (UTC)
- Not only does the English seem to be a copulative phrase, it is a copulative phrase. Being intentionally obtuse is not a "durative non-passive action" because it is not an action. If the word were defined as "pretending or intending to be obtuse" or "acting obtuse" that would be different. I am not too surprised that the problem has to be remedied on a case by case basis. As I siad above: "The correction could be simple (automatic or semiautomatic) replacement of the offending expression, but probably more extensive rewording would be better". DCDuring (talk) 20:05, 8 September 2024 (UTC)
- What I meant was that the words I quoted denote durative non-passive action. If they are most clearly glossed by "act of being [ADJ]" or "act of being [PAST PART.]," I don't see that as a big issue. "Act of pretending/intending to be obtuse" would be inaccurate and "act of acting obtuse" is tautological. —Caoimhin ceallach (talk) 21:24, 8 September 2024 (UTC)
- What I am saying is that "act of being" never belongs in a definition because be is always either a copula or an auxiliary with an -ed-form making a passive verb. The predicate with a copula is never an act, in any normal sense of the word act (See act#Noun.). When being is a component of a passive, the subject of the passive is not an agent, but rather a patient. Patients do not act in any normal sense of the word act. Looking at occurrences of "the act of being" in Google Books should be sufficient indication that the expression is not normal English. It occurs principally in works of metaphysics. DCDuring (talk) 01:39, 9 September 2024 (UTC)
- My take is that it's a way to emphasize the verb POS, since an act has to involve a verb. A number of non-European languages use stative verbs where we use adjectives- we have a relatively small number (look, seem, sound, smell, to name a few), but those aren't what we think of when verbs are mentioned. Likewise, English has lost its passive morphology, and instead uses constructions made of forms already in use for other purposes. Saying "the act of being" makes it clear that action is referred to, even if it's being done by someone or something else. Of course, both are at the expense of not making literal sense, but their practitioners aren't paying attention to that aspect. Chuck Entz (talk) 03:44, 9 September 2024 (UTC)
- So we can use an expression commonly used in English only in metaphysics, theology, and spiritualism in our English definitions and glosses? DCDuring (talk) 11:34, 9 September 2024 (UTC)
- I get your argument. I get that being per se isn't an act, nor is being tired, or being eaten alive. But being intentionally obtuse is, and being occupied with something is too, despite them being grammatically analogous to the former examples. I think the semantics of the constituent parts is more important than the formal properties of the word being. If we're talking about formal logic you may have an argument, but this is a dictionary and clarity is all that matters. —Caoimhin ceallach (talk) 12:35, 9 September 2024 (UTC)
- If I thought that the "act of being" definitions were clear, I wouldn't have bothered introducing this topic. I think "act" allows for what ever modest active role a patient may have, but at the expense of muddying the basic definition.
- I'm not in the slightest concerned about formal logic and didn't use it. I am concerned about not confusing ordinary folks who might see our definitions, not just on our site, but also via Google Search and entities like OneLook.com (which give us a very favored treatment), but don't have hyperlinks, hovertext, etc. to explain things and cover over some of the inadequacies of our definitions.
- Andrew Sheedy noted that, given the need to define terms of the form dis-...-ment, the OED uses the wording "The act of ...ing, the fact of being ...ed." I don't think we should be too proud to learn from and follow their example. I don't recall ever seeing the wording "the act of being" used in any dictionary's definitions.
- In the case of Icelandic útúrsnúningur (“the act of being intentionally obtuse”), I propose "intentional obtuseness", "pretending to be obtuse", "feigning obtudeness". "Intentional", "pretending", and "feigning" all convey an active role for the intender, pretender, or feigner.
- For Hungarian foglalkozás (“the act of being occupied with something”), all the meanings of the verb Hungarian foglalkozik are active and are so worded, excepting "be engaged in", one of the synonym cloud to glosses of definition 4, which could easily be worded as "engage in". Hungarian -as seems to function much as English -ing. Normally we don't reword all the definitions of the verb at each form of the verb or each term derived from the verb, unless there are new meanings or, perhaps, restrictions of meanings. Leaving the definition of Hungarian foglalkozás as "verbal noun of foglalkozik" without the sense-obscuring gloss seems preferable to the current state. DCDuring (talk) 23:09, 9 September 2024 (UTC)
- I concede that some of your suggestions might work better than what we currently have. The problem however with English -ing (verbal noun) is that it is homonymous with the present participle. That's an ambiguity which I presume the admittedly not-so-beautiful "the act of"-formulation is intended to avoid. Alternatively we could choose a formulation like "the feigning of obtuseness" or "the engaging in an activity" for verbal nouns, but I'm not sure if this is better. Leaving out a gloss altogether seems even worse to me because not everyone has a perfect intuition for what a verbal noun is.
- Perhaps you can make the case better for why ordinary folks might be confused by definitions like "act of being [ADJ]/[PAST PART.]" in cases where the phrase "being [ADJ]/[PAST PART.] clearly denotes an agentive activity, because I'm still not entirely convinced. —Caoimhin ceallach (talk) 00:06, 10 September 2024 (UTC)
- My take is that it's a way to emphasize the verb POS, since an act has to involve a verb. A number of non-European languages use stative verbs where we use adjectives- we have a relatively small number (look, seem, sound, smell, to name a few), but those aren't what we think of when verbs are mentioned. Likewise, English has lost its passive morphology, and instead uses constructions made of forms already in use for other purposes. Saying "the act of being" makes it clear that action is referred to, even if it's being done by someone or something else. Of course, both are at the expense of not making literal sense, but their practitioners aren't paying attention to that aspect. Chuck Entz (talk) 03:44, 9 September 2024 (UTC)
- What I am saying is that "act of being" never belongs in a definition because be is always either a copula or an auxiliary with an -ed-form making a passive verb. The predicate with a copula is never an act, in any normal sense of the word act (See act#Noun.). When being is a component of a passive, the subject of the passive is not an agent, but rather a patient. Patients do not act in any normal sense of the word act. Looking at occurrences of "the act of being" in Google Books should be sufficient indication that the expression is not normal English. It occurs principally in works of metaphysics. DCDuring (talk) 01:39, 9 September 2024 (UTC)
- What I meant was that the words I quoted denote durative non-passive action. If they are most clearly glossed by "act of being [ADJ]" or "act of being [PAST PART.]," I don't see that as a big issue. "Act of pretending/intending to be obtuse" would be inaccurate and "act of acting obtuse" is tautological. —Caoimhin ceallach (talk) 21:24, 8 September 2024 (UTC)
- Not only does the English seem to be a copulative phrase, it is a copulative phrase. Being intentionally obtuse is not a "durative non-passive action" because it is not an action. If the word were defined as "pretending or intending to be obtuse" or "acting obtuse" that would be different. I am not too surprised that the problem has to be remedied on a case by case basis. As I siad above: "The correction could be simple (automatic or semiautomatic) replacement of the offending expression, but probably more extensive rewording would be better". DCDuring (talk) 20:05, 8 September 2024 (UTC)
Korean determiner from of adjectives
[edit]For example "진정한," I couldn't find any determiner form of Korean adjectives terms on this dictionary. Should we create a term for them or we should make them redirect to, for example, 진정하다, or should we just not create page for them? If we're going to create a term for them, what should we write? 列维劳德 (talk) 00:33, 9 September 2024 (UTC)
- I see 좋은 is a redirect although it used to be an entry. Justin the Just (talk) 12:19, 9 September 2024 (UTC)
- Honestly, I'd keep them at redirects, but I'll CC the other Korean editors: (Notifying TAKASUGI Shinji, Atitarev, HappyMidnight, Tibidibi, Quadmix77, Kaepoong, The Editor's Apprentice, Saranamd): , @Solarkoid. AG202 (talk) 22:34, 10 September 2024 (UTC)
- @AG202 I'm not keen on having hard redirects for what are basically non-lemmas. Theknightwho (talk) 22:41, 10 September 2024 (UTC)
- @列维劳德: At some stage I created a few determiner forms but they were frowned upon. There are just too many forms, even determiners. It's best to focus on lemmas. It's a similar situation with Japanese verbs and adjectives. Anatoli T. (обсудить/вклад) 04:20, 11 September 2024 (UTC)
Links on Pinyin/Jyutping/etc. entries
[edit]These don't link to Chinese — for example, the first link on jan4 goes to 人#Cantonese instead of 人#Chinese. Are there any objections to me changing this? -saph668 (user—talk—contribs) 17:55, 9 September 2024 (UTC)
RQ for template editor
[edit]I've been working on adding support for dark mode with @Ioaxxere and there are many small templates that are locked that are unreadable in dark mode. I'm mainly creating a dark mode color palette using recommendations from MediaWiki, so far it's coming along great but some templates that need adjustments don't have any classes and can't be adjusted from my css page. — BABR・talk 22:16, 9 September 2024 (UTC)
- No objections from me. Benwing2 (talk) 04:08, 10 September 2024 (UTC)
- @Benwing2 No objections yet. Do you think ~29 hours is enough time or should we wait a bit longer? — BABR・talk 03:09, 11 September 2024 (UTC)
- Give it a day or two and if no one says anything I'll add you. Benwing2 (talk) 04:07, 11 September 2024 (UTC)
- @Benwing2, it's been about two days now, I think. — BABR・talk 20:05, 12 September 2024 (UTC)
- @Babr Thanks for reminding me, you are now a template editor! Benwing2 (talk) 20:08, 12 September 2024 (UTC)
- @Benwing2, it's been about two days now, I think. — BABR・talk 20:05, 12 September 2024 (UTC)
- Give it a day or two and if no one says anything I'll add you. Benwing2 (talk) 04:07, 11 September 2024 (UTC)
- @Benwing2 No objections yet. Do you think ~29 hours is enough time or should we wait a bit longer? — BABR・talk 03:09, 11 September 2024 (UTC)
About a new translation parameter for quote-book
[edit]For multiple different historical circumstances, it was pretty common for many Albanian books and periodicals to be printed with an Italian translation next to the Albanian text. These translations are very valuable because they were written by the authors themselves, which let us know more or less exactly what the authors meant for each word they wrote. For this reason I think they should not be omitted whenever these works are quoted, as we would be losing important context. Take for example akull (§ ety 2) where we are deducing the otherwise unattested dialectal meaning "arrow" only thanks to the Italian translation of the quote, which is however not presented in the entry, same thing for kacadre. For this reason, on the entries tipos and gëluhë I temporarily used the parameter |origtext=
which does exactly what I'm looking for, except for printing the text "original", which is not the case here as the original text is actually the Albanian one.
So I propose the creation of a parameter |transltext=
(and all other |transl...
etc.) to essentially work like |origtext=
but saying "translation". It's true this parameter name could look confusing at first, given we also have |transl=
and |text=
respectively, I can't think of a better one. Catonif (talk) 23:18, 9 September 2024 (UTC)
- @Catonif I'm thinking maybe instead of generalizing this slightly, so that there would be an
|alttext=
param (and maybe|alttext2=
, etc.) along with a param|altprefix=
or something to specify the prefix used for this text. Original text, normalized text, translations, etc. are all instances of "alternative" text that you might want to show, and supporting multiple types of alternative text would let you e.g. put renderings in multiple languages if it's important to do so. For a case where this might be useful, see the example in the{{quote-book}}
documentation of Italian text translated from a French translation of the Zhuang-zi. There's no current way of inserting all of the original Old Chinese text, the first-level French translation, the second-level Italian translation and the modern English rendering. Similarly sometimes people have found it important to include multiple renderings in English, e.g. a "poetic" translation and a literal translation; the poetic one could use|alttext=
. Pinging @Sgconlaw and @Vininn126 who may have thoughts about this. Benwing2 (talk) 03:15, 12 September 2024 (UTC)- BTW these parameters would actually be added to Module:usex so they are also available to
{{ux}}
,{{quote}}
and the like. Benwing2 (talk) 03:17, 12 September 2024 (UTC)- Hi @Benwing2, to me this sounds like a very sensible solution, you have my full support. Just to be clear, this wouldn't imply the removal of the
|norm=
parameter, right? Catonif (talk) 08:15, 12 September 2024 (UTC)- @Catonif Right, that param would remain. Benwing2 (talk) 08:24, 12 September 2024 (UTC)
- Hi @Benwing2, to me this sounds like a very sensible solution, you have my full support. Just to be clear, this wouldn't imply the removal of the
- This sounds fine to me. Vininn126 (talk) 09:20, 12 September 2024 (UTC)
- I like this. Especially
|alttextN=
. Thereby we do not need to conceive, or it is agnostic to, why an editor wants multiple texts. Otherwise it becomes intellectually challenging to distinguish the multiple formatting options, new version, old version, original version, translation text and so on. So stick with|text=
/|passage=
for the entry language’s quote and before- and after-texts the labelling of which the editor can choose, including for|t=
in the case that something is to be said about the translation. Fay Freak (talk) 01:14, 13 September 2024 (UTC)- It's useful to have an unambiguous and well defined interpretation for the standard parameters, such as
|text=
,|norm=
or|t=
. This makes quotations machine readable. At the same time, the potential great flexibility and freedom of|alttext=
makes it great for humans, but possibly difficult to parse for machines. --Ssvb (talk) 04:32, 13 September 2024 (UTC)
- It's useful to have an unambiguous and well defined interpretation for the standard parameters, such as
- @Benwing2: Will this new
|alttext=
model allow differentiating professional English translations from published books and the English translations provided by Wiktionary contributors? - For example, the Belarusian quotation from бачыць right now lists the English translation done by Mary Mintz in 1989 in the
|t=
parameter together with the|newversion=English translation from
parameter. But the|t=
parameter is normally supposed to be used for the translations authored by Wiktionary editors, right? --Ssvb (talk) 04:18, 13 September 2024 (UTC) - I like this, and think it would be useful to have in the language-specific usex templates, too, like
{{ja-usex}}
which sometimes include translations to multiple languages like on だはんで. Or, migrate the language-specific code from the language templates into Module:usex and use that everywhere. Pinging @Fish bowl who might have some good ideas about this. JeffDoozan (talk) 13:58, 14 September 2024 (UTC)
- BTW these parameters would actually be added to Module:usex so they are also available to
Hello,
How can we make a dictionary entry for zzxjoanw? I made a pronunciation audio yesterday, and it's said to be of Maori origin. It apparently means "drum" "file" or "conclusion". There is a Wikipedia page for it, and I put my voice on Wikipedia a moment ago. Can anybody attest to that?
Thank you Flame, not lame (talk) 00:34, 10 September 2024 (UTC)
- It's a known hoax. Besides which, Polynesian languages like Maori pretty much always end syllables with a vowel, nor do they have double consonants, and Maori doesn't use j, x, or z in native words. Chuck Entz (talk) 04:45, 10 September 2024 (UTC)
- @Chuck Entz: You don't generally get b, c, d, f, l, q, s, v and y in Maori either, though the place and lake Waihola (known for its black swans) springs to mind. I'm not sure if 'ng' and 'wh' (pronounced like an f) combined qualify as Maori letters. DonnanZ (talk) 11:20, 12 September 2024 (UTC)
- Maybe define "zzxjoanw" as an English word that is a fake Maori word. Flame, not lame (talk) 08:13, 10 September 2024 (UTC)
- @Flame, not lame: The pronunciation is at Appendix:English dictionary-only terms/zzxjoanw. J3133 (talk) 05:05, 10 September 2024 (UTC)
- Writing as an NZer, we don't need this. There shouldn't be an entry for Waikikamukau either, a fake Maori place name pronounced "why kick a moo cow". DonnanZ (talk) 10:54, 12 September 2024 (UTC)
- I can't believe it. "Don't talk to me." 💔 Flame, not lame (talk) 22:14, 12 September 2024 (UTC)
Letter articles without definitions, Latin Extended Additional block
[edit]Hi. Per request, I'm consolidating requested deletions here rather than posting 'rfd' multiple times. The following articles have no content, apart from the Unicode name being used in place of a definition. There is no indication of which languages they may be used in, or if they're translingual as claimed by the header. Previous consensus has been that the Unicode name, or a paraphrase of it, does not qualify as a definition.
Ḁ Ḕ ḕ Ḙ Ḛ ḛ Ḝ ḝ Ḭ ḭ Ḯ ḯ Ṍ ṍ Ṏ ṏ Ṑ ṑ Ṥ ṥ Ṧ ṧ Ṩ ṩ Ṵ ṵ Ṷ ṷ Ṹ ṹ Ṻ ṻ Ẏ ẚ
I'd be interested in seeing what these letters are used for, if anyone can document them, but I've failed to find anything myself.
Thanks. kwami (talk) 07:25, 10 September 2024 (UTC)
Latin: words with suffixes (and prefixes?)
[edit]I couldn't find habitasne. I eventually decoded it as habitās + -ne. @Nicodene has advised that words like habitasne do not merit a separate entry, but I feel it's worth a broader discussion, expanding on the original conversation.
I wouldn't mind so much not having a separate entry for words like habitasne if there were an easier way to find them. For example, if the search results could be coerced into showing something more useful, and/or if it could be presented (perhaps not hyperlinked) in a table of conjugations or similar. Having the word appear somewhere within the main verb entry could presumably help the search page to list it too — it seems to work this way for bailémosles, which doesn't have its own entry, but is mentioned within the bailar entry.
Slightly off-topic: is it possible to force the search to only look within a specified language or languages? For example, if the user 'knows' that the word is Latin, then can they avoid being shown results from English and other irrelevant languages?
A table of conjugations can perhaps (?) be automatically generated (and manually edited where necessary), and minimised by default. I'm thinking of the Spanish verb conjugation tables, which include not just the 'simple' conjugations, but also every (?) combination with pronoun suffixes too, such as in the Selected combined forms of bailar table: many words in the table do have their own entries too (such as bailarme and bailándolas), and are correspondingly linked, but also many — presumably less common — words don't (such as bailémosles and báilenla), which are somehow redlinked without being coloured red in that table. The convention adopted for Spanish verbs must surely have expanded the number of entries, but was still deemed worthwhile.
For people familiar with Latin it may seem trivial. But suppose I encounter a hypothetical new Latin word *previviruminsmaste. I would rather not have to 'manually' try various combinations in order to decode it: for example, would it be defined in one single entry (previviruminsmaste), or across two entries (pre + viviruminsmaste or previ + viruminsmaste or previviruminsmas + te or previvirumins + maste etc.), or across three entries (pre + viviruminsmas + te or previ + virumins + maste etc.)?
Alternatively, if there is no desire to add conjugation tables or similar to each main verb entry, how about adding a link to a grammar page listing various Latin suffixes (and prefixes?) that can commonly be applied?
—DIV (2001:8004:44F0:5AD4:F864:E084:92A9:DBF4 00:51, 11 September 2024 (UTC))
- The problem is that -ne belongs to a class of "enclitic" particles that can in principle be suffixed to just about any Latin word, not just verbs. See the discussion at Talk:fasque#Deletion_debate. It would be unwieldy and not very useful to display all of these forms even in a collapsed table. Ideally we would have redirects, but one of the many structural flaws of Wiktionary as a MediaWiki-based multilingual dictionary is that it doesn't make it easy to set up automatic redirects for cases like this.--Urszag (talk) 01:01, 11 September 2024 (UTC)
- One can vaguely dream of a search feature which, in the event of a query finding no results, displays results matching that query minus various common clitics. Nicodene (talk) 01:24, 11 September 2024 (UTC)
- Many languages have similar issues; e.g. we don't lemmatize every word with 's added. Arabic single-letter conjunctions and prepositions regularly cliticize onto the next word, which can momentarily trip up even native speakers, e.g. Fenakhay was looking for the rare verb اِسْتَسْأَلَ (istasʔala) and momentarily interpreted the form أستسألني as a form of this verb أَسْتَسْأَلُنِي (ʔastasʔalunī) (maybe "I ask myself", although this may be ungrammatical) when it's actually أَ (ʔa) (which marks a yes-no question) + سَ (sa) (future-tense prefix) + تَسْأَلُ (tasʔalu, “you ask”) + نِي (nī, “me”), i.e. "will you ask me?". The problem, as noted by User:Urszag, is that many types of clitics can be added onto pretty much any word, e.g. -que, -ne and -ve attach to the first word, whatever it is. Potentially we could write a JavaScript add-on that helps with this; we already have JavaScript gadgets that auto-redirect certain forms to certain other forms, and so it's not out of the question to write a gadget that tries to analyze a nonexistent word into its components, as User:Nicodene notes. But this would have to be quite complex and ideally would have machine learning attached to figure out the likely language and do the segmentation. Benwing2 (talk) 04:05, 11 September 2024 (UTC)
- There was a discussion a while ago about having our templates (modules), whenever they transliterate an Arabic word, output all the common methods of transliteration of Arabic, but then set them [except the Wiktionary Standard one] to "display: none" (or hide them in HTML comments), so that searching for them in our on-site search engine, or on Google, will find the relevant pages, without the extra content actually being displayed to readers of the entry itself. I'm not sure whether anyone got around to implementing that, but the same basic idea suggests itself to me here: have Latin-specific headword or inflection templates produce (but not display) text like "suffixed with -ne: foobarne, suffixed with -que: foobarque", etc, so that searches for those things find the relevant entry (and ideally the 'results snippet' even includes the "suffixed with..." text so the reader can work out what's going on). (Edited to add: the discussion was in December 2022.) - -sche (discuss) 19:16, 11 September 2024 (UTC)
- Other dictionaries of course do these automatic redirects since the user chooses his language in the mask. MediaWiki is not for languages, though we be better than the other dictionaries by virtue of the other things MediaWiki is designed for. One probably indeed needs some frequency data for any target language, if not so-called machine learning which sounds so undebuggable as to be out of scope of a Wiki. A list of relevant clitics and the mechanisms by which they are attached to be edited by trusted editors plus a toggle for the searcher to restrict for a specific language. I rather believe in someone just doing it with an external site … Fay Freak (talk) 19:46, 11 September 2024 (UTC)
I’m not a TTS
[edit]Last month @Fytcha deleted my contributions to Wiktionary accusing my voice recordings of being “computer-generated”. They are not. I request them to be brought back. JapanYoshi (talk) 00:23, 13 September 2024 (UTC)
- Your audio files have weird singsong intonation and missing or mispronounced sounds. Whether they're generated by a computer or by a human, we would rather have audio generated by people who speak the language well. - -sche (discuss) 01:34, 13 September 2024 (UTC)
- @-sche: There's no missing sound. The /p/ at the end of poop in poop pipe is [p̚] which is perfectly valid in GA (in fact, [p] would sound unnatural). With that said this one sounds a little non-native to me. I don't think JapanYoshi is using TTS, unless it's some kind of super-advanced AI that sounds exactly like a human, in which case I wouldn't be opposed to it anyway. Ioaxxere (talk) 06:39, 14 September 2024 (UTC)
- I hope this thread is not used in the future to assert consensus for the use of TTS. I'd be strongly opposed. The takeaway is that JapanYoshi's audios may not be TTS but they are incredibly unnatural sounding. Vininn126 (talk) 09:13, 14 September 2024 (UTC)
- I don't get the sense that the audios were recorded by someone who doesn't speak the language well. I think any unnaturalness is simply due to over-enunciation. So the solution is very simple: we just explain to JapanYoshi that we want audio files to sound as natural as possible, not over-enunciated, and if we find their speech a little unusual, then it should be labelled with the appropriate region. Of course, if JapanYoshi does have an idiosyncratic accent, then we might consider letting them know that it's important for the audio to be fairly representative of a given accent. But let's not jump all over this person and their contributions without even welcoming them to Wiktionary and giving them a little guidance! Andrew Sheedy (talk) 16:30, 14 September 2024 (UTC)
- @-sche: There's no missing sound. The /p/ at the end of poop in poop pipe is [p̚] which is perfectly valid in GA (in fact, [p] would sound unnatural). With that said this one sounds a little non-native to me. I don't think JapanYoshi is using TTS, unless it's some kind of super-advanced AI that sounds exactly like a human, in which case I wouldn't be opposed to it anyway. Ioaxxere (talk) 06:39, 14 September 2024 (UTC)
- The links you gave were all adequate pronunciations. Jeez, get off JY's back! Denazz (talk) 15:53, 14 September 2024 (UTC)
- As I said in the other thread, there's a certain type of pronunciation that should be expected in a dictionary. You can look at the OED, Merriam-Webster, Dictionary.com, etc. to find it. Even if they may sound like TTS (or be TTS), they still have a very specific and clear intonation & enunciation that's been missing from your audios. Remember that audios are meant to illustrate a standard pronunciation and are especially used by non-natives for learning/illustration purposes. Honestly, I really do think that we should have an explicit policy as to what should be expected from audios reflecting standard speech, as a lot of recent ones have been problematic for various reasons. I've been getting frustrated with the less-than-par quality that we've been allowing recently, and I also really do not have the time to go through each one, removing the ones that sound noticeably non-standard. CC: @-sche, @Benwing2, @Theknightwho. AG202 (talk) 17:29, 14 September 2024 (UTC)
- @AG202 I agree with you about the need for good-quality audio files but would an explicit policy accomplish anything? I assume the people who are uploading bad audio files are unlikely to read the policy even if it's in their face. Maybe a more relevant issue IMO concerns User:DerbethBot, which auto-uploads audio files. I have encountered lots of problems due to this; some of them are old but I don't know if they are all fixed and I can't tell from looking over the github source code because it isn't well documented. As an example, all audio files for any Arabic-script and Hebrew-script terms should be blacklisted because the scripts are underspecified. Yet there are definitely lots of Arabic script audio files present that have been uploaded by DerbethBot, and I don't know whether this can still happen. Benwing2 (talk) 20:30, 14 September 2024 (UTC)
- @Benwing2: An explicit policy would at least give us something to point to if we added a like filter or warning or something. It would also give less wiggle room to argue about what is and isn't "good audio", as we've seen happen time and time again. Re: bots like User:DerbethBot: as stated on their page, "Administrators: if this bot is malfunctioning or causing harm, please block it." If it's been seen time and time again that this bot is problematic in the way it adds audios, why wasn't it been blocked since 2008? Honestly, it baffles me a bit. AG202 (talk) 00:45, 15 September 2024 (UTC)
- @AG202 Because I don't know if the bot is still causing issues; I'm waiting for User:Derbeth to respond. I feel somewhat uncomfortable about the idea of a bot that auto-adds audio files without any way of verifying the correctness of the actual content, but not enough to insist on shutting it down outright. Benwing2 (talk) 01:15, 15 September 2024 (UTC)
- Doesn't that bot operate based on a whitelist? Vininn126 (talk) 06:26, 15 September 2024 (UTC)
- I don't think so, maybe it has whitelists for sites but generally it uses blacklists I think. Benwing2 (talk) 06:29, 15 September 2024 (UTC)
- Doesn't that bot operate based on a whitelist? Vininn126 (talk) 06:26, 15 September 2024 (UTC)
- @AG202 Because I don't know if the bot is still causing issues; I'm waiting for User:Derbeth to respond. I feel somewhat uncomfortable about the idea of a bot that auto-adds audio files without any way of verifying the correctness of the actual content, but not enough to insist on shutting it down outright. Benwing2 (talk) 01:15, 15 September 2024 (UTC)
- Hello, thank you for the patience. I had a longer vacation and wasn't able to answer. I would like to start with repeating User:DerbethBot#Frequently Asked Questions point 1. It's best to solve any problems on Commons because there are other bots adding audio files and they share nothing in common with my bot. I don't even know what rules those bots have. A problem fixed on Commons is a problem fixed for sure, and everywhere. Also, I reworked the FAQ to be clear about blacklist vs whitelist and the role of Lingua Libre files, as I agree with you, it's complicated and hard to understand. In this particular case, I suggest renaming the files on Commons so that they won't be matched. See FAQ point 4. --Derbeth talk 14:36, 23 September 2024 (UTC)
- I think that a workable solution would be to implement some sort of a voting system at https://lingualibre.org/ (the project under the Wikimedia Foundation's umbrella?) and grade audio recordings based on that. The downvoted audios or their submitters could be blacklisted. But the problem is that not all words even have audio recordings available, and beggars can't be choosers: https://lingualibre.org/wiki/List:Eng/Lemmas-without-audio-sorted-by-number-of-wiktionaries --Ssvb (talk) 18:06, 15 September 2024 (UTC)
- @Derbeth, @Benwing2: I saw the FAQ before making comments, and frankly, I don't think we should rely on Commons and English Wiktionary editors should not be expected to go through the Commons process to remove problematic entries here.
"I regularly re-run my bot (sometimes every week), so it will repeat the same edit over and over again." If the problem is with Commons file, please fix the Commons file.
- The above is too much to be expected when we simply want to remove problematic audios from English Wiktionary, and this is probably why we have so many audios here that are of poor quality. I would honestly simply say that Commons audios should not be added by any bot by default is a policy that we should have. AG202 (talk) 18:50, 23 September 2024 (UTC)
- Support. CitationsFreak (talk) 19:15, 23 September 2024 (UTC)
- 'Support'? Support what? AG202 CitationsFreak can you give any reasoning behind your strong demands? We are discussing, not voting for Brexit. What concretely do you propose instead? How do you know it will give better results than the status quo?
- My bot has over 500,000 edits. There is no way even 10% of this work could be achieved by manual edits. People on Commons add files there without using them anywhere. I have spoken to at least 1 uploader saying he expects some bot to take care of editing Wiktionary. I don't think there will be people here manually matching entries to files. It's very complicated: naming is inconsistent, categories are a mess. Plus it's as boring as hell.
- You are giving some anecdotal evidence of bad files being added, but no numbers. Even if there were 5,000 bad added, it would still be 99% beneficial edits. Show me such a positive ratio for human edits, please.
- I also think what you propose is against the Wikimedia spirit. Or the spirit of open knowledge. Wiktionary benefits from Commons data, so in addition to taking, should also give something back. What kind of thinking is that if something is wrong on Wiktionary, then we are going to fix it, but if there is a mistake on Commons, well, let it rot, it's not our problem, it's Commons guys problem? I started working in Wiktionary in an edition other than English and it's enfuriating when I see that the proposed solution to a shared bad file is to fix the local usage here, and let all others use the bad file. There were times I believed we are one community, not 'English Wiktionary community', 'German Wiktionary community' and then some distant 'Commons community'. Does it no longer apply? --Derbeth talk 21:22, 23 September 2024 (UTC)
- It's not about the percentage of bad audios, even 100 bad audios is not something that we should tolerate, regardless of the total number. If you allowed a blacklist, this would be easier, but since you don't I'd have to suggest simply blocking the bot until we have a policy set in stone. My issue is that we simply do not have enough people monitoring audios, leading to an alarming rate of inaccurate audios being created and added as of late. Having a bot that automatically adds them with no human review only makes that problem worse. We simply do not have the time to individually go through all 500,000 edits. And just because humans make bad edits too, doesn't mean that we should allow bots to either. We don't even know which audios are bad because there are so many of them, and there's no human review.
- "What kind of thinking is that if something is wrong on Wiktionary, then we are going to fix it, but if there is a mistake on Commons, well, let it rot, it's not our problem, it's Commons guys problem" I did not say this, and please don't extrapolate further. I said that we cannot expect Wiktionary editors to go fix the problems with Commons. If they choose to do so, power to them and that's helpful to the Wikimedia goal, but we cannot expect them to do so. Commons has their own rules and procedures and we cannot wait for them to implement the changes that we need here. Since we have our own rules and procedures, we can also say that we don't want bots automatically adding Commons audios for that reason. AG202 (talk) 21:35, 23 September 2024 (UTC)
- I support not adding anything from another wiki by default without human review. You should be able to vouch for your bot. CitationsFreak (talk) 22:56, 23 September 2024 (UTC)
- @Derbeth I have to agree with @AG202 and @CitationsFreak. When it comes to bot changes, I am very stringent about what I allow the bot to do, and don't allow automatic changes unless there's a very low rate of error. Given the number of audios being added to Commons and the large percentage of them that are bad, it's IMO simply not appropriate to auto-add them and expect people to go through them all manually and filter out the bad ones. It's that much less reasonable IMO to require that filtering out the bad ones be done on Commons or in general on a site other than Wiktionary; nor is it reasonable for your bot to have no mechanism to note when a previous audio was deleted and keep re-adding it over and over. This sort of sloppiness might have been appropriate 10 or 15 years ago when Wiktionary was just getting started and had much less quality control, but it is not appropriate now. I would ask that you shut your bot down until and unless you can come up with an automatic or semi-automatic mechanism for verifying that the audios are correct before you add them (which would probably require machine learning). Benwing2 (talk) 23:52, 23 September 2024 (UTC)
- @Benwing2: The bot finds audio files added by (potentially untrustworthy) users to Commons and adds them to Wiktionary. I don't see how that's any better or worse than that same user adding their audio file directly to Wiktionary. With that said: @Derbeth, given that many users are reluctant to spend time learning Commons's processes, would it be possible to do something like have the bot automatically create a deletion request on Commons if the file is removed from Wiktionary? Ioaxxere (talk) 03:58, 24 September 2024 (UTC)
- @Ioaxxere: There's a huge difference. If a user is adding their own audios to Wiktionary, then we can reasonably assume that they probably read the Wiktionary's contribution guidelines, such as Help:Audio pronunciations. But if a bot is automatically adding some random audios from Commons, then we can't count on that. --Ssvb (talk) 14:06, 24 September 2024 (UTC)
- @Benwing2: The bot finds audio files added by (potentially untrustworthy) users to Commons and adds them to Wiktionary. I don't see how that's any better or worse than that same user adding their audio file directly to Wiktionary. With that said: @Derbeth, given that many users are reluctant to spend time learning Commons's processes, would it be possible to do something like have the bot automatically create a deletion request on Commons if the file is removed from Wiktionary? Ioaxxere (talk) 03:58, 24 September 2024 (UTC)
- @Derbeth I have to agree with @AG202 and @CitationsFreak. When it comes to bot changes, I am very stringent about what I allow the bot to do, and don't allow automatic changes unless there's a very low rate of error. Given the number of audios being added to Commons and the large percentage of them that are bad, it's IMO simply not appropriate to auto-add them and expect people to go through them all manually and filter out the bad ones. It's that much less reasonable IMO to require that filtering out the bad ones be done on Commons or in general on a site other than Wiktionary; nor is it reasonable for your bot to have no mechanism to note when a previous audio was deleted and keep re-adding it over and over. This sort of sloppiness might have been appropriate 10 or 15 years ago when Wiktionary was just getting started and had much less quality control, but it is not appropriate now. I would ask that you shut your bot down until and unless you can come up with an automatic or semi-automatic mechanism for verifying that the audios are correct before you add them (which would probably require machine learning). Benwing2 (talk) 23:52, 23 September 2024 (UTC)
- @Derbeth: "What kind of thinking is that if something is wrong on Wiktionary, then we are going to fix it, but if there is a mistake on Commons, well, let it rot, it's not our problem, it's Commons guys problem?"
- This thinking is very much reasonable. The process of recording audios is very much automated, at least when using Lingua Libre. Any contributor is able to record hundreds of audios in a matter of just a few hours with all the QA checks if they are serious about the quality of their samples. But if somebody isn't doing any QA at all, then they can easily record and upload any garbage to Commons at a rate of less than 10 seconds per sample!
- And for comparison, how much effort is required to challenge a single bad quality audio on Commons? Why would anyone bother doing that? Moreover, are English audio samples created by non-native English speakers even illegal on Commons according to the rules of Commons? Are robotic sounding audios illegal on Commons? --Ssvb (talk) 14:25, 24 September 2024 (UTC)
- @Benwing2: An explicit policy would at least give us something to point to if we added a like filter or warning or something. It would also give less wiggle room to argue about what is and isn't "good audio", as we've seen happen time and time again. Re: bots like User:DerbethBot: as stated on their page, "Administrators: if this bot is malfunctioning or causing harm, please block it." If it's been seen time and time again that this bot is problematic in the way it adds audios, why wasn't it been blocked since 2008? Honestly, it baffles me a bit. AG202 (talk) 00:45, 15 September 2024 (UTC)
- @AG202 I agree with you about the need for good-quality audio files but would an explicit policy accomplish anything? I assume the people who are uploading bad audio files are unlikely to read the policy even if it's in their face. Maybe a more relevant issue IMO concerns User:DerbethBot, which auto-uploads audio files. I have encountered lots of problems due to this; some of them are old but I don't know if they are all fixed and I can't tell from looking over the github source code because it isn't well documented. As an example, all audio files for any Arabic-script and Hebrew-script terms should be blacklisted because the scripts are underspecified. Yet there are definitely lots of Arabic script audio files present that have been uploaded by DerbethBot, and I don't know whether this can still happen. Benwing2 (talk) 20:30, 14 September 2024 (UTC)
- (Previous discussion: Wiktionary:Beer parlour/2024/August § Synthesised audio files (again))
- @JapanYoshi: Hey. I'm willing to take you at your word that your audio files are not computer-generated and I therefore apologize for my mistake. When I read the BP thread I linked to above, I reviewed your audio files and found there to be multiple issues with them. On top of that, some files, especially File:En-fucking Nora.ogg, sounded "robotic" to me; to my ears, there's something weird going on in the higher frequencies of that file, exactly the same kind of artifact often encountered in synthesized audio files. However, that could just as well be your recording equipment or maybe I'm just mishearing things.
- All that said, even if not the product of speech synthesis software, there's still issues to be addressed with your audio files as others in this discussion have also pointed out. I won't touch your audio files anymore and I wouldn't revert you if you revert my removal. — Fytcha〈 T | L | C 〉 19:58, 14 September 2024 (UTC)
- Having just noticed this, I'm going to block the user for unacceptable conduct (bigotry). For my part, I set the block length to indef because my feeling is that a user whose 31 edits are "queer people / theorists advocate pedophilia and bestiality" and unnatural audio and defense thereof (which, in light of the other thing, someone could even speculate could be trolling) is NOTHERE, but if the user makes an unblock request that persuades another admin that they should be unblocked, I (of course) won't stand in the way of that. - -sche (discuss) 21:28, 14 September 2024 (UTC)
- WTF, -sche? You blocked them for asking a question "why don't we have such an entry?" I'm disappointed. Denazz (talk) 21:39, 14 September 2024 (UTC)
- Yikes on their part. AG202 (talk) 00:46, 15 September 2024 (UTC)
- I oppose an indefinite block. I don't really understand what they were getting at with that question you blocked them for, but I really don't understand what happened to assuming good faith. It seems we assume bad faith now until a user can prove otherwise. Andrew Sheedy (talk) 04:00, 15 September 2024 (UTC)
- Well, it sure reads to me like that post is trolling. However, if they ask for an unblock and can provide a reasonable explanation why their post was not trolling, I would not be opposed to reducing the block to e.g. a month. Benwing2 (talk) 04:08, 15 September 2024 (UTC)
- Well, can I ask for a unblock on their behalf? I assume they were asking why we were missing a term, albeit a vulgar/offensive one. Sure, it wasn't very clear a request, but not blockworthy. Like if I ask "I heard 'you are a honky donkey' in a film used against a white person from Ottawa. Can we add it?" Denazz (talk) 07:21, 15 September 2024 (UTC)
- No, it's very obvious what type of place they're coming from. Judith Butler has never argued for those topics, nor is she their advocate, and anyone who's seriously taken a look at queer theory would know that those topics are not a part of it. Don't be obtuse, saying that they're just asking "why don't we have xyz entry". It's at best trolling and at worst bigotry to equate queer theory and queerness with those unrelated repulsive topics. I'm disappointed but not surprised. AG202 (talk) 15:40, 15 September 2024 (UTC)
- I know little of LGBT-studies, and their stance on the issue is not my concern. The user deserves another chance. BTW, if anything creative comes out the discussion, let it be the creation of q***r! Denazz (talk) 07:26, 18 September 2024 (UTC)
- No, it's very obvious what type of place they're coming from. Judith Butler has never argued for those topics, nor is she their advocate, and anyone who's seriously taken a look at queer theory would know that those topics are not a part of it. Don't be obtuse, saying that they're just asking "why don't we have xyz entry". It's at best trolling and at worst bigotry to equate queer theory and queerness with those unrelated repulsive topics. I'm disappointed but not surprised. AG202 (talk) 15:40, 15 September 2024 (UTC)
- Well, can I ask for a unblock on their behalf? I assume they were asking why we were missing a term, albeit a vulgar/offensive one. Sure, it wasn't very clear a request, but not blockworthy. Like if I ask "I heard 'you are a honky donkey' in a film used against a white person from Ottawa. Can we add it?" Denazz (talk) 07:21, 15 September 2024 (UTC)
- @Andrew Sheedy What they asked is equivalent to a user asking why we don't list "criminal" as a sense of black, and that's being quite generous if I'm honest. Theknightwho (talk) 00:44, 19 September 2024 (UTC)
- Based on the explanation on their talk page, I'm not convinced that's the case. As weird as the request sounded. The user could certainly work on communicating more clearly, but I wouldn't be confident in saying it was in bad faith. Andrew Sheedy (talk) 04:00, 19 September 2024 (UTC)
- @Andrew Sheedy If it's not in bad faith, then it means they are pushing views so utterly repugnant that they are inherently antithetical to the ethos of this site. Either way, I have no interest whatsoever in reversing a permanent block. Theknightwho (talk) 12:35, 19 September 2024 (UTC)
- Based on the explanation on their talk page, I'm not convinced that's the case. As weird as the request sounded. The user could certainly work on communicating more clearly, but I wouldn't be confident in saying it was in bad faith. Andrew Sheedy (talk) 04:00, 19 September 2024 (UTC)
- Well, it sure reads to me like that post is trolling. However, if they ask for an unblock and can provide a reasonable explanation why their post was not trolling, I would not be opposed to reducing the block to e.g. a month. Benwing2 (talk) 04:08, 15 September 2024 (UTC)
- I also agree with sche's block. Unless there's some sort of severe misunderstanding and/or JY has poor communication skills, I cannot see how this comment was not intended to be troll-y or intentionally homophobic. — BABR・talk 07:04, 22 September 2024 (UTC)
- Sometimes offensive messages are so exaggerated I cannot determine if they were a messed up prank or a messed up person. "Don't talk to me." 💔 Flame, not lame (talk) 07:13, 22 September 2024 (UTC)
-Sche made the right call here. There is legitimate disagreement over the term queer within the LGBT community. Someone taking the position that queer is a slur isn't necessarily here in bad faith. But someone who has suggested that queer is synonymous with "pedophilia/bestiality advocate" is very obviously an anti-LGBT troll. The singling out of Judith Butler is a subtler tell. They are basically the only gender theorist that anti-LGBT folks can name. Few anti-LGBT people have actually engaged with Butler's work. That's why none of them can seem to clearly articulate anything Butler has actually written. These people are playing a game of telephone with like two garbled quotes. Butler did not argue in Undoing Gender (2004) that "some forms of parental child rape are only bad because of the social stigma" as JapanYoshi has claimed. They suggested that "there are probably forms of incest that are not necessarily traumatic or which gain their traumatic character by virtue of the consciousness of social shame that they produce." That's a nuanced argument referencing cases like this British woman who never had children because of her deep shame at learning as an adult that she was born of seemingly consensual sibling incest. I wouldn't trust contributions from a user who has either knowingly misrepresented an author's writing to promote an anti-LGBT conspiracy theory or didn't care enough to verify a supposed quote. WordyAndNerdy (talk) 08:13, 19 September 2024 (UTC)
With apologies for not responding to the unblock request (from JapanYoshi and from Andrew, here and on the former's talkpage) sooner: my view is that someone arriving, making a handful of questionable edits (all or most of which other users have had to undo) and then saying queer theorists are advocating/preaching pedophilia/bestiality, is very obviously either NOTHERE (if trolling) or not someone we want here (if sincere). Although their comment on the talk page, and not their audio is the basis on which I issued the block, it does give a certain context to the fact that their only other scant contributions seem like like they could also be trolling (awkward audio which they stridently defend). I issued an indef block because I judged that to be the appropriate thing to do in this situation, and since I do not see a reason to modify the block, I am not personally going to modify it, but (as always) I welcome anyone who thinks I've made an inappropriate block to discuss it like this and modify it if people think it should be modified. - -sche (discuss) 06:57, 20 September 2024 (UTC)
- Oh my gosh! Deepest apologies replying to @Ioaxxere's comment and dropping tips. I did not read your message first nor look at block log! "Don't talk to me." 💔 Flame, not lame (talk) 00:17, 22 September 2024 (UTC)
- To use an analogy: if someone was stopped for feeding wild animals after tossing red meat around and denied they intended to feed any animals, in order to take them at their word one would have to conclude they were either unaware that the substance they were tossing was red meat, that there was anything wrong with tossing it around in public places, or that wild animals would eat it. If not lying, they would be too clueless to be trusted in places frequented by wild animals. The same could be said for someone tossing around ideologically loaded buzzwords as for the red meat. Chuck Entz (talk) 01:08, 22 September 2024 (UTC)
- Oh... It's still 1am and I'm using my cell phone in bed, and either way I can't really read paragraphs without text-to-speech so... "Don't talk to me." 💔 Flame, not lame (talk) 06:53, 22 September 2024 (UTC)
zh-pron order
[edit]Hey, I think Wade-Giles should appear above Tongyong Pinyin in Template:zh-pron, on the basis of wider usage of Wade in personal names, historically, etc. I don't know where to make that change in the code but I think it would be non-controversial. It seems too minor for beer parlor and grease pit. If anyone that sees this could do that, I would appreciate it, or tell me what to do and where could I take this. Thanks. --Geographyinitiative (talk) 22:58, 13 September 2024 (UTC)
- I'm not sure if this change should be done. Pinyin is, to my understanding, more widely used in transliterating Chinese than Wade-Giles presently, so it should go first. CitationsFreak (talk) 00:17, 14 September 2024 (UTC)
- Hanyu Pinyin, not Tongyong Pinyin. MuDavid 栘𩿠 (talk) 00:51, 14 September 2024 (UTC)
- Oh yeah, of course Hanyu Pinyin is on top, I'm just saying that it should be: Hanyu Pinyin, then Bopomofo (so-called "Zhuyin"), then Wade-Giles, then Tongyong Pinyin, then the rest. I think that's more in line with volume of usage of those systems. --Geographyinitiative (talk) 09:29, 14 September 2024 (UTC)
Archiving failure at payback's a bitch
[edit]This deleted entry was just recreated, and I went to the talk page to see the details of the deletion. The only thing on the talk page was a discussion from January of 2013 where Equinox and I explained that the {{rfd}}
template had to stay because its deletion was still being discussed (that put the entry on my watchlist, which is how I found out it was recreated). The page itself was deleted in April of 2013 as having failed RFD, but no mention of that made of it onto the talk page. It was only after wading through the revision history of WT:RFD from 2013 that I was able to find that it had been added to the RFD for life's a bitch, and I found the discussion was archived at Talk:life's a bitch.
How should we handle this? The new definition is odd and probably wrong, but not SOP. I'm not really sure what to do with the talk page so the previous RFD is reflected there, and right now it seems a bit off to tell someone that their good-faith page creation is going to be deleted because of something not explained anywhere findable from the entry or its talk page. If someone wants to retag the new entry and send it to RFDE, that might help. Chuck Entz (talk) 00:51, 15 September 2024 (UTC)
- This, that and the other re-deleted the entry, saying it failed RFD. I've added a link from the talk page to the RFD. — excarnateSojourner (ta·co) 06:42, 22 September 2024 (UTC)
- Sorry, didn't see this discussion - in any event, I did try to make it clear in my deletion summary what the next steps are for a potential entry creator. This, that and the other (talk) 09:38, 22 September 2024 (UTC)
Should personal attacks be restored?
[edit]Let's say that Alice and Bob get into a heated personal argument. Insults lobbed, caps lock engaged, lawyers threatened, the whole nine yards. But then Caroline decides to hide the comments made by Alice and Bob. The question is, should the comments be restored?
My understanding of the policy is that they should be, since it's common etiquette to not edit other's comments. However, it does feel wrong to let such incivility lay out in the open. CitationsFreak (talk) 07:56, 15 September 2024 (UTC)
- I say they should be if only lest discords be continued by editing others’ comments. Any bidding to hide or keep hidden exaggerated argumentative behaviour specifically – as opposed to e.g. data protection violations where findability in machine searches has to be considered, which loses relevance in so far as pseudonymity is kept, and circular arguments of editors that have been hidden by a click-to-open box in ultimately inoffensive cases due to the otherwise unpalatable bulk of the discussion – sets a perverse incentive.
- Empirically it is also shown that the cases occurring on Wiktionary – I won’t point at the cases – would have fared better if people would have gotten over the matter by just remembering they are not a main character and not reading it already, instead of heating up for edit summaries.
- The probability of success in forgetting such microtraumata without even any cognitive reframing effort is great, while only complexity is engaged by hiding their agents in edit histories. Fay Freak (talk) 09:17, 15 September 2024 (UTC)
- I think hiding, but not deleting, is fine. I'd favor doing so whenever motives, values, attitudes, or beliefs are attributed to a user. DCDuring (talk) 17:34, 15 September 2024 (UTC)
- I recently came across
{{RPA}}
, a nearly unused template that assumes removing a personal attack made by someone else is at least sometimes appropriate. I documented it based on Wiktionary:No personal attacks, which says, "Many Wiktionarians remove personal attacks on third parties on sight, and although this is not policy it is often seen as an appropriate reaction to extreme personal abuse." — excarnateSojourner (ta·co) 06:27, 22 September 2024 (UTC)
Request to change libelous block statement
[edit]Hello, I am User:Gapazoid. I was blocked by User:Surjection for an edit to MAP that promoted the idea that there are people who are attracted to minors and are against inappropriate adult-minor relationships (so-called "anti-contact pedophiles" or "non-offending pedophiles"). Furthermore, I identified myself as being both attracted to minors and fundamentally against any sexual contact between adults and minors.
The stated reason for my block is "Unnacceptable conduct: pedophilia advocacy". To the average person, "pedophilia advocacy" implies that I was promoting inappropriate adult-minor relationships, which is not the case, as I have repeatedly explained. It is very important to me that the public is not misinformed about my values. In my discussion with Surjection on their talk page, they stated that the exact reason for my block was "promoting the idea that there are non-offending pedophiles". This statement I have no issue with, as it is truthful and cannot be misconstrued.
Therefore, I am requesting that the stated reason for my block be changed from "Unacceptable conduct: pedophilia advocacy" to "Unacceptable conduct: Promoting the idea that there are non-offending pedophiles". 76.35.75.228 18:28, 15 September 2024 (UTC)
Quotations asserting dubious, clickbaity, controversial, deceptive or sometimes even blatantly false statements or conjectures
[edit]Today an IP user made this edit, adding a quotation about Putin allegedly admitting that he is "hunting" his opponents. To put it mildly, I'm not a fan of Putin, but I personally think that the concept of "hunting" can be better illustrated using some other quotations, which don't mention Putin, Biden, Trump or any other modern politician. And also without trying to promote any political, religious, ideological or corporate narratives. I checked the WT:QUOTE#Choosing_quotations policy and it doesn't say anything on this topic. Does Wiktionary need some kind of a formal rule to prevent it from turning into an outlet of propaganda for various modern ideologies, hoaxes and conspiracy theories?
That said, really old books may contain quotations, which mention obsolete morally questionable barbaric traditions or some outdated unscientific information. Do they get a free pass on the basis of their age? --Ssvb (talk) 20:22, 15 September 2024 (UTC)
- Adding a controversial quote to an entry for a non-controversial term that doesn't need the controversial aspect to illustrate the meaning is definitely a violation of WT:NPOV. I'm not talking about politically charged or bigoted terms, which would have bigoted or politically charged usage that we would be wrong not to document. I'm talking about converting an entry for an ordinary term into a political statement by adding a quote that illustrates something political that doesn't need to be there to understand the term. Sure, there are lots of really outrageous things people have said that happen to contain the word "the", but that's not a reason to add them to the entry for "the" as quotes or usage examples.
- I've reverted and hidden the edit that added that quote. Chuck Entz (talk) 20:50, 15 September 2024 (UTC)
- It is not a controversial term but its meaning range has to be described in a controversial context: “hunting” in the figurative sense always involves various kinds of, well, predatory behaviour designed to offend. In other words not the term, but the meanings being charged is enough for the quotes to be charged. Only that the Belarusian entry has not been that elaborate. It should get one gloss or at least quote that is normal and then the user might add propaganda, with some hyperbole.
- I cannot agree with the general rule given that I normally browse political websites and find quotes there about specific people or brands that everyone relates too, even find them when I specifically search terms, because that’s what publications are about since humans are social animals, and if you aspire to be in a leading political office, the more so as an eternal leader, you have to bear being an example of everything. I would be more concerned if the shown example skewed the usage already, like the anti-abortion propaganda redefining infant the other day. Fay Freak (talk) 18:29, 16 September 2024 (UTC)
templatizing raw category references more generally
[edit]We have a mechanism that automatically tracks raw category references. See subcategories of Category:Entries with language name categories using raw markup by language and Category:Entries with topic categories using raw markup by language. I have a script to templatize these into calls to {{cln}}
and {{C}}
, respectively, grouping multiple categories into a single call as much as possible. I have run the script on all the pages in various individual common languages (e.g. Spanish, French, German, Russian, Italian, several others) but not generally. As discussed in Wiktionary:Grease_pit/2024/September#user_sandboxes_showing_up_in_categories and elsewhere, there are two major disadvantages in using raw category references: (1) sort keys are not properly generated for languages that have custom sort orders, meaning that the pages are wrongly ordered in the categories in question; (2) transclusions of pages containing raw category references into userspace pages result in the userspace pages wrongly showing up in the categories in question. My script has been extensively tested through its use on the various common languages mentioned above. I propose running the script on all the pages in all languages under the above maintenance categories; or maybe, on all but certain languages (e.g. excluding English if people object for some reason to this). The only downside I can think of is a slight increase in Lua memory usage, which could theoretically push some pages over the limit if they're close to it; but AFAIK, with the increase in memory limits late last year, no pages are close to the current limit. Instead, we're hitting the template expansion limits before the memory limits, and I don't think the use of Lua-based templates here will increase the template expansion size (and in any case, the number of such categories on a given page is usually small). If for some reason any given page ends up hitting a limit as a result of this, we can back out the changes for that particular page, whitelist it in the code that generates the contents of the subpages of Category:Entries with language name categories using raw markup by language etc., and blacklist it in my templatize-categories script so a future run won't affect it. Benwing2 (talk) 23:12, 15 September 2024 (UTC)
- I personally am in favor of this; it would save me a lot of time and energy. -BRAINULATOR9 (TALK) 03:48, 17 September 2024 (UTC)
- Do it! Might be worth running it on a regular basis afterwards too. — excarnateSojourner (ta·co) 05:22, 22 September 2024 (UTC)
- Support. Einstein2 (talk) 19:52, 23 September 2024 (UTC)
- Support. Juwan (talk) 08:24, 24 September 2024 (UTC)
- OK, I did this for both language name and topic categories for all languages except English. Since it seems to have worked, in a couple of days I'll do this for English as well unless there are specific objections. Benwing2 (talk) 21:52, 24 September 2024 (UTC)
- BTW the remaining members of these categories for languages other than English are false positives. I fixed the algorithm in Module:headword/page that generates the categories so eventually these categories will empty. Benwing2 (talk) 21:53, 24 September 2024 (UTC)
rename Template:senseno to Template:senselink and clean up
[edit]{{senseno}}
is a nasty hack created by IP 70.* (who seems to have disappeared). Per discussion with User:Vininn126, I am planning on renaming it to {{senselink}}
and not having it display the sense number by default because I don't believe this is the best way of referring to senses; instead senses should be named using a summary of the meaning of by POS. Also the code in Module:senseno to determine the number of the sense is really terrible. I am planning on renaming it to {{senselink}}
, cleaning it up and adding a required param to specify either a meaning summary (arbitrary text), a request for the sense number (maybe +#
or something) or a part of speech (maybe pos:POS
or something). As an example of what I mean, under raz you have:
{{senseno|pl|counting|uc=1|pos=numeral}} is a generalization of {{senseno|pl|instance|pos=noun}}, for which see {{cog|zlw-opl|raz}}. For this use, compare {{cog|ru|раз}}. {{senseno|pl|case|uc=1|pos=noun}} is a semantic narrowing of {{senseno|pl|instance|pos=noun}}.
which displays as
Sense 1 is a generalization of sense 1, for which see Old Polish raz. For this use, compare Russian раз (raz). Sense 1 is a semantic narrowing of sense 1.
This is really awful. Much better would be "the sense one is a generalization of (one) time, for which see (etc.)", which would make a lot more sense. Benwing2 (talk) 06:13, 16 September 2024 (UTC)
- Anything for more specificity would be preferable. Vininn126 (talk) 06:19, 16 September 2024 (UTC)
- No objection to adding an option for a gloss (which I already add manually), but I'm not sure it's a good idea to remove the ability to display a sense number altogether. If an entry has many senses, having the sense number may be a quick way of determining which is the relevant sense referred to. Could you provide an example of how the template would display if the sense number is removed?
- On a separate note, perhaps there should also be options for adding the etymology number (for example "etymology 1, sense 2") and the part of speech ("noun sense 1"), though I'm not sure how this would be displayed if the sense number is ultimately removed as proposed. — Sgconlaw (talk) 19:43, 16 September 2024 (UTC)
- @Sgconlaw I'm not suggesting removing the ability to display a sense number, but just requiring that if the user wants a sense number, they request it explicitly using e.g.
{{senselink|pl|#}}
or{{senselink|pl|+#}}
, instead of having the template default to displaying a sense number. Basically the second param is required and specifies either a short gloss, a request for a sense number or a part of speech. Benwing2 (talk) 19:54, 16 September 2024 (UTC)- @Benwing2: ah, I see. Could you provide some mock-ups of how the template will display if different parameters (sense number, gloss, part of speech, etc.) are used? — Sgconlaw (talk) 20:24, 16 September 2024 (UTC)
- @Sgconlaw
{{senselink|pl|#}}
displays as "sense 1" or whatever, linked appropriately{{senselink|pl|pos:noun}}
displays as "the noun sense", linked appropriately{{senselink|pl|(one) time}}
displays as "(one) time", linked appropriately; alternatively it could display as "the sense (one) time", but then you'd need a way of suppressing the words "the sense"
- If you think it would be useful, I can provide syntax to include the etymology number; maybe
{{senselink|pl|##}}
displays as "etymology 1, sense 2" - or whatever. Benwing2 (talk) 21:41, 16 September 2024 (UTC)
- @Sgconlaw
- @Benwing2: ah, I see. Could you provide some mock-ups of how the template will display if different parameters (sense number, gloss, part of speech, etc.) are used? — Sgconlaw (talk) 20:24, 16 September 2024 (UTC)
- @Sgconlaw I'm not suggesting removing the ability to display a sense number, but just requiring that if the user wants a sense number, they request it explicitly using e.g.
- I think the template was designed for use in image captions, where brevity is valuable. I'm not hugely supportive of any changes, especially if it's going to introduce yet more of this bespoke syntax ("funny characters to memorise") that seems to be in vogue these days. This, that and the other (talk) 01:49, 17 September 2024 (UTC)
- @This, that and the other The problem is that this template is not only used for image captions. Would you rather have two different templates, one for image captions and another for etymology sections? That seems a worse solution. Benwing2 (talk) 02:02, 17 September 2024 (UTC)
- @Benwing2 surely it wouldn't be too much trouble to have
{{senseno}}
to generate a sense number, and{{senselink}}
to generate a sense link? Obviously the situation at raz is silly, but it's hardly the fault of{{senseno}}
that it's being forced to do bad things (I certainly would not have attempted to use it on an entry with more than one etymology section!). Anyway maybe I need to think about this some more. This, that and the other (talk) 02:09, 17 September 2024 (UTC)
- @Benwing2 surely it wouldn't be too much trouble to have
- @This, that and the other The problem is that this template is not only used for image captions. Would you rather have two different templates, one for image captions and another for etymology sections? That seems a worse solution. Benwing2 (talk) 02:02, 17 September 2024 (UTC)
- @Benwing2: One feature that I would like is a
|t=
parameter like our other templates. So you would be able to do something likeSense 2 ("something something") comes from [...]
without having to hack it together in wikitext. It could be generated automatically as well but in some cases you want to shorten the gloss a bit. Ioaxxere (talk) 03:44, 17 September 2024 (UTC)
That pesky dot in Template:pedia
[edit]The dot at the end of {{pedia}}
is an absolute nuisance. I suppose it was put there because most of our reference templates end with a dot, but (a) Wikipedia isn't a reference, and (b) the template is so frequently used in running text that the dot becomes a pain to deal with. If you want to write a sentence like "See {{pedia|Something}}
", you have to remember to leave off the dot at the end, because the template adds it for you!
Would there be support for a bot run to add a dot after every instance of {{pedia}}
, after which we can remove the dot itself from the template? The same would need to be done with the other bolded, logo-adorned Wikimedia project link templates like {{specieslite}}
. This, that and the other (talk) 01:47, 17 September 2024 (UTC)
- Yes definitely. Benwing2 (talk) 02:03, 17 September 2024 (UTC)
- I frequently use
{{pedia}}
for references, but I have no objection to the removal of the dot from the template. There are other templates it could be removed from too. DonnanZ (talk) 08:19, 18 September 2024 (UTC) - Let's remove the period. I believe it's used more often in bulleted lists than running text, but in either case, it's unnecessary. On e.g. dirigible, the See also section looks awkward with a list of raw pagelinks followed by "dirigible on Wikipedia." Ultimateria (talk) 23:16, 22 September 2024 (UTC)
- How often is
{{pedia}}
used in running text? I have hardly come across that. Most of the time it is used as a reference in the "Further reading" section to provide one or more links to relevant Wikipedia articles, in which case a full stop at the end is appropriate. I would prefer that the full stop remain, but that it can be turned off using|nodot=1
. — Sgconlaw (talk) 19:56, 28 September 2024 (UTC)
- How often is
Minitoc
[edit]{{minitoc}}
has been added to 436 of our longest entries so far. I think now that we've had time to get used to it we can decide on a policy for when it can be added. I've personally found it very useful on mobile, especially with User:Ioaxxere/minitoc.js so I would support adding it to all entries with at least five language section (probably via a continuously running bot job). Note that the template uses some complex rules to show or hide itself on different skins which you can see here. Ioaxxere (talk) 03:44, 17 September 2024 (UTC)
- I love it. And I also love the initiative that has been taken to address a real, longstanding problem.
- A few minor comments about the look of the template (I know that's not the purpose of this section!):
- Why is it collapsed by default? The regular TOC is not collapsed by default, so why should this one be?
- The space before the bullet should be a non-breaking space.
- It serves no purpose when Tabbed Languages is enabled, so something should be added to MediaWiki:Gadget-TabbedLanguages.css to hide the minitoc.
- As for the thrust of your point, I feel that a better threshold would be - add
{{minitoc}}
to entries where the regular TOC exceeds, say, 25 lines (this could be easily calculated by a bot). This, that and the other (talk) 04:46, 17 September 2024 (UTC) - One thing I find confusing: why does it have to be implemented by a template in each page's source code (whether added manually or by a bot)? Is it impossible to add logic to whatever code generates and displays the normal TOC?--Urszag (talk) 07:31, 17 September 2024 (UTC)
- @This, that and the other: You can make it uncollapsed by default by clicking the link in the sidebar and clicking "Show table of contents" (see diff). @Urszag: Yes, we cannot control how the TOC is generated to my knowledge. Ioaxxere (talk) 02:57, 18 September 2024 (UTC)
- Thanks @Ioaxxere for addressing the issues. As for collapsing, I was talking about the default state for logged-out desktop users. The default state of the MediaWiki TOC is uncollapsed; the default state of
{{minitoc}}
is collapsed. What is the rationale for the inconsistency? - In any event, I Support wider use of this template. This, that and the other (talk) 04:57, 18 September 2024 (UTC)
- @This, that and the other: We could try that. I think we would have to change something in MediaWiki:Gadget-defaultVisibilityToggles.js or MediaWiki:Gadget-VisibilityToggles.js? Not sure (@Erutuon?). Ioaxxere (talk) 19:56, 18 September 2024 (UTC)
- Thanks @Ioaxxere for addressing the issues. As for collapsing, I was talking about the default state for logged-out desktop users. The default state of the MediaWiki TOC is uncollapsed; the default state of
- Pinging @Benwing2, JeffDoozan in case either of you are interested in taking this on as a bot job. Ioaxxere (talk) 19:44, 28 September 2024 (UTC)
- Used this for the first time for tee. Looks good. DonnanZ (talk) 14:48, 29 September 2024 (UTC)
- Ironically, it's not so good for an English entry with multiple headings. You can't choose a section (from the TOC) as you could before. DonnanZ (talk) 16:00, 29 September 2024 (UTC)
- @Donnanz: On Vector 2022, the default TOC is always visible so you get the best of both worlds. Ioaxxere (talk) 16:26, 29 September 2024 (UTC)
- @Ioaxxere: Sorry, I'm not sure how you get Vector 2022. DonnanZ (talk) 17:57, 29 September 2024 (UTC)
- Is there a way to have it available for all skins? CitationsFreak (talk) 19:09, 29 September 2024 (UTC)
- @Donnanz: Go to Special:Preferences and you can change your skin under "appearance". You can also temporarily try a different skin by adding
?useskin=vector-2022
to the link, e.g. https://en.wiktionary.org/wiki/fettuccia?useskin=vector-2022 Ioaxxere (talk) 19:45, 29 September 2024 (UTC) - @CitationsFreak: If you always want to see the TOC, you can add this to your CSS:
[data-toc-length] { display:block !important; }
to your common.css. But I wouldn't recommend doing that since it's pretty ridiculously long on a page like A. Ioaxxere (talk) 19:45, 29 September 2024 (UTC)- That's not the issue. I'm uncomfortable with the idea that we should either use a certain skin or add something to our CSS. CitationsFreak (talk) 04:05, 30 September 2024 (UTC)
- @Donnanz: Go to Special:Preferences and you can change your skin under "appearance". You can also temporarily try a different skin by adding
- @Donnanz: On Vector 2022, the default TOC is always visible so you get the best of both worlds. Ioaxxere (talk) 16:26, 29 September 2024 (UTC)
- Ironically, it's not so good for an English entry with multiple headings. You can't choose a section (from the TOC) as you could before. DonnanZ (talk) 16:00, 29 September 2024 (UTC)
- @Ioaxxere: Is there a limit on the number of letters in a word? I tried it with over and strand, but nothing happened. DonnanZ (talk) 12:34, 30 September 2024 (UTC)
- @Donnanz: Those entries have 12 and 11 language sections respectively, so the template is invisible to users of the Vector skin. I've added a note to the documentation. That's just how I set it up — it can be changed if we'd like. Ioaxxere (talk) 00:11, 1 October 2024 (UTC)
ISO dab mislabeled; unicase Latin letters called "symbols"
[edit]If we enter 'ISO' in the {lb} tag, it's converted to the generic "international standards". However, ISO frequently contrasts with other international standards. For example, at ṛ, the ISO definition contrasts with the IAST definition. Both are international standards, but currently one is labeled "IAST" while the other is labeled just "international standards". Could we restore the ISO tag to its actual meaning?
Also, at that same article, the letters of IAST and ISO transliteration fall under the heading "letter", while the letters of NAPA and UPA transcription fall under the heading "symbol". They're all alphabetic letters; the only difference is that NAPA and UPA are unicase, while ISO and IAST are, sometimes, cased. ISO and IAST are also often unicase, because they transliterate unicase scripts, but there is an allowance for capital forms. That is, however, the only effective difference, and we don't call the letters of unicase scripts like Georgian "symbols". Some languages are written only in the IPA, NAPA etc. alphabet, and it's weird to say they're written in "symbols". Shouldn't we just have two "letter" headers, one with casing and one without?
To be clear, IMO actual alphabetic symbols -- e.g. those like e and pi used in math, chemistry and the like -- should remain under the "symbol" heading, because they're not used as letters of an alphabetic script. kwami (talk) 09:21, 17 September 2024 (UTC)
This page is over 1MB in length, which is too big. I propose a three-way split:
- Requests for language splits/mergers/additions go to WT:RFLM = Wiktionary:Requests for language moves, mergers and splits.
- Requests not related to individual terms (i.e. non-mainspace, non-Reconstruction and non-Appendix-only-language pages such as categories, modules, templates, etc.) go to WT:RFMO = Requests for moves, mergers and splits/Others (compare WT:RFDO).
- Requests related to individual terms remain on WT:RFM.
Benwing2 (talk) 04:02, 18 September 2024 (UTC)
- Support 2 and 3. I support 1 in principle too; I feel the name is a little wordy, and I would like something like WT:Lect workshop, but since it's a request page, not a discussion room, this might not be so great. Maybe WT:Requests to rename, merge or split languages (you don't "move" a language) or simply WT:Language treatment requests (a la WT:LT). In any event I don't want to hold this effort up with petty disagreements; it's exactly these language discussions that make the RFM page so large, so they are the priority for moving off the page.
- While we're solving this issue, we should also deal with the issue that there is no natural place to archive language-oriented RFM discussions, yet archiving them for posterity is especially important. The current situation is that they are archived across WT:Language treatment/Discussions and Wiktionary talk:Language treatment/Discussions, but this is clearly unsustainable. I propose to resolve this issue by archiving completed discussions to yearly archive subpages of the new venue, such as WT:____/Archive/2024. We can't use yearly discussion subpages in the same manner as BP, because the request discussions need to be closed, handled and archived; it won't do if they silently disappear into oblivion at the end of each year. This, that and the other (talk) 05:10, 18 September 2024 (UTC)
- I can agree with not using "move" for the L2 discussion page. Vininn126 (talk) 20:21, 18 September 2024 (UTC)
- @Benwing2: I don't really care too much but I oppose doing this on the basis of page size alone, because that can easily be resolved by just archiving old discussions (why are there still conversations from 2015?). Also keep in mind that Wiktionary:Request pages will get really crowded with an additional column. Ioaxxere (talk) 19:53, 18 September 2024 (UTC)
- Some conversations from 2015 are still unresolved. I don't think we should archive unresolved discussions even if they're 10 years old. Benwing2 (talk) 19:56, 18 September 2024 (UTC)
- See also the open RFM discussion about splitting language discussions off onto their own page. — excarnateSojourner (ta·co) 06:06, 22 September 2024 (UTC)
- I strongly support splitting, and I don't care much how it's done. I would also support creating a threshold for archiving very old, stale, and unresolved RFM discussions. If a discussion is, say, six years old with no comments within the last year, it's unlikely to receive new information / perspectives that would influence the outcome. But as long as I don't have to wait for my laptop to load a megabyte of markup I'll be happy. — excarnateSojourner (ta·co) 06:06, 22 September 2024 (UTC)
- I support splitting up the page. I also like the name "Language treatment requests". Einstein2 (talk) 19:56, 23 September 2024 (UTC)
- I started splitting up into Wiktionary:Requests for language moves, mergers and splits, in the only way I know i.e. sloppily! Denazz (talk) 15:35, 25 September 2024 (UTC)
- I split some more. Someone might want to edit Wiktionary:Request pages.Denazz (talk) 20:38, 25 September 2024 (UTC)
- I moved WF's creation to Wiktionary:Language treatment requests = WT:LTR in keeping with Vininn's and Einstein2's comments (and my own). This, that and the other (talk) 04:57, 26 September 2024 (UTC)
- I split some more. Someone might want to edit Wiktionary:Request pages.Denazz (talk) 20:38, 25 September 2024 (UTC)
I've largely avoided bringing this up since I frankly didn't have the energy, but I've seen one too many entries now. I'd like to start a discussion about whether or not we should include Reddit as a source for WT:CFI. Right now, it's been included de facto mainly because CFI has essentially stopped being enforced for online quotes (the main people who did are either inactive or have been overwhelmed or don't care anymore), but looking at entries like j*et (etym 2, sense 2), I'm very averse to having any entry that's solely based upon Reddit quotes. Reddit is much more anonymous than, for example, Twitter, and there's little to actually verify if each account is an individual person. The content is also not durable. 3 Reddit users is simply not enough for us to be including a word; it starts to harm our credibility and comes off as honestly unserious, becoming the likes of Urban Dictionary with some of the recent terms.
The last time this was brought up was at Wiktionary:Beer parlour/2022/September § Reddit, where the vote was 9-9, which meant that it shouldn't have been included by default, but again enforcement hasn't really been a thing. As such, I want to open up the discussion again. AG202 (talk) 05:22, 18 September 2024 (UTC)
- That being said, I would be okay with Reddit quotes showing usage, providing that there's ample evidence that it's not a complete nonce word (ex: references, much more than 3 quotes, etc.). AG202 (talk) 05:26, 18 September 2024 (UTC)
- I'd be OK with preventing Reddit from being an exclusive source of quotes. But I don't like the idea of just outright banning it. I added a slang term at one point (slang senses of dead) which was pretty well unciteable apart from Reddit and Twitter (and very difficult to find cites for on Twitter). Yet I hear and see this sense all the time in real life (texting, conversations) among my peers. A lot of slang just slips through the cracks if you're not able to use internet sources, so until there's an alternative, I'd prefer that we be generous in what we include. Andrew Sheedy (talk) 05:35, 18 September 2024 (UTC)
- Well yes, I'm not saying that we should ban it. I will say though that that particular example has been around for quite some time (I've used it since at least 2017 after checking my texts), and shouldn't be hard to find at all in other media, let alone Twitter. It's mentioned in this 2021 CNN article, this 2023 USA Today article, this 2022 The Atlantic article, and used in this CharlotteWeekly artice, for example. There's even a cite in the OED (no paywall) for this term. There's definitely no need for Reddit here, and I'm more so surprised that we didn't have it before considering how widespread it is, though maybe that's a sign. AG202 (talk) 05:52, 18 September 2024 (UTC)
- @AG202: I don't think Reddit should count for CFI in general. But CFI states that "a term should be included if it's likely that someone would run across it and want to know what it means", and this is clearly met for jeet. But if the issue is Reddit specifically, then we could find quotes from other websites as well. Generally I try to add a mix of Reddit and Twitter citations since both sites are easily searchable and archivable. Ioaxxere (talk) 19:46, 18 September 2024 (UTC)
- The issue is Reddit specifically for me. If the aforementioned word is something that folks would run into then it's gotta have quotes outside of Reddit as well. AG202 (talk) 13:24, 19 September 2024 (UTC)
Reddit is an important tool for attesting fandom and video game slang. For all its flaws, Reddit seems to be the last mature, widely used, and openly accessible social-media platform. There's a decent built-in search function on the site that can be used to find quotes. Plus Reddit is indexed by Google and will likely remain so in the near term. The fact that Reddit is generally used for casual discussion also makes it an ideal source for quotes. I had a lot of success finding short illustrative quotes on Reddit. That's just not as easy to do on Tumblr. Tumblr's search functionality is basically non-existent, and the site's text content tends toward cryptic in-jokes and long essays. Reddit also potentially has some safeguards against linkrot. AFAIK you can't change account or subreddit names. Comments are also preserved after account deletion unless manually deleted beforehand. Whereas on Twitter and Tumblr, links can break with account name changes, as well as with account deletion or suspension. More broadly, I'd argue that Reddit is a modern-day Usenet. Wiktionary needs to keep pace with the evolving landscape of social media to document new and emerging language. The vast majority of fandom slang never makes it into print publications. I found it wasn't uncommon for fandom slang with a decade-plus history on Reddit to have zero hits on Google Books, Google Scholar, Issuu, etc. Sometimes the search needs to start where language is actually being used. WordyAndNerdy (talk) 08:01, 18 September 2024 (UTC)
- I agree with you all, but I agree with the status quo as well for the given reasons, since you don’t and won’t have a particular formulation that will find agreement, because precisely we have come close enough to include what we should include without being gameable by three Reddit usernames. The inclusion criteria always have been about what usage is there and not about what three quotes are shown on the front. Sometimes you don’t take a quote even from a book if it is the heading of a table or the context is too confusing or extensive for the quote to be read by anyone or the isolated sentence is misleading factually or politically. When we have a word with three Reddit quotes or three Twitter quotes or three Telegram quotes or whatever it is just for example, after which the editor called it a day, it is understood that one site is not enough like a word from the universe of one videogame is not enough. I don’t find it more ambiguous than is apt. Fay Freak (talk) 08:58, 18 September 2024 (UTC)
- I think Reddit should be a less broad analog to the "clear widespread use" clause. The main problem with Reddit is independence: as I said before when we first discussed using social media, you sometimes have the equivalent of a group of friends who hang out together in school and develop their own in-group vocabulary. The idea is to find a way to filter out the in-group stuff for narrow groups and look for the terms that people use not because it's part of participating in the specific group but because that's the way they talk online in general. I'm not sure exactly how to implement it, but that's the idea. Chuck Entz (talk) 13:58, 18 September 2024 (UTC)
- Exactly the above. Also @WordyAndNerdy: I get what you're saying and I do think Reddit is useful; I just think that we need more stringent criteria. 3 usages is not enough. Also, I would be against deleted accounts being counted for CFI (unless we're able to find the original account and cite that), as that completely goes against our criteria for independent usages from different people. AG202 (talk) 16:44, 18 September 2024 (UTC)
- These concerns have come up in discussions about Usenet. The "independent" clause in CFI applies to authors. It doesn't apply to publishers. Attesting an entry with cites from a single newsgroup or subreddit would be like attesting an entry with only New York Times articles. Sometimes terms are restricted to a specific community. Warhammer slang is easier to find on /r/warhammer40k than on cute animal subreddits. I usually gathered "extra" cites as a personal practice. But one needn't go out of their way as I did. Only derogatory terms and limited documentation languages are held to different standards under CFI. Three cites should be enough for attesting English slang off Reddit if it's enough to attest marketing buzzwords.
- CFI's one-year requirement is effective at filtering out most nonsense. It's more difficult than one might expect to make fetch happen. Friend groups often lack the dedication and/or social cohesion necessary to push in-jokes/protologisms into wider use. This is not a problem encountered with any regularity in the wild. Bored kids will try dropping their coinages directly onto Wiktionary and move on when they're rejected (perhaps after a bit of feet-stomping). Few if any will go to the trouble of creating three Reddit sockpuppets and letting their comments age a year. And if anyone actually wants to play that kind of 4D chess it would be entirely possible for them to game protologisms onto Wiktionary with two friends and three letters to local newspapers.
- As for deleted accounts, this seems no different from including quotes from anonymous authors, articles without bylines, etc. There can never be 100% forensic certainty that any three quotes are from three different people. However, it's often possible to infer authorship from style, timestamps, discussion flow, etc. on Reddit. "Deleted_account" replying to "ILoveGarfield82" multiple times in a single chain can reasonably be assumed to be the same user. There won't be many instances in which the only quotes available are from a deleted account anyway. Reddit's karma system disincentivizes account deletion and anything that meets the one-year provision of CFI is almost guaranteed to have been used by more than one person. WordyAndNerdy (talk) 20:24, 18 September 2024 (UTC)
- "These concerns have come up in discussions about Usenet." I've told you before that I've been openly against our Usenet criteria, but I stopped bringing it up because it's simply not worth it. Also, derogatory terms aren't really held to a different standard in terms of the number of cites. They only require that cites be provided in a timely manner.
- "As for deleted accounts, this seems no different from including quotes from anonymous authors, articles without bylines, etc." I don't think we include (and I wouldn't support either way) quotes from anonymous authors for CFI anyways? And you know that sending three letters to local newspapers is way harder than just leaving 3 comments on Reddit. AG202 (talk) 13:23, 19 September 2024 (UTC)
- I thought we did, in some instances? There are famous texts where we don't know who made it, like medieval manuscripts. CitationsFreak (talk) 05:14, 21 September 2024 (UTC)
- Note: I'm specifically referring to the provision in CFI that requires that a text come from 3 different authors for attestation purposes. Not the inclusion of anonymous quotes, which is perfectly fine. I just don't see how we can count, for example, 3 anonymous comments from a website and say that they're definitively 3 different people. AG202 (talk) 03:23, 24 September 2024 (UTC)
- There is no way to know with absolute certainty that any three quotes were written by three different people. It's true that we can't definitively prove that three Reddit comments weren't made by one user with two socks. But we also can't know with 100% empirical certainty that Shakespeare quotes aren't actually Christopher Marlowe quotes. Wiktionary's purpose is to document language. Attributing the authorship of texts falls outside that remit. We don't need to approach Reddit citations with the rigour of mainline historians debunking anti-Stratfordian claims. Distinct usernames are usually sufficient evidence of authorship. We can't know with absolute empirical certainty whether best-selling authors have secret pen names or rely on uncredited ghost-writers. The potential for uncertainty exists in print media too. Getting tangled up in such questions doesn't seem helpful to Wiktionary's mission. WordyAndNerdy (talk) 04:32, 24 September 2024 (UTC)
- Note: I'm specifically referring to the provision in CFI that requires that a text come from 3 different authors for attestation purposes. Not the inclusion of anonymous quotes, which is perfectly fine. I just don't see how we can count, for example, 3 anonymous comments from a website and say that they're definitively 3 different people. AG202 (talk) 03:23, 24 September 2024 (UTC)
- It's fine to quote anonymous or unknown authors. There's a provision for anonymous authors in quote templates. Entering "anon" in the "author" field will transclude as "anonymous author." This isn't just relevant to Reddit posts. There's ancient manuscripts by authors forgotten to time; Victorian novels published pseudonymously (think Currer Bell, but unidentified) or anonymously ("a lady"); decades of letters to agony aunts from "Frustrated by My In-Laws" etc. All of these can be valuable sources of quotes. WordyAndNerdy (talk) 02:44, 24 September 2024 (UTC)
- I thought we did, in some instances? There are famous texts where we don't know who made it, like medieval manuscripts. CitationsFreak (talk) 05:14, 21 September 2024 (UTC)
- The "three quotes" criterion doesn't apply to online sources. When a term without durably archived attestations is brought to RFV, widespread online usage needs to be demonstrated through a discussion). Einstein2 (talk) 13:11, 22 September 2024 (UTC)
- This was discussed two years ago. There was no consensus for selectively requiring additional cites for Reddit or Twitter. I'm guessing there was more support for Twitter than Reddit at the time because few foresaw just how fast and hard Twitter would fall. Google stopped "durably archiving" Usenet posts in February of this year. The archive is still accessible but no posts past that date will be preserved. Wiktionary needs to understand and work with the media ecosystem as it exists in 2024. The continual re-litigation of this topic is incredibly frustrating. It's hamstringing Wiktionary's ability to document language. WordyAndNerdy (talk) 03:18, 24 September 2024 (UTC)
- I agree. CitationsFreak (talk) 03:37, 24 September 2024 (UTC)
- "There was no consensus for selectively requiring additional cites for Reddit or Twitter." The actual vote was for allowing Twitter or Reddit cites to count towards CFI on their own, both of which ended in no consensus, with Reddit having an equal number of votes for and against. Thus, per a simple reading of that vote, Reddit shouldn't be included by default, which honestly is what I'm trying to get at. I just want there to either be a full-fledged discussion about Reddit ending in a proper policy, but until then, our current policy needs to be enforced, rather than the laissez-faire attitude that we've had recently where close to none of our policies have been enforced. AG202 (talk) 10:00, 24 September 2024 (UTC)
- This is a monkey paw situation. I would also prefer clear policy to unwritten rules. But the status quo is better than nothing. Wiktionary sometimes needs to reference websites to document online slang. Relying on print media means Wiktionary will always be lagging five-to-ten years behind everyone else. And it will create weird gaps in coverage, like having a large, up-to-date collection of incel slang while we don't have popular gaming slang, fandom slang, trans community slang, etc. That's because there's been a bunch of academic articles and theses on the incel movement. It seems like the only fandoms to generate multiple academic papers in the past decade have been Sherlock and MLP. I wish more Wiktionarians with direct personal experience of the logistics involved in attestation would contribute to these conversations. WordyAndNerdy (talk) 08:35, 30 September 2024 (UTC)
- "There was no consensus for selectively requiring additional cites for Reddit or Twitter." The actual vote was for allowing Twitter or Reddit cites to count towards CFI on their own, both of which ended in no consensus, with Reddit having an equal number of votes for and against. Thus, per a simple reading of that vote, Reddit shouldn't be included by default, which honestly is what I'm trying to get at. I just want there to either be a full-fledged discussion about Reddit ending in a proper policy, but until then, our current policy needs to be enforced, rather than the laissez-faire attitude that we've had recently where close to none of our policies have been enforced. AG202 (talk) 10:00, 24 September 2024 (UTC)
- I agree. CitationsFreak (talk) 03:37, 24 September 2024 (UTC)
- This was discussed two years ago. There was no consensus for selectively requiring additional cites for Reddit or Twitter. I'm guessing there was more support for Twitter than Reddit at the time because few foresaw just how fast and hard Twitter would fall. Google stopped "durably archiving" Usenet posts in February of this year. The archive is still accessible but no posts past that date will be preserved. Wiktionary needs to understand and work with the media ecosystem as it exists in 2024. The continual re-litigation of this topic is incredibly frustrating. It's hamstringing Wiktionary's ability to document language. WordyAndNerdy (talk) 03:18, 24 September 2024 (UTC)
- Exactly the above. Also @WordyAndNerdy: I get what you're saying and I do think Reddit is useful; I just think that we need more stringent criteria. 3 usages is not enough. Also, I would be against deleted accounts being counted for CFI (unless we're able to find the original account and cite that), as that completely goes against our criteria for independent usages from different people. AG202 (talk) 16:44, 18 September 2024 (UTC)
- Agree (although mayyybe there should be a way to ensure that there are three people using the term.) CitationsFreak (talk) 03:10, 19 September 2024 (UTC)
Let us differentiate between content words (obviously the topic of interest in this discussion) and function words/alternative forms. There are various such colloquial features I have only been able to attest using Reddit, and I propose that a three-cite rule be uncontroversially applied to Reddit aources in cases which do not fall under internet slang/fandom terminology. ―Biolongvistul (talk) 14:38, 22 September 2024 (UTC)
- @Biolongvistul Could you perhaps provide some examples where you think this more lenient rule should be applied? Einstein2 (talk) 20:00, 23 September 2024 (UTC)
- If it's reliable for alt forms, it's reliable for other terms. CitationsFreak (talk) 20:17, 23 September 2024 (UTC)
- This seems like it's proposing a two-tier application of CFI based on the subjective assessment that Internet slang and fandom slang (two distinct but overlapping areas of language) are not "content words." WordyAndNerdy (talk) 03:30, 24 September 2024 (UTC)
- What I think the proposal is saying is that words with actual meanings, like "rizz" would not count for CFI, but alternative spellings, like "colour" would. CitationsFreak (talk) 03:39, 24 September 2024 (UTC)
Hello,
An audio for "on drugs" is on my Lingua Libre, and I'm aware this entry used to exist but was deleted. This term is defined in a few other online dictionaries such as Merriam-Webster and Oxford Languages. If I can find quotations of this prepositional phrase being used, then is it ok to put it back online?
Thank you. "Don't talk to me." 💔 Flame, not lame (talk) 23:58, 18 September 2024 (UTC)
- It was not deleted for lack of quotations, it was deleted because it’s sum of parts. If you know of an idiomatic sense, you can reopen the deletion discussion. MuDavid 栘𩿠 (talk) 01:18, 19 September 2024 (UTC)
- No thank you. "Don't talk to me." 💔 Flame, not lame (talk) 02:22, 19 September 2024 (UTC)
Classical Nahuatl entries and vowel length
[edit]I am not fully sure how this works in mainspace since I have tended to mostly work on reconstructions so far, but I've noticed an issue with Classical Nahuatl entries in that their page names do not possess the diacritics to note vowel length, and the templates such as {{m|
, {{l|
and {{cog|
do not detect any long vowel when used.
Given that this present situation causes issues, such as when noting that a term uses -tlan vs -tlān, can the page names, modules and templates for Classical Nahuatl be updated to better handle entries with long vowels? Antiquistik (talk) 07:22, 19 September 2024 (UTC)
- Were macrons present in Classical Nahuatl texts from the era when it was spoken, or are they only added in modern scholarly editions? When diacritics are only added in scholarly or pedagogical recensions, Wiktionary usually only displays the macrons in 'display text' (the displayed headword, or the displayed text of a link like -tlān) but not in the titles of the pages themselves (which instead match the diacriticless way the language was actually/contemporarily written). For example, Latin -ēs and -es are on one page, because they were both spelled -es in Latin, though modern scholars add diacritics to note vowel length; the situation is the same with Old English. Hence, I believe the current behavior is intended. Of course, it isn't some law of physics, we could make an exception, but is there compelling reason to? For example, do most modern Nahuan languages write macrons in everyday writing? A cursory search of Nahuan languages we have entries on suggests not...? - -sche (discuss) 07:03, 20 September 2024 (UTC)
- @-sche The macrons were added only in modern editions. However, Classical Nahuatl itself did not use the Latin script, and it had its own pictographic and logosyllabic script, which seems to complicate the situation since we have an extinct language that was written in its own script before its extinction but which is currently written using macrons. Antiquistik (talk) 10:58, 21 September 2024 (UTC)
-
(U+0x2D) in IPA transcriptions
[edit]Currently marked as an invalid IPA character. See this PetScan query for entries currently in Category:IPA pronunciations with invalid IPA characters, which is mostly entries which are marked as such because of -
. @theknightwho says that they're marked as invalid because of being outside the brackets. Does this reflect something which should be enforced or has this not been discussed? -saph668 (user—talk—contribs) 07:10, 22 September 2024 (UTC)
- @saph668 I've looked through several of the entries in the category and didn't see any that used a hyphen. Has someone cleaned them up? Or can you give an example that uses a hyphen? — excarnateSojourner (ta·co) 02:35, 2 October 2024 (UTC)
- I think some change happened to MOD:IPA. I included the PetScan to show what was in the category at the time but I forgot it runs every time you open the link. -saph668 (user—talk—contribs) 09:41, 2 October 2024 (UTC)
Proposal to add other Quechuan languages
[edit]I've noticed there is only an general entry for "Quechua". However, this label represents many different subvarieties that can and are often considered languages in their own right. So, something akin to Wiktionary's entries for "Arabic" and "Southern Levantine Arabic", "Egyptian Arabic", "Moroccan Arabic", etc. How do I add these languages? (They do have ISO codes, by the way.) SantiChau23 (talk) 01:25, 23 September 2024 (UTC)
- there have been multiple conversations about splitting Quechua, the last time I believe there was hang up regarding what was a dialect or a language etc. I cannot find the previous conversation again but I seem to remember @Thadh and @Theknightwho being involved in the discussion. — BABR・talk 06:44, 23 September 2024 (UTC)
- See WT:Beer parlour/2023/September#Splitting Quechua Thadh (talk) 07:08, 23 September 2024 (UTC)
- Just FYI, IIRC there was agreement that Quechua should be split but disagreement over how to split it. Some were proposing a 44-way split based on Ethnologue codes; others (e.g. me and User:-sche) don't believe such a split is workable and proposed a split into fewer varieties (something like 5-12 depending on the proposal). In any case IMO these language-splitting discussions should happen in one centralized place and not necessarily in the BP; currently they often happen in WT:RFM but that page is too big and needs splitting (see the recent BP thread on this). One proposal is to have a dedicated page for language treatment discussions; this would cover splits, mergers, renames, etc. of languages. Benwing2 (talk) 21:44, 24 September 2024 (UTC)
- Right, so how should I go forward with this? I mean, I gather it isn't clear how many ways it should be split, but I'm sure there's agreement on at least some varieties. I don't see why there is such opposition when we have these Arabic dialects right there. I don't know where to start a new discussion on this, but a simple agreement of some should do. For future reference, I think we should model the splits based on how linguists split the family pragmatically. I mean, for example, Quechua linguists agree on the existence of Wanka Quechua and Ancash Quechua as different varieties of Central Quechua —there are no "Central Quechua" dictionaries. Nor are there different Shawsha Quechua and Waylla Quechua dictionaries —they're subsumed under "Wanka". I know no decision will be agreed upon 100% by everyone: I mean none is perfect for any language. But that doesn't mean that we shouldn't create these submodules.
- I propose guiding ourselves, as a start, with the Six Quechua Grammars and Dictionaries created by the Ministry of Education of Peru in 1976, composed by the leading Quechua researches, just mentioning the inclusion of Cerrón-Palomino and Parker. These would be Áncash-Huailas (maybe under the label "Ancash Quechua"), Junín-Huanca (maybe under "Wanka Quechua"), San Martín (maybe under "San Martín† Quechua"), Cajamarca-Cañaris, and of course there's already consensus that Ayacucho-Chanca and Cuzco-Collao should be unified under "Southern Quechua" by Wikilexicographers and Quechua linguists alike (cf. Diccionario sureño unificado by Cerrón-Palomino and more recently Diccionario quechua sureño by Itier). I think it's a good start and other varieties can be later discussed and added on. I don't see why the well-agreed upon "Ancash Quechua" should be stalled by the disagreement over if Standard Kichwa exists or not, and vice-versa. Plus, this way we ensure that people are able to locate terms as they can easily consult these dictionaries or plenty on that have been modelled on these and that there is greater consensus over the splitting of the languages. I don't think we should come here and "prove" the mutual intelligibility or separateness of the languages since this is a problem as well for well-versed PhD-having experts who, you know, publish academic papers about the minute details over the differences. Not that that should have any impact on the creation of dictionaries. This also solves the "44 or 1 language" reduction, as we're only adding 4 new varieties, two of which have significant speaker populations and written traditions (Ancash and Wanka), with their own published official alphabets and working dictionaries and (small) language academies.
- (Tagging some people of the other discussion: @Thadh, @Theknightwho, @User:AG202, @Vininn126, @Benwing2). SantiChau23 (talk) [†: corrected from original) 03:36, 25 September 2024 (UTC)
- @SantiChau23 This sounds generally fine with me but we should get agreement from the above people as well as User:-sche. Note also that one of my concerns for creating 44 new L2 languages is that in my experience, language splits are significantly easier than language merges to implement, so I would rather err on the side of fewer splits and then create more as needed, rather than the other way around. Also as for your post in the Grease Pit, I can help you add labels for different Quechua varieties; just give me a list of all the varieties in question, and for each variety, (a) the place(s) where the variety is spoken (ideally with Wikipedia links to these places), and (b) any Wikipedia articles on the specific variety (it's fine if they're in a different language, such as an article from the Spanish Wikipedia). In addition, if you think it makes sense to group individual varieties into subgroups, indicate the subgroups and which varieties go in them, and give the same info for each subgroup as for individual varieties (i.e. place(s) spoken and any Wikipedia articles on the subgroup). For an example of a language with lots of existing varieties grouped by subgroups, see Category:Varieties of Spanish (or Category:Varieties of English for that matter). Benwing2 (talk) 04:31, 25 September 2024 (UTC)
- BTW we can get started with adding the varieties now, even before splitting Quechua. In fact, one of the prerequisites to implementing a split is figuring out which language each term labeled "Quechua" actually goes under, and that often requires someone going through the existing Quechua terms and labeling each one appropriately, which could be done with the new variety labels we add. Benwing2 (talk) 04:34, 25 September 2024 (UTC)
- This sounds reasonable to me too, and seems to provide coverage of all the major branches. (Rereading the earlier discussion I apologize for how strident I was in it.) SantiChau23, to clarify, when you say
San Martín (maybe under "Huánuco Quechua")
, are you referring to the Quechua I → Central Quechua → Huánuco Quechua cluster referred-to here or the Quechua II → Northern Quechua → San Martín Quechua referred-to here? (Did you mean to write "Huarochiri" instead of "Huánuco"?) San Martín [Quechua] seems to be the most commonly used name for the latter cluster Glottolog's bibliography of works about it, followed by Huarochiri. (BTW presumably we'll later find ourselves adding codes for the 2-4 clusters of Central Quechua which are not in the above list — including Yaru/Tarma and Yauyos, which also have dictionaries — since unlike with the 'minor' varieties of the other branches, I'm not seeing any other obvious place to put them, if we're splitting up Central.) - -sche (discuss) 07:03, 25 September 2024 (UTC)- Yeah, whoops! I meant San Martín as in Lamista Quechua, so QII. I think I got it mixed up cuz I was thinking on varieties spoken along the Huallaga River. But yeah, San Martín under "San Martín Quechua"—I'll make a correction. In any case, I don't mind adding Yaru and Yauyos later on since, as you say, there are different dictionaries and we're splitting up Central in any case. I think there are other reasons why have them separate, such as the significant distinction in pronunciation and, again, different written traditions. This can be debated later on and see which is the best path to adding these varieties (maybe there are some dictionaries that consign them under one unified variety and which make sense). SantiChau23 (talk) 17:07, 25 September 2024 (UTC)
- This sounds reasonable to me too, and seems to provide coverage of all the major branches. (Rereading the earlier discussion I apologize for how strident I was in it.) SantiChau23, to clarify, when you say
- BTW we can get started with adding the varieties now, even before splitting Quechua. In fact, one of the prerequisites to implementing a split is figuring out which language each term labeled "Quechua" actually goes under, and that often requires someone going through the existing Quechua terms and labeling each one appropriately, which could be done with the new variety labels we add. Benwing2 (talk) 04:34, 25 September 2024 (UTC)
- @SantiChau23: How exactly do you propose to handle Ayacucho and Cuzco under one L2? Will you list all forms with boxes like
{{krl-regional}}
, or will you standardise on one variety, and which one? Because the existance of ejectives in Cuzco and the significantly different morphology were a major concern for me in the initial discussion. Thadh (talk) 09:54, 25 September 2024 (UTC)- The use of aspirated/ejective consonantes (hereinafter laryngealised) is a "recent" development in Cuzco-Bolivia Quechua, so all laryngealised consonants originally come from an unlaryngealised version, which is basically what Ayacucho has. Now, Cuzco Quechua, for example, distinguishes tanta (“collection”) vs. thanta (“old, ragged”) vs. t'anta (“bread”); however, Ayacucho Quechua only has tanta (“bread”) with no other meanings. That is to say, Ayacucho speakers don't (seem to) use tanta to mean "ragged" or "collection". Another point to have in mind on laryngealisations is that they're very variable apparently. Just to quote Lingüística quechua (2003: 119): "Not only is there no regular correspondence between the aspirates in Ecuadorian [Quechua] and those of Cuzco [Quechua]; nor are there always [correspondences] among the Cuzco and Bolivian cognates in terms of the laryngealised [consonants]: even within the same area, and even within the same speaker, there is great variation". Maybe this can also explain why some user included pach'a instead of the usual p'acha that is found in the dictionaries (or it could also be a misinformed entry and it actually doesn't exist). Mind you: there are only some items that laryngealisation results in a three-way distinction. Most other times it just creates a differing pronunciation of the words. For instance, allpa (“soil, earth”) is the exact same thing as hallp'a and there are no *hallpa or *hallpha. Note that sometimes there are only two-way distinctions, such as t'ika (“flower”) and tika (“baking mould; adobe”).
- Given this, I think what should be done is treat laryngealisation as alternative forms of the unlaryngealised words, only for words with the same meaning. I'll give an example:
- _____(1: main entry = non-laryngealised)_____
- Quechua
- Etymology 1
- Pronunciation
- Noun
- tanta
- bread
- Synonym: t'anta (Cuzco-Collao)
- Etymology 2
- Pronunciation
- IPA(key): /ˈtan.ta/
- (Cuzco-Collao) IPA(key): [ˈtan.ta]
- IPA(key): /ˈtan.ta/
- Noun
- tanta
- Pronunciation
- Usage notes
- The word tanta ("bread") is laryngealised in Cuzco-Collao varieties, distinguishing it from the terms tanta ("collect") and thanta ("old, ragged") not found in the Ayacucho variety.
- _________________________________________
- ___[below: a different entry page]___
- _________________________________________
- Quechua
- Pronunciation
- IPA(key): /ˈtʰan.ta/
- (Cuzco-Collao) IPA(key): [ˈtʰan.ta]
- IPA(key): /ˈtʰan.ta/
- Noun
- thanta
- Usage notes
- This word is only found in Cuzco-Collao. For similar words, see tanta and t'anta.
- _________________________________________
- ___[below: a different entry page]___
- _________________________________________
- Quechua
- Pronunciation
- IPA(key): /ˈtʼan.ta/
- (Cuzco-Collao) IPA(key): [ˈtʼan.ta]
- IPA(key): /ˈtʼan.ta/
- Noun
- t'anta
- (Cuzco-Collao) Alternative form of tanta.
- Usage notes
- This word is only found in Cuzco-Collao. For similar words, see tanta and thanta.
- __________
- In here we can see that there are two entries for tanta: one (Etym. 1) for the meaning of "bread", universal among all Southern Quechuas, and another (Etym. 2) for the meaning of collection, which is only found in the Cuzco-Collao varieties. An explanation under Usage notes is further given. Now, if we don't agree in this, I'm open to doing what's always been done and that is treat the Ayacucho forms as alternatives of the Cuzco-Collao forms, which are already differentiated. Thus, a second alternative gives:
- _____(2: main entry = laryngealised)_____
- Quechua
- Pronunciation
- Noun
- t'anta
- _________________________________________
- ___[below: a different entry page]___
- _________________________________________
- Quechua
- Pronunciation
- IPA(key): /ˈtan.ta/
- (Cuzco-Collao) IPA(key): [ˈtan.ta]
- IPA(key): /ˈtan.ta/
- Noun
- tanta
- (Cuzco-Collao) collection
- (Ayacucho) Alternative form of t'anta
- Usage notes
- The Cuzco-Collao varieties have a three-way distinction between tanta ("collect"), thanta ("old, ragged") and t'anta ("bread"). On the other hand, Ayacucho-Chanca only has tanta with no laryngealisation and only with the meaning "bread", having other terms for differentiated words in Cuzco-Collao.
- __________
- Now, for the terms that are exactly the same, I propose uniting them under the older, undifferentiated form since that is what it is (i.e option 1). However, I'm not opposed to Option 2, because at the end of the day it's something more about how to organise them rather than a significant hurdle. So for a word like allpa vs. hallp'a that mean exactly the same always just consign it under allpa with both pronunciations and have hallp'a redirect to that (as it's done already). The previous examples also work for two-way distinctions: grouping either under t'ika and have Ayacucho as the variant or have tika and Cuzco-Collao as the variant.
- As can be seen, the matter is only in relation to where is the main entry (the largynealised or non-laryngealised) should be. The same can be said based on the morphological features. I imagine you mean suffixes such as -q/-pa vs. -pa, but then again we can include them under a same entry, and give one as the variation, such as how it's done now under -p and same thing for -nchik (with -chis as variant), etc. This is my initial proposal, I think it's sensible to choose form one of these two options or build upon them. SantiChau23 (talk) 17:01, 25 September 2024 (UTC)
- I can see option 1 working, but only with marking the differentiated forms as alternative forms instead of synonyms. However, that does open up the question whether we are in fact creating a kind of "Standard Quechua" here that is not in use - I'd think most Cusco written forms would either consistently or at least semi-consistently (based on their own speech) differentiate between t'ana, thana and tana, whereas no Ayacucho text or speaker would ever use the former two spellings for writing their speech.
- Option 2 I can't see working at all, for the reason given above; If a Cusco speaker could forego diacritics and digraphs (although I'm doubtful they would), an Ayacucho speaker can't predict features of a language they don't speak. Thadh (talk) 18:24, 25 September 2024 (UTC)
- I don't think this qualifies as creating a kind of "Standard Quechua". We're not mandating speakers to write in any way nor use language in any way. We're simply grouping the lemmas under one form. Similar to how Wiktionary is not mandating English speakers or creating a sort-of "Standard English" closely related to the American varieties because the main entry for honor is under the American <-or> spelling and redirects users of many varieties from honour. It's basically saying these are regional realisations of a same form, which is absolutely true. As I say, I'm all for Option 1, I see it making sense for speakers and serves both Cuzco-Collao and Ayacucho speakers well. SantiChau23 (talk) 20:23, 25 September 2024 (UTC)
- So, I think everyone so far thinks this proposal is sensible. How can we start implementing this split then? @Thadh@Benwing2@-sche@Babr SantiChau23 (talk) 15:29, 2 October 2024 (UTC)
- Hi, looking for an update on this Quechua situation. @Thadh @Benwing2 @-sche @Babr SantiChau23 (talk) 14:25, 30 October 2024 (UTC)
- @SantiChau23 This sounds generally fine with me but we should get agreement from the above people as well as User:-sche. Note also that one of my concerns for creating 44 new L2 languages is that in my experience, language splits are significantly easier than language merges to implement, so I would rather err on the side of fewer splits and then create more as needed, rather than the other way around. Also as for your post in the Grease Pit, I can help you add labels for different Quechua varieties; just give me a list of all the varieties in question, and for each variety, (a) the place(s) where the variety is spoken (ideally with Wikipedia links to these places), and (b) any Wikipedia articles on the specific variety (it's fine if they're in a different language, such as an article from the Spanish Wikipedia). In addition, if you think it makes sense to group individual varieties into subgroups, indicate the subgroups and which varieties go in them, and give the same info for each subgroup as for individual varieties (i.e. place(s) spoken and any Wikipedia articles on the subgroup). For an example of a language with lots of existing varieties grouped by subgroups, see Category:Varieties of Spanish (or Category:Varieties of English for that matter). Benwing2 (talk) 04:31, 25 September 2024 (UTC)
- Just FYI, IIRC there was agreement that Quechua should be split but disagreement over how to split it. Some were proposing a 44-way split based on Ethnologue codes; others (e.g. me and User:-sche) don't believe such a split is workable and proposed a split into fewer varieties (something like 5-12 depending on the proposal). In any case IMO these language-splitting discussions should happen in one centralized place and not necessarily in the BP; currently they often happen in WT:RFM but that page is too big and needs splitting (see the recent BP thread on this). One proposal is to have a dedicated page for language treatment discussions; this would cover splits, mergers, renames, etc. of languages. Benwing2 (talk) 21:44, 24 September 2024 (UTC)
Rename Proto-Ossetic and Old Ossetic
[edit]I used the name Proto-Ossetic, which includes the Sarmatian dialect of Alanic, because that's what's found in the literature, but sometimes Proto-Ossetic is also used for the stage in-between the Old Ossetic language Alanic and Ossetian, while Proto-Pre-Ossetic is used in its place. To help disambiguate the confusion, I'd like to rename:
- Proto-Ossetic
[os-pro]
to Proto-Sarmatian[xsc-sar-pro]
- Old Ossetic
[oos]
to Alanic[xln]
@-sche, Antiquistik --{{victar|talk}}
08:00, 24 September 2024 (UTC)
- No objections from me regarding this. Antiquistik (talk) 09:05, 24 September 2024 (UTC)
- @-sche, is this something you have the time to do? --
{{victar|talk}}
04:34, 1 October 2024 (UTC)- Sorry, I've been looking for but haven't been able to find enough information about these stages of these languages to feel like I can add much to this discussion. (I presume the changes themselves would best be done by someone with a bot, unless the number of affected pages, categories, etc is very small.) The only observation I can make is that while on the face of it "Proto-Sarmatian" does seem clearer about its scope, I've only spotted one book using "Proto-Sarmatian": is it used in literature? If "Proto-Ossetic" is the usual name found in the literature, using a different name could be more confusing rather than less. (But that hasn't stopped us from renaming some other lects...) - -sche (discuss) 15:16, 3 October 2024 (UTC)
- @-sche: There aren't many entries -- 4 Proto-Ossetic lemmas and 9 Old Ossetic lemmas -- so the moves could be done manually. The proto prefix is often omitted in the literature, ex. "Sarmatian *βōr (POss. *bor) from *babru-", but as Sarmatian is unattested and exists as a language continuum, it should be labeled Proto-Sarmatian. Sometimes, it's also referred to as pre-Proto-Ossetic, as much of the literature is written from an Ossetian-centric perspective, with Proto-Ossetic used for the direct ancestor of the Ossetian dialects. It's admittedly all a bit messy, but I believe these suggested changes offer the most clarity. --
{{victar|talk}}
19:54, 3 October 2024 (UTC) - @-sche: Just shooting you another ping. --
{{victar|talk}}
02:24, 13 October 2024 (UTC)- OK, I've added
xsc-sar
Proto-Sarmatian;os-pro
can be removed once orphaned ([2]). I addedxln
to the 'full languages' module (and removed it from the 'etymology-only languages' module); would you prefer to orphanoos
and have that code removed from our infrastructure entirely, or to have it made an etymology-only variant of xln (reversing the previous arrangement of the two codes)? - -sche (discuss) 01:52, 14 October 2024 (UTC)- @-sche: The latter, could you make
oos
as etymology-only variant ofxln
? I also just realized I should have asked make the code for Proto-Sarmatian[xsc-sar-pro]
. 🤦 Could you change that as well? Thanks. --{{victar|talk}}
06:26, 14 October 2024 (UTC)- OK. (My bad, too, for not catching that either!)
Can you make whatever changes are needed to the Old Ossetic entries (move and recode them to Alanic?) and figure out how Category:Old Ossetic reference templates should be (re?)categorized? Then the code can be moved, I think.
(Actually, Category:Terms derived from Old Ossetic by language was formerly timing out after I initially moved the codes, which I didn't expect, because AFAICT its name should stay the same even if oos is ety-only, so something unexpected appears to have gone wrong and I undid my change to oos for now. Possibly the fact that I didn't quickly enough update xsc-sar in Module:languages/code to canonical name was causing a problem somehow?...) - -sche (discuss) 19:24, 18 October 2024 (UTC)- @-sche, Victar: there are module errors at робас, рувас, and یل that are related to this, and the consistency checks on the language data modules are showing related problems. Chuck Entz (talk) 21:17, 18 October 2024 (UTC)
- Thanks for pointing that out. I think I've fixed the ones (that I could find) which were due to the xsc-sar → xsc-sar-pro change. The ones having to do with Alanic not being an ancestor I think I've temporarily patched by setting oos's ancestor to xln; once the entries and reference templates etc which use oos are updated, the code can be switched to being an ety-only variant of xln. - -sche (discuss) 16:51, 19 October 2024 (UTC)
- Thanks, @-sche! --
{{victar|talk}}
18:29, 19 October 2024 (UTC) - @-sche, Victar That fixed some things and broke others. I made os-pro an ancestor of oos and made xln an ancestor of os-pro. That should temporarily fix everything until we can orphan os-pro and set oos back to having xln as ancestor. I also created the redlinked CAT:Alanic language. Feel free to adjust/improve. Chuck Entz (talk) 00:55, 20 October 2024 (UTC)
- Thanks, @-sche! --
- Thanks for pointing that out. I think I've fixed the ones (that I could find) which were due to the xsc-sar → xsc-sar-pro change. The ones having to do with Alanic not being an ancestor I think I've temporarily patched by setting oos's ancestor to xln; once the entries and reference templates etc which use oos are updated, the code can be switched to being an ety-only variant of xln. - -sche (discuss) 16:51, 19 October 2024 (UTC)
- @-sche, Victar: there are module errors at робас, рувас, and یل that are related to this, and the consistency checks on the language data modules are showing related problems. Chuck Entz (talk) 21:17, 18 October 2024 (UTC)
- OK. (My bad, too, for not catching that either!)
- @-sche: The latter, could you make
- OK, I've added
- @-sche: There aren't many entries -- 4 Proto-Ossetic lemmas and 9 Old Ossetic lemmas -- so the moves could be done manually. The proto prefix is often omitted in the literature, ex. "Sarmatian *βōr (POss. *bor) from *babru-", but as Sarmatian is unattested and exists as a language continuum, it should be labeled Proto-Sarmatian. Sometimes, it's also referred to as pre-Proto-Ossetic, as much of the literature is written from an Ossetian-centric perspective, with Proto-Ossetic used for the direct ancestor of the Ossetian dialects. It's admittedly all a bit messy, but I believe these suggested changes offer the most clarity. --
- Sorry, I've been looking for but haven't been able to find enough information about these stages of these languages to feel like I can add much to this discussion. (I presume the changes themselves would best be done by someone with a bot, unless the number of affected pages, categories, etc is very small.) The only observation I can make is that while on the face of it "Proto-Sarmatian" does seem clearer about its scope, I've only spotted one book using "Proto-Sarmatian": is it used in literature? If "Proto-Ossetic" is the usual name found in the literature, using a different name could be more confusing rather than less. (But that hasn't stopped us from renaming some other lects...) - -sche (discuss) 15:16, 3 October 2024 (UTC)
- @-sche, is this something you have the time to do? --
ID parameter in etymon
[edit]As of now, {{etymon}}
has |id=
set as mandatory and it gives an error without if the ID is not entered. However, for the vast majority of entries, there is only one etymology section and thus for most cases I have seen till now, the ID is completely redundant and inconvenient to type in all such entries. Also, for multiple senses under the same etymology, it often becomes difficult to remember what exactly was the ID chosen. Bringing the discussion at Module talk:etymon to light,
- Ioaxxere said:
Yes, the ID system isn't really needed in the case of single-etymology entries, but it makes the template more robust in cases when we need to add an etymology section or maybe move an entry to another page.
- To which I replied:
it is hard to type it out on every page and always keep in mind which ID was asigned especially for multiple senses under the same etymology, so that's why I think it would be nicer if it can be avoided for obvious cases where there is almost zero probability that there would be another etymology section in future. And in case there is, we could probably just type it out later when the other etymology section is being added and update all associated pages, like we would have to do anyway under the present system.
- Therefore, my proposal is that we should do away with IDs on strictly single-etymology entries and retain them in cases that do require them like multiple-etymology entries, which would save a lot of unnecessary manual labour.
Since this is likely to be brought up. Example:
{{etymon|en|from|foo>TERM>redundantID}}
(current) vs{{etymon|en|from|foo>TERM}}
{{etymon|en|from|foo>TERM}}
will by default be interpreted asfoo
being a langcode and TERM as the single-etymology entry in the language whose langcode isfoo
, iff foo is a valid langcode{{etymon|en|from|foo>TERM}}
will by default be interpreted as English word entryfoo
with IDTERM
if "foo" is not a language code.- In the very rare instance that the language code foo exists as well as an actual word foo and here we want foo to be interpreted as a word, this could be solved by writing something like
{{etymon|en|from|foo>redundantID}}
where the redundantID is the ID of the English entry at "foo" and there exists no entry at redundantID of the language foo.
Again, this would be an extremely rare occurrence if at all, and even writing this paragraph I feel I am giving more importance to this issue than is actually needed.
Pinging some other users for more, Ioaxxere, Theknightwho, AryamanA, Kutchkutch, Fenakhay, Benwing2, Vininn126, Babr, Trooper57. Svartava (talk) 08:17, 25 September 2024 (UTC)
- I think instead it should check if the pointed-to entry has multiple etymologies and request to clarify which. However, if a term is later split from one etymology to two, then any entries pointing to it will need updating. There will be a need for a way to track that. Vininn126 (talk) 08:55, 25 September 2024 (UTC)
- @Vininn126: Regardless of how entries with multiple etymologies are handled, do you support getting rid of IDs for entries with only one etymology? Svartava (talk) 09:03, 25 September 2024 (UTC)
- In would obviously be more convenient if we have a fail-safe for etymology splitting. I'm not sure how easily that could be implemented. Vininn126 (talk) 09:04, 25 September 2024 (UTC)
- @Vininn126: So the only issue is with etymology splitting. Making the template
check if the pointed-to entry has multiple etymologies and request to clarify which
look like the perfect solution for this. - Another important point: According to this search result, of the 2300+ entries using
{{etymon}}
, only 60 have multiple etymologies, which further proves how massively redundant is|id=
in most cases. Svartava (talk) 10:13, 25 September 2024 (UTC)- So if we split an entry to have multiple entries, any page pointing to that will then be added to a request category requesting an ID? Vininn126 (talk) 10:16, 25 September 2024 (UTC)
- @Vininn126: Yes, assuming the module will be able to detect that the pointed-to entry has more than one etymologies under the same ==Language== header. If that is able to be achieved, adding a tracking category for the same would be easy. Svartava (talk) 10:21, 25 September 2024 (UTC)
- So if we split an entry to have multiple entries, any page pointing to that will then be added to a request category requesting an ID? Vininn126 (talk) 10:16, 25 September 2024 (UTC)
- @Vininn126: So the only issue is with etymology splitting. Making the template
- In would obviously be more convenient if we have a fail-safe for etymology splitting. I'm not sure how easily that could be implemented. Vininn126 (talk) 09:04, 25 September 2024 (UTC)
- @Vininn126: Regardless of how entries with multiple etymologies are handled, do you support getting rid of IDs for entries with only one etymology? Svartava (talk) 09:03, 25 September 2024 (UTC)
- An "auto-ID" for single etymologies would be interesting. You not only have the issue of remembering what ID you used, but also knowing what people have put in other pages. I recently fixed an ID that didn't match between panis and *peh₂- and wasn't categorizing any page. Trooper57 (talk) 13:35, 25 September 2024 (UTC)
- Oppose - it's far safer to just add an ID when you make the page than to expect another user to add the correct IDs when they add a second etymology section (since I can guarantee the vast majority of people won't do that). Especially given they would be expected to update all pages which point to that page, which they definitely won't do. This just seems like a recipe for creating a ton of messiness, all for the sake of not coming up with an ID, which is really not worth it in my view. Theknightwho (talk) 14:20, 25 September 2024 (UTC)
- It's arguable there will be less of a mess, because pages linked to pages with a single etymology won't need to all be updated if there's ever a change (not that that happens often, but it actually reduces the margain of error as there's less need for manual input). Vininn126 (talk) 14:58, 25 September 2024 (UTC)
- @Vininn126 One way to prevent issues with that is to have
{{etymon}}
raise a warning if a given ID doesn't exist on the target page, which will allow us to keep track of any changes like that. What's much harder is to be checking if multiple etymologies exist in an entry, and then updating all the entries, because additional etymologies will be added far more often than IDs will get changed. Theknightwho (talk) 15:09, 25 September 2024 (UTC)
- @Vininn126 One way to prevent issues with that is to have
- It's arguable there will be less of a mess, because pages linked to pages with a single etymology won't need to all be updated if there's ever a change (not that that happens often, but it actually reduces the margain of error as there's less need for manual input). Vininn126 (talk) 14:58, 25 September 2024 (UTC)
- Support - I've made this suggestion before. I'm unconvinced that the hypothetical possibility of future etymology splits is important enough to add this inconvenience to each use of the etymon template, given that other templates such as Template:affix don't mandate the use of an ID. It's usually quite feasible to fix any errors that arise by means of occasional manual oversight of categories such as Category:French terms suffixed with -oire, etc. Etymologies can become out of date for various reasons, so there's no way to completely avoid the need to have editors occasionally revisit and update etymologies: I don't think dealing with newly-split etymologies will constitute an excessive or unmanageable amount of maintenance work. If the solution that Theknightwho proposed is technically possible (checking whether a given ID exists on the target page), I wonder if the following alternative proposal could be implemented: allow the ID to be omitted only if there are no IDs in the relevant language section on the target page, but require an ID to be used if there are preexisting IDs in the language section on the target page.--Urszag (talk) 19:43, 25 September 2024 (UTC)
- @Urszag Is adding an ID really an inconvenience..? We already insist on this for translations. The whole point is that it's not much work to do in the first place, but a big pain to have to retroactively change a bunch of entries after the fact, even if it only affects a minority of entries. There's also the fact that requiring an ID if there are multiple etymologies means that adding a new etymology might result in a ton of other entries suddenly raising errors/causing issues. I would be really pissed off if I had to correct errors on 17+ pages simply because I added a new etymology to Dutch thee, for example, all because we insisted that it was too much work to take a few seconds to add an ID in the first place, and even if have
{{etymon}}
not raise errors, there's a good chance the other entries will start showing wrong info. It's a total false economy (see technical debt). This is also not like IDs on other templates: the big difference is that these are chained together and potentially affect a large number of other entries, so it's important to have them be set once and then never changed. Theknightwho (talk) 19:48, 25 September 2024 (UTC)- I have found the ID requirement annoying and I know I've made id errors (where the id doesn't match the one on the actual page) at times, and have seen such errors made by other editors (meaning the status quo does not only prevent some kinds of errors, but also causes some). It's often not especially intuitive what the id should be, and in cases where more than one possibility is reasonable, you need to manually check (but sometimes people just guess and potentially get it wrong). Another difficulty is that since some parts of an etymology chain might have been created earlier by someone else, they might have used a different id for an earlier stage of the same etymon, which leads to a type of inconsistency that makes it more difficult to remember the correct id for each language stage. Inconsistency also arises if you use a straightforward translation for the ancestors of a term, but then are banned from using that same id for English since you can't use a word as its own id. For example, in the case of solstice I decided to use the id "day" since we cannot use "solstice" as its own id: for consistency with the English id, I also used this as the id for solstitium, although "solstice" would be more straightforward. Leaving out an id would have been easier, and I think the additional ease would have been worth the risk that we one day discover a new, unrelated etymology of "solstitium" and forget to ever update the etymologies of the derived terms.--Urszag (talk) 20:08, 25 September 2024 (UTC)
- @Urszag Errors which are raised immediately and can be corrected are completely different from erorrs which are inadvertently propagated across lots of entries because of doing something ostensibly correct (i.e. adding a new etymology to an entry). The issues you point out are problems that aren't fixed by doing away with IDs; they're simply problems being caught as they happen, rather than silently existing and causing wrong information to flow down to other entries until someone eventually notices. Theknightwho (talk) 20:25, 25 September 2024 (UTC)
- As I said, I've seen such id errors made by other users, meaning they aren't invariably caught immediately. (Mismatching ids is a 'silent' error in that it doesn't trigger any error message: you would have to notice that the etymology tree is missing ancestors beyond a certain etymon, and it isn't always obvious if this is because the wrong id was used or because no etymology had been created yet for this etymon.) In the case of affix entries, adding a new etymology has already required updating the affix template in the derived terms: e.g. when Category:Latin terms suffixed with -icius was split by adding ids for Category:Latin terms suffixed with -icius (long) and Category:Latin terms suffixed with -icius (short), each entry needed to be updated to use the correct suffix id. It doesn't seem to have created insurmountable difficulties.--Urszag (talk) 20:34, 25 September 2024 (UTC)
- @Urszag Again, that's because it doesn't propagate the issue through to a bunch of other entries immediately. If you add a second etymology to Dutch thee, you would immediately cause issues on all of its descendant entries. This problems is magnified even more for anything involving Latin or PIE, for instance. It's much, much easier to catch ID issues straight away than it is to retroactively change lots of other entries after the fact, because people aren't going to go out of their way to do that when they've added a new etymology section. Theknightwho (talk) 20:51, 25 September 2024 (UTC)
- My solution for this would be that if the pointed-to entry has multiple etymologies and no ID is given, the etymology section containing
{{etymon}}
specifically without the ID is taken into consideration, along with the tracking category requesting the addition of a proper ID. I'm not sure if this is technically feasible though. - If we be meticulous in keeping the tracking category empty, it is still much less an effort than writing unneeded IDs on a very large number of pages. I'd even support
{{etymon}}
showing a module error in such cases as that would make sure editors take the effort to fix the related pages - and honestly, as shown by the above search result, it seems much less an effort to update five related pages than write an unneeded ID on ten times more number of pages. Svartava (talk) 20:36, 25 September 2024 (UTC)- Alternatively, we can atleast make
{{etymon}}
just go blank or non-functional in such a case of multiple etymologies not having IDs if what I said is not feasible technically. This would prevent any error from being propagated until IDs are added and the issue is resolved. Svartava (talk) 20:42, 25 September 2024 (UTC)- @Svartava Which means that you could potentially break (or truncate) etymologies on tens of entries if this problem happens high up in the tree, like with Sanskrit or PIE. The easiest way to prevent that problem from happening is to just have the IDs there in the first place. This is a textbook example of technical debt. Theknightwho (talk) 20:53, 25 September 2024 (UTC)
- @Theknightwho: The point about PIE and Sanskrit is definitely quite valid. However, I still believe that such a problem would be a rather rare occurrence in practice even though we are considering that scenario quite heavily.
- The solution I propose is: yes, let the etymologies get truncated on a bunch of entries than let them go wrong, along with the tracking cat. The ideal situation for us would be to maintaining the tracking cat to be empty (or very minimally filled) in all situations, similar to how CAT:E is treated. Adding IDs to a bunch of related pages listed in the tracking cat because of a recent addition of a new etymology section, can easily be done (semi-)automatedly, if the user who adds the new entry just assigns ID to the previously written etymology section as well. (If they don't know how to do that, they are probably also not using
{{etymon}}
in the etymology section they added, in which case{{etymon}}
could continue functioning as before but with the tracking cat requesting ID.) Svartava (talk) 21:05, 25 September 2024 (UTC) - I would like to know about the feasibility of the other solution I proposed:
if the pointed-to entry has multiple etymologies and no ID is given, the etymology section containing
. This would probably solve most of the situations similar to those you are writing about above. Svartava (talk) 21:09, 25 September 2024 (UTC){{etymon}}
specifically without the ID is taken into consideration, along with the tracking category requesting the addition of a proper ID
- @Svartava Which means that you could potentially break (or truncate) etymologies on tens of entries if this problem happens high up in the tree, like with Sanskrit or PIE. The easiest way to prevent that problem from happening is to just have the IDs there in the first place. This is a textbook example of technical debt. Theknightwho (talk) 20:53, 25 September 2024 (UTC)
- Alternatively, we can atleast make
- As I said, I've seen such id errors made by other users, meaning they aren't invariably caught immediately. (Mismatching ids is a 'silent' error in that it doesn't trigger any error message: you would have to notice that the etymology tree is missing ancestors beyond a certain etymon, and it isn't always obvious if this is because the wrong id was used or because no etymology had been created yet for this etymon.) In the case of affix entries, adding a new etymology has already required updating the affix template in the derived terms: e.g. when Category:Latin terms suffixed with -icius was split by adding ids for Category:Latin terms suffixed with -icius (long) and Category:Latin terms suffixed with -icius (short), each entry needed to be updated to use the correct suffix id. It doesn't seem to have created insurmountable difficulties.--Urszag (talk) 20:34, 25 September 2024 (UTC)
- @Urszag Errors which are raised immediately and can be corrected are completely different from erorrs which are inadvertently propagated across lots of entries because of doing something ostensibly correct (i.e. adding a new etymology to an entry). The issues you point out are problems that aren't fixed by doing away with IDs; they're simply problems being caught as they happen, rather than silently existing and causing wrong information to flow down to other entries until someone eventually notices. Theknightwho (talk) 20:25, 25 September 2024 (UTC)
- I have found the ID requirement annoying and I know I've made id errors (where the id doesn't match the one on the actual page) at times, and have seen such errors made by other editors (meaning the status quo does not only prevent some kinds of errors, but also causes some). It's often not especially intuitive what the id should be, and in cases where more than one possibility is reasonable, you need to manually check (but sometimes people just guess and potentially get it wrong). Another difficulty is that since some parts of an etymology chain might have been created earlier by someone else, they might have used a different id for an earlier stage of the same etymon, which leads to a type of inconsistency that makes it more difficult to remember the correct id for each language stage. Inconsistency also arises if you use a straightforward translation for the ancestors of a term, but then are banned from using that same id for English since you can't use a word as its own id. For example, in the case of solstice I decided to use the id "day" since we cannot use "solstice" as its own id: for consistency with the English id, I also used this as the id for solstitium, although "solstice" would be more straightforward. Leaving out an id would have been easier, and I think the additional ease would have been worth the risk that we one day discover a new, unrelated etymology of "solstitium" and forget to ever update the etymologies of the derived terms.--Urszag (talk) 20:08, 25 September 2024 (UTC)
- I don't really see how
{{affix}}
really applies here. I think if it were possible to create a non-resource-intense category requesting an ID in the case of multiple etymologies then it'd be fine. Vininn126 (talk) 19:50, 25 September 2024 (UTC)- Currently Template:affix places words into categories such as Category:French terms suffixed with -oire; in cases such as this where there are multiple distinct affixes spelled the same way, this category is supposed to be empty as all terms should be placed in the id-defined subcategories Category:French_terms_suffixed_with_-oire_(adjective), Category:French terms suffixed with -oire (feminine noun), Category:French terms suffixed with -oire (masculine noun). But there is no requirement for an id if there is only one affix.--Urszag (talk) 20:08, 25 September 2024 (UTC)
- @Urszag Is adding an ID really an inconvenience..? We already insist on this for translations. The whole point is that it's not much work to do in the first place, but a big pain to have to retroactively change a bunch of entries after the fact, even if it only affects a minority of entries. There's also the fact that requiring an ID if there are multiple etymologies means that adding a new etymology might result in a ton of other entries suddenly raising errors/causing issues. I would be really pissed off if I had to correct errors on 17+ pages simply because I added a new etymology to Dutch thee, for example, all because we insisted that it was too much work to take a few seconds to add an ID in the first place, and even if have
- I do think, as TKW pointed out, this creates a situation where someone has to constantly look out for etymons that don't have an ID and fix them. That seems a bit... undesirable. It would be nice though, if etymon could automatically generate a code, similar to the Wikidata codes we use for
{{tcl}}
(which aren't automatic generated but still). Personally, I would be fine with putting the etymon ID as e.g. Q789H, especially as it would allow me to use the same ID for all descendants regardless of semantic changes. — BABR・talk 02:53, 26 September 2024 (UTC) - I'd like to start off by mentioning that IDs are (sometimes) used in category names and thus should at least be somewhat coherent. To use @Urszag's example, a category like "solstice (solstice)" is absurd and that's why IDs can't be the page name. Automatically generated IDs would be a good opportunity for a bot job — maybe feed the entry into an LLM — but I don't have the resources to make this happen.
- Now @Theknightwho has argued pretty persuasively as to why not having IDs would be a huge maintenance headache. The only thing I would add: "tens of entries" might be "thousands" if the term were as prolific as Latin cum, for example. Thankfully, that entry was given an ID from the start and the headache is thus avoided.
- My question to @Svartava is what should happen if the template doesn't use an ID, and runs into an ambiguous case. Should it...
- Throw an error?
- Fail silently?
- Try to guess?
- Svartava suggested having a maintenance category, and cleaning these cases up as soon as possible. I'm not convinced that we can rely on the community to do that, especially considering the steady growth of Category:Entries referencing etymons with invalid IDs. And it doesn't seem fair to have a system where users can break things willy-nilly and someone else has to clean up the mess.
- Ioaxxere (talk) 04:40, 27 September 2024 (UTC)
- @Ioaxxere: I would actually think the growth of Category:Entries referencing etymons with invalid IDs is due to the reason others have stated above, that people can't remember what ID they wrote for what term or are not mindful of what some other editor did. Sometimes, people don't take the pain to always go back to successive entries and add
{{etymon}}
's to them. So if anything, this category would shrink down due to this. - For the solution if the template runs into an ambiguous case:
- In all the above three, I propose the tracking category be generated for cleanup. Svartava (talk) 04:52, 27 September 2024 (UTC)
- @Svartava These are not equivalent errors, though:
- If I add a bad ID to entry A when trying to connect it to
{{etymon}}
on entry B, that only affects entry A. Yes, it could propagate down the chain if I change the ID, but that isn't something people should be doing (and I don't see the incentive, either). - With your proposed solution, entry A could be completely correct, but adding a second etymology to entry B will cause problems for entry A when it tries to connect to
{{etymon}}
. This is extremely unintuitive, because (a) adding a new etymology usually doesn't involve{{etymon}}
, so it's not clear to most users why it would be affected, (b) even worse, the issues are caused on other pages, and (c) adding a new etymology is not itself a mistake, unlike adding a wrong ID. Together, this makes it extremely likely that the problem will get missed every time a new etymology is added.
- If I add a bad ID to entry A when trying to connect it to
- The workarounds you propose are problematic for a few reasons:
- Defaulting to the
{{etymon}}
without an ID just means that wrong information will get propagated down the chain, and again, users essentially have no way of knowing that will happen unless they check all the connecting entries (which they won't). - Truncating the chain just reduces the quality of the dictionary, all for the sake of a small perceived convenience.
- Defaulting to the
- Theknightwho (talk) 05:20, 27 September 2024 (UTC)
- @Theknightwho:
adding a new etymology usually doesn't involve
- So the workaround to{{etymon}}
[t]ake the etymology section containing
works, right? If there is no{{etymon}}
if there is only one{{etymon}}
on the page like many of the pages in the invalid ID category, no information is truncated. - How does
[d]efaulting to the
?{{etymon}}
without an ID […] mean[] that wrong information will get propagated - There is an entry with only one etymology using
{{etymon}}
without an ID (if it already did have an ID then there is nothing to worry about anyway). - A user comes and adds another etymology.
- If they know how to use
{{etymon}}
: they add{{etymon}}
to the second etymology they added along with the ID, and first etymology remains without ID so defaulting to it would save the linked pages until the instance is tracked down by the category and fixed.- If the concern is that some other user adds
{{etymon}}
without ID on some page related to the second etymology - automatically, if the etymology defaults to the first one, wrong results will be displayed in the output tree or text, and{{etymon}}
can be made to warn if ID is not given when referring to a page with multiple etymologies.
- If the concern is that some other user adds
- If they don't know how to use
{{etymon}}
: they don't add it to the second etymology, so defaulting to the etymology containing{{etymon}}
(if only one), would work until the instance is tracked down by the category and fixed.
- If they know how to use
- Svartava (talk) 06:30, 27 September 2024 (UTC)
- @Svartava
- yes, it can, but that warning will be happening on other pages. Potentially lots of them. The one place the warning won't show is on the page which was actually changed, since it has no knowledge of any incoming links. This is exactly the problem I keep pointing out. Theknightwho (talk) 07:31, 27 September 2024 (UTC){{etymon}}
can be made to warn if ID is not given when referring to a page with multiple etymologies- @Theknightwho Yes, but the workarounds can work until the instances are fixed, as I just wrote above. They're not ideal but that is why I included the idea of a tracking category containing such entries.
Potentially lots of them
- yes, but among the few pages having this issue, I find that in most of them{{etymon}}
was added simultaneously in both the etymology section. Svartava (talk) 07:53, 27 September 2024 (UTC)
- @Theknightwho Yes, but the workarounds can work until the instances are fixed, as I just wrote above. They're not ideal but that is why I included the idea of a tracking category containing such entries.
- @Svartava
- @Theknightwho:
- @Svartava These are not equivalent errors, though:
- @Ioaxxere: I would actually think the growth of Category:Entries referencing etymons with invalid IDs is due to the reason others have stated above, that people can't remember what ID they wrote for what term or are not mindful of what some other editor did. Sometimes, people don't take the pain to always go back to successive entries and add
- The ID requirement is one of the major reasons I have not started using
{{etymon}}
. I'm not going to assign IDs to 100,000 Finnish words, mostly compounds, that are never going to have a second etymology. Asserting that this should be mandatory is absurd to me. — SURJECTION / T / C / L / 11:00, 28 September 2024 (UTC)- I'm surprised that's why. Would you use it were that not a requirement? Vininn126 (talk) 12:07, 28 September 2024 (UTC)
- No, it is not the only reason. — SURJECTION / T / C / L / 13:47, 28 September 2024 (UTC)
- I'm surprised that's why. Would you use it were that not a requirement? Vininn126 (talk) 12:07, 28 September 2024 (UTC)
- If we're going to use IDs, we need a way to look at them easily without checking the source manually. They should render somewhere on the page (maybe through an optional gadget). —AryamanA (मुझसे बात करें • योगदान) 09:37, 29 September 2024 (UTC)
Heading level 4 appearance
[edit]Currently on at least Vector, Vector-2022 and Minerva (default mobile skin), level 4 headings (h4, ====...====
) are essentially visually indistinguishable from level 5 headings (h5, =====...=====
). They both use the standard text size and are in bold (except the latter on Minerva). I would propose increasing the h4 font size to 110%, which is in between the current 100% and the 120% used by h3 (level 3 headings). Then we can also start bolding level 5 headings on mobile.
Here is a demonstration of what the changes would look like:
Vector before | Vector after |
---|---|
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Minerva before | Minerva after |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
— SURJECTION / T / C / L / 19:40, 25 September 2024 (UTC)
- Support — BABR・talk 19:41, 25 September 2024 (UTC)
- Support —Justin (koavf)❤T☮C☺M☯ 19:41, 25 September 2024 (UTC)
- Support — Fenakhay (حيطي · مساهماتي) 19:43, 25 September 2024 (UTC)
- Support əkrəm. 19:46, 25 September 2024 (UTC)
- Support, thanks. Svartava (talk) 19:53, 25 September 2024 (UTC)
- Support. Benwing2 (talk) 21:51, 25 September 2024 (UTC)
- Support. Vininn126 (talk) 21:53, 25 September 2024 (UTC)
- Support. - -sche (discuss) 22:22, 25 September 2024 (UTC)
- See also the same issue back in Jan 2023. — excarnateSojourner (ta·co) 22:02, 26 September 2024 (UTC)
- Past me is finally being vindicated after nearly 2 years 💔 — BABR・talk 04:08, 27 September 2024 (UTC)
- Support. I've been waiting on this since I started working here. AG202 (talk) 05:46, 27 September 2024 (UTC)
- Done — SURJECTION / T / C / L / 19:26, 27 September 2024 (UTC)
- H3's and H4's look quite close now. Perhaps a small increase in H3 size, or a small decrease in H4 size, could improve that situation.
Vector h3 120% h4 110% | Vector h3 125% h4 110% | Vector h3 120% h4 107% |
---|---|---|
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Minerva h3 120% h4 110% | Minerva h3 125% h4 110% | Minerva h3 120% h4 107% |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
Etymology 1
heading 3 above. lorem ipsum Numeral
heading 4 above. dolor sit amet Usage notes
heading 5 above. consectetur adipiscing elit |
- — SURJECTION / T / C / L / 19:43, 27 September 2024 (UTC)
- To me on my Mac OS (Ventura, i.e. 13.x), h4 at 110% looks very similar to h5 at 100%, and h4 at 107% is even worse. I'd consider increasing h3 to 125% and h4 to 112% or 113% to see if it will help distinguish h4 from h5 more. Benwing2 (talk) 04:02, 28 September 2024 (UTC)
- I have experimentally increased h3 font size to 125%. We'll see if anyone complains. — SURJECTION / T / C / L / 07:34, 28 September 2024 (UTC)
- I'm not a big fan of L3 headers now being so close in size to L2s, especially since the former are bold and the latter are not, but I suppose I will eventually get used to it. It just seems odd when an L3 "Alternative forms" section is almost more prominent than the name of the language. Andrew Sheedy (talk) 03:53, 1 October 2024 (UTC)
- I personally like it and have no problem with confusion between L2 and L3 headers, although that may partially be because I have Surjection's language link gadget turned on, so L2 language names show in blue and are clearly distinguished from L3 headers. Benwing2 (talk) 04:30, 1 October 2024 (UTC)
- I'm not a big fan of L3 headers now being so close in size to L2s, especially since the former are bold and the latter are not, but I suppose I will eventually get used to it. It just seems odd when an L3 "Alternative forms" section is almost more prominent than the name of the language. Andrew Sheedy (talk) 03:53, 1 October 2024 (UTC)
- I have experimentally increased h3 font size to 125%. We'll see if anyone complains. — SURJECTION / T / C / L / 07:34, 28 September 2024 (UTC)
- To me on my Mac OS (Ventura, i.e. 13.x), h4 at 110% looks very similar to h5 at 100%, and h4 at 107% is even worse. I'd consider increasing h3 to 125% and h4 to 112% or 113% to see if it will help distinguish h4 from h5 more. Benwing2 (talk) 04:02, 28 September 2024 (UTC)
- — SURJECTION / T / C / L / 19:43, 27 September 2024 (UTC)
- Support. Yes, probably h4 107 % looks better, too—and more conservative. Fay Freak (talk) 03:54, 28 September 2024 (UTC)
- I am unimpressed. Level 4 is now too close in size to Level 3. Can a different colour be used, like purple? DonnanZ (talk) 11:00, 17 October 2024 (UTC)
- Can't we use indentation to supplement (or replace) type-size distinctions of heading levels? DCDuring (talk) 14:36, 17 October 2024 (UTC)
Policies about Scots headwords
[edit]Scots does not have any standard orthography the way English does. This results in variant spellings for one word, compounded by dialectal pronunciations. How should we create policies about the headword of each Scots word? For reference, the major Scots dictionaries are A Dictionary of the Older Scottish Tongue (12 volumes, 1931-2002, Oxford University Press) and The Scots National Dictionary (10 volumes, Scottish National Dictionary Association, 1931-1976), both of which are reproduced online on the Dictionary of the Scots Language (DSL) by Dictionaries of the Scots Language. Other dictionaries include Concise Scots Dictionary (2nd ed, Edinburgh University Press, 2017) which is primarily based on A Dictionary of the Older Scottish Tongue and The Scots National Dictionary. YukaSylvie (talk) 08:26, 27 September 2024 (UTC)
- Courtesy link: Wiktionary:About Scots. —Justin (koavf)❤T☮C☺M☯ 10:58, 27 September 2024 (UTC)
- Thank you! I was unsure whether to post my question here on Wiktionary talk:About Scots. YukaSylvie (talk) 21:52, 27 September 2024 (UTC)
- Here will get more eyeballs, there will get the most relevant users. I recommend thread here, post on talk page there saying "See the thread at the Beer parlour". —Justin (koavf)❤T☮C☺M☯ 00:58, 1 October 2024 (UTC)
- Thank you! I was unsure whether to post my question here on Wiktionary talk:About Scots. YukaSylvie (talk) 21:52, 27 September 2024 (UTC)
'Wikidata item' link is moving. Find out where...
[edit]Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project. The Wikidata item sitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.
We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2.
More information can be found on the project page.
We welcome your feedback and questions.
MediaWiki message delivery (talk) 18:56, 27 September 2024 (UTC)
Can 'see also' be a primary heading?
[edit]If a 'see also' section is not for any particular language -- say a navigation template for symbols at the bottom of a page, can it be made a primary heading on level with the language entries, rather than subsumed under whichever language happens to be last?
I assume this is spelled out somewhere, I'm just not finding it. kwami (talk) 22:29, 28 September 2024 (UTC)
- Aren't symbols of that type Translingual? I didn't think a navigation template needed a heading. DCDuring (talk) 22:52, 28 September 2024 (UTC)
- A heading helps set it off visually. When the nav box is large, such as the one for braille, keeping it under 'translingual' at the top breaks up the entry and obscures the language-specific entries, because it looks like you've scrolled to the bottom of the article when you haven't. kwami (talk) 23:59, 28 September 2024 (UTC)
- Any examples? DCDuring (talk) 03:58, 29 September 2024 (UTC)
- Yes, ⠍, where I moved it down. You can see how the Japanese gets a bit lost otherwise at ⠿. kwami (talk) 04:04, 29 September 2024 (UTC)
- Any examples? DCDuring (talk) 03:58, 29 September 2024 (UTC)
- A heading helps set it off visually. When the nav box is large, such as the one for braille, keeping it under 'translingual' at the top breaks up the entry and obscures the language-specific entries, because it looks like you've scrolled to the bottom of the article when you haven't. kwami (talk) 23:59, 28 September 2024 (UTC)
- Currently all of our L2's are strictly limited to approved languages. So, no. — BABR・talk 23:06, 28 September 2024 (UTC)
- Right. Like DCDuring, I think "Translingual" is the logical place for this. - -sche (discuss) 23:06, 30 September 2024 (UTC)
- Yes, but the normal place for a large navigation template is at the bottom of the page. Any way to reconcile the two? kwami (talk) 23:10, 30 September 2024 (UTC)
- I'm not sure that's a correct assumption...? To me, it seems like the normal place for a large navigation template is at the bottom of the relevant language section, and indeed the relevant etymology division thereof. For example, on red the large list of links to other reds and the table of other colours is not only not at the bottom of the page, it's not even at the bottom of the English section. Similarly, gules's big table is above Catalan and Spanish. A user of Tabbed Languages won't even (automatically) see the contents of other language sections (unless they click to switch tabs), so if a Translingual-ly relevant table is put in the Japanese section on some entries, they won't even see it. - -sche (discuss) 00:45, 1 October 2024 (UTC)
- The last is a problem, definitely. I didn't know about that. But although 'translingual' makes the most sense if we had to pick just one, the template is just as relevant to every other language entry.
- Maybe it would be better on the right side, under the character info box? kwami (talk) 14:51, 1 October 2024 (UTC)
- Okay, I made it a collapsible box so it won't be so overwhelming and am returning it to the translingual section. kwami (talk) 06:28, 2 October 2024 (UTC)
- I'm not sure that's a correct assumption...? To me, it seems like the normal place for a large navigation template is at the bottom of the relevant language section, and indeed the relevant etymology division thereof. For example, on red the large list of links to other reds and the table of other colours is not only not at the bottom of the page, it's not even at the bottom of the English section. Similarly, gules's big table is above Catalan and Spanish. A user of Tabbed Languages won't even (automatically) see the contents of other language sections (unless they click to switch tabs), so if a Translingual-ly relevant table is put in the Japanese section on some entries, they won't even see it. - -sche (discuss) 00:45, 1 October 2024 (UTC)
- Yes, but the normal place for a large navigation template is at the bottom of the page. Any way to reconcile the two? kwami (talk) 23:10, 30 September 2024 (UTC)
- Right. Like DCDuring, I think "Translingual" is the logical place for this. - -sche (discuss) 23:06, 30 September 2024 (UTC)
Inter-language links for Korean suffixes
[edit]On English Wiktionary, most Korean suffixes entries are titled "-은", "-처럼" etc, but on most Wiktionaries of other language versions, those terms are usually titled without "-", e.g. ko:는. This leads to the page -는 has no inter-language links, and most languages versions of that entry does not have inter-language links to English Wiktionary. Is there a solution to that? 列维劳德 (talk) 09:38, 30 September 2024 (UTC)
- We could just remove the hyphens. There are other languages, such as Japanese, where our entries for affixes don't include hyphens. Binarystep (talk) 05:22, 14 October 2024 (UTC)
- I don't think this is necessarily a good solution. AFAIK the Korean editors (e.g. User:Tibidibi) prefer using hyphens in affixes, and there is in fact special support for having hyphens in translit but not in display. I think it should be possible to control the interwiki links through Wikidata entries or something; certainly, Wikipedia interlanguage links are handled through some sort of semi-manual mechanism that probably involves Wikidata. Benwing2 (talk) 05:31, 19 October 2024 (UTC)
- FWIW: when we had a similar issue with English vs French Wiktionaries using different apostrophes, we first solved it (in the days when interwiki links were added by bots checking for a page on every Wiktionary) by each wiki having a redirect from the form they didn't use (we lemmatized l'... with a redirect at l’..., fr.Wikt did the reverse). Such cases are now linked automatically by considering the characters equivalent. In theory, perhaps the same "Cognate" functionality could consider "hyphen string-initially when the rest of the string is Korean" and "absence of a hyphen" equivalent, but this would have undesirable side effects if any entries actually needed hyphens, so is not ideal. We could go back to the days of mass-creating redirects (for these entries) and/or adding interwiki links by bot (to these entries) where the bot would know to link hyphenated and hyphenless entries, but this requires other Wiktionaries to do likewise. Unless (as Binarystep says) we want to change how we handle Korean affixes, the solution is probably (as Benwing says) to allow some kind of 'semi-manual' crosslinking of specific entries to override the usual automatic way they're linked: either manual interwikis in the entries, or something on Wikidata. (That's also a more future-proof solution: sure, we could avoid it here if we just change how we handle Korean, but what if this comes up again with something we're not willing to change? It might also be worth looking into how (or whether!) the different characters that are used for palochkas and geresh/gershayim vs '," are crosslinked...) - -sche (discuss) 17:19, 19 October 2024 (UTC)
The root boxes were a bad idea?
[edit]Is it only me who finds it hard to orient amoung the etymologies for the root languages? I mean, Hebrew and Arabic, not the bock saga. I understand that it is a linguistical tradition to use root system for Semitic etymologies, because of the nature of semitic languages themself, when they are root languages.
But all these root-boxes are placed in a weird corner, and many of them do not even created, while many of the words have both etymology AND the root (see for example all the mess at אדום entry). In the same time, many of these root entries have no etymology either (see ث ق ل having no etymology, while its derived word ثقل has both root-box AND etymology).
If everybody think we should only use the root boxes insted of normal etymology system, than am gladly will help to sort out the Hebrew words at least into a root-box etymology system or whatever. But in this case, what we should do with the "Related terms" sections? They are completely useless if we use these root boxes (and we are using them already anyway, so this paradox bothers me even more). Tollef Salemann (talk) 15:31, 1 October 2024 (UTC)
- The related terms sections are useless, given that they clutter the page, though the benefit outweigh the burden in other languages, and the root system is a better system that centralizes Semitic related terms. The rootboxes are also necessary because otherwise the etymologies are trivial non-etymologies just having the purpose of stating a root. I do not share your impression of weird corners; אדום is a good example: the etymology sections contains actual words, the boxes the superficial structure by which we make relations and new words could be created. Fay Freak (talk) 11:08, 4 October 2024 (UTC)
Should the letters of phonetic alphabets be 'letters' rather than 'symbols'?
[edit]I've noticed this discrepancy for a while. I assume it's because phonetic alphabets are usually unicameral, and perhaps it's a pain to have two 'letter' entries under Translingual, one with case and one without. I bring this up because of Latin chi, ꭓ, which has a capital form in Unicode not because of any national orthography, but because it has a distinct capital in Lepsius's phonetic alphabet. We therefore need to link to the capital from the lower case and vice versa, which means that we now have symbols with orthographic casing.
If we have 'symbols' that are cased letters, and used to write languages, what's the difference between a 'symbol' and a 'letter'? Should IPA, NAPA, Lepsius and Teuthonista letters all be moved to under a 'letter' heading? And if so, should we have two separate 'letter' headings for casing and non-casing uses, or can that be handled with a usage note? Actually, IPA and NAPA are occasionally used with casing too, though that's uncommon where they haven't been adopted as the basis of a national orthography. For example, there's an IPA version of Alice in Wonderland that's printed with capitals, and because of it those were added to Unicode when they didn't already exist. But sometimes texts of otherwise unwritten languages are spelled out in a phonetic alphabet with casing.
Might it be possible to add a note of 'rare' after a capital variant we list in the heading for a phonetic alphabet? Something like this:
- Letter
ꭓ (upper case (rare) Ꭓ)
kwami (talk) 23:04, 2 October 2024 (UTC)
- IMO no. Logically, IPA symbols are symbols not letters. Some of them look like letters but not all. Some IPA symbols like ɔ are also letters in certain languages and then have cased forms, but IMO they should be treated separately. Benwing2 (talk) 00:00, 4 October 2024 (UTC)
- But what's the difference? Shouldn't the difference be one of function? Are casing Lepsius letters also 'symbols', or are they an exception because of casing? If it's casing, what about Georgian? And if it's appearance, what about the Hawaiian okina and the nasalization mark of Pe̍h-ōe-jī? Those cover the full range of IPA letters.
- I know dictionary definitions don't always make a good argument, but MW defines a 'letter' as a symbol usually written or printed representing a speech sound and constituting a unit of an alphabet. That would seem to include the IPA. kwami (talk) 01:10, 4 October 2024 (UTC)
- BTW, when IPA letters are used in national alphabets, they don't always have cased forms. Some of the orthographies are unicameral. kwami (talk) 01:49, 4 October 2024 (UTC)
- I disagree: a letter is a written character that represents a speech sound for spoken languages. While the "IPA" is not a language, the written characters do represent speech sounds, just like any letter in the Cyrillic or Greek or Latin alphabets do. —Justin (koavf)❤T☮C☺M☯ 01:43, 4 October 2024 (UTC)
Do not automatically expand all sections on mobile
[edit]In phab:T63447 ten years ago, Wikimedia sysadmins made the decision to enable a feature on the mobile version of the English Wiktionary that automatically expands all sections when a page is opened. The stated reason for this was that it "is pretty rough" when a page only has a single section (like English) and it is collapsed, forcing users to open it manually. However, this feature does not only act when the page only has a single section, but always. This
- makes pages with multiple language editions annoying to read
- makes long pages very slow
With pages that only contain a single section, we can easily implement a JavaScript feature ourselves that expands the section if there is only one. This cannot be done the other way around (collapse all sections), because it interferes with other logic (e.g. #English expands English automatically) and does nothing to address the slowdown caused by the browser having to render everything.
Therefore, I propose we seek community consensus to overturn this decision, which by itself seems to have been taken based on a small group of editors (most of whom were never particularly active on Wiktionary), and without discussion, let alone consensus, here on Wiktionary. — SURJECTION / T / C / L / 15:52, 3 October 2024 (UTC)
- Earlier discussions: Wiktionary:Information desk/2021/March#Always minimize all sections (mobile version), Wiktionary:Grease pit/2021/March#Wiktionary:Information desk/2021/March#Always minimize all sections (mobile version), Wiktionary:Grease pit/2021/June#Experience on mobile. — SURJECTION / T / C / L / 16:01, 3 October 2024 (UTC)
- I don't think people use their mobile phones much these daysDenazz (talk) 18:51, 3 October 2024 (UTC)
- Where are people not using mobile phones now? 77.18.59.30 20:36, 3 October 2024 (UTC)
- Denazz was being /s. I must admit I LOLd (non-/sly) when I read Denazz's comment. BTW, I support this proposal (non-/sly). Quercus solaris (talk) 22:18, 3 October 2024 (UTC)
- Where are people not using mobile phones now? 77.18.59.30 20:36, 3 October 2024 (UTC)
- I don't think people use their mobile phones much these daysDenazz (talk) 18:51, 3 October 2024 (UTC)
- Strong support. Of course having everything collapsed isn't great either, so I propose to have entries only expand the first section, whatever it may be (or it could be a more sophisticated thing that accounts for the height of each section — point being that it should be in our control). Ioaxxere (talk) 21:33, 3 October 2024 (UTC)
- Support. I could imagine for example a gadget that allows the user to customize which section(s) to open (e.g. open a specific language's section), but I agree this should be under our control. Benwing2 (talk) 23:55, 3 October 2024 (UTC)
- Support It is a PITA to use Wiktionary on mobile. — Fenakhay (حيطي · مساهماتي) 01:49, 4 October 2024 (UTC)
- Support This has always annoyed me. Stujul (talk) 10:08, 4 October 2024 (UTC)
- Weak support Has rarely annoyed me, but the rationale for the present setting only applies to Wikipedia and some other wikis but not the dictionaries. Fay Freak (talk) 11:13, 4 October 2024 (UTC)
- Strong support. This has annoyed me for a while. —Caoimhin ceallach (talk) 11:58, 4 October 2024 (UTC)
- Support. per Ioaxxare, always expanding the first section until another more sophisticated tool is created. Juwan (talk) 21:22, 5 October 2024 (UTC)
- Support. Theknightwho (talk) 23:41, 5 October 2024 (UTC)
- Support —AryamanA (मुझसे बात करें • योगदान) 07:29, 6 October 2024 (UTC)
- Strong support — सौम्य (talk) 14:31, 6 October 2024 (UTC)
- Support. IMO it should not always be the first section that is expanded, but the English section if available, and the first section if not (i.e. English should have precedence over Translingual). This is how Tabbed Languages currently works. — Vorziblix (talk · contribs) 23:33, 7 October 2024 (UTC)
- Support Binarystep (talk) 05:12, 14 October 2024 (UTC)
Show portlet links to logged-out users
[edit]On the mobile site, portlet links ("Discussion", "Citations") are not shown at all to logged-out users. This seems unfair. I think this is something that can be changed on the WMF's side, so I'm aiming to get consensus here and create a Phabricator task. Ioaxxere (talk) 21:40, 3 October 2024 (UTC)
- Support, seems a no-brainer. Benwing2 (talk) 00:00, 4 October 2024 (UTC)
- Support. Also find a way to display Citations when it exists, without the need for a gadget. — Fenakhay (حيطي · مساهماتي) 01:51, 4 October 2024 (UTC)
- Support, I've wanted this for some time (and it's been a discussed problem for some time: I recall it coming up in some long-prior discussions about the utility of ====Quotations==== headers, and I brought it up in the recent vote about them). Weirdly, it seems to be device dependent (?), because if I view the mobile version of a page from a computer, I do see a "Citations:" link at the top, but I don't see it if I view the page from an actual mobile device. (I did just find that if I click the "last edited..." link at the bottom of the page, and go to the page history, I do see a link to the Citations page at the top of that page, but having to click through to an intermediary page is a faff.) - -sche (discuss) 05:10, 4 October 2024 (UTC)
- Support Fay Freak (talk) 11:09, 4 October 2024 (UTC)
- Support —AryamanA (मुझसे बात करें • योगदान) 07:29, 6 October 2024 (UTC)
- Support Binarystep (talk) 05:13, 14 October 2024 (UTC)
- Support This would clearly be helpful. -BRAINULATOR9 (TALK) 04:48, 16 October 2024 (UTC)
- Support Juwan (talk) 10:52, 18 October 2024 (UTC)
Opposite synonyms
[edit]The adj utter means extreme and used with words with negative connotation; the adj. sublime also means extreme/complete, but used for positive connotations.
Is there a label for this type of relationship? Should they be added under the section "synonyms? JMGN (talk) 11:34, 6 October 2024 (UTC)
- Although utter is not used exclusively with negative connotation (e.g., utter joy, utter bliss), no doubt there are some adjectives that are exclusively positive or negative in this way. I can't think of any metalanguage for this particular phenomenon, but I wouldn't be surprised if linguists have a name for it, because it reminds me of things such as some#Determiner versus any#Determiner, either versus neither (which some call an "assertive determiner" versus a "negative determiner"), and positive anymore, all of which linguists have metalanguage for, albeit not carved in stone. I would say yes, they should be added under synonyms, because a short label can be appended to them such as "exclusively negative" or "exclusively positive", or "chiefly negative" or "chiefly positive", or "negative counterpart" versus "positive counterpart", which would be both clear enough and succinct enough. Quercus solaris (talk) 00:55, 8 October 2024 (UTC)
Please take a minute to look at the Pronunciation section at ârbros. I am not sure if it is the greatest piece of amateur lexicography since Thesaurus:penis/translations, or a massive stinking piece of misleading shit. Thoughts? Denazz (talk) 20:30, 6 October 2024 (UTC)
- I don't think this is garbage. This is @Nicodene's work in conjunction with @Kc kennylau, based on various dialect dictionaries. Benwing2 (talk) 23:43, 7 October 2024 (UTC)
- I suppose I should be flattered. Nicodene (talk) 01:11, 8 October 2024 (UTC)
- I wish that there was less pronunciation immediately shown, but damn. Should be FWotD based on that section alone. CitationsFreak (talk) 04:39, 8 October 2024 (UTC)
- Wow! That's exactly what we need to get for Norwegian! Currently, we've only got only some few examples like Norwegian Nynorsk furu, and they are very far from being fullfilled, especially compared to this example. Tollef Salemann (talk) 16:43, 8 October 2024 (UTC)
Can someone explain what is going on here? I was under the impression that within a certain language community at a certain place and time the pronunciation of words was more or less fixed. Is my understanding wrong or is Franco-Provencal different? Say I want to know how to say the word for "trees" in the dialect of Valais, am I to conclude that I can pronounce it however I damn well please? —Caoimhin ceallach (talk) 07:41, 8 October 2024 (UTC)
- The areas in question are highly mountainous, meaning essentially each village had its own pronunciation. Valais is not a village but a canton containing lots of villages, so you can't logically talk about a single "Valais" pronunciation. Franco-Provençal seems somewhat extreme in the variation you see, but a similar situation pertains to Rhaeto-Romance, where again each village tends to have its own pronunciation. I think that even within the 7 or so identified "dialects" of Swiss Rhaeto-Romance (which generally go per valley), there are further subvariations in different villages in the same valley. Benwing2 (talk) 07:58, 8 October 2024 (UTC)
- Ok, that makes sense. Do you agree though that the way the section is organised makes it appear like those pronunciations belong to a single dialect? Maybe it's a work in progress and I imagine it's a tricky thing to sort out, but a long list of pronunciations that aren't tied to a specific time and place isn't very useful. —Caoimhin ceallach (talk) 09:24, 8 October 2024 (UTC)
- They are tied to specific places, which can be displayed by clicking “more”. Nicodene (talk) 09:37, 8 October 2024 (UTC)
- I see. Well, I'm impressed! —Caoimhin ceallach (talk) 09:40, 8 October 2024 (UTC)
- They are tied to specific places, which can be displayed by clicking “more”. Nicodene (talk) 09:37, 8 October 2024 (UTC)
- Ok, that makes sense. Do you agree though that the way the section is organised makes it appear like those pronunciations belong to a single dialect? Maybe it's a work in progress and I imagine it's a tricky thing to sort out, but a long list of pronunciations that aren't tied to a specific time and place isn't very useful. —Caoimhin ceallach (talk) 09:24, 8 October 2024 (UTC)
- Providing a wrapper for the whole content of the section, to allow show/hide (collapse/expand) with collapsed being the default state, would be reasonable. Another layer of "show/hide" toggle, at a higher level than the existing "more/less" toggle (which would be nested beneath it). I am not one to whine that such collapsibility is desperately needed or sorely missed, but some humans are sticklers about it. Quercus solaris (talk) 16:27, 8 October 2024 (UTC)
- So these linguists went round the Swiss villages with pictures of trees and stuff and asked the locals "what are these?". Not a bad job, really! Phacromallus (talk) 22:07, 8 October 2024 (UTC)
@IvanScrooge98, Sartma While editing I gradually came to the realisation that the compromise we reached appears a bit inconsistent. Since we removed the accents from mid vowels on piane, I was thinking we could remove it everywhere, because it stands as a weird situation, in my opinion, now that è ò and é ó are distinguished in sdrucciole but not in piane. So I propose amending the guidelines and removing the written accent from sdrucciole and also from the puina~bevuo kind of words, keeping it only on tronche and monosyllables. (Secondarily, this change would also get rid of the issue of whether words like cauxa should be considered piane or not, and headwords would look slightly less clunky.) Of course, IPA will get even more necessary, which is perhaps in a sense also a positive consequence. What do you think? Catonif (talk) 10:21, 9 October 2024 (UTC)
- I’m not sure removing accent marks altogether is a good option. Regarding the distinction of é/ó and vs è/ò only in proparoxytones, somethimg similar happens in Catalan and Portuguese, which have very well established conventions for accents. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 10:30, 9 October 2024 (UTC)
- True, though from my Italian viewpoint saying liéoro with an accent and lievro without it looks a bit weird. Also pinging @GianWiki, Nicodene, Imetsia for further input. Catonif (talk) 19:34, 10 October 2024 (UTC)
- Personally I would favour an all-or-nothing approach. That is, either marking all stressed mid-vowels as low-mid (◌̀) or high-mid (◌́), or marking no vowel at all that way. The Standard Italian practice of using these diacritics in oxytones and proparoxytones, but not in paroxytones, has never made sense to me. Nicodene (talk) 21:54, 11 October 2024 (UTC)
- I'm a bit concerned that we're essentially making up spelling rules. How are such words normally written "in the wild"? We should try to follow whatever is done there. Benwing2 (talk) 05:25, 19 October 2024 (UTC)
- @Benwing2 Your concern is very legitimate, the thing is, as Sartma said in the previous discussion,
Native speakers of Venetan dialects use any sort of spelling. [...] I have no issues tanking a bold approach here and go with what we prefer
, given that the standardisation attempts are also multiple and often disagreeable in some regards. Note I am very careful to describe every spelling I encounter "into the wild" and place it under alternative forms as an alternative spelling, so in the end no information is lost, but lemmatising at those spellings would be a mess in the long run. Catonif (talk) 09:24, 19 October 2024 (UTC)- @Catonif I see. In that case yes we should use some sort of normalized spelling and make all the attested variants be classified as alt spellings. Ideally the normalized spelling should match the practice used in dictionaries (or in at least one of them if there are multiple standards). I would also not favor an approach that simply discards all accents. Generally I prefer having more accents rather than fewer, but would not be opposed to following the Italian practice of marking accents only in final-stressed words and monosyllables. Benwing2 (talk) 21:22, 19 October 2024 (UTC)
- I second most of this. I would rather have ràntego and dexéna than rantego and dexena. Italian accent rules should not be part of this unless they are followed more or less consistently by reputable sources/dictionaries. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 22:13, 19 October 2024 (UTC)
- All fine with me. Benwing2 (talk) 06:36, 20 October 2024 (UTC)
- @IvanScrooge98
I would rather have [...] dexéna than [...] dexena.
I'm a bit confused, didn't you sayI’d go for accent on neither regarding ⟨e⟩ and ⟨o⟩
in the past discussion? That's why we ditched the unambiguousness the system had. But anyways, personally I believe that Italian accent rules do play a role in this since to Venetan speakers they would seem natural and clean, rather than drawing parallels in Iberian orthographies. Catonif (talk) 16:54, 20 October 2024 (UTC)- What I meant is, if we have to choose between accent marks in all cases and no accents at all other than for final vowels, I’ll go for the first option. The parallel with Catalan and Portuguese was merely to point out the current “mixed system” isn’t an outright invention and has a history among Romance languages. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 19:06, 20 October 2024 (UTC)
- I second most of this. I would rather have ràntego and dexéna than rantego and dexena. Italian accent rules should not be part of this unless they are followed more or less consistently by reputable sources/dictionaries. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 22:13, 19 October 2024 (UTC)
- @Catonif I see. In that case yes we should use some sort of normalized spelling and make all the attested variants be classified as alt spellings. Ideally the normalized spelling should match the practice used in dictionaries (or in at least one of them if there are multiple standards). I would also not favor an approach that simply discards all accents. Generally I prefer having more accents rather than fewer, but would not be opposed to following the Italian practice of marking accents only in final-stressed words and monosyllables. Benwing2 (talk) 21:22, 19 October 2024 (UTC)
- @Benwing2 Your concern is very legitimate, the thing is, as Sartma said in the previous discussion,
- I'm a bit concerned that we're essentially making up spelling rules. How are such words normally written "in the wild"? We should try to follow whatever is done there. Benwing2 (talk) 05:25, 19 October 2024 (UTC)
- Personally I would favour an all-or-nothing approach. That is, either marking all stressed mid-vowels as low-mid (◌̀) or high-mid (◌́), or marking no vowel at all that way. The Standard Italian practice of using these diacritics in oxytones and proparoxytones, but not in paroxytones, has never made sense to me. Nicodene (talk) 21:54, 11 October 2024 (UTC)
- True, though from my Italian viewpoint saying liéoro with an accent and lievro without it looks a bit weird. Also pinging @GianWiki, Nicodene, Imetsia for further input. Catonif (talk) 19:34, 10 October 2024 (UTC)
unhiding the hidden
[edit]I vaguely remember someone saying they'd got a list of all the hidden comments in WT. Does this exist? I'm intrigued how much nonsense users have inserted over the years. Denazz (talk) 15:27, 10 October 2024 (UTC)
- It is WT:BJ. Svartava (talk) 10:37, 12 October 2024 (UTC)
- @Denazz: check out https://paste.ee/p/pew4Z Ioaxxere (talk) 05:26, 13 October 2024 (UTC)
- Hmm, thanks. It is, understandably, mostly very boring. P. Sovjunk (talk) 23:36, 14 October 2024 (UTC)
Suggestions for labels
[edit]I have made many proposals for labels at Module talk:labels/data/topical and would like others to check them and suggest improvements and implements, as I don't have the appropriate user permissions to do so. Juwan (talk) 11:43, 11 October 2024 (UTC)
Proposal: make all maintenance categories hidden
[edit]Specifically, every category under Category:Wiktionary maintenance. Hidden categories are opt-in, rather than being shown to every logged-out user who visits the page. Our long pages have a massive amount of categories, and I feel that categories like Category:English terms with quotations or Category:English terms with homophones drown out the ones that a casual user might actually be interested in. To be clear, the only change I'm advocating for is to make these categories hidden by default on the entry — the pages will still be in them. What do you think? Ioaxxere (talk) 03:40, 12 October 2024 (UTC)
- @Ioaxxere: no objection if there is an option for logged-in users to change the default and make these categories permanently visible. As someone who regularly tidies up entries, it is useful to see the categories. — Sgconlaw (talk) 11:37, 12 October 2024 (UTC)
- @Sgconlaw: You can check the box at Special:Preferences → Appearance → Show hidden categories. Ioaxxere (talk) 18:29, 12 October 2024 (UTC)
- @Ioaxxere: cool, thanks. — Sgconlaw (talk) 19:29, 12 October 2024 (UTC)
- @Sgconlaw: You can check the box at Special:Preferences → Appearance → Show hidden categories. Ioaxxere (talk) 18:29, 12 October 2024 (UTC)
- Eminently reasonable idea. Casual readers don't care or need to see these. —Justin (koavf)❤T☮C☺M☯ 16:28, 12 October 2024 (UTC)
- Support Binarystep (talk) 05:13, 14 October 2024 (UTC)
- Not Category:Entry maintenance by language though. It contains all the requests for translations, pronunciations etc., and I have inferred that we gain new editors, sought for foreign languages, by this. The others seem technical.
- Category:English terms with homophones is not even under Category:Entry maintenance by language (but Category:Terms by lexical property by language and then already Category:Fundamental) and hence not Category:Wiktionary maintenance, while Category:English terms with quotations is only there via Category:Entry maintenance by language. You are confused, @Ioaxxere.
- Don’t decide this without typically foreign-language editors, anyhow. For now I oppose for inconsiderate reasoning. Fay Freak (talk) 08:54, 15 October 2024 (UTC)
- @Fay Freak: My mistake, you're right about the homophone categories — in that case nothing would happen to it, but I still think it should be hidden. But I think you've gotten confused as well, since requests for translations and pronunciations are already hidden, so there would be no change. Ioaxxere (talk) 13:39, 15 October 2024 (UTC)
- Looking through Category:Spanish entry maintenance, these are the categories that I would find useful as a casual reader: terms with audio pronunciation, terms with IPA pronunciation, terms with quotations. These have strong applications for language learning, especially for smaller languages; all the other categories are more geared toward editing. I almost included Terms with collocations/usage examples, but those are more "nice to see on pages" than "worth clicking through a category", especially compared to quotations. Ultimateria (talk) 04:42, 16 October 2024 (UTC)
- @Ioaxxere Most of these maintenance categories are already hidden, and in general the category system hides or shows categories on a per-category (technically, per-category-prototype, or whatever) basis rather than through blanket rules like "anything under Category:Wiktionary maintenance should be hidden". I think it's important to enumerate all the specific categories you think should be hidden which aren't currently hidden, and we can decide which ones should be hidden. Benwing2 (talk) 04:59, 19 October 2024 (UTC)
- Also, I think that some of the categories under e.g. Category:Spanish entry maintenance should be grouped into subcategories to reduce the number of categories directly visible. In particular, some of the categories are purely for cleanup purposes (e.g. Category:Spanish terms with redundant script codes), but some aren't (e.g. Category:Spanish terms with quotations). Benwing2 (talk) 05:02, 19 October 2024 (UTC)
- @Benwing2: That's a fair point. Here are a couple of specific examples: X terms with quotations, X terms with usage examples, X terms with collocations, X terms with IPA pronunciation, X terms with audio pronunciation, X terms with homophones (that last one isn't a maintenance category). But I think my proposal was motivated on the more philosophical point that it doesn't make sense to show anons categories that *we* describe as being for "maintenance". Ioaxxere (talk) 05:40, 19 October 2024 (UTC)
- Right, and I agree with that in general; in fact, as I mentioned, most of these are already hidden. Just keep in mind that sometimes whether a category is considered "maintenance" isn't always clear-cut and whether it's under a maintenance umbrella category or umbrella metacategory may be a historical accident as opposed to something well thought-out. Benwing2 (talk) 05:48, 19 October 2024 (UTC)
Automated addition of 1953–1993 Romanian forms
[edit]Forms belonging to the previous Romanian orthographic standard should be added to Wiktionary. This unchallenging operation involves creating an alternative spelling entry containing the letter î corresponding to every present entry that contains the letter â.
To this end I propose creating the template {{ro-î-form of}}
, displaying 1953–1993 spelling of [term]. The alternative forms would correspondingly be linked from the main entry with {{alt|ro|term||î-form}}
.
Romanian-speaking admin Robbie SWE has also been consulted. According to User:Kc kennylau, this measure would affect almost 5000 entries. Potential anachronistic alternate forms for terms which did not yet exist when the former standard was in effect are, I can assure, very unlikely.
A number of such forms as I am talking about have already been created and are found in Category:Romanian superseded forms. The greater part of them claim to have been introduced in the 1904 standard; this is false, as said standard is (in regard to î and â) largely identical to the present one.
To expand on the previous: a small subset of the superseded î spellings had already been in use since 1904. Correction: it is actually the 1899 standard. They are inflections (participles, gerunds and first person plural present forms) of fourth conjugation verbs ending in -î, a closed class.
Special treatment is also required for derived terms of român, which under a 1964 provision were reverted to the spelling with â, identical to the present standard.
The previous two exceptions should be accommodated via a parameter; I propose |var=
, which would either take the value ro
(for derived terms of român, displaying 1953–1964 spelling) or 4
(for fourth conjugation forms, displaying 1904–1993 spelling 1899–1993 spelling). These adjustments will have to be made manually. ―K(ə)tom (talk) 21:45, 12 October 2024 (UTC)
- Support This appears to be a sensible proposal. Einstein2 (talk) 20:38, 15 October 2024 (UTC)
- I think this is fine if forms are attested somewhat, I try to stick to old spellings for Polish mostly if they exist. They usually do, but I'm the type of person to check everything. Vininn126 (talk) 20:40, 15 October 2024 (UTC)
- The Communist period saw scholarly editions of old texts, obviously edited in the then-current orthography, in large numbers. Anachronism in the opposite direction—old words given in this newer orthography they were never printed in—is, while never completely unavoidable, almost as unlikely as the other sort of anachronism I mentioned in my first post. Let’s also not forget that the most comprehensive dictionary of Romanian was, for the most part, also compiled in this period, with the headwords using î. ―K(ə)tom (talk) 08:12, 17 October 2024 (UTC)
- Do you have actual proof of that for Polish? Just restating the claim that they did and then being unable to produce many texts for them is kinda the exact thing we're trying to avoid on this website. Vininn126 (talk) 08:56, 17 October 2024 (UTC)
- I don’t really understand your comment, but, either way, I have my corpora. And we aren’t doing the three attestations thing for alternative spellings, right? ―K(ə)tom (talk) 10:03, 17 October 2024 (UTC)
- Sorry, I confused my threads. Please disregard that, haha! Otherwise this looks very sensible. I don't always do exactly 3 attestations for certain spellings, but I do check if it's there. Since some words came after certain spelling reforms and as such never had that old spelling, if that makes sense. Vininn126 (talk) 10:05, 17 October 2024 (UTC)
- I don’t really understand your comment, but, either way, I have my corpora. And we aren’t doing the three attestations thing for alternative spellings, right? ―K(ə)tom (talk) 10:03, 17 October 2024 (UTC)
- Do you have actual proof of that for Polish? Just restating the claim that they did and then being unable to produce many texts for them is kinda the exact thing we're trying to avoid on this website. Vininn126 (talk) 08:56, 17 October 2024 (UTC)
- The Communist period saw scholarly editions of old texts, obviously edited in the then-current orthography, in large numbers. Anachronism in the opposite direction—old words given in this newer orthography they were never printed in—is, while never completely unavoidable, almost as unlikely as the other sort of anachronism I mentioned in my first post. Let’s also not forget that the most comprehensive dictionary of Romanian was, for the most part, also compiled in this period, with the headwords using î. ―K(ə)tom (talk) 08:12, 17 October 2024 (UTC)
- @Ktom It looks like you're requesting two things, a template
{{ro-î-form of}}
(which seems completely unobjectionable) and a bot job to create î-spellings of word spelled with â. I'm not convinced, however, despite your claim, that there really are no words in â created in Romanian since 1993. I'm sure there have been tons of words that have entered the Romanian language since then, many referring to new technologies, social movements and such that didn't exist in 1993. Logically, many of these words will be formed from existing Romanian words, and many of those words have â in them, so it seems hard to believe that there are no terms in â created since 1993. This means you might need to manually go through the list of the 5,000 or so existing words in â, and pick out the ones created after 1993, so that the variant in î doesn't get bot-created. Benwing2 (talk) 05:23, 19 October 2024 (UTC)- Î/â is a letter exclusive to native Romanian vocabulary, and Romanian is not big on coining words based on native roots and stuff like that.
- Additionally, mass Romanian addition to Wiktionary was an operation dependent on dictionary entry lists, and any word not found as a headword in a dictionary was unlikely to be added; and given that Romanian dictionaries are laggards when it comes to adding new words, especially non-technical ones, the likelihood that we have a word found in a major dictionary that contains â and did not exist before 1993 is too low for me to consider.
- Additionally, the letter â does not even appear in any inflectionary suffixes.
- However, as a potential safeguard against adding an anachronistic î-form to some novel slang expression we may happen to have—and also for general cleanliness and anti-pedancy purposes—I do think there should be no alternative spelling entries made for multi-word terms. That may already be the policy, I don’t know about that. ―K(ə)tom (talk) 10:31, 19 October 2024 (UTC)
- @Ktom Does â occur in derivational suffixes? Also I don't quite understand your point about Romanian dictionaries being laggards when adding new words; this may be true, but presumably the list of î-alternative forms will be based on existing Romanian lemmas in Wiktionary, rather than in some major print dictionary, and Wiktionary tends to have quite good coverage of slang and neologisms, at least in many languages. As for "there should be no alternative spelling entries made for multi-word terms" I don't know if there is any such policy, but this seems reasonable to me. Benwing2 (talk) 20:27, 19 October 2024 (UTC)
- The point about the dictionaries is that Wiktionary does not have good coverage of Romanian non-dictionary terms, so we should expect our list of Romanian entries to align closely to the list of headwords of print dictionaries, a list whose newest additions belong only to international vocabulary. And no, â does not feature in any affixes. ―K(ə)tom (talk) 20:41, 19 October 2024 (UTC)
- @Ktom Does â occur in derivational suffixes? Also I don't quite understand your point about Romanian dictionaries being laggards when adding new words; this may be true, but presumably the list of î-alternative forms will be based on existing Romanian lemmas in Wiktionary, rather than in some major print dictionary, and Wiktionary tends to have quite good coverage of slang and neologisms, at least in many languages. As for "there should be no alternative spelling entries made for multi-word terms" I don't know if there is any such policy, but this seems reasonable to me. Benwing2 (talk) 20:27, 19 October 2024 (UTC)
- @Bogdan: What is your opinion in regard to this concern? ―K(ə)tom (talk) 10:43, 19 October 2024 (UTC)
- Post-1993 borrowings are almost all from Western languages (or through a Western intermediary), so they don't have the î/â sound. Neologisms are almost never created internally in Romanian, the only case could be a slang word, but I don't think there are any that fit this criteria in Wiktionary. In theory, it could happen, but I think it's very unlikely. Bogdan (talk) 08:39, 20 October 2024 (UTC)
- Support. I've added
î-form
(orî
),î-form-ro
(orî-ro
) andî-form-4
(orî-4
) at MOD:labels/data/lang/ro, so that now{{alt|ro|cîine||î}}
displays cîine — 1953–1993 spelling and{{altsp|ro|câine|from=î}}
displays 1953–1993 spelling of câine. I don't think the creation of a Romanian specific alt form template is needed. Catonif (talk) 20:48, 24 October 2024 (UTC)
@Benwing2: In light of the qualified opinions presented, do you find your concerns eased? As for me, after considering the facts, I’m relieved at how auspiciously unencumbered this entire measure has aligned itself to be: I mean, from morphological lack of productivity to—unaddressed but personally considered—compatibility with any future historical spellings we may some time implement, this truly makes for a best case scenario. ―K(ə)tom (talk) 20:01, 24 October 2024 (UTC)
- @Ktom Although I'm still a bit leery of blithely assuming there are no post-1993 terms containing â, I won't object if someone wants to do a bot operation to add the relevant entries, and I agree with User:Catonif's approach of using labels rather than bespoke Romanian-specific templates. Also, please be aware that this is not as trivial as you may think it is, because you have to account for the possibility that there's already a Romanian entry using the spelling you're trying to add, or a different-language entry using the same spelling. Instances of the latter can be handled by appropriate bot code, but all such cases of the former need to be skipped by the bot and handled by hand. Benwing2 (talk) 08:16, 28 October 2024 (UTC)
- Of course. The already created entries in question are to be found in Category:Romanian superseded forms (along with a few that pertain to different facets of previous standards), as well as cînd, which was in Category:Romanian dated forms. As for the choice of dedicated template, I had simply modelled myself on
{{fr-pre-1990}}
et sim. ―K(ə)tom (talk) 10:22, 28 October 2024 (UTC)
- Of course. The already created entries in question are to be found in Category:Romanian superseded forms (along with a few that pertain to different facets of previous standards), as well as cînd, which was in Category:Romanian dated forms. As for the choice of dedicated template, I had simply modelled myself on
alternative form of/synonym of
[edit]What is the difference between {{alternative form of}}
and {{synonym of}}
, and when should each be used? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:45, 13 October 2024 (UTC)
- Wiktionary:Entry_layout#Alternative_forms. This should help a guess. Tollef Salemann (talk) 16:19, 13 October 2024 (UTC)
- The verb stay mum is defined as an “alternative form of” keep mum, but I think this is wrong. I’d only use it if the terms, read aloud by the same speaker, are pronounced the same or almost the same. --Lambiam 20:03, 13 October 2024 (UTC)
- Right, I wouldn't say the pronunciation needs to be exactly the same, but an "alternative form" should have the same or a similar pronunciation and an identical or nearly identical etymology. Synonyms are commonly etymologically unrelated, but an alternative form never should be. For example, I think fo'castle is appropriately marked as an alternative form of forecastle. I'm not sure what the precise line should be between "alternative form of" and "alternative spelling of" (as used at foc's'le). In the context of languages with more inflections such as Latin, I've used "alternative form" for words where the root is shared and the definition is identical but the endings (and thus, pronunciation) differ, e.g. cornupeta and cornupetus.--Urszag (talk) 20:24, 13 October 2024 (UTC)
- Actually, am agree with it in a way, but sometimes I find or create entries with similar construction: to do X or N with Y, where N is alternative to X. In this case it is indeed an alternative form of the phrase, but not word-for-word. We have a lot of such examples in Swedish and Nynorsk, but i can now only remember my own which i recently created: заправлять арапа (literally, to fill a black noble servant). You see, in theory you can put almost any verb in it, even a verb which doesnt exist, and the meaning is gonna be the same. So the difference in verb is not important, and therefore it’s not just synonymous, but rather alternative form.
- If not, I will gladly go thru all this kinda phrases in Russian, Swedish and Nynorsk and put alternative forms into synonyms. But in this case we should disvuss it in a more wider discussion with all the editors. Tollef Salemann (talk) 20:26, 13 October 2024 (UTC)
- Regarding lines between "alternative form of" and "alternative spelling of", it is true that the latter is logically hyponymous to the former, but one facet of the whole relationship that to my mind is clear is that an alternative spelling is solely another orthographic method of writing the selfsame set of sounds, whereas an alternative form that is not an alternative spelling involves a morphologic difference. Thus, neurologic and neurological should be marked with "alternative form of" (not "alternative spelling of"), whereas homolog and homologue, or sulfur and sulphur, should best be marked with "alternative spelling of" (not "alternative form of"). As for what to call idioms that are clearly the same thing conceptually but with a mere substitution of vocabulary (such as "don't give up your day job" versus "don't quit your day job"), this is where people quibble between "alternative form of" and "synonym of", and neither one is wrong (from one viewpoint or another), but I would support Wiktionary standardizing on "synonym of" as a consistent convention even though the alternative option is not wrong either; this would probably accord with what Lambiam and Urszag said. Idioms of that class can take only certain vocabulary item substitutions, not a limitless range of them, so I guess they are probably a different class from the class that Tollef mentioned. Quercus solaris (talk) 05:27, 14 October 2024 (UTC)
- I think I'm in agreement with everyone above when I say something is an "alternative (form|spelling) of..." when it's merely another spelling/form of what is basically ~the same word, with (roughly) the same etymology (and same meaning).
When only the spelling differs, but the pronunciation is the same, it's an "alternative spelling of..." like kinikinic vs kinnikinnick, whereas when the form is different enough that the pronunciation also differs, like killikinick vs kinnikinnick, it's an "alternative form of...". There's been a proposal to make the templates spell this out, and an alternative proposal to give up on making the "form"-vs-"spelling" distinction at all.
When you've got different words for the same thing, like living rock vs living stone, that's when one is a "synonym of..."... but sometimes, people forgo using that template and just define stone as "Rock.
" (Your question makes me realize how non-obvious and potentially arbitrary our distinction can be to anyone unfamiliar with it.)
There is a smallish grey area when it comes to closely related words: e.g. suppose hofoobar is the Belarusian-derived English word for apple-flavoured vodka, and gofoobar is the Russian-derived word for it: are these alternative forms because they're closely related words for the same thing, or synonyms because they have different etymologies, one coming from one language and the other from a different language? But in such cases, there's often also some semantic difference, i.e. in such a scenario, gofoobar would typically mean "Russian apple-flavoured vodka" or "apple-flavoured vodka, especially from Russia" and hofoobar would typically mean "Belarusian apple-flavoured vodka", so you might just make each of those its own entry with its own separate definition, and link them as related terms...
(BTW, @ Quercus, for my part I'd probably just define "neurologic" as "Neurological.
", rather than listing it as either an "alt form" or a synonym"; I suppose it's a similar grey area, as I'd be tempted to say the extra suffix -al makes it not an alternative form but a separate, synonymous word... but I can also see the argument for it being a mere alt form...) - -sche (discuss) 01:47, 15 October 2024 (UTC)
Preliminary results of the 2024 Wikimedia Foundation Board of Trustees elections
[edit]Hello all,
Thank you to everyone who participated in the 2024 Wikimedia Foundation Board of Trustees election. Close to 6000 community members from more than 180 wiki projects have voted.
The following four candidates were the most voted:
While these candidates have been ranked through the vote, they still need to be appointed to the Board of Trustees. They need to pass a successful background check and meet the qualifications outlined in the Bylaws. New trustees will be appointed at the next Board meeting in December 2024.
Learn more about the results on Meta-Wiki.
Best regards,
The Elections Committee and Board Selection Working Group
MPossoupe_(WMF) 08:26, 14 October 2024 (UTC)
User:Kwamikagami making a mess again
[edit]@Kwamikagami has been using {{mul-letter}}
for non-translingual entries and has refused to learn and apply proper formatting or case. The history on the page ə is an absolute mess and trying to figure out a solution for the letter entries which are nigh unusable from ones on the edge of usability feels like a futile task. This is not to mention the fact the user has added tons of ill-researched letters without regard for whether they were actually widely used or not, instead focusing on an obsession for Unicode. I'm not even sure how to begin approaching trying to fix this page. We need input from other mods, @Benwing2, @Chuck Entz, @Surjection as bureucrats and @Thadh as an admin who has dealt with the user in question. Vininn126 (talk) 23:18, 14 October 2024 (UTC)
- My initial suggestion on Discord was to just revert all pages to the last known good version before Kwami's edits (bot edits can be redone) but would like to hear from others. Benwing2 (talk) 23:28, 14 October 2024 (UTC)
- I also don’t know what to do about changes that he’s made towards even just Nigerian languages. And as I’ve said before, we need more enforcement. If we had indefinitely blocked Kwami as people have requested in the past, the damage would not be as bad as it is right now. We need to stop being lenient with repetitive problematic users that have shown that they’re refusing to learn. Kwami is not the first one, but hopefully he’ll be the last. AG202 (talk) 23:44, 14 October 2024 (UTC)
- Please provide one example of a problem I caused since my May block, apart from the Efik letter 'ñ' where sources are contradictory. kwami (talk) 19:22, 15 October 2024 (UTC)
- He definitely listens to advice from time to time, and seems to show good faith, but there's an element of randomness in his decision-making that combines with the sheer volume of his edits and with the periods when he doesn't listen to produce lots of sheer nonsense. There are parts of Category:Entries with incorrect language header by language, WT:Todo/Lists/Template language code does not match header, and WT:Todo/Lists/Entries with no headword line that I steer clear of because they're such a morass- he's used just about every combination of L2 header and language code in his single-character entries. Sometimes he does things right, sometimes wrong, but he seems to be compelled to keep going at high volume no matter what. Chuck Entz (talk) 00:29, 15 October 2024 (UTC)
- I see I did use 'mul-letter' for the Osage entry of schwa back in January. I'd be curious if I've made that error more recently. I do know to use the ISO code for the language, but evidently I sometimes overlook it when I copy-paste from another entry or article. I copy-paste because I've found that I may omit critical things if I create an entry from scratch, or not use the proper formatting. It's best for me to copy an established framework.
- If you just drop a note on my talk page that I made a mess of schwa or whatever, I'm happy to correct myself. Or that an a number of errors in some tracking cat are from me, I'll go through them. kwami (talk) 00:57, 15 October 2024 (UTC)
- BTW, I'm currently blocked from correcting the schwa article.
- I guess what I'm confused by, if I've made a 'shitty edit', or especially a number of them, why not just tell me so that I know to fix them? Certainly if you avoid a whole tracking category because of me, I should take care of it. Vin keeps saying I 'refuse to learn', but there's no refusal -- I need feedback. When I do things that inconvenience other editors, sure, you shouldn't have to clean up after me. Just tell me so I can clean up after myself. It's not intentional. Also, I'd be curious if I've made any errors of fact, or if it's all template and formatting errors. (P.S. In case you think I forgot, an editor did complain not long ago that I made an error of fact with the Efik alphabet and should have know better, but AFAICT the difference is a matter of user or publisher preference -- I followed curriculum materials and monolingual print publication.) kwami (talk) 01:00, 15 October 2024 (UTC)
- AG202 specifically referred to problems with your edits of Nigerian languages, which (as can be seen from this thread on your talkpage) is a linguistic issue, not a formatting one. Vininn126 also said
the user has added tons of ill-researched letters without regard for whether they were actually widely used or not
, which is not about formatting either. Whatever the merits of those complaints, people clearly have more issues with your edits than merely formatting, so please take the time to read the threads you are replying to properly in future. Theknightwho (talk) 01:34, 15 October 2024 (UTC)- Yes, that's the Efik alphabet issue that I mentioned above. I did of course take the time to read it, and AFAICT my use of the letter n-macron was correct, though I did change it as requested. (AG, if you could respond to that thread, I'd appreciate it.) As for Vin saying saying I've added 'tons' of ill-researched letters, he hasn't provided any examples that I recall of anything I've done since my block. All specific complaints have been about cleaning up tracking categories. Someone once objected that it was inappropriate to create individual entries for Yoruba letters with diacritics, as I had done, but that was years ago and I don't know of any other mess I've made with Nigerian languages since.
- Is it inappropriate to create Wiktionary entries for Unicode characters? I often come to Wikt to discover the usage of some obscure Unicode character that I happen across, and it can be frustrating when we have no information here, or when we only repeat the Unicode name. So yes, I have been fleshing out our coverage. If that's not acceptable, please let me know. kwami (talk) 01:50, 15 October 2024 (UTC)
- "Officer, why didn't you warn me about the kid on the skateboard? I didn't see him until it was too late. And I'm truly sorry about the medians over that 5-mile stretch." As a responsible wiki editor, you shouldn't require constant supervision to keep you from veering off in the wrong direction, and you shouldn't be going so fast that mistakes turn into huge cleanup projects before anyone spots them. Chuck Entz (talk) 02:16, 15 October 2024 (UTC)
- So, basically, the problem seems to be that I add too many quick entries, that I should slow down with my contributions. Well, a block will certainly accomplish that.
- There are two kinds of complaint against me. One, that I make factual errors. Vin keeps saying that, but hasn't provided any examples of something I've done recently [e.g. since my block]. So I don't know if this is actually a problem, or if Vin is not letting go of past history [like the Yoruba letters with diacritics]. Two, that I make sloppy edits that cause problems with tracking categories. I've certainly done that. I copy-paste from existing articles to get the formatting and templating correct, but sometimes overlook adjustments -- such as missing a template when I change the ISO codes, or not re-indenting the subheadings. Or perhaps there are other adjustments I don't know to make. That's a problem. I thought it was something that I could fix by reviewing the tracking category when my errors crop up there, but I guess that's not going to work. kwami (talk) 02:47, 15 October 2024 (UTC)
- You've been warned of making a mess before, and while you say you've done that, the fact you've been warned and still need to ask in this thread what you've done shows either you are playing dumb or can't learn from your mistakes while still leaving a massive mess. Vininn126 (talk) 08:22, 15 October 2024 (UTC)
- This edit is from January, 4 months before my block! This isn't evidence I'm not being more careful since. kwami (talk) 17:49, 15 October 2024 (UTC)
- You've been warned of making a mess before, and while you say you've done that, the fact you've been warned and still need to ask in this thread what you've done shows either you are playing dumb or can't learn from your mistakes while still leaving a massive mess. Vininn126 (talk) 08:22, 15 October 2024 (UTC)
- AG202 specifically referred to problems with your edits of Nigerian languages, which (as can be seen from this thread on your talkpage) is a linguistic issue, not a formatting one. Vininn126 also said
- For reference, this PetScan should have all the entries in question. It's most Osage letters and quite a bit more, not just the schwa. -saph668 (user—talk—contribs) 10:27, 15 October 2024 (UTC)
- Thank you for that. If someone had notified me before my block, I would have cleaned them all up. kwami (talk) 19:07, 15 October 2024 (UTC)
- I've gone through them, and where the error is mine, they're all old, from before my block. I don't see anything I've done since then. kwami (talk) 19:12, 15 October 2024 (UTC)
- Us Wiktionarians are renowned for making a mess. I make plenty, mostly accidentally. There's a fine line to tread between high-speed edits and high-quality edits. If one user, for example, churns out 98 decent audios in an hour, 2 unclear audios and 1 fart sound that they stick on the Pronunciation section of penguin, we have a net gain - the fart sound will get quickly reverted, while the unclears should get noticed eventually. Yes, it can be annoying to correct, but part of wikiculture is to clean up others' (and our own) shit. We all need supervision - even our bureaucrats! BenWing's bot has brought up plenty of errors (soon corrected) and Chuck Entz....well, he...that joker....err...well....actually that guy is an exception, having a basically untarnished record. By the way, I've not looked into kwami's case, this is just a general observation. P. Sovjunk (talk) 11:58, 15 October 2024 (UTC)
- Yes, we all make mistakes. I frequently make typos or other things, but the ratio of mess-productivity is what's important, and also I'm open to people asking me to clean it up, you can see my talkpage where Chuck frequently asks me to clean up my mess. Vininn126 (talk) 12:01, 15 October 2024 (UTC)
- Then why not have the same courtesy toward me, and notify me on my talk page when I make a mess, so that I have the same opportunity to clean it up? kwami (talk) 17:51, 15 October 2024 (UTC)
- I literally just explained that you've been warned multiple times. That's the courteousy. Vininn126 (talk) 17:54, 15 October 2024 (UTC)
- Since my May block, there have been 4 threads on my talk page.
- One about fixing an error in arrow emojis.
- One where I followed Chuck Entz's lead in moving Tahitian entries from an ASCII apostrophe to a proper okina, and he reverted me. He later said he didn't remember his earlier page moves.
- One where someone informed me it wasn't appropriate to do the same for Old Tupi, and I corrected myself.
- One for the Efik alphabet, mentioned above. Again, I corrected myself, though I doubt it was a correction.
- So, again, if I make an error, why don't you have the same courtesy Chuck has for you, and notify me that I made an error? I am also willing to correct myself. kwami (talk) 18:06, 15 October 2024 (UTC)
- Since my May block, there have been 4 threads on my talk page.
- I literally just explained that you've been warned multiple times. That's the courteousy. Vininn126 (talk) 17:54, 15 October 2024 (UTC)
- Then why not have the same courtesy toward me, and notify me on my talk page when I make a mess, so that I have the same opportunity to clean it up? kwami (talk) 17:51, 15 October 2024 (UTC)
- Yes, we all make mistakes. I frequently make typos or other things, but the ratio of mess-productivity is what's important, and also I'm open to people asking me to clean it up, you can see my talkpage where Chuck frequently asks me to clean up my mess. Vininn126 (talk) 12:01, 15 October 2024 (UTC)
- As I said before, I think it's time to re-do the the famous vote on this issue and if it passes we'll be done with the whole problem all together. As for specifically this incident, I do think Kwami has a long history of messing up, being told not to do it, and then continuing to do the exact same thing. Thadh (talk) 14:58, 15 October 2024 (UTC)
- I will strongly oppose this once again. I would hate for people's legitimate work to go down the drain because of a user who was allowed a free rein of terror because you all refused to take appropriate action. It's disappointing. AG202 (talk) 15:42, 15 October 2024 (UTC)
- Whose work has gone down the drain? Your only objection on my talk page is that I followed Efik print sources for the Efik alphabet, rather than online English-language sources. I changed the letters to match the English sources, though you have yet to answer my question as to why we shouldn't prefer professional Efik-language sources. Regardless, that's hardly a case of people's legitimate work going down the drain, since there was no Efik-alphabet template before I created it. kwami (talk) 17:57, 15 October 2024 (UTC)
- And the constant denial begins again. It never changes. Vininn126 (talk) 17:59, 15 October 2024 (UTC)
- I think you've misread AG202's comment: "I would hate for people's legitimate work to go down the drain" isn't about anything you did. It refers to the loss of useful information that would occur if Thadh's proposal to remove all letter entries not under Translingual passed (it failed, but Thadh is now suggesting trying it again as a way to avoid arguing about the entries you were working on).--Urszag (talk) 18:07, 15 October 2024 (UTC)
- Ah, okay. Yes, I thought it was about me. kwami (talk) 18:10, 15 October 2024 (UTC)
- That seems a strange solution. saph668 just provided a useful Petscan link above, and all my errors are old, predating my May block. I don't see any evidence this is an ongoing problem, and if I'd seen the Petscan results earlier [I had no idea such a thing existed], I could've cleaned them up myself. kwami (talk) 19:15, 15 October 2024 (UTC)
- Whose work has gone down the drain? Your only objection on my talk page is that I followed Efik print sources for the Efik alphabet, rather than online English-language sources. I changed the letters to match the English sources, though you have yet to answer my question as to why we shouldn't prefer professional Efik-language sources. Regardless, that's hardly a case of people's legitimate work going down the drain, since there was no Efik-alphabet template before I created it. kwami (talk) 17:57, 15 October 2024 (UTC)
- I will strongly oppose this once again. I would hate for people's legitimate work to go down the drain because of a user who was allowed a free rein of terror because you all refused to take appropriate action. It's disappointing. AG202 (talk) 15:42, 15 October 2024 (UTC)
User:Victar and false citations
[edit]I have come across two instances of Victar citing sources in support for specific claims, in which if you actually checked the source he cited, the scholar actually said something else.
The instances are:
- On Latin rutilus, he cited this month two scholars who actually made the exact opposite claim to what Victar wrote: he wrote that original second vowel was *-e-, when the two sources cited actually said *-i-, and Victar wrote that this word was a diminutive when the two sources actually say that the -lus in this word was of non-diminutive origin.
- On what is now Proto-Brythonic *giow, Victar in 2019 cited two sources (EDPC and McCone) for a claim that this word came from a Proto-Celtic athematic root noun, when they actually both reconstruct thematic Proto-Celtic *gyos.
I have reminded Victar on his talk page to stop doing this, but he responded that he saw such a reminder as a "waste of time" and told me to "take it to the entries". Surely, false use of citations should not be condoned nor should it rest on the shoulders of other editors to correct after the fact? — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 03:41, 15 October 2024 (UTC)
- So the whole etymology I cite that line is correct to the source, but because I used an *-elos in the Proto-Italic suffix instead of an *-ilos, the etymology is the "exact opposite"? The suffix *-elos is the correct Proto-Italic reconstruction of the suffix both according to
{{R:ine:de Goede:2014|15}}
and{{R:itc:EDL}}
. We're not beholden to follow sources to the exact letter when they're outdated or wrong, otherwise our PIE reconstructions would look like *ərāu-. - @Benwing2, how about we make exaggerated and false accusations a "blockable offense", per your discord comment. --
{{victar|talk}}
05:11, 15 October 2024 (UTC)- First of all, I don't appreciate the snark. Secondly while I do understand the principle of correcting notation to the latest scholarly consensus (although if you think *-ilos is outdated, it is strange that the citation is from 2019), you didn't respond to any of the other points made by User:Mellohi!. Third, why don't you respond on Discord directly if you're lurking in the background? Benwing2 (talk) 05:39, 15 October 2024 (UTC)
- @Victar, how about we not make exaggerated and false accusations about someone else's accusations? Regardless of who's right here, throwing around accusations of bad faith and requesting someone be blocked because they questioned your actions isn't helping you at all. Chuck Entz (talk) 05:46, 15 October 2024 (UTC)
- It's bad faith for @Benwing2 to threaten a block without even looking at the edit. --
{{victar|talk}}
05:51, 15 October 2024 (UTC)- Benwing2 specifically said
IMO falsely citing sources is a blockable offense. If this happens again, let me know.
It is a blockable offence in my view as well, as it shows academic dishonesty, which is something we cannot tolerate on Wiktionary. This is not bad faith to point out. Theknightwho (talk) 16:19, 15 October 2024 (UTC)
- Benwing2 specifically said
- It's bad faith for @Benwing2 to threaten a block without even looking at the edit. --
- There is an important difference between normalizing the spelling of a reconstruction to a different standard (the case of *ərāu-) vs. claiming that an author used one derivational pathway when they actually used a different one (as with rutilus).
- Prosper says that the adjectival suffix for rutilus is essentially lambdacized -idus - absolutely no diminutive *-elos involved.
- Schaffner specified *-i-los and not *-elos because he is not deriving with diminutive *-elos either; the word does not end in -ulus as one would expect from *-elos (only *-ilos can become -ilus in Schaffner's understanding), and the -los suffix (with no *-e-!) Schaffner derives rutilus with has possessive function (not diminutive function); the -i- is derived by Schaffner from base *rutis.
- In neither case should these sources be cited for a claim that rutilus was derived with the diminutive suffix *-elos. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 06:28, 15 October 2024 (UTC)
- Proto-Italic *-elos isn't just a diminutive suffix, see
{{R:ine:de Goede:2014|15}}
, where it lists its function as forming "desubstantival and deadjectival diminutive nouns", "verbal adjectives", and "desubstantival adjectives". Bare Proto-Italic *-los, as far as I know, was only ever appended to the root -- I don't know of any cases of *ROOT-i-los, or instances of an *-ilos suffix in Proto-Italic. - Additionally, rutilus is also attested as rutulus (Verg. A. 8.430), and Latin is no stranger to -ulus ~ -ilus ~ -illus variants, compare caupulus ~ caupilus ~ caupillus. According to Sen (2015) p22, the -i- in rutilus can be explained as a "dissimilation of lip-rounding from immediately preceding /kʷ/, or /u/ in the preceding syllable".
- Again, this could have been discussed on the entry page. --
{{victar|talk}}
07:38, 15 October 2024 (UTC)- The point is that you should not be attributing your own (or De Goede's, or Sen's, etc.) thoughts on a matter to another scholar who does not share the same thought process (Schaffner in this case).
- Why did you specify "diminutive suffix" in your edit citing Schaffner when Schaffner specifically invokes a non-diminutive function of Proto-Indo-European *-lós?
- Again, why did you cite Schaffner, who evidently does not share your line of thought that "Bare Proto-Italic *-los, as far as I know, was only ever appended to the root...", given he derives rutilus from stacking -los on top of a base *rutis in the first place?
- And why did you cite Schaffner for *rutelos > rutilus when he draws a phonological distinction between *rutelos > rutulus and *rutilos > rutilus?
- You have also not explained your citation of Prosper to support a -los derivation when she outright dismisses such a notion in her paper that was cited. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 12:04, 15 October 2024 (UTC)
- @Mellohi!: All you've managed to reply is "Schaffner reconstructs an *-i-", without addressing any of my argumenets or giving any counterexamples. Again, "we're not beholden to follow sources to the exact letter when they're outdated or wrong", and the sources I've given say Schaffner is wrong in reconstructing *-ilos, including Prosper. --
{{victar|talk}}
20:08, 15 October 2024 (UTC)- Regardless of whether "we're not beholden to follow sources to the exact letter when they're outdated or wrong", citations must not be formatted in a way that suggests that the sources say something that they didn't, because this is false representation of the sources.--Urszag (talk) 20:25, 15 October 2024 (UTC)
- It does not matter whether you or me, other scholars, or anyone else think Schaffner or Prosper are right or wrong; the point is that you cannot cite them to support a derivation from *rutelos > rutilus when these two do not posit such an etymology in the first place. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 20:40, 15 October 2024 (UTC)
- And the references are there from Schaffner and Prosper to support the derivation from Proto-Indo-European *h₂rew-, which they do. If we had the ability to reference only certain sections of a sentence and not others, then there might be a point to be made about the source being in the wrong place, but we do not. --
{{victar|talk}}
21:00, 15 October 2024 (UTC)- Nothing in this version of the page makes it clear that the citations only refer to the derivation from PIE, and not the derivation from Proto-Italic or the affixation, which (together) are the primary statement of the sentence those citations purport to cite. You could easily have provided a reference partway through the sentence, or clarified that the references only support the PIE derivation, but you did not. Theknightwho (talk) 21:10, 15 October 2024 (UTC)
- And the references are there from Schaffner and Prosper to support the derivation from Proto-Indo-European *h₂rew-, which they do. If we had the ability to reference only certain sections of a sentence and not others, then there might be a point to be made about the source being in the wrong place, but we do not. --
- Victar seems to still be failing to understand that the issue is not the accuracy or credibility of the sources themselves, but the fact that it is dishonest to misrepresent what they say. Frankly, the seriousness of the issue, the repeat offences, the failure to properly address the accusation and the baseless accusations of bad faith in return incline me towards a block. Falsifying sources simply cannot be tolerated on Wiktionary if we're going to have any credibility as a resource. Theknightwho (talk) 20:47, 15 October 2024 (UTC)
- Just saying, but in case you missed this, there's also this. Relevant quote about *ȷ́ʰárati:
- "Having the PIIr entry read "Rix derives the verb from Proto-Indo-European *ǵʰérm̥-ti ~ *ǵʰr̥m-énti / *ǵʰr̥m-tór ~ *ǵʰr̥m-n̥tór" is completely misleading." ... "What is actually given by LIV at p.178 is: Präsens *ĝʰR̥-né/n-H-"
- (yes, that still needs to be cleaned up, but there are several roots to disentangle) Exarchus (talk) 19:11, 29 October 2024 (UTC)
- There's also Wiktionary:Requests_for_deletion/Reconstruction#Reconstruction:Proto-Indo-Iranian/Háȷ́ʰāȷ́ʰaršt, where victar made it clear that despite this discussion, he sees nothing wrong with putting a citation at the end of a sentence that is not fully supported by the cited sources (and may even be contradicted by them). I can only assume victar is planning to keep at this practice.--Urszag (talk) 19:27, 29 October 2024 (UTC)
- The fact that Victar still sees fit to do this even after this discussion is beyond the pale for me. @Benwing2 @Surjection @Chuck Entz I intend to block Victar for a week, pending any objections - please do let me know if you have any. Theknightwho (talk) 22:25, 29 October 2024 (UTC)
- I don't have any objections, and in fact given what @Urszag said just above, I think a longer block might be in order. Misrepresenting cited sources is a serious issue and doubling down when confronted with the problem does not instill confidence. Benwing2 (talk) 22:43, 29 October 2024 (UTC)
- The fact that Victar still sees fit to do this even after this discussion is beyond the pale for me. @Benwing2 @Surjection @Chuck Entz I intend to block Victar for a week, pending any objections - please do let me know if you have any. Theknightwho (talk) 22:25, 29 October 2024 (UTC)
- @Mellohi!: All you've managed to reply is "Schaffner reconstructs an *-i-", without addressing any of my argumenets or giving any counterexamples. Again, "we're not beholden to follow sources to the exact letter when they're outdated or wrong", and the sources I've given say Schaffner is wrong in reconstructing *-ilos, including Prosper. --
- The point is that you should not be attributing your own (or De Goede's, or Sen's, etc.) thoughts on a matter to another scholar who does not share the same thought process (Schaffner in this case).
- Proto-Italic *-elos isn't just a diminutive suffix, see
I am also reminded of Victar once altering the vowel of a reconstruction given by two sources to a phonemically different vowel. Victar still retained the two citations to support his altered form *fellō even though the two sources explicitly said *fillō. Discussion of this incident did not find Victar's alteration of the reconstruction to be warranted. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 17:06, 15 October 2024 (UTC)
I also think Victar/Sokkjo should be more careful with references. Examples where I recently noticed that he used references to support reconstructions that are very far removed from what is actually in those references are *gʰrem- (which has been thoroughly cleaned up) and *ǵéwseti (which still has many problems). —Caoimhin ceallach (talk) 22:39, 16 October 2024 (UTC)
- I should add that I generally think he does great work, but there are too many cases where he slips up and then refuses to admit a mistake. —Caoimhin ceallach (talk) 22:44, 16 October 2024 (UTC)
If a statement is followed by an inline citation, then that statement should be accurate to what the cited work says. It’s fine if an editor wishes to contradict some (or even all) the cited sources, but they should make it clear that they are doing so and, ideally, explain their reasoning. Nicodene (talk) 23:22, 16 October 2024 (UTC)
I will pile on and say that yes, it is important that we do not make claims that are not present in the sources, or ascribe to sources claims that they do not make, and would support a block if an editor refuses to abide by these principles. — SURJECTION / T / C / L / 20:29, 29 October 2024 (UTC)
- Generally, this should be obvious. There are times when certain information has to be extrapolated from sources, but as stated above, it should be clear, and Victar's work above is fairly clearly across the line for me. Vininn126 (talk) 20:32, 29 October 2024 (UTC)
- I think he justly asserted that it is only to be taken to the entries, since it is obvious that he knows the lines. It is just quite challenging an art to clarify in each footnote and referenced sentence in what respect exactly, without also loosing the line of thought of what one actually wanted to do, the citation – which might not even be directly in view, amongst dozens of other ones in view and in mind – corresponds to the points made by the editor(s), suffocating his creativity, which does not arise from a dichotomic phenomonology differentiating conclusions experienced in references and additions to them assessed for Wiktionary, but on the contrary from the combination of all material. Fay Freak (talk) 20:47, 29 October 2024 (UTC)
- I don't think it is obvious that he knows the lines, given the persistent evidence he is willing to cross them: this looks like a real disagreement to me. If it's too difficult to place inline citations accurately, there's no obligation to use them as opposed to citing relevant sources as general references in a "Further reading" section.--Urszag (talk) 21:49, 29 October 2024 (UTC)
- This is a good summary. There's no need to becry a limitation of editors' creativity when we are first and foremost a scholarly source. Vininn126 (talk) 21:54, 29 October 2024 (UTC)
- If one wishes to write a sentence that is only partly supported by a source, one can simply start the sentence with whatever is true to that source, add the inline reference at that point, and then for the rest of the sentence continue with one’s own ideas. Nicodene (talk) 17:20, 31 October 2024 (UTC)
- I don't think it is obvious that he knows the lines, given the persistent evidence he is willing to cross them: this looks like a real disagreement to me. If it's too difficult to place inline citations accurately, there's no obligation to use them as opposed to citing relevant sources as general references in a "Further reading" section.--Urszag (talk) 21:49, 29 October 2024 (UTC)
- I think he justly asserted that it is only to be taken to the entries, since it is obvious that he knows the lines. It is just quite challenging an art to clarify in each footnote and referenced sentence in what respect exactly, without also loosing the line of thought of what one actually wanted to do, the citation – which might not even be directly in view, amongst dozens of other ones in view and in mind – corresponds to the points made by the editor(s), suffocating his creativity, which does not arise from a dichotomic phenomonology differentiating conclusions experienced in references and additions to them assessed for Wiktionary, but on the contrary from the combination of all material. Fay Freak (talk) 20:47, 29 October 2024 (UTC)
FWIW, to me blocking Victar for a week seems mostly counter-productive, to solve this for the long run we should probably add a section to WT:REF, approved by community consesus through a formal vote, where we have a clear and specific description of where to place references in sentences, on the steps of w:WP:INTEGRITY which Urszag mentioned on the PII RFD discussion. Catonif (talk) 16:07, 31 October 2024 (UTC)
- I wouldn’t have blocked Victar had they not decided to keep defending it in a current discussion at WT:RFDR, which makes it ongoing disruption; as Caoimhin ceallach put it there,
It is ludicrous that we are arguing about this.
If Victar had shown any kind of willingness to correct the issue it would be different, but the fact is that they haven’t, and instead they decided to keep defending it, wasting everyone else’s time. - I do agree with adding this as a formal policy, though. Theknightwho (talk) 17:19, 31 October 2024 (UTC)
- I would support such a vote. — SURJECTION / T / C / L / 18:26, 31 October 2024 (UTC)
Seeking volunteers to join several of the movement’s committees
[edit]Each year, typically from October through December, several of the movement’s committees seek new volunteers.
Read more about the committees on their Meta-wiki pages:
Applications for the committees open on 16 October 2024. Applications for the Affiliations Committee close on 18 November 2024, and applications for the Ombuds commission and the Case Review Committee close on 2 December 2024. Learn how to apply by visiting the appointment page on Meta-wiki. Post to the talk page or email cst@wikimedia.org with any questions you may have.
For the Committee Support team,
-- Keegan (WMF) (talk) 23:09, 16 October 2024 (UTC)
- I'll do it! Erp1039 (talk) 23:22, 17 October 2024 (UTC)
Cleanup of interwiki links
[edit]I wish to request some cleanup for the appendices and Wiktionary namespaces relating to how interwiki links are handled. many of these pages have interwiki links still present at the bottom of the page. these should be moved to Wikidata, and I am dumbfounded how they managed to remain here in 2024.
if any experienced scripters know how to find all the pages that have these interwiki, please feel free to help! Juwan (talk) 10:50, 18 October 2024 (UTC)
- To be clear, how interwiki links are created and stored at Wikidata is different from how it is at other sister projects. See d:Wikidata:Wiktionary. —Justin (koavf)❤T☮C☺M☯ 11:48, 18 October 2024 (UTC)
- @Theknightwho I want to know what was the reasoning for this diff. the page remained fine because it was linked on Wikidata, showing other wikis either way. Juwan (talk) 17:53, 18 October 2024 (UTC)
- @JnpoJuwan Alright, fair enough. My bad. Theknightwho (talk) 18:00, 18 October 2024 (UTC)
Changing the default skin to Vector 2022
[edit]I've been personally using Vector 2022 for a little while and enjoying it a lot. I'm curious whether we can reach consensus to enable it as the default skin across the site, and reap a number of UX benefits — namely:
- The Vector 2022 TOC is objectively better than Vector's since it doesn't push the content down.
- Customizable text size and width.
- Dark mode is supported out of the box, and with MediaWiki:Gadget-Palette.css and MediaWiki:Gadget-AutoContrastFixer.js, it works pretty well with our templates.
That's a purely objective comparison, since I think both skins are very attractive in terms of appearance. What do you think? Ioaxxere (talk) 04:28, 19 October 2024 (UTC)
- We had this discussion before and a bunch of people objected to Vector 2022. IMO the biggest problem is the waste of horizontal space taken up by the two sidebars. In comparison, Vector 2010 has only one sidebar of smaller width than either of the two Vector 2022 sidebars. You can hide the Tools sidebar on the right, but then, it seems, you don't have easy access to things like User contributions. And if you "hide" the table of contents on the left, the width doesn't get reclaimed; instead you just get a big blank space on the left. Benwing2 (talk) 04:41, 19 October 2024 (UTC)
- @Benwing2: Actually, if you clear the sidebars, set the text size to "small", and set the width to "wide", you can get more horizontal space than you can in Vector. You're right that this comes at the cost of additional clicks for some things, but I personally haven't found that to be an issue. Ioaxxere (talk) 05:40, 19 October 2024 (UTC)
- It isn't ready. The last point also comes across as a bit disingenuous to me, because the option to enable dark mode isn't even shown to users (when I last tried). — SURJECTION / T / C / L / 06:39, 21 October 2024 (UTC)
- When I've tried to use Vector 2022, drawn in by the prospect of dark mode (I have alternatively considered porting Wikipedia's Dark Mode gadget over to here...), assuming that I'll adapt to the new locations of things if I use it enough, the thing that most immediately made me switch back to Vector 2010 was that at the level of zoom I use, neither the TOC nor the Tools bars were visible, so the TOC and QQ were inaccessible. I see that if I zoom out, they become visible. It is annoying that this site does not just display differently in different skins, it also displays the same skin radically differently depending on your level of zoom and factors like whether you're accessing the mobile version of the site from a computer (where you get the Citations tab/link) or from an actual mobile (on which the Citations tab is absent). (Personally, I also like that in Vector 2010 the TOC is a different background/colour than the entry, whereas in Vector 2022, at least in dark mode, the TOC and the Tools and the entry all have the same unseparated black background. I assume some custom css or even an improvement to the skin itself could make the TOC have a slightly lighter background or clearer border on Vector 2022?) - -sche (discuss) 19:26, 21 October 2024 (UTC)
- Using Vector 2022 zoomed out enough to see the TOC and Tools bars, I'm not impressed with the amount of wasted space (although wasted space is an issue on every version/skin of our site); if I hide the "Tools" bar it is better, but then I lose the "QQ" button and have to click on the tools dropdown ever time to get to it. I would like to think this could be fixed by some css or js change to put the "QQ" link into the same top-bar as the "Read - Edit - View History" links, like is done in Vector 2010, but I don't know. - -sche (discuss) 21:30, 21 October 2024 (UTC)
Punjabi Infinitives
[edit]Pinging Punjabi group (Notifying AryamanA, Kutchkutch, Svartava, AryamanA, Kutchkutch, Notevenkidding): and @RonnieSingh, عُثمان, OblivionKhorasan, ChromeBones (and others are welcome to comment on this).
Hi everyone, I wanted to have this discussion on Punjabi infinitives, and just understand everyone's thoughts.
Currently there is a difference between Punjabi infinitives with verbs which end in -ā in Gurmukhi and Shahmukhi. From my view, in Pakistani Punjabi (based on Lahori Punjabi), such verbs have the infinitive -āṇā آݨا (āṇā) / ਆਣਾ (āṇā), whereas Indian Punjabi tends to employ the infinitive –āuṇā آؤݨا (ā'oṇā) / ਆਉਣਾ (āuṇā). There is also another infinitive stem which ends in -āvaṇā آوَݨا (āvaṇā) / ਆਵਣਾ (āvaṇā) which is quite common in Pakistani Punjabi. How should this be dealt with?
It's also important to mention that the because of this, Shahmukhi and Gurmukhi conjugation templates currently have differences. نعم البدل (talk) 10:27, 19 October 2024 (UTC)
- I would use ਆਉਣ / آوݨ since this form is used in most dialects (it is not always the same form, in Western dialects it can be the direct case form but in Eastern dialects it is oblique case). It is also consistent with the form used in Salahuddin’s dictionary and the PILAC dictionary. عُثمان (talk) 13:42, 19 October 2024 (UTC)
- I believe that maintaining the difference in the two scripts is necessary so as to emphasise the pluricentricity of Punjabi. A usage note can be provided to better explain this. Having consistency between scripts erases the actual conventions the different groups follow. I vote to keep the separate templates and to add a suitable usage not on both sides. RonnieSingh (talk) 16:17, 19 October 2024 (UTC)
- I should add that if the two scripts use predominantly the same forms, it is generally better to use a single module and have it conditionalize as appropriate. Otherwise you have a lot of duplicated code. This has been discussed before in the context of how to avoid duplication of definitions. Benwing2 (talk) 20:49, 19 October 2024 (UTC)
- Wait so how exactly are you supposed to avoid duplication of definitions? —AryamanA (मुझसे बात करें • योगदान) 01:38, 21 October 2024 (UTC)
- See Wiktionary:Beer_parlour/2024/April#Punjabi_vs._"Western_Panjabi". This was the BP thread where this was discussed in detail. Benwing2 (talk) 03:06, 21 October 2024 (UTC)
- I second this, yes. Just to conditionalise the same module. RonnieSingh (talk) 16:51, 22 October 2024 (UTC)
- Wait so how exactly are you supposed to avoid duplication of definitions? —AryamanA (मुझसे बात करें • योगदान) 01:38, 21 October 2024 (UTC)
- I should add that if the two scripts use predominantly the same forms, it is generally better to use a single module and have it conditionalize as appropriate. Otherwise you have a lot of duplicated code. This has been discussed before in the context of how to avoid duplication of definitions. Benwing2 (talk) 20:49, 19 October 2024 (UTC)
- Is -āvaṇā آوَݨا / ਆਵਣਾ related to the double causative ending -ਵਾਉਣਾ as at ਬੁਲਵਾਉਣਾ (bulvāuṇā) and comparable to Hindi/Urdu -वाना (-vānā), or are they distinct? Kutchkutch (talk) 12:35, 20 October 2024 (UTC)
- No, they are distinct عُثمان (talk) 12:56, 20 October 2024 (UTC)
Category: adjectives with the same spelling as their corresponding adverbs (homographs)
[edit]I am referring to forms such as cowardly, but I am not knowledgable enough to do it myself. JMGN (talk) 11:27, 19 October 2024 (UTC)
What if only non-standard spellings are used?
[edit]What to do if non-standard spellings are there, but no standard spelled form is known in use? I came across this problem while creating entries for dialectal forms for ankle malleolus in Norwegian, and all of them are in standard spelling would be compounds of okle + kule. And this word itself (oklekule) is pretty normal to expect to find in some or another book or, in the worst case, in some random blog. But how surprised I were to find the word oklekule not attested nowhere! Tollef Salemann (talk) 20:13, 19 October 2024 (UTC)
- @Tollef Salemann Ideally, pick one of the nonstandard spellings (whichever is most common) as the "canonical" form that hosts the definition, and make the other spellings be alternative forms using
{{alt form}}
(or{{alt spell}}
if the pronunciations are the same, but it looks in this case like they aren't). Alternatively, you can host the same definition(s), if short enough, in more than one place and identify each one as having alternative forms using{{alt}}
under an "Alternative forms" heading; but that risks duplication. If the prescribed ("standard") spelling is completely unattested, it probably shouldn't be present as a lemma, but if it's rare but attested, it can be defined as an alt form and given labels like{{lb|nn|prescribed|but|rare}}
or similar. Benwing2 (talk) 20:56, 19 October 2024 (UTC)- The most common form is a good idea for simple words. This one is made of two words, both with very obvious standard spelling, which should only be oklekule. Maybe there are any other examples of such words in other languages? Tollef Salemann (talk) 21:23, 19 October 2024 (UTC)
- Old English editors seem to have chosen to just use the standard form: if I'm remembering correctly, entries with "ie"-spellings such as ielfen have been created freely here on Wiktionary based on etymological/inter-dialectal correspondences regardless of whether that particular spelling is attested or not (this diphthong was only a distinct sound in early West Saxon).--Urszag (talk) 21:04, 19 October 2024 (UTC)
- I agree with that practice for Old English but I think that extinct languages are a special case because we necessarily have gaps in attestation. For living languages that aren't LDL, if a word isn't attested it probably isn't accidental. Benwing2 (talk) 21:09, 19 October 2024 (UTC)
- @Tollef Salemann: What about oklekul? Chuck Entz (talk) 22:13, 19 October 2024 (UTC)
- The mystery is solved! Tollef Salemann (talk) 08:15, 20 October 2024 (UTC)
Users' Birthdays
[edit]Hello,
You are welcome to drop your birthday on User:Flame, not lame/Birthdays. Please do so in chronological order, and do not record others' birthdays without their permission.
Thank you Flame, not lame (Don't talk to me.) 22:56, 19 October 2024 (UTC)
- It’s up to users, but to me this seems like an inadvisable idea for data protection and privacy reasons. — Sgconlaw (talk) 23:09, 19 October 2024 (UTC)
- That is valid. I will not write about other users without their permission. Flame, not lame (Don't talk to me.) 00:43, 20 October 2024 (UTC)
- What, you wouldn't support a user page where Wiktionary editors write their mothers' maiden names? — SURJECTION / T / C / L / 10:52, 21 October 2024 (UTC)
- Whenever a user submits an edit on Wikimedia, he or she irrevocably agrees to release his or her text under the CC BY-SA 4.0 License and GFDL. Flame, not lame (Don't talk to me.) 11:17, 21 October 2024 (UTC)
Cognates in etymologies for New Indo-Aryan languages
[edit]Pinging @Pulimaiyi, @Svartava, @Kutchkutch (and anyone else is free to chime in!). So, we have some NIA entries with massive cognate lists. When the ancestor of these NIA words (usually a Prakrit or Apabhramsa word) has a complete entry with descendants list, I believe the cognate list becomes redundant. I think then we should remove the long list in favour of centralising the information in the Prakrit/Apabhramsa entry. I just did this at Hindi बोलना (bolnā), see the edit history for an example. Is this acceptable for you all? —AryamanA (मुझसे बात करें • योगदान) 01:37, 21 October 2024 (UTC)
- This has already been discussed a few times. For a related discussion see
- The consensus seems to be that in most cases, if the ancestor has a complete entry with descendants list, then most cognates can be removed from the cognates list.
- Perhaps Early New Indo-Aryan languages should be exempt since it is helpful to have a comparison with other contemporaneous historical chronolects.
- If it is comparatively advantageous to have a small list of cognates to highlight certain important cognates, then that could potentially be allowable.
- Certain important cognates would be geographically nearby languages, cognates within the same subfamily or cognates that share a certain typological feature that most other cognates do not have.
- A cognates list on a Marathi entry could be entirely omitted or be limited to show:
- Varhadi & Konkani (to compare other Southern Indo-Aryan languages)
- Gujarati (to compare the neighbouring state language)
- Ahirani (which is transitional between Southern Indo-Aryan and Western Indo-Aryan)
- or Hindi/Urdu (to compare with the regional lingua franca).
- A cognates list on a Marathi entry could be entirely omitted or be limited to show:
- Deciding which cognates are comparatively advantageous could possibly lead to some sort of bias.
- Kutchkutch (talk) 02:21, 21 October 2024 (UTC)
- Agreed, for pages like बोलना (bolnā) where the lists can be very long for NIA terms, we could remove all cognates since a complete list for that would be found on the ancestor page in that case.
- I also agree with Kutchkutch that for Early NIA cognate lists could be exempt because that is a very interesting.
- The listing of other "interesting" cognates on NIA entries could be on the editor's discretion but in general we could move towards completely avoiding long and regular/expected cognate lists since that would be completely available now in the centralized descendants section of the ancestor page. Svartava (talk) 03:39, 21 October 2024 (UTC)
change in color to nyms, usex, affixusex
[edit]@Ioaxxere It looks like you changed the color of usexes, nyms and such without a prior discussion. Lots of people commented in Discord, some liking it, some not. IMO in general these sorts of highly visible changes need discussion beforehand so they don't come as surprises. @AG202 asked me to revert it pending discussion, which seems reasonable to me, so I have gone ahead and done it. This revert is without prejudice to the change itself; it's just to encourage discussion to make sure there's a consensus in favor of this change. Benwing2 (talk) 05:31, 21 October 2024 (UTC)
- The change in question was this: [3] Benwing2 (talk) 05:32, 21 October 2024 (UTC)
- Thank you. I'd oppose such a change until we have ample discussion from other language communities, especially those that don't use the Latin script. Font color alterations aren't really that preferable for ex: Korean, especially when compared to the blue and red (and yellow/orange) text that often exists on the same line. Also, I'm concerned about accessibility. Let's please make sure to run major changes like this with everyone, as I've mentioned many times before. AG202 (talk) 05:35, 21 October 2024 (UTC)
- I personally have no strong feelings. It's a small change and for me, barely perceptible. If it increases readability, why not? Vininn126 (talk) 09:15, 21 October 2024 (UTC)
- OK, I copied some of the comments from Discord so far:
- Vininn126 (not Polish) — Today at 1:36 AM does anyone have an example what it looked like?
- User:LunaEatsTuna (*tablet*) — Today at 1:53 AM (posted screenshot)
- Vininn126 (not Polish) — Today at 1:57 AM Thanks
- [1:57 AM] I hardly see a difference
- [1:57 AM] I do, but hardly
- Svartava — Today at 1:59 AM As a user of eye comfort/night light, I also
hardly see a difference
and can't say which I find better - User:LunaEatsTuna (*tablet*) — Today at 2:01 AM For me it is easier to ignore as the text is a different color Which I kinda vibe with since, at a glance, I can see and register all of the senses first Makes it less clutter-y for me
- >User:LunaEatsTuna (*tablet*) For me it is easier to ignore as the text is a different color Which I kinda vibe with since, at a glance, I can see and register all of the senses first Makes it less clutter-y for me
- AryamanA — Today at 2:02 AM yeah i liked this as well
- Soap — Today at 2:44 AM i've had usexes in red for about a year now. it makes them stand out
- [2:44 AM] so i like the idea of them being in a different color. maybe if we don't make it default, we can at least pass around an eaasily copied line of CSS code to do it
- hythonia — Today at 3:39 AM perhaps usexes could use the <marquee> tag
- Benwing2 (talk) 09:18, 21 October 2024 (UTC)
- OK, here is earlier commentary. Note, this (and the above commentary) is all in the #general channel.
- Stujul — Yesterday at 3:46 PM Usexes are grey now? (:open_mouth: emoticon)
- User:LunaEatsTuna (*phone alt*) — Yesterday at 3:50 PM I just saw that myself! (:sob: emoticon)
- [3:50 PM] I thought it was manual.
- >I thought it was manual.
- Stujul — Yesterday at 3:56 PM What do you mean manual?
- >Stujul What do you mean manual?
- User:LunaEatsTuna (*phone alt*) — Yesterday at 3:59 PM That someone specifically made it grey themselves.
- [3:59 PM] With a template or wikitext.
- Stujul — Yesterday at 3:59 PM Ohh
- User:LunaEatsTuna (*phone alt*) — Yesterday at 4:06 PM Honestly I love the grey text
- Stujul — Yesterday at 4:08 PM Yes I like it too
- Soap — Yesterday at 5:20 PM my css overrides it
- [5:21 PM] btw, i kept this quiet because nobody else is complaining, so it might be just me. but i noticed a few days ago that on m y tablet, all links are underlined and blue
- [5:21 PM] redlinks, bluelinks etc ... all appear the same. on both wiktionary and wikipedia
- [5:21 PM] no Prefs setting can override it. its only on the tablet
- [5:21 PM] that t ablet is old so it might be a browser issue
- AryamanA — Yesterday at 7:32 PM am i losing my mind or are usexes light gray now
- >AryamanA am i losing my mind or are usexes light gray now
- Ser be etre shi — Yesterday at 8:01 PM there's been plenty of comments about this change. yes it's a change (:thumbsup: reaction by AryamanA)
- benwing — Yesterday at 11:28 PM Ioaxxere changed it in [4]
- [11:28 PM] honestly i think he should have posted to the BP before doing this
- AryamanA — Yesterday at 11:53 PM i see!
- [11:54 PM] i think it's pretty good actually, just was wondering when it happened
- AG202 — Today at 12:27 AM can we please revert until discussion has been had
- [12:29 AM] that is one of the things that should've been brought up to BP
- [12:32 AM] affecting every language without discussion is exactly something that I've brought up as frustrating before
- Benwing2 (talk) 09:50, 21 October 2024 (UTC)
- OK, here is earlier commentary. Note, this (and the above commentary) is all in the #general channel.
- color is of course good, WT is very black and white. cnrtl uses color well. Anyway, I suggest going even further - using rainbow coloring, or flashing text, or making a ding sound when the cursor hovers over it, or having homonyms fly around the screen on a roflcopter, and hyponyms spiralling in from each corner of the screen to the tune of Bach's Orchestral Suite no. 1 in C major BWV 1066. P. Sovjunk (talk) 09:26, 21 October 2024 (UTC)
- As seen in the Discord discussion above, I like the change. It helps differentiate the usexes from the definitions. Though, if it is possible, I would like it to be an optional change, as it may be hard to read for some users.
- Stujul (talk) 12:17, 21 October 2024 (UTC)
- Yeah this kind of stuff should really be discussed on-wiki rather than just on Discord; the Discordification of the community is an unfortunate development of the past couple of years. Major changes should always require on-site discussion. — Mnemosientje (t · c) 12:29, 21 October 2024 (UTC)
- I
don't have strong views about the colour change, butagree that this sort of change should be discussed on-wiki. (Updated: sorry, I thought the colour change referred to was the one relating to boxes. I didn't see the colour change in question, so I reserve comment.) — Sgconlaw (talk) 13:47, 21 October 2024 (UTC)
- I
- No worries. I'm glad everyone was able to try it out for the couple hours that it was live and form an opinion. We'll have to see whether anyone has strong feelings, although in my opinion it is barely perceptible but serves to emphasize the definitions a little bit more (it's inspired by M-W's site, e.g. [5]). Btw, @AG202, Stujul, with regards to accessibility, the text colour achieves a AAA WCAG rating as seen here so I don't expect that to be an issue. Ioaxxere (talk) 15:55, 21 October 2024 (UTC)
- First of all, why wasn't this discussed on Wikt? Second, what about langs that don't have usexs like English (eg Chinese)? Are those accessible? CitationsFreak (talk) 17:15, 21 October 2024 (UTC)
- No one should be making any sitewide changes without on-wiki discussion. It's incredibly poor judgement to even think that's a good idea. —Justin (koavf)❤T☮C☺M☯ 18:01, 21 October 2024 (UTC)
- @CitationsFreak: Chinese has its own usex system through Module:zh-usex so it isn't affected. Interestingly, they have it so the text is black but the romanization is grey. The shade of grey used there is very hard to read in dark mode, so in that regard it isn't accessible, but that's straightforward to fix. Ioaxxere (talk) 18:26, 21 October 2024 (UTC)
- First of all, why wasn't this discussed on Wikt? Second, what about langs that don't have usexs like English (eg Chinese)? Are those accessible? CitationsFreak (talk) 17:15, 21 October 2024 (UTC)
Blotto's game
[edit]User:SemperBlotto may be gone but I am negotiating with IFDB to store his zombie game forever [6]. Hint: don't go down the stairs at the beginning. 2A00:23C5:FE1C:3701:74C9:3FA9:762E:473D 18:20, 21 October 2024 (UTC)
- Who are you, IP? P. Sovjunk (talk) 18:56, 21 October 2024 (UTC)
- It's User:Equinox as the IP claims (and likely is IMO, but obviously it can't be proved without check-user). Svartava (talk) 19:09, 21 October 2024 (UTC)
- Hmm, I thought Equinox retired. He should get a new account P. Sovjunk (talk) 19:14, 21 October 2024 (UTC)
- The IPs who are actually good editors generally don't want to create account(s), and there is no way he has not thought about that yet... Svartava (talk) 19:41, 21 October 2024 (UTC)
- So, how does one win the game? I wore the bikini, but it didn't help. P. Sovjunk (talk) 21:56, 21 October 2024 (UTC)
- The IPs who are actually good editors generally don't want to create account(s), and there is no way he has not thought about that yet... Svartava (talk) 19:41, 21 October 2024 (UTC)
- Hmm, I thought Equinox retired. He should get a new account P. Sovjunk (talk) 19:14, 21 October 2024 (UTC)
- It's User:Equinox as the IP claims (and likely is IMO, but obviously it can't be proved without check-user). Svartava (talk) 19:09, 21 October 2024 (UTC)
Isan Romanization
[edit]Should Isan be romanized as Lao (to which they are most closely related) or as Thai?. Rodrigo5260 (talk) 19:44, 21 October 2024 (UTC)
'Wikidata item' link is moving, finally.
[edit]Hello everyone, I previously wrote on the 27th September to advise that the Wikidata item sitelink will change places in the sidebar menu, moving from the General section into the In Other Projects section. The scheduled rollout date of 04.10.2024 was delayed due to a necessary request for Mobile/MinervaNeue skin. I am happy to inform that the global rollout can now proceed and will occur later today, 22.10.2024 at 15:00 UTC-2. Please let us know if you notice any problems or bugs after this change. There should be no need for null-edits or purging cache for the changes to occur. Kind regards, -Danny Benjafield (WMDE) 11:28, 22 October 2024 (UTC)
Appendix-only entries in categories
[edit]In my opinion, appendix-only entries (entries that do not meet the usual WT:CFI) in languages that are themselves not appendix-only should not appear in main categories, yet they currently apparently do. If these entries don't meet WT:CFI and have a spot in the main body of the dictionary, then they also shouldn't appear on category lists that ought to be dedicated to that main body. — SURJECTION / T / C / L / 14:52, 22 October 2024 (UTC)
- Not really supportive of this. The number of appendix entries in, say Cat:English lemmas is minimal (121 out of 778573, or less than 0.02%), and the vast majority are either snowclone entries, which are hard enough for our readers to discover as it is (so why make it harder?), and Minecraft jargon, which ought to be merged into a single glossary-style page at Appendix:Minecraft rather than being laid out as individual entries (and then they disappear from the categories anyway). This, that and the other (talk) 05:18, 23 October 2024 (UTC)
Linking Philippine place names
[edit]Followed through from User talk:Mlgc1998#Consensus on PH places:
I have introduced a way to link Philippine place name entires with each other, by utilizing {{meronyms}}
, {{coordinate terms}}
, and {{hyponyms}}
on each definition line. Examples are in Camp One, Marcos, and Atok. This has numerous advantages:
- It is easier to see which is it referring to (not split up into different headings)
- It clearly states hierarchy (purok/sitio < barangay < (district, if applicable) < municipality/city < province) (sometimes, purok < sitio, like Gusaran)
- It can delineate from a general into a specific barangay (eg. Quirino Hill & Bayan Park)
- It fits neatly with other symantic relations like
{{synonyms}}
(eg. Pongayan) - It is easy to just collapse them and make them hidden.
However, I was pointed out by @Mlgc1998 that these should go instead to the "See also" portion. Examples on how they arranged it are in Paco, Malate, and Port Area.
While I am open to accepting it, I have some reservations:
- Will it confuse readers that they are split up, especially on different places with the same names?
- What about the most commonly used name Poblacion? Will there just be endless scrolling under "See also"?
- How can it delineate hierarchy, knowing that people outside the Philippines doesn't instinctively know that barangays are meronyms of cities/municipalities, sitios are meronyms of barangays, some puroks are meronyms of sitios while others are meronyms of barangays, etc.?
- What about the name for a group of barangays (like Upper Bauko and Special Geographic Area)?
- How can it delineate from a general into a specific barangay?
Looking forward for input from others. — 🍕 Yivan000 viewtalk 08:31, 24 October 2024 (UTC)
- To streamline the process, I have made
{{list:places in the Philippines/en}}
which supports both options. It also eliminates the concern of upkeep, since all are editable in the module pages as opposed to each entry page. - For clarification, I am asking on which approach is better: (Camp Four used as an example)
- The inline definition approach:
- A place in bla bla bla
- Meronyms: Balococ, Benmetao, Camp 5, Camp 6, Canubas, Forestry, Gawad Kalinga, Goldstream, Lablab 1, Lablab 2, Liwliw, Manayon, Maramal, National Road — sitios of Camp Four
- Coordinate terms: Ansagan, Camp Four, Camp One, Camp Three, Nangalisan, Poblacion, San Pascual, Tabaan Norte, Tadiangan, Taloy Norte, Taloy Sur, Twin Peaks — barangays of Tuba
- A place in bla bla bla
- The 'See also' approach:
See also
- (sitios of Camp Four):
- (barangays of Tuba):
- Note also the aforementioned pros and cons from my earlier message. TY.— 🍕 Yivan000 viewtalk 09:34, 28 October 2024 (UTC)
Towards a Standardization of Inflection Tables
[edit]Currently, there seems to be no policy on what inflection tables should look like on Wiktionary (the only thing I found was WT:Templates#Inflection-table templates, which only states they should preferably be collapsible). Looking through Category:Inflection-table_templates_by_language, this causes a great variety in how inflections are presented. This is not necessarily a problem, but some do pose some issues. I would like to propose a few points to improve the reading experience of readers, without inhibiting editors' freedom in choosing a table style too much.
- Inflection tables should not have a fixed width. This is mainly an issue for mobile users. Some templates use a fixed width, which can cause the table to exceed the screen size, making you able to scroll the entire page sideways. See for example
{{lv-decl-possessive pronoun}}
. Others set the width to be a percentage of the screen size, which often makes the table very narrow on mobile screens (for example:{{huu-decl-noun}}
). This can be fixed by usingmax-width
instead of justwidth
.
- Side-note: there are also some templates that use
width:100%
, such as{{da-noun-infl-base}}
. I don't personally like it, but I suppose there is no problem with this.
- Inflection tables should comply with accessibility contrast requirements. Some templates use background colors that make the text quite hard to read. For example:
{{eo-conj}}
(see here). I believe we should strive for WCAG AAA compliance for black text, and WCAG AA for links (since AAA is then impossible). I made a table with the darkest colors one can use as backgrounds in several colors here. One can also use tools such as [7] and [8] to check compliance. - Inflection tables should be readable in both light and dark mode. Most inflection tables currently have hard-coded colors. This is understandable, as dark mode is quite a recent development for Wiktionary, but it usually makes them very hard to read in dark mode. Editors should use colors from MediaWiki:Gadget-Palette.css (which, in my opinion, could use some more colors) or use a custom style sheet, so that the colors can be varied between the themes. I understand this is already being worked on.
I am hoping these points are uncontroversial, so that they can be made into policy. Please share your thoughts and opinions about this. Stujul (talk) 16:17, 25 October 2024 (UTC)
- Proposal 1 feels uncontrovserial, and I support that.
- There has been some discussion over the Discord over the inflection table colors. I know that @Theknightwho has expressed supprt in changing the inflection table due to accessibility, while @Thadh is against that due to the cultures that speak the langs having some sort of connection to the specific color of the table. CitationsFreak (talk) 17:21, 25 October 2024 (UTC)
- Yes, as CF says, the second change is controversial. Having a defined set of colours to choose from means that the various templates cannot be distinguished as well, which in turn means various languages will be the same. This is a problem. Some people think it isn't, but people actually like to see their language distinguished in some way or another from the mass of tables, and usually this distinction is preferred in the colour of the template, which is then usually shared among related languages. Boo to uniformity! Thadh (talk) 18:11, 25 October 2024 (UTC)
- To be clear: I am not pleading for full uniformity. I have not proposed a "defined set of colours to choose from", I only said that the colours chosen should comply with these contrast requirements. And this restriction is not as restrictive as it may seem: in fact, most templates I've seen already comply with these contrast regulations.
- I do agree that the variety that we have is a good thing, but accessibility should never be compromised on.
- Stujul (talk) 14:37, 26 October 2024 (UTC)
- 1. is not straightforward. The best solution I can come up with is making the table scroll horizontally instead of the entire page. Forcing the table to be narrow or wrapping words cannot be considered an acceptable solution.
- 2. and 3. are much easier if all inflection and other language-specific templates used TemplateStyles. Converting templates to use it is relatively straightforward, but tedious and highly repetitive, yet difficult to automate. I've ensured the Finnish, Ingrian and Votic inflection templates (unless I forgot some) use TemplateStyles and support dark mode correctly. The end result is much better than what can be done by sticking strictly to the palette. — SURJECTION / T / C / L / 22:12, 25 October 2024 (UTC)
- Generally I'm in favor of standardization in this respect. I would like to add that it would be nice to standardize the colors somewhat, because some colors (IMO) look nicer than others. I particularly like the blue theme used for Slavic and certain other languages, and I don't really like tables that use lots of different contrasting colors, rather than using shades of the same color (it looks gaudy and probably isn't accessibility-compliant for people who are colorblind). Benwing2 (talk) 08:12, 26 October 2024 (UTC)
- Rather than uniformity, I personally would prefer to see some easily noticeable difference between the declension tables of different languages, which are co-located on the same page. It happened more than once that I landed on a weird looking declension table and looked at it in confusion for a few seconds, before finally realizing that it's just a different language. So I think that having slightly different background colors of at least the Belarusian, Russian and Ukrainian declension tables could help to resolve this at least for me. But I understand that the others are probably in favor of exactly the same uniform blue theme everywhere for the sake of uniformity. --Ssvb (talk) 00:25, 27 October 2024 (UTC)
- I'm fine with different languages having different appearance, but CAT:Inflection-table templates by language currently has 397 subcategories (I hope it's just a beginning!), so there will be a point where having all of the languages easily recognizable by appearance will become too hard to achieve. Chuck Entz (talk) 01:19, 27 October 2024 (UTC)
- I'm talking about closely related languages with many cognates and identical spelling of lemmas, which tend to share the same wiki pages. Such as the East Slavic languages group. It doesn't matter if any of the other nearly 400 languages outside of that group happen to share the same color, because they almost never clash in practice. For example, have a look at the pages гора or лук. Bulgarian and Macedonian have different styles of the declension tables and the number of cases is different, so any confusion is less
unlikely. But Russian and Ukrainian have nearly identically shaped tables. And лось is a purely East Slavic page. Different background colors of the declension tables would help to visually differentiate them. --Ssvb (talk) 14:05, 27 October 2024 (UTC)- This is honestly a good argument for the controversial splitting of pages by language, as it shouldn't be necessary to be able to differentiate languages by how the inflection table looks haha. But let's not open that can of worms.
- Stujul (talk) 16:27, 29 October 2024 (UTC)
- I'm talking about closely related languages with many cognates and identical spelling of lemmas, which tend to share the same wiki pages. Such as the East Slavic languages group. It doesn't matter if any of the other nearly 400 languages outside of that group happen to share the same color, because they almost never clash in practice. For example, have a look at the pages гора or лук. Bulgarian and Macedonian have different styles of the declension tables and the number of cases is different, so any confusion is less
- I'm fine with different languages having different appearance, but CAT:Inflection-table templates by language currently has 397 subcategories (I hope it's just a beginning!), so there will be a point where having all of the languages easily recognizable by appearance will become too hard to achieve. Chuck Entz (talk) 01:19, 27 October 2024 (UTC)
- Rather than uniformity, I personally would prefer to see some easily noticeable difference between the declension tables of different languages, which are co-located on the same page. It happened more than once that I landed on a weird looking declension table and looked at it in confusion for a few seconds, before finally realizing that it's just a different language. So I think that having slightly different background colors of at least the Belarusian, Russian and Ukrainian declension tables could help to resolve this at least for me. But I understand that the others are probably in favor of exactly the same uniform blue theme everywhere for the sake of uniformity. --Ssvb (talk) 00:25, 27 October 2024 (UTC)
- It may not be straightforward or have an ideal solution, but anything is better than scrolling the entire page. I think it would be good to have a guideline with some "approved" examples of inflection tables with good styling practice so that things like this don't spread from people copying other templates.
- Stujul (talk) 16:26, 29 October 2024 (UTC)
- I would argue that forcing words to wrap is a worse solution than having the entire page scroll. Both are terrible, but the former is simply worse. — SURJECTION / T / C / L / 20:06, 30 October 2024 (UTC)
- Generally I'm in favor of standardization in this respect. I would like to add that it would be nice to standardize the colors somewhat, because some colors (IMO) look nicer than others. I particularly like the blue theme used for Slavic and certain other languages, and I don't really like tables that use lots of different contrasting colors, rather than using shades of the same color (it looks gaudy and probably isn't accessibility-compliant for people who are colorblind). Benwing2 (talk) 08:12, 26 October 2024 (UTC)
- Fully supportive of all points. To take one example relating to point 2, the Latin noun and adjective declension tables
{{la-ndecl}}
and{{la-adecl}}
are notorious for using, well, questionable colour choices, but to me the bigger problem with them is the terrible contrast in the header cells. Not to mention that the look and feel is totally different to the verb conjugation table{{la-conj}}
! - I feel that, even with a standardisation effort, there is definitely still room for individuality in terms of distinctive colour palettes for certain languages and language families, as Thadh mentions.
- My suggestion is to come up with two broad "model layouts" for inflection tables: (1) a "narrow" layout for situations where there are few inflections (e.g. German
{{de-ndecl}}
, Celtic mutation boxes, Tocharian{{txb-decl-noun}}
, ...) - this would not have a set width at all (simply adapting to fit its content), would likely use 100% font size, and may be non-collapsible when it only has a handful of rows; and (2) a "wide" layout which occupies the full width of the page on desktop devices (e.g. most Romance verb conjugations) - this may use 90% font size. This, that and the other (talk) 09:13, 26 October 2024 (UTC)- Yes, those tables would benefit from an overhaul. About the different look: it would probably make sense to encourage editors to keep the style the same across tables in the same language. I have seen multiple examples where this isn't the case, which goes against the idea of languages being recognizable through their table style.
- The idea of your two layouts sounds good, but I'm not sure I completely follow it. How would these behave on mobile? Also, I'm not sure that changing the font size is a good idea.
- Stujul (talk) 16:35, 29 October 2024 (UTC)
- Support - I don't have much to add here, as these proposals all seem completely reasonable. Theknightwho (talk) 14:41, 26 October 2024 (UTC)
- @Stujul: Thank you for pointing this out. I've already fixed dozens of inflection tables using hard-coded widths, but there are a lot of obscure ones left. When it comes to using NavFrames, there are only two sensible options: not specifying the width, which makes it take up the whole screen width, or setting
max-width: 40em
(or a similar number) which tries to do the same thing but stops early if it reaches the specified size (there's also the issue of overflow but that's another story). - As for colours: your table is really cool but I don't think we should ever use 100% saturated colours for backgrounds because they are blindingly bright. I would encourage everyone to use the Palette colours, for which you can see the accessibility information here. @Thadh, the goal is not uniformity but convenience, because I can write
<span style="color: var(--wikt-palette-blue)">some text</span>
and my text ends up blue and accessible everywhere with practically no effort on my part. Anyone is welcome to contribute new colours although ideally we should avoid having tons of almost-identical colours. Ioaxxere (talk) 15:38, 26 October 2024 (UTC)- @Ioaxxere: I think the main problem has never been light/dark mode but whether or not pastel colours should be mandatory. I think doing that would be a grave mistake. But other than that, I'm fine with there being light/dark mode variants of colours, as long as they are still recognisable as the intended colour. Thadh (talk) 15:43, 26 October 2024 (UTC)
- Yes, it seems that using
max-width
together withstyle="overflow:auto"
seems to work the best for most cases. Maybe also"white-space:nowrap"
to prevent the wrapping as Surjection mentioned above, but I've not seen that in any template, so maybe there is a good reason to not use it. - Maybe my table is not as useful as I'd hoped it to be then haha. In any case, I like the convenience of the palette as you mention, but I don't really like the palette as it currently is. There seems to not really be any structure to the chosen colors. It could benefit from organizing the palette colors by use-case, as it seems to be on ru:w:MediaWiki:Gadget-common-site.css, on which it is based. In the context of inflection tables, this could mean specifying colors for the header and background.
- Stujul (talk) 16:50, 29 October 2024 (UTC)
- The palette is simply way too small for it to be used more widely in inflection templates. At the very least we need a graded color system where we have a hue + different levels of brightness, e.g. blue-1 to blue-5 where blue-1 has the least contrast (the lightest in light mode, the darkest in dark mode) and blue-5 has the most (the closest to a pure blue in both). — SURJECTION / T / C / L / 20:11, 30 October 2024 (UTC)
- @Ioaxxere: See WT:Information desk/2024/October#Request assistance in modifying the styles to accommodate dark mode where @Ryanlo713 has compiled quite a long list of candidates. Chuck Entz (talk) 00:24, 27 October 2024 (UTC)
- Support I must support your proposal, as it has consistently been a source of annoyance for me. What are the steps we can take to implement this, and how can we proceed?
- Σ>―(〃°ω°〃)♡→L.C.D.(-{に〇〇する}-) 14:52, 30 October 2024 (UTC)
@Stujul, CitationsFreak, Thadh, Surjection, Benwing2, Ssvb, Ioaxxere, Ryanlo713 I've had a red hot go at mocking up a standard design template. Take a look at User:This, that and the other/inflection table standardisation and share your thoughts, in particular, whether you prefer Style A or Style B. Surjection is right that the Wiktionary palette will need to be expanded, but I tried to do the best with what is currently on offer. (I might not have ready access to a computer in the coming week or so, so replies may be delayed.) This, that and the other (talk) 10:42, 31 October 2024 (UTC)
- My two cents: we want some kind of cell borders, but their color should be relatively muted. I'm not convinced that text is better centered than not. — SURJECTION / T / C / L / 10:47, 31 October 2024 (UTC)
- Support Thanks for this. I'm working on extracting conjugation data for offline viewing, and it's a pain to adapt the parser to the various table formats. Having a more standardized format will help. But perhaps this proposal is mostly related to layout/colors, without touching the table structure itself? - Jberkel 11:10, 31 October 2024 (UTC)
- I agree that we want cell borders; they strike me particularly necessary (or at least, their absence is particularly confusing) when tables have multiple cells (rows) in one column correspond to one (larger, merged) cell in another column, like this (apologies that I can't off the top of my head think of a local, Wiktionary example that does this in the "contents" as opposed to just the "labels" section of the table, but I think they exist): if the merged cell has multiple words in it, then without cell borders it may be impossible to tell they belong to one multi-row merged cell as opposed to separate cells/rows... - -sche (discuss) 18:00, 31 October 2024 (UTC)
- @Ioaxxere, This, that and the other perhaps not appropriate, but relevant: I was trying to make a table with params for grk greek periods with lang params (to apply specials, like colours), number columns num=sg or num=pl genders (with outer and inner borders applied), dat=0 (no dative)... or acc=- or acc=0 to make every cell, every case visible or not, with dashes (for empty), grey expected but not attested, asterisks etc. notes= User:Sarri.greek/template4 (the first empty table Module:User:Sarri.greek/grk-nouns-decl). for forms: Template:User:Sarri.greek/lse. Sorry: I do not know how to write templates or modules. Thank you. ‑‑Sarri.greek ♫ I 12:22, 31 October 2024 (UTC)
- I prefer Style B as it makes it clearer which row and column a certain word belongs to, especially when there are multiple words in a single cell.
- Your use of a lighter text color against a darker background is something I had not considered, and I do like the look of it. But it does bring me to another question: some templates use links in the headers to clarify their meaning (for example
{{nl-conj-wk}}
and{{sv-decl-noun}}
). I think this is good practice as many readers will not be familiar with all the grammar terms, but it does make it harder to pick good background colors. How do you think we should handle this? - Stujul (talk) 13:44, 31 October 2024 (UTC)
English usage examples in Translingual entries
[edit]At "+" there are several usage examples, of which "3 + 2 = 5" is Translingual, but most of the others are in English. How do we handle this? Even though it's a bit odd, I could understand that Translingual usage examples are in English because this is the English-language wiktionary. Such a policy should be mentioned on the page wiktionary:About Translingual. A second question would be: What about things that are Translingual, but not found in English? Would they get usage examples in other languages? 92.218.236.85 21:15, 26 October 2024 (UTC)
- Translingual is not a language, so the usage examples need to be in some language. I agree that it generally makes sense to use English, since this is the English Wiktionary, but there may be occasional reasons to depart from this principle (for example, terms that are not used in English). This, that and the other (talk) 23:35, 26 October 2024 (UTC)
Why are many English surnames labelled as countable and uncountable?
[edit]We list several thousand English proper nouns as being both countable and uncountable, most of which are surnames (e.g. Selby). Maybe I'm missing something here, but I really don't follow how that makes any sense. @Donnanz seems to have made this change on a number of entries, but I don't know how widespread the practice is. Could someone please fill me in? Theknightwho (talk) 22:23, 26 October 2024 (UTC)
- It only happens with proper nouns that include surnames where someone has added the plural, I don't add those myself. Usually the plural would not apply to place names. DonnanZ (talk) 22:47, 26 October 2024 (UTC)
- I have only done this in entries that include both surnames and place names. DonnanZ (talk) 23:39, 26 October 2024 (UTC)
- Countable in some senses, uncountable in others is pretty much the default for proper nouns: very few are completely impossible to pluralize, but pluralization also generally necessarily involves a change in meaning, so you could say that some senses are "uncountable". From that perspective, you could question instead why there are any labeled as only countable (or only uncountable). Overall, I would have to say that treating the countable/uncountable distinction as a lexically specific piece of information in such cases doesn't make that much sense. (This came up previously with the RFV for Latin plural forms of Oedipus, which are in fact attested because in Latin, like in English, it's not impossible to add plural endings to a proper noun.)--Urszag (talk) 23:04, 26 October 2024 (UTC)
- For example: "There aren't that many people with the surname Entz" (uncountable), vs. "There aren't that many Entzes" (countable). Chuck Entz (talk) 23:22, 26 October 2024 (UTC)
- @Chuck Entz Surely by that logic "the word happy" is an uncountable use, which doesn't really make sense to me. Definiteness doesn't make it uncountable.
- @Urszag I was always under the impression that "uncountable" was being used to mean "mass noun", but are we taking it to mean "the plural is not used"? I'm not really sure that's grammatical, is it? It's just a semantic quirk that we don't usually talk about more than one of a proper noun, even though we very much can. It's very different to information, where the plural can only refer to different kinds of information, and it's grammatically incorrect to use it in any other way: compare "he gave me a glass of waters" (ungrammatical use of an uncountable noun) to "we visited three Parises" (semantically bizarre, but grammatically correct). Theknightwho (talk) 23:40, 26 October 2024 (UTC)
- Good point. I'm not sure whether this really falls under the definition of "uncountable". Also, on second thought, I'm not really sure whether it is ever useful to include the label "countable and uncountable" on a headword line for terms like this (or even for other terms: it seems to immediately raise the question "depending on what?"). I feel like the best thing to do is just mark any uncountable uses (if there are any) with a label on the relevant definition line. That is, I don't think there would be any loss of particularly useful information if "Russia (countable and uncountable, plural Russias)" was just replaced by "Russia (plural Russias)", although I guess you could argue that there's some small value in implying that the plural form might not be commonly used (but that would be better expressed by "usually uncountable" rather than "countable and uncountable", and it's kind of obvious from the definition of such terms that the plural might or might not be used depending on the context).--Urszag (talk) 23:48, 26 October 2024 (UTC)
- @Urszag Yes, I'd agree with that, though I'd prefer "chiefly in the singular" or some other label implying the plural isn't usually required, even though it may be grammatically valid. I'm not sure that it's even possible to have a truly uncountable proper noun, as all nouns (countable or not) can be used uncountably in colloquial language:(e.g. "there's a piece of car over there", after a crash), and any uncountable proper noun uses I can think of fall under that usage. The thing that makes a noun uncountable (in a particular sense) is when it cannot be used countably at all, and I can't think of any examples of that. Theknightwho (talk) 00:06, 27 October 2024 (UTC)
- Here's an example that has something to confuse everybody: I remember an old documentary on the US Civil War that made the point that the war changed the United States from an "is" to an "are". That is, we now say the United States "is" rather than the United States "are" when talking about the country. It changed the United States from a loose collection of entities that might secede at any time to a unified entity that had to be spoken of in the singular. I'm not really sure if that supports or refutes any of the above, since it's an ad hoc bending of grammatical categories to make a point. It does highlight the pitfalls of taking specific examples too seriously. Chuck Entz (talk) 01:00, 27 October 2024 (UTC)
- Many more pages, like Kendall, have never had the plural added. DonnanZ (talk) 11:11, 27 October 2024 (UTC)
- @Urszag Yes, I'd agree with that, though I'd prefer "chiefly in the singular" or some other label implying the plural isn't usually required, even though it may be grammatically valid. I'm not sure that it's even possible to have a truly uncountable proper noun, as all nouns (countable or not) can be used uncountably in colloquial language:(e.g. "there's a piece of car over there", after a crash), and any uncountable proper noun uses I can think of fall under that usage. The thing that makes a noun uncountable (in a particular sense) is when it cannot be used countably at all, and I can't think of any examples of that. Theknightwho (talk) 00:06, 27 October 2024 (UTC)
- Good point. I'm not sure whether this really falls under the definition of "uncountable". Also, on second thought, I'm not really sure whether it is ever useful to include the label "countable and uncountable" on a headword line for terms like this (or even for other terms: it seems to immediately raise the question "depending on what?"). I feel like the best thing to do is just mark any uncountable uses (if there are any) with a label on the relevant definition line. That is, I don't think there would be any loss of particularly useful information if "Russia (countable and uncountable, plural Russias)" was just replaced by "Russia (plural Russias)", although I guess you could argue that there's some small value in implying that the plural form might not be commonly used (but that would be better expressed by "usually uncountable" rather than "countable and uncountable", and it's kind of obvious from the definition of such terms that the plural might or might not be used depending on the context).--Urszag (talk) 23:48, 26 October 2024 (UTC)
- For example: "There aren't that many people with the surname Entz" (uncountable), vs. "There aren't that many Entzes" (countable). Chuck Entz (talk) 23:22, 26 October 2024 (UTC)
- As an aside (not worth a topic), I now have to declare whether it's AI-generated or not when uploading an image to Wikimedia Commons. DonnanZ (talk) 09:47, 27 October 2024 (UTC)
- FWIW, regarding Wiktionary's conflation of "uncountable" and "the plural is not used": this is an issue I recall Equinox bringing up several years ago, and which I have questioned at various times since then myself (one prior discussion: 2021, when someone seems to have used "uncountable" for lack of any way to display "[is countable but] does not usually pluralize"). I support the general idea of changing things to better distinguish "
is (usually) a mass noun, "we have some water"
" / "is (usually) a count noun, "we have a plan B if the launch fails" (not normally "we have some plan B if the launch fails", which makes it sound like you have some of the medicine)
" from "(usually) pluralizes
" / "(usually) doesn't pluralize
", in whatever way we can agree on. I like "chiefly in the singular", but maybe we could go even briefer: "Russia (usually singular; plural: Russias)
" or something? - -sche (discuss) 05:55, 28 October 2024 (UTC)- It's already done for headwater (chiefly in the plural). I guess they can be tailored according to circumstance, but what about the question "How many Washingtons are there in the US?" The answer would depend on whether people or places were meant. DonnanZ (talk) 15:17, 28 October 2024 (UTC)
- I have always thought that uncountable noun was synonymous with mass noun. One simple test for uncountability is attestable use with much. Much headwater doesn't make it, with our without an -s. Surnames don't meet the test, except in cases like In normal times four terms would have been too much Roosevelt. DCDuring (talk) 18:51, 28 October 2024 (UTC)
- Yes, agreed, and that's the kind of colloquial use which can take any noun (e.g. "too much house, not enough garden"). Theknightwho (talk) 18:58, 28 October 2024 (UTC)
Whitespace edits used to leave comments in history.
[edit]In sì, whitespace edits keep being used to leave comments in the history despite a talk page is already being used to discuss the comments.
28 October 2024 Theknightwho talk contribs 4,169 bytes +1 That usage note was already at the bottom, so please don't bullshit. undothank 28 October 2024 Emanuele6 talk contribs m 4,168 bytes −1 This is the lamest edit I have seen; I fixed a thing, you undid the fix. Please do not vandalise the page with whitespace edits since there is a discussion in your talk page. undo Tags: Manual revert Reverted 28 October 2024 Theknightwho talk contribs 4,169 bytes +1 Undo revision 82506619 by Emanuele6 (talk) Not vandalism. undothank Tag: Undo
https://en.wiktionary.org/w/index.php?title=s%C3%AC&diff=prev&oldid=82506654
Is it really acceptable to dirty the wikitext of the page with trailing whitespace just to leave such petty comments in history?
If it is acceptable, I am going to use this technique in the future to fixup mistakes I make in edit messages, in the future.
The wikitext is now left with a trailing space at the end of a line.
o/
emanuele6 Emanuele6 (talk) 01:55, 28 October 2024 (UTC)
- I don’t think this is a good idea as whitespace shouldn’t be randomly added at the ends to lines, etc. Use the talk page for comments. — Sgconlaw (talk) 04:48, 28 October 2024 (UTC)
- If it's an undecided matter, my position on this matter is the same. There shouldn't be any trailing whitespace in pages, and you should not just add them and leave them only to leave a comment in the history.
- In fact, I tend to clean up all the unnecessary trailing whitespace I notice in pages when I edit them on wikipedia.
- Not exactly related to this, this is not the case here, but also note that some whitespace changes can actually change how the page is rendered on certain platforms.
- I recall this edit I did on wikipedia https://en.wikipedia.org/w/index.php?title=TTNG&diff=prev&oldid=979390957
- The newline in <timeline> was invisible on PC, but it was being displayed as a literal "\n" (backslash n) on the android Wikipedia app. Emanuele6 (talk) 05:09, 28 October 2024 (UTC)
- Don't do this and don't leave anti-social, hostile edit summaries. —Justin (koavf)❤T☮C☺M☯ 05:07, 28 October 2024 (UTC)
- I agree. — Sgconlaw (talk) 05:16, 28 October 2024 (UTC)
- @Koavf Given that Benwing2 has pointed out no-one should have been reverting or making those whitespace changes, that also applies to you, so you should not have made any further edits to the page sì. Theknightwho (talk) 12:23, 28 October 2024 (UTC)
- I'm not sure why you think that what someone writes seven hours later should apply retroactively, but I disagree and you shouldn't have done what you did, which is the actual point of this thread. Your distractions and irrelevant noise are not appreciated. —Justin (koavf)❤T☮C☺M☯ 18:01, 28 October 2024 (UTC)
- @Koavf It doesn't take a genius to work out why it's relevant. Please take your personal grudge elsewhere. Theknightwho (talk) 18:34, 28 October 2024 (UTC)
- "Please take your grudge elsewhere" is actually exactly what you should be doing. Please stop with this and listen to others telling you that your prior behavior was inappropriate. —Justin (koavf)❤T☮C☺M☯ 18:35, 28 October 2024 (UTC)
- @Koavf Leaving whitespace to add points to edit histories is not something only I have done, not even particularly uncommon, and certainly does not constitute vandalism, as Emanuele6 mentioned. Benwing2 made some good points below about what should and should not have happened for reasons entirely outside of pedantry over whitespace in entries, but unless you can point me to some kind of policy on leaving whitespace in order to make comments in edit histories in particular (or even a guideline or past discussion), I'm not especially interested. Theknightwho (talk) 18:42, 28 October 2024 (UTC)
- I don't recall anyone saying that only you have done this, so in case I was somehow mistaken, I will go on record: don't do this to anyone. Anyway, as I have written multiple times, this thread is about your problematic editing and multiple editors have told you to stop it. Since it seems like you understand that you shouldn't have done it in the first place and that you seem like you're saying you won't do it again, sounds good. Have a nice day. —Justin (koavf)❤T☮C☺M☯ 18:58, 28 October 2024 (UTC)
- @Koavf Whether or not the comments were appropriate, this thread is not about my behaviour, but about whether we should be able to use whitespace to leave comments in edit histories. Two comments about that doesn't constitute a definitive consensus, I'm afraid. There are clearly situations in which it *is* appropriate, such as correcting a major mistake in an edit summary which would cause confusion. Theknightwho (talk) 19:06, 28 October 2024 (UTC)
- The thread was actually begun by someone else and that person began it because of things you did. I've asked you to stop. Please stop. There is no reason for you to keep this distraction going and to keep pinging me. —Justin (koavf)❤T☮C☺M☯ 19:12, 28 October 2024 (UTC)
- @Koavf Oh, well you'd better tell Wikipedia that w:Help:Dummy edits are a problem, despite being a widespread practice there. This thread was started with a question of whether they were appropriate, and the only mention of me was in the copied log, so no, this thread was about the question, and not about me. This is precisely why I said you were making this about your grudge, in which you have a long history of making mountains out of molehills whenever my behaviour is in question. Enough. Theknightwho (talk) 19:14, 28 October 2024 (UTC)
- I told you to stop pinging me. Stop it. Your completely exhausting behavior is so wildly inappropriate I don't know why you think it's acceptable. Go away and do something else and quit making this a personality-based grudge and then acting like I'm making it a personality-based grudge. —Justin (koavf)❤T☮C☺M☯ 19:16, 28 October 2024 (UTC)
- Well, you didn't, but what I'm actually doing here is preventing you from claiming some kind of false consensus against a well-established practice because you want excuses to call my behaviour inappropriate. Unsurprisingly, you've now found some other way to do it as a way to ignore the issue. Theknightwho (talk) 19:21, 28 October 2024 (UTC)
- Edit summaries are for summarizing edits, talk pages are for talking about pages. What I initially wrote was not personality-based, but you made it so. Please be better. —Justin (koavf)❤T☮C☺M☯ 19:49, 28 October 2024 (UTC)
- w:Help:Dummy edits have plenty of legitimate uses, as that page on Wikipedia helpfully points out. There isn't really anything else that needs to be said. Theknightwho (talk) 19:54, 28 October 2024 (UTC)
- mw:Help:Edit summary
- mw:Help:Talk pages
- This isn't Wikipedia.
- Have a nice day.
- —Justin (koavf)❤T☮C☺M☯ 20:06, 28 October 2024 (UTC)
- Haha - classic Koavf. I was pointing out those are legitimate uses, not claiming it's some kind of policy. Theknightwho (talk) 20:12, 28 October 2024 (UTC)
- Please stop posting attacks against me and continuing this grievance. Have a nice day. —Justin (koavf)❤T☮C☺M☯ 20:49, 28 October 2024 (UTC)
- What attack? Are you seriously trying to pretend that you thought linking to the MediaWiki help pages on edit summaries and talkpages was supposed to be a genuinely helpful response? Theknightwho (talk) 21:33, 28 October 2024 (UTC)
- Both of you need to knock it off. Further continuing this discussion is going to lead nowhere good. Benwing2 (talk) 21:39, 28 October 2024 (UTC)
- From personal experience, these two are as bad as each other. No love lost on the pair of them. DonnanZ (talk) 18:34, 30 October 2024 (UTC)
- Both of you need to knock it off. Further continuing this discussion is going to lead nowhere good. Benwing2 (talk) 21:39, 28 October 2024 (UTC)
- What attack? Are you seriously trying to pretend that you thought linking to the MediaWiki help pages on edit summaries and talkpages was supposed to be a genuinely helpful response? Theknightwho (talk) 21:33, 28 October 2024 (UTC)
- Please stop posting attacks against me and continuing this grievance. Have a nice day. —Justin (koavf)❤T☮C☺M☯ 20:49, 28 October 2024 (UTC)
- Haha - classic Koavf. I was pointing out those are legitimate uses, not claiming it's some kind of policy. Theknightwho (talk) 20:12, 28 October 2024 (UTC)
- w:Help:Dummy edits have plenty of legitimate uses, as that page on Wikipedia helpfully points out. There isn't really anything else that needs to be said. Theknightwho (talk) 19:54, 28 October 2024 (UTC)
- Edit summaries are for summarizing edits, talk pages are for talking about pages. What I initially wrote was not personality-based, but you made it so. Please be better. —Justin (koavf)❤T☮C☺M☯ 19:49, 28 October 2024 (UTC)
- Well, you didn't, but what I'm actually doing here is preventing you from claiming some kind of false consensus against a well-established practice because you want excuses to call my behaviour inappropriate. Unsurprisingly, you've now found some other way to do it as a way to ignore the issue. Theknightwho (talk) 19:21, 28 October 2024 (UTC)
- I told you to stop pinging me. Stop it. Your completely exhausting behavior is so wildly inappropriate I don't know why you think it's acceptable. Go away and do something else and quit making this a personality-based grudge and then acting like I'm making it a personality-based grudge. —Justin (koavf)❤T☮C☺M☯ 19:16, 28 October 2024 (UTC)
- @Koavf Oh, well you'd better tell Wikipedia that w:Help:Dummy edits are a problem, despite being a widespread practice there. This thread was started with a question of whether they were appropriate, and the only mention of me was in the copied log, so no, this thread was about the question, and not about me. This is precisely why I said you were making this about your grudge, in which you have a long history of making mountains out of molehills whenever my behaviour is in question. Enough. Theknightwho (talk) 19:14, 28 October 2024 (UTC)
- The thread was actually begun by someone else and that person began it because of things you did. I've asked you to stop. Please stop. There is no reason for you to keep this distraction going and to keep pinging me. —Justin (koavf)❤T☮C☺M☯ 19:12, 28 October 2024 (UTC)
- @Koavf Whether or not the comments were appropriate, this thread is not about my behaviour, but about whether we should be able to use whitespace to leave comments in edit histories. Two comments about that doesn't constitute a definitive consensus, I'm afraid. There are clearly situations in which it *is* appropriate, such as correcting a major mistake in an edit summary which would cause confusion. Theknightwho (talk) 19:06, 28 October 2024 (UTC)
- I don't recall anyone saying that only you have done this, so in case I was somehow mistaken, I will go on record: don't do this to anyone. Anyway, as I have written multiple times, this thread is about your problematic editing and multiple editors have told you to stop it. Since it seems like you understand that you shouldn't have done it in the first place and that you seem like you're saying you won't do it again, sounds good. Have a nice day. —Justin (koavf)❤T☮C☺M☯ 18:58, 28 October 2024 (UTC)
- @Koavf Leaving whitespace to add points to edit histories is not something only I have done, not even particularly uncommon, and certainly does not constitute vandalism, as Emanuele6 mentioned. Benwing2 made some good points below about what should and should not have happened for reasons entirely outside of pedantry over whitespace in entries, but unless you can point me to some kind of policy on leaving whitespace in order to make comments in edit histories in particular (or even a guideline or past discussion), I'm not especially interested. Theknightwho (talk) 18:42, 28 October 2024 (UTC)
- "Please take your grudge elsewhere" is actually exactly what you should be doing. Please stop with this and listen to others telling you that your prior behavior was inappropriate. —Justin (koavf)❤T☮C☺M☯ 18:35, 28 October 2024 (UTC)
- @Koavf It doesn't take a genius to work out why it's relevant. Please take your personal grudge elsewhere. Theknightwho (talk) 18:34, 28 October 2024 (UTC)
- I'm not sure why you think that what someone writes seven hours later should apply retroactively, but I disagree and you shouldn't have done what you did, which is the actual point of this thread. Your distractions and irrelevant noise are not appreciated. —Justin (koavf)❤T☮C☺M☯ 18:01, 28 October 2024 (UTC)
- @Koavf Given that Benwing2 has pointed out no-one should have been reverting or making those whitespace changes, that also applies to you, so you should not have made any further edits to the page sì. Theknightwho (talk) 12:23, 28 October 2024 (UTC)
- I agree. — Sgconlaw (talk) 05:16, 28 October 2024 (UTC)
- I looked at the whole edit history involving the two of you. My comments are this:
- I agree that whitespace changes should not be used to leave comments like this, and in general there should not be trailing whitespace. Use the talk page if there's a disagreement (see point 3).
- You made a bunch of formatting mistakes, which User:Theknightwho tried to clean up. You should be more careful about this in the future.
- Both you and User:Theknightwho edit warred to some extent, which is not a good idea. It's much better to use the talk page at the first sign of disagreement.
- I disagree that sì is a "particle". "Particle" is an extremely nebulous part of speech with no clear meaning, and it's best to avoid it. Portuguese, for example, defines sim as an interjection, which to me makes a lot more sense.
- Benwing2 (talk) 08:08, 28 October 2024 (UTC)
- > You made a bunch of formatting mistakes, which User:Theknightwho tried to clean up. You should be more careful about this in the future.
- I don't think this is true; if you look at what actually change on the page; the only mistake I did is mistakenly using the it-adv head tag instead of
head|it|particle
. Instead of just fixing that, they undid my edit, moving information back to the wrong location and leaving it there. - > I disagree that sì is a "particle". "Particle" is an extremely nebulous part of speech with no clear meaning, and it's best to avoid it. Portuguese, for example, defines sim as an interjection, which to me makes a lot more sense.
- The only reason why I chose particle is that both English "yes", and Spanish "sí" have this meaning under Particle. It is definitely not an advert. If it's something else that should also be changed on sí.
- yes has both particle and interjection, if you look at the examples for particle, that definitely matches the use described by the "Usage notes" in sì; anyway it is also true that sì can be used as interjection, as well as a particle, so an entry for that could be added in addition.
- > Both you and User:Theknightwho edit warred to some extent, which is not a good idea. It's much better to use the talk page at the first sign of disagreement.
- I don't claim that I have performed the edit on sì cleanly, as I have used the wrong head template, and triggered an abuse warning, but 1) I fixed a thing about that page, and it was reverted; 2) I removed a whitespace added for no reason on that page, that has no right to be there as I always do on any wiki, and it was reverted.
- I am discussing those decisions in talk pages.
Emanuele6 (talk) 08:33, 28 October 2024 (UTC)- In your edits you made several mistakes:
- using
{{it-adv}}
instead of{{head|it|particle}}
; - your first edit left the ===Adverb=== header stranded with no corresponding headword template (hence the abuse filter that you seem to have ignored or misinterpreted; you must have gotten a warning and then saved anyway, because it left a
no-head-temp
tag indicating the missing headword template); - you made things worse by alphabetizing the parts of speech, instead of putting the most common usage first.
- using
- User:Theknightwho made three edits after your two edits, trying to correct these various mistakes. You then complained about the Usage note being in the wrong place, but as noted by Theknightwho, that's how it was previously, and the Usage note ending up in the wrong place again appears to have been a side effect of trying to correct the various formatting mistakes you made, not anything intentional. That's what Theknightwho's comment "That usage note was already at the bottom, so please don't bullshit." was trying to say; it definitely could have been phrased in a more polite fashion, though. Following that you accused Theknightwho of vandalism, which was not the case; you probably shouldn't have reverted his change and he definitely should not have reverted your change.
- User:Theknightwho can sometimes be abrasive in his comments, which is regrettable, but at the same time IMO you should assume good faith when it comes to experienced editors trying to clean up your mistakes. Benwing2 (talk) 09:03, 28 October 2024 (UTC)
- How is adding a random space, and readding it again, and then leaving it there not vandalism though?
- I have no problem with them fixing my mistakes. Emanuele6 (talk) 09:09, 28 October 2024 (UTC)
- Because it makes no difference to the rendered display, because final whitespace is eliminated from lines before being rendered. That’s simply not what vandalism is. Theknightwho (talk) 12:26, 28 October 2024 (UTC)
- > Following that you accused Theknightwho of vandalism, which was not the case; you probably shouldn't have reverted his change and he definitely should not have reverted your change.
- Benwing2 I don't understand how to interpret this. I should have left the whitespace because they used it to comment?
- "Following that you accused Theknightwho of vandalism"? Maybe you misunderstood that I reverted the change adding of space twice.
- I didn't. I reverted it once and then create this discussion after seeing them claiming "not vandalism" readding the space, to learn if it was really acceptable.
- It was reverted a second time by another user who commented in this discussion, not me. Emanuele6 (talk) 09:33, 28 October 2024 (UTC)
- In your edits you made several mistakes:
Request for extended mover
[edit]following the advice from @Benwing2 on the Discord server, I wish to request permission for "extended mover" given my editing history. Juwan (talk) 07:49, 28 October 2024 (UTC)
Make Wiktionary:English adjectives an official policy
[edit]I suggest making Wiktionary:English adjectives an official policy. It'd forbid adjective senses of present participles and other English words that don't act as true adjectives.
Wiktionary:Votes/2022-01/Excluding trivial present participal adjectives isn't a good proposal, because it'd delete actual adjectives and dealign Wiktionary with other dictionaries. Davi6596 (talk) 13:55, 28 October 2024 (UTC)
Request for review of image policy
[edit]this request is regarding the two pages Help:Images and Wiktionary:Images. these policies are very poorly documented and are lacking in content for a prominent aspect for readers of the dictionary. it is unusual for the English Wiktionary which has several guidelines to follow for general entry layout, to lack anything for this. below I have outlined some points that I want to have discussed and added to policy.
- harmonisation: between multiple entries, there should be a layout by which entries should abide. what placement, what size (or lack of size marking), what letter capitalisation, what use of full stops, etc.
- multiple images: mention of the
{{multiple image}}
template - senseno: with multiple definitions for a given lemma, it is useful to differentiation images with the given senseno.
- language tagging: as of now, images in different languages are not tagged at all for foreign text. in short, this is terrible for screen reader accessibility, as these would not know how to properly read the given text, see the rationale on Wikipedia.
I am aware that writing policy is hard, but over the coming days I will try to make a draft for others to review and further implement. Juwan (talk) 19:20, 29 October 2024 (UTC)
- Sounds good to me. Both of the pages you cite are years and years old. I think the issue is that most Wiktionary pages aren't accompanied by images and (unlike Wikipedia) most editors don't make it a priority to add images, but I completely agree with having standards. Benwing2 (talk) 22:46, 29 October 2024 (UTC)
removing inactive autopatrollers
[edit]The purpose of being an autopatroller is, more than anything else, to reduce the burden on people who patrol Special:RecentChanges by excluding "known good" contributors. In addition, sometimes being an autopatroller gives you the ability to modify an otherwise-protected page, on the theory that autopatrollers generally know what they're doing and can be trusted, at least to some extent, to not mess things up. (Although in practice, I think most pages are either protected at the autoconfirmed level, i.e. below autopatrol protection, or at the template editor or admin level, i.e. above autopatrol protection.) An inactive autopatroller no longer serves the primary purpose of reducing the volume of Special:RecentChanges, and over time autopatrollers are likely to lose the knowledge of how Wiktionary works, both due to simply forgetting over time and due to the gradual evolution of Wiktionary templates, practices and standards. In addition, inactive accounts present a potential security risk, as the account might get compromised by someone whose bad or even malicious changes might then slip under the radar due to the autopatrol status. It's true that an individual inactive autopatroller account presents less of a security risk than an individual inactive admin account, but contrariwise there are a lot more inactive autopatroller accounts than inactive admin accounts.
So I propose that autopatrollers automatically lose autopatrol status after some amount of time. Specifically, I propose:
- Inactive accounts (defined by having no "actions" where an action is any change to the site, such as an edit) lose their autopatroller status after one year (maybe two years).
- Inactive accounts that later become active again may regain their autopatroller status without prejudice as long as some amount of time has not passed (e.g. five years). "Without prejudice" means a request to restore autopatroller status will automatically be granted barring some good reason to the contrary, and in addition any admin may freely restore autopatroller status for such accounts without any consultation (e.g. if the admin is patrolling Special:RecentChanges and sees a previously inactive account become active again). For reference: you (anyone, admin or not) can see what rights a given user has, along with the full history of changes to these rights, by going to Special:UserRights.
- Inactive accounts that have been inactive for sufficiently long (e.g. five years), became active again, and wish to regain autopatroller status will need to go through the normal nomination/approval process for this; see Wiktionary:Whitelist. (FWIW we should IMO consider renaming this, both because its purpose is not obvious from its name and because there is a recent dispreference for the terms "whitelist" and "blacklist". I would suggest something very obvious like Wiktionary:Autopatrol nominations.)
For reference, there are currently 1,063 autopatrollers but only 219 of them have been active within the last 30 days. I'm not sure how to get the list of those active within the last year; if someone knows how to do that, please post the relevant query along with the number of such users.
Benwing2 (talk) 07:38, 30 October 2024 (UTC)
- No objection to this. — Sgconlaw (talk) 11:56, 31 October 2024 (UTC)
- No objections to any of this as well. However, wouldn’t there need to be a vote to make this a policy? Kutchkutch (talk) 12:14, 31 October 2024 (UTC)
Sicilian, stripping the dot from ḍ in page titles
[edit]To give context for interested people passing through, Sicilian has a phoneme /ɖɖ/, distinct from /dd/, both having most often been written as dd. Recent standardisation proposals have come up with the orthographic mean ḍḍ to distinguish the former from the latter. Pretty ingenious, but still quite artificial and, although seemingly has grown in popularity especially on the Internet, still far from being the most common way of writing down the phoneme.
This is phenomenon is nothing new, and usually we handle it with the entry_name
at Module:languages. I propose we make it so ḍḍ can be used in links, headwords, etc. and keeping dd in page titles. The stripping from links would be automatic, like Latin macrons and Russian accents.
@Hyblaeorum, Nicodene. Catonif (talk) 09:33, 30 October 2024 (UTC)
- @Catonif Are we sure we want to do this, as opposed to simply using ḍḍ in pagenames? There are already a lot of page titles using ḍḍ, such as aḍḍumari. All of these would have to be renamed and head= added to all of the headwords. This is similar to our use of ё in Russian headwords even though it isn't usually written in the wild (following dictionary conventions). Benwing2 (talk) 23:14, 30 October 2024 (UTC)
- I would guess that most speakers simply use Standard Italian orthography to write the sounds of their particular dialects, with frequent interference from the spelling of Italian cognates.
- We could follow this practice in our lemmas, but I don’t see a problem with adopting a standard Sicilian orthography instead, such as that of the Cademia Siciliana. There’d be more coherence to it (one standard form as opposed to a spectrum of ad-hoc choices by speakers of various dialects) and it would presumably be better-equipped to handle sounds or contrasts that are alien to Standard Italian (like the one that inspired this thread). Nicodene (talk) 00:20, 31 October 2024 (UTC)