Wiktionary >
Discussion rooms
> Beer parlour
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!
Beer parlour
archives
edit
Earlier years
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
I would like to establish by consensus precise rules for when an entry should be placed into
Category:Terms derived from other languages by language
. The reason why this is necessary now is because these rules are meant to be specified as code in
Module:etymon/categories
, and it is important that our modules work the way our editors expect.
For the purpose of these rules, a term is a
direct descendant
of another term if it etymologically originates from that term with no morphological additions. This includes inheritance, borrowing, and same-language derivation (not involving compounding). To give a concrete example, the etymology tree at
graffiti#Etymology
shows a single chain of direct descendants.
The rules are:
If a term is derived from a certain language, all of its direct descendants are also derived from that language.
A term is always derived from an immediate ancestor's language, except for purely semantic ancestors, namely calques and semantic loans.
Categories of the form
X terms derived from X
are disallowed (must be different languages).
Ioaxxere
talk
01:36, 2 March 2026 (UTC)
Reply
Graffiti
is hardly an example of an etymology with no morphological additions. Do plural, past participle, and verb suffix not count as morphological additions? (Another thing missing in that etymology, apart from the things just mentioned, is why the Italian verb was borrowed with the
-ire
suffix and the
-isc
"infix". That seems extremely non-obvious to me.)
More generally, what exactly is "same-language derivation" if not the addition of morphology?
Even more generally, I find a lot about this higly unintuitive. If we're going to fiddle with this anyway I might as well speak out my misgivings.
Saying an English term (say
graffiti
) is derived from Greek (ie
γρᾰ́φω
grắphō
) is ambiguous and/or misleading. To me it suggests it was directly derived from Greek. That is to say editors get the impression they should put words in this category if and only if they are directly taken from Greek. More correct and intuitive would be calling the category someting like
English words of Greek origin
Why exactly don't we have a category
English terms derived from English
? I would like to have a category for words coined within a given language (as opposed to inherited or borrowed). —
Caoimhin ceallach
talk
11:50, 2 March 2026 (UTC)
Reply
To your first grievance, that's not really what derived categories are for, direct derivations usually are borrowings or inheritences.
Vininn126
talk
12:21, 2 March 2026 (UTC)
Reply
That hits precisely on my point: what the categories are for does not correspond to what the names suggest they are for. The problem I think is this:
English terms derived from Ancient Greek
is supposed to mean "English words whose derivation can be traced to Greek", but it actually means "English words obtained directly from Ancient Greek". If I'm alone in seeing it this way then this is clearly a me-problem, but I wanted to have said that I find these names unintuitive. —
Caoimhin ceallach
talk
13:01, 2 March 2026 (UTC)
Reply
This has been a thing for a long time, and the transitivity of derived from categories has a tradition in templates like
{{
dercat
}}
or "Derived from FOO PIE root". It might be easier if you suggest a name, which can leave things open for discussion - I personally don't see the need to change them, but it's easier to take action with a suggestion on what could be done as opposed to what shouldn't be done.
Vininn126
talk
13:33, 2 March 2026 (UTC)
Reply
I'd rather see "derived from X" used for what Caoimhin ceallach describes. If we want to have a transitive category, it should be called something like "ultimately derived from X". —
URJECTION
12:35, 5 March 2026 (UTC)
Reply
I think this could potentially be a compromise that would also allow for more broad categorization and proposed by Ioxxere, I wouldn't be opposed. I was simply stating what I understand the current status quo to be. Such a category would also be useful for things like internationalisms, where we know the ultimate source.
Vininn126
talk
12:39, 5 March 2026 (UTC)
Reply
Well, this discussion seems to have died. I like Surjection's idea of making the "derived from" categories non-transitive and potentially using a separate category where the rules are clear. @
Fenakhay
would you like to implement and document this?
Ioaxxere
talk
22:37, 13 March 2026 (UTC)
Reply
It needs more input from others. This is a radical change in how "derived from" categories work. Plus I won't be able to implement it right now as I'll be busy in the coming weeks. —
Fenakhay
حيطي
مساهماتي
14:02, 14 March 2026 (UTC)
Reply
I agree I would like a few more voices. So far the number seems low.
Vininn126
talk
14:17, 14 March 2026 (UTC)
Reply
I agree with Fenakhay and raise it to
likely requires a vote
. I agree with Caoimhin & Surjection, although I prefer the verbiage "
X terms of Y origin
" as it seems clearer. Is it possible for a term to have more than one
ultimately derived from
language, like:
klama
TranqyPoo
✏️
16:56, 6 April 2026 (UTC)
Reply
I actually like the solution of X terms of Y origin quite a bit.
Vininn126
talk
17:02, 6 April 2026 (UTC)
Reply
Where did we have this exact discussion before? Was it when we were reviewing the
{{
etymon
}}
template?
Polomo
⟨
oi!
⟩ ·
21:20, 6 April 2026 (UTC)
Reply
I am seeking consensus for a new feature in
Module:affix
: the ability to provide morphological information for each component, probably in the same format as used by
{{
infl of
}}
{{
+obj
}}
(without additional details like glosses, though).
The case I would like to use this for is to mark relevant cases and stems in Finnish compounds and suffixed words. Finnish compounds often use the default nominative case for both parts, but it's also common for the former component to be in some other cases (in the majority of cases, the genitive). Currently there is no real way to mark this other than using q, but that also has uses.
A new
mform
or similar parameter could be used something like this:
{{
affix
|fi|vesi
which would display something like this:
veden
genitive
singular
keitin
Ideally, there would also be two additional features, although the latter might be too confusing:
That a certain set of 'default' forms could be added, but would not result in a visible display. This would allow adding morphological information without adding clutter in cases where the 'default' case/form is used, e.g. the nominative in Finnish. (Otherwise, the default would be to not have any mform indicated at all, but I'd rather this just mean "it is not relevant, or nobody has added it yet").
Language-specific shortcuts, e.g.
aliasing to
gen&sg
for Finnish only.
These would be configured in some kind of language-specific data modules. —
URJECTION
12:26, 5 March 2026 (UTC)
Reply
Support
. the main way I see this done is with
, as in: (using Finnish as an example as it is not my editing language)
vesi
or
veden
this data and formatting used in
{{
infl of
}}
would be a good base. (do consider also
as the modifier label).
Juwan
🕊️
13:04, 5 March 2026 (UTC)
Reply
Supportive of the concept, but:
I oppose the linking of
veden
to
vesi
. A link labelled
veden
should go to the
veden
entry. We should have separate links to
veden
and
vesi
, or at minimum a link to
vesi
only.
The POS should not be in italics. It should be in roman text to clearly and immediately distinguish it from the text in the non-English language, just like the existing
|pos=
parameter does. I'm skeptical of the need to link the grammatical terminology, too.
What is "m" in
mform
? Why not just
form
As for the &, why not just a space?
With those changes you could have something like
veden
veden
genitive singular of
vesi
This, that and the other
talk
01:41, 8 March 2026 (UTC)
Reply
I strongly oppose the first point. Etymologies for lemmas should link to lemmas, because that is where the actual information will be, while the display text should be the non-lemma, because that is the form actually used in a compound. Space should not be used for the same reason it's not used in
{{
+obj
}}
- it allows you to write custom tags containing spaces. The "m" in "mform" stands for morphological. —
URJECTION
09:36, 8 March 2026 (UTC)
Reply
Now added as
|inflN=
. The text is not linked, but is currently in italic, because it acts like a qualifier. I'm not opposed to displaying it in roman text.
Module:pron qualifier
contains the relevant code. —
URJECTION
10:41, 8 March 2026 (UTC)
Reply
Now rewritten to use roman text and not use
Module:pron qualifier
. Instead, the relevant code is now in
Module:links
(search for
tagged_inflections
). —
URJECTION
16:01, 8 March 2026 (UTC)
Reply
Support
. I often need this kind of functionality in Dutch, as it often creates compounds with past or present participles of verbs (e.g.
vleesetend
).
I do agree with TTO that I would like to see the base lemma form displayed in the actual text, not just linked as an alt. Your current display may be confusing to readers, as it doesn't tell them what
veden
is the genitive singular of.
Stujul
talk
10:43, 8 March 2026 (UTC)
Reply
Displaying it as text gets complicated to implement from a technical standpoint. Readers can see what the base form is by clicking the link - it's better than being brought to a non-lemma form that is nothing more than a soft redirect to a lemma. We would be actively doing a disservice to readers by linking to it in etymologies. —
URJECTION
11:56, 8 March 2026 (UTC)
Reply
To be clear, I'm not opposed to the idea of showing the lemma form in text, but I don't know how to best implement it from a technical point of view and how to lay it out in the template syntax. —
URJECTION
12:49, 8 March 2026 (UTC)
Reply
Okay, that makes sense, thank you for clarifying.
Stujul
talk
13:17, 8 March 2026 (UTC)
Reply
I think the links for the morphological labels might be a bit too much, especially considering both the linked term and the qualifiers would be in italics, and so visually undistinguished.
So if I had the theoretical Ingrian term
genetivanpohja
, I would have the etymology present as
genitivan (genitive singular,
"of the genitive"
) + pohja (
"stem"
. If then "genitive singular" is linked, it will be quite hard to see which exact term there is the etymon, and which is the qualifier.
Thadh
talk
07:24, 15 March 2026 (UTC)
Reply
Yeah, the current implementation does not link the terms, and it also uses upright rather than italic formatting. (It has already been deployed to a whole number of Finnish entries, including
vedenkeitin
which I gave as an example.) —
URJECTION
07:29, 15 March 2026 (UTC)
Reply
That looks perfect!
Thadh
talk
07:45, 15 March 2026 (UTC)
Reply
the map
Template:dialect map/pt/strong R
(by @
Trooper57
) shows the realisation of the phoneme /ʁ/ ("strong R") across Portuguese lects. I propose that we extend the support for these types of maps for information other than dialectal synonyms. (think
WALS
and
IDS
).
pinging @
Fenakhay
as the main maintainer.
Juwan
🕊️
12:57, 5 March 2026 (UTC)
Reply
Edit summaries in poor English, and very numerous probably bad edits to swear words. Please take a look and assess damage so far.
~2026-14738-79
talk
22:17, 8 March 2026 (UTC)
Reply
Now blocked by someone else. —
Justin (
ko
vf
00:10, 13 March 2026 (UTC)
Reply
despite having a lot of homophones, there appears to be a lot of missing terms from the entries. take this
recent diff
as an example, for each entry, there are only a few (if any) homophones listed. would there be any way to clear this up?
Juwan
🕊️
11:13, 11 March 2026 (UTC)
Reply
looking at
WT:EL
(for the topic above), there should be some clarification on what is the correct layout for a given pronunciation section. the page is seft-contradicting in the order for the bullet points for hyphentation and homophones: § "List of headings" lists homophones above hyphenation (option 1) and § "Pronunciation" lists it below (option 2), see below:
Option 1
{{
IPA
en
/ˈsɪm.bəl/
}}
{{
hmp
en
cymbal
}}
{{
hyph
en
sym
bol
}}
Option 2
{{
IPA
en
/ˈsɪm.bəl/
}}
{{
hyph
en
sym
bol
}}
{{
hmp
en
cymbal
}}
in practice, it appears that the second one is used more commonly across languages, with template implementations coding it into their logic (e.g.
{{
es-pr
}}
). this option is what I personally support, as it separates the information about a term in the entry (higher priority) from others. if this is agreed by other editors, I propose that a bot cleans up the remaning entries (periodically?) and the EL page be updated. as this is a not a substantial change, this shouldn't require a vote.
(further notes and opinions are welcome in
this draft
Juwan
🕊️
11:41, 11 March 2026 (UTC)
Reply
Sounds like a good idea. —
Sartma
𒁾𒁉
𒊭 𒌑𒊑𒀉𒁲
15:37, 11 March 2026 (UTC)
Reply
I think the hyphenation should stay at the end. Although we indicate it in this section, it is the least related to pronunciation (it is really more related to etymology and spelling). If both
{{
homophones
}}
and
{{
rhymes
}}
are used, I usually put them in that order as I figure that arranging them alphabetically seems to make sense. —
Sgconlaw
talk
20:17, 11 March 2026 (UTC)
Reply
I like and support the conventions that Sgconlaw mentioned here. Another reason I like homophones before rhymes is that they have the closest/highest relevance/connection to the pron at hand (soundalike), and the rhymes are next in proximity/relevance after that.
Quercus solaris
talk
01:19, 12 March 2026 (UTC)
Reply
I should also mention syllabification, used by a couple of languages, which differs from hyphentation (see Esperanto), giving:
IPA
syllabification
hyphentation
rhymes
homophones
note also to Portuguese editors that what we call 'hyphenation' should really be syllabification.
Juwan
🕊️
11:53, 15 March 2026 (UTC)
Reply
Juwan
: can you give an example of an Esperanto entry? Also, I don’t understand your last sentence. Who’s “we” here—English language editors, Portuguese language editors, or all editors? If you mean English language editors or all editors (I don’t know about Portuguese), hyphenation and syllabification are not always the same. —
Sgconlaw
talk
12:58, 15 March 2026 (UTC)
Reply
Sgconlaw
for an example, take
homino
, where the hyphenation only occurs between the root and its suffixes.
we
is used as generically for Portuguese editors only.
Juwan
🕊️
13:11, 15 March 2026 (UTC)
Reply
I guess they really are the same if you consider “syllable” in the written sense, i.e., as referring to the unit used during hyphenation. A written syllable is itself defined by hyphenation rules, specifically those in effect since 2009. So, is this true by definition? Or is it maybe circular reasoning?
I think, regardlessly, "hyphenation" is at least more applicable. Portuguese syllabification does not reflect spoken syllables... for example,
ss
in words such as
a·mas·sar
is split across "syllables", even though it is a single onset. This differs from syllabic
scansion
, which often (but not always...) has
rr
and
ss
listed in a single syllable, see
e.g. here
Polomo
⟨
oi!
⟩ ·
23:19, 2 April 2026 (UTC)
Reply
Support
standardizing to option 2. For the same reason as the nom., I like IPA > rhymes > hyphenation > homophones. I’m not sure there can be an objectively “better” option, but we need a standard (just like for the order of headings) and have to choose mostly based on preference.
Polomo
⟨
oi!
⟩ ·
23:20, 2 April 2026 (UTC)
Reply
I've seen some complaints about users casting supports and opposes in votes for no reason. I wonder if anybody supports a vote on establishing a rule that supports and opposes must be cast in votes with an
intelligible
reason, or else they'll invalidated (or a similar rule). To be clear, I don't have a set opinion on this: I'd just like to hear what y'all think.
Davi6596
talk
00:01, 13 March 2026 (UTC)
Reply
I think that vote would fail and it would just encourage these kinds of voters to write "support per above" or "oppose as bad idea". You can't genuinely make anyone elaborate. —
Justin (
ko
vf
00:10, 13 March 2026 (UTC)
Reply
On wikis, the custom is to take more into account than just the raw number of votes on either side. That's why the term "
!vote
" is used in discussions here. A bare "support" or "oppose" doesn't carry as much weight as a vote with a reason, but it means more than no vote at all. A single bare vote will sometimes be ignored in measuring consensus, but a significant difference in numbers pro and con can be decisive.
Chuck Entz
talk
03:38, 13 March 2026 (UTC)
Reply
Chuck Entz
The rule would apply to formal votes, where no vote can be ignored.
Davi6596
talk
12:07, 13 March 2026 (UTC)
Reply
Indeed something similar is already
policy
, even though it’s not frequently brought up. I don’t think we can do much better... maybe make the wording slightly more critical of "tallying" — currently it says tallying is important although not the only factor, but really the arguments should be the most important factor rather than number. This is what Wikipedia does, iirc.
Polomo
⟨
oi!
⟩ ·
23:01, 2 April 2026 (UTC)
Reply
Polomo
The policy you mentioned applies to discussions which aren't formal votes. Do you think it should apply to formal votes as well?
Davi6596
talk
23:16, 2 April 2026 (UTC)
Reply
Come to think of it now, I don’t think the folks on wiki ever make decisions by plain tallying, which... makes sense. But in practice, it seems obvious that many if not most discussions over there end up decided by amount of votes anyway. I don’t see any harm to this, and there are possible upsides. It’s a radical change to our current
WT:VOTE
system, though.
Polomo
⟨
oi!
⟩ ·
23:33, 2 April 2026 (UTC)
Reply
Oppose
;)
Thadh
talk
07:58, 13 March 2026 (UTC)
Reply
Oppose
per Koavf. Also, it would delegitimize
gut feel
and may compel voicing of rationales better left unvoiced should anyone take such a rule literally. It would make more sense to disallow votes by folks who are too recently registered, which may not be a good idea, but still better than the proposal. For example, do these "arguments" really help on this?
DCDuring
talk
14:18, 13 March 2026 (UTC)
Reply
DCDuring
It may be a good idea if "too recently registered" is properly defined.
Davi6596
talk
14:36, 13 March 2026 (UTC)
Reply
Maybe we could have a bicameral system for certain classes of votes, thereby eating our cake while still having it.
DCDuring
talk
14:42, 13 March 2026 (UTC)
Reply
I do think we should increase the requirements listed in
WT:VP
(for formal votes), which currently allows votes from 1-week old users with 50 edits. If, unlike Wikipedia, an editor’s gut feeling can make community-wide decisions, then we should require editors to be more familiar with the project.
I’d like to start a vote to change this minimum to 30 days and 500 edits, like Wikipedia’s extended-confirmed status. We could also require a minimum amount of edits in the past 6 months, but I don’t know what that should be.
Polomo
⟨
oi!
⟩ ·
01:11, 3 April 2026 (UTC)
Reply
Polomo
Yes, please draft this vote at least. My idea has practically been rejected, and this is ok.
Davi6596
talk
14:59, 3 April 2026 (UTC)
Reply
Support
30 days/500 edits.
TranqyPoo
✏️
17:17, 3 April 2026 (UTC)
Reply
Strong support
30 days/500 edits.
Chihunglu83
talk
17:21, 3 April 2026 (UTC)
Reply
Created it:
Wiktionary:Votes/2026-04/Updating voting eligibility
Polomo
⟨
oi!
⟩ ·
20:42, 3 April 2026 (UTC)
Reply
I can understand the motivation of this. I'm tired of dogmatic votes and unjustified opinions. It's a fine place to start, but if you don't further think critically and justify it then you're not engaging in scientific thinking. That said, I don't think in practice this would actually be that beneficial, and I think we'd see more bad-faith "justifications".
Vininn126
talk
14:48, 13 March 2026 (UTC)
Reply
Oppose
primarily for reasons discussed by Koavf above. A voter may not feel that they have any additional value to add to the discussion beyond the vote, and such a rule would likely come off as telling those users that such votes lack any value whatsoever. That's not what we want in a collaborative environment such as Wiktionary.
StrangerCoug
talk
17:24, 29 March 2026 (UTC)
Reply
First of all, I would like to say that I'm not an experienced editor here on Wiktionary. All my edits have been surface-level and do not include templates, let alone coding or Lua.
I see that the phonemic analysis used by {{
mn-IPA
}} has not been revisited, even though some aspects of the transcription it produces may not accurately reflect modern Standard Khalkha. The last edit is very recent (2026), but the edits do not challenge the phonemic analysis the template supports. In 2017, two users
proposed its deletion
, but the template still exists, so it appears the proposal did not result in deletion. I think there are very problematic choices made Re: grapheme–phoneme correspondence. I would like to propose revising or rebuilding the template. Although I do not have experience with Lua, I think a better version (based on the current one or otherwise) is feasible, and I believe it will be useful since the template is present on multiple pages.
I believe the template would need clear limitations.
I believe the transcription should only follow the synchronic analysis of modern Standard Khalkha. The narrow scope of the transcription can be explicitly stated within the template (with outputs similar to "(
Standard Mongolian
)" or "(
Khalkha
)" as it is usual for dialect labelling). Other dialectal transcriptions can always be added manually anyway.
The transcription should be exclusively phonemic and not narrow, at least at the beginning. If there is a need to create narrow transcription in square brackets using a template, this template can be expanded, but I propose this should be done only after a solid infrastructure for broad phonemic transcription is established.
Words with unexpected grapheme–phoneme correspondence will obviously need to be transcribed manually, as the transcription is automatic. This includes unadapted loanwords from Russian.
I do realise that Khalkha phonology is a field that may not have broad consensus on every single phoneme or topic. The template could follow an approach based on:
Teangacha
talk
18:58, 13 March 2026 (UTC)
Reply
Teangacha
: Happy to see someone interested to improve our Mongolian coverage again!
What you say mostly makes sense. I think the easiest way to do this is to create a second module first, test it in the userspace, and after that move all the current instances of
{{
mn-IPA
}}
to
{{
mn-IPA/old
}}
(or something like that), after which you manually fix the terms that feature it. It's quite labourous but the easiest way to make sure you don't have errors in the transformation from the old module to the new one.
It would be great if you could write the module yourself but if you think your knowledge of Lua is not sufficient yet, you should make a page where you explain the rules you want to apply, and then someone else can make the module based on that.
Thadh
talk
07:13, 15 March 2026 (UTC)
Reply
Teangacha
I too was thinking about doing some revamp - I had something I was working on a year or so ago -
Module:User:AmazingJus/mn
, but it's not finished yet and I haven't gotten back to it. It'd be great if we could revive this module to fine-tune the details and officially use it! —
oi yeah nah mate
amazing
JUSSO
...
[ɡəˈdæɪ̯]
08:54, 15 March 2026 (UTC)
Reply
The current Proto-Italic second conjugation causative inflection table template displays inconsistent reflexes of PIE
*-éyo-
. The first-person plural ending is
*-ēmos
(< PIE
*-éyomos
), which shows the contraction of
*-éyo-
*-ē-
already in Proto-Italic. However, the third-person plural ending is
*-eont
(<
*-éyonti
), which reflects a time when
*-eo-
remained uncontracted.
Graearms
talk
22:33, 13 March 2026 (UTC)
Reply
Fixed
mello
hi!
Goodbye!
16:05, 16 March 2026 (UTC)
Reply
Mellohi!
I've notice another possible error in the Proto-Italic conjugation templates—we currently reconstruct the 2p.pl.pass ending as
*-m(e?)n(ai?)
, yet we also derive the form from
*-mh₁nos
. This etymology is indeed supported by certain linguists, with Brent Vine proposing that the nominative plural of
*-mh₁no-
yielded
Proto-Italic
*-manoi
, whence
Latin
-mini
Essentially, if we are to accept the connection with
*-mh₁nos
then the reconstruction
*-m(e?)n(ai?)
is inaccurate. I'll go ahead and fix the conjugation myself.
Graearms
talk
15:05, 31 March 2026 (UTC)
Reply
Vine, Brent (
2017–2018
), “Chapter VIII: Italic”, in Klein, Jared S.,
Joseph, Brian D.
Fritz, Matthias
, editors,
Handbook of Comparative and Historical Indo-European Linguistics: An International Handbook
(Handbücher zur Sprach- und Kommunikationswissenschaft
Handbooks of Linguistics and Communication Science
41.2
), Berlin; Boston: De Gruyter Mouton,
→ISBN
, § The morphology of Italic, page
786
What oversight exists for adding languages to
Module:etymon/data/text allowed
? I can find no language-community discussion about
adding Swahili
[sw]
, nor do I find any for many of the other languages listed there, including Proto-Indo-Iranian and Nuristani. Each language added should have a corresponding discussion, similar to how language changes are handled at
WT:LTR
. @
Fenakhay
--
{{
victar
talk
}}
01:19, 14 March 2026 (UTC)
Reply
Fuck off
. You are a real piece of work. —
Fenakhay
حيطي
مساهماتي
13:42, 14 March 2026 (UTC)
Reply
Ridiculous behaviour. I understand that you find this annoying, but the
most recent vote
explicitly limits use of
|text=
to “languages whose editing communities have explicitly approved it”. It is therefore perfectly justified to ask when and where those discussions have taken place.
I myself would like to know on what basis English and Latin were added to the list. I would also like to know what it means for a language family to be on it. Does that mean
|text=
is allowed for all members of that family? In that case, can you point to the discussion held for Indo-Aryan?
In general I would suggest that these discussions take place somewhere that makes sense, like
Wiktionary_talk:English_entry_guidelines
for English or if it's somewhere else then at least, for reference, add a link there to where it took place. —
Caoimhin ceallach
talk
22:56, 14 March 2026 (UTC)
Reply
I added English to the whitelist in
diff
to reflect what I believed to be existing consensus. Indeed in the past few days, the number of pages in
Category:English entries with etymology texts
has grown rapidly.
Ioaxxere
talk
19:45, 15 March 2026 (UTC)
Reply
Ioaxxere
: To be fair, the fact it did just means someone is going around adding
{{
etymon
}}
to already existing English pages, that doesn't mean that new pages are created with the template. A large number of instances of this template were added by @
Jlwoodwa
, and the last time this editor has created a new English entry seems to be never.
Thadh
talk
20:10, 15 March 2026 (UTC)
Reply
I have also used it to add etymologies to several entries which previously had none.
jlwoodwa
talk
20:12, 15 March 2026 (UTC)
Reply
Yeah, it does seem like the large majority of the edits are being done by Jlwoodwa. Many of the entries look like
fictioneer
, where the text is "From fiction + -eer" and there is virtually zero chance of this ever changing or being expanded. It also looks like Jlwoodwa is doing the responsible thing by avoiding adding the text parameter in cases where the etymology is complex enough that automatically generated boilerplate would be insufficient. I think that most editors approve their work thus far.
Ioaxxere
talk
20:30, 15 March 2026 (UTC)
Reply
I don't know what the consensus is for English. I just pointed out that the fact there are many instances of
{{
etymon
}}
in English entries does not by itself prove that a consensus in support of it is in place.
Thadh
talk
08:36, 16 March 2026 (UTC)
Reply
On an English language dictionary website I cannot believe I need to explain to you what "explicitly" means. —
Caoimhin ceallach
talk
22:06, 15 March 2026 (UTC)
Reply
No such thing has ever been upheld for similar templates like
{{
bor+
}}
. Such a requirement seems unprecedented, and to be frank, comes across as sore after the vote.
Vininn126
talk
22:16, 15 March 2026 (UTC)
Reply
I am speechless. Is there a similar text in a vote held on
{{
bor+
}}
? Why then did you even bother adding "explicitly approved" to the etymon vote? —
Caoimhin ceallach
talk
22:59, 15 March 2026 (UTC)
Reply
Explicitly has ranged from stated in a quick thread to many other things. Never has it been "a rule on the pages About page". There have been similar votes on + templates, it is an apt comparison. Not sure why you're speechless.
Vininn126
talk
23:01, 15 March 2026 (UTC)
Reply
I am speechless because:
Adding English to the whitelist "to reflect what I believed to be existing consensus" (Ioaxxere's words) doesn't have even the faintest homeopathic whiff of "explicit approval".
I haven't found a mention of "explicit approval" being required by specific language editing communities for the use of
{{
bor+
}}
in entries, either in documentation pages, the beer parlour, or votes, but you're using this to argue that "explicit approval" means, well, basically nothing.
Holding the discussion on
Wiktionary_talk:English_entry_guidelines
was a suggestion. I though it would be a good idea to have it somewhere predictable. It might prevent this kind of argument in future. —
Caoimhin ceallach
talk
23:36, 15 March 2026 (UTC)
Reply
Ask any of the editors in this thread about approval and + templates. They might not like it, but that kind of approval has been common in the past. I am merely pointing out the unprecedentedness. I am not opposed to updating About pages with that, but to suggest that it ought to be the way right off is indeed not something practiced.
Vininn126
talk
23:39, 15 March 2026 (UTC)
Reply
Obviously editors can come together at any time and discuss any aspect of the guidelines for editing in their respective languages. I don't see how
{{
bor+
}}
is relevant here as there was (as far as I can tell) never a vote mandating "explicit approval" for it's use.
To be clear: the one thing that is absolutely required, per
the recent vote
, which you authored, is "explicit approval". I didn't claim this entailed that a discussion on
Wiktionary_talk:English_entry_guidelines
was required. That was a suggestion. My hope was that this thread could be about a practical way of implementing the requirement. —
Caoimhin ceallach
talk
00:02, 16 March 2026 (UTC)
Reply
Caoimhin ceallach
I understand the concern. Since this discussion is already active, maybe we can fold in some of the language-specific discussions. I've created a subsection below so we have something to link to to enshrine the "explicit approval".
Ioaxxere
talk
03:28, 16 March 2026 (UTC)
Reply
Let's not go there. There was a vote for using
{{
bor+
}}
, and it failed, followed by a group of users saying "whatever" and continuing to use the template against consensus. Using that template as an example of how due process should function is like using North Korea as an example of a democratic society.
Thadh
talk
08:41, 16 March 2026 (UTC)
Reply
I am simply stating how it's unprecedented. Is that untrue?
Vininn126
talk
10:07, 16 March 2026 (UTC)
Reply
What exactly is unprecedented here? And why is
{{
bor+
}}
even relevant? —
Caoimhin ceallach
talk
10:33, 16 March 2026 (UTC)
Reply
Because the application of that template was also based on "community consensus", which was reflected differently. The only reason I want to point it out is that it should be recognized when making a proposal. Your approach of "I think explicit can be reflected this way" comes across much more good-faith and constructive than anything else that's been going on in this thread.
Vininn126
talk
10:48, 16 March 2026 (UTC)
Reply
Please point out where "community consensus" was discussed with reference to the use of
{{
bor+
}}
(and similar) in individual language editing communities. My suspicion is that this comparison is irrelevant.
This is also the case because "community consensus" and "explicit approval" are subject to different interpretations.
I find it unfair of you to imply that I have been anything but constructive in this thread. Compare that to the fact that my questions about Latin and Indo-Aryan have been ignored and @
Victar
was told to "fuck off" for bringing up Swahili in the first place. —
Caoimhin ceallach
talk
11:40, 16 March 2026 (UTC)
Reply
I'm not sure where I have an example of this, but in the past consensus has even been a user's talkpage where that person is the most active editor saying "Wanna use + templates?" "Sure".
Again, I understand that, but I do not get that impression from some of the editors. I should assume good faith, but I've had quite a few encounters with some of these editors where the ultimate goal was indeed not constructive, and they've essentially said that. That was also where my comment in the BP thread came from, I've all but heard from some editors that they're not interested in debate resulting in something.
Vininn126
talk
11:55, 16 March 2026 (UTC)
Reply
Well, that happened. W admin. The Swahili discussion linked hardly reflects a clear "language-community consensus", but I'll leave that assessment to others. I'm going to remove Proto-Indo-Iranian and Nuristani, as these are languages I have actively worked in and I am not aware of any prior discussion supporting the use of
{{
etymon
|text=1}}
on them.
Like @
Caoimhin ceallach
, I am also surprised that Latin was included, seemingly with no discussion, and
User:Fenakhay
does appear to
revert on sight
any edits removing
|text=1
from Latin entries.
--
{{
victar
talk
}}
22:02, 16 March 2026 (UTC)
Reply
Latin was brought up previously in this February discussion:
Wiktionary:Beer_parlour/2026/February#references_appearance_and_usage_of_the_text_parameter_in_Latin_entries
. Supported or accepted by @
Saumache
This, that and the other
. I didn't comment then since I was still thinking about the issue and waiting to see how the vote turned out, but I don't personally object to text=.--
Urszag
talk
22:15, 16 March 2026 (UTC)
Reply
Thank you. —
Caoimhin ceallach
talk
23:28, 16 March 2026 (UTC)
Reply
Urszag
: With many of these inclusions, it seems they have jumped the shark with the "language-community consensus" label.
User:Saumache
's post was a wall of text that only mentioned
|text=
as an aside at the bottom. Even page deletions get more discussion than that. Again, I recommend making such requests at
WT:LTR
going forward for better visibility. --
{{
victar
talk
}}
23:32, 16 March 2026 (UTC)
Reply
Get off your high horse. You ONLY reverted my edit but not the 100+ edits of @
Saumache
, who has
explicitly asked
for whitelisting Latin use of
|text=
. (Added by @
Vininn126
after that thread. See:
diff
I simply converted
Special:AbuseFilter/202
to a module. Ask @
AryamanA
who added Nuristani and other Indo-Aryan lects. You have a pathetic fixation on me, as if I am a thorn in your shoe. —
Fenakhay
حيطي
مساهماتي
22:16, 16 March 2026 (UTC)
Reply
Fenakhay
: From the mud, every horse looks high. This may come as a huge surprise to you, but I actually don't follow your edits. I only noticed
|text=1
on
iuvenis
because I built out the
Proto-Italic entry
to it and was updating referring links.
If you have no responsibity in Proto-Indo-Iranian and Nuristani being included, why did
you
revert me? Let
User:AryamanA
revert me and argue his rational, if he wishes.
--
{{
victar
talk
}}
23:32, 16 March 2026 (UTC)
Reply
Victar’s vitriol aside, I do believe that asking one editor on their talk page is not a good way to check community consensus. Most editors (as is the case for
Tbm
) will politely point out that there are more editors in that language, but loose cannons do exist. I therefore propose to
Fenakhay
to post at a more visible place in the future (for example the
Swahili entry guidelines
), tag those editors that you managed to identify, and wait a tad longer to give less active editors time to take notice.
MuDavid
栘𩿠 (
talk
01:24, 17 March 2026 (UTC)
Reply
I would like to revisit this issue, as @
Trooper57
and @
MuDavid
have since added language exemptions to
Module:etymon/data/text allowed
without, to my knowledge, prior discussion. @
MuDavid
, I understand that you may be the "only editor for bnt-sab-pro", however, the concern here extends beyond consensus to include transparency.
Although I am the primary editor for a number of Iranian languages, I
still submit requests
to
WT:LTR
when making language-related changes. Please also note that this is not intended to single you out; I
ask the same
of others editors.
--
{{
victar
talk
}}
07:40, 10 April 2026 (UTC)
Reply
I see that the entry
drive round the bend
, which was a mere hard redirect to
round the bend
, has been deleted as SOP. I don't understand the added value of this move. @
Sartma
Ultimateria
10:19, 14 March 2026 (UTC)
Reply
Undeleted. Deletion was out of process, possibly the result of simple confusion. I have removed the RfD. If someone wants to RfD the redirect, so be it.
DCDuring
talk
13:41, 14 March 2026 (UTC)
Reply
Based on the wording, I thought it was the result of a move; the mover often nominates those redirects for speedy deletion.
Ultimateria
talk
22:01, 16 March 2026 (UTC)
Reply
That's the kind of confusion about this I was experiencing myself.
DCDuring
talk
22:03, 16 March 2026 (UTC)
Reply
Add a note to
#Etymology
Many English entries with relatively simple etymologies use the
{{
etymon
}}
template to automatically generate text.
Ioaxxere
talk
03:28, 16 March 2026 (UTC)
Reply
IMO, the greatest drawback of
{{
etymon
}}
is that it's unintuitive. For simple etymologies, why not have something like this instead:
{{
inh
|gmw-pro|gem-pro|*stainaz|ety=1}}
. That strikes me as a best of both worlds compromise. --
{{
victar
talk
}}
22:43, 16 March 2026 (UTC)
Reply
Victar
Your claim is that
{{
inh
|gmw-pro|gem-pro|*stainaz|ety=1}}
is intuitive while
{{
etymon
|gmw-pro|:inh|gem-pro:*stainaz|text=1}}
is unintuitive, but they seem almost the same to me. The etymon version is better than your proposed parameter because it is more extensible: you could have
{{
etymon
|gmw-pro|:inh|gem-pro:*stainaz|gem-pro:*some other term|text=1}}
to have multiple inheritance (conflation) and the text will immediately be updated to reflect this. But I would be interested to hear your thoughts as to why you say it is unintuitive, as perhaps it is something we can address in the documentation.
Ioaxxere
talk
23:25, 16 March 2026 (UTC)
Reply
We are in disagreement on what is intuitive. --
{{
victar
talk
}}
23:35, 16 March 2026 (UTC)
Reply
I also find it unintuitive, probably because most of our templates (at least the common ones I'm familiar with) don't use colons.
Andrew Sheedy
talk
14:46, 19 March 2026 (UTC)
Reply
most do when needed, see
Wiktionary:Inline modifiers
Juwan
🕊️
00:34, 20 March 2026 (UTC)
Reply
looks good to me!
Juwan
🕊️
00:34, 20 March 2026 (UTC)
Reply
Oppose
per above. --
{{
victar
talk
}}
17:21, 20 March 2026 (UTC)
Reply
Oppose
Caoimhin ceallach
talk
23:20, 20 April 2026 (UTC)
Reply
Support
I see no actual arguments above in relation specifically to English. Kinda sad. ~~
Vininn126
talk
12:48, 21 April 2026 (UTC)
Reply
Why do there need to be arguments specifically related to English? My reasons are the same as before in the vote
Wiktionary:Votes/2026-01/Reconsidering_the_parameters_text_and_tree_of_etymon
. I also don't see any arguments pro specifically in relation to English... —
Caoimhin ceallach
talk
14:55, 21 April 2026 (UTC)
Reply
If arguments need not be supplied, I do not see the need to supply my arguments for my above stance. Let my vote count and that be that.
Vininn126
talk
15:20, 21 April 2026 (UTC)
Reply
To be less trite, you say why do they need to be specific to English - well, when discussing whether it should be done for a given language or not, you'd think that there might be more input on that specific issues.
As to the only other argument I've seen, the conclusion seemed quite clear that it was a subjective difference of intuitiveness as opposed to anything else, which is hardly something to argue with.
So if we're going to vote based purely on stances of the template overall, I shall do the same.
Vininn126
talk
15:23, 21 April 2026 (UTC)
Reply
That's fine. But why would you demand arguments from one side only? —
Caoimhin ceallach
talk
18:44, 21 April 2026 (UTC)
Reply
Well, it's been a month, I'm going through with it.
Ioaxxere
talk
23:08, 20 April 2026 (UTC)
Reply
There is not sufficient support to justify this change. --
{{
victar
talk
}}
08:48, 21 April 2026 (UTC)
Reply
Unstriking
Absolutely not sufficient support.
DCDuring
talk
12:33, 21 April 2026 (UTC)
Reply
They have already
added it to the page
. --
{{
victar
talk
}}
17:02, 21 April 2026 (UTC)
Reply
Rolled back.
DCDuring
talk
13:18, 22 April 2026 (UTC)
Reply
I created
this article
(for the seal script character "
") because
Seal script
(篆書) is soon to be encoded as part of Unicode 18.0 in September of 2026, (the allotted codepoint for this particular character "
" will be u+3d4cd).
I created the article ahead of time as a means of previewing how seal script characters articles might look in Wiktionary
The document below shows the upcoming codepoints which will span codepoints 3D000..3FC3F & will encompass 11328 characters sorted by 540 説文解字 radicals
I think it's probably best to treat seal script character formatwise in a similar manner as their Han script counterparts, i.e. a translingual seal script character section containing 説文解字 radical, stroke count, & composition etc., along with various cjk language editions in their own formatting.
For the Chinese language section, I used "zh-see" forms just as I would for any other ancient character form. (although it'd be best to a add seal script form to that template) Obviously, the template completely breaks because of the title used as a placeholder but once seal script is encoded, this won't be an issue
My Japanese is not strong enough to know how the Japanese language sections ought to be formatted for seal script. That is certainly a great topic for community discussion
I'd also love to thank @
Verdy p
for creating this Unicode codepoint directory on Wikimedia Commons for seal script as sorted by 説文解字 radical
very useful & well done
As an addendum, I personally chose not to use the allocated codepoint in the article for "
" because they technically haven't been fully released yet, (and won't be until September). That said, they are being used on Commons, if other users have information which would lend them to believe that the codepoints are indeed firmly & finally determined, then I'd be happy to simply use those codepoints
-Best wishes
鬱鬱鬱ㄓㄥ
23:43, 15 March 2026 (UTC)
Reply
I attempted to move the article for "
" to the upcoming codepoint at the suggestion of @
0DF
who commented in the character's talk page
Talk:Seal_script_character_辵
, it didn't let me move it because the character is in a codepoint outside the allowed range.
That's fine for now I think. The placeholder title is awkward, but it functions for the time being.
I think the main thing I'm interested in is how the CJKV community feels about the formatting, as well as how we should approach seal script from a template & formatting perspective in general. I would love to hear everyone's thoughts, especially some of the pillars of the community such as @
Justinrleung
Fish bowl
etc.
-best wishes
鬱鬱鬱ㄓㄥ
01:31, 16 March 2026 (UTC)
Reply
Wow, thanks, this is cool! :D It's nice to finally have a textual representation of old script forms.
As for Japanese, I suppose I can't be sure either, since I rarely have even seen it mentioned in resources like dictionaries talking about kanji... still, I think in kanji entries, it would make sense to treat seal script characters as just alternative forms of their modern equivalents. This is how kyujitai are now represented – using an alternative-form link to the shinjitai.
Kiril kovachev
talk
contribs
14:07, 17 March 2026 (UTC)
Reply
Kiril kovachev
It is really freaking cool lol. Honestly so excited that these are finally being encoded, it has taken more than 20 years for us to get to this point. As far as article structure is concerned, I think you are absolutely correct. I think it's best we format the articles for these in a very similar way as we do for modern 漢字. We will have to make a new script category, "Seal script". Additionally, we'll have to create a new template similar to
Template:Han char
, (something like
Template:Seal char
) noting that seal script & the Unicode proposal itself
[1]
are sorted by 說文解字 radicals & not 康熙 radicals. The list of which can be seen here:
Shuowen radical
. As far as individual cjkv languages are concerned, we don't need to change much, just add "seal" as an ancient character form. Noting that in some cases, the main character form in Seal script is not necessarily the main character form in modern 漢字. (i.e. we'll have to do something as follows:
"篆書 char. "A" is the seal script form of 漢字 "B" which itself is a variant character of 漢字 "C" which is the orthodox modern form."
) (thankfully, this is specified in the Unicode document itself.) In conclusion, I'm really freaking excited for this & I can't wait for the full Unicode release in September!
-Best wishes & happy 篆書ing
鬱鬱鬱ㄓㄥ
18:20, 17 March 2026 (UTC)
Reply
鬱鬱鬱ㄓㄥ
lovely work! until the release of Unicode 18.0, the entries should remain under the unsupported titles page, until we bulid any needed infrastructure.
Juwan
🕊️
01:30, 18 March 2026 (UTC)
Reply
Thanks for the support as always！ I look forward to creating many new 篆書 articles in the future
-Cheers & Happy 篆書ing
鬱鬱鬱ㄓㄥ
05:10, 18 March 2026 (UTC)
Reply
I aim to replace
T:jbo-etym
with
T:etymon
. Part of this quest is displaying the Lojbanized transliterations of these terms, as that is how the root words were formed (see
this discussion
for a little more detail). However, as kindly identified by
Fenakhay
, manual Chinese transliterations are suppressed (per
this discussion
). I request to either:
allow manual Chinese transliterations in non-Chinese entries
or
(if too broad)
allow manual Chinese transliterations in Lojban entries only.
Please render an opinion for both options.
TranqyPoo
✏️
15:50, 16 March 2026 (UTC)
Reply
I don't see clear documentation describing when to use it on Wiktionary, but the lect code "cmn" specifies Mandarin Chinese. Since Pinyin is Mandarin-specific, I would guess that is more appropriate than just "zh" here, assuming the pinyin transliteration is the source that you're talking about. Compare
Category:Toki Pona terms derived from Mandarin
.--
Urszag
talk
16:06, 16 March 2026 (UTC)
Reply
The same problem occurs when using "cmn". Strangely, {{etymon}}'s automatic transliteration for "zh" is Pinyin. Pinyin is not relevant for my purposes, as the creators seemingly transliterated the terms by how it would sound in Lojban, including English terms (
later
leitr
). I hope that I understood you correctly.
TranqyPoo
✏️
16:51, 16 March 2026 (UTC)
Reply
Please disregard my request
. I now understand that Mandarin was used for transliterating pronunciations and Fenakhay allowed non-
zh
Chinese entries to be transliterated.
TranqyPoo
✏️
18:16, 16 March 2026 (UTC)
Reply
When is language Proto-Romance to be used and how is it distinguised from Late Latin or Vulgar Latin? Last year the guidelines page for Vulgar Latin was renamed to
Wiktionary:Proto-Romance entry guidelines
with the comment "Theknightwho moved page Wiktionary:Vulgar Latin entry guidelines to Wiktionary:Proto-Romance entry guidelines: This is about Proto-Romance, as we explicitly state in the lede." Did somebody kill Vulgar Latin and I missed it? Is there a policy page explaining?
Vox Sciurorum
talk
19:53, 17 March 2026 (UTC)
Reply
Vox Sciurorum
"Late Latin" is normally used for attested written Latin from roughly 200-500 (or at the latest, something like 700) CE: basically, the time period between Classical Latin and Medieval Latin. For example, Macrobius and Jerome are Late Latin authors, and Isidore can be considered to fall in the endpoint of this period. Applying the Late Latin label to unattested forms would be less usual, but could possibly be justified if there's a reason to think the absence of attestations in these kinds of documents was merely accidental. "Proto-Romance" is normally used for unattested terms that are reconstructed exclusively or mostly by bottom-up comparison of Romance-language data. "Vulgar Latin" is used in various ways, sometimes as more or less a synonym of "Proto-Romance", sometimes to refer to one or more hypothesized distinct low-prestige registers of Latin used during various historical time periods when it was spoken.--
Urszag
talk
20:19, 17 March 2026 (UTC)
Reply
Discussion moved from
User talk:-sche
Hello! I'd like to ask you to give me event organizer rights in order for me to create a page for an online workshop on adding Yiddish words to the English Wiktionary. Thank you in advance!
Warm regards,
Luftmentsh
Luftmentsh
talk
11:06, 18 March 2026 (UTC)
Reply
I've moved this from my user talk page to see if anyone else has input. It does not appear that Wiktionary has used this user-group / right before. As I understand it, granting the "event organizer" user-group / rights would allow the user to create an event page in the Event: namespace (AFAICT we currently don't have any, but see
w:Event:Australia wishes Wikipedia a Happy 25th Birthday
for example), enable event registration on that page, and let them send emails to registered participants. At least on Wikipedia, the right also allows "users to create accounts without being subject to the 6 accounts per IP address limit" and allows the editor "to temporarily add confirmed status to event attendees with newly created accounts, bypassing the standard four-day wait", which allows them to "skip CAPTCHA checking when adding links" (so they can create a bunch of accounts which can add a bunch of links very quickly).
- -sche
(discuss)
19:04, 18 March 2026 (UTC)
Reply
As we have no experience with this, I'd be concerned with granting such powers to a user other than one who had a long and clean record, preferably on en.Wiktionary, where their contributions have been for nearly a year. If there are some users who have encountered Luftmentsh on other projects, they can vouch for them.
DCDuring
talk
19:22, 18 March 2026 (UTC)
Reply
I recommended Luftmentsh to reach out to admins to get this permission. It is just technical formality to create event page, there are close to none other "powers" that it gives. Please note that all autoconfirmed users can create events on small wikis, just some bigger projects, including English Wiktionary requires role to be assigned, but, again, it is just formality to get event page going.
Renvoy
talk
19:42, 18 March 2026 (UTC)
Reply
I see; I appreciate this information (as I said, I believe this is the first time anyone has requested this right on this wiki, so I know little about it). If this is just a formality, I'll wait a day or so to hear if Wiktionary's other main technically adept and/or vandal-fighting editors (@
Chuck Entz
Surjection
This, that and the other
,...) foresee any problems with it and, if not, then I'll grant the right — or if any other admin here has experience with this user-right on other projects and feels it's fine to grant, they should feel free to beat me to it.
- -sche
(discuss)
20:33, 18 March 2026 (UTC)
Reply
-sche
I have no issues with granting the right. Reading
the documentation
and
FAQ
satisfies me that the event organiser role is self-contained.
This, that and the other
talk
23:15, 18 March 2026 (UTC)
Reply
-sche
also, you are incorrect, on English Wiktionary this permission does not allow adding confirmed status or meddling with CAPTCHA. See
Special:UserGroupRights
Renvoy
talk
19:50, 18 March 2026 (UTC)
Reply
I see. Can you update
w:Wikipedia:Event coordinator
, then? It currently says that "
The event coordinator user group (eventcoordinator user group) [...] Allows editors to temporarily add confirmed status to event attendees with newly created accounts, bypassing the standard four-day wait. Confirmed status allows those accounts to directly create new articles, move draft pages to articles, skip CAPTCHA checking when adding links, and upload images.
- -sche
(discuss)
20:14, 18 March 2026 (UTC)
Reply
It differs from English Wikipedia and English Wiktionary. What you wrote is correct just for Wikipedia.
Renvoy
talk
20:22, 18 March 2026 (UTC)
Reply
I see; then what I wrote was correct ("at least on Wikipedia, the right also allows..."), but I appreciate you letting us know that that is only on Wikipedia and is not the case on Wiktionary.
- -sche
(discuss)
We have now established how inexperienced those who have participated in this little discussion so far are about this. Where do we find how this user group is empowered on enwikt?
DCDuring
talk
20:37, 18 March 2026 (UTC)
Reply
The page Renvoy linked to,
Special:UserGroupRights
, says Event organizers have these rights on this wiki: "Email event participants (campaignevents-email-participants), Enable event registrations (campaignevents-enable-registration), Generate invitation lists (campaignevents-generate-invitation-lists), and Organize events (campaignevents-organize-events)". I suppose this is probably harmless, but as I said, will wait a day to let other people comment.
- -sche
(discuss)
20:42, 18 March 2026 (UTC)
Reply
Indeed, I was just looking there.
What does "Organize events" mean? I could organize an event to my own satisfaction right now. What specific powers are authorized by (campaignevents-organize-events). Just that an event I organize is "official"?
DCDuring
talk
20:48, 18 March 2026 (UTC)
Reply
Again, it is just technical rights to use Event extention
Renvoy
talk
21:12, 18 March 2026 (UTC)
Reply
Luftmentsh
: I would like to ask you to
add sources
(references or quotations), particularly during the event, but also generally when creating Yiddish entries. I think the last thing our dictionary needs is hundreds of stubs that will have to be cleaned up after the event :)
Thadh
talk
07:24, 19 March 2026 (UTC)
Reply
Don't see how this is any relevant to this discussion and if you are not happy with any edit I've made so far, feel free to update it.
Luftmentsh
talk
11:02, 19 March 2026 (UTC)
Reply
I've found your handling of this to be condescending. If it were a mere formality, "permission" wouldn't be required. We have no particular reason to trust folks we don't know who ask for such permission who duck questions by saying "just a formality". I trust TT&O, not you.
DCDuring
talk
14:21, 19 March 2026 (UTC)
Reply
I did not duck any of your questions and I have been always ready to answer any of your questions concerning the event I was planning. And it wasn't me who told you about "formality", so I guess you are answering to the wrong person. Regarding any wishes for the event or my contribution to the Wikipedia projects (if this is why you decided to call me condescending), I have been always ready to take them into consideration, of they are transmitted politely, which the comment of @
Thadh
was not.
Luftmentsh
talk
14:53, 19 March 2026 (UTC)
Reply
I apologise if my request seemed impolite, I most definitely did not intend it as such. I simply asked you to format entries properly during the event you are planning, since I assume it will envolve the creation of many entries by potential new users, and I think it would be a good idea to set a good example for them. Seeing as your recent entries did not add references or quotes, I thought it would be best to make sure you understand that adding them is crucial, especially for minority languages like Yiddish.
Thadh
talk
06:55, 20 March 2026 (UTC)
Reply
And the very last note/answer from my side: I asked @
-sche
for the permission in a very polite way. Since then, I haven't obtained any event-specific questions and instead of just admitting that neither @
-sche
nor you, @
DCDuring
, know how to grant me this permission and transfer me to a person responsible for this matter, you decided to call me "condescending" and leave some strange comments regarding the event. I agree that sources are important and that sometimes as a native speaker I tend to neglect them, but for the surprise of three of you, I wasn't planning this event for the admins to have more cleaning job in "your dictionary" and did not deserve this kind of comments. I needed these right in order to be able to create a talk page for the event and invite people, since I prefer to work not only with folks I know. And just FYI, I fit all your criteria, I have a clean record and have been active for almost a year. So once again, no point in treating me like this. Even if I had been active on wiktionary only for a month, it would not be an excuse, since you just cannot treat newcomers like this. If you have further questions regarding my contribution, you can always address them in a
polite
way on my talk page. Kind regards, Luftmentsh
Luftmentsh
talk
16:09, 19 March 2026 (UTC)
Reply
We might know how, but I for one didn't trust you and have the feeling now that that lack of trust might be permanent. We can treat newcomers who ask for special permissions exactly like this. In fact. I think it is our duty to do so.
DCDuring
talk
18:32, 19 March 2026 (UTC)
Reply
I am sorry this discussion has become a bit heated.
Luftmentsh's
request on my talk page for Event Organizer rights was polite, and (as I said) I moved it here only because I wanted to check that the Wiktionary community was OK with someone organizing an Event, because that's never happened before, and Wiktionary (being a smaller community than Wikipedia) has fewer people-hours available to bring entries up to snuff if (for example) newbies were to enter a lot of unsourced entries. After Renvoy's informative replies and TTO's, I was prepared (as I said) to grant the rights, but I have to say that Luftmentsh's response to Thadh's polite request to ensure entries have sources has given me pause. It is not my impression that the community wants a bunch of unsourced or potentially non-CFI-meeting entries, so I would feel better if the response had been "sure, I will make sure entries are sourced" (as it is, and perhaps I am misunderstanding it, it comes across to me as suggesting that Thadh should do the work of updating any unsourced entries to be sourced). Again, I'm sorry this discussion has become heated, and I hope we can dial the temperature back down. Trusting, based on Luftmentsh's other comment, that effort will be made to ensure the entries that are added (during the Event and in general) meet our
criteria for inclusion
(which, in the case of Yiddish, means being sourced to another dictionary, or having a quotation of use in a book, magazine, etc), I will add the rights shortly: Wiktionary can have its first Event and see how it goes.
- -sche
(discuss)
23:47, 19 March 2026 (UTC)
Reply
I apologize to all for contributing to the heat of the discussion. I might have been even testier, though, had I realized that we were inviting folks to contribute entries likely to be unsourced. Perhaps we need to give a regular Yiddish contributor event organizer rights if such rights would enable them to reach out to would-be event participants about sourcing etc.
DCDuring
talk
21:39, 20 March 2026 (UTC)
Reply
I have granted Luftmentsh Event organizer rights. I set them to expire after six months (if they are needed for longer, please comment). I have done this with the understanding that entries added to mainspace during the event (and in general) will in general be sourced, to meet our criteria for inclusion. (If the event is e.g. inviting Yiddish speakers to add words they personally know, without regard to whether they are attested anywhere in print, it might be better to collect those in userspace or on the event page.)
- -sche
(discuss)
08:30, 21 March 2026 (UTC)
Reply
I would like to add inflected forms based on the Latin third/fourth conjugation future, both of which likely continue the original Proto-Indo-European thematic subjunctive. However, it is not exactly clear how to properly label these categories within Proto-Italic. They could be construed as subjunctive due to their historical origins, though that would conflict with the existing PIt subjunctive forms, which are actually optative in origin. To further complicate matters, it is also disputed whether or not the optative and subjunctive had even merged by Proto-Italic. For instance, Rix, in his article
Towards a reconstruction of Proto-Italic
does differentiate between the optative and subjunctive at the Proto-Italic level. We could treat the pre-forms of the Latin third/fourth conjugation as future forms, but this could maybe conflict with the Sabellic evidence, where the future is actually sigmatic and derived from an aorist subjunctive (see
Umbrian
ostensendi
Oscan
didest
). Given that Old Latin attests to both a sigmatic and 'regular' future, it might be best to also reconstruct two separate future formations at the Proto-Italic level.
Graearms
talk
00:00, 21 March 2026 (UTC)
Reply
Also, we currently are not consistent regarding whether we choose to label PIt inflectional categories based off their Latin outcomes or their PIE origins. For instance, the template for
*ezom
provides a set of forms that, though historically subjunctive, eventually evolved into the Latin future. Nevertheless, the page still reats these terms as subjunctive at the PIt level. However, the template for the conjugation of
*welō
treats the historically optative forms as Proto-Italic subjunctives.
Graearms
talk
20:40, 26 March 2026 (UTC)
Reply
in Portuguese, several given names are variations ending in
-o
(masculine) and
-a
(feminine). as such, many entries use the
|f=
in
{{
pt-prop
}}
to include these. my question is whether this should be formatted inline with
{{
given name
}}
, following the practices of other languages without grammatical gender. the second option is what I personally have done in my edits.
Juwan
🕊️
00:29, 20 March 2026 (UTC)
Reply
(Notifying
Daniel Carrero
Jberkel
Cpt.Guapo
Munmula
Koavf
Sarilho1
Benwing2
SinaSabet28
MedK1
Polomo
Psi-Lord
Emanuele6
):
notifying Portuguese-language editors. for clarity, the options that I am asking about are as follows:
Option A
: using both the hatnote and inline given name params to indicate the feminine. using the name
Alberto
(feminine
Alberta
) as an example:
===Proper noun===
{{
pt-prop
}}
{{
given name
pt
male
Alberta
}}
Option B
: only using the inline given name params.
===Proper noun===
{{
pt-prop
}}
{{
given name
pt
male
Alberta
}}
Option C
: only using the hatnote params.
===Proper noun===
{{
pt-prop
}}
{{
given name
pt
male
}}
Juwan
🕊️
13:48, 25 March 2026 (UTC)
Reply
Option A
or (in less clear cases)
, personally, as this is the clearest to me.
Juwan
🕊️
13:50, 25 March 2026 (UTC)
Reply
I don't think it matters much, but I think whatever is consistent with other languages is better.
Andrew Sheedy
talk
02:24, 30 March 2026 (UTC)
Reply
I prefer
myself, and I think that’s more common, too... we don’t even indicate the plural for proper nouns most of the time (even though we should).
{{
given name
}}
is special because, although it occupies the definition line, it gives etymological info and lists derived/related terms; in this particular case, I don’t feel the redundancy of also listing them in the headword is needed.
By the way, nobody got your ping; you should ping again.
Polomo
⟨
oi!
⟩ ·
22:54, 2 April 2026 (UTC)
Reply
According to the RAE's
Dictionary of the Spanish Language
, the etymology of
armazón
is
armatio, -ōnis
Shouldn't it read
armatio,
ti
onis
, so that it is not confused with
-onis
Or rather it is our entry that should be corrected?
JMGN
talk
12:18, 21 March 2026 (UTC)
Reply
This isn't about stems, broken down, the word does indeed read as
armā-tiōnis
. In displaying Latin nouns, the genitive singular giving up the word's declension pattern to the reader can be shortened to its ending (here
-ōnis
) for the sake of being convenient (note we ourselves don't do so), not according to suffixes, but other rules. So that seeing
-ōnis
does not imply
armātiō
is suffixed with
-ō, -ōnis
Saumache
talk
15:24, 21 March 2026 (UTC)
Reply
What Saumache said. armatio, -ōnis is simply an abbreviation of armatio, armatiōnis: for brevity, "armati..." is omitted from the genitive singular since it is unchanged from the nominative singular. This abbreviation has no significance: armatio, -tiōnis, or armatio, armatiōnis would just be longer ways of writing the same thing.--
Urszag
talk
16:10, 21 March 2026 (UTC)
Reply
Continuation of
Wiktionary:Beer parlour/2026/February#Updating_on_how_reduplications_are_handled
Reduplication is often denoted using patterns; in English they are "C" for consonant and "V" for vowel. I'm using Ilocano as an example (due to it being highly agglutinative), but this is common across Austronesian languages.
TLDR:
I'm tracking all related terms at
Category:Terms with reduplication patterns
. —
Yivan
000
view
talk
15:43, 21 March 2026 (UTC)
Reply
Comment:
for the third bullet point, the word is
circumfix
, I believe. for last one, this involves more than reduplication, as these are used in all types of terms; I can't remember a good term for these, however. thank you for the good work on Philippine languages.
Juwan
🕊️
13:33, 25 March 2026 (UTC)
Reply
Juwan
I intentionally avoided "circumfix" since it gets iffy when there is reduplication involved. Also, is
manaC- -V-
considered a circumfix? To solve these questions, I simply consider them as just affixes (a more broad term). —
Yivan
000
view
talk
03:32, 27 March 2026 (UTC)
Reply
Discussion moved from
Wiktionary:Tea room/2026/March
I checked that sorbian Doesnt has a wiktionary, can I suggest one, and where is the page to do that?
JadenGotLost
talk
22:30, 21 March 2026 (UTC)
Reply
JadenGotLost
: it's at "
meta:Language committee/Handbook (requesters)
". However, note that there is already an
Upper Sorbian Wiktonary
, and a
Lower Sorbian Wiktionary
at the
Wikimedia Incubator
, which you can edit. "Sorbian" itself doesn't appear to be a language; rather, it is a
group of languages
consisting of Lower Sorbian and Upper Sorbian. —
Sgconlaw
talk
22:46, 21 March 2026 (UTC)
Reply
The current
Hittite entry guidelines
state that verbs should be lemmatized at their infinitive, which is inconsistent with the vast majority of current Hittite verb entries, almost all of which are lemmatized to the third-person singular non-past active. We should probably update the Hittite entry guidelines accordingly or be prepared to move all of these pages.
Graearms
talk
00:57, 22 March 2026 (UTC)
Reply
Full support of this policy change. --
{{
victar
talk
}}
06:37, 22 March 2026 (UTC)
Reply
Given that it's basically policy already, and that there is currently no opposition, I'll
be bold
and implement this policy change, even though there hasn't really been much discussion.
Graearms
talk
20:55, 19 April 2026 (UTC)
Reply
Hello, this message is to notify that
Faster than Thunder
has been nominated for a global ban at
m:Requests for comment/Global ban for Faster than Thunder
. You are receiving this notification as required per the
global ban
policy as they have made at least 1 edit on this wiki. Thanks, --
SHB2000
talk
01:55, 22 March 2026 (UTC)
Reply
I've been looking through our entries for Hittite verbs recently and there are a bunch of issues with the treatment of the language on Wiktionary. In particular, the way we handle all of the different spellings of Hittite words seems problematic. Currently, there are bunch of entries on Wiktionary that are unattested variant spellings of otherwise attested Hittite words, such as
𒀭𒉌𒄿𒄑𒍣
an-ni-i-ez-zi
𒀀𒊑𒄑𒍣
a-ri-ez-zi
or
𒄿𒁕𒀀𒆷𒌑𒌍𒍣
i-da-a-la-ú-eš-zi
. This is in direct violation of the current Hittite entry guidelines, which state that "if the lemma form [in this case, meaning the infinitive of a verb] is not attested, the page must be treated as a reconstruction." We could just delete the aforementioned pages and move their contents to some other entry in the reconstruction namespace. Alternatively, we could remove the policy in question and treat technically unattested 3s.pres forms of verbs as normal lemmas in the mainspace, the same way we won't treat a Latin 1s.pres.act.indc form of a verb as reconstructed even if that form specifically is not attested. We could also just lemmatize at other inflected forms in the absence of an attested 3s.pres, as in the case of
𒅗𒆷𒀭𒃰𒁺
ka-la-an-kad-du
, though apparently that term itself has an uncertain conjugation, which would presumably qualify it as an exception to any rule.
But also, just to complicate matters, all of the aforementioned entries beside
𒅗𒆷𒀭𒃰𒁺
ka-la-an-kad-du
actually do have other attested 3s.pres forms, though they aren't included on Wiktionary for whatever reason. For instance, we have chosen to lemmatize at
𒀭𒉌𒄿𒄑𒍣
an-ni-i-ez-zi
instead of an attested form such as
𒀀𒉌𒄑𒍣
a-ni-ez-zi
. This issue extends to the inflection table templates themselves. Consider the page
𒂊𒅁𒍣
e-ep-zi
, where the inflection table template provides the 1pl.pres.act form
𒀊𒁍𒂊𒉌
ap-pu-e-ni
instead of any of the myriad attested forms provided by Kloekhorst. I am not sure whether or not all of these forms are viable alternative spellings of the word in Hittite cuneiform; however, we should still probably prioritize the actually attested spellings over the ones artificially generated for Wiktionary. Such a policy would require some adjustment to the Hittite inflection-table templates as well, though perhaps that discussion is better left for the grease pit.
Even when the inflection template does provide an actually attested form, it usually leaves out other spelling variations found in Hittite texts, and—since there are no standardized criteria for deciding between these forms—the choice seems somewhat arbitrary: Is there any particular reason why the conjugation table for the page
𒂊𒅁𒍣
e-ep-zi
must provide the 3pl.pres.act form
𒀊𒉺𒀭𒍣
ap-pa-an-zi
instead of
𒀀𒀊𒉺𒀭𒍣
a-ap-pa-an-zi
? Thus, either we should come up with a clear set of rules regarding the choice of any particular inflected form or adjust the conjugation templates to allow for the inclusion of all of the different forms.
Moreover, the inflection templates for Hittite verbs do not provide links for any terms other than the lemma itself. It seems somewhat strange to not include entries for attested non-lemma forms in Hittite, but to include such entries for other ancient languages like Umbrian, especially when we are willing to include reconstructed non-lemma forms for languages like
Proto-Germanic
. I would like to propose that we edit the conjugation templates to link to attested non-lemma forms. If we are not willing to accept such a policy change, then we will have to delete entries like
𒀀𒊭𒀭𒈾
a-ša-an-na
. However, I am not sure whether we should include entries for any unattested inflectional forms in Hittite. Since there are often multiple possible spellings of the same Hittite verb, there is something that seems especially artificial, I suppose, about creating pages for any specific cuneiform spelling of a Hittite inflection forms. We could mention such possible forms in the inflection template itself, and then just not have them link to any page.
Interestingly enough, it looks like we already have a bunch of romanizations for Hittite non-lemma forms, even though the corresponding cuneiform entries do not exist: See
i-da-a-la-u-wa-aḫ-ḫi
a-ni-ya-az
, and
al-la-an-da-ru
Graearms
talk
19:00, 23 March 2026 (UTC)
Reply
Kloekhorst, Alwin
2008
),
Etymological Dictionary of the Hittite Inherited Lexicon
(Leiden Indo-European Etymological Dictionary Series; 5), Leiden, Boston: Brill,
→ISBN
pages
179-180
Kloekhorst, Alwin
2008
),
Etymological Dictionary of the Hittite Inherited Lexicon
(Leiden Indo-European Etymological Dictionary Series; 5), Leiden, Boston: Brill,
→ISBN
page
202
I would like a gadget or extension that can restricts any list of pages, e.g., from
Special:Search
or
Special:WhatLinksHere
, to pages that only include an entry in a specific language (or possibly set of languages). For example, to list only pages with an English entry that link to a Latin word. Most reconstructed roots have categories for these, but other entries do not.
Note that it need not be the English entry on that page that links to a word. That would be ideal but much more complicated.
I can imagine a technical solution. There are colorizing and pagepreview gadgets the follow links and look at target contents. In this case, simply
display: none
for the entries to be filtered out rather than changing a link's color or display a preview. While this can be slow, it need only be applied when a filter by language option has been specified. This option would need to be added where useful, which is perhaps why an extension might be required. A MediaWiki-based software solution would be ideal (to prevent, for example, only 12 links to be shown in a list that ought to have 20), but there is no current method to indicated a set of language entries per page (the main content language is always English for the English Wiktionary).
Is this the right place to request such a feature?
Dpleibovitz
talk
21:08, 23 March 2026 (UTC)
Reply
Howdy! I intend to add the following line under
Further reading
for all
Lojban gismu
* {{R|jbo|Cowan:2018|id=section-gismu-making.html|section=4.14. The gismu creation algorithm}}
* {{R:jbo:gismu}}
This source informs the reader how gismu terms were systemically created. I request either:
Someone with bot privileges to perform these edits, or
Temporary permission to use AWB to perform these edits myself.
Please let me know if you need more information.
TranqyPoo
✏️
20:50, 24 March 2026 (UTC)
Reply
Minor comment
: would you consider using a simpler wrapper template, say
{{
R:jbo:gismu
}}
, rather than having to specify the entire reference manually?
Juwan
🕊️
13:59, 25 March 2026 (UTC)
Reply
Done
TranqyPoo
✏️
14:48, 25 March 2026 (UTC)
Reply
per
this request on CLTR
(notifying @
Sgconlaw
), I wish to know what is the preferred way to name etymon IDs with verbs, specifically whether they should include the infinitive
to
before them.
Juwan
🕊️
13:17, 25 March 2026 (UTC)
Reply
not entirely sure which groups to explicity notify regarding this, as it involves basically every language.
Juwan
🕊️
14:12, 25 March 2026 (UTC)
Reply
No
to
, as we do for PIE roots.
Trooper57
talk
15:30, 25 March 2026 (UTC)
Reply
I made the request because I noticed that there were a cluster of categories for terms derived from Proto-Indo-European roots where the "etymon ID" (is that what they're called) was, for example, "to bend" rather than just "bend". I hadn't seen this done before—all other categories of this kind which I've seen omit the word
to
. Seems like it's easier if we do this, especially since some PIE roots are both verbs and nouns. —
Sgconlaw
talk
15:39, 25 March 2026 (UTC)
Reply
Yeah, every time I've seen it was because someone added
{{
etymon
}}
without using the preexistng ID.
Trooper57
talk
15:53, 25 March 2026 (UTC)
Reply
The Wiktionary convention for Navajo, as best I've understood it, is for verb roots to have ALL UPPER-CASE entries, and all verb stems (derivations from that root) have all lower-case entries.
I think this
-LǪ́
entry may have been created in error. That etymology currently says:
Closely related to
-LĮ́Į́ʼ
However, if we view instead the related entry at
-LĮĮD
, we see that verb stem
-lǫ́
is listed as the neuter imperfective, and indeed the verb entry at
hólǫ́
it is, there are
also explicitly describes this
-lǫ́
verb stem as the neuter imperfective form of verb root
-LĮĮD
Side note: Some of the terminology regarding Navajo seems a bit odd, due to choices made by US linguists decades ago. Navajo verbs do not have grammatical gender -- "neuter" here refers instead to a kind of stative verb form.
I notice also that
Special:WhatLinksHere/-LǪ́
has almost nothing; the only mainspace incoming link is from
-LĮ́Į́ʼ
, which was added by
Julien Daux
talk
contribs
) way back in
this edit
from 2016.
It looks like Julien ceased any Wiki editing in 2019. The only other editor I'm aware of currently working on Navajo is @
Vergencescattered
. Vengence, do you (or any other editor savvy to Navajo) have any objection to deleting the entry at
-LǪ́
and reworking mentions of this to point to the verb-stem entry
-lǫ́
instead? ‑‑
Eiríkr Útlendi
Tala við mig
17:58, 25 March 2026 (UTC)
Reply
Per
Young and Morgan 1992
: "The neuter stem LǪ́: exist is (arbitrarily) included under LĮĮD." The next page refers to "a closely related stem LǪ́: exist" (related, that is, to -LĮ́Į́ʼ). So it seems that it is kind of unclear whether it should be treated as a fully distinct root or as simply a stem of -LĮĮD, but Young and Morgan prefer to refer to it as a stem. For consistency and convenience, I think it makes sense to keep -LĮĮD as the main entry, with -LǪ́ as a redirect or alternative form.
Vergencescattered
talk
18:47, 25 March 2026 (UTC)
Reply
Just some etymological speculation about the relationship between them: Lower Tanana has a transitional perfective suffix -t ~ -d in certain verb roots. I suspect that the same suffix appears in -LĮĮD, since that is a momentaneous/transitional perfective stem. Thus,
-LĮĮD
would be cognate with
Lower Tanana
lat
, (compare the corresponding imperfective stems
-lįįh
and
lax
). Meanwhile,
-lǫ́
-lin
-lį́
would be cognate with LT
lanh
, and
-LĮ́Į́ʼ
would be cognate with LT
la'
. The Ahtna equivalents would be
laet
laen
leʼ
Vergencescattered
talk
21:53, 25 March 2026 (UTC)
Reply
Thank you for this additional detail, that's quite interesting to me. Presumably you refer to
lax#Lower_Tanana:_be
? I've long wondered about the perfectives in Navajo -- if you peruse the list of roots and their perfective forms as listed at
Appendix:Navajo_roots_and_stems_derivation#Roots_and_stems_table
, most of them end in either
-d
or
-ʼ
(glottal stop). Several also include a shift to a nasal vowel or a final
-n
, which I suspect might be related to the terminative
ni-
, possibly also indicating the ongoing resulting state of the action of the verb, perhaps as in root
-TIN
to freeze
. ‑‑
Eiríkr Útlendi
Tala við mig
01:13, 26 March 2026 (UTC)
Reply
Yes, I meant the stem in Etymology 2, sorry for the confusion! The "fish swim" root is unrelated.
As you noted, there seem to be two main ways of forming the perfective in Athabaskan languages, the "glottal perfective" (formed with Proto-Athabaskan *ʔ) and the "nasal perfective" (formed with PA *nʸ / *n / *ŋ / *ŋʸ, depending on the reconstruction). Like I said above, Lower Tanana has a transitional perfective -t ~ -d that I suspect is also reflected in some Navajo roots like -LĮĮD, but I haven't seen anything discussing whether that suffix exists in Navajo. I'm not sure if the perfective suffix is related to the terminative, although it's certainly possible, since the progressive suffix
*-ɬ
and the
*ɬ-
classifier are related despite being on different sides of the verb root. I would have to check, but I believe I remember reading that the *nə-perfective prefix is related to the terminative, which would strengthen the case that the terminative is related to the nasal perfective suffix.
The exact usage of the glottal/nasal perfectives doesn't seem to be consistent across languages. For example, the root
*čən
has a glottalized perfective in Navajo and Wailaki, but not in Lower Tanana, and Ahtna only has glottalization in the transitional aspect. (Note that in this case, the *-n in the root is apparently just part of the root, not the perfective marker). In other cases, Navajo has the nasal perfective, but Ahtna and LT don't.
*teˑ
came out as
tae
in Ahtna (neuter perfective teʼ),
ta
in LT (neuter perfective ta'), and
-TĮ́
in Navajo, which apparently reflects a PA form *teˑnʸ. Likewise, PA
*qaˑ
resulted in Ahtna
kaa
(neuter perfective
kaʼ
), LT
ko
(neuter perfective
ko'
), and Navajo
-KĄ́
. (As a side note, I'm not certain why Kari gives a non-glottalized form for the shape of the root in the Ahtna and Lower Tanana examples, but I assume it's because the glottal stop is technically a suffix).
It's also worth nothing that some of the Navajo perfectives ending in -d appear to come from roots that ended in *tʼ in Proto-Athabaskan, such as
-WOD
and
-TSʼǪ́Ǫ́D
. Meanwhile
-KĄĄD
to sweeten
comes from a PA root ending in *nʸ (cf. Ahtna
kan
, which I haven't created yet). But that Ahtna root has a transitional stem
kaat
that I suspect is related to the Navajo form. This still leaves the nasalization in Navajo unexplained, though. Perhaps it was extended from other nasalized stems by analogy, or perhaps both the perfective *nʸ and the transitional *t suffixes were applied to it. That's just speculation on my part, though.
There don't seem to be a lot of good sources breaking down the aspect suffixes that form Athabaskan stems (and I don't know that it's clear whether these affixes were still productive in Proto-Athabaskan), but the best I've seen comes from the introduction of
Athabaskan Prosody
. Rice and Hargus reconstruct: *-ç for the momentaneous imperfective (Kari 2024 has this as *xʸ but I think this is just an orthographic difference); *-ŋ for the perfective (as I mentioned above, there are several different ideas of what this nasal actually was); *-ʔ for the durative perfective and optative mode; *-ɬ for the progressive, which is also used for the future mode; *-kʸ for the customary (Kari 2024 reconstructs two customary suffixes, *-k and *-g); and *=he for the negative (I'm not sure what the equal sign represents here; in any case, I don't think it's preserved in Navajo).
Let me know if I can clarify anything :)
Vergencescattered
talk
03:03, 26 March 2026 (UTC)
Reply
I have a few questions about the linguistic terminology.
What does "transitional" mean in this context? Does this indicate a semelfactive / momentaneous / telic / etc. change-of-state kind of action?
What does "neuter" actually mean for Navajo verbs? I've long been puzzled by Young and Morgan's word choice for this. Is my intuition right that this indicates some kind of ongoing stative quality?
Separately:
The
-KĄĄD
to sweeten
root does have a nasal vowel in most forms, with only the neuter imperfective stem
-kan
not having a nasal vowel, although it does have that nasal coda consonant. Is the nasal vowel for most forms, and the final
-n
in the neuter imperfective, reflective of the
*nʸ
in the PA root? If so, is the final
-d
of the root, which only appears in the perfective form, reflective of the "transitional perfective" you mention in Lower Tanana?
The
-LĮĮD
to become, to appear
root currently only really has one derived verb,
hólǫ́
he/she/it exists
, with derived nominal
hólóní
the one that exists
. Yet, the
-LĮĮD
entry lists several other verb-stem forms, and it looks like the only stems that have any derived verbs are those stem forms shared with root
-LĮ́Į́ʼ
to become; to happen; to be born
What is the basis for reconstructing a separate verb root
-LĮĮD
on the basis of verb stem
-lǫ́
Are there actually other verbs derived from this same root, that reflect any of the other verb-stem forms listed in the
-LĮĮD
entry?
It doesn't seem to make sense to have entries both for a verb stem
-lǫ́
explained as deriving from verb root
-LĮĮD
, and for a separate verb root
-LǪ́
but with ostensibly the same derived verbs as for
-LĮĮD
. (
-LǪ́
doesn't currently list any derived verbs, but
hólǫ́
is the only fitting verb I can think of.) Do we really want to have these two separate entries,
-lǫ́
and
-LǪ́
Thank you for sharing your expertise! ‑‑
Eiríkr Útlendi
Tala við mig
18:00, 26 March 2026 (UTC)
Reply
The transitional aspect in Athabaskan generally refers to a change in state, usually 'becoming' or 'turning.' For example, the transitional verb
yiistsóóh
means 'it is turning yellow.' All the transitional aspect forms of
-TSOII
refer to in some way becoming, turning, or being turned yellow or brown. Transitional stems are often similar or identical to momentaneous stems, and I'm not really sure what the relationship between them is. As far as I know, the semelfactive is treated as a completely different aspect, and I'm not aware of any direct link to telicity. However, that might just be a lack of knowledge on my part.
The use of neuter in Athabaskan is, frankly, annoying. In Navajo, neuter imperfective verbs are generally just stative verbs. For example, using the same root as above,
łitso
means 'to be yellow.' While the transitional verb describes
becoming
yellow, the neuter describes
being
yellow. A few neuter imperfectives also have distinct comparative forms. The neuter perfectives, meanwhile, generally describe position or existence. For example,
siʼą́
means 'a solid roundish object lies, exists, is in position.' These positional verbs can be transitive, though, with the meaning 'keep an object in place.' I feel like 'stative' and 'positional' verbs would have been a more useful label, but alas.
WRT
-KĄĄD
: I believe the final -n in
-kan
reflects the original Proto-Athabaskan nasal, but I'm not sure why the vowel didn't nasalize like it did in most other forms. The same thing seems to have happened in
-lin
and
-zhin
, but I'm not sure why. I believe that the final -d reflects the same transitional suffix, but that's based on my own analysis, not a specific source.
WRT to
-LǪ́
: I think this should be at most an alternate form, rather than a full entry. It's not separate from
-LĮĮD
WRT to -LĮĮD and
-LĮ́Į́ʼ
. Young and Morgan
say
that these two are 'probably cognate' but that 'the distinctive variations in stem form appear to justify separate treatment.' There are a couple of other verbs that are formed from -LĮĮD, such as
hodolįįh
. That's a momentaneous verb, with the stem -lįįh, as opposed to the momentaneous stem
-leeh
that we see for -LĮ́Į́ʼ. One wrinkle, though: although our article doesn't mention it, -LĮ́Į́ʼ has two momentaneous perfective stems:
-lį́į́ʼ
and
-lįįd
. Based on all of that, I don't think it would crazy to merge the two roots and say that it has two separate momentaneous stem sets. That isn't unheard of, but I do think it makes more sense to treat them as separate. In any case, the
-LĮĮD
entry needs to be rewritten, which I can do soon.
Another wrinkle: This is also not present on our entry, but there is another root with the shape
-LĮĮD
with the meaning 'be(come) interesting.' Young and Morgan say it might be identical to either the other
-LĮĮD
or -LĮ́Į́ʼ, but don't seem to prefer either one. As such, even if we merge these two entries, we will probably want to keep a page at
-LĮĮD
for this root.
One final detail which I somehow missed yesterday: Young and Morgan refer to the root
-LĮ́Į́ʼ
as "often" having a suffix *d in the transitional, which I think supports my theory that the same transitional suffix exists in Lower Tanana and Navajo. At some point, hopefully later today, I will create an entry for
Proto-Athabaskan
*leˑ
that can hopefully detail all this information more conveniently for future readers.
Vergencescattered
talk
18:52, 26 March 2026 (UTC)
Reply
Eirikr
I have created
Proto-Athabaskan
*leˑ
and redone
-LĮĮD
. The way the stem set is listed in YM1992 is a bit confusing, so I'm not sure exactly what the transitional stems for -LĮĮD are supposed to be. I will create entries for
hodilįįh
and some verbs Etymology 2 under -LĮĮD later tonight. Let me know what you think! If you're okay with it, I'll also turn
-LǪ́
into an alternative form of -LĮĮD, as long as that's okay with you?
Vergencescattered
talk
03:33, 27 March 2026 (UTC)
Reply
Thank you for your work!
Re:
"If you're okay with it, I'll also turn -LǪ́ into an alternative form of -LĮĮD, as long as that's okay with you?"
-- crikey, I'm no expert. 😄 I'm coming at this as someone who is not an Athabaskanist, just trying to puzzle out the terminology and make sense of what looked like conflicting information. I think the differences in phonology between the two (vowels, tone, coda) are difficult to understand, but if the "alternative form" approach makes sense to you, please proceed! ‑‑
Eiríkr Útlendi
Tala við mig
17:53, 27 March 2026 (UTC)
Reply
Rib eye
's etymology doesn't mention it though.
JMGN
talk
00:44, 27 March 2026 (UTC)
Reply
I fixed it.
Quercus solaris
talk
03:32, 30 March 2026 (UTC)
Reply
I've been wondering how to show this kind of difference but haven't seen an entry which has such information yet. So for example,
폭넓다
pongneolda
) is pronounced as
퐁넙따
pongneoptta
in North Korea for sure, prescribed in every North Korean dictionary without a counterexample. However, the
Template:ko-IPA
has no configuration to alter "SK standard", so unfortunately I have no idea how to make an edit for now. If you wonder why I don't post this to the Grease Pit, my previous topic has no useful answer up to the present, and I guess maybe someone would suggest me use the
Template:IPA
. But to me—using IPA template is no different from reinventing a wheel, where we already have a barely satisfactory template and just need some minor improvement for it. Almost forgot to say, for now, no individual template designed for North Korean pronunciation is available. But the inter-Korean pronunciation difference is largely negligible since both Koreas viewed the
Seoul dialect
as orthodox, from which the current South Korean and North Korean are developed. For similar cases, a parameter to change the above-mentioned words is good enough, though I have to admit this kind of discrepancy is indeed rare.
Maraschino Cherry
talk
01:53, 29 March 2026 (UTC)
Reply
I support modifying
Template:ko-IPA
to allow NK pronunciations (e.g. of NK-only terms) to be displayed when necessary. There was prior discussion at
Wiktionary:Beer parlour/2023/December#Removal of ko-IPA
(and that discussion has links to other, earlier discussions) but volunteer time and expertise to implement the change was lacking, so you might have to resort to using the same
{{
IPA
}}
template that most entries in most languages use for now, until someone has the time and will to create the necessary (changes to) Korean-specific infrastructure.
- -sche
(discuss)
23:04, 30 March 2026 (UTC)
Reply
Hello! There will be a
Wikimedia Café
meetup on
Saturday, 11 April 2026 at 14:00 UTC
timestamp conversion tool
), focusing on the
the 2026-2027 Wikimedia Foundation Annual Plan
. The featured guests will be
Kelsi Stine-Rowe
(senior manager,
Movement Communications
, Wikimedia Foundation), and
Sam Walton
(senior product manager,
Moderator Tools
, Wikimedia Foundation).
In addition to this Café session,
several additional meetings regarding the Annual Plan are listed on the Collaboration page
, and you may participate on the
talk page
This Café meetup will be approximately two hours long. Attendees may choose to attend only for a part. Please see the Café page for more information, including
how to register
↠Pine
05:43, 29 March 2026 (UTC)
Reply
Pinging @
Sarri.greek
to continue the discussion we've had under
Wiktionary:Requests for deletion/Others#Category:Polytonic Greek
as there seems to be no clearly established policy either way on whether and under what circumstances polytonic entries for monotonic Greek words should be allowed. My stance is that any reliably attested polytonic Greek spelling (keeping
WT:SPELL
in mind) should be admitted; my understanding of Sarri.greek's stance is that only katharevousa terms should have a modern Greek entry under their polytonic spelling. The discussion I've started under
Wiktionary:Grease pit#Polytonic Greek
contains a policy proposal as well that would be of use either way.
StrangerCoug
talk
15:07, 29 March 2026 (UTC)
Reply
I want to narrow my stance above slightly, though, to disallow spellings with grave accents, respelling them with acute accents instead (since the grave accent does not appear on words in isolation in any form of Greek).
StrangerCoug
talk
19:01, 29 March 2026 (UTC)
Reply
Thank you @
StrangerCoug
for inviting me. For
polytonic
duplications, I have given my opinion many times since 2018, as a Greek. But here is the en.wiktionary, I am not an anglophone and perhaps should not interfere. Also, I was taking a break for health reasons. Please proceed as you wish. ‑‑
Sarri.greek
22:34, 29 March 2026 (UTC)
Reply
Pinging @
Thadh
Fay Freak
, feel free to ping others who might be interested. This was
discussed
a few years ago, there was some support but ultimately nothing came out of it.
In normal usage the Ethiopic script doesn't mark consonant gemination, however, gemination is phonemic in most (if not all) languages that use the script. This makes it necessary to supply a manual transliteration in terms where a geminate consonant is present. Some dictionaries use a diacritic to mark gemination, the diacritic itself varies by work, but there's an Ethiopic-specific
◌፟
[U+135F ETHIOPIC COMBINING GEMINATION MARK] which is used in (for example)
{{
R:ti:Gugarts:2022
}}
and Leslau's Reference Grammar of Amharic.
Having geminates transliterated automatically would remove the need for many (but not all, since letters in the
-row would still be ambiguous) manual transliterations. For example, we could simplify
ምፍጻም
from
===Noun===
{{ti-noun|+
# {{verbal noun of|ti|ፈጸመ
# {{verbal noun of|ti|ተፈጸመ
to
===Noun===
{{ti-noun|ምፍጻ፟ም|m}}
# {{verbal noun of|ti|ፈጸ፟መ|t=to end, to finish}}
# {{verbal noun of|ti|ተፈጸ፟መ|t=to be over}}
Thus, I propose that we add support for gemination marks in Ethiopic headwords. This would involve:
Adding the following to
m["Ethi"]
in
Module:scripts/data
in order to get the plain pagename without diacritics. u(0x135D) and u(0x135E) are the other two Ethiopic combining diacritics, I've never encountered them but I think they shouldn't be present in pagenames either.
strip_diacritics = {remove_diacritics = u(0x135D) .. u(0x135E) .. u(0x135F)}
Adapting the transliteration module (done, see
Module:User:Santi2222/Ethi-translit/testcases
). The module assumes that non-final geminates are surrounded by vowels (so it will always keep
before and after the geminate), word-final geminates in the
-row are shown without a vowel by default.
Santi2222
talk
16:10, 29 March 2026 (UTC)
Reply
Sounds good to me!
Thadh
talk
16:40, 29 March 2026 (UTC)
Reply
I have implemented the aforementioned changes.
Santi2222
talk
18:39, 5 April 2026 (UTC)
Reply
I’ve noticed that
User:Theknightwho
has been creating a very large number of Ancient Greek entries consisting of inflected forms (verbs across multiple tenses/persons, as well as declined noun/adjective forms).
While these forms are often morphologically plausible, many appear to have been created systematically without clear evidence that they are actually attested in Ancient Greek texts.
Examples:
I’m unsure what the current consensus is on large-scale creation of inflected-form entries for Ancient Greek without explicit attestation. My understanding is that entries should be verifiable and not generated purely from morphology.
Could experienced editors clarify:
Whether this kind of mass creation is acceptable
How such entries should be handled
Whether broader cleanup or review is needed
I have not attempted large-scale reverts due to the volume.
Thanks.
Eletrr2
talk
06:20, 30 March 2026 (UTC)
Reply
We generally accept non-lemma entries for all forms of attested verbs without insisting on attestation for every single one, so long as the paradigm is known, regular and unambiguous, as is the case in, say, English, French and Latin (although in Latin we would want enough forms to be attested to be certain of what the correct paradigm is). Imagine if we insisted on attestation for every single verb form - what an utter waste of volunteer time that would be!
As for the case at hand, I admit I know little of Ancient Greek morphology - is there something to distinguish it?
This, that and the other
talk
09:22, 30 March 2026 (UTC)
Reply
I do something similar to Theknightwho for Spanish verbs, though since in most cases the missing non-lemma entries are verb forms combined with pronouns, I double-check to make sure the verb is transitive before proceeding.
StrangerCoug
talk
14:13, 30 March 2026 (UTC)
Reply
My policy is not to create entries that I have not seen, at least in a dictionary. Collecting blue links is not helpful and likely harmful. I once added a Greek hapax and somebody followed up with a declension table of a hundred or so hypothetical forms that we know are unattested. We should not do that either.
Vox Sciurorum
talk
14:30, 30 March 2026 (UTC)
Reply
In the case of hapaxes, I support not even adding a declension or conjugation table to begin with since it wouldn't be a hapax if we knew the paradigm.
StrangerCoug
talk
14:43, 30 March 2026 (UTC)
Reply
I’m generally not active as an Ancient Greek editor, but my experience as a Latin editor is consistent with yours regarding Theknightwho taking a systematic approach to adding inflected forms without checking for attestation.
In principle, entries should be attestable, but I think it is widely accepted that we don’t need to bother checking for attestations for every inflected form when a word unambiguously belongs to a class that follows regular and obvious inflection patterns, like masculine o-stem nouns in Greek or Latin. Taking the recently-added Latin name
Bogardus
as an example, every form shown in the inflection table at that page can be inferred straightforwardly from general rules, without any real doubt. So creating entries for these forms wouldn't be something I would find problematic, even if some happened not to have three attestations (unless there is some reason to think the absence or rarity of attestations of some particular form is non-accidental).
However, I think taking a systematizing, hypothetical approach can be problematic when dealing with words that have difficult/irregular/problematic inflection features. A recent example I saw in Latin is the entry for the verb
lavō
: this generally inflects as a first-conjugation verb, but has a somewhat anomalous perfect stem lāv- (instead of lavāv-). Most first-conjugation verbs, such as
amō
, have "contracted" forms that delete the -v- of the perfect suffix, such as amāstī for amāvistī. This led to the entry for
lavō
getting assigned a template that displayed forms like "lāstī", "lāt", "lāmus" since at least this
2019 edit
by @
Benwing2
's WingerBot. Then in February of this year, @
Theknightwho
created entries for such forms (
larunt
, etc.), which I
discussed here
, that recently failed RFV. If there are any comparable cases in Greek, where there are either good reasons to think the form was actually never used, or there is doubt about what the form would be, then it would be good to challenge them by requesting verification.
As a general matter, we'd ideally want to avoid both omitting genuine forms and including spurious forms. However, the process for removing/deleting entries is a bit more complicated than the one for creating them, so if there's doubt, I think it's better to not create an entry.--
Urszag
talk
23:32, 30 March 2026 (UTC)
Reply
I believe TheKnightWho uses
this site
to determine whether forms are attested or not, at least in some cases.
As for the broader issue of creating forms, I am of the opinion that if a term is formed with a well-known suffix or is a compound formed with a well-attested element, it makes sense to create the forms for it.
Vergencescattered
talk
01:15, 31 March 2026 (UTC)
Reply
Correct.
Separately, I'm a little concerned that @
Eletrr2
was even considering mass-reversion on a prject that they only have ~100 edits on, frankly, given they're evidently not familiar with how things work here, especially when they
deleted
the declension tables at
δῖος
dîos
for no clear reason.
Theknightwho
talk
09:01, 31 March 2026 (UTC)
Reply
Eletrr2
:, why did you delete the declension table? —
Justin (
ko
vf
09:09, 31 March 2026 (UTC)
Reply
I also note that all the forms of
ὦλξ
ôlx
were nominated for speedy deletion, despite me having added 6 quotations to the lemma form which cover some of them. Based on the attested forms, its paradigm is completely predictable.
Theknightwho
talk
11:02, 31 March 2026 (UTC)
Reply
To me, ὦλξ seems like a somewhat arguable case. It seems common for other dictionaries to note that only certain forms are attested. The quotations show two forms, the accusative singular ὦλκα and the accusative plural ὦλκας. All dictionaries on
Logeion
note the first, and Middle Liddell shows the second as well. Only ὦλκα shows up in the Scaife ATLAS tool that @
Vergencescattered
mentioned. For the remaining, hypothetical forms, I'm not familiar enough with Greek declension rules to be certain how unambiguous they are. For example, I'm unsure whether the accentuation of gen pl ὠλκῶν and the gen/dat dual ὠλκοῖῐ̈ν is secure: there are certain monosyllabic nouns that don't move the accent in these forms, so it seems like ὤλκων (as in παίδων, φώτων, ὤτων) and ὠλκοιῐ̈ν (as in ὤτοιῐ̈ν) would be a possible alternative. Overall, the forms seem highly but maybe not all 100% predictable, and the table at
ὦλξ
ôlx
acknowledges this with with the disclaimer that "Some forms may be based on conjecture". I think the are arguments both for and against creating pages for inflected forms in such cases: they have minimal utility as search targets (since we'd expect almost no searches for unattested forms), but they could potentially be useful as the standard place where we put pronunciation information for inflected forms. That said, the pronunciation sections in this and other cases are almost always algorithmically generated, and the reason that is possible is because the pronunciation is predictable from the spelling, so it doesn't truly add any new information for someone familiar with how to pronounce Ancient Greek. I'd view it as up to each editor's judgement.
Wiktionary:Ancient Greek entry guidelines
has no guidelines on whether/when to create entries for inflected forms, unlike e.g.
Wiktionary:Turkish entry guidelines
Getting into technical points: I do not see nominations for speedy deletion in the edit history of
ὠλκί
ōlkí
etc. Rather, it seems @
Eletrr2
edited to add rfd tags (including for
ὦλκα
ôlka
, which I think must have been a mistake). Adding rfd tags is part of the standard Request for deletion process, although the other part, the discussion, wasn't clearly linked from the tagged entries because of the technical awkwardness of making an RFD for non-lemma forms. A discussion was created at
Wiktionary:Requests_for_deletion/Others#Category:Ancient_Greek
which was presumably intended to cover these and other cases. Obviously we're all discussing it here now.--
Urszag
talk
22:12, 31 March 2026 (UTC)
Reply
What if everyone on Wiktionary, was a CheckUser?
~2026-19918-85
talk
21:14, 30 March 2026 (UTC)
Reply
"What if my beard were made of green spinach?" cried Mr. Wonka. "Bunkum and tummyrot! You’ll never get anywhere if you go about what-iffing like that."
~2026-19770-79
talk
01:10, 31 March 2026 (UTC)
Reply
"Everybody's a dreamer and everybody's a star and everybody's in movies, doesn't matter who you are." --
Ray Davies
Vox Sciurorum
talk
15:54, 31 March 2026 (UTC)
Reply
We have the
fantasy
hope that we can preserve a kind of privacy by limiting access to that info[
citation needed
].
DCDuring
talk
17:38, 31 March 2026 (UTC)
Reply
See
Vox Sciurorum
talk
20:59, 31 March 2026 (UTC)
Reply
I thought it was obvious that WMF wants to limit access to private information, but apparently not to everyone, so see:
this summary
if Vox's link doesn't satisfy.
DCDuring
talk
17:10, 1 April 2026 (UTC)
Reply
This is a non-banned alternate account of
User:Purplebackpack89
, who has been permabanned here since 1 April 2025. Both accounts are also banned on Wikipedia. Close up the hole?
~2026-19770-79
talk
01:10, 31 March 2026 (UTC)
Reply
Done
Justin (
ko
vf
01:35, 31 March 2026 (UTC)
Reply
It appears as if many of current Black Speech entries are ripped directly from an old "
Orkish-English-Russian
" dictionary that, as far as I can tell, records a ton of "Neo-Black Speech" entries
created by LOTR fans
rather than Tolkien himself. All of the "dialect" information on current Black Speech entries in particular derives from these fan-creations rather than the original texts, such as the
one particular "dialect"
that was apparently invented by and for specifically Swedish roleplayers. Also, many of these entries provide IPA transcriptions, but there doesn't appear to be any standardized system for Black Speech phonology adopted by Wiktionary, though there are apparently
fan-created attempts
at constructing Black Speech pronunciation. Are we really willing to include all of these elaborate fan-expanded forms of artistic conlangs? Do these even really count as the same conlang as Tolkien's invented languages?
Graearms
talk
02:25, 1 April 2026 (UTC)
Reply
If the entries are not attestable, then they can and should be RfVed. If we can see a pattern of users making a number of items that fail RfV (See
WT:RFVE
.), we might be willing to delete all of the items that fit some clear criteria. Violating the purity "of artistic conlangs" is not inherently against policy.
DCDuring
talk
18:54, 3 April 2026 (UTC)
Reply
list
of terms used by the
Navajo Codetalkers
, some of which are recorded on Wiktionary
here
. My question is how this information should be incorporated onto Wiktionary. The dictionary entries do not use the typical spelling system used for Navajo, so it sometimes requires some interpretation to identify which Navajo term is being referenced, and I am not sure if everyone would agree that we should record this information on the site at all.
For example, the Codetalkers' Dictionary includes the term "GA-GIH," which it glosses as 'crow' and says was code for "patrol plane." Presumably, this refers to
gáagii
. I propose adding a definition to this entry, which would look something like
Codetalking
patrol
plane
. Does anyone have thoughts on this formatting?
Finally, do we need entries for the spellings given in the Codetalkers' Dictionary? For example, should we create an entry at
JAY-SHO
, and if so, should it just be an alternative spelling of
jeeshóóʼ
, or should it be treated as a lemma unto itself?
Vergencescattered
talk
23:08, 1 April 2026 (UTC)
Reply
speaking as someone without good knowledge of Navajo, your proposal seems good. the entries should be located with in the entries with normalised spellings. the original glosses could be incorporated into the refs.
if no objections are raised, I can create the label, categories and ref template needed.
Juwan
🕊️
12:18, 5 April 2026 (UTC)
Reply
That would be amazing, thank you!
Vergencescattered
talk
22:19, 8 April 2026 (UTC)
Reply
e.g.
[2]
~2026-20486-19
talk
17:55, 3 April 2026 (UTC)
Reply
Stop following me around!!!
box16
talk
17:58, 3 April 2026 (UTC)
Reply
harangue begins
You should have been banned years ago for all of your vile and obscene language.
box16
talk
18:00, 3 April 2026 (UTC)
Reply
Why are you still here following me around every day and harassing me when you should have been banned years ago for the following behavior:
--- where you called another user a "
faggot
". You were not banned for this slur.
You wrote "
f---k off you absolute c--t and die in a fire
". You were not banned for this egregious and heinous infraction, and continue to follow me around and harass me here.
I do not appreciate the names that you have called me in the past and I will continue to call you out on this and inform the Wiktionary community regarding your disgusting behavior.
box16
talk
18:07, 3 April 2026 (UTC)
Reply
If you are making changes against policy, than someone who is reversing those changes is following policy. It may well be that following you around is the most efficient way of following policy.
DCDuring
talk
19:58, 3 April 2026 (UTC)
Reply
response and harangue/response continues
I note that on the only link you provided, the offense was in 2023. I seem to recall that you have previously unsuccessfully used this as a means of deflecting concerns about your edits. I further not that you have not provided a link for the other offense. Do you have evidence of a relatively recent offense?
DCDuring
talk
18:41, 3 April 2026 (UTC)
Reply
I do not have the link but Equinox called me some kind of slur in the past such as "twat" or "faggot" when he was an administrator. I feel very uncomfortable with him following me around everywhere I go, merely because I changed the spelling of "popularise" to "popularize".
box16
talk
18:44, 3 April 2026 (UTC)
Reply
Here's another very rude and disrespectful response you made to another user:
<< I don't care what you've done. We have a policy, formed by consensus, and you either obey it or get fixed later and/or kicked out. Do you also go to the law courts of England and Wales and say "loads of people commit mugging so I did it too, Your Honour".
You fucking clown
. Stay off RFV and RFD pages please. Equinox >>
You called another user a "
fucking clown"
and you were not banned for one minute for this vile behavior. This is totally unacceptable.
box16
talk
18:32, 3 April 2026 (UTC)
Reply
Do you have evidence that this is recent behavior?
Also, this is not a page for conducting a harangue against another user. I hope all readers realize that "you" in your posts does not refer to them.
DCDuring
talk
18:41, 3 April 2026 (UTC)
Reply
I'm sorry, but I'm still very upset by all the times that Equinox called me names and slurs when he was an adminstrator on here and was never sanctioned or banned for it.
Here is an example where the user "Koavf" calls out Equinox for this behavior:
box16
talk
18:47, 3 April 2026 (UTC)
Reply
As I stated previously, I didn't save the links where he made these statements, but I do vividly recall him making them many times. He also wrote one time in reference to another editor "this user is going to make me commit murder." That is totally unacceptable and hurts our community.
box16
talk
19:05, 3 April 2026 (UTC)
Reply
STICKS AND STONES MAY BREAK MY BONES BUT WORDS CAN NEVER HURT ME. If you're offended by any words at all, that's on you- get over it. Normal human communication includes insults, and is conducive to the growth of dictionary project. Hurt feelings are a part of life. Down with Speech Restrictions (beside any explicitly required by law).
Revolution is coming because of these insane speech limitations.
--
Geographyinitiative
talk
19:12, 3 April 2026 (UTC)
Reply
I do understand that. But remember that words also cut deep, and the tongue wounds more than a lance. Notwithstanding the priceless privilege of free speech on the Internet, there are limits and bounds to one's use and choice of language in a community which requires a sense of respect and decorum.
box16
talk
19:15, 3 April 2026 (UTC)
Reply
User:Dolpina
and
User:Wmbata
seem to have been edit-warring over various Igbo entries like
ichafu
. Third-party intervention might be useful if anyone knows Igbo.
~2026-20486-19
talk
21:08, 3 April 2026 (UTC)
Reply
Reverting once a bad faith edit and spotted canvassing that was spotted on Wikipedia main site is not edit warring, sorry. I did not violate the 3 rules. Maybe learn what the rules are first before accusations from your IP burner instead of your account. Or is this more canvassing and sockpuppetry? If the vandalism continues, the "ichafu" will get salted here too. Let a term for a scarf remain that, not
a cosplay to add another culture's traditional attire to it.
Dolpina
talk
21:29, 3 April 2026 (UTC)
Reply
Wow, why so defensive? I see you're the troll and the other guy is the good editor.
~2026-20486-19
talk
21:30, 3 April 2026 (UTC)
Reply
Here is a bit of timeline of the "ichafu" vandalism on wikipedia and sockpuppetry investigations for an admin or interested wikitionary skilled users :
Dolpina
talk
21:59, 3 April 2026 (UTC)
Reply
I’m stepping in as Wmbata to clarify a few things, as this discussion has taken a turn that doesn’t really help the dictionary. I am a native Igbo speaker and a researcher; my only interest here is making sure our entries are linguistically and etymologically accurate.
On the word itself, calling ícháfụ́ just a "scarf" is a major cultural reduction. In the Igbo language, it’s a specific compound verb cha (to wrap) plus fụ (to wind) and a noun for a very specific ceremonial headwrap. It is disappointing to see my native language and heritage labeled as "cosplay."
As a native speaker, I am sharing the lived reality and linguistic structure of my own people. To have an outsider dismiss this indigenous knowledge as "cosplay" or "bad faith" is a violation of the neutral and respectful environment Wiktionary aims to foster. I’m providing 100-year old academic sources to back up my edits, and I’d welcome any third-party Igbo linguist to review the 1913 Thomas citation I’ve provided so we can move past these personal accusations and focus on the facts.
Wmbata
talk
22:55, 3 April 2026 (UTC)
Reply
This has gotten out of hand. @
Dolpina
and @
Wmbata
: please read
our Criteria for inclusion
and
WT:NOT
. Wiktionary is a descriptive dictionary based on usage- not on reliable sources. If a term is used in a language with a specific meaning, we have an entry for it with a definition for that meaning. We're not an encyclopedia, so the focus is on words and phrases
as words and phrases
. There may be layers and layers of culture and customs associated with the things referred to, but we only document what's necessary to understand what people mean what when they use the terms for them.
I've temporarily protected the page to stop the edit war- not because I think the current version is correct, but to give things time to quiet down. Details may be changed in the meanwhile after discussion. Pinging @
AG202
as the first person I can think of who both knows Wiktionary practices and is likely to understand the issues involved. Feel free to invite others to this discussion.
Chuck Entz
talk
23:22, 3 April 2026 (UTC)
Reply
Thanks for the response. Just to clarify, nothing got out of hand that involves me, click the links I pasted to show you want is going on here and what I addressed. I'll read more on wikitionary since I'm new here, hoping in from Wikipedia. From what I know already, Wikitionary is based on definitions of words and phrases, which is what users should abide by... basically a dictionary... not an encyclopedia or self publishing paper or propaganda promotional. Hopefully the other user recognises this. That user Wmbata has also vandalised the ogiri page here... Also just to clarify too that I didnt engage in any edit warring or whatever that person went on about. I just want other eyes on what I noticed since I'm not active here. Thanks.
Dolpina
talk
00:08, 4 April 2026 (UTC)
Reply
I appreciate the Admin's goal of letting things quiet down. I want to briefly address the concerns raised by @Dolpina:
Regarding the
'vandalism'
claim on the
ogiri
and
ícháfụ́
pages: Adding verified botanical names (for
ogiri
) and historical linguistic citations (for
ícháfụ́
) is the opposite of vandalism; it is the definition of
improving
a dictionary. My goal is to ensure that Igbo terms are not defined through a Western lens (like 'scarf' or 'chiffon') but through their actual usage and structure in the Igbo language.
Wiktionary is indeed a dictionary, not an encyclopedia. However, a dictionary must be
accurate
Accuracy:
Defining
ícháfụ́
as a French loanword without a single linguistic source is exactly what 'self-publishing' or 'POV' looks like.
Usage:
In the Igbo-speaking world, this word is a compound verb and a noun for a specific headwrap.
I am happy to wait for the protection to expire. I suggest that when it does, we move forward with a version that defines the word as it is used by native speakers, supported by the historical citations I have provided, and leaves out any speculative theories about foreign origins that cannot be backed up by a source.
Wmbata
talk
08:33, 4 April 2026 (UTC)
Reply
Thank you for the clarification and for stepping in to moderate. I completely understand that Wiktionary is descriptive and focuses on how terms are used.
My concern with the current version isn't just about the history; it’s about
accuracy of usage
Definition:
In modern Igbo usage,
ícháfụ́
is not a generic 'scarf' (which we would call
akpọrọ
) or 'chiffon' (the fabric). It refers specifically to the traditional headwrap. Defining it as a 'scarf' is like defining a 'kimono' as a 'bathrobe'—it misses the actual meaning of the word in the language.
Etymology vs. Usage:
While I provided the 1906 and 1913 sources to prove the word is indigenous, my main point is that the
internal logic
of the word (
cha
fụ
) is how native speakers understand it today. It is a compound verb describing an action.
Usage as a Noun:
Currently, the page lacks a noun entry. In everyday Igbo,
ichafu
is the name of the object itself.
I would like to propose a compromise version that simply describes the word as it is used by millions of Igbo speakers: defining it as a
headwrap
and noting its
native compound origin
, without the unsourced claim of it being a French loanword. This would fulfill the 'Criteria for Inclusion' by accurately reflecting the word's function in the Igbo lexicon.
Wmbata
talk
08:31, 4 April 2026 (UTC)
Reply
I would like to bring an important development to the Administrator’s attention regarding the neutrality of this dispute.
The editor @Dolpina has now moved to Wikimedia Commons to request the deletion of the image used for ícháfụ́, claiming it is 'Gele' (a Yoruba term) and therefore the Igbo term is 'cosplay' or a 'scarf.'
This is a clear case of cultural erasure and POV-pushing.
Linguistic Fact: While 'Gele' is the Yoruba term for a headwrap, ícháfụ́ is the documented Igbo term for the same practice, as proven by the 1906 and 1913 sources I provided.
Project Neutrality: One culture’s terminology should not be used to delete another culture’s educational records. Both terms describe traditional African head tying, and both have a right to exist on Wiktionary Commons.
Usage: Defining an Igbo headwrap as a 'scarf' which in English implies a necktie or a simple winter garment is a descriptive error that ignores how millions of Igbo speakers use the word today.
I am asking the Admin to consider that these deletion requests are not based on 'Criteria for Inclusion,' but are an attempt to remove historical and visual evidence that contradicts a personal theory. I stand by the academic sources (Thomas, 1913) and the living usage of my people.
Wmbata
talk
08:44, 4 April 2026 (UTC)
Reply
Wmbata
: I've taken a look at some of your edits, and I and others are concerned about your apparent use of AI to make edits. Please
do not use AI for edits
(including references) on Wiktionary or any other Wikimedia project.
Ex:
your edit here
. I've checked
Anthropological Report on the Ibo-speaking Peoples of Nigeria
(Part II) at
this link
, and it does not have this word in it at all. It also uses <č> instead of
addenda
as well, and it does have
ičafǫ
"kerchief" on page 50, which is the closest thing. Nonetheless, it is certainly not a verb (which tracks for any basic knowledge of native Igbo morphology, since native verbs start with consonants). Please actually check the references that you cite, or you may be blocked in the future.
CC: @
Chuck Entz
, @
Surjection
AG202
talk
20:04, 4 April 2026 (UTC)
Reply
@AG202:
I want to thank you for taking the time to do deep research in the archives to support an etymology that contradicts the everyday usage of native indigenous people.
I will be honest: I have used AI to assist with my English grammar, as it is not my native language, but the
facts
of the Igbo language come from my life and my people, not a machine. You found the word
ičafǫ
in a 1913 record, but a record written by a foreigner over a century ago does not define what a word means to the people who breathe it today.
Calling
ícháfụ́
a 'scarf' or 'handkerchief' is false, no matter what a colonial archive says. In the living Igbo language, it is a headwrap. Period. The morphology of
í-
(prefix) +
chá
(spread) +
fụ́
(wrap) is how the word is understood by those who actually speak it.
Wiktionary is a dictionary of how words are
used
. If you prefer the 'dead' definitions of 1913 foreigners over the 'living' definitions of 2026 native speakers, that is your choice. I would rather be blocked for defending the truth of my culture than be 'correct' in a system that prizes old mistakes over modern reality.
For your information: this response was also polished by AI for grammar, but the heart of it is 100% mine.
Wmbata
talk
22:34, 4 April 2026 (UTC)
Reply
@AG202
I want to be very clear, I have not used AI to vandalize or delete any existing content. Regarding
ichafu
, I was the one who created the page because it was completely missing from the dictionary. Regarding
ogiri
, I did not change the Yoruba definitions; I simply added the Igbo perspective to provide a complete picture.
I admit to using AI for grammatical correction because English is not my native language. I use it as a bridge to communicate, not as a source of facts. The facts of the Igbo language come from my lived experience as a native speaker.
You are prioritizing 100-year-old records by colonial foreigners over the living, everyday usage of indigenous people. Calling ícháfụ́ a 'scarf' or 'handkerchief' is fundamentally false to an Igbo person. If you consider a 1913 British report a 'better' source than the people who actually speak the language today, that is a failure of the system to represent African cultures accurately.
I was not promoting a 'point of view'; I was providing the definition used by millions of people in Southeastern Nigeria. If my lack of 'colonial' sources is a problem, I invite you to use modern search engines to see the everyday usage and images of these words. They reflect a reality that 1913 archives cannot.
If defending the actual meaning of my language and culture is considered 'vandalism' or 'bot-like behavior,' then you may proceed with a block or better deletion. I would rather be restricted than stay silent while my culture is reduced to 'scarves' and 'handkerchiefs' by outsiders.
Wmbata
talk
22:50, 4 April 2026 (UTC)
Reply
To clarify the morphology further: ícháfụ́ is a nominalized form of a verb phrase. Depending on the dialect (such as Owerri or Ikeduru), the roots are í-chá (to spread/clear) + fụ́ (to wind/wrap), or í-chí + áfụ́.
When these verbs perform an action on the head, they merge into the single noun ícháfụ́.
Wmbata
talk
07:46, 5 April 2026 (UTC)
Reply
Wmbata
: You see, I know you're using AI to write these responses because you didn't even ping me correctly. Also the "100-year-old record" is the one
YOU
cited in the entry. I only checked it because you put it there, and you
miscited
it. I made no comment on the etymology, since I'll check that on my own later. I also never said that it's better than contemporary sources. Please do not misquote me.
I would much rather you write by yourself 100% of the time, even if it's ungrammatical English, than using AI for writing, and you're also clearly using AI for fact-checking as well. I'm almost certain that you're wrong with the etymology too.
AG202
talk
18:07, 5 April 2026 (UTC)
Reply
Thanks for the ping, I'll take a look tomorrow.
AG202
talk
19:48, 4 April 2026 (UTC)
Reply
Disciplinary update
edit
I have indeffed Wmbata for persistent and insistent abuse of LLMs to make edits and comments, even after an unambiguous warning to stop doing that. —
mello
hi!
Goodbye!
21:21, 5 April 2026 (UTC)
Reply
Mellohi!
I would like to bring to your notice and that of other Admins to please take your time and review all edits of @
Dolpina
across English Wikipedia in the Articles: "Ogiri" "Ijede" "Ogbono soup" "Akwa Ocha" "Akwete cloth" "Ichafu (headdress)" "Wrapper (clothing)" "Egusi" "Traditional marriage in Igbo culture".
I took my time to track all edits of this user and I can prove to you with these highlighted articles on the English Wikipedia (and from a neutral standpoint) an intentional vandalism and cultural eroding of a people under the guise of "improving African history."
For instance, in the article in
Ogiri
, I took my time to go through all the sources provided by this user which they used to revert previous edit and I see intentional omission of the correct information provided in some of the sources the user provided. I also notice intentional cut and join to suit their narrative and also provision of sources that are not accessible and with broken links all in the guise of reverting VANDALISM.
I therefore invite you to take your time and review these users edits across these highlighted articles and even the Wiktionary entry in discussion here.
I am also tagging members of the Igbo Wikimedians User Group to also weigh in on this discussion.
Tochiprecious
Oby Ezeilo
Akwugo
Uzoma Ozurumba
Udehb
Ceslause
King ChristLike
And some other Nigerian Wikimedians @
Vandaawalforces
as an Admin from the Nigerian community.
Lucy Iwuala
talk
03:03, 18 April 2026 (UTC)
Reply
My impression then was that Delpina was overreacting in some ways and that they should not be trusted to have the only say on the end result. Yes, Wmbata had an agenda, and was improperly using an LLM to push it. That doesn't necessarily mean that they were categorically wrong on all points. Delpina has mostly been asserting just that, and using Wmbata's misbehavior as proof.
I still don't know if the term in question has been used in running Igbo text to refer to a head wrap as opposed to a scarf. If it has, we should have a sense for it. After all, we're an uncensored descriptive dictionary based on usage. The only question is what usage notes and labels should be added to let our readers know about the context. In a case such as this, where something that is a source of pride for one culture is being claimed by a neighboring and possibly rival culture, we need to make sure that we are as open and neutral as possible.
Chuck Entz
talk
03:43, 18 April 2026 (UTC)
Reply
I feel like I (a Souther Californian native speaker) pronounce
accept
and
except
as /ækˈsɛpt/ and /ɛkˈsɛpt/ respectively, but those pronunciations are only listed as Received Pronunciation. Should they also be listed as General American as well?
McYeee
talk
01:16, 4 April 2026 (UTC)
Reply
I don't notice any difference between the two in my own speech (Encino native, almost Lake Balboa). It's a small enough difference to be easily neutralized in a prestress environment like that. I imagine that a (made-up) sentence like "there's nothing to accept except acceptance" would end up with the first vowels of the three words sounding more like schwas than either of the sounds they might have in isolation.
Chuck Entz
talk
02:19, 4 April 2026 (UTC)
Reply
Do we transcribe how the word is pronounced in the most neutralized environment, the least neutralized environment, both, or neither?
McYeee
talk
03:28, 4 April 2026 (UTC)
Reply
A phonemic transcription of the norm during typical prosody is done, representing neither poorly articulated (mumbly) speech nor emphatic enunciation that bucks the normal degree of
vowel reduction
. It's true that any accent, when saying any word that has reductions, can
crank up
the reduction in mumbly speech or
dial back
to less-than-normal reduction when emphatic enunciation is given, but then that's why there wouldn't be much value in transcribing those two poles in addition to the typical norm. The problem with distinguishing /ækˈsɛpt/ and /ɛkˈsɛpt/ in GenAm is that they aren't /ˌækˈsɛpt/ and /ˌɛkˈsɛpt/ during usual prosody, which tends to force them both to have /ək-/ or /ɪk-/. Wiktionary usually does a more realistic (face-the-facts) job with this than AHD does; AHD is a bit more notional, to the point that it sometimes ignores the reality of usual reduction, in favor of notional simplicity. All AHD gives for
accept
is "ăk-sĕpt
)", which is notional, really, rather than prosodically real.
Quercus solaris
talk
04:38, 8 April 2026 (UTC)
Reply
I admit that a good aspect of AHD's method is that it tells any reader that a
short
, not a
long
, is what belongs to the word when reduction is not obscuring it. But a disadvantage of the method is that a reader can't find out "what the word usually sounds like [in most utterances]" from it though.
Quercus solaris
talk
14:14, 8 April 2026 (UTC)
Reply
Thanks for the answer. It took me a bit to digest it, but I think I get it now.
McYeee
talk
22:55, 9 April 2026 (UTC)
Reply
I am a native
Hoosier
and in my General American accent, I pronounce these differently and something like what you've transcribed. I feel like "ak-CEPT" and "egs-ZEPT" are perfectly normal American English pronunciations for these words. —
Justin (
ko
vf
14:43, 8 April 2026 (UTC)
Reply
I'm surprised you have a voicing distinction. I don't think I've heard of that in that context.
McYeee
talk
22:51, 9 April 2026 (UTC)
Reply
Just now, I said it out loud: "I'll happily ak-CEPT the feedback, egs-ZEPT for your tone". (Your tone was fine, I just needed an excuse to use both words.) I'm actually struggling to think of what the merged pronunciation would be. Are they both ækˈsɛpt or both ɛkˈsɛpt or both something else? —
Justin (
ko
vf
23:16, 9 April 2026 (UTC)
Reply
They're both anything in the range of /əkˈsɛpt/ to /ɪkˈsɛpt/ in my accent unless one is enunciating more than normal, in which case they can be /ˌækˈsɛpt/ and /ˌɛkˈsɛpt/, differentiated respectively. It has to do with the fact that there's only a sole stress, rather than a primary and a secondary stress, unless one is enunciating more than normal. This is comparable to how when some BrE accents say
condition
they say /ˌkɒnˈdɪʃ(ə)n/ but my accent says /kənˈdɪʃ(ə)n/.
Quercus solaris
talk
04:15, 14 April 2026 (UTC)
Reply
I have sometimes heard
accept
as /ækˈsɛpt/ and/or
except
as /ɛkˈsɛpt/ from some Americans. Whether those pronunciations are best described as GenAm or as something else, I'm unsure (there is not always great agreement about what is GenAm...), but on the strength of their inclusion in (some) dictionaries I think they could be acknowledged as variants. Cambridge, Collins, Dictionary.com, Longman's, Merriam-Webster, and the Oxford Learner's Dictionary have
except
(in both the US and UK) as /ɪkˈsept/, but the OED acknowledges /ɛkˈsɛpt/ as a second pronunciation in both the US and UK. For
accept
, Merriam-Webster acknowledges /ɪkˈsɛpt/, /ækˈsɛpt/,
and
(confusingly) /ɛkˈsɛpt/ (listing /ɪkˈsɛpt/ first), Dictionary.com has /ækˈsɛpt, ɪk-/, Cambridge and Longman and Oxford Learner's have only /əkˈsɛpt/ with full reduction to schwa (for both US and UK), Collins has only /ækˈsɛpt/ and no reduced form (for the US; they have the UK pronunciation starting with a schwa); the OED has
accept
as "/əkˈsɛpt/ uhk-SEPT [or] /ækˈsɛpt/ ak-SEPT".
I haven't heard voiced /-ɡz-/ in
except
; it doesn't surprise me that some speakers have it — compare
exist
, where it is the most common pronunciation — though it doesn't seem common/standard/GenAm enough to mention (at least as GenAm).
- -sche
(discuss)
01:02, 10 April 2026 (UTC)
Reply
I mean, it should be a thing, right? WP:STRANGE is already here, and we should have a place, even if just as a joke, to share the fun parts of words, like
Fully Automated Luxury Gay Space Communism
and maybe
skibidi Ohio rizz
or
or
or all the other strange words.
AtTheTownHouse
talk
00:34, 5 April 2026 (UTC)
Reply
We have an
Anteroom of Silliness
...
This, that and the other
talk
02:45, 5 April 2026 (UTC)
Reply
oh
ok
AtTheTownHouse
talk
14:17, 5 April 2026 (UTC)
Reply
but still, why not put it into one independent room with everything else silly?
AtTheTownHouse
talk
14:19, 5 April 2026 (UTC)
Reply
It's OK to just mark for speedy deletion
Catalan
Spanish
Portuguese
, etc. passive past participle forms that were autogenerated for verbs that don't actually have them, right?
There are heaps of these, and various pages that exist only to hold them. When it is not clear whether they can be used or not, it makes sense to have a discussion: e.g.
Talk:pecar#RFV discussion: October–December 2025
Talk:peccata#RFV discussion: June–October 2025
WT:RFVI#dependido
[permalink]
WT:Tea_room/2026/February#urini
, etc.
But in most cases, at this point, it is pretty clear when those are not actually possible, and do not exist. For at least Catalan, Spanish
and Portuguese, one simply has to check whether the verb has transitive senses: if it has none, these forms do not exist because they are only used in a passive sense. (For Italian, there are some other things to consider because inflected past participles are also used whenever a reflexive is involved and with verbs taking
essere
as auxiliary, see
Talk:peccata
.)
If it is OK, I will just be marking those for speedy deletion, linking to this discussion, in the future.
Emanuele6
talk
05:49, 5 April 2026 (UTC)
Reply
We quite regularly speedily delete incorrect bot creations. At least I would do it for these cases. Ping me when you find any.
Polomo
⟨
oi!
⟩ ·
17:46, 5 April 2026 (UTC)
Reply
thinking about the consequences of
WT:NSE
, especially the following bullet point:
No individual person should be listed as a sense in any entry whose page title includes both a given name or diminutive and a family name or patronymic. For instance, Walter Elias Disney, the film producer and voice of Mickey Mouse, is not allowed a definition line at Walt Disney.
in order to make entries useful to a given reader, the entry for
Disney
should be able to mention that Walt Disney. following a principle of notability, only few individuals should be included. see the examples at English
Epstein
diff
) and Portuguese
Dilma
rev
):
Dilma
plural
Dilmas
masculine
Dilmo
masculine plural
Dilmos
a female
given name
, masculine equivalent
Dilmo
, notably borne by Brazilian politician
Dilma Rousseff
(born 1947)
similarly, the town sense already mentions Wesley E. Disney. the name templates and
{{
place
}}
should ideally allow for easier adding of eponyms. see my (very bodgy) work at
Module:sandbox/person
to see how the backend might look.
Juwan
🕊️
13:02, 5 April 2026 (UTC)
Reply
the informal tests that I have been taking into account when considering adding these is
the name is heavily associated with an individual (see
WP:RPRIMARY
at Wikipedia)
checking for if several eponyms, derived from name
Lemmings test (compare Merriam-Webster's biographical name dictionary)
Juwan
🕊️
14:24, 5 April 2026 (UTC)
Reply
to note, I am okay with this the criteria being stricter in some sort. in some offwiki discussions with Polomo, he mentioned
this RfD for "Elon" and "Musk"
(pinging @
-sche
who may be interested). the objections raised about the lemma for "Epstein" are similar to the ones for those regarding "Elon".
Juwan
🕊️
05:15, 11 April 2026 (UTC)
Reply
I think we should only include individual people as senses when the name is
almost exclusively
associated with
one particular
individual. I’m against including “Jeffrey Epstein” in the definition line at
Epstein
, because there are other people known by that name, and at that point it stops being very useful to specify. Other than the two you mentioned, the Beatles agent
w:Brian Epstein
comes to mind. I think it’s okay to have the specific names listed as collocations (i.e., examples of people with the name), though.
Polomo
⟨
oi!
⟩ ·
17:45, 5 April 2026 (UTC)
Reply
If we do decide to have them, then it should be based off of the eponyms that Wiktionary has. For
Epstein
, as an example, we could list
Jeffery Epstein
Anthony Epstein
Richard Epstein
and
Jacob Epstein
, since they have eponyms based off their (last) names in Wiktionary.
CitationsFreak
talk
18:06, 8 April 2026 (UTC)
Reply
A strict criterion could be if the given name or surname redirects to the individual by default on a relevant Wikipedia edition (probably en.WP). —
URJECTION
18:35, 8 April 2026 (UTC)
Reply
Just link the surname to the WP dab page. Let them our sister encyclopedia keep track of encyclopedic content. I think that is the status quo. The last thing we would want is to simply duplicate WP dab pages or have long "Derived terms" sections. I regret us having copious toponyms. This would be another triumph of quantity over quality and another step toward converting enwikt from a dictionary to a short-attention-span encyclopedia. A renaming would be in order: WPJr? wpjr? jrwp?
DCDuring
talk
18:51, 8 April 2026 (UTC)
Reply
Just had some edits reverted and I can't figure out what I'm supposed to do under Wiktionary's policies. I assume that I'm not supposed to revert back (although
Help:Revert
isn't very clear on how much reverting is too much and who is obliged to stop), but what then?
Help:Dispute resolution
says that if the disagreement is about 'Content, definitions, synonyms, pronunciation, etymology', I should use rfv, but that is just a request for verification of the whole entry, and in any case some disputes are about wordings rather than verification. It also says you should 'ask for help from outsiders', but it doesn't explain how you go about that.
Anonymous44
talk
06:07, 6 April 2026 (UTC)
Reply
This page
Help:Dispute resolution
is super-old and misleading. Help or input from others you get at
WT:TR
WT:ES
WT:ID
or
WT:BP
Help:Revert
being ambiguous corresponds to planned ambiguity in practice: if you introduce more rules on how to behave people argue around them instead of talking sense and thereby have even more disputes, with less productivity, and so on. Many mistakes of Wikipedia in overbureaucratization we have succeeded to avoid.
Fay Freak
talk
11:13, 8 April 2026 (UTC)
Reply
I have updated
Help:Dispute resolution
, @
Anonymous44
Fay Freak
talk
11:29, 8 April 2026 (UTC)
Reply
Thanks for the explanation.
Re the comparison with Wikipedia, I think Wiktionary's current approach is worse than Wikipedia's and results in anarchy (for example, different people using different principles in transcriptions in the pronunciation sections) and anonymous amateurs' personal opinions on historical linguistics being presented as The Truth (as seen in the etymology sections - I see that your update has now made the legitimacy of original research on this subject on Wiktionary more explicit). The reason why Wiktionary can sorta do with fewer formal rules than Wikipedia - and consequently with less arguing about them - is probably that far fewer people care about Wiktionary and edit it to begin with. A club or a village can afford to stick to informal ways where a city needs laws. But even with Wiktionary's smaller number of regular editors, some negative consequences are visible.--
Anonymous44
talk
14:43, 8 April 2026 (UTC)
Reply
Anonymous44
The reason why Wiktionary can sorta do with fewer formal rules than Wikipedia
– it is also due to the content matter and interests involved. When biographies of living people are written and the merits of
listed companies
are presented you figure fast how paramount sourcing is.
From the perspective maintained by this site’s main contributors, with its content matter and primary-source matter, the contributions themselves generally give themselves off in how professional someone is in the field. It is as in open-source programming where you can't object to a contributor not being professional enough: if their work is judged fair by the professional principles.
Your point about different presentations of the transcriptions and pronunciation sections is fastidious. Negative consequences of that are barely discernible and you could conclude that, given there are apparently loose principles, you can be relaxed in adding that content. Where different transcriptions exist, even one and the same person, not only different people, can apply different principles: my transcribing
Classical Syriac
varied to that respect according to probably mood, while Arabic varies not at all because it is so automated, but if a community arises that desires a unified look it can be botted in the desired direction.
Fay Freak
talk
16:07, 8 April 2026 (UTC)
Reply
Re
From the perspective maintained by this site’s main contributors ... the contributions themselves generally give themselves off in how professional someone is in the field
- give themselves off in whose assessment, though? In the assessment of the site's contributors. And who is to vouch for the competence of the site's contributors to assess that? Nobody but themselves. This boils down to 'We're right, because
we
say so'. The original 'truth by consensus' that Colbert falsely ascribed to Wikipedia. Or 'truth determined by a small club'.
Re transcription - this isn't serious. It's a fundamental principle of reference works, and of scholarly works in general, that the same system and principles for things like transcription are to be followed throughout them, because otherwise people might get the impression that the difference is in the facts and not in the form chosen, which results in disinformation. In other words, you don't transcribe the same sound or phenomenon in different ways in different entries, because otherwise people might think that they are different sounds or phenomena. Lemmas also need to be presented in the same way in order to make entries maximally comparable. That's the reason why Wiktionary does generally give quite a few rules for the form of entries - contrary to the principle that you proclaimed - although there doesn't seem to be enough of a culture of observing and maintaining them when it comes to the pronunciation section of English entries (which is what I primarily had in mind). The fact that there is chaos doesn't prove that chaos is good. The idea that it's OK to transcribe differently according to what 'mood' you are in is ... exotic, to put it mildly. Re
negative consequences of that are barely discernible
- you can say that about almost anything in Wiktionary, since inaccurate information in it generally won't sink a ship or start a world war, but if you set about to do something, including giving lexicographical information, you should do it properly.--
Anonymous44
talk
18:37, 8 April 2026 (UTC)
Reply
Anonymous44
: It’s just wrong that it is inaccurate when it is inconsistent. Your impression can only be a conclusion from comparison – a fallacious conclusion, hence it never befell me. The individual entry and transcription scheme is scholarly if it satisfies scholarly standards, here in particular excelling by being unambiguous and avoiding digraphs or vulgar transcriptions (I think about the
Arabic chat alphabet
, for instance) that would be the opposite because they are so easy to input. But it won’t make a difference when the same sound is once
and later
(we switched in Arabic from the former to the latter, with residues, and not for all other Semitic languages I am so sure about the consequences, but nobody likes to make decisions about presenting languages he does not know well). And in collaborative scholarly works the writing style is also different. I wouldn’t even notice when the citation style across multiple pieces in the same journal issue differs. Sounds like
bikeshedding
on the side of lectors. And
allistic
field dependence
problem, I don’t have this attachment where one constantly needs to signal ingroup and outgroup by a uniformity-enforcing dance ritual like job applications are read (you are out if you are weird), it’s not what science or the academic pursuit per se is!
At the same time, peer reviewers don't know much about contributors professionalities either – perhaps we even fare better than academia (at spotting mistakes) by being aware what the other editor uses to be good at. There is another paralogism you try to commit by presenting it so that people assess themselves but actually they are reviewed by each other. Now it would be different on a one-editor wiki – but my point was about the accessibility of the subject matter of languages causing better or more immediate verifiability and falsifiability than the original findings in other fields. The main question, about the monitoring of which you are concerned, is what editors can know and wherefrom: the room for manoeuvre in the field of language description is of a limited kind and therefore it works thus simply.
Fay Freak
talk
19:47, 8 April 2026 (UTC)
Reply
If you transcribe the same sound (as in the case of
and later
) in different ways, the reader who is not an expert has no way of knowing that it is the same sound (unless you just list both versions in a table and say entries may contain either, which would definitely look unprofessional). Similarly, if you transcribe Received Pronunciation sometimes with the assumption that words like
far
and
bar
have an underlying rhotic and sometimes with the assumption that they don't, people will assume that, say,
far
and
bar
have different rhymes. An expert will just realise the inconsistency in these cases, but a reference work isn't written only for experts, and sometimes such inconsistency can confuse an expert as well, because the same symbol can mean different things in different systems. People can be reviewed by each other, but if two incompetent people review each other, the result won't be a competent assessment. Peer reviewers are
known
to be experts - there lies the difference. Re 'I wouldn’t even notice when the citation style across multiple pieces in the same journal issue differs' - citation style is one thing - although yes, a unitary format
is
imposed in a journal - but you
would
notice if the entries in a dictionary or encyclopedia use formatting schemes and especially different transcriptions for the same things. It's true that being systematic is not 'what science or the academic pursuit is' - it's just one minimal prerequisite for them. --
Anonymous44
talk
20:26, 8 April 2026 (UTC)
Reply
a reference work isn't written only for experts
– but reference works are mostly not written for total beginners. There are lots which you can barely use at all when you are not trained in the field. Well there might be different proficiency levels targeted as the audience, but dictionaries always require some acquaintance with the grammar to be usable. In more
analytic
languages like English this is not immediately obvious, though at the same time (typical) Chinese dictionaries due to the writing system must be learned to use. The Arabic and Hebrew dictionaries contain lots of cryptic statements for those to whom the language is foreign in the sense that they have not learnt anything about it at all yet.
Here again you miss the fact that regular contributors show their competence in and in particular knowing the grammars of individual languages and language groups (though this is muddle by AI). For peer reviewers in linguistics the opposite is the case; you know they passed some exams (which is also muddled by AI, and ghost-writing), though probably not those of being interpreters in various particular languages they review treatises about: academic linguistics teachers sometimes brag about not needing to know foreign languages for their sciences—which leaves a lot on the table.
Fay Freak
talk
11:54, 9 April 2026 (UTC)
Reply
If there is a way to avoid unnecessary difficulty, such as by transcribing the same sound the same way in the same language, then it would be good to use it. No need to make things
more
difficult than they actually are.
CitationsFreak
talk
22:22, 9 April 2026 (UTC)
Reply
See recent edits at
anticat
antibear
anticity
antianimal
~2026-22133-15
talk
16:42, 10 April 2026 (UTC)
Reply
I support the reversions.
Ultimateria
talk
19:12, 15 April 2026 (UTC)
Reply
Would it be acceptable to transcribe Lingua Ignota and other old conlangs into the website. I understand there are far too many to simply accept any of them, so I suggets narrowing it down to ones either A) notable on Wikipedia and made before the internet, and/ or B) ones that have/ had multiple fluent speakers.
Starbeam2
talk
14:21, 11 April 2026 (UTC)
Reply
If one believes that most of the the language's fundamental terms can survive
attestation
(one quote showing usage), then I see no reason to oppose adding such language. However, I'm unfamiliar with the technical process of adding a language to Wiktionary.
TranqyPoo
✏️
22:28, 11 April 2026 (UTC)
Reply
Per the current policy at
Criteria for inclusion
, words in conlangs other than Esperanto, Ido, Interlingua, and Volapük are not allowed in the main namespace, but can be listed in the Appendix namespace. See
Category:Lojban language
and
Appendix:Sindarin
as different examples of how this can be done.--
Urszag
talk
23:00, 11 April 2026 (UTC)
Reply
by the criteria above, unsure whether Lingua Ignota qualifies for full appendix entries, since the language is only attested in a single known work, according to Wikipedia. the best course of action for it specifically would be transcribing the work on Wikisouce if available and making a single appendix page with a vocabulary list.
Juwan
🕊️
07:18, 12 April 2026 (UTC)
Reply
That works for me. I think that might also apply to the remainder of other pre-modern conlangs.
Starbeam2
talk
17:45, 15 April 2026 (UTC)
Reply
Fenakhay
Vininn126
the
{{
etymon
}}
template currently doesn't have any option for explicitly showing surface derivations (akin to
{{
surf
}}
) in text and tree etymologies. what is the rationale here to distinguish it from
afeq
, and could this be changed in the future?
Juwan
🕊️
07:31, 12 April 2026 (UTC)
Reply
Already there
:surf
. —
Fenakhay
حيطي
مساهماتي
07:35, 12 April 2026 (UTC)
Reply
oh! that's nice to know. please do update the documentation page to include it.
Juwan
🕊️
07:38, 12 April 2026 (UTC)
Reply
Oh, good to know this has been added. Does it support things like non-affixal derivations like deverbal?
Vininn126
talk
07:54, 12 April 2026 (UTC)
Reply
throwing out an idea to be discussed: for aiding searching, we could have automatic redirects from the language codes to the appropriate language pages.
on the server, there was some informal support from other editors (pinging @
TranqyPoo
Vininn126
Juwan
🕊️
07:36, 12 April 2026 (UTC)
Reply
Would be convenient.
Vininn126
talk
07:54, 12 April 2026 (UTC)
Reply
Support
:Would be convenient, I always need to Google those.
Chihunglu83
talk
10:37, 12 April 2026 (UTC)
Reply
Oppose
on technical grounds - this would be a maintenance nightmare. —
URJECTION
12:42, 12 April 2026 (UTC)
Reply
I support the idea. However, if it is too cumbersome to implement technically, then the juice isn't worth the squeeze.
TranqyPoo
✏️
15:04, 12 April 2026 (UTC)
Reply
User:Recycled1
was perma-blocked by
User:Surjection
in Oct 2023 for "abusing multiple accounts/block evasion". I believe this user is the same as
User:Mysteryroom
, now known as
User:Box16
. The activity dates seem to align pretty well, and note the very characteristic obsessive habit of changing "the 1980 film TITLE" to "the film TITLE (1980)", as here:
[3]
~2026-22516-53
talk
08:10, 12 April 2026 (UTC)
Reply
Why are you still following me around and harassing me nonstop over a purely stylistic preference? I have repeatedly stated in a previous post I am not "recycled1". I have no idea who that is. I have only used one account here on Wiktionary You have been following me around and harassing me, and trying to get me banned when it is you that should be banned for using the most vile language and insults towards other editors in the past, which I have documented here copiously. You have repeatedly failed to apologize or at the minimum, acknowledge your foul language and insults. And for the record, since you're Equinox, and now using multiple anonymous IP (sock puppets) it is you that should be banned for abusing multiple accounts due to your horrendous behavior in the past.
box16
talk
08:19, 12 April 2026 (UTC)
Reply
In defence ox Boxy, c'mon guys - the user is an entry-creating machine! In his attack, they are obsessed with being "harassed"
Vealhurl
talk
20:50, 13 April 2026 (UTC)
Reply
Yes, that they are the same user is kind of an open secret. I don't even know what they were banned for originally (Surjection once told me "long story"). In any case, there hasn't been any ban-worthy behaviour lately so it doesn't seem like anyone cares. Happy editing!
Ioaxxere
talk
04:51, 14 April 2026 (UTC)
Reply
Boxy my beloved you need to do a better job hiding that you're an alt
~2026-23024-52
talk
16:47, 14 April 2026 (UTC)
Reply
Nobody cares bro
Hftf
talk
18:38, 14 April 2026 (UTC)
Reply
What is the way in Wiktionary to express major words that exist on a continuum? Specifically, I would like to see a list that includes the most common words expressing a range of temperatures:
without the noise of the extensive list seen at
Category:en:Temperature
. I'm thinking coordinate terms, but that would require duplicating the list on each of those pages. (Also, not sure about scorching being the most common term for that end of the temperature range; it's likely context-dependent.)
Is this a job for
Wiktionary:Thesaurus
? I see
Thesaurus:temperature
exists, but it conflates lukewarm with warm. Maybe I just need to edit that page.
Thisisnotatest
talk
23:58, 12 April 2026 (UTC)
Reply
I've just edited
Thesaurus:temperature
but open to hearing other thoughts.
Thisisnotatest
talk
00:21, 13 April 2026 (UTC)
Reply
I made a similar proposal with a much worse example a few years ago. I think your example is fairly strong, but there's still some ambiguity and interpretation in this: is "freezing" colder than "cold" or is it just a kind of "cold"? I think the only way that we can really represent these is on an entry-by-entry basis using various coordinate term templates. I'm entirely open to these kind of spectrum words and a way to represent and interlink them. —
Justin (
ko
vf
03:18, 13 April 2026 (UTC)
Reply
I support these lines of thought (above). It is pretty simple to put a template inside the
{{
cot
}}
template. A good example off the top of my head is to click through to
A-shaped
, and thence to any other letter's counterpart. Such navigation is fun because the Related terms for each one can be quickly visited during a single mental session.
Quercus solaris
talk
04:00, 14 April 2026 (UTC)
Reply
Hi everyone! I'm curious about how Wiktionary handles regional vocabulary differences, specifically regarding carbonated soft drinks. In different parts of the English-speaking world, people use different terms like "pop", "soda", "coke" (as a generic term), "fizzy drink", etc.
My question is: How does Wiktionary determine which regional usage notes to include for entries like
pop
and
soda
? Are there specific criteria for documenting regional variations, and are there any ongoing discussions about standardizing how these geographic distinctions are presented across entries?
I'd appreciate any insights into how these decisions are made. Thanks!
~2026-22723-80
talk
17:09, 13 April 2026 (UTC)
Reply
This is a famously complicated and niche example, so for these kinds of usage varieties that are not easily explained, a usage note is common. Generally, usage notes are mildly discouraged and the content in them should be brief and clear, but they are occasionally necessary, since it's not possible to always convert something so complicated into a label with
{{
lb
}}
. See
Wiktionary:Entry_layout#Usage_notes
. —
Justin (
ko
vf
17:23, 13 April 2026 (UTC)
Reply
The most comprehensive source for US regional usage differences is the 6-volume
Dictionary of American Regional English
(1985-2013), now also in a digital edition ($49/yr. for individuals, but many institutions subscribe). I don't know how or whether it is currently being updated. Soft-drink names are also covered in many language/linguistics and general-interest books because they are a set of good, accessible examples or regional differences. (See
tonic
cold drink
soda-pop
soda pop
sodapop
dope
for others, which may or may not have good definition or be properly labeled.)
DCDuring
talk
17:34, 13 April 2026 (UTC)
Reply
What are we supposed to present? The gold standard is to hotlink a dialectological map right in the usage note, as seen in
Eierfrucht
Lauch
, or
Berliner
. It was only our affinity to texts rather than graphics which traversed their proliferation.
Fay Freak
talk
20:24, 13 April 2026 (UTC)
Reply
Another entry with a map:
tea
. —
Justin (
ko
vf
20:51, 13 April 2026 (UTC)
Reply
map is
here
now.
Soap
00:34, 20 April 2026 (UTC)
Reply
(Notifying
Agamemenon
Apisite
BigDom
GabeMoore
Insaneguy1083
Helrasincke
Hippietrail
RichardW57
Sławobóg
):
Anatolijs_LTV
AstrOtuba
Dijacz
JimiYoru
Juliusmborris
MerlinMDV
Muonium777
Nitori43
Solvyn
エリック・キィ
(Please let me know if I missed anyone, and apologies if you prefer not to be pinged!)
Hello everyone,
With the aim of offering a more standardized approach to Lithuanian pronunciations, I have put together a module that automatically generates pronunciations based on spelling and stress patterns. The new template and its backend are now ready for review:
The technical details, usage instructions, and comprehensive testcases are all fully documented on the respective template and module pages, so I won't clutter this post with all the details. Currently, the module successfully handles the vast majority of cases, and I have already done some small-scale manual deployments to verify its stability.
I would like to deploy this template across all applicable Lithuanian entries to standardize our coverage. Because this will affect a significant number of pages (approximately 30,000 entries), I am bringing this here to seek community consensus.
If there are no major objections to the module's logic or the deployment plan in the coming days, I will formally submit a request to grant the bot flag to my
bot account
to carry out these automated changes.
I would greatly appreciate it if editors familiar with Lithuanian or automated pronunciation modules could take a look at the outputs and let me know if any final adjustments are needed before we proceed.
Thank you!
TongcyDai
talk
16:19, 14 April 2026 (UTC)
Reply
Looks fine overall, I just question whether the 1 or 2 (I assume that's a tonal thing) need to be included in the rhyming template.
Dijacz
talk
16:23, 14 April 2026 (UTC)
Reply
Dijacz
I wasn't entirely certain about splitting them myself, but my initial thought was that the tonal distinctions on heavy syllables (tvirtaprãdė 1 vs. tvirtagãlė 2) might be somewhat analogous to vowel length—since they sound distinct and can even form minimal pairs with completely different meanings (e.g.,
áukštas
[¹ˈɑˑʊkʃtɐs]
"tall" vs.
aũkštas
[²ˈɒʊˑkʃtɐs]
"storey"), they perhaps ought to be treated as different rhymes. That said, I'm completely open to adjusting this; if the consensus is that tone doesn't strictly dictate rhyme in Lithuanian, or if keeping them separate makes the categories too fragmented, I'd be more than happy to remove the numbers and merge them!
TongcyDai
talk
18:23, 14 April 2026 (UTC)
Reply
I have created our first dialectal equivalent map for English which can be found here:
Template:dialect map/en/pencil crayon
. I'm curious to know what you guys think and whether we should make more for other highly regional words (soda/pop/coke). I would also like discuss what consistutes proper sourcing for these dialect maps. For some English-speaking regions we have access to detailed surveys, while for others we can only go off vague anecdotal evidence.
Ioaxxere
talk
18:51, 14 April 2026 (UTC)
Reply
This is beautiful, thank you. I think that these are very valuable and having more would be hi-value to the dictionary. I think it's best if we use some kind of data, even if it's a decent-sized web survey (e.g. I recall that
xkcd
had one about color names), because the nature of these things will encourage crankery and crackpottery. Looking forward to us having one for soda/pop. —
Justin (
ko
vf
18:57, 14 April 2026 (UTC)
Reply
This is awesome. Definitely a useful addition to the dictionary and much more helpful for displaying regional variation than usage labels. I really appreciate the inclusion of varieties of English beyond North America and the UK, as well as the level of detail (it's easy to read visually, without implying that there is a just one term in use in the UK or the US).
Andrew Sheedy
talk
20:39, 14 April 2026 (UTC)
Reply
For reference, it is
{{
dialect synonyms
}}
, where also documentation can be found, that the map information is in a subpage of
Module:dialect synonyms
. This not easy to find given that a page like
Template:dialect map/en/soft drink
transcludes
{{
dialect map
}}
which invokes
Module:dialect map
. Some documentation, if only links to the main explanations, should be added to
{{
dialect map
}}
which invokes
Module:dialect map
There should be a place to dump references an editor found and found not easy to find: would be a shame if one has them at hand but still doesn't add them because embarrassed about the placement. Maybe with noinclude on a page such as
Template:dialect map/en/pencil crayon
; or better, in addition to “view map”, a page such as
pencil crayon
linking a map should have “view references” when available. This can be partially primary data, of course, if we have quotes as evidence, but in the important cases other surveyors did the work.
Fay Freak
talk
11:25, 15 April 2026 (UTC)
Reply
You can (and should) leave references. E.g. see
Template:dialect_map/es/pavo
. Thanks for starting the soft drink one. —
Justin (
ko
vf
13:43, 15 April 2026 (UTC)
Reply
I would go further than requiring references. I think the
caption
should have a date (range) for when the data was collected and, in broad terms, how it was collected, eg, web survey, non-web convenience sample, interviews, etc. Some footnoted data is much worse than other footnoted data. Forcing our users to wade through the references (which they are unlikely to do) to find out the basics undermines the quality of the Wiktionary experience as much as shoddy, unsupported definitions.
DCDuring
talk
15:17, 15 April 2026 (UTC)
Reply
Is there any way to have smaller dialect regions? for example,
tanbark
is used only in the San Fransisco Bay Area to refer to
woodchips
, I'm sure there has got to be other examples of this
BirchTainer
talk
05:07, 19 April 2026 (UTC)
Reply
Is there any realistic possibility for pulling such data together for a group of synonyms such as for
plane ticket
(most common per NGrams)?:
Synonyms:
plane ticket
airline ticket
air ticket
flight ticket
airplane ticket
DCDuring
talk
15:41, 15 April 2026 (UTC)
Reply
Thanks, this looks good! I've had a go at a
Template:dialect map/en/bread roll
. A couple of observations:
It's not easy to find the list of accepted varieties. There's regional variation within Scotland, Wales and Ireland, for instance, but I couldn't find an accepted variety for Aberdeen/Aberdeenshire or for North and South Wales.
The West Midlands doesn't render on the map. I wonder if the parser is getting stuck on West Midlands (region) vs West Midlands (ceremonial county). In this case, the ceremonial county would be the correct one.
I worry about the granularity of the data - I wanted to add other countries, but for the US for example, the question of bread roll names has never been surveyed AFAICT. Sources online say everyone says
bread roll
or
dinner roll
(except maybe
weck
in Buffalo? I don't know how specific that name is), but if I fill out every single state that way, am I vouching that Arkansas DEFINITELY doesn't have its own weird local word? We should tend towards high-level national or regional labels (Midwestern US, Southern US) rather than individual states or counties except where we really do have the granular data.
Anyway, thank you again!
Smurrayinchester
talk
09:14, 16 April 2026 (UTC)
Reply
(I've fixed the problem with the West Midlands, and added North and South Wales. I still think there should be higher-level regions (for the US, perhaps: Northeast, West, Midwest, South, Southwest; for England, perhaps: North, Midlands, South, West Country) and unless we have really granular data, these should be preferred to individual states/counties)
Smurrayinchester
talk
09:18, 17 April 2026 (UTC)
Reply
Not sure what to do about this:
profess
JMGN
talk
00:49, 15 April 2026 (UTC)
Reply
Wait, it's now everywhere!?
JMGN
talk
00:52, 15 April 2026 (UTC)
Reply
It was template vandalism, so it propagated widely. It's now fixed. —
Justin (
ko
vf
09:54, 15 April 2026 (UTC)
Reply
Can someone please block this vandal account? Thanks.
Ikuzaf
talk
00:53, 15 April 2026 (UTC)
Reply
Coming here to second this. User is active right now - may also be worth restricting the editing rights for important templates (like the ones this user is editing) but I'm not sure if that's a separate discussion
Actually
Never
Happened02
a place to chalk
a list of stuff i've done
00:56, 15 April 2026 (UTC)
Reply
update - account blocked
Actually
Never
Happened02
a place to chalk
a list of stuff i've done
00:57, 15 April 2026 (UTC)
Reply
I've gone ahead already and revamped the Ainu entries with IPA pronunciation to follow the
{{
ain-pron
}}
template. This was to standardize the rendering of Ainu pronunciations so they could follow on if the template was updated in future. Now I'm planning to standardize the dual kana-Latin spellings for those pages. I'm wondering, would it be good business to use the small ㇽ as a catch-all transcription for the coda /ɾ/-phoneme as in
sir
(land) and
kar
(to do)?
The tradition is to delegate each kana based on the vowel that comes before it, so that
sir
would be シㇼ (sir
) and
kar
would be カㇻ (kar
). By my proposal I would render these two words as シㇽ (sir
) and カㇽ (kar
) while compromising with adding the vowel-based japanizations as alternative forms.
I compare this with the way Japanese uses ル with the silent vowel in transliteration of loanwords (like バレーボール "volleyball" and アルバイト "part-time work"). I also compare this with the way my indigenous language Māori uses long vowels to mimick the British pronunciation for loanwords with a coda R (
motokā
"motorcar" and
mita
"meter").
I do this because I find the practice of representing the same coda sound with all five of the R-row kana confusing and rather redundant. I contrast this with Persian having four letters to represent the /z/-phoneme; three of them represent Arabic phonemes that Persian doesn't have and it's much more complicated. And on a personal note, the above practice feels disgustingly Japonic to me, considering these two cultures' sordid historical relations.
Pohewatanga
talk
10:45, 16 April 2026 (UTC)
Reply
Can you clarify if the method you're describing has any significant prior use, or if you're proposing a new standard to replace the existing convention for writing Ainu in kana? It doesn't seem like a good idea to me to change the spelling just because you find the existing conventions a bit more complicated than they need to be.
Regarding switching pronunciations to the ain-IPA template, in theory that should be a good thing, but one thing to be careful of is to not remove information in the process (assuming the prior pronunciation is accurate). For example, was the old pronunciation [ʔájꜜnù mò̞ꜛɕír] at
aynumosir
wrong? I see that you removed the second accent (on the final syllable), replacing it with [ʔáj.nu.mo.ʃiɾ] in the current version of the page.--
Urszag
talk
15:26, 16 April 2026 (UTC)
Reply
In response to your first point: This was indeed a proposal to replace the existing conventions, but I realize now that upsetting a whole spelling system based solely on my own convictions is rather bad practice after all. But I will say that I got the idea from the Japanese Wiktionary, which features both the vowel-based シㇼ spelling and the consonant-based シㇽ spelling for R-coda words in Ainu entries. This is codified in lines 78-82 of the
ja:ain-kana-conv
template. Really, I think that the phonology of Ainu is better written out in the Latin script anyway.
In response to your second point: I deleted the second accent because
aynumosir
I treat in that entry as one word with the stress falling on the first syllable, because the first syllable ends in a coda /j/. Ainu phonological rules dictate that the first syllable is stressed if it ends in a coda, otherwise the second syllable is stressed. (This is demonstrated ably with
áynu
and
mosír
as separate words.) My reference is Tamura Suzuko (2000); Chapter 3: Phonology, in
The Ainu Dictionary
, translated from
Ainu-go
, published by Sanseido.
I compare with
síssimoye / sírsimoye
(earthquake), which has the same number of syllables but only a stress attested on the first syllable in that entry's dialect table. (Except for
sicímoe
, where the first and second syllables do not have codas, so the stress is on the second syllable.)
Nítnekamuy
(demon) features
kamúy
(in which the second syllable features a coda /j/), but the first syllable ends in a coda /t/ so I put the stress there.
Pohewatanga
talk
22:38, 16 April 2026 (UTC)
Reply
Is there a reason why the Appendix font size is unchangeable and set to
small
? It completely dismisses accessibility for our readers and editors, specifically for Appendix-only languages, like Toki Pona & Lojban.
TranqyPoo
✏️
03:20, 17 April 2026 (UTC)
Reply
TranqyPoo
: That presupposes that both statements are true. I see absolutely nothing of the sort. It's true that, as an admin for the past 14 years, I don't really see things the same as other users do. However, I copied the url of a Lojban Appendix entry and pasted it into the address bar of a browser that I've never used to log in to Wiktionary. It looks basically the same, though there's a reason I disable the most recent Vector skin in every Wikimedia site I visit.
At any rate, that tells me that your experience is most likely due to either a) the browser skin you use. b) a gadget you have installed, or c) some custom .js or .css files on your system.
I would recommend starting a topic at the Grease Pit and asking for help from someone with Interface Administrator rights. It will speed things up if you go through your user settings and see what gadgets you have enabled so you can answer questions about them.
Chuck Entz
talk
03:52, 17 April 2026 (UTC)
Reply
This is some server-side configuration issue and should be raised at
Phabricator
. —
URJECTION
11:09, 17 April 2026 (UTC)
Reply
The developers insist we go through
the full procedure
to allow this. So I'm starting this subthread for a poll to gather consensus to enable the font size to be changed in the Appendix namespace (namespace 100) on en.wikt. —
URJECTION
16:39, 17 April 2026 (UTC)
Reply
Support
URJECTION
16:39, 17 April 2026 (UTC)
Reply
Strong support
. Very strange that this would require consensus. Thank you, @
Surjection
, for spearheading this change!
TranqyPoo
✏️
17:42, 17 April 2026 (UTC)
Reply
WTF? I cannot imagine why this "font size lock" exists. Very peculiar that the developers implemented this anti-feature without asking anyone but now require consensus to get rid of it. So here's my
Support
for doing so immediately.
Ioaxxere
talk
17:59, 17 April 2026 (UTC)
Reply
It's because they excluded all namespaces with ID 100 by default. Their reasoning was flimsy, but I doubt anyone will be able to convince them how that was a bad idea. —
URJECTION
18:09, 17 April 2026 (UTC)
Reply
Support
. Ridiculous that stuff like this can be changed by devs without even a hint of discussion with actual editors of wikis.
Thadh
talk
08:56, 18 April 2026 (UTC)
Reply
Consensus for other pages
edit
I found a few other places where this font size lock is in effect:
Let's see if we can keep the current default font size, while giving the user to change the font option, as is available everywhere else.
Ioaxxere
talk
19:44, 17 April 2026 (UTC)
Reply
Support
as proposer including any pages I may have missed.
Ioaxxere
talk
19:44, 17 April 2026 (UTC)
Reply
I think the special pages (including history and info) are intentionally/technically restricted to small font size. —
URJECTION
21:37, 17 April 2026 (UTC)
Reply
While Artificial Intelligence can be very useful, it can also produce utter nonsense that's very hard to spot. When used to compose text, it adds lots of unnecessary verbiage
I've seen LLM text described as "gossip": gossip is full of "they say" and "I heard". It also can easily be contaminated with lies from people with ulterior motives and with unfounded speculation. Some people just make stuff up to have something to talk about.
In the same way, AI takes information from who knows where without assessing the reliability of the sources. It then combines it according to some unknown algorithm and synthesizes it into authoritative-sounding statements of fact.
It's important to remember the influence of marketing in all this: LLM AI providers are under extreme pressure to promote their services, so they have a vested interest in making the AI seem knowledgeable and authoritative, and in underplaying any shortcomings in their data or its interpretation. There's a distinct lack of "I don't know", I'm not sure, and "I guess".
Problems:
Lack of attribution
Lack of critical thinking about sources
Filling in the blanks/hallucinations
Indiscriminate mixing of relevant and irrelevant information
So, should we avoid using AI tools altogether? As someone who uses Google Translate quite a bit, I wouldn't say that:
If you haven't got a clue, AI can give you exactly that- a clue. If you have
no
idea, it can give you
an
idea. Just don't trust either. Use what the AI tells you to do your own research, and if you've already done some research, use the AI to help understand what you've found- without taking it completely at its word.
Note: This is partly in response to an inquiry at the Information desk a a while back. It's not as complete or concise as I'd like, but this month has been rather hard for me IRL, so I decided to go with what I have. Better to not
let the perfect be the enemy of the good
Chuck Entz
talk
06:15, 17 April 2026 (UTC)
Reply
Watch this, replace the word "AI" with the word "Wikipedia", and return yourself to the year 2003:
My take on Wikipedia (2003)
While Wikipedia can be very useful, it can also produce utter nonsense that's very hard to spot.
I've seen Wikipedia described as "gossip": gossip is full of "they say" and "I heard". It also can easily be contaminated with lies from people with ulterior motives and with unfounded speculation. Some people just make stuff up to have something to talk about.
In the same way, Wikipedia takes information from who knows where without assessing the reliability of the sources.
Problems:
Lack of attribution
Lack of critical thinking about sources
Filling in the blanks/hallucinations
Indiscriminate mixing of relevant and irrelevant information
So, should we avoid using Wikipedia altogether? As someone who uses Wikipedia quite a bit, I wouldn't say that:
If you haven't got a clue, Wikipedia can give you exactly that- a clue. If you have
no
idea, it can give you
an
idea. Just don't trust either. Use what the Wikipedia tells you to do your own research, and if you've already done some research, use Wikipedia to help understand what you've found- without taking it completely at its word. --
Geographyinitiative
talk
07:35, 17 April 2026 (UTC)
Reply
I don't see the point, since a) we don't allow other wikis as sources, b) Wikipedia requires references showing reliable sources behind the information given, which is a glaring omission from AI, c) copying wording from Wikipedia without attribution would be a violation of the Creative Commons licenses for both projects, d) Wikipedia has revision histories establishing the authorship of every detail, while AI is just a
black box
Chuck Entz
talk
18:11, 17 April 2026 (UTC)
Reply
I've found AI (Gemini) very helpful for answers to narrow questions of fact, eg, gender of taxa. OTOH, when I asked it to make a historical railroad route map for me, it produced an antiquey map that didn't even put towns and topography in proper relative location. (WP actually had what I wanted, but Gemini didn't use it.) It would be interesting to experiment with asking it to come up with definitions for expressions used in various citations. I would expect it to get better at it over time, but we and others like us would be teaching it, for the benefit of Google.
DCDuring
talk
19:46, 17 April 2026 (UTC)
Reply
IMHO
, self-nominations shouldn't trigger votes for user rights, as they may be used for
self-promotion
, e.g. the one in
Wiktionary:Votes/sy-2026-03/User:M Ali Kara for admin
. Forbidding or at least limiting self-nominations would also prevent this type of vote from lacking a reason, such as the aforementioned one, as the nominator has to analyze the user's suitableness for the right in question and create a case for it to convince the community into voting for it.
Even if they aren't self-promoting, self-nominations are still highly biased, so I believe it's better for users to apply for user rights by, for example, contacting an admin or bureaucrat.
Davi6596
talk
15:48, 17 April 2026 (UTC)
Reply
I support this, at least for administrator rights. I'm not opposed to applying this also to the higher roles past administrator, though. —
URJECTION
16:24, 17 April 2026 (UTC)
Reply
Oppose
. Endorsement by another admin increases the likelihood of success and confidence from other voters, but it should not absolutely be required. In the unlikely event the administrative community of Wiktionary becomes dormant or tyrannous, self-nominations would allow the editing community to
elect
. Additionally, this assumes that voters do not do their due diligence for determining whether someone is worthy of adminship. In other words, if a self-nominee is voted in as an admin, it would be because the editing community has done their research. The referenced vote adds credence that voters do not blindly cast their votes.
TranqyPoo
✏️
17:38, 17 April 2026 (UTC)
Reply
I don't think there should be an absolute prohibition, but it should be made very clear- if it isn't already- that it's almost always a bad idea. Something like: "self-nomination is generally frowned upon and unlikely to succeed. If self-nomination is absolutely necessary, please include an explanation of the extraordinary circumstances requiring it."
Chuck Entz
talk
17:56, 17 April 2026 (UTC)
Reply
I agree to this. It would dissuade those who just want to
shoot their shot
while not prohibiting such attempt.
TranqyPoo
✏️
21:23, 17 April 2026 (UTC)
Reply
This seems fine to me.
Davi6596
talk
23:52, 17 April 2026 (UTC)
Reply
I have never really understood the Wiktionary community's dislike of self-nominations. Surely if you've worked out you're fit to be an admin, you might as well nominate yourself rather than wait for someone else to notice. (By the time you're ready to be an admin, there's a good chance that people might think you're already one!) Arguments around bias make no sense - votes are votes, people can make up their own minds.
This, that and the other
talk
23:06, 17 April 2026 (UTC)
Reply
~2026-19565-13
I have tried mentoring on their talk page but they must have not seen it. They have recently made some edits to
dehīscō
where translations they provided are not relevantly cut to match the new quotes they added (granted the translation used is quite free). They also hyperlink each and every word in a citation and will add (very) long ids to the
{{
ety
}}
template for some reaon and ids where otherwise not needed. Tell-tale might be the false etymology they gave to
hiātiō
They are productive to a degree that makes me quite scared, I hope they can see this.
Saumache
talk
16:41, 17 April 2026 (UTC)
Reply
I've given them a 1-day mainspace block to get their attention. I'll remove it as soon as there's any indication they got the message. I hope this works- if they're through editing for the week, they may not even know they're blocked.
Chuck Entz
talk
17:45, 17 April 2026 (UTC)
Reply
There are too many pages that incorrectly spell phonetic representation
[ ]
as phonemic representation
/ /
for some German words.
The example page is as follows:
Äthan
Landsbergerin
Fuchsberger
YeBoy371
talk
03:43, 18 April 2026 (UTC)
Reply
YeBoy371
: I'm not sure exactly what you mean, since the examples you give are spelled with [] rather than //. I can only guess that you mean the exact opposite of what you seem to have said, and that these are phonemic examples that should be spelled with //, but are instead spelled with [].
The problem is that a living language is too complicated to be completely and accurately represented with either notation if you take them strictly. The same person may pronounce the same thing differently enough to show up differently in a strictly phonetic notation depending on whom they're speaking to, where they're speaking, and just random chance. On the other hand, there are many potential levels of phonological abstraction, and the broadest ones leave out details that would help our readers know how to pronounce things. Any notation is necessarily a compromise, and you would have to discuss it with our German editor community to understand the choices made. Pinging @
Mahagaja
, who knows more about this than I do.
Chuck Entz
talk
04:19, 18 April 2026 (UTC)
Reply
Indeed, all of those should be written with slashes. The thing is that German Wiktionary always uses square brackets in their pronunciation sections, even though the transcription used is quite broad, so that habit often gets transferred over here. —
Mahāgaja
talk
09:16, 18 April 2026 (UTC)
Reply
I would like to clarify that my understanding is correct and that this is not classed as rendaku (and instead usually reflects preservation of an older /p/ phoneme). I ask because it seems based on
this search
that up to 240 entries categorize it as such, and I would like to double check before setting out to correct those.
Horse Battery
talk
15:56, 18 April 2026 (UTC)
Reply
The romanized word
rendaku
is from the Japanese spelling
連濁
rendaku
, literally something like "sequential + muddy, muddying", where "muddy" here refers to a voiced consonant, as opposed to a "crisper" or "clearer" unvoiced consonant. See also
濁音
dakuon
, literally "muddy sound" and referring to a voiced consonant, contrasting with
清音
seion
as a "clear/clean sound", i.e. an unvoiced consonant.
Since the
shift can occur regardless of sequence, and since it has nothing to do with adding one's voice to an otherwise-unvoiced consonant, then by definition, this cannot be
rendaku
I still don't know what this shift is called officially / linguistically in English. I
posed a question about this
a while back over at the Japanese Stack Exchange, and no one had any leads on the official English-language label for this phenomenon, suggesting the accurate-but-cumbersome "bilabialization-plosivization". In Japanese, folks floated
半濁音化
han-dakuon-ka
, but I don't find this in references. I do find
半濁音
han-dakuon
, literally "half sequential-voicing". Sequential voicing for the
sounds in Japanese involves both a bilabialization and a voicing, so this "half" prefix seems to refer to the first half of this shift (the bilabialization) while omitting the second half (the voicing).
Although this involves adding the lips to the articulation of the sound, this is not what's discussed at
w:Labialization
, so we shouldn't try to call it that. I also don't find anything at either
bilabialization
or
w:Bilabialization
Curious what others think. ‑‑
Eiríkr Útlendi
Tala við mig
19:18, 20 April 2026 (UTC)
Reply
Hmm. If we need a term to use in etymologies, could we not just use a general term like "change", e.g. say ɲ̟ip̚põ̞ŋko̞kɯ̟ is from ɲ̟ihõ̞ŋko̞kɯ̟ with a (regular, or phonemic, or common, or whatever adjective might be applicable, if one is needed) "change" of /h/ to /p/? Or if we need a term in order to have a category for words with this change, could it just be "Japanese terms with change of /h/ to /p/", or "Japanese terms with plosivization of /h/ to /p/"? (There's a paper about
Coronal palatalization in Logoori
which you can find if you search Google Scholar for "h plosivization", which calls a change of /h/ to /b/ by that name. While "plosivization" can, as that shows, refer to other changes than just the change of /h/ to /p/, ... is that a problem here? Are there cases where /h/ changes to /b/, or /k/, etc, that we are trying to distinguish /h/→/p/ from? Or can we get away with using a general term?)
- -sche
(discuss)
19:52, 20 April 2026 (UTC)
Reply
My question wasn't really to know how to describe it or what category to add it to, just what it isn't. Since I think we've established that these are
not
examples of
rendaku
, are there any objections to removing these terms from
Category:Japanese terms with rendaku
For my opinion on how to handle these, perhaps we could have a category like "Japanese terms with
半濁音化
handakuon-ka
" or "Japanese terms with h>p" and then just clarify in the category page that these terms represent preservation of a historical /p/ phoneme, or are formations based on analogy to historal processes (e.g. emphatic /h/>/pp/, historical /p/>/pp/).
Horse Battery
talk
21:13, 20 April 2026 (UTC)
Reply
Re: @
Horse Battery
and removing instances of this specific
/h/
/p/
shift from
Category:Japanese terms with rendaku
, I absolutely support this.
Re: @
-sche
and what this phenomenon is, as @
Horse Battery
mentions, Old Japanese had a
/p/
phone that gradually lenited, becoming
/ɸ/
in certain contexts by at least the
Heain period
and then leniting further to become the modern
/h/
. Some time in (I think) the 1300s, when this was still
/ɸ/
, the
/p/
was re-introduced as a contrastively significant phone, probably due to influence from borrowings from Chinese.
In that historical context, the
濁音
dakuon
or "muddy" or "voiced" version of this phone had already become established as
/b/
back when the "clear" or "unvoiced" version was still
/p/
. That correlation is pretty clear, and even though the
/p/
became
/ɸ/
, the idea that
/b/
was a "voiced"
/ɸ/
persisted. But the
/ɸ/
/p/
correlation was less clear, once that
/p/
was reintroduced. So some writers appear to consider this a shift from
/ɸ/
or modern
/h/
to a
/p/
, whereas others seem to view it as a reversion of
/h/
or
/ɸ/
to the "original" phonetic value of
/p/
. At any rate, the Japanese terminology looks like it's settled on
半濁音
handakuon
literally “half-muddy sound”, the voiceless bilabial plosive
for the
/p/
sound itself, and
半濁音化
handakuon-ka
“half-muddy-sound-ification”, maybe “voiceless-bilabial-plosive-ization”? 😄
for the
/h/
/p/
change.
So this is a synchronic three-way cluster of contrasting phones
/h/
/b/
, and
/p/
, whereas pretty much every other Japanese initial consonant only has a two-way contrast, between the unvoiced and the voiced (ignoring for the moment the finer details of palatalization depending on the following vowel). There are no cases where
/h/
changes to any other consonant value, synchronically speaking. Diachronically, this phone also became
/w/
in certain contexts, but only diachronically, and words with this sound in the modern language spell them with the
/w/
kana
wa
. The synchronic shifts are spelled using diacritics on the
/h/
kana -- 〃 to mark voicing, and ゜ to mark ... whatever we want to call this
/h/
/p/
change. Compare
ha
ba
pa
Anyway, I hope that helps provide some background and I didn't just muddy things up (ha!). ‑‑
Eiríkr Útlendi
Tala við mig
23:36, 22 April 2026 (UTC)
Reply
Can anyone find a PDF of the first edition of Thomas Hobbes' English translation of
De Cive
entitled
Philosophical Rudiments Concerning Government and Society
(1651) online? I have looked at Google Books, the HathiTrust Digital Library, and the Internet Archive to no avail. I can hardly believe that such a well-known work has not been digitized. —
Sgconlaw
talk
19:04, 18 April 2026 (UTC)
Reply
I have PDFs of the 1984 Oxford University Press edition and the 1978 Humanities Press/Harvester Press edition and can excise any non-free content. Do you have a preference? Also, did you post this to
s:en:Wikisource:Scan Lab
? Ping me and let me know which PDF to edit/upload. —
Justin (
ko
vf
19:10, 18 April 2026 (UTC)
Reply
Koavf
: that's kind, but I was seeking a copy of the original 1651 version. There are numerous later republications of the text online (including the 19th-century version published in volume II of
{{
RQ:Hobbes English Works
}}
), but where possible we should try to use the first edition. Still find it hard to believe a digitized copy of that version isn't readily available. —
Sgconlaw
talk
19:15, 18 April 2026 (UTC)
Reply
I will post to the Scan Lab. —
Justin (
ko
vf
19:46, 18 April 2026 (UTC)
Reply
[4]
. BTW, questions like this can be answered by AI.
Vahag
talk
19:48, 18 April 2026 (UTC)
Reply
Vahagn Petrosyan
: oh, excellent! Thanks. (Somehow it never occurs to me to do that. I guess I'm rather old-school.) —
Sgconlaw
talk
20:50, 18 April 2026 (UTC)
Reply
Can someone check
this IP
's mathematics related edits? I have no knowledge in this field but I do know they have some trouble telling derived from related terms apart.
Saumache
talk
16:45, 19 April 2026 (UTC)
Reply
No, this doesn’t need a “guy” and this user isn’t any IP nor IPA nor plural. What trouble do you mean? Most pages confuse derived and related.
~2026-23921-56
talk
17:07, 19 April 2026 (UTC)
Reply
We use "IP" to refer to users that have not taken the time to create an account, thus having no username; "they" is regularly used in English in referring to an unknown person, especially to one whose sex is unknown. Yours is no defence against what I said about some, or some parts (again, I'm a stranger to this field), of your edits.
Saumache
talk
18:19, 19 April 2026 (UTC)
Reply
I know the habits of some so there was no need to tell me. My IP is HTTPS, the same as yours. My IP address isn’t used in the account name as Wikimedia no longer use that. Pronouns in general don’t refer to a person’s sex as one’s anatomy is unknown but to gender. If you don’t know mine, you may call me a who. For me to need to defend my edits you need to establish what about them is wrong.
~2026-23921-56
talk
23:16, 19 April 2026 (UTC)
Reply
After looking at your reversions they are nothing but vandalism. At first maybe your problem was that I put multiply derived lemmas under a derived lemma, but the glossary entry for derived doesn’t enforce a direction. But you actually put related terms like blends that aren’t inflections of the stem back under derived and derived terms back under related.
~2026-23921-56
talk
00:10, 20 April 2026 (UTC)
Reply
I noticed I had put "sex" for "gender" as soon as I posted this, my bad... I don't how you wanted me to use relative pronouns to refer to you btw ("it is someone who"?), I've never seen someone hurt by the use of singular "they" here, a pronoun boasting of at least as old an history as singular you.
I'm suspicious of new users adding lots of "nyms" (synonyms, meronyms, etc.), given the technical field involved, I preferred checking with someone who could vouch for the legitimacy of your additions, rather than false claims may slip unnoticed (a very common occurance). A
derived term
is a term that derives (by affixation, back-formation, metanalysis or whatnot) from the lemma of the current entry you are working on, blends are derived terms, others that may appear like so by "
surface analysis
" are not (e.g.,
dissipation
): note
how I'm not the only one concerned
What I should have first said is that you add "nyms" headers rather than following the now common practice of adding them (when feasible, that is, when a synonym or else does not cover each sense rather than one, or two) inline, using
{{
syn
}}
{{
ant
}}
, etc.
Saumache
talk
07:41, 20 April 2026 (UTC)
Reply
I had a quick scan, starting with the earliest.
ergodic
- edit to the definition is OK I think. Of the antonyms, only
nonergodic
is definitely correct (in general, it's unlikely for a technical term to have more than one exact antonym for a given sense!). I don't think entropic systems are always nonergodic or vice versa -
this article
for instance seems to treat entropy as a subset of ergodicity. I certainly wouldn't call them exact antonyms.
degenerate
is too broad to be an antonym of ergodic - I can see that some nonergodic systems could be called "degenerate", but not all nonergodic systems are degenerate (I don't know whether some simple ergodic systems - a perfect orbit, for instance - could be considered degenerate. No obvious examples of contrasting
ergodic
and
degenerate
appeared on Googling). The addition of the "co-ordinate terms" header is incorrect as I understand it - the terms listed there are derived terms.
degenerate
injective
one-to-one
as an antonym seems correct in specific cases in set theory, but not as an antonym for the extremely broad mathematical sense we currently have. You could not say "A circle with radius zero is degenerate, but circles with positive radius are injective".
frustrated
- This whole edit seems straight-forwardly incorrect. For a start,
frustrating
is not derived from
frustrated
but from
frustrate
anergic
- seems fine.
anergy
- I think this is correct.
recurrence
- mostly fine, but
recurrency
is not an alternative form of
recurrence
, even if they are effectively synonyms (they aren't perfectly substitutable, and
recurrency
has the suffix
-y
, making it etymologically distinct beyond just spelling). I don't understand why
reoccurance
was deleted as a synonym. Most of the derived terms were derived from
recur
, not
recurrence
. The coordinate terms should be derived terms - they are adjectives, and certainly cannot be coordinate with a noun!
dissipate
- Wrong but understandable. I can see why you'd think
dissipation
derived from
dissipate
, but both terms are borrowed into English from Latin - the
-ation
suffix wasn't added in English. On Wiktionary, we'd consider these as related terms that appear derived by
surface analysis
There is some useful stuff here, but I think the IP needs to check
Wiktionary:Semantic relations
to make sure they are using the right heading, and ensure that the antonyms correspond to the (generally broad) senses that we actually have, not just to specific sub-cases of them. Of course, adding more (verifiable) senses is welcome!
Smurrayinchester
talk
08:45, 20 April 2026 (UTC)
Reply
Smurrayinchester
Could you go through their edits and my reverts and make changes as needed? I would greatly appreciate.
Saumache
talk
14:49, 21 April 2026 (UTC)
Reply
Had a little run through. Not exhaustive, I admit, but I saved a few "non-X" type antonyms.
Smurrayinchester
talk
07:36, 24 April 2026 (UTC)
Reply
Certain nouns whose last sound is a voiceless fricative switch it to a voiced fricative before the plural and plural possessive endings. The ending is then pronounced /z/. The change is shown in spelling in the case of f—v (
wives
), but not for θ—ð , s—z (
mouths
).
Therefore, can such irregular pronunciations somehow be added in the entry of the singular noun? Such as the following:
Noun
mouth
(plural
mouths
/maʊðz/)
Oherwise, it's highly unlikely for users to check the entry of its plural "just in case" the pronunciation varies...
JMGN
talk
20:39, 19 April 2026 (UTC)
Reply
Maybe we could but there are exceptions to the standard RP pluralisation here, such as the Cockney ‘maafs’ being plural of ‘maaf’. Not to mention that saying ‘paadhs’ instead of the more phonetic ‘paths’ as the plural of ʽpathʼ (and for that matter saying ‘path’ as ‘pahth’) is only really an Southern English thing.
Overlordnat1
talk
22:28, 19 April 2026 (UTC)
Reply
FWIW, the pronunciation is /mʌʊðz/ for me. But I think this is more of a Beer Parlour discussion, because it has wider ranging implications than just this entry.
Andrew Sheedy
talk
23:11, 19 April 2026 (UTC)
Reply
Andrew Sheedy
Please, move it to the Beer Parlor if you know how to.
JMGN
talk
23:13, 19 April 2026 (UTC)
Reply
Discussion moved from
Tea Room
JMGN
Done
Andrew Sheedy
talk
23:23, 19 April 2026 (UTC)
Reply
There's another source of English plurals that are only irregular in pronunciation. Some American speakers pronounce the plurals of some loanwords from Spanish with and unvoiced /s/. For example, "tacos" may be either /ˈtɑ.koʊz/ or /ˈtɑ.koʊs/.
McYeee
talk
04:40, 20 April 2026 (UTC)
Reply
Another example is
antipode
/ˈæn.tɪ.poʊd/, which sounds nothing like the plural it was back formed from:
antipodes
/ænˈtɪp.əˌdiz/.
McYeee
talk
04:58, 20 April 2026 (UTC)
Reply
I've noticed that in recent years the traditional pronunciation of
houses
/ˈhaʊzɪz/
is being increasingly replaced by
/ˈhaʊsɪz/
. —
Mahāgaja
talk
11:18, 20 April 2026 (UTC)
Reply
I agree that irregular pronunciation of plurals has to be noted at the entry for the singular. As JMGN notes users would not likely check the plural. I'm sure that users are unlikely to learn a pronunciation of a plural from a dictionary, but they might. It doesn't seem too likely that they would notice the existence of an irregular plural pronunciation in the singular entry either, but the odds seem better. This would apply, in principle, to all irregular pronunciations of inflected forms of English words, possibly extending to MWEs.
DCDuring
talk
14:09, 20 April 2026 (UTC)
Reply
DCDuring
I think the addition of Usage Notes is not the appropriate solution though...
JMGN
talk
14:37, 20 April 2026 (UTC)
Reply
FWIW, in my lect,
/maʊðz/
is the third-person singular present tense of the verb, contrasting with
/maʊθs/
as the plural of the noun. I grew up along the US eastern seaboard, for context. ‑‑
Eiríkr Útlendi
Tala við mig
18:56, 20 April 2026 (UTC)
Reply
This is also the case for me. I'm from Southern California. That said, there are certainly speakers for whom this is not the case.
McYeee
talk
19:10, 20 April 2026 (UTC)
Reply
In principle
, I like the idea of indicating the pronunciations of plurals on the singular (lemma) entries for English, because English words almost always have only one plural form, so it's easy to provide that one little extra piece of information in the same place as the other information. (Obviously, more highly inflected languages like Latin are in a different boat.)
However,
if we were to do that, (1) we would run into the edge cases, words that have a
lot
of plurals with a
lot
of different pronunciations in different accents, and the pronunciation sections of those entries would be very large, and (2) we would need to
not
indicate the pronunciation on the entries for the plurals themselves, or if we try to systematically have pronunciation information
in two places for 479,000 (so, in fact, 958,000) entries
, things will
definitely
fall out of sync, and we'll have situations where
mouth
says
mouths
is pronounced /maʊðz/ but
mouths
says it can be either /maʊðz/ or /maʊθs/ (or something, because people only update one entry and not the other) and readers will be confused, and (3) we would still need pronunciation sections on entries like
mouths
to provide the verb form's pronunciation (unless we're moving that too to the lemma), and it seems like people are likely to see that pronunciation section
mouths#Pronunciation
and be tempted to add the noun form's pronunciation to it, so it seems like a maintenance nightmare to try to keep the pronunciation info for the noun out of
mouths
(but also a maintenance nightmare to try to have it in
mouths
if we're also trying to have it in
mouth
and keep the two synced) ... so,
on a practical, pragmatic level
, I think the current system whereby each entry houses its own pronunciation (only) may be best.
- -sche
(discuss)
19:24, 20 April 2026 (UTC)
Reply
I agree that full duplication of multiple irregular plural pronunciations would not be desirable. I envisaged the plural-at-lemma to be only a single common irregular current form with some kind of "see also" to the plural for anything else. IMO, that "see also" would serve if there were multiple non-current or less-than-common irregular current pronunciations in addition to the regular plural pronunciation.
Maintenance is a problem for all sorts of things. The WP solution may be forced on us for all sorts of things.
DCDuring
talk
21:08, 20 April 2026 (UTC)
Reply
According to
this search
, there are 394 pages that have a "Paronyms" header.
They seem to have been added by six people:
June, 2015:
categorially
, March, 2020
walk of shame
by
User:JackPotte
From the end of December, 2015 through to March, 2016, in Ido entries (
WT:Ido entry guidelines
), by
User:Algentem
18 pages:
-uyo
ante
avan
debar
devar
eskadro
eskadrono
esquado
genro
humuro
importar
negra
noktar
papero
papiro
sioro
tra
trans
From February, 2016 through to March, 2017 in Romanian entries (
WT:Romanian entry guidelines
), by
User:Robbie SWE
14 pages:
aceră
botgros
botroș
canale
carpo-
eider
farmacolog
farmacologă
flamingo
meteorolog
meteorologă
metrolog
metrologă
traductor
September, 2019:
judaïté
by
User:Hans-Friedrich Tamke
From December, 2020 through to the end of October, 2024 in French, English, Latin, and a few other languages by
User:Olybrius
(hundreds of pages)
January, 2026
Puqi
pushy
pussy
by
User:Geographyinitiative
Aside from not being an allowed header in
WT:EL
, I sincerely doubt that it means anything to the vast majority of our readers. To make things worse, there are a couple of different meanings mentioned in
the Glossary
- so it's entirely possible to look it up there and still not be really sure what it means.
From the sorts of terms included it looks like it was meant as an assortment of near-homonyms- they "Sorta-Sound-Like" the entry name.
Which all comes down to the obvious question: what should we do with these? Allowing anyone to use different section headers without discussing it anywhere onwiki seems like a very bad idea. I have no idea whether the header is used on other wiktionaries, but it shouldn't matter.
Do we:
Just remove them? Most of these are rather subjective and provide little useful information.
Convert them to an accepted header such as "See also"?
Merge them with existing headers?
A combination of the previous 2 options, depending on whether an appropriate header already exists in an entry?
Chuck Entz
talk
03:28, 20 April 2026 (UTC)
Reply
Is
patronym
a paronym of
paronym
? Or is
paranym
a paronym of
paronym
? Or is that one just a homophone? Is
homophone
a hyponym of
paronym
? Or is it just a co-hyponym? So many questions... By the way, I'm voting
keep
. That wasn't one of your four options, but whatever. I don't think the paronym section is more subjective than the see also one. But yes, I agree that there should have been some discussion beforehand.
Tc14Hd (aka Marc)
talk
09:36, 20 April 2026 (UTC)
Reply
Even though it's definitely not the only section that isn't mentioned in
WT:EL
. "Statistics" and "Gallery" come to mind.
Tc14Hd (aka Marc)
talk
10:08, 20 April 2026 (UTC)
Reply
We should definitely not allow "
paronym
" because it is an ambiguous term. —
URJECTION
14:54, 20 April 2026 (UTC)
Reply
Most (maybe all, I didnt check) of Robbie's Romanian entries are cognates and could be moved to a
Related terms
header. I think
judaïté
likewise. The two English entries by JackPotte could fit under either that or
See also
. Perhaps the Ido items merit inclusion just because it is Ido, a language that's intended to be as straightforward as possible and avoid confusion. The
pushy Puqi poochie pussy
thing seems more like wordplay than something learners will actually confused. And I didnt check Olybrius.
Soap
15:23, 20 April 2026 (UTC)
Reply
I think
Puxi
and
pushy
are really close, hence I tried to document it somehow. The others are less convincing. Maybe it would be under See also, and then write (paronym). Note that I tried to invlude documentation that people were confusing certain terms in the edit summary (I think). Or just delete it, it's just me exploring how I can show a link I see.
Geographyinitiative
talk
15:36, 20 April 2026 (UTC)
Reply
Other language communities or their language educations work with this term more commonly. I randomly picked a physical Russian
словарь
пароним
ов
at some point, though it turned out to have no point for me, like most individual books, that won't be read. Yet the header seems redundant to “related terms” on Wiktionary?
Fay Freak
talk
21:00, 20 April 2026 (UTC)
Reply
I say remove them. They seem pretty useless to me. —
Caoimhin ceallach
talk
23:29, 20 April 2026 (UTC)
Reply
Hello, I would like to add to the debate the fact that this header exists in some other language Wiktionaries. That's why for example Olybrius and I naturally used it, like on
the French one
(TLDR: they are a kind of related terms which can be confounded, because their
Levenshtein distance
is short). This use case is why I would vote to make it legit.
JackPotte
talk
08:25, 22 April 2026 (UTC)
Reply
I don't have a strong personal preference about keeping or removing the
Paronyms
header — I'm fine with whatever solution the community ultimately agrees on. --
Robbie SWE
talk
18:40, 22 April 2026 (UTC)
Reply
Following up on
this revert
, @
J3133
: For some reason, the description for how to close votes at
Wiktionary:Votes/Timeline
still tells us to mark votes that are closed when "the number of supports is approximately between 40% or 50%
(disputed)
and 66.6% (or higher)" as "no consensus", even though in
Wiktionary:Votes/2019-03/Defining a supermajority for passing votes
, we codified the "no consensus" result as explicitly between 50% & 66.66%, as seen in
WT:Voting policy
It seems that the 40% number is a holdover from when "no consensus" results were more fluid, but did not receive an update with the new policy. This has led to some discrepancies with certain votes saying "failed" on their pages, while listing "no consensus" on the timeline page, such as with
Wiktionary:Votes/2025-02/Deletion of "Tennis player test"
. I propose that we just list what the actual vote result is for any vote after April 19, 2019. CC: @
-sche
AG202
talk
05:16, 20 April 2026 (UTC)
Reply
AG202
: I was not aware the note was contradicting the voting policy, hence I support the change. Other “failed” votes with “no consensus” are
Wiktionary:Votes/bc-2024-12/A few users for debureaucratization
and
Wiktionary:Votes/2025-02/Retiring the English verb conjugation table
J3133
talk
05:34, 20 April 2026 (UTC)
Reply
Support
. If a vote has no majority support, it failed.
Davi6596
talk
14:14, 21 April 2026 (UTC)
Reply
The ill-conceived "German Low German" (nds-de) has been merged back into "Low German" (nds). All former nds-de entries have been added to a category "German Low German" and provided with a tag with the same text. All of this is very good and has my full support. May I just suggest that the display text of the tag be changed simply to "
Germany
". This would be shorter, less awkward-sounding, more in line with our general practice, and entirely unambiguous.
~2026-22405-75
talk
04:52, 21 April 2026 (UTC)
Reply
I don't really believe these are separate enough to warrant different thesauruses, if this is kept at least move
Thesaurus:git
to a different title, as an American I've never heard this word before, and I think some other word or phrase would be better.
BirchTainer
talk
23:11, 21 April 2026 (UTC)
Reply
American here: seems reasonable to me. —
Justin (
ko
vf
23:51, 21 April 2026 (UTC)
Reply
I have not heard the word
milksop
before, maybe this is British slang? I think another word or phrase would be better, please put suggestions if you have an idea.
BirchTainer
talk
23:14, 21 April 2026 (UTC)
Reply
Probably wimp? Weakling? —
Justin (
ko
vf
23:52, 21 April 2026 (UTC)
Reply
Wimp
is okay.
Weakling
suggests physical lack of strength which is different.
~2026-24622-84
talk
14:17, 22 April 2026 (UTC)
Reply
I agree that wimp might be the best title
BirchTainer
talk
19:47, 22 April 2026 (UTC)
Reply
After a couple of Reddit users posted screenshots of the page, confused about the image that is included, this entry has gotten new attention. Lately, ogged-in editors have removed or hidden the image: @
Tyrui
Inpacod2
Quercus solaris
I understand that removing the image is objectively against policy, seeing as
WT:IMAGE
states that
While Wiktionary is not censored, it is recommended to avoid primarily offensive images, such as those involving offensive matters, unless its inclusion would make the entry more informative, relevant or accurate.
— and it’s hard to argue an image depicting the thing itself does not make the entry more informative. Considering the image is decidedly not unethical and that it is not particularly sexual in its portrayal of the characters, despite them being naked.
Regarding the "offensiveness" of the image and the possibility of adding a content warning: I understand that having the image hidden behind a click is also in violation of policy, particularly
WT:NOTCENSORED
and
w:WP:NOTCENSORED
(which
WT:IMAGE
links to). These pages say, respectively, that
Wiktionary is not censored (nor is it content-rated)
and that
Attempting to ensure that articles and images will be acceptable to all readers, or will adhere to general social or religious norms, is incompatible with the purposes of an encyclopedia.
— censorship does not have to mean the complete removal of content, as it can also involve hiding it in a different way... to bring a couple of references from music, I recall John Lennon and Yoko Ono’s
w:Two Virgins
and Gal Costa’s
w:Índia
had to be sold wrapped in brown paper due to censorship regarding the album covers.
We must consider that Wikipedia’s primary
reason to forbid content warnings
and
disclaimers
is that it has a general
w:WP:Content disclaimer
linked to under all pages, which already covers the potential for offensive material.
And
we do too
Notably, it is only a soft redirect to the Wikipedia page. I feel that it would be better if we copied the content from the Wikipedia disclaimer into that page, possibly with adaptations. If there is agreement on this, I will draft something in my userspace and likely propose a vote. Even currently, though, I understand there is already a bunch of policy against removing or hiding this type of image.
CC: @
Juwan
-sche
Polomo
⟨
oi!
⟩ ·
14:15, 22 April 2026 (UTC)
Reply
Support
. as the writer of the image policy, we need not any censors.
Juwan
🕊️
14:21, 22 April 2026 (UTC)
Reply
there was a tea room post a few days ago
~2026-24653-17
talk
14:24, 22 April 2026 (UTC)
Reply
further discussions
Juwan
🕊️
14:28, 22 April 2026 (UTC)
Reply
Annoying that the one other person directly involved in the debate is not made aware of a discussion regarding their own actions. For completeness, I invite these people to consider the policy and precedent I brought up above: @
Fay Freak
Vininn126
Eirikr
Horse Battery
Polomo
⟨
oi!
⟩ ·
17:41, 22 April 2026 (UTC)
Reply
Support
a local page and I also
Support
us using our best judgement about if an entry
really
needs to have some kind of pornographic or violent or otherwise explicit imagery. I also
Support
any implementation of "click to see image" tool in principle, which would require a lot more discussion about implementation. In the case of this particular entry, I could plausibly imagine a scenario where there is art that has someone wearing skimpy clothing that shows an outline of the relevant anatomy without it being nude and that could be perfectly sufficient. —
Justin (
ko
vf
14:31, 22 April 2026 (UTC)
Reply
in what world would a covered bulge be as informative as an anatomical illustration? plus with the comment by Polomo below, would this also not be wished to be censored too? it is not explicit but still questionable (using booru terms).
Juwan
🕊️
13:42, 23 April 2026 (UTC)
Reply
I support click-hiding NSFW images to avoid discouraging use of Wiktionary in work environments. I would be interested as well in avoiding discouragement of use by children, eg, by parents and educators blocking access to enwikt on grounds of the unsuitability of the images. I think we need to
think of the children
(def. 2), no matter how childless our contributors may be. Technical means of suppressing appropriately tagged images entirely might be desirable.
I wish there were a consensus on simple objective criteria for discriminate among images, but as US Supreme Court Justice
Potter Stewart
famously said of pornography, "I know it when I see it.". I wonder when someone will offer an online product to assess the acceptability of images in this regard.
DCDuring
talk
15:41, 22 April 2026 (UTC)
Reply
Why do you propose Wiktionary should handle this any differently from Wikipedia? Also @
Koavf
. The key thing is that what is "objectionable" or not is entirely subjective. Knowing it when you see it is subjective. And there are definitely people I wouldn’t want censoring a wiki project based on what they subjectively find.
As I see it, any decision to remove an image from a page needs to have consensus determining that it is more objectionable than informative (clearly not the case for
futanari
IMO). And I find that adding any type of disclaimer to the project is completely inviable. Various instances of policy are already against it, and so is precedent by our older brother Wikipedia. Unless you know something the Wikipedians don’t.
Polomo
⟨
oi!
⟩ ·
16:53, 22 April 2026 (UTC)
Reply
Writing that it's "entirely subjective" is something like naive or just hopelessly bad faith. We all know that certain kinds of media are much more likely to be objectionable than others and even if we disagree and there are edge cases, it's not some free-for-all where you could say, "Well maybe someone is offended by pictures of teapots!". If we're afraid of wading into subjective territory, then we should just shut down the entire dictionary, because language usage is entirely subjective. I'm also not suggesting censorship to the extent of actively removing material that someone could plausibly use for educational purposes in our scope: I'm saying that a "click-to-see" is the mildest possible barrier and in no way stops someone from learning. I also think it's silly to think that we need a discussion for all removal of images: why would we treat images differently than text or audio or video or 3-D models or anything else? There's nothing special about JPEGs that requires elevated consensus. —
Justin (
ko
vf
16:57, 22 April 2026 (UTC)
Reply
Well, sure, someone can be bold and remove an image, and someone can revert them and add the image back; this naturally requires a discussion to determine whether the image is in violation of the policy described at
WT:IMAGE
. Have you read the reasons presented against disclaimers at
w:Wikipedia:Perennial proposals § Content warnings
and
w:Wikipedia:No disclaimers
? And, just for context, do you think the images included at
w:Vulva
w:Scrotum
w:Fellatio
should be hidden?
Polomo
⟨
oi!
⟩ ·
17:32, 22 April 2026 (UTC)
Reply
I have yes, and no I do not. —
Justin (
ko
vf
21:34, 24 April 2026 (UTC)
Reply
adding to the last point, wondering why are there discussions about censoring (hiding or removing) images and not say, text? it would be
discouraging use of Wiktionary in work environments
and
by children
if they come across the entry for anything offensive and see offensive definitions and quotations.
Juwan
🕊️
17:52, 22 April 2026 (UTC)
Reply
User:Juwan
Isn't it obvious? Images are much more a problem at work because they can readily be seen at a distance and give the impression that one is doing porn at work. Images tend to be more emotionally evocative, at least for normal folks, ie, other than linguists. Imagine trying to make billions of dollars with text-only internet pornography, competing against what's available visually.
DCDuring
talk
21:11, 22 April 2026 (UTC)
Reply
I think it should be handled the same as wikipedia. Also I love
gock
. You should create a vote on this.
~2026-24549-48
talk
18:05, 22 April 2026 (UTC)
Reply
I also think "click to view image" would be a good idea. At end of the day people want to use Wiktionary at school, work, etc. and shouldn't have to worry about an extremely graphic image appearing at any time. Also keep in mind that the amount of images that could
potentially
be added is huge. Or would you guys be okay with
do
having an image of someone "doing" someone else (oh and "do" is also slang for kill)? BTW many Wikipedias other than the English Wikipedia have this sort of system so there is no single universal precedent.
Ioaxxere
talk
19:52, 22 April 2026 (UTC)
Reply
Let the user decide if they want to hide such content. It looks like WP already has a
solution
for this; perhaps we should make it known here as well. I agree that we should not be removing
offensive
images without discussion/consensus unless it is blatant vandalism.
TranqyPoo
✏️
20:59, 22 April 2026 (UTC)
Reply
One key difference between Wiktionary and Wikipedia is page titles, as shown in the text of most links.
Wikipedia article titles are, for the most part, in English, so readers are expected to have some idea of what they are about to see before clicking through to any given article.
Wiktionary headwords are, intentionally, in much more than just English, so readers cannot be expected to have any idea of what they are about to see before clicking through.
Just based on this alone, we can anticipate that there is more potential for content to be surprising and unexpected for any given reader.
Considering also the NSFW implications, I see much more reason to automatically hide images by default, rather than show them. If
all
images are folded away by default, and if images are appropriately captioned with those captions visible even when the image is folded, users are given the option of informed decision-making as to whether or not to display them.
Again, Wiktionary is a
dictionary
site. Let's focus on the words. Images are ancillary -- often very useful, yes, but not the point of a dictionary. ‑‑
Eiríkr Útlendi
Tala við mig
00:00, 23 April 2026 (UTC)
Reply
Visual dictionaries exist, and even many traditional text-on-paper dictionaries have the occasional illustration of something that benefits from illustration. Wiktionary is, of course, not paper. That said, I wouldn't object to a "click to view image" function for aspects of human nudity.
bd2412
04:11, 23 April 2026 (UTC)
Reply
Only nudity? What counts as nudity? Probably all frontal, bottom nudity. Do we add it to pictures of topless women? But probably not topless men? Do we add it to pictures of women’s behinds? Men’s too? What about pictures of clothed people with
bulges
or
cameltoes
? Clothed women with erect nipples? Some people brought up violence... and I don’t think Wiktionary should have images of violent gore, as that (violence) is unethical; but are pictures of fights NSFW? Of people with injuries? What kind of injuries? Do injured people generally have to conceal their injuries to prevent shocking passerbys? If not, then I think we shouldn’t hide those.
I’m not against the
concept
of adding a “show image” toggle, but what bothers me is the implementation. It seems to me that it is hard to draw a line and that this line would be biased based on the demographics of Wiktionary editors, despite Wiktionary being a global project. How do you (or anyone) propose we could formulate a vote do determine what we consider NSFW? Or perhaps you (or anyone) think we don’t need set criteria for what is or isn’t NSFW?
Polomo
⟨
oi!
⟩ ·
13:26, 23 April 2026 (UTC)
Reply
Polomo
w:Wikipedia:Offensive material
might be useful as a guideline. —
Sgconlaw
talk
13:44, 23 April 2026 (UTC)
Reply
the contnet guideline there is not exactly strict with its definition of "offensive". some relevant bits to this discussion:
Material that would be considered vulgar or obscene by typical Wikipedia readers should be used if and only if its omission would cause the article to be less informative, relevant, or accurate, and no equally suitable alternative is available.
Wikipedia editors should not remove material solely because it may be offensive, unpleasant, or unsuitable for some readers. However, this does not mean that Wikipedia should include material simply because it is offensive, nor does it mean that offensive content is exempted from regular inclusion guidelines. Material that could be considered vulgar, obscene, or offensive should not be included unless it is treated in an encyclopedic manner.
Images or video containing offensive material that is extraneous, unnecessary, irrelevant, or gratuitous are not preferred over non-offensive ones in the name of opposing censorship. Rather, the choice of images should be judged by the normal policies for content inclusion.
in short, this simply furthers that offensive images follow the same
inclusion guidelines
as any other, with the purpose of being informative, and are not prioritised above others. a normal reader would expect that a sexual topic will have sexual definitions and accompanying sexual imagery. @
Eirikr
a guideline that may help a typical reader to not get shocked when clicking on an entry is including these types of images only on English entries, which is already common practice (for separate reasons).
Juwan
🕊️
14:01, 23 April 2026 (UTC)
Reply
I am familiar with that guideline and linked to it here myself. The problem is that guideline concerns how you can determine whether an image is more “offensive” than “educational” (and should thus be removed); it does not explain which kind of image is considered “offensive” in the first place, nor which criteria could be used for determining that – especially not with the intent of deciding if an image should be hidden behind a click, seeing as Wikipedia doesn’t do such a thing.
Polomo
⟨
oi!
⟩ ·
14:07, 23 April 2026 (UTC)
Reply
As others have said above, I think we should have a "click to view image" (if possible, changed to "tap to view image" on the mobile version) option for images containing nudity or any graphic content that users may not want to see.
Andrew Sheedy
talk
06:04, 23 April 2026 (UTC)
Reply
I think the click to view image would be best.
BirchTainer
talk
09:40, 23 April 2026 (UTC)
Reply
I suppose we should set up a formal vote to amend
Wiktionary:Images
. Also, would we need a new template or does one already exist? —
Sgconlaw
talk
12:08, 23 April 2026 (UTC)
Reply
Sgconlaw
Polomo
Juwan
: I've added NSFW blur support to
{{
img
}}
. See:
Special:Diff/90312097
. —
Fenakhay
حيطي
مساهماتي
14:21, 23 April 2026 (UTC)
Reply
I would like to object to this being done on mainspace and not in a sandbox while this is still in discussion.
on the technical implementation side,
|nsfw_image=
does not set
|class=notpageimage
, asked for by others. the blurring also extends outside of the image box, causing some visual oddities.
Juwan
🕊️
14:30, 23 April 2026 (UTC)
Reply
Fenakhay
would you please consider implement
|class=
rather than
|notpageimage_image
. this matches the template function on the Wikipedia template (ideally, I would prefer if the current version was re-imported). additionally, please conduct tests in a sandbox and not in mainspace. any editor should know this is good practice especially for coding.
Juwan
🕊️
20:49, 23 April 2026 (UTC)
Reply
Can I just put it on record that I find "NSFW content" a cringeworthy way to make this type of warning, as though Wiktionary is made for 13-year olds? If we implement something like this, which I don’t think we really can, let it please just say "Nudity".
Polomo
⟨
oi!
⟩ ·
16:22, 23 April 2026 (UTC)
Reply
But it might potentially be for content other than nudity, such as violent content (hopefully extremely rare). —
Sgconlaw
talk
17:09, 23 April 2026 (UTC)
Reply
In which case we should specify exactly what content is behind the blur... "Violent imagery" or something. And
inshallah
we don’t touch the words "
trigger warning
" with a ten-foot pole.
Polomo
⟨
oi!
⟩ ·
18:18, 23 April 2026 (UTC)
Reply
You can customize the warning text with
|nsfw_warning_label=
. I also made a gadget,
MediaWiki:Gadget-NsfwOverride.js
, that disables NSFW blur/labels sitewide for users who enable it. —
Fenakhay
حيطي
مساهماتي
18:23, 23 April 2026 (UTC)
Reply
would it be better to instead make this an opt-in to censor images rather than an opt-out to see them? we trust most readers to judge the offensiveness by themselves. the typical reader of a dictionary may make their own judgement and needs not be protected by an image filter.
Juwan
🕊️
20:45, 23 April 2026 (UTC)
Reply
Many things might be objectionable to many users, not just nudity. I don't think I've encountered much by way of objectionable imagery on Wiktionary, but on Wikipedia, I've sometimes found myself quickly closing a browser tab due to various things -- not just nudity, but also various medical images. I never considered going into medical as a kid simply because I don't like seeing bodies cut open, I don't like seeing detailed pictures of lesions, etc.
Considering the subjectivity of deciding what is "objectionable", I think it makes the most sense, is fairest and most consistent, and would be easiest to implement, to simply hide / fold / blur
all
images, make sure they have informative captions, and then let the user decide whether to reveal the image. ‑‑
Eiríkr Útlendi
Tala við mig
18:20, 23 April 2026 (UTC)
Reply
Wiktionary is made for everyone, thinking otherwise
is
"cringeworthy".
Saumache
talk
18:38, 23 April 2026 (UTC)
Reply
I.e., not made specifically for 13-year-olds – we are in agreement. Similarly, Wiktionary is not made specifically for Afghanis who are afraid of female faces. Or for those few Americans who tremble in fear of female shoulders.
Polomo
⟨
oi!
⟩ ·
18:52, 23 April 2026 (UTC)
Reply
OK, got you.
Saumache
talk
18:58, 23 April 2026 (UTC)
Reply
Fenakhay’s solution is genius, great job. It outweighs the issue of it being debatable in individual cases what should be hidden, which is an entirely different complication. @
Polomo
: The
Wiktionary:Content disclaimer
you linked seems irrelevant as it is unlinked. The footer on every page links to
Wiktionary:General disclaimer
; so unlike Justin on short glance opted, we don't need a local page there but its deletion, I guess, for sanitization reasons – as it already diverted attention.
Fay Freak
talk
20:48, 24 April 2026 (UTC)
Reply
The content disclaimer is one of the general Wiktionary disclaimers, linked to at the footer of each page. It is the same way on WP.
Polomo
⟨
oi!
⟩ ·
22:19, 24 April 2026 (UTC)
Reply
Polomo
: I see. It is still strange to find disclaimers within a disclaimer, as if they disclaimed the disclaimer. Because that was never likely how you navigate on the web, but editors collect everything thus. The original main intention that applied to Wikipedia is not met: being linked on medical, legal topics
etc.—which, to address the present thread, will not happen beside controversial or graphic pictures either. Still I don't see if we should be able to add anything to Wikipedia’s content disclaimer even if we link their disclaimers in our general disclaimer.
Fay Freak
talk
22:49, 24 April 2026 (UTC)
Reply
We are not in the business of deciding what is and isn't offensive, and we shouldn't
start
being in that business. I've seen someone complain that
File:Gay couple.jpg
and
File:Lesbian kiss.jpg
are
"pornography"
and should be removed from
gay
. There are certainly workplaces that would consider those images "not safe". If we take it upon ourselves to decide what is and isn't NSFW, we'd have to either hide all images of gay people or say that those workplaces don't count. Or we can avoid this, and many more issues, by just not doing that.
I support creating gadgets and other tools to allow users to easily control what they see. Eirikr's suggestion, where all images are blurred and have an informative caption that allows users to decide for themselves whether it should be displayed, seems like a good option to provide. As long as it is easy for readers to toggle between this new "everything blurred" state and the current "nothing blurred" one, either one would be fine as the default.
jlwoodwa
talk
01:17, 24 April 2026 (UTC)
Reply
I think it is clearly overkill to blur all images. If there is genuinely a difference of opinion over whether a certain image should be blurred, the matter can be discussed at the Beer Parlour. —
Sgconlaw
talk
04:53, 24 April 2026 (UTC)
Reply
What you're suggesting, is that not the current status quo?
Which is the bigger usability issue -- some people opting to not use Wiktionary at all due to images, or some people having to click something to display images?
As I see it, the former is more of an issue. ‑‑
Eiríkr Útlendi
Tala við mig
07:47, 24 April 2026 (UTC)
Reply
It’s not the status quo because right now potentially offensive images aren’t hidden. The options are whether to have the image or not. —
Sgconlaw
talk
08:30, 24 April 2026 (UTC)
Reply
I doubt this is something we'll ever settle to
every
one's satisfaction.
On one hand, we are not (and should not be) censored, and we have (and should have) unhidden, unblurred images that some people object to: for example, some Hasidic Jews don't want to see pictures of women, and photoshop them out before printing pictures in newspapers, as went viral when they photoshopped Hillary Clinton out of a photo of Obama's Situation Room; some homophobes complain that we have
gay
pictures, as noted above; some transphobes consider it grooming and/or a sex crime to make "children" (including legal adults) aware of
drag queens
or trans people, like some of our pictures do. I hope we never censor / remove / blur / "click to reveal" those kinds of pictures.
On the other hand, we're not indiscriminate, we're not putting just any and every image into any and every entry; a perusal of our entries reveals that we
de facto
collectively determined not to have e.g. pictures of rape at
rape
or
assault
In some cases, an image (of some form, whether a photo or a diagram) is, in my opinion, outright necessary; for example, the fact that some people use
nipple
to mean "the nipple and also the areola", while other people use
nipple
to mean "the nipple", makes me think a picture illustrating nipple vs areola is of great value at
nipple
, though it too has been objected to.
At
penis
, my inclination would be to either use a (unhidden, unblurred) diagram like the Wikipedia
w:Human penis
article's
File:Penis_lateral_cross_section.jpg
, or/and (in lieu of the current collage that just shows a human penis over and over) use a collage showing various organisms' penises, including a human's, similar to how the Wikipedia article contains images of various penises.
In the case of
futanari
, the image is a cartoon, rather than a photo, so I see less reason to hide it, but OTOH it also doesn't seem as vital to understanding the definition as some images do, so I'm not wedded to it being there at all.
An
opt-in
gadget that blurs all images for users who
want
to blur all images seems unobjectionable to me (letting them read the definition / image description and then decide if they want to see an image), if it can be implemented without requiring us to use a special
{{
img
}}
template or parameter to make it work (i.e. if users can keep using the longstanding
[[:File:
syntax).
Blurring all images for everyone by default and requiring people to opt
out
of that in order to see images seems to me like a bad idea and I would oppose it. And a system where only certain images are blurred seems like a can of worms we're better off not opening.
- -sche
(discuss)
15:26, 24 April 2026 (UTC)
Reply
I pretty much agree with everything -sche says. I would also oppose making all images blurred as the default position, but if there is some gadget that allows users to choose that option for themselves I have no objection to it.
Also, if certain images are blurred or hidden, I'm wondering if it is necessary to have a special message saying something like "This image is not safe for work". Wouldn't it be enough to have a properly written (and visible) caption which provides enough information for users to decide whether or not to view the image? —
Sgconlaw
talk
15:34, 24 April 2026 (UTC)
Reply
thank you
to @
Jlwoodwa
and @
-sche
for describing the situation very well.
Juwan
🕊️
16:05, 24 April 2026 (UTC)
Reply
I am also in favor of a gadget that allows users to hide all images. I think blurring is the wrong approach in that case... I envision a box, of a size similar in width to that of
{{
swp
}}
that reads
Images ▼
and reveals images when clicked.
Polomo
⟨
oi!
⟩ ·
16:07, 24 April 2026 (UTC)
Reply
requesting @
Fenakhay
to update his gadget for something like this, without necessitating the experimental
|nsfw_warning=
parameters. see also the notes on implementation above.
Juwan
🕊️
16:27, 24 April 2026 (UTC)
Reply
+1 for @
-sche
's succinct summary -- especially the "can of worms" description of attempting to hide only certain images.
Sgconlaw
, the trouble with coming up with any special message about "This image is not safe for work" is that this requires that we (the editors) go through each and every image to categorize -- necessitating a huge burden; and in that process, we cannot imagine all of the cases that our audience (readers anywhere on the planet) might or might not find "safe" -- necessitating opinion-wrangling. If we are to implement any system at all for hiding images, the only sane way is to apply it to all images. I am perfectly happy having this be an opt-in system, presumably something that would only be available to logged-in users via user preferences (unless user prefs are now also something that anons get, and that can somehow be saved across anon sessions?). But trying to set this up this only for
some
images is an implementation and maintenance morass.
May I suggest messaging that's something like these instead, which could be applied to any and all images:
"This image might be unsafe for work. Please read the caption, if any, and reveal the image at your own discretion."
"Images are [hidden/blurred/etc.] by default, as configured by
[link to relevant user pref]
. Please read the image caption, if any, and click the image to to reveal it at your own discretion."
‑‑
Eiríkr Útlendi
Tala við mig
17:28, 24 April 2026 (UTC)
Reply
Eirikr
: the point I made in my most recent comment was: do we need to have a special warning message? Wouldn't a properly written caption be enough for users to decide whether to click on a hidden image? —
Sgconlaw
talk
17:46, 24 April 2026 (UTC)
Reply
If an image is blurred without any indication of why, it might not be obvious to readers what has happened, how to view the image, how to switch the preference, etc. They might just think it has failed to load. Many websites display a blurred thumbnail of an image while downloading the full version, after all.
jlwoodwa
talk
18:06, 24 April 2026 (UTC)
Reply
People could also make this judgment based on the word’s definitions.
On the desktop website, the right sidebar allows you to permanently show or hide quotations, conjugations, etc. until clicked — we could similarly allow people to hide all images through a button in the sidebar (keeping the default as having them shown), so that if someone sees something they don’t like once, they can disable images sitewide. The problem is that the mobile website doesn’t have as easy a way to change this type of thing.
Polomo
⟨
oi!
⟩ ·
18:24, 24 April 2026 (UTC)
Reply
I don't think we are giving proper consideration to use cases in which an image many object to more or less ambushes the user, appearing by default at the first screen for an entry, such as:
at work in an open office or otherwise shared space.
in a public place, such as an internet cafe or a library, similar to workplace open office
anywhere for a new, unregistered user, who does not have or is not aware of "preferences" and "gadgets".
anywhere for young children.
Failing to consider each of these and take action to prevent or deflect pressure to exclude Wiktionary from intranets including homes may prevent a large portion of users from benefiting from our service. I think the problem is mostly with sex-related images, though gratuitous violence, and images of clowns may turn out to also be problems.
DCDuring
talk
21:42, 24 April 2026 (UTC)
Reply
See
Template talk:haplological form of
and
Category talk:English haplological forms
1. Rename categories named "Category:[Language] haplological words" to "Category:[Language] haplological terms" as per regular practice in our category-naming overall.
2. Have "Category:[Language] haplological forms" as non-redirect subcategories to the aforesaid "... terms" categories which would differentiate haplological alt forms (e.g., Latin
dīxtī
) from terms regularly derived by haplology (e.g., English
vie
).
Second proposal may have further impact on other "... form of" templates and related categories; see
scrum
, which I doubt one would formally deem a "form" (further discussed in linked talk page above).
On a related note: I think
bounce
and other entries like
abash
are miscategorized in
Category:English onomatopoeias
("terms that were coined to sound like what they represent", a definition not found at
onomatopeia
): should we strive for inclusive categories that minimize the creation of subcategories/precise categories or create as many as is needed to better and more accurately categorize terms?
Saumache
talk
12:02, 24 April 2026 (UTC)
Reply
Lately,
{{
col
}}
has been increasingly used in various sections of entries, including semantic relations, Derived terms, Related terms, Collocations, and See also. However,
WT:ELE
only mentions the template in the
Derived terms
section. Is it possible to update the formatting guidance on the page in relevant sections to reflect current practice or does this change require a vote?
In addition,
WT:NYMS
also contains example markup for each semantic relation. However, this seems even more outdated as most sections don't even explain inline templates as an alternative to the list format (except for synonyms). Therefore, I suggest moving detailed (and up-to-date) formatting advice on semantic relations to either
WT:ELE#Synonyms
or
WT:NYMS#Synonymy
and add pointers from the other locations.
Einstein2
talk
20:49, 24 April 2026 (UTC)
Reply
I think if you want to explain it according to your best abilities right in
WT:ELE
—the greatness of which I am acquainted with—, you have to write more than you can include without a new vote. But you can rewrite
Wiktionary:Semantic relations
without that requirement, and only afterwards make
WT:ELE
harmonize and lose a few words on these formatting variants.
WT:ELE
has become outdated in a broader sense because of the assumption of everything being structured around headers—a plaster won't do it.
Fay Freak
talk
21:05, 24 April 2026 (UTC)
Reply
Note this is of particular interest to Cherokee editors. There is not a working group to ping, tho. —
Justin (
ko
vf
21:33, 24 April 2026 (UTC)
Reply