Wiktionary:Beer parlour

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:BEER)
Jump to: navigation, search

Wiktionary > Discussion rooms > Beer parlour

Lautrec a corner in a dance hall 1892.jpg

Welcome, all, 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 Wiktionary aspects—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list (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. There are various other discussion rooms which may serve the idea behind your questions better. Please take a look to see which is most appropriate.

Sometimes discussion identifies an issue as an idea for policy development or rewriting. Such discussions may be taken out of the Beer parlour to a relevant page, or a brand new page may be created. Usually, the active policy pages will be listed in one of the sections below. See also the policy development page and the votes page.

Questions and answers will not remain on this page indefinitely, as it would very soon become too long to be editable. After a period of time with no further activity (usually a couple of weeks), information will be moved to the archives. We make a point to preserve all discussions that were started here in the archives. However, talk that is clearly not intended for this page may be moved and will not end up in the archives. Enjoy the Beer parlour!

Beer parlour archives edit


November 2017

Category:Subtypes of compounds by language[edit]

I'd like to create categories for French compounds comprised of:

but I don't know how to name them. It would be useful to distinguish between words such as porte-clef (verb+noun) and porte-fenêtre (noun+noun). Any ideas? --Barytonesis (talk) 19:13, 1 November 2017 (UTC)

I'd just name them more or less as you said, Category:French verb-noun compounds. I notice that we have Category:French compound words with "words" at the end, but all the subcategories of Category:Subtypes of compounds by language, as well as this category itself, lack "words" in the name. Is this something that needs to be corrected? It might be better to do it now, before we start creating more of these categories. —Rua (mew) 20:14, 1 November 2017 (UTC)
Category:Subtypes of compound words by language then? Category:Compound words subcategories by language? Category:Types of compound words by language? (to follow up on Erutuon's suggestion at Wiktionary:Beer parlour/2017/July § Compound and fiction etymology categories)
See also Module talk:category tree/poscatboiler/data/terms by etymology.
Fine by me in any case. --Barytonesis (talk) 00:10, 2 November 2017 (UTC)
@Rua? --Barytonesis (talk) 15:00, 3 November 2017 (UTC)
I'm waiting for others to offer their views. —Rua (mew) 15:05, 3 November 2017 (UTC)
@DCDuring: you were mentioning here the idea of categorising compounds by their head. Maybe you'd like to weigh in? --Barytonesis (talk) 15:23, 13 November 2017 (UTC)
I like the idea of adding depth to our existing entries by almost any means, including categorization.
For compound words one could categorize by head PoS and subcategorize by the PoS of the other element of the two-part compound. The subcategorization might be essential because for most English compounds the PoS of the compound is the same as the PoS of its head. English being what it is (terms that are nouns and verbs as well as nouns being used as noun modifiers), not all such categorization would be indisputable. I think such categorization could help non-natives understand English compounding better and might be useful to linguists. I don't think we would have to have complete coverage to be useful.
It would be consistent with a general scheme of characterizing all multi-word terms grammatically. We already have such categories as Category:English coordinates, Category:English non-constituents, and Category:English predicates.
Also, for words that have suffixes or prefixes it might be useful to distinguish via categories those words of denominal, deverbal, and deadjectival derivation. DCDuring (talk) 20:54, 13 November 2017 (UTC)

Participate in Dispute Resolution Focus Group[edit]

The Harvard Negotiation & Mediation Clinical Program is working with the Wikimedia Foundation to help communities develop tools to resolve disputes. You are invited to participate in a focus group aimed at identifying needs and developing possible solutions through collaborative design thinking.

If you are interested in participating, please add your name to the signup list on the Meta-Wiki page.

Thank you for giving us the opportunity to learn from the Wikimedia community. We value all of your opinions and look forward to hearing from you. JosephNegotiation (talk) 22:50, 1 November 2017 (UTC)

"The scope of this project is limited to the resolution of disputes concerning improper or disruptive behaviors." (from m:Research:Developing Wikimedia's anti-harassment and behavioral dispute resolution systems) DCDuring (talk) 13:24, 2 November 2017 (UTC)
P.S. I am setting up a group for the promotion of improper disruptive behaviours, because they are the only way to stop some bastards. You know whom to call. Equinox 13:25, 2 November 2017 (UTC)

Project idea kind-of maybe[edit]

SECRET CLUB LINK: User:Equinox/EWDC. The rest is babble.

Who else is obsessed with adding missing English words, like I am? I know there are some of you, although User:Visviva seems to have found something better to do. I've got a ton of missing English words from all kinds of sources. The ones I have really tried but couldn't work out can be seen in the alphabetical list on my user page. But I've got a zillion more. Does anyone want to be in ENGLISH WORD DEFINING CLUB. I think it would be pretty amusing, and maybe useful, to break down some of these huge lists and split 'em across a group, and everyone would take five words per week (or whatever) and see what they can do. Probably not alphabetically or there would be a rash of suicides as we hit M and everybody got 30-letter words starting with methyl. -- If anyone is into this I will tell more secrets about my word lists. Equinox 05:48, 2 November 2017 (UTC)

I'm in. Let's get to 1 million lemmas. DTLHS (talk) 05:54, 2 November 2017 (UTC)
If you wanna do it then sign on this page, and make a little Scout salute. User:Equinox/EWDC. Equinox 06:00, 2 November 2017 (UTC)
Minerals, geological periods and formations. DCDuring (talk) 13:20, 2 November 2017 (UTC)
It's only fun when the words are random. We could split them by theme but see above re methyl. Equinox 13:22, 2 November 2017 (UTC)
If I had done Webster 1913 from A to Z rather than having a random number generator, I would probably have chugged bleach in 2015 rather than 2018. Equinox 13:27, 2 November 2017 (UTC)

November LexiSession: toilets[edit]

The monthly suggested collective theme is toilet. It's not a fancy topic but an interesting one and 19th of November is the World Toilet Day (no kinding). So, we may improve Thesaurus:toilet and all the slang words referring to this crucial place! And you are not push to contribute from this place.

Lexisession is a collaborative experiment without any guide or direction. You're free to participate however you like and to suggest next month's topic. If you participate, please let us know here or on Meta, to keep track on the evolution of LexiSession. I hope there will be some people interested this month, and if you can spread it to another Wiktionary, you are welcome to do so. Ideally, LexiSession should be a booster for every project at the same time, to give us more insight into the ways our colleagues works in the other projects.

Have a good time! Face-smile.svg Noé 09:03, 2 November 2017 (UTC)

French Wiktionary October news[edit]

Logo Wiktionnaire-Actualités.svg


Hey! October issue of Wiktionary Actualités just came out in English!

Long Actualités this month with five articles: what is the patrol, a review of a research that use Wiktionary, a dictionary with celtic words in French, a feedback from the Wikiconvention francophone and a short point on the phatic function of the language. Plus, as usual: highlights from the press, statistics, videos, LexiSession and colorful pictures!

This issue was translated by Jberkel in less than a day, and may can be improved by readers (wiki-spirit-love-love). We did not receive any money for this publication and we are not supported by any user group or chapter. It is only written by the community, for the large community of lexilovers! Feel free to send us comments on our writings, or differences between our projects Face-smile.svg Noé 08:53, 3 November 2017 (UTC)

Template:bor: Replace notext=1 with withtext=1[edit]

@Daniel Carrero, TheDaveRoss As part of the effort to remove the text from {{bor}}, we've been adding notext=1 to calls of this template. The idea is that any instances that are called the old way, without that parameter, are still in need of fixing. But this is really annoying and backwards so I propose to reverse the sense of the parameter:

  1. Module:etymology/templates is modified to accept both a notext=1 and withtext=1. withtext=1 is initially implemented as a no-op parameter.
  2. Any instances of {{bor}} that don't currently have notext=1 get withtext=1 added by a bot.
  3. The module is modified so that the text is not displayed by default, thus notext=1 becomes the no-op, and withtext=1 triggers the inclusion of the text.
  4. Any instances of {{bor}} that have notext=1 have it removed by a bot.
  5. The module is modified again to remove the notext= parameter.
  6. The template now works the way it should, and any further efforts at cleanup are now focused on Category:bor with withtext.

Rua (mew) 13:38, 3 November 2017 (UTC)

I concur. --Barytonesis (talk) 15:00, 3 November 2017 (UTC)
I see no way in which this helps at all (just like using a bot to change "{{bor|aa|bb}}" to "Borrowed from {{bor|aa|bb|notext=1}}"). It's just more work for the editor. —Aryaman (मुझसे बात करो) 17:51, 3 November 2017 (UTC)
Why? —Rua (mew) 17:56, 3 November 2017 (UTC)
The question to ask is whether this does any harm other than temporary confusion to editors while the switch is underway. If not, the benefits of speeding up the phaseout of the "Borrowed" text would be reason enough, IMO.
The removal of this text was agreed to a while back, partly to reduce the arbitrary differences needed to be learned between the behavior of similar templates in the {{bor}}/{{inh}}/{{der}}/{{cog}} group, and partly because the added parameters needed to customize the text like |nocaps= are more trouble for many editors than just typing the text by hand every time.
Although the removal of the text makes more work when the template is at the very beginning of the etymology, it makes things simpler for new users and less work in all other cases. Even for those who don't like what's being done, there's something to be said for getting the transition over with. Chuck Entz (talk) 20:06, 3 November 2017 (UTC)
I concur too. It is regularly nerve-racking having to add “notext=1”, and the reasons explained by Chuck Entz are true to the facts. Palaestrator verborum (loquier) 22:14, 3 November 2017 (UTC)
Yes, let {{bor}} default to showing no text. Ideally, in future, let "Borrowed" be no longer shown in etymologies at all. --Dan Polansky (talk) 22:24, 10 November 2017 (UTC)
I'm supportive of unifying template behavior to no longer add text. However, why remove "borrowed" if an editor has added it? This is useful information for the reader. ‑‑ Eiríkr Útlendi │Tala við mig 22:30, 10 November 2017 (UTC)
It is not part of Rua's proposal, but anyway: I don't believe "Borrowed" is useful. It looks like cruft to me. Merriam-Webster does not have it. Whether term T1 is borrowed from T2 or is inherited seems to nearly always follow from which languages T1 and T2 belong to, and therefore, it is a rather trivial piece of text that does not need to be on the radar screen of the reader. --Dan Polansky (talk) 22:34, 10 November 2017 (UTC)
I write "From" for inherited terms, and "Borrowed from" for borrowed terms. I do this also for non-initial parts of the etymology, e.g. Latin borrowed from Greek in an English etymology. —Rua (mew) 22:43, 10 November 2017 (UTC)
It's a distinction without a difference. Czech cannot inherit from French, so it has to borrow; when I see "From French ...", I know it's a borrowing. --Dan Polansky (talk) 22:48, 10 November 2017 (UTC)
You know that, but does everyone else using Wiktionary also know? And there are some languages that are both borrowed and inherited from. Latin is a good example. For those languages, we need to specify borrowings. And for consistency it then makes sense if we do it for all of them. I really don't understand what the objection to it is. —Rua (mew) 22:51, 10 November 2017 (UTC)
There is nothing to know since "borrow" is only a terminology that indicates a trivial distinction, one without a difference. It's the same kind of objection that I have when someone adds "noun" before the word in etymology chain, or instead of "from" writes "which comes from"; I like things to be very compact, and get rid of all that looks like cruft. Merriam-Webster online seems to see things the same way I do. --Dan Polansky (talk) 23:02, 10 November 2017 (UTC)
The distinction between borrowing and and non-specific derivation might not be significant, particularly for Greek terms borrowed using Latin spelling, but the distinction between borrowing and inheritance is significant for some doublets like Spanish palabra and parábola. Both of them originate from the same Latin term, parabola, but the inherited one has undergone sound changes that the borrowed one has not. I don't know how this exactly relates to having "derived" as well as specifically "borrowed" and "inherited" categories, though. — Eru·tuon 23:45, 10 November 2017 (UTC)
These doublets are interesting, thank you, but I do not see that rather small group of items as a sufficient reason to flood our etymologies with "borrowed" that for all but a very small portion of all cases (>99%?) adds nothing beyond the obvious. --Dan Polansky (talk) 08:11, 11 November 2017 (UTC)
If you find it fluff, but others find it useful, can you live with the presence of Borrowed from in entries? ‑‑ Eiríkr Útlendi │Tala við mig 03:44, 12 November 2017 (UTC)
I want to see "Borrowed" gone even if some people find it useful. I reject the following principle: If several users find a certain more loquacious and space-consuming presentation useful, all users should be exposed to that presentation, even if those several users are a small minority. If I am the minority, I have to live with "Borrowed" anyway. --Dan Polansky (talk) 08:25, 12 November 2017 (UTC)

I've done step 1 and a bot is now doing step 2. —Rua (mew) 22:41, 10 November 2017 (UTC)

Step 2 is complete, but I noticed that Category:bor without notext is still being filled with new entries day by day. I've notified Equinox of the upcoming change, but there may be others who still rely on the old format that need to be notified. —Rua (mew) 17:34, 11 November 2017 (UTC)
Step 3 has been done, now the template works in the intended way. The text is no longer shown by default. —Rua (mew) 12:36, 12 November 2017 (UTC)
A bot is now working on step 4. There's 40 thousand entries, so it will take a while, possibly multiple days. —Rua (mew) 12:44, 12 November 2017 (UTC)
Everything is now done! —Rua (mew) 19:36, 12 November 2017 (UTC)
Nice! --Daniel Carrero (talk) 01:29, 13 November 2017 (UTC)

Translations with a different part of speech that express the same idea[edit]

@Adelpine I just noticed diff. French may not even have a noun to express this idea, so I don't think it's helpful to remove this translation. I recall that we had a discussion in the past where we agreed that it was desirable to have translations that express the same idea even if the part of speech is different. A common example is a verb that expresses what is an adjective in English or vice versa. Stative verbs are a thing in many languages. —Rua (mew) 13:46, 3 November 2017 (UTC)

@Rua OK. I will not remove this kind of translations from now on.--Adelpine (talk) 20:42, 3 November 2017 (UTC)

Add pronunciation of chinese words in the table titled "Dialectal synonyms of", under the "Synonyms" header.[edit]

Just like in the box for "Derived terms from", under the "Compounds" header, there's plenty of space for it, and otherwise you have to click every word and then go back in your browser, expand the table again. --Backinstadiums (talk) 21:35, 3 November 2017 (UTC)

Since when do we have a separate header for Compounds? It should be Derived terms. —Rua (mew) 22:17, 3 November 2017 (UTC)
Symbol oppose vote.svg Oppose. This was discussed and it was decided to leave them out, for otherwise the table could get quite wide and also we don't hold pronunciations for most regional dialects. The discussion is somewhere. —suzukaze (tc) 22:30, 3 November 2017 (UTC)
@Rua: For example
That entry is malformed in all kinds of ways. There's no part-of-speech header, and there's a Compounds header at L3. I changed Compounds to L4 Derived terms, but the part of speech needs to be fixed still. —Rua (mew) 22:47, 3 November 2017 (UTC)
Compounds are not necessarily derived from the definitions; they are merely all multicharacter words containing the character. Characters can also be used phonetically. Wyang (talk) 22:48, 3 November 2017 (UTC)
Single-character Chinese entries don't get part-of-speech headers and it has been the language policy, de facto and by the About Chinese page, for quite some time. They get Definitions header. --Anatoli T. (обсудить/вклад) 00:37, 4 November 2017 (UTC)
It seems phonocentristic to me to assert that the contested formations are not derived terms. Of course they are derived terms, in so far as we take the graphical words, independent of any underlying phonetic value, and stick them together. It’s graphemological derivation in the sense as we also use the word “derivation” to subsume compounds. So I presume that Rua is right about that heading. Palaestrator verborum (loquier) 00:49, 4 November 2017 (UTC)
WT:ELE#Derived terms:
List terms in the same language that are morphological derivatives.
See Morphological derivation. Wyang (talk) 01:04, 4 November 2017 (UTC)
Seems like the definition there is a slip, as everywhere there are compounds listed under “derived terms”, notably German, while derivations are “contrasted with other types of word formation such as compounding”. Meseems WT:EL has a bug, because compounds and such as the Chinese formations need either to use the Derived terms heading against the WT:EL definition or have invented a new heading. Palaestrator verborum (loquier) 04:13, 4 November 2017 (UTC)
Morphological derivation and compounding are subsumed under "Derivation" in general Wiktionary terminology (see e.g. search:"insource:/derived from/"), whereas Chinese words using characters phonetically are not said to "be derived from" those individual characters. Consequently, CJKV character entries conventionally use "Compounds" instead of "Derived terms" to include these words, at L3, as they are not subordinate to the definitions. Wyang (talk) 05:21, 4 November 2017 (UTC)
That’s what I already have observed and is expressed above. I have explicitly stated that the practice of listing lexical compounding deviates from the description in WT:EL, or rather the description deviates from the current best practice, and Atitarev has elucidated that Chinese entries generally use the heading “Compounds”. However I contest the notion of “phonetical derivation”. Your outlinings exhibit some unjustly blurry and simplifying thinking. Most commonly “derivation” is understood as lexical, on the level of lexemes and lexes rather than phonemes and phons. But nothing gainstays speaking of derivation on a mere graphical level. But here I opine that “Derived terms” and “compounds” are alike misleading. “Compounds” are typically understood as lexical, i.e. inheriting the meanings of the uncompounded elements – though this is mitigated by the use of L3 instead of L4 –, and is here used quite untechnically, while “term” is a word that can hardly be used in English if no focus on meaning is intended, so the reader might wrongly assume or maybe needs wrongly assumes a little that it is spoken of “derived terms” because some meaning is inherited. Factually both headings are – on the L3 place – roughly correct as long as understood the intended way. However so far it seems to me that there is no way to solve the dilemma because the available English lexicon is too phonocentristic for a reliable generalized heading. Every handling is wrong and there is no solution as long as no cruel and unusual diction is adopted. Palaestrator verborum (loquier) 06:31, 4 November 2017 (UTC)
No, you still don't get it. "Derivation/derived/derives from" on Wiktionary generally means both morphological derivation and compounding, but the terminology is not used for phonetically used glyphs. You have to understand there isn't a perfect solution to many issues in language handling on Wiktionary; what is to be respected is conventional practices that the relevant editors have come up with and have deemed to be the most appropriate. The CJKV editors have long felt the use of "derived" in the description of phonetically chosen characters to be very misleading and have been avoiding such wording whenever possible. It provides way more harm than benefit to Wiktionary readers who are used to understanding "derived" as "etymologically derived".
From your initial, almost instinctive denunciation as an unfamiliar outsider, to the insistence that "derivation" on Wiktionary be interpreted in your manner after having been corrected, and the silly summarisation of the practice as "phonocentrism", your posts come across as quite misinformed and pretentious. You have not worked on CJKV languages, and are unfamiliar with them, so please appreciate that you are unversed in these languages' complexities and the rationales for the conventions. Wyang (talk) 07:20, 4 November 2017 (UTC)
I disagree that the editors and/or speakers of a language should always have the last say, as it can lead to politically/emotionally motivated decisions rather than linguistically based ones (Wiktionary:Votes/pl-2014-03/Unified Norwegian anyone? And the opposing votants barely contribute here, with the exception of Donnanz...). However, I have complete trust in the Chinese contributors, who are numerous, very active and very linguistically literate (as far as I can tell, which doesn't mean much in this case). So I think all the decisions about Chinese can be safely left to them. --Barytonesis (talk) 09:53, 4 November 2017 (UTC)
But you only repeat what I say, Wyang: “No, you still don't get it. ‘Derivation/derived/derives from’ on Wiktionary generally means both morphological derivation and compounding, but the terminology is not used for phonetically used glyphs.” I have said that derivation means 1. lexical/morphological derivation 2. in a broader sense, compounding 3. by virtue of the abstract meaning of the word, those Chinese “compounds” which are not formed because of meaning but because of matching sounds – I don’t think that it is false to speak of “derivations” in the third case, and I have not claimed that the third meaning is used with the “Derived terms” headings. I rather opine that it is wrong to speak of “derivations”, rather than false, because of the misleading consequences you already know (people thinking that the meaning is inherited).
“but the terminology is not used for phonetically used glyphs.” It’s what I have presumed; I have even given the reasons why it is misleading to speak of derived terms. I have said “Of course they are derived terms, in so far as we take the graphical words, independent of any underlying phonetic value, and stick them together,” but that is only the reason why one might believe that it is correct to to speak about the “compounds” as “derived terms”, while on the contrary I have give a reason against using it and why it is wrong, but not false. “’term’ is a word that can hardly be used in English if no focus on meaning is intended, so the reader might wrongly assume or maybe needs wrongly assumes a little that it is spoken of “derived terms” because some meaning is inherited.”
“You have to understand there isn't a perfect solution to many issues in language handling on Wiktionary” – I said ”there is no way to solve the dilemma because the available English lexicon etc.”.
“the insistence that "derivation" on Wiktionary be interpreted in your manner” I have not insisted on anything, I have quite explicitly stated that I know no solution but rather deny its possibility – ”However so far it seems to me that there is no way to solve the dilemma”. My purpose has been to pronounce in which different meanings “derivation” can be understood by whomever, to elucidate the causes of the frictions about and that the definition in WT:EL needlessly contributes to a confusion by dint of displaying only half of the practice with the “Derived terms” heading. How difficult is it to get that I do not call for any action (short of possibly clarifications in WT:EL to regard compounds as in German and those here called “compounds” in the Chinese entries) but call for awareness about the terminology needs being frictious?
In other words:
  1. The ”compounds” listed at are all compounds.
  2. The ”compounds” listed at are not only compounds.
  3. The ”compounds” listed at are all derived terms.
  4. The ”compounds” listed at are not only derived terms.
I esteem all four propositions correct, I am with no side. No contradiction is intended. And if I have said “I presume that Rua is right about that heading” it’s not because I side but because it follows from her proposition that I have formulated in (3.) being correct and only that far. However I do not recommend that stance, as this choosing of words is more likely to be misunderstood than “compounds”; and I do not recommend any wording, as I have said, as all wordings I know are wrong. Palaestrator verborum (loquier) 17:59, 4 November 2017 (UTC)
TLDR. You lost me when I saw the number of bytes in your addition. Not everyone has time for this. Wyang (talk) 23:09, 4 November 2017 (UTC)
@Suzukaze-c: Neither of your reasons are very convincing; as I said, most tables have plenty of space, and otherwise they could be expanded lengthwise. As happens in the table for "Derived terms from", leaving out those pronunciations we are not aware of is not very disturbing, just as we do with unknown etymologies, translations, definitions themselves... and yet those words are added as "Derived terms from", appearing in red. --Backinstadiums (talk) 22:45, 3 November 2017 (UTC)
I don't think adding pronunciations to the module is sustainable, especially considering that there will be topolects not covered yet or words with multiple readings but I think adding simplified form is probably feasible and should be done. So far, the promise after the centralisation of the contents to always provide simplified characters in all entries was kept in all Chinese modules but not in this one. --Anatoli T. (обсудить/вклад) 03:27, 4 November 2017 (UTC)
What on earth happened to politeness in this functionality request (actually more like a demand)? Wyang (talk) 07:38, 4 November 2017 (UTC)
Hi guys, @Wyang: I am sorry if I seem too "demanding", or even cheecky, but I am just a language enthusiast, and so I try to improve this place with objective critical posts. --Backinstadiums (talk) 08:36, 4 November 2017 (UTC)
I didn't mean to sound demanding either, sorry if it sounded that way. It was a general comment - we have kept the promise but not always, which includes myself, since I have been involved in Chinese edits as well. The feature (of providing simplified variants) would be good to have. --Anatoli T. (обсудить/вклад) 09:59, 4 November 2017 (UTC)
{@Wyang: No offense taken at all, do not worry :-) --Backinstadiums (talk) 10:36, 4 November 2017 (UTC)


Regarding Appendix:HSK_list_of_Mandarin_words, except for the first level, the rest presents first the simplified word, then traditional in parentheses, which as far as I can tell is the reverse approach taken here. Furthermore, the advanced level shows a formatting error, starting at letter "w", repeating "Template:l" in a column several times. --Backinstadiums (talk) 11:20, 4 November 2017 (UTC)

WT:ACCEL upgrade[edit]

Over at WT:GP there's a thread about improving the WT:ACCEL script. I've now completed this and I'd like to replace the original script with it. To spare you all the technical details of the discussion, here's what's changed in the new version:

  • Rather than generating the entire new entry for each accelerated link in a page, it only appends the acceleration data onto the URL.
  • If the OrangeLinks gadget is enabled, any orange links are modified to become edit links, and also have acceleration data added.
  • The data in the URL is picked up by the edit page, which is what actually generates the entry and places the content in the edit window. This relieves some of the workload from the main page.
  • If you are editing an existing page and acceleration data is given in the URL (as with modified orange links), the script will insert the new language section into the existing wikitext at the appropriate location.

This last point is especially a big improvement, as it means that you can now use accelerated links even if the entry already exists. The current creation rules work with the new script without changes, and no changes need to be made to accelerated links.

Is it ok to replace the old script with my new one? The code is at User:Rua/Gadget-AcceleratedFormCreation.js. —Rua (mew) 11:56, 4 November 2017 (UTC)

An additional feature has been added. Now, it is possible to specify multiple sets of grammar tags in the URL, using accel1=, accel2= and so on. The script will generate multiple entries in this case, but it will try to merge them so that information isn't duplicated. If two adjacent entries differ only in their definition, with everything else being equal, then the two entries are merged and the definitions are placed next to each other. Moreover, if both definitions use {{inflection of}}, then the inflection tags are also merged, so that e.g. definition 1 with {{inflection of|soddjil||com|s|lang=se}} and definition 2 with {{inflection of|soddjil||loc|p|lang=se}} are merged as {{inflection of|soddjil||com|s|;|loc|p|lang=se}}.

The part of the script that generates the links does not yet make use of this feature, so if two different forms have the same page name, each link will still only generate an entry for its own form. It would be desirable for the script to combine accelerated links if they have the same page name, but this is not trivial: the script would have to decide in which order to place the forms. Consider the entry soddjil: the comitative singular is identical to the locative plural. In the HTML, the locative plural appears first, since tables are organised by row and locative is in a higher row than comitative. It would be desirable, however, to generate an entry with the order com|s|;|loc|p as above, with singular taking precedence over plural. Either the script would have to be modified with more complicated logic to decide which goes first, or the ordering of the elements in the HTML would have to be changed so that all singular forms appear in the HTML before all plural forms. —Rua (mew) 14:53, 5 November 2017 (UTC)

After some more work, the script will now automatically combine identical forms into a single link. It does this on a per-language basis, meaning it gathers all the accelerated links for a particular language for a particular target page, and combines them. It uses the order that the links appear in the HTML to determine which order the entries should be generated in. But perhaps there are ways to change the HTML order? —Rua (mew) 16:21, 5 November 2017 (UTC)

It is a definite improvement to not generate a bunch of new entries at once, and to allow the gadget to add language sections to existing pages. However, I haven't used the gadget much (it needs support for Ancient Greek), so I'm not a good person to test it.
For Ancient Greek and Latin at least, I doubt it would be worth trying to mess with the HTML in tables to get the forms to appear in the correct order. The HTML order for Ancient Greek and Latin nouns is by case and then by number, as the numbers are in column headers and the cases in row headers. The order could be changed by putting each number in a subtable, but that would be messy. The order for Ancient Greek verbs is probably okay though.
Perhaps the order could be imposed using maps and the array sorting function. Thinking of Latin nouns, maps from label to information: type (case or number) and a ranking number (nominative: 1, genitive: 2, ...; singular: 1, plural: 2). And a map from number and case to their ranking numbers (number: 1, case: 2). — Eru·tuon 06:32, 12 November 2017 (UTC)
I've implemented another possibility instead, the one I described on WT:GP. Now, if you want forms in one column (e.g. singular) to always have their definition before forms in another column (e.g. plural), then you specify data-accel-col=number on the table cells of each column. Forms within the same column will then always come before forms in a column with a higher number. This can be seen in Module:se-adjectives (or for an example entry, soddjil). Although the comitative singular form appears in the HTML after the locative plural form, the column numbers make sure it comes first in the generated entry, so that you get {{inflection of|soddjil||com|s|;|loc|p|lang=se}} and not {{inflection of|soddjil||loc|p|;|com|s|lang=se}}. This should work for Latin and Greek as well. —Rua (mew) 16:47, 13 November 2017 (UTC)

If there are no further comments, I will put in the new script on the 19th, two weeks after the initial post. —Rua (mew) 13:11, 14 November 2017 (UTC)

The script has now been activated. Have fun! —Rua (mew) 11:47, 19 November 2017 (UTC)

Thanks, seems like an improvement. Equinox 16:14, 21 November 2017 (UTC)

chinese anagrams[edit]

鞦韆 indicates it's an anagram, but without being indexed to a category of anagrams. How can I find a list of the ones shown in Wiktionary?

This should be a good approximation of what you wanted. Wyang (talk) 00:07, 5 November 2017 (UTC)
@Wyang: Could you tell me where to find info. about the advanced search operators? --Backinstadiums (talk) 08:12, 5 November 2017 (UTC)
You can find more documentation on mw:Help:CirrusSearch and w:Help:Advanced search. Wyang (talk) 08:16, 5 November 2017 (UTC)
@Wyang: Thanks again! BTW, I'd rather use that space for the HSK levels, creating a category for anagrams and indexing words to it. --Backinstadiums (talk) 08:52, 5 November 2017 (UTC)
Wiktionary currently does not have an anagrams category in any language. —suzukaze (tc) 08:54, 5 November 2017 (UTC)
@Suzukaze-c: Regarding the English language, I've read similar proposals and discussions about the topic.--Backinstadiums (talk) 09:00, 5 November 2017 (UTC)
The problem is most words don't have anagrams. So if we created a category (automatically) for each word like "English words with alphagram abc", we would have hundreds of thousands of categories with only a single member. Adding the alphagram categories explicitly only for words with anagrams wouldn't provide any benefit over just listing the anagrams on the page with a bot (like I do now). DTLHS (talk) 21:54, 5 November 2017 (UTC)

Desysopping CodeCat aka Rua[edit]

FYI, I created Wiktionary:Votes/sy-2017-11/Desysopping CodeCat aka Rua. --Dan Polansky (talk) 22:40, 4 November 2017 (UTC)

variant forms of 𠃊[edit]

The cross-references for the variant forms of 𠃊 seem to have failed, aren't they generated automatically? --Backinstadiums (talk) 08:57, 5 November 2017 (UTC)

nope! all manual —suzukaze (tc) 08:58, 5 November 2017 (UTC)
O.K. Is it as such on purpose or for technical issues, or rather nobody noticed it before? --Backinstadiums (talk) 09:02, 5 November 2017 (UTC)

Grouping descendants (by borrowing) by language family[edit]

It has come to my attention that this habit that I feel improves readability may be more controversial than I presumed, because the reader might interpret it as the word being borrowed into a common ancestor of the family.

To give an example, here's an example from *buka:

Here's the alphabetical ordering for comparison:

I think that parsing meaningful information from the list in this form is much harder, am I alone in this? Crom daba (talk) 22:35, 5 November 2017 (UTC)

I agree. I like the language family organization better, but it is potentially ambiguous as descendants lists in Reconstruction entries use family names as a proxy for proto-languages. — Eru·tuon 00:45, 6 November 2017 (UTC)
We could change that. —Rua (mew) 00:46, 6 November 2017 (UTC)
I agree. — Ungoliant (falai) 16:48, 13 November 2017 (UTC)

chinese templates[edit]

Templates like {{Chinese-numbers}} could offer the pronunciation right under the characters (BTW, if sb. please would show me where one can add such info., I'll be so grateful). Their category page could also show the pronunciation since there're few items in them (I volunteer to do it manually, yet I'd need some guidelines on how to proceed).

Secondly, other templates such as {{list:days_of_the_week/zh}} are not displayed as an expandable box with translations, which worsens the user experience. --Backinstadiums (talk) 11:43, 6 November 2017 (UTC)

I believe the latter is by design. None of the list templates offer translations. —suzukaze (tc) 17:17, 6 November 2017 (UTC)
@Suzukaze-c: Is there any specific reason why the second design has been chosen? Can list templates start to show translations? What about pronunciations? --Backinstadiums (talk) 19:06, 6 November 2017 (UTC)

The Community Wishlist Survey 2017[edit]

Hey everyone,

The Community Wishlist Survey is the process when the Wikimedia communities decide what the Wikimedia Foundation Community Tech should work on over the next year.

The Community Tech team is focused on tools for experienced Wikimedia editors. You can post technical proposals from now until November 20. The communities will vote on the proposals between November 28 and December 12. You can read more on the 2017 wishlist survey page. /Johan (WMF) (talk) 20:17, 6 November 2017 (UTC)

Yeah! Go for thousand of proposals! I am convinced none of them will be picked by the Community Tech, but they may inspire a dev or a session at a future hackathon...or at least a dozen of proposals may become a signal for the Wikimedia Foundation that Wiktionaries do exist and deserve some attention. So please, express your wishes! Face-smile.svg Noé 09:05, 8 November 2017 (UTC)
There's a section specifically for Wiktionary proposals at meta:2017 Community Wishlist Survey/Wiktionary. --Yair rand (talk) 18:51, 8 November 2017 (UTC)

Annotating the first English–Navajo dictionary[edit]

https://www.newyorker.com/culture/personal-history/annotating-the-first-page-of-the-first-navajo-english-dictionaryJustin (koavf)TCM 21:13, 7 November 2017 (UTC)

paywall :( --2A02:2788:A4:F44:39D4:48CB:D128:F4DE 21:19, 7 November 2017 (UTC)
I don't see one. —Justin (koavf)TCM 21:51, 7 November 2017 (UTC)

Category:Metaphors by language[edit]

These categories are currently empty. Meanwhile, the label {{lb|metaphorically}} automatically redirects to {{lb|figuratively}}, but we have no CAT:Terms used figuratively by language or CAT:Terms with figurative senses by language. Should we create one of these and delete CAT:Metaphors, or start using it? --Barytonesis (talk) 23:39, 7 November 2017 (UTC)


I created Appendix:Fiction/Films with a few fictional terms used in films. --Daniel Carrero (talk) 21:52, 9 November 2017 (UTC)

Oh thanks!! Equinox 23:20, 9 November 2017 (UTC)
You're welcome. Although I seem to remember that you don't like when I create appendices of works of fiction, so maybe there's a chance you're being sarcastic. --Daniel Carrero (talk) 23:23, 9 November 2017 (UTC)
lol Equinox 23:26, 9 November 2017 (UTC)
rsrs --Daniel Carrero (talk) 23:27, 9 November 2017 (UTC)
lol Equinox 23:29, 9 November 2017 (UTC)

When a city and a province/state/subdivision share a name[edit]

In the Netherlands, two provinces, Groningen and Utrecht, have cities in them by the same name. The cities of course came first, and are the usual referent of these names; the provinces were named after the cities. But what order should the definitions be in? Since the city is the most common sense, it should come first. However, the city is defined as being in the province of the same name, which hasn't been defined yet. So the city definition depends on the province definition. How should this be handled? —Rua (mew) 20:30, 10 November 2017 (UTC)

A map would give an ostensive definition of both (or all three) that surpasses the kind of verbal definition in those entries. A good verbal definition of the city wouldn't reference the province. The etymology or {{defdate}} (together with basic common sense on the part of the user) could address which definition came first. DCDuring (talk) 21:14, 10 November 2017 (UTC)
I guess the province should be listed last: A province in the Netherlands named after the city / capital ? DonnanZ (talk) 00:09, 12 November 2017 (UTC)
  • Just in passing…"Since the city is the most common sense, it should come first." – that isn't policy AFAIK, and I for one am dead against it (in favour of historical ordering). Ƿidsiþ 08:11, 16 November 2017 (UTC)
    • The city is also the oldest sense, so the point is moot. But the oldest sense should definitely not come first by default. Do we really want entries to start with a bunch of obsolete senses before getting to the ones that really matter? I would rather have the most important sense first, the one that is most likely the one intended by the user. —Rua (mew) 15:13, 16 November 2017 (UTC)
      • "Do we really want entries to start with a bunch of obsolete senses before getting to the ones that really matter?" I do, since for me those are the ones that matter. It also make the development of senses much more obvious; otherwise it's hard to understand the connection between wildly different senses of a word that has many definitions. It's also not clear to me how you will determine which sense is most "important" in a word like set. But this is a discussion that should be pursued elsewhere; the only point to make now is that we do not have an agreed policy on the matter. Ƿidsiþ 15:50, 16 November 2017 (UTC)

French IPA pronunciation - express markup vs. autotemplate[edit]

Is it preferable to replace express IPA markup with autotemplate, like in diff?

Thus, replace {{IPA|/e.zɔ.te.ʁik/|lang=fr}} with {{fr-IPA}}.

--Dan Polansky (talk) 22:02, 10 November 2017 (UTC)

I don't have a problem with it, if the template generates the right output. —Rua (mew) 22:51, 10 November 2017 (UTC)
If the backend module is stable and well tested I am fine with it. DTLHS (talk) 01:17, 11 November 2017 (UTC)
So am I. I've seen a bunch of these replacements over the last several weeks and they always seem to give the right results. It is possible to give a phonetic respelling in |1= for words whose pronunciation is not predictable from the spelling. —Aɴɢʀ (talk) 08:12, 11 November 2017 (UTC)
More importantly: with well over 5,000 edits over 10 days at rates up to 8 per minute, this looks like an unauthorized bot. I've blocked them accordingly. Chuck Entz (talk) 23:29, 11 November 2017 (UTC)
Well, if you're referring to User:, it's not a bot. Just a human who edits fast. Please don't block them. They are useful. --Spreaderofwords (talk) 15:49, 13 November 2017 (UTC)

Characters in the same phonetic series (Zhengzhang, 2003)[edit]

Could sb. please add how the info. "Characters in the same phonetic series (Zhengzhang, 2003)" can be used for language learning purposes? Thanks --Backinstadiums (talk) 20:52, 11 November 2017 (UTC)

It would help you understand how the characters were coined in the first place, I hope. Wyang (talk) 21:12, 11 November 2017 (UTC)
@Wyang: could the rest of reconstructions be added as well? --Backinstadiums (talk) 15:30, 12 November 2017 (UTC)
@Backinstadiums I don't have the data, unfortunately. Someone needs to key in the data manually or extract them from somewhere reliable. Wyang (talk) 07:38, 14 November 2017 (UTC)

Changes to the global ban policy[edit]

Hello. Some changes to the community global ban policy have been proposed. Your comments are welcome at m:Requests for comment/Improvement of global ban policy. Please translate this message to your language, if needed. Cordially. Matiia (Matiia) 00:34, 12 November 2017 (UTC)
On Meta, I posted my oppose since the change in wording makes it possible to globally ban someone based on only two bans on Wikimedia projects even if those bans are on projects ruled by small cliques without transparent processes. --Dan Polansky (talk) 11:28, 12 November 2017 (UTC)

Vote: Placing Wikidata ID in sense ID of proper nouns[edit]

FYI, I created Wiktionary:Votes/2017-11/Placing Wikidata ID in sense ID of proper nouns.

Let us postpone the vote as much as discussion requires, if at all. --Dan Polansky (talk) 09:30, 12 November 2017 (UTC)

Why is this just about proper nouns? Shouldn't we generalize this? - Jberkel (talk) 12:04, 13 November 2017 (UTC)
@Jberkel: You may already know this, but proper nouns seem to be a special case. Wikidata is for concepts, not words. This is OK for proper nouns. Wikidata is expected to have a specific data item for each place, like d:Q29 = Spain. But things get tricky with some other parts of speech. Like, d:Q3133 is green, but would we use that for the noun or adjective? d:Q31920 is the concept of swimming, so would we add that ID for multiple senses of "swim" and "swimming"? In any event, proper nouns may get the same ID in multiple entries, but the sense should be the same: d:Q30 means United States of America and is available for use in USA, US, United States of America, United States, etc. The same ID can be used for other languages, like in entry Estados Unidos, which means "United States" in Portuguese. Still, the sense is the same.
Let me know if there are any exceptions or problems I did not think yet.
I would be fine with keeping the vote for proper nouns only. Or maybe creating 2 options: proper nouns, and everything else. But the "everything else" part was not properly discussed yet, so maybe I would oppose it. I support placing the Wikidata ID as the sense ID of proper nouns.
It is important to note that some Wikidata ID senses are already being added to proper noun entries. I assume this is why @Dan Polansky created this vote. This Wikidata ID project was discussed at least a couple of times (discussion links are in the vote). This project was never voted yet. --Daniel Carrero (talk) 13:50, 14 November 2017 (UTC)
OK, but I can think of many cases where Wikidata ids are also applicable for “normal” nouns / senses, if they refer to specific concepts. As an example, class can refer to a class in Object Oriented Programming: this can be mapped to d:Q4479242. If class refers to a mathematical class, there's d:Q217594. etc.
Of course we shouldn't add Wikidata ids randomly to any sense, but really just to those where there is a good match and where it is necessary to distinguish multiple senses of a word. For proper nouns this is less controversial but also less useful (ok, the classic counter example here would probably be “Paris, Texas”). – Jberkel (talk) 17:02, 14 November 2017 (UTC)

Browser extension to label a selected chinese word[edit]

Since I am starting to learn Chinese, instead of sitting down and manually edit entries systematically, I thought about doing it on the go, checking whenever they show up in an online text.

After selecting a chinese word, I need an extension to show to which of four groups of words, named by numbers 1 to 4, that word belongs; otherwise, nothing should pop up if the selected word does not belong to any of the four groups. The four groups of chinese words are in this list, and the label to appear is the "level number" of each category.

Regarding the apperance of the number (typeface, font, place etc.) any suggestions are welcome. @Atitarev --[[--Backinstadiums (talk) 11:01, 12 November 2017 (UTC)User:Backinstadiums|Backinstadiums]] (talk) 09:41, 12 November 2017 (UTC)

If you are interested in a general cursor translation tool for Chinese, you can try Lingoes (for Windows) or the in-built Mac dictionary. Both provide decent results for simplified Chinese at least. Wyang (talk) 09:47, 12 November 2017 (UTC)
@Wyang: That's not what I meant. Please check this thread. --Backinstadiums (talk) 09:54, 12 November 2017 (UTC)
That discussion is a bit hard to follow, I still don't quite understand your request or question. Do you mean editing Wiktionary pages themselves to include the levels, or ...? Wyang (talk) 09:58, 12 November 2017 (UTC)
@Wyang: A browser extension so that any user can select the headword of a Chinese entry which hasn't been indexed to an HSK level category yet, and check which one it belongs to, or whether it doesn't belong to any, thereby collectively editing them. --Backinstadiums (talk) 10:09, 12 November 2017 (UTC)
(edit conflict) @Wyang: User:Backinstadiums must be talking about a pop-up dictionary similar to Perapera Chinese Firefox or Chrome, which I use (there are also Japanese and Korean versions). Absolutely unreasonable requests. We are not producing browser extensions! --Anatoli T. (обсудить/вклад) 10:12, 12 November 2017 (UTC)
If Anatoli's right, then my first reply of this thread would apply - there are already mature softwares and extensions that do that. If the aim is to add the appropriate category to all HSK words, manually adding the category to entries missing it would be easier to achieve and much more efficient. Wyang (talk) 10:18, 12 November 2017 (UTC)
@Wyang: "If the aim is to add the appropriate category to all HSK words" Correct, that's the goal "manually adding the category to entries missing it would be easier to achieve and much more efficient" This is false, for the fact is that it's not done yet. I just want to engage with the thousands of users that monthly use Wiktionary. Creating a page of tasks or projects to carry out would really help, similar to https://commons.wikimedia.org/wiki/Commons_talk:Stroke_Order_Project. -- Backinstadiums (talk) 11:01, 12 November 2017 (UTC)

Topics of discussion[edit]

I'm new to Wiktionary, regarding topics, and this is continuing from above BP discussion, what topics are there besides 1, improving Wiktionary, 2, word etymologies, 3, policy topics, 4, discussion about discussion.. -Aision (talk) 03:13, 13 November 2017 (UTC)

Occasionally we slag off another that we find disagreeable. And every now and then we tell jokes or play a wiki-game. --Spreaderofwords (talk) 15:39, 13 November 2017 (UTC)

Defining affixes[edit]

I've seen that Equinox (talkcontribs) has been changing a lot of affix definitions to be less descriptive and more gloss-like; for instance, the definition of viscero- used to say "Forming compound words related to viscera", and it now reads just "viscera". Ditto for many dozens of similar affixes on my watchlist. Is this in accordance with some policy that I missed? It seems strange to me, because "viscero-" doesn't really mean "viscera", otherwise you'd be able to say "I removed the animal's viscero-". I understand that descriptive definitions are something of a grey area, but in the case of affixes they seem justifiable to me. Ƿidsiþ 09:57, 13 November 2017 (UTC)

Mh, yes, I preferred the old version. I've reverted back to it and added {{non-gloss}}. --Barytonesis (talk) 10:05, 13 November 2017 (UTC)
Well OK, but given how many pages this involves, I'd rather work out some consensus on the issue rather than changing one or two here and there. Ƿidsiþ 11:58, 13 November 2017 (UTC)
I concur as well. —Μετάknowledgediscuss/deeds 19:15, 13 November 2017 (UTC)
Hi! I've been doing this because I think that sense lines should tell us what is meant by the prefix (or suffix etc.). We don't define apple as "MEANING A SORT OF FRUIT", we just say what it means. So, to me, we should equally define a *fix like "-phobia" as meaning "fear" and not as "MEANING FEAR" because that isn't a definition per se. I seem to be in a minority here but let us talk a bit more. Why should pre/suffixes be defined in a weird way that we would revert in a second if we saw them for normal nouns or adjectives? Equinox 23:34, 13 November 2017 (UTC)
The quick-and-dirty fix is to put the old n-g template around some text that says "meaning XYZ" but I really think that's dodging the issue. Surely it's reasonable to say (for example) that the prefix "mega-" means "million", without spazzing too much. Yet would we write "MEANS A MILLION" at the capital symbol M, rather than merely writing "million"? Look at the SI units. Equinox 23:40, 13 November 2017 (UTC)
I sort of want to ask, if we need to write that a suffix -xx is used in "forming compound words", well what else would it do? Suffixes by their very nature form compound words. When I delete that stuff I feel like I'm deleting the bracketed part from "dog, n. NOUN [THIS IS A WORD AND A NOUN] an animal that barks". hissss. Equinox 23:45, 13 November 2017 (UTC)
I understand the concern but I think it makes things less clear. "An animal that barks" is already a (compound) noun, and "move quickly" for "run" is already a (compound) verb, but the same is not true of your affix definitions. It's a bit like interjections – we define words like sorry by saying that they "express regret" or similar, which is metadefinitional in the same way. I don't know exactly how it should be codified, but the point is that I think for most people, saying that viscero- means "viscera" is not sufficient, even given the stated part of speech. Ƿidsiþ 07:39, 14 November 2017 (UTC)
Perhaps we shouldn't give them a definition at all, but just redirect to the plain word somehow? --Barytonesis (talk) 10:46, 14 November 2017 (UTC)
The Equinox version has its charm, for the reason given by Equinox: "Forming compound words concerning viscera" does not tell me anything that I do not learn from "viscera". --Dan Polansky (talk) 18:05, 14 November 2017 (UTC)
https://www.merriam-webster.com/dictionary/cardio- does basically what Equinox does; so does AHD[1]; Macmillan has "relating to the heart"[2]. --Dan Polansky (talk) 18:08, 14 November 2017 (UTC)

Independent Synonyms section, or {{synonyms}} under each relevant sense?[edit]

I've noticed some use of {{synonyms}} just after relevant senses, replacing the independent ====Synonyms==== section, as in this edit to the 青空 (aozora) entry. I don't see anything relevant at Wiktionary:Entry_layout#Synonyms. Is this use of {{synonyms}} the expected practice going forward?

Curious, ‑‑ Eiríkr Útlendi │Tala við mig 17:29, 13 November 2017 (UTC)

I don't think it has widespread consensus yet, but I prefer it because it's much easier to associate synonyms with specific senses that way. When they're in a separate ====Synonyms==== section, there's a risk that a sense will get deleted, or a sense will be split into two, and then the synonyms listed in a separate section get stranded. When they're right there under the sense, people are more likely to remember to move them at the same time. They're also easier for users to find when they're right there. —Aɴɢʀ (talk) 17:52, 13 November 2017 (UTC)
One (current) problem with {{syn}} / {{synonyms}} is that it's not possible to put any qualifiers or notes along with the synonyms such as "rare". DTLHS (talk) 17:56, 13 November 2017 (UTC)
That problem could be (and should be) solved — each synonym can have an alternative display with alt1= etc, so they could have qual1= etc just as easily. —Μετάknowledgediscuss/deeds 19:14, 13 November 2017 (UTC)
I use {{syn|pt|[[word|words]] {{q|qualifier}}}}. — Ungoliant (falai) 19:23, 13 November 2017 (UTC)
Functional, but ick -- that's starting to look dangerously like Perl.  :-P ‑‑ Eiríkr Útlendi │Tala við mig 19:41, 13 November 2017 (UTC)
Yeah, it’s not pretty. Still, I think it’s better than using qual1=, qual2=, alt1=, etc., since that would generate incorrect content whenever someone moves, removes or adds synonyms without paying attention to the other parameters.
Another possibility is using regular parenthees and having the module format it like {{q}}, but that would remove the distinction between qualifiers and optional particles (e.g., deixar has a synonym largar (de), where deixar X is synonymous with largar X and largar de X). — Ungoliant (falai) 15:19, 14 November 2017 (UTC)
  • Ideally, synonyms, translations and other sense-specific information would all come in little drop-down boxes on the definition lines, much as citations do now. @Ruakh raised this issue years ago and suggested some technical ways to make it work, but it never got anywhere (mainly due to general apathy, I think – so one really objected to it). Ƿidsiþ 10:35, 14 November 2017 (UTC)
Yes, there should be drop-down boxes possible for semantic relations. For example I can’t make the entry graph very pleasing without it. Technically it would be fine if I could just take the hyponym table that is now in a separate section and put it (minus the terms belonging to other senses) with few changes under the sense it belongs to. Maybe what we need are wrappers {{hypowrap}} and so on in which we can insert the tables, but as I see for at least that table in graph that does not have multiple columns it would be fine to have parameters, like table=yes or hidden=yes, in the semantic relations templates because it is quite easy to convert that table for {{hypo}}, only that under a sense I require a hidden listing instead of a full listing without user interaction. Also, why don’t I see a template {{mero}}, {{holo}}, {{coordinate}} while there is {{syn}}, {{hypo}}, {{hyper}}, {{ant}}?
In fact, the same can be said about translations. We would then need a wrapper which the user could click for each sense to see semantic relations and translations. Or that table would have smart mathematics and hide translations always unless clicked (would be good for learners) and show semantic relations in so far as they do not have excessive length:
1. to turn off, switch off
Antonyms: anstellen, anmachen, anschalten, einschalten, (click to see more)
(click to see translations) (if it is an English sense) Palaestrator verborum (loquier) 18:33, 14 November 2017 (UTC)
One problem I have with putting more things directly under definitions is that it makes it harder to modify or combine English senses. This is especially relevant for translations since an English editor probably will not know all the languages under a particular sense. This problem does not occur with the current gloss system, although translation boxes may become out of sync with definitions. DTLHS (talk) 18:38, 14 November 2017 (UTC)
It does in fact occur currently, except that people ignore the translations when merging senses, so that they go out of sync. Putting them under senses would just make it harder to ignore this problem. —Rua (mew) 18:44, 14 November 2017 (UTC)
If an English sense is modified and the corresponding translation box is not, those translations are still valid since they have an independent gloss that they refer to. DTLHS (talk) 18:46, 14 November 2017 (UTC)
However one might still have the current translation headers. Translation sections sometimes need to be more differentiated than the English glosses. For example I added under interference a specific legalese sense “intrusion into the scope of protection of a guaranteed right” without finding it necessary to add any English gloss, as the sense is included by the most general definition while other languages have already a distinction there. For the inner-language semantic relations, it would help to keep the senses in sync with the synonyms and other semantic relations if these are directly under sense, as else editors are tempted to underspecify to which senses the synonyms belong if they do it in special sections, and, what Rua said, it is a gentle push to keep things in sync if the semantic relations and translations are under the senses. Palaestrator verborum (loquier) 18:52, 14 November 2017 (UTC)
Also one should be more conscious about when it can actually happen that senses get merged, modified, or added.
  1. If senses are added, there is no problem with the translations and semantic relations. There are none for the new sense and the older specified ones are not wrong.
  2. If you combine senses, it is, as I understand it, because it has been foolish in the first place to differentiate, so there can be no distinction discerned in two translation sections either. There are many such English definition pages, and I would like to ask how a translator shall distinguish all the allegedly different eleven concepts of understanding currently listed at enforce – it is hard to relate a table in this lemma to a gloss, and translators have already forgot the sense which they actually want to translate when they have chosen a table, and one doubts the essentiality of the differences between the glosses, this is why there are almost no translations, unlike on enforcement. That article can hardly be made worse by adding the translations under glosses and also not further become worse by further merges, as long as and because the distinctions in the translations tables are incomprehensible. Actually having bilingual dictionaries at hand for some of the translation targets should tell you if it is really necessary to distinguish so many meanings. If in doubt, delete the translation tables because they are insufficient and unhealable to allow the births of new ones – it is better than letting confusing, poorly hedged glosses stay.
  3. If you modify senses, it is because you want to make the senses clearer: In those cases the translations will continue being correct and in the future it will be easier to translate because the sense to be translated is more clear for the translator. If you modify the sense because the former sense was just plain wrong and not extant for the lemma, which is highly unlikely, the translations can be deleted because they are misplaced. Palaestrator verborum (loquier) 19:25, 14 November 2017 (UTC)
Very true, but there's a fourth case: splitting senses. —Rua (mew) 19:37, 14 November 2017 (UTC)
Well, I presumed that the senses are somehow monadic, so splitting would be modifying (specifying) + adding. Because how wretched must one be to have actually two separate meanings as one gloss? At the latest the translator will split up such a gloss. It’s the whole problem of unreadable pages and translations conflicting glosses if the editors do not understand that the fact that they can describe meanings in multiple glosses does not imply that they are dealing with that many separate meanings. By talking more one does not necessarily make more statements, sometimes one clarifies, sometimes one even obsfuscates by hiding the simple. For the lovers of examples, a complete fail of the described kind has happened at نِسْبَة (nisba) until fixed today where there was a list of glosses with one word each gloss as if the English words had no manifold meaning themselves. The skilled editor does not just list every possible rewording but distinguishes the meanings in relation opposite to each other and specializes them as feasible – with means of vocabulary or layout – for the reader to understand given sentences that contain the word; sometimes the translation tables are desired to be even more special than the meaning has been presented without them, but listing the semantic relations and translations for each gloss helps to distinguish independently of this. There is in the case of enforce one abstract meaning that, as I admit, needs at least two main glosses to describe (mainly force for the increase of the effect of something being added and force being just applied on something or someone for a certain effect, as I see before now actually regrouping the enforce lemma content), but not eleven. Palaestrator verborum (loquier) 23:16, 14 November 2017 (UTC)
I like separate synonym sections as mandated by WT:EL, but there was a recent poll showing many people like the new format. --Dan Polansky (talk) 07:28, 17 November 2017 (UTC)
The poll is at Wiktionary:Beer_parlour/2017/May#Poll: putting "nyms" directly under definition lines. It shows a 2/3-supermajority support placing -nyms (including synonyms) directly under definitions. --Dan Polansky (talk) 07:44, 17 November 2017 (UTC)
I have a stylistic objection, currently "Synonyms:" is so big and bold that it overshadows the definition line above it which should be more important. Crom daba (talk) 15:12, 22 November 2017 (UTC)
I agree with Crom daba. Plus, I can’t see why synonyms should be linked. — Ungoliant (falai) 15:26, 22 November 2017 (UTC)
I'd like to point out that the poll shows there is no consensus to put them under definitions if they are not hidden like quotations, which is not currently the case. There is only majority support for having them under definitions AND hidden. Andrew Sheedy (talk) 02:26, 4 December 2017 (UTC)
Nobody has bothered to make them hidden yet. —Rua (mew) 11:58, 4 December 2017 (UTC)
I express that I also have that stylistic objection – Synonyms should be somewhat greyed out, it is too obtrusive. Else I do not care if it is hidden or not. Maybe the best is a display on hovering, as with the CSS pseudo-class :hover, to introduce a third option. @Rua Palaestrator verborum (loquier) 16:05, 4 December 2017 (UTC)
Hiding something until the user happens to place their mouse in that location is terrible discoverability, and terrible usability. How would anyone know to mouse-over? ‑‑ Eiríkr Útlendi │Tala við mig 18:20, 6 December 2017 (UTC)
@Eirikr: Don't you like treasure hunts? --Barytonesis (talk) 18:50, 6 December 2017 (UTC)
Never mind platforms that don't even have a mouse cursor. —Rua (mew) 18:51, 6 December 2017 (UTC)

Hyphen at the end of a proto-language word[edit]

What is the meaning of the hyphen at the end of a proto-language word? For example, if the source uses *pura without a hyphen, can it be changed to *pura-? This change was made at the Hungarian verb fúr and I wonder if it is valid. Thanks. --Panda10 (talk) 18:11, 13 November 2017 (UTC)

It's how the lemma form has been chosen for Proto-Uralic verbs. Verb lemmas are the stem, noun/adjective lemmas are the nominative singular. —Rua (mew) 18:59, 13 November 2017 (UTC)

Proposal: delete all Latin script letter senses from all languages except Translingual[edit]

I suggest deleting all Latin script letter senses from all languages except Translingual. The "letter name" senses like "bee" = "name of letter B" may be kept.

Example: diff. (I just edited the first few language sections)

If we keep the current format without changes and add a language section for each language that uses "a", it will become basically infinite, and useless. It gets increasingly hard to find the non-letter senses.

I know I have proposed different things in the past concerning letters. I've been trying to figure out what to do with them.

Pronunciation can be found in appendices like Appendix:English pronunciation. The appendices may even be expanded with detailed info if needed.

Feel free to propose different things or say if there's any problem with this idea.

This is a major proposal, so if people like this idea, I'm sure it would need to be voted at some point. I'm not in a hurry. --Daniel Carrero (talk) 23:08, 13 November 2017 (UTC)

Why only Latin? The page А is also huge. DTLHS (talk) 23:12, 13 November 2017 (UTC)
I support this, but for other scripts as well. --Barytonesis (talk) 23:29, 13 November 2017 (UTC)
What about unusual or maybe even non-Translingual letters? For example, are there other languages than Gregorian using Gregorian letters like , or languages other than Cherokee using Cherokee letters like ? If there aren't, then properly speaking it's not translingual.
What about inflection? {{en-letter|upper=A|lower=a}} also produces "plural a's" which is an English plural. Well, it might belong into a noun and not a letter section, but there wouldn't be much gain in removing the letter section and adding new noun sections for inflection.
- 00:05, 14 November 2017 (UTC)
Support, though some solution for inflection does need to be found. I definitely agree that these pages are so huge, and have the potential to get so much huger, that they are useless. Moreover, letters themselves don't convey meaning, they just stand for themselves just like any mention of a word stands for the word itself, so they don't even meet CFI. Yes, letters can used in an ordinal fashion, but our current entries don't make any mention of this so there is no loss in that regard. —Rua (mew) 00:18, 14 November 2017 (UTC)
Oppose. I find pronunciation information for individual languages very helpful, especially for the actual name of the letter (how else could you figure out how to spell in another language?). As an alternate, would it be possible to make the Translingual page the default, and move most language-specific information on the letter to an appendix, or break it up into more than one mainspace entry somehow (with links from the main entry), or have two versions of the page? I very badly don't want to lose all the pronunciation information, so I think simply stripping the entries down is a bad idea. Andrew Sheedy (talk) 01:31, 14 November 2017 (UTC)
"Pronunciation can be found in appendices like Appendix:English pronunciation." ;) —suzukaze (tc) 01:54, 14 November 2017 (UTC)
Does that appendix explain that the letter A is pronounced /eɪ/? I can't see it. Ƿidsiþ 08:57, 14 November 2017 (UTC)
@Widsith: No it doesn't, but see my suggestion below. —Aɴɢʀ (talk) 10:08, 14 November 2017 (UTC)
Support, and for non-Latin scripts too. —suzukaze (tc) 01:54, 14 November 2017 (UTC)
  • Support and for non-Latin scripts too. However, although "Pronunciation can be found in appendices like Appendix:English pronunciation" as Suzukaze-c points out, those appendices do not usually contain spelling-to-pronunciation rules. Perhaps we could have separate appendices for those, e.g. Appendix:English reading rules (or a better name?) which tells us that ⟨a⟩ is most often pronounced /æ/, /eɪ/, /ɑː/, and /ə/, and in what environments; ⟨b⟩ is most often pronounced /b/ but is silent at the end of a word after ⟨m⟩; and so on. —Aɴɢʀ (talk) 07:24, 14 November 2017 (UTC)
    Yeah but the point is not about how the letter is pronounced in words (that's also an issue, but one covered by appendices) – it's about what the letter is called in different languages. H is called aitch in English and ache in French; Y is called i grec in French; where will that information be? Ƿidsiþ 10:31, 14 November 2017 (UTC)
    Letter names can be found in appendices too, but maybe not the same as the pronunciation appendices. Appendix:Romanian alphabet, Appendix:Letters/Spanish and other appendices contain lists or tables of letter names. Maybe some of these appendices could be renamed and revised to use a more consistent format, but this is a wiki. --Daniel Carrero (talk) 13:17, 14 November 2017 (UTC)
  • Support moving language-specific information about letters (not letter names!) to appendices, including non-Latin scripts. — Ungoliant (falai) 13:05, 14 November 2017 (UTC)
  • Support also for all other scripts that can be covered by Appendix:Writing systems and alphabets (I do not make any statement about Chinese characters) – it will be easier to find non-letter meanings and easier to compare writing systems. The letter meanings can be outsourced to an appendix for each graph/glyph which is linked by {{also}} in the namespace, having in the case of a for example the name Appendix:Graph/a or even in a new namespace Graph:a. If an entry can only be a graph and not lexical, the mainspace can redirect. Possibly for this purpose a namespace is better, as the software can habitually check for matchings in a namespace dedicated to writing system glyphs like it redirects me to أنبوبة if I type انبوبه. Appendix:Graph/َ  or Graph:َ  with fatha seem to work too, so there is no problem with diacritics? Palaestrator verborum (loquier) 14:04, 14 November 2017 (UTC)
    I think just Appendix:a would be ok too. —Rua (mew) 14:24, 14 November 2017 (UTC)
  • Support also for non-Latin scripts (except Chinese) —Aryaman (मुझसे बात करो) 16:17, 14 November 2017 (UTC)

Vote: Restricting Thesaurus to English[edit]

FYI, I created Wiktionary:Votes/pl-2017-11/Restricting Thesaurus to English.

Let us postpone the vote as much as discussion requires, if at all. --Dan Polansky (talk) 10:28, 15 November 2017 (UTC)

Comments on Recent Votes[edit]

I am curious if people feel as I do, that vote pages are often overrun with discussions and that those discussions are often tangential at best. I propose that we eliminate discussion within the vote page itself, and if someone would like to engage in some discussion concerning an individual's vote that they do so on the vote talk page. Perhaps a link to the discussion on the talk page can be placed on the voting page, but protracted conversations within the vote only obfuscate the results. I am only referring to secondary comments; a comment left by the voter to clarify or justify their vote is, of course, perfectly fine.
Secondly, a number of times recently there have been comments to the effect that votes should include a written rationale, or requests that individuals justify their votes in some way. This is inappropriate. Any member of the community is eligible to vote, and they can vote how they please for whatever reasons they please; if they wish to share their rationale that is their prerogative. Requesting clarification about a vote is acceptable (e.g. "if the proposal had been x instead of y would you have voted differently") but demanding justification is completely out of line. - TheDaveRoss 15:33, 15 November 2017 (UTC)

protracted conversations within the vote only obfuscate the results – well, that is why the three voting possibilities have colored badges so one can count through. And technically the “result” has only to be counted through at the end by one person. Isn’t it then actually good that the result is obfuscated? It diminishes group pressure and enables free voting because one does not see such heaps of votes.
Also I have suggested that some kind of hedge template is created that demarcates digressions from the topic and maybe needs a click for drop-down because often nobody does want to move or one does not know whither exactly to move the discussions. Palaestrator verborum (loquier) 11:04, 16 November 2017 (UTC)
Oppose. First of all, about: "demanding justification is completely out of line". I'm not sure about that. I would support having a different voting system where unjustified votes don't count. (except maybe votes for bots and admins, etc.) But I'm fine with the current system, anyway.
More importantly, I disagree with what has been proposed. I would prefer still freely allowing discussion in vote pages. Some written rationales are more likely than others to attract further comments from other people, and thus discussions begin. I think that's fine. In fact, I consider the in-vote discussions even more important than the actual simple count of "Support"/"Oppose"/"Abstain". The discussions should encourage us to think and justify stuff. If someone says "I'm voting because of reason X", it would most likely be an avoidable hassle to go to the talk page to discuss about reason X, if the alternative is replying right then and there in the vote page itself.
When someone adds the first comment to someone's rationale, it's not clear yet if this will become an actual discussion. It's not clear if someone else will reply. I don't suppose we're expected to create separate sections in the talk page for each little comment when we don't know if this will become an actual discussion, right?
Interestingly, we have this rule in WT:Voting policy: "Debate is welcome on these pages." But this rule was never voted itself. --Daniel Carrero (talk) 12:30, 16 November 2017 (UTC)
@Daniel Carrero Part of the reason I dislike discussions within the vote is that it indicates that the vote was premature, and there was not adequate discussion prior to its start. Votes should not be islands, they should be the final step in a process. The commentary often takes forms which I find distasteful, such as pressure to change one's vote, casting aspersions on the subject of the vote or the voter themselves, or other such nonsense. Why is having the discussion within the vote so important? Re whether or not a comment will lead to a discussion, I think any comment beyond that of the voter constitutes discussion, so every time it happens it is the case. - TheDaveRoss 14:08, 16 November 2017 (UTC)
I don't think discussions in the vote are (necessarily) an indication that the vote is premature. I think we can't ever say for sure that the discussions are over. If some idea is discussed by many people and has close to 100% approval before any vote starts, this would indicate that the issue is so noncontroversial that maybe a vote is not even needed. --Daniel Carrero (talk) 14:34, 16 November 2017 (UTC)
Approval and sufficient discussion are not the same thing, I am perfectly fine with a vote being run for a controversial topic. But if people feel the need to make arguments within the vote itself it is an obvious indicator that they have not had sufficient opportunity to do so ahead of time. - TheDaveRoss 15:07, 16 November 2017 (UTC)
I oppose removing discussions from the vote page. I like the idea of show-hide concealment, perhaps beginning a short time after the last comment in the thread or when the thread is 'too' long. DCDuring (talk) 13:08, 16 November 2017 (UTC)
I support using show-hide concealment in some cases too. --Daniel Carrero (talk) 13:09, 16 November 2017 (UTC)
@DCDuring If the consensus is that discussions within votes are appropriate, then I would support hiding them as well. - TheDaveRoss 14:08, 16 November 2017 (UTC)
  • I oppose removing, limiting or hiding discussions from the vote page. These discussions are a great feature. Votes should be understood to be votes/requests for comment. If votes have the potential to be "evil" to an extent, these discussions directly on the vote page make them less so. I think we should invite more discussion directly on the vote page. The discussions do not "obfuscate the results" since we use icons and vote counting. As for "demanding justification is completely out of line", I think the opposite: we should do more to encourage people to provide rationales and make votes more like requests for comments and discussions. The idea that enough people come to discuss a proposal before the vote starts is unrealistic; it is the vote that forces people to pay attention to a proposal lest it passes. --Dan Polansky (talk) 07:24, 17 November 2017 (UTC)
    That said, it may be a good practice to continue the discussion on the vote talk page once it becomes more protracted. --Dan Polansky (talk) 17:15, 17 November 2017 (UTC)
    I also oppose, for pretty much identical reasons to Dan. —Μετάknowledgediscuss/deeds 17:16, 17 November 2017 (UTC)
    @Dan, I would consider the sentiment of your final sentence to be an abuse of the voting system, not a feature. - TheDaveRoss 20:15, 17 November 2017 (UTC)
    @TheDaveRoss: I read that sentence as a simple statement of fact, not an endorsement of starting votes purely to force people to think about things. — Eru·tuon 22:40, 20 November 2017 (UTC)
This made me start vaguely wondering if a secret ballot (with names/votes posted at conclusion of vote only) would be an improvement over a public voting page. (I doubt it!) It wouldn't stop people from making comments, anyway; would just prevent voting based on how others have voted, which I bet also happens. Equinox 16:49, 17 November 2017 (UTC)
I like to see how others have voted. There are some editors I trust a great deal, and I do sometimes vote oppositely to them, but I am sure to think it through more carefully first. —Μετάknowledgediscuss/deeds 21:01, 27 November 2017 (UTC)

stroke order exceptions within the standard guidelines[edit]

Where could I find a dabase of exceptions of the stroke order to be expected following the standard guidelines? Input methods' lists of input sequences could be used for this issue, which is of great lexicographical value --Backinstadiums (talk) 09:34, 19 November 2017 (UTC)

Request translations of wikipedia pages related to languages[edit]

After jumping from page to page for an hour, I still do not know how to request a translation. The article I'd like to have an English version of, among others, is https://zh.wikipedia.org/wiki/%E5%90%88%E6%96%87. Would it be possible to request the translation of a whole "category"? Thanks --Backinstadiums (talk) 13:49, 20 November 2017 (UTC)

We have WT:TRREQ, but requesting translation of whole Wikipedia articles is asking an awful lot. Of course, you could enter the URL of the Wikipedia page into Google Translate, but for the URL you gave the result is pretty useless (Chinese speakers may find it good for a laugh, though). Chuck Entz (talk) 14:25, 20 November 2017 (UTC)
Indeed, and it starts right from the title... lol! Wyang (talk) 14:28, 20 November 2017 (UTC)
@Chuck Entz: I meant there used to be a page for this in wikipedia, neamely https://en.wikipedia.org/wiki/Category:Translation_Request, yet it's inactive now, and cannot find the current formal procedure --Backinstadiums (talk) 14:58, 20 November 2017 (UTC)
@Backinstadiums: Did you see w:Wikipedia:Translation#Requesting a translation from a foreign language to English? —Aɴɢʀ (talk) 16:38, 20 November 2017 (UTC)
@Angr: Yes, and still do not know where to post... it's easier in Wiktionary. I cannot seem to find the exact final thread to request it. I think those articles are highly relevant for Wiktionary as well --Backinstadiums (talk) 18:31, 20 November 2017 (UTC)

New print to pdf feature for mobile web readers[edit]

CKoerner (WMF) (talk) 22:07, 20 November 2017 (UTC)

Noto font family[edit]

Google has designed and released Noto Sans and Noto Serif (freely available) that can handle a large number of languages. Currently, Noto covers over 30 scripts, and will cover all of Unicode in the future. Noto download. Go to Noto Sans specimen to see how it looks. —Stephen (Talk) 05:31, 21 November 2017 (UTC)

Bah, still no Manichaean. Crom daba (talk) 14:23, 21 November 2017 (UTC)
I use this for everything, it's awesome. Their Devanagari serif font looks so cool and has a ton of ligatures. —AryamanA (मुझसे बात करेंयोगदान) 00:57, 30 November 2017 (UTC)

Gender-neutral French plurals[edit]

Should we be concerned with documenting these? —Justin (koavf)TCM 18:03, 21 November 2017 (UTC)

If they're attestable, of course. —Mahāgaja (fomerly Angr) · talk 19:24, 21 November 2017 (UTC)
The · entry might need the addition of a "French > Symbol" section — again, if attestable. Equinox 19:31, 21 November 2017 (UTC)

Similarly spelled words (not alt. spellings) but somewhat related, e.g. skink and skunk[edit]

Hi, I'm not sure if this should go under "See also" but sometimes it's useful to show similarly spelled words. A majority of English speakers might know skunk but some might not remember or know skink (a type of lizard). Obviously this should be sparingly used. Thanks in advance for any advice! Facts707 (talk) 13:58, 26 November 2017 (UTC)

I don't think we should put "unrelated" stuff in the actual entry (in most cases). This kind of "did you mean...?" seems like a job for the search engine. (At present, it means you just have to click the Search button instead of the Go button; and I'm not sure how well it deals with soundalikes.) Equinox 21:31, 27 November 2017 (UTC)
Currently similar things are put under “usage notes”, which is not optimal: etymology is “not to be confused with entomology (“the study of insects”) or etiology (“the study of causes or origins”)” Palaestrator verborum (loquier) 17:04, 30 November 2017 (UTC)

Uncountable nouns under singularia tantum[edit]

The category for uncountable nouns is currently under the category of "singularia tantum". I don't think this is right for languages that do not really have grammatical number, like Chinese. Chinese still has uncountable nouns, i.e. nouns that do not take a classifier/counter, but these are not "singularia tantum". — justin(r)leung (t...) | c=› } 20:49, 27 November 2017 (UTC)

But our category structure is gem-like in the perfection of its universality. DCDuring (talk) 22:15, 27 November 2017 (UTC) and
Indeed. We categorise everything from Category:Aa: ⠁ to Category:Zz: ⠵ via Category:Furry fandom and Category:Working dogs. --Lirafafrod (talk) 22:31, 27 November 2017 (UTC)
The underlying issue would seem to be that most of the entries use {{en-noun|-}} which automatically categorizes them as uncountable nouns. I don't think many of them are. We don't seem to have a {{en-singular noun}} that parallels {{en-plural noun}}. Category:English singularia tantum needs cleanup, as it, among other things, contains words that agree with both singular and plural verbs. I've never understood why we emphasize the form of the word rather than the number of the verb that it is normally agrees with. DCDuring (talk) 18:43, 28 November 2017 (UTC)
I don't particularly like the term, it has a certain "urgh" factor, especially when there there are categories in various languages for uncountable nouns, and where nouns can be recorded as uncountable by the template used. I have eradicated it from some entries. I'm not keen on pluralia tantum either. DonnanZ (talk) 19:53, 1 December 2017 (UTC)
I don't know of any dictionary that routinely uses singulare tantum and plurale tantum. Among OneLook dictionaries only Wiktionary and WP even define them. I'd be happy to get rid of them for all English entries and categories. DCDuring (talk) 22:21, 1 December 2017 (UTC)
It's being quite pretentious actually. So as the Daleks said: "Exterminate!". DonnanZ (talk) 17:19, 4 December 2017 (UTC)
Are there uncountable pluralia tantum? If there are, then in no way do uncountable nouns belong under singularia tantum. 1990s should be a plurale tantum and uncountable (as there is no a 1990s is/was, one 1990s is/was, two 1990s are/were but only the 1990s were (historic also: are)).
It could work there other way though: Both singularia tantum and pluralia tantum could belong under uncountable. However there could also be countable pluralia tantum, e.g. litterae (sense letter) could be countable like unae litterae (one letter), duae litterae (two letters). - 17:53, 4 December 2017 (UTC)
Well, there is a template {{en-plural noun}} for English plural nouns, but I'm not sure whether it generates pluralia tantum as a category. I hope not. DonnanZ (talk) 01:04, 5 December 2017 (UTC)
Oh, it does... — justin(r)leung (t...) | c=› } 01:18, 5 December 2017 (UTC)
Looking at the first few entries that used {{en-plural noun}}, I found feet and computer graphics reported as plural nouns. Feet is not plural only in any of the definitions in the entry. Similarly for computer graphics, which is a plural of computer graphic in one sense and is a singular noun (in terms of the number of the verb for grammatical agreement) in the other senses. It would not surprise me to find that 10-20% of the entries of the category that use the template used it improperly, in whole or in part. I can't really get excited about issues like subcategorization when plain error is so common. DCDuring (talk) 02:18, 5 December 2017 (UTC)
I'm beginning to think that we should just make Category:English pluralia tantum and Category:English singularia tantum hidden so that normal users don't see all the evidence of a high rate of error. DCDuring (talk) 02:25, 5 December 2017 (UTC)
Hmm, that's a bit like sweeping the dust under the carpet. Wouldn't it be better to amend the templates and categories? DonnanZ (talk) 13:12, 5 December 2017 (UTC)

Removing Proto-North-Caucasian[edit]

Judging by Wikipedia, North-Caucasian is not a valid language grouping. This is a part of Moscow school "Sino-Caucasian" long range reconstruction which is supposed to connect Sino-Tibetan, Dravidian, North-East Caucasian, North-West Caucasian and Yeniseian into a single super family.

I understand that it's sometimes easier to just copy things from the Starling database, but I don't think we should give space to crackpot theories over here. Crom daba (talk) 15:52, 28 November 2017 (UTC)

Well, some parts of Starling are decent enough. The North-Caucasian etymologies are particularly notorious though. —AryamanA (मुझसे बात करेंयोगदान) 00:56, 30 November 2017 (UTC)
The problem is that Starling doesn't offer reconstructions on the proto-NEC level, so the editor (specifically @Vahagn Petrosyan since he seems to be the one making these) would have to know enough about NEC to excise aspects of the reconstruction formed through spurious NWC comparanda. Crom daba (talk) 13:51, 30 November 2017 (UTC)
I don't know enough about NEC to do that, but I support removing Proto-North-Caucasian. --Vahag (talk) 16:49, 30 November 2017 (UTC)
I previously thought that it would be possible to somehow maintain these reconstructions, Proto-North-Caucasian, Nostratic and so on, with extra templates that show that even the family is not accepted, perhaps even in a new namespace to hedge this “poison”, but I am in in the deletion, because I see that these macrofamilies attract all kinds of howthery-towthery people that burn the candle at both ends with their smattering learning. It’s hard enough to know the languages and collect the data for the accepted families. It’s beyond the level of man to do more in acceptable quality – those people who want Nostratic shall fork their own Wiktionary thus. That @Jaspet shall work on an own server where he continually clones Wiktionary entries for acceptable terms, and he can create entries for the acceptable languages here. Let’s see if that works: It won’t and he can’t work this way because such people are incompetent and try to hide it by working in areas that nobody can have enough concrete knowledge about. It is like metaphysics: Nothing serious people want to read. Palaestrator verborum (loquier) 21:18, 7 December 2017 (UTC)
I too support removal. @Crom daba, is it no longer referenced in mainspace? —Μετάknowledgediscuss/deeds 21:43, 7 December 2017 (UTC)
It's still referenced, I'll clean up derived forms. Crom daba (talk) 21:54, 7 December 2017 (UTC)
With all due respect I don't know what you're talking about, nor what that is meant to convey.
There is, by the way, a major difference between comparative linguistics and metaphysics: one is a posteriori and theoretical, for which all of the methodology rests on the idea that evidence is what conclusions about reality are drawn from; the other is a priori (thus very often ad hoc), philosophical, and hypothetical, being based on personal beliefs for the causes of experiences rather than on a scientific methodology. A small and irrelevant detail, I know. I'll let you humor yourself guessing which is which.  — J​as​p​e​t 22:31, 7 December 2017 (UTC)
"Judging by Wikipedia" is your first problem. The last time I checked, Wikipedia isn't itself a source and doesn't have an opinion. Regardless, I agree that we should be using original sources rather than mindlessly pulling from StarLing in a practically copy-and-paste manner. Rather, it is more logical to cite original sources and only include StarLing when it is absolutely necessary (i.e. when it is the only source, as is the case for the majority of this database). At least one such "original source" exists in this case for North Caucasian, but it is hosted on the StarLing site itself and is by the same authors, so in this case it might not make much difference.
That said, although I do not support deleting it outright, I want little part in North Caucasian: it is a case in which there is far too much long-term proximity of the two language families for any amount of evidence to appease people, and invoking the argument that every resemblance is due to contact/borrowing is not entirely ridiculous as it would be in some other cases.  — J​as​p​e​t 22:31, 7 December 2017 (UTC)
@Jaspet: As an aside--I don't want to get off-track with the main conversation--a neutral point of view is a point of view. It's not that Wikipedia has no perspective but a neutral one. —Justin (koavf)TCM 23:38, 7 December 2017 (UTC)
There is nothing stopping us from linking these potential cognates on PNEC and PNWC pages, this however does not necessitate making PNC pages.
Seeing as there are no regular phonologic correspondences between these languages that are accepted outside of Starostin's books, we cannot do our own informed reconstructions and the entries will unavoidably be StarLing copy-pastes.
Not to mention how misleading these are, if you saw Proto-North Caucasian *bHV̆rgĂ (beast of prey) in an etymology, you might imagine it to be solid etymon (well not if you had prior contact with StarLing wildcard etymologies) with many regular descendants. Instead it's a (seemingly solid) PNWC word for a jackal/fox plus two very dubious NEC words.
This is endemic to all of StarLing, methods of reconstruction are fixed so that long-range cognates line up, this is no way to do philology.
Crom daba (talk) 00:04, 8 December 2017 (UTC)
Fair enough. I would say it has a perspective but not an opinion, such that it tries not to take sides. But I suppose this is an unhelpful semantic issue.
On a more relevant note, there is no objective manner in which to settle differences in perspectives/opinions/beliefs about linguistic theories, and for better or worse it is ultimately up to the consensus of individual Wikimedia contributors. My two cents is that, though the theory itself isn't accepted at large, that doesn't mean Wiktionary shouldn't allow the reconstructions to be shown at all. In the same way that Wikipedia articles can exist for these theoretical language families, though with plenty of disclaimers, Wiktionary entries can exist for the specific comparisons and reconstructed protoforms, with disclaimers. As has been suggested, maybe the creation of a new template (yet another disclaimer) is warranted, or I alternatively suggest going back to using appendices specifically for these less accepted reconstructions. Additionally, it is difficult to discern whether the linguistics community at large even has a perspective on each of such connections between language families, since most study directed at the comparisons are only done by those arguing in favor of their relationship.  — J​as​p​e​t 00:18, 8 December 2017 (UTC)

Restoring vmf and eliminating gmw-hfr[edit]

Five years ago we voted to exclude the code vmf because it was unclear what language it was supposed to refer to. However, in the meantime, SIL/Ethnologue has cleaned up their definition and it is now clear that it refers to East Franconian German: Ethnologue's name for the language is "Eastern Franconian" and the area where it is said to be spoken is "Bayern state: Oberfranken, Mittelfranken, and Unterfranken districts; Thüringen state: south", which corresponds to the usual understanding of East Franconian.

At the same time, we do have gmw-hfr for "High Franconian", which is supposed to cover both East Franconian and South Franconian; however, dialectologists no longer accept that these two lects are more closely related to each other than they are to the other Upper German lects, so "High Franconian" is apparently not actually a valid clade.

I therefore request that we reinstate vmf as a valid code and call it East Franconian, and abolish gmw-hfr. There are currently only four High Franconian entries, all of which are labeled with locations in the East (not South) Franconian area, so we can safely move all of them to vmf. —Mahāgaja (formerly Angr) · talk 16:13, 29 November 2017 (UTC)

Oh, they finally did something about that mess. Support. — Ungoliant (falai) 16:24, 29 November 2017 (UTC)
Wouldn't than a new code gmw-sfr (german middle west - south franconian) for South Franconian be needed too?
Isn't according to SIL (www-01.sil.org/iso639-3/documentation.asp?id=vmf) vmf = w:Main-Franconian dialects? www.ethnologue.com/language/vmf calls vmf "Eastern Franconian" (w:East Franconian German) and "Upper Franconian" (w:High Franconian German?) and mentions the alleged autonyms "Mainfränkisch", "Ostfränkisch". Thus isn't it still unclear what's it supposed to be? Wouldn't a clear code gmw-efr (german middle west - east franconian) be a better choice, also as it is similar to gmw-sfr?
- 16:29, 29 November 2017 (UTC)
Yes, we can add gmw-sfr for South Franconian too, but at the moment we don't seem to have any South Franconian entries. As for what vmf refers to, I think it's clear enough from the Ethnologue entry that all of East Franconian is meant: Ethnologue says vmf is spoken in Oberfranken, but Oberfränkisch is not usually considered part of Mainfränkisch. So if vmf includes Oberfränkisch, then vmf must be broader than Mainfränkisch. And franlkly, even if only Main Franconian were meant, we have enough flexibility to extend it to the whole of East Franconian. Compare nrf, which SIL uses only for Guernésiais and Jèrriais but which we have extended to cover Sercquiais and Continental Norman. —Mahāgaja (formerly Angr) · talk 16:52, 29 November 2017 (UTC)
OK, I have added vmf as a valid code and removed gmw-hfr. For some reason {{auto cat}} doesn't work on East Franconian categories, but the other boilerplate templates (e.g. {{poscatboiler}} do. —Mahāgaja (formerly Angr) · talk 11:29, 7 December 2017 (UTC)

Excluding syr[edit]

A user has been adding Latin-alphabet entries in Syriac, using the code syr, which currently has no other lemmas but which we define as being written in the Syriac script, not Latin. For this reason, I have reverted them. However, it turns out that syr is a macrolanguage covering Assyrian Neo-Aramaic (aii) and Chaldean Neo-Aramaic (cld), which we treat as two separate languages. I therefore suggest we exclude syr as a valid code and ask the user to add entries only in Syriac script and only using one of those two codes (whichever is appropriate). —Mahāgaja (formerly Angr) · talk 16:40, 29 November 2017 (UTC)

Yes, if we split the language one way we can not lump it the other. Also, syr is an easy misspelling for syc (I have cleaned those at some point), that’s why it should go.
Also, can somebody add language data to the Old South Arabian dialects (as etymology-only languages, like ML.)? We treat Old South Arabian as one language, but currently if someone uses the codes xsa (Sabaean), xhd (Hadramautic), xqt (Qatabanian), inm (Minaean), xha (Harami) he can do what he wants but reasonable use of the codes is hindered because the templates set the South Arabian script cursive (they should just have the same properties as sem-srb in this regard). Palaestrator verborum (loquier) 00:21, 30 November 2017 (UTC)
@Palaestrator verborum: By cursive do you mean italicization? Italicization is controlled by MediaWiki:Common.css, not by language data. There is already a style rule preventing italicization for South Arabian script: .Sarb, .Sarb * { font-style: normal; }. It will not apply in the mobile version of the site, however. — Eru·tuon 01:14, 30 November 2017 (UTC)
Oh, I see. xsa and the others don't have a script listed. Do they all use South Arabian script? — Eru·tuon 01:16, 30 November 2017 (UTC)
@Erutuon Yes, the script had been pretty widespread throughout the Arabian peninsula. I can’t tell what they also used, as the period under question is to a great part the period of emergences and mixings of various scripts and their prototypes and the epigraphic literature is scattered and hard to reach (all trifles are digitized or collected by university libraries but rarely the crucial reproductions of Arabian inscriptions), but definitely one is not wrong with ascribing the Ancient South Arabian script to all the Old South Arabian languages. Palaestrator verborum (loquier) 01:33, 30 November 2017 (UTC)
@Palaestrator verborum: Okay, done (diff1, diff2). Now the correct script class will be used and the languages will display without italics. — Eru·tuon 01:54, 30 November 2017 (UTC)
To get back to the original topic, are there any objections to my removing syr from Module:languages/data3/s and listing it as excluded at WT:LT? —Mahāgaja (formerly Angr) · talk 13:05, 30 November 2017 (UTC)
It seems like it was planned to exclude it, as WT:LT says: Syriac (syr) See the entry for "Aramaic". But it’s not there. But note that you have to move some babel templates. Currently they are all on the code syr. Lol the deletion of {{User syc}}: “Not used, and the correct code syr already exists” – but that was 2011. Palaestrator verborum (loquier)
Oh Lord. I don't even know what language {{User syr}} and {{User syr-1}} are written in. Presumably not Classical Syriac since Kathovo claims to be a native speaker. I assume he's a native speaker of either aii or cld, but he hasn't edited here since 2013 or at Wikipedia since 2016. @Lingo Bingo Dingo, Profes.I.: what language did you guys mean when you put "syr-1" on your user pages? Classical Syriac, Assyrian Neo-Aramaic, Chaldean Neo-Aramaic, or something else? —Mahāgaja (formerly Angr) · talk 21:32, 30 November 2017 (UTC)
Classical Syriac, because I couldn't find a Babel tag for that variety. Lingo Bingo Dingo (talk) 09:54, 1 December 2017 (UTC)
OK, then I'm moving the templates from "syr" to "syc", removing "syr" from the language module, and updating LT. —Mahāgaja (formerly Angr) · talk 19:25, 4 December 2017 (UTC)
I think I'm done. I've corrected all the errors that appeared at CAT:E as of now. —Mahāgaja (formerly Angr) · talk 21:39, 4 December 2017 (UTC)

A little last-minute but I'd like a Christmas competition[edit]

We haven't had one in a few years. I'd be willing to brainstorm for one and post it December 1 if the community thinks there is enough interest in some word games. —Justin (koavf)TCM 18:28, 29 November 2017 (UTC)

See Category:Wiktionary fun stuff for previous entries. —Justin (koavf)TCM 18:28, 29 November 2017 (UTC)
Never too late — I'd love a Christmas competition. The best ones are like the one from earlier this year in that they have a structure which encourages entry creation as side effect of the game. —Μετάknowledgediscuss/deeds 19:13, 29 November 2017 (UTC)
I’d love one too. — Ungoliant (falai) 11:07, 30 November 2017 (UTC)
I could organise multilingual Scrabble, as the original cretor doesn't seem to be around any longer. --Lirafafrod (talk) 15:41, 1 December 2017 (UTC)
Or we can rehash old games - I doubt any of us were still around in 2008. Wiktionary:Possible Christmas Competition 2017 1 is a catchy name. --Lirafafrod (talk) 15:49, 1 December 2017 (UTC)
Wiktionary:Possible Christmas Competition 2017 2 - rewriting a Christmas song with Wiktionary-based lyrics. --Lirafafrod (talk) 15:55, 1 December 2017 (UTC)
Thanks, Lirafafrod. I don't have more to add, so I'm in favor of whatever everyone else decides. I'll brainstorm for an Easter competition for next year. —Justin (koavf)TCM 02:38, 2 December 2017 (UTC)
His name is Wonderfool (probably) —AryamanA (मुझसे बात करेंयोगदान) 03:12, 2 December 2017 (UTC)

Let's please have a final game by Monday the 4th, so we have three weeks to "compete". —Justin (koavf)TCM 02:42, 2 December 2017 (UTC)

  • OK, so Wiktionary:Christmas Competition 2017 is the official game this year. The other I'll use in 2019. Gives you a couple years to think up a Wixmas song. --Lirafafrod (talk) 12:25, 2 December 2017 (UTC)
    And it started epically bad, with 5 incorrect submissions, including one by the Gamesmaster themself. --Lirafafrod (talk) 21:22, 3 December 2017 (UTC)

Ingush palochka[edit]

I've just noticed that, in our entry Ingush, the Ingush translation for the language is гӏалгӏай (ġalġaj), with Unicode u04cf for the palochkas. Wikipedia's entry for w:Ingush language has гӀалгӀай, which uses the palochka codepoint u04c0 (the original Unicode palochka, and the one used by Ingush and Chechen writers). The palochka glyph has never had separate upper- and lowercase forms, but only a single case. Recently somebody created a special Unicode u04cf (as used in our гӏалгӏай) as a new lowercase form, and this new lowercase ӏ is identical to the original Ӏ (at least in my font). Since the palochka has never had two cases, and since the original form and the new form look identical, it causes a lot of confusion. I don't think the new form is being used by anyone (except for some of our editors). Besides that, the palochka is never initial in a word, so there is no place to use an uppercase form (the uppercase being represented by the original form which is virtually always used in lowercase environments). The only situation where an uppercase might theoretically be used is in all caps, a rarity. I think we should stop using the new form (u04cf) since no one else uses it.

One result of this confusion is that Ingush words using the original palochka are being transliterated strangely: гӀалгӀай (ġalġaj). See Wiktionary:Ingush transliteration. Another difficulty is that searching for one spelling misses words written with the other spelling. This is what I think. Using that new lowercase form is like creating a special apostrophe, identical to the normal apostrophe in every way except codepoint, for use in lowercase environments. It's just a big headache for no good reason. —Stephen (Talk) 10:54, 30 November 2017 (UTC)

I think you're right, we should be using the original palochka U+04C0 in entry titles. We could make hard redirects from the forms using U+04CF just in case anyone searches for them, and to prevent people from starting new entries with that character. —Mahāgaja (formerly Angr) · talk 13:07, 30 November 2017 (UTC)
I beg to differ. The small palochka is the latest required introduction but it hasn't caught up yet everywhere. Besides, this is a strict dictionary style. While it's important to show how characters are/were used in the real life, we shouldn't promote the incorrect common usage. There are numerous examples in various languages:
  1. Russians don't use stress marks usually don't use letter ё usually replacing it with a е.
  2. Arabs don't use vowel points and, depending on country and style don't use a hamza over alif and under alif - أ and إ, final dotted ي is often replaced with ى and sometimes the final ة is replaced with a ه.
  3. All Hindi letters with nuqta: क़, ख़, ग़, ज़, झ़, फ़, ड़, ढ़ are replaced with their counterparts without it: , , , , , , ,
  4. Chuvash Cyrillic letters ӑ, ӗ, ҫ, etc. are replaced with their Latin lookalikes.
  5. Ossetian ӕ is replaced with the Latin lookalike.
  6. Mongolian (Cyrillic) standard ө and ү were replaced with є and ї.
The transliterations should work (ideally) with the wrong characters and substitutes but we should aim for the standard and dictionary styles in entries and redirects should be for the less standard forms, not the other way around. --Anatoli T. (обсудить/вклад) 03:15, 2 December 2017 (UTC)
Hindi nuqta letters aren't always unused, it's a matter of preference. I always use nuqtas in text, even though my sociolect doesn't distinguish them from non-nuqta consonants (except ज़ (za)) And ड़ (ṛa) and ढ़ (ṛha) would definitely be misspelled without the nuqta, since they are native sounds. —AryamanA (मुझसे बात करेंयोगदान) 01:13, 6 December 2017 (UTC)
@AryamanA: Thanks for reminding me, I slightly forgot the rules (it's been a while) but I know that some nuqta letters cause both misreadings and overcorrections and it may also depend on the origin of the word or frequency. फ़िल्म (film, film), AFAIK, would always be pronounced "film", even if it's spelled फिल्म (philm) but words of Persian or Arabic origin may not be so "lucky", like ग़रीब (ġarīb, poor) -> गरीब (garīb). I think these variants also need (eventually) to have their "alt form" entries with or without phonetic respelling, so that users know what pronunciations are acceptable - actual with or without nuqta, or of the alternative. E.g., users need to know for both ज़रूरी (zarūrī, necessary) and जरूरी (jarūrī), if both "zarūrī" and "jarūrī" can be tolerated, also which spelling is now common and included in dictionaries, etc. --Anatoli T. (обсудить/вклад) 06:20, 6 December 2017 (UTC)
The last but not the least example are the Hebrew geresh and gershayim. We normalise words that out there use a simple apostrophe with a ׳, etc. --Anatoli T. (обсудить/вклад) 04:30, 2 December 2017 (UTC)
I think you're conflating three different things here. There are cases where the underlying character is clear, but the wrong Unicode code point is used. There are cases where we use things like vowel points that are useful in a dictionary but not necessary in normal writing. And then there are points where the practice simply doesn't match with the theory, in which case we are supposed to go with the practice, not the theory.--Prosfilaes (talk) 06:35, 5 December 2017 (UTC)
The amount of contradictions and conflations and underspecifications in your post is baffling. Unicode is a theory we abide by as practice is inferior to it. Like the regulative idea of having tomorrow better entries than we have had the week before. Sometimes practice just lacks the right to life. I don’t know about those points where we should go with practice that contradicts theory. One can just handle the practice and else follow the reasonable rules to get the most for all. Dictionary editors needs have abstractions that commoners do not have and it shan’t be a disadvantage to follow the laws. Unicode is most accessible and available on all platforms, thus it is everyone’s obligation to consider it, and even to drop the platform that is unfit for serious working with language (Microsoft Windows). Palaestrator verborum (loquier) 07:00, 5 December 2017 (UTC)
Unicode is not a theory. It's a character encoding standard, a set of sometimes quite arbitrary rules created to allow computers to store written text.
Modern dictionary theory, and Wikimedia principles, deprives us of the right to follow "practice just lacks the right to life".--Prosfilaes (talk) 11:35, 5 December 2017 (UTC)
(edit conflict) @Prosfilaes: Dictionary creators/publishers use what they consider normal and standard for dictionaries, the most current and correct from various points of view. Palochka was replaced with a vertical bar "|" and other characters for a long time, these languages didn't have the luxury to have a keyboard provided for them. Then a single (upper case) was introduced. The lower case is the latest addition. The Ossetian, Chuvash situations is no different. The writers often choose what they have available and what they got used to but it's not consistent. Ossetian is the only language that uses [[ӕ]] but they used [[æ]] instead for various reasons.
Reasons for the Russian [[е]] instead of [[ё]], failure to spell out Hindi nuqta, Arabic hamza above and below, dots under the final yāʾ and over the tāʾ marbūṭa and Hebrew writing an apostrophe instead of geresh [[׳]] also vary but we choose to use what we consider the latest dictionary style for these languages, even if some dictionaries not necessarily use the same rules.
We use stress marks and vowel points even if most attested texts don't use them. (Some people consider writing out super- and subscript hamza and dots I mentioned above additional diacritics as well.)
The main point, perhaps, is that what we use at Wiktionary is not necessarily the same what we can find citations and real-life examples for even if reasons and frequencies are different with different symbols and languages. There are too many examples of normalisations and fixes and other things (like Japanese furigana) we use here, even if this is not normal in some running texts and many texts, like North Caucasian languages are full of incorrect characters. Call it fixes, normalisations or enhancements, dictionaries are different from running texts. --Anatoli T. (обсудить/вклад) 07:25, 5 December 2017 (UTC)
ӕ and æ are different code points. It's clear to me that in context, they're the same character. If you were looking at a printed text, you couldn't tell the difference, and there's no difference in intent. When it gets to things like "Mongolian (Cyrillic) standard ө and ү were replaced with є and ї.", it seems clear that we're changing spelling, and that's problematic.--Prosfilaes (talk) 11:35, 5 December 2017 (UTC)
I can fix the issue with transliteration. I would think that both palochkas should be transliterated the same way, even if one of them is not supposed to be used. — Eru·tuon 05:42, 2 December 2017 (UTC)
@Erutuon: Thanks but please be aware that palochka is used a significant number of North Caucasian languages and the mix-up between the upper case and lower case palochka is not the only problem. It's often replaced with [[|]], I, l. --Anatoli T. (обсудить/вклад) 06:15, 2 December 2017 (UTC)
Note that with the Russian-based polyglot and reactionary keyboard layout you can use both palochkas; the explicit lower-case one U+04CF CYRILLIC SMALL LETTER PALOCHKA with Caps + й (Q), U+04C0 CYRILLIC LETTER PALOCHKA with Caps + Shift + й (Q).
So from the keyboard layout side there is no preference, the free desktops have a layout that fits quite well to wiki editing in any Cyrillic script; the usage is a bad guide if it comes to encoding. Palaestrator verborum (loquier) 13:42, 2 December 2017 (UTC)
@Atitarev: Done. Those other replacements are not the right script, or a formerly correct usage, so they should be unsupported. — Eru·tuon 20:02, 2 December 2017 (UTC)
@Erutuon: Thanks. I am OK to not support "|" and other substitutes. Are you able to apply the same fix for other modules, which use palochka, please? Adyghe (ady), Avar (av), Chechen (ce). @Vahagn Petrosyan: Have I missed any modules we have, which use the palochka? --Anatoli T. (обсудить/вклад) 02:13, 3 December 2017 (UTC)
@Atitarev: I think this search will find all the modules that transliterate palochkas. — Eru·tuon 02:41, 3 December 2017 (UTC)
@Erutuon: Wow, that's a lot. Thanks. They are the right ones. If a generic method for treating equally upper- and lower-case palochkas is found, then it should apply to all of them. For transliteration purposes, they are equal. --Anatoli T. (обсудить/вклад) 02:45, 3 December 2017 (UTC)
@Atitarev: The method I've arrived at is to make sure all palochkas in the module are lowercase, then convert any uppercase palochkas in the text to lowercase and proceed with transliteration. That's pretty straightforward and reliable. I had been creating testcases, which takes time, but I think I'll just go ahead and implement this method. — Eru·tuon 04:21, 3 December 2017 (UTC)
If we are to only use one type of palochka, why bother transliterating the other one? —suzukaze (tc) 04:14, 3 December 2017 (UTC)
I think the uppercase palochka is the older character and was formerly correct. Not transliterating it correctly would be like penalizing people for not using the newer character. I could imagine a variety of reasons for not using the newer character: ignorance, computer issues, or principled objection. And it's nice to be backwards-compatible. The use of the newer character can be enforced in other ways. (Also, I just discovered that Wiktionary:Abaza transliteration itself uses both characters, and the older one wasn't being transliterated correctly.) — Eru·tuon 04:56, 3 December 2017 (UTC)

Okay, I think all the modules treat both palochkas alike now. — Eru·tuon 05:08, 3 December 2017 (UTC)

@Erutuon: Great job and a good method! --Anatoli T. (обсудить/вклад) 11:57, 3 December 2017 (UTC)

stroke order exceptions[edit]

It would be great to find a dabase/list of characters whose stroke order is different from the one to be expected according to the standard guidelines 现代汉语通用字笔顺规范. Prof. Yin mentions in the "Routledge's Encyclopedia of Chinese" 女 as a simple example.

Eventually, the characters that do not follow the standard guidelines should be arranged into groups according to the "type of irregularity", which would be very useful both for lexicographic and learning purposes.

Maybe the info. necessary can be gathered form new input methods' lists of sequences as well as from stroke order gifs. Then it would be manually checked. --Backinstadiums (talk) 12:47, 30 November 2017 (UTC)


The moment I tried to apply this template to a confirmed sock user it was deleted ASAP by Metaknowledge. The deletion itself is not why I'm bringing it here.

In his deletion reason he claimed that the sockpuppeteer template is pointless in general. Does anyone else think it should be deleted? mellohi! (僕の乖離) 20:31, 30 November 2017 (UTC)

My general reasoning: it's a Wikipedia template that links to Wikipedia policies. It might be useful there, but block summaries are good enough for our modest needs. —Μετάknowledgediscuss/deeds 20:32, 30 November 2017 (UTC)
Not even Wonderfool got that far? mellohi! (僕の乖離) 20:36, 30 November 2017 (UTC)
Not sure what you mean, but WF has not taken any pains to hide his identity for many years. —Μετάknowledgediscuss/deeds 21:04, 30 November 2017 (UTC)
Who's Wonderfool? --Lirafafrod (talk) 15:53, 1 December 2017 (UTC)
@Lirafafrod: A user who was an admin that went rogue and caused all kinds of damage (like deleting the Main Page). —Justin (koavf)TCM 17:44, 1 December 2017 (UTC)
Hey Justin, look up at the ceiling, it says "gullible"... —Μετάknowledgediscuss/deeds 19:06, 1 December 2017 (UTC)
Confirmed. Lirafafrod is an anagram of "i arr da ffol", which is obviously Welsh for "I am the (Wonder)fool". Equinox 19:27, 1 December 2017 (UTC)
Wonderfoolati confirmed. — Ungoliant (falai) 19:31, 1 December 2017 (UTC)

December 2017

Etymology cleanup[edit]

Not sure how to approach the etymology in a coinage like panpygoptosis. If someone could give it a pair of eyes, that would be appreciated. Thanks. —Justin (koavf)TCM 07:05, 1 December 2017 (UTC)

Is it pan- +‎ pygo- +‎ ptosis? Not sure about the "opto" part in the current entry. Equinox 07:43, 1 December 2017 (UTC)
I think you're right. There are two meanings for Ancient Greek ὀπτός (optós), "roasted" and "seen", but neither makes any sense here. — Eru·tuon 08:31, 1 December 2017 (UTC)
Done. --Barytonesis (talk) 21:09, 1 December 2017 (UTC)

delete unnecessary intermediate pages[edit]

Situtations like both fukyo and the page it redirects to ふきょ to finally, after 3 steps, get the right 不許, should be avoided when possible. --Backinstadiums (talk) 16:04, 2 December 2017 (UTC)

No, it shouldn't. Learn a little about Japanese and why our structure is the way it is before you tell us to delete things. —Μετάknowledgediscuss/deeds 18:50, 2 December 2017 (UTC)
@Metaknowledge: Just suggesting, as usual, so I should've chosen a clearer modal verb. I know a little of Japanese phonology/phonetics. Wikipedia encyclopedic approach redirects whenever it's desirable --Backinstadiums (talk) 21:08, 2 December 2017 (UTC)
We should absolutely not use hard redirects. fukyo could easily be a word in another language, and aren't other languages besides Standard Japanese (e.g. Ryukyuan languages) also written in hiragana? If so, then ふきょ could potentially also be a word in another language. And while fukyo/ふきょ may have only one kanji reading, consider cases like fu/ where there are five different associated kanji. —Mahāgaja (formerly Angr) · talk 21:28, 2 December 2017 (UTC)
We could still alleviate the issue by listing the kanji directly at fukyo. —Rua (mew) 22:14, 2 December 2017 (UTC)
@Rua: I agree --Backinstadiums (talk) 23:17, 2 December 2017 (UTC)
Absolutely NOT! Rōmaji entries link to kana readings - usually one but can be a few. The kana entry (hiragana and katakana) serves as a disambiguation page, it can link to a large number of kanji entries. kōsō -> こうそう (kōsō). Please read the policy on Japanese entries in WT:AJA and stop messing around. @Eirikr, TAKASUGI Shinji. --Anatoli T. (обсудить/вклад) 13:26, 3 December 2017 (UTC)
... or こうしょう (kōshō). Wyang (talk) 15:50, 3 December 2017 (UTC)
Actually one should mithe to access the Roman transcriptions in the first place, isn’t it? Probably you should learn to use an IME. But it displays the true state of things if one has to click twice if one uses a transcription of a transcription.
Though why doesn’t the template {{ja-romanization of}} take an additional argument in the case that the hiragana is itself a transcription of the Chinese? I can imagine that it is regularly the case that users click twice in those cases. Palaestrator verborum (loquier) 23:45, 2 December 2017 (UTC)
The problem is that there's no guarantee that someone won't add more kanji for the pronunciation, and if they only add them to one or the other, but not both, the pages go out of synch. It's hard enough to get all the readings reflected where they should be without requiring updating of another page every time. Like many of Backinstadium's ideas, this is based on the premise that the dictionary is a finite, finished product that merely needs to be rearranged, rather than a dynamic entity that's constantly being edited by people who don't know what anyone else is doing on other pages. Chuck Entz (talk) 16:01, 3 December 2017 (UTC)
@Chuck Entz, Atitarev: I was told in past discussions, I think about the Simplified/Traditional redirect issue, that it was the structure used for the wikis the one that limited the implementation (in your example just sinchronizing two pages). Secondly, I've never thoutht of a lexicographic resource as a finished product; rather I prioritize enhancing the user experience, especially for beginners, even if that means extra work. --Backinstadiums (talk) 17:21, 3 December 2017 (UTC)
Dude, just compare the time you have talked here with the time lost by this disenhancement of you having to click twice. The editing work needed for the enhancement is completely disproportionate to the enhancement gained: Either editors would have to check for rearrangements constantly or complicated templates would have to be used on the Hiragana pages whereby the Romaji pages would autofetch the Chinese. It is better to create some new entries. Palaestrator verborum (loquier) 17:32, 3 December 2017 (UTC)

Confusing cleanup category[edit]

What is Category:Needs cleanup supposed to be and how are terms included in it? —Justin (koavf)TCM 21:52, 2 December 2017 (UTC)

It's being generated by {{da-verb}}. DTLHS (talk) 21:54, 2 December 2017 (UTC)
I have already asked User:Gamren about this. It's something he will be working on eventually. DonnanZ (talk) 22:08, 2 December 2017 (UTC)


We currently only have one entry for the Hlai language, which is nom³. This entry is in some sort of IPA. However, Hlai does have a written language in the Latin script, based on Ha. Should we move nom³ to noms, based on the newest orthography (2005)? — justin(r)leung (t...) | c=› } 22:01, 2 December 2017 (UTC)

Yes, definitely. -sche has created many such entries, usually basing the orthography on whatever linguistic materials they have access to. Whenever I come across these and they need to be moved to an orthography that's actually used, I fix the entry (and the translation at water#Translations) and create a short about page that documents the orthography I have selected. —Μετάknowledgediscuss/deeds 22:10, 2 December 2017 (UTC)
@Metaknowledge Thanks! I've added a Hlai section to noms, but should nom³ be a redirect or deleted? — justin(r)leung (t...) | c=› } 00:25, 3 December 2017 (UTC)
I'd say that's at your discretion. Unless somebody else uses it, my instinct would be to delete it. —Μετάknowledgediscuss/deeds 01:02, 3 December 2017 (UTC)
@Metaknowledge: Alright, thanks again! — justin(r)leung (t...) | c=› } 01:07, 3 December 2017 (UTC)
No, thank you for working on minority languages! —Μετάknowledgediscuss/deeds 02:15, 3 December 2017 (UTC)
Yes, thank you! :) I try to find if there is any standard orthography for each language (at the time I create the entry and in periodic re-checks of previously-created entries), but sometimes I can't find any. For Hlai, searching for a standard orthography was complicated by the fact Hlai has many varieties. - -sche (discuss) 02:54, 4 December 2017 (UTC)
@-sche It is certainly an issue that Hlai has many varieties. With the standard orthography, I'm not sure how the various dialectal differences can be shown. On a related note, I've also noticed that you have also created "water" entries for different varieties of Zhuang using IPA. Should these all be deleted, since most of our Zhuang coverage doesn't distinguish between dialects? The same issue occurs here with Zhuang, where I'm not sure how the standard orthography can be used to represent varieties other than the the standard register and the Wuming dialect. — justin(r)leung (t...) | c=› } 04:39, 6 December 2017 (UTC)
Are the varieties of Zhuang so similar that they should not be considered separate languages, i.e. we should retire the separate codes we currently have for them? (WT:LT says as much, but there does not appear to have been any discussion of it — if you can confirm that we should treat Zhuang as one language, we can add a link on WT:LT to this discussion.) In that case, the entries we currently have, to the extent they show that e.g. Yang Zhuang uses ham⁴, could be migrated into the ===Pronunciation=== section of the "standard Zhuang" term, it would seem to me. Whereas if the varieties should be considered separate languages and the problem is just that only one has a standard orthography, it seems like a tolerable interim solution to leave the others at the best orthography we have access to, even if that is an IPA-ish orthography. - -sche (discuss) 00:20, 7 December 2017 (UTC)
@-sche: Traditionally, these varieties were considered to be one language by the Chinese government (since they are grouped under the Zhuang ethnicity). I think situation is similar to Arabic or even Chinese, where the varieties have very limited to no mutual intelligibility but speakers generally think they are speaking the same language. That is why there is only one standard for all these varieties. See these two files for more information: [3] [4] — justin(r)leung (t...) | c=› } 02:21, 7 December 2017 (UTC)

Removing precomposed characters from MediaWiki:Edittools[edit]

A lot of the space in the edit tools is taken up by precomposed characters like á, ē, ằ, ѝ etc. These aren't actually needed on Wiktionary, because the software automatically converts everything to composed normal form whenever you save a page. It would be perfectly fine if you entered a regular letter a followed by a combining acute accent, the end result is exactly the same. So I propose removing these precomposed characters from the edit tools, and instead making a special tab with all combining diacritics. That would give a lot more flexibility and allow editors to enter combinations that were not previously possible. —Rua (mew) 13:16, 3 December 2017 (UTC)

the software automatically converts everything to composed normal form whenever you save a page – that’s important information, because the upcoming IPA keyboard layout heavily relies on combining characters. I thought before that maybe I have to use precomposed characters.
As for me, the whole bar can be disabled, as all is accessible via dead keys and the compose table and appropriate keyboard layouts or direct Unicode input and charmaps. A web table under an editing area for such seems like a relict from 2004 and a very lame way of input, also the selection is arbitrary, like Ð ð but not Đ đ; dictionary editors can be expected to use appropriate input methods. Or @Anglish4699, do you need that bar?
I can’t disable it just for me? I don’t see such a setting under the editing preferences. Palaestrator verborum (loquier) 15:37, 3 December 2017 (UTC)
For myself at least, I have never used that bottom tool bar, but I have used the top one above the edit workspace. That one does come in handy much of the time. I would not be against the more flexible diacritic table (as that may be more helpful to others), but I think more input from the users is needed here. Anglish4699 (talk) 20:26, 3 December 2017 (UTC)
I used to use the Greek menu, but now I use the template {{chars}}. I still sometimes use the menu for non-Greek characters, though.
I don't know if I've ever used the "Special characters" menu on top. It groups things by Unicode block (I guess), which is somewhat less helpful for scripts such as Greek that are located in multiple blocks, and it doesn't contain all the characters that I would want to type (for instance, punctuation-type characters such as §, ’, ◌). — Eru·tuon 20:55, 3 December 2017 (UTC)
Symbol support vote.svg Supportsuzukaze (tc) 21:15, 3 December 2017 (UTC)
Symbol support vote.svg Support --Barytonesis (talk) 21:16, 3 December 2017 (UTC)
Template:neutral I'd like to see a simulation. Will inserting combining characters work on virtually all the systems that people are using to edit Wiktionary? Especially with monospace fonts in the edit box, I'm not sure if the combining characters will show up correctly on many systems. I find the box quite useful, however.--Prosfilaes (talk) 11:44, 5 December 2017 (UTC)
They may not appear exactly right in the edit box, but that should go away once you save the page. It might even go away just by previewing the page, but someone will have to test that. —Rua (mew) 15:23, 5 December 2017 (UTC)
Yes, when I enter a + ◌́ (U+301, acute accent, minus the dotted circle) and press "show preview", this sequence changes to á (U+E1, Latin small letter a with acute) in the text box. — Eru·tuon 19:16, 5 December 2017 (UTC)
  • I would support some combining characters being removed. That is, when the menu is not for an orthography in which letter + combining character is considered a letter. For example, I think it would be an improvement if the Vietnamese menu gave the letters ă, â, ê, ô, ơ, ư as precombined characters, but listed the tones ◌̀, ◌̉, ◌̃, ◌́, ◌̣ as combining characters. And perhaps the Arabic menu should list the diacriticked letters that are used to transliterate Arabic consonants, but it should give a combining acute accent instead of vowel + acute combinations. (Either that or the acute accent should be removed.) The rationale is that the tonal diacritics and acute accent are separable symbols that represent a phonemic or phonetic unit in themselves, while the other diacritics do not represent a unit in themselves, but only in combination with a letter. — Eru·tuon 21:26, 5 December 2017 (UTC)
    • But for "Latin", everything is a diacritic. I don't think this is a particularly meaningful distinction. The point of the change is to make it easier for people to use diacritics and not having a list of precomposed characters. If everyone and their dog wants their own custom set of "letters" in the menu, then it defeats the point entirely. —Rua (mew) 21:35, 5 December 2017 (UTC)
      • My concern does not apply to the "Latin" menu, only to the ones for particular languages or other scripts. — Eru·tuon 21:39, 5 December 2017 (UTC)
        • Vietnamese is written in the Latin script. None of the precomposed characters in its menu are needed, all can be created with combining diacritics. —Rua (mew) 21:48, 5 December 2017 (UTC)
          • Of course, but it's less convenient to select from a huge long list of diacritics (which are in a difficult-to-understand order) than from a short list of diacritics or letter–diacritic combinations used in a particular orthographical system. — Eru·tuon 21:55, 5 December 2017 (UTC)
          • When visually similar diacritics are involved, it might help to have a menu specific to an orthographical system. Some people confuse háček or breve, circumflex or inverted breve, ogonek or cedilla or comma. Then again, we do not have a menu for every orthography that uses some of these diacritics and I'm not really arguing for that. And they would probably be confused by a minority among active contributors. — Eru·tuon 22:10, 5 December 2017 (UTC)
            • I've included Unicode names and codepoints in the title text of the new diacritics submenu. That will hopefully help people decide which is the right one. —Rua (mew) 22:17, 5 December 2017 (UTC)
              • That is a helpful feature. To be clear, I do support your proposal as far as the Latin menu is concerned. — Eru·tuon 22:35, 5 December 2017 (UTC)
All these confusions are a reason why such a menu should not exist at all 😒. If you use Gucharmap or Fcitx Unicode Input you see more information about the characters you try to give in, and these application also update their data without manual intervention by a Wiktionary coder. Perhaps we should just disable the menu entirely for some time and look who complains. If it goes unnoticed, you’ll can rub your hands because you have less bothering and a new argument for that bug being fixed.
But as this extreme step will not be performed, it slowly becomes more desirable that that bug be fixed. There isn’t a specific script that I can block with uBlock Origin, I can only hide the bar with the element picker. Palaestrator verborum (loquier) 23:55, 5 December 2017 (UTC)
Because not everyone is using a Linux box with xkbconfig and without Gnome IBus overriding all other keyboard interfaces and ignoring ~/.XCompose configurability as too hard. And sometimes people need to use a character that's not in the keyboards they have configured, or for which they haven't memorised the <dead_circumflex><compose><shift><hyphen><j> dance to get ʲ. If you want "It works for me therefore everyone else is doing it wrong", you know where to find systemd. This "extreme step" of removing alternate and accessible ways of entering characters beyond 7-bit ASCII will not be performed because it is arrogant and wrong-headed. --Catsidhe (verba, facta) 01:36, 6 December 2017 (UTC)

Inviting IABot[edit]

While working on Wikipedia I noticed that they use IABot (InternetArchiveBot) to automatically replace dead links with a version stored on archive.org. The project is a joint effort between the Internet Archive and the WMF (more in this blog article). The project has funding, is developed in the open (github) and has already been deployed on a few Wikipedias. As far as I know it hasn't been used on a Wiktionary instance yet. We don't generate the same amount of external links / references as other Wikis but I think it doesn't hurt to make sure what we have is valid and usable. We need to establish a consensus first so I'd like to get your opinions. – Jberkel (talk) 10:25, 4 December 2017 (UTC)

Thanks, T181879 on Phab if you want to follow up. – Jberkel 11:33, 9 December 2017 (UTC)
Symbol support vote.svg SupportRua (mew) 12:01, 4 December 2017 (UTC)
Sounds good. Equinox 12:24, 4 December 2017 (UTC)
I like this idea. I would also like it if we had more external links, especially in areas like etymology, reconstructed languages, etc. - TheDaveRoss 14:32, 4 December 2017 (UTC)
Symbol support vote.svg Support I always make sure that the URLs of quotes I post are archived. It goes without saying as a thing of the durability ideal. Palaestrator verborum (loquier) 15:53, 4 December 2017 (UTC)
Symbol support vote.svg SupportΜετάknowledgediscuss/deeds 19:19, 5 December 2017 (UTC)
Symbol support vote.svg Support — justin(r)leung (t...) | c=› } 19:31, 5 December 2017 (UTC)
Symbol support vote.svg Support --Barytonesis (talk) 19:37, 5 December 2017 (UTC)

Chinese ordering[edit]

Are there any guidelines about the preferred ordering for Chinese? I cannot find any info. at About_Chinese, and after searching in Category:zh:Grammar I realized how chaotic radical ordering can be, especially when treating simplified and traditional versions individually. I would always include some (alternative) pinyin ordering, which has helped increase literacy a great deal since its implementation. --Backinstadiums (talk) 11:24, 6 December 2017 (UTC)

@Backinstadiums: There are many ways to order Chinese characters. Radical ordering is the common way before the advent of bopomofo and pinyin, and is still the common way for traditional Chinese dictionaries. In recent years, ordering by pinyin has become more common, especially in Mainland China. However, most dictionaries would also have an index ordered in alternative ways. For instance, a traditional Chinese dictionary with radical ordering often has a 難查字表 for characters whose radicals are not apparent. It may also include a pinyin/bopomofo index.
The reason why Chinese categories are ordered by radical here in Wiktionary is because Chinese is not only used for Mandarin, making pinyin/bopomofo sorting unreasonable. The categories for specific Chinese lects, e.g. CAT:Mandarin lemmas and CAT:Cantonese lemmas, are sorted according to their respective romanizations. — justin(r)leung (t...) | c=› } 17:37, 6 December 2017 (UTC)
@Justinrleung: Except if a true semantic conversion were intended, at least traditional and simplified forms should be treated as a single unit for purposes such as ordering, (currently) the traditional one being used as common lemma. Regarding Pinyin, since nowadays it's the most used romanization (and transliteration) system regardless of one's native Chinese lect, it would be truly beneficial to add it as much as possible to spread Chinese literacy. --Backinstadiums (talk) 18:01, 6 December 2017 (UTC)
Symbol oppose vote.svg Oppose
1. Someone looking for 刘 won't find the traditional lemma of 劉 because of the drastically different number of strokes. Sort them independently to accommodate users of both.
2. Not every character has a Mandarin pronunciation. Use Category:Mandarin lemmas to search by pinyin.
suzukaze (tc) 18:36, 6 December 2017 (UTC)
(Chiming in...)
One additional wrinkle is that the MediaWiki software backend appears to only allow sorting by one index key per category. Sorting a given Chinese character by each of the various possible pinyin representations would require a change in the underlying database software, one that the MW devs seem uninterested in tackling.
We've run into this issue with Japanese entries, where a given Chinese-based spelling often entails multiple phonetic realizations, and thus ideally multiple sortings -- see for instance, where we would want the entry to appear in Category:Japanese_nouns, etc., under all of these indices: え (e), かび (kabi), かい (kai), から (kara), つか (tsuka), つく (tsuku), and ほぞ (hozo). Due to how the MW software is programmed, this 柄 character only appears indexed under the last reading, hozo.
Categorizing Chinese characters separately by lect would work for indexing by pinyin reading. But categorizing Chinese characters in a single category, and trying to index by the pinyin readings for all of the lects at once within that one category, is currently barred by baked-in technical difficulties. ‑‑ Eiríkr Útlendi │Tala við mig 18:38, 6 December 2017 (UTC)

Category:English misnomers[edit]

I think that it may be of interest, especially for English learners, to see a compendium for words or locutions that don’t mean what they would imply. To start, we have: strawberry, Rhode Island, East River, funny bone, prairie dog, French braid, Boston cream pie and Hawaiian Pidgin (amongst many other candidates, but I don’t want to exhaust room here). I can’t think of any possible objections at the moment, though some may find the topic too trivial or too uninteresting to merit a category, but I’d like to see others’ thoughts here first. — (((Romanophile))) (contributions) 19:01, 6 December 2017 (UTC)

There will inevitably be disputes about what in particular goes into it but yes, I think that it's fine to have some listing of counter-intuitive words. It may be better suited to an appendix. —Justin (koavf)TCM 19:16, 6 December 2017 (UTC)
I would think that almost any noun phrase (any phrase of any kind?) that was also an idiom would necessarily be a misnomer. DCDuring (talk) 00:07, 7 December 2017 (UTC)
Perhaps even single words that are used in a non-literal sense, depending on how you define "what they would imply". — Eru·tuon 00:10, 7 December 2017 (UTC)
* What does strawberry imply? And how many berries would be exempt from this? cranberry (which do not come in crans), chokeberry, cowberry, hagberry, raspberry, gooseberry, hackberry? (The coffee bean is, of course, the true hackberry, and a real cowberry is of course bullshit.)
* A pidgin and a creole are technically distinct, but nobody but a linguist really cares; it's not really confusing.
* A prairie dog is a sort of dog-like creature that lives on the prairies. It's a wonder of clarity compared to the robin, which can refer to any number of distantly related species of bird.
* I don't see even what you're getting with French braid; it's a hair braid that is called French.
What I'm getting at, is that it seems pretty vague and broad as a category, and given the examples you gave, I don't think it would be terribly helpful to an English learner.--Prosfilaes (talk) 09:58, 7 December 2017 (UTC)
Strawberries aren’t berries, prairie dog aren’t dogs (though all robins are at least birds), and French braids did not originate in France. Even so, I do see that it has the potential to be too big of a category unless we made up some special rules for it. — (((Romanophile))) (contributions) 03:40, 11 December 2017 (UTC)
berry, sense #1 is "A small fruit, of any one of many varieties.". Many things we call berries aren't botanical berries and some things, like grapes, that are botanical berries we don't call berries. French practically needs a definition of "fancy" (though apparently they're called tresse française in French.) Also, French doesn't necessarily mean "originated in France"; it could mean it was "popular in France" or even "associated with France". Also, cf. pineapple braid (another name for the Dutch braid or inverted French braid.) The extreme here is the "canoe wife", a name in English tabloids for a woman whose husband allegedly drowned in a canoe accident (body never found), who moved to Brazil with the insurance money and lived the good life with her husband, until she was extradited back to England for insurance fraud. Hence, "canoe wife". Adjectives have to communicate clearly to the audience, not necessarily make good literal sense.
I'd see a category of things like prairie dog, where the root word is clearly a misnomer in normal English--that is, most people would agree that a prairie dog is not a dog. That seems a reasonable enough and possibly useful category.--Prosfilaes (talk) 16:37, 11 December 2017 (UTC)

Unusual English pronunciations categorized as 1 syllable words[edit]

trousers, thousandth, straighten, Pirc Defence, cat's meow, read receipt. DTLHS (talk) 06:11, 7 December 2017 (UTC)

Pirc Defence is incomplete; cat's meow and read receipt used {{IPA}} instead of {{IPAchar}}. —suzukaze (tc) 06:24, 7 December 2017 (UTC)
In trousers, @Bcent1234 added the 1-syllable category, no doubt by mistake. In thousandth, someone didn't indicate that the n formed a syllable, which can be done with a syllabic diacritic or a schwa. — Eru·tuon 07:09, 7 December 2017 (UTC)

Alternative template that applies the same font formatting as Template:IPAchar[edit]

As part of ongoing maintenance and cleanup work, @Mahāgaja recently made this change to the Japanese 光 entry, replacing a call to {{IPAchar}} with {{l|und}} instead. This was due to the inclusion of <sub> tags in the string formerly contained by {{IPAchar}}. Talking things over with him, I understand his reasons and have no objection. (That thread is here for those interested.)

One issue that remains, however, is font formatting. {{IPAchar}} results in text at 15.4pt, while {{l|und}} produces 14pt. I could manually add in a <span> tag specifying class="IPA" to do that, but I wanted to ask first if anyone is aware of some other template that would apply a 110% font size?

(And if this query should go in the Grease Pit instead, I'm happy to move it.)

TIA, ‑‑ Eiríkr Útlendi │Tala við mig 22:12, 7 December 2017 (UTC)

I don't know if it is correct to consider this notation IPA, even though all but the subscripted vowels at least belong to the IPA character set. Perhaps it would be better to consider it as Old Japanese text (though it is a transcription system for the actual man'yougana used to write Old Japanese), tag it as Old Japanese ({{m|ojp||...}} or {{m|ojp|...}} depending on whether there will be entries), add Latin as a script for Old Japanese in Module:languages/data3/o, and assign the desired styles to Old Japanese written with Latin script in MediaWiki:Common.css? — Eru·tuon 22:59, 7 December 2017 (UTC)
Apologies, I'm not married to the idea of IPA-ness at all -- I merely want the text to appear in the same font and at the same scaling as the /slash-transcription phonemic string/ IPA text that follows it on the same line. The w:International Phonetic Alphabet article describes using ⟨angle brackets⟩ for non-/phonemic/ and non-[phonetic] transcriptions meant to indicate the ⟨original-language orthography⟩, which would seem to make sense for Old Japanese strings like this with the numeric subscripts -- but as Mahāgaja argued, we probably don't want to use {{IPAchar}} for angle-bracket orthographic strings (which makes sense to me).
I hope that clarifies -- I'm not looking for IPA per se, just something that formats similarly for visual consistency. ‑‑ Eiríkr Útlendi │Tala við mig 00:28, 8 December 2017 (UTC)
What are these pronunciations? What system do they follow? Does that system have a name? What symbols can and can't appear in them? If there are multiple answers to these questions multiple templates should be created. DTLHS (talk) 00:53, 8 December 2017 (UTC)
@DTLHS: One system, symbols used would be a subset of ASCII lower-case letters, whitespace, and subscripted 1 and 2 to indicate differences apparent in w:Jōdai Tokushu Kanazukai and apparently indicating phonemic differences lost in the Japanese language during the w:Heian period (roughly the 900s-1000s CE).
Not sure why we'd need multiple templates; all I need is something that formats the font, and that is ideally more elegant in the wikicode than <span class="IPA">using raw HTML</span>.
You may only need something that formats the font, but other people may appreciate knowing explicitly how some string of symbols is to be interpreted and what its source is. DTLHS (talk) 01:11, 8 December 2017 (UTC)
Ah, yes, that I agree with -- I'd missed your intent earlier. The subscripted numerals are described in w:Old Japanese, which is linked to already by the {{inh}} template that should be right nearby, as at 光#Japanese, Etymology 1; is that not insufficient? ‑‑ Eiríkr Útlendi │Tala við mig 20:07, 8 December 2017 (UTC)
If no one is aware of any extant template (besides {{IPAchar}}) that does this, I'm happy to make a new one. ‑‑ Eiríkr Útlendi │Tala við mig 01:03, 8 December 2017 (UTC)
I'm pretty sure that {{IPA}} and {{IPAchar}} and other pronunciation templates are the only ones add the IPA class. But once again, I do not think it is correct to label this transcription IPA. It would be better to tag it as Old Japanese written in the Latin script, and to apply the desired styles to that language–script combination. — Eru·tuon 01:27, 8 December 2017 (UTC)
I realize I've confused the issue. I'm happy using some other class -- class="IPA" just happens to be the only one I know of right now that I'm sure applies the font styling I want. Looking at the rendered HTML in Chrome's "Inspect" view, I don't think this CSS class does anything to label the text as IPA: it just sets font and line height styling. I have no interest in labeling the romanized OJP text as IPA; Mahāgaja's arguments against doing so have already convinced me of that.  :) My reservation about using something like {{m|ojp|...}} is that, in my specific use case (including romanized OJP to show phonetic development through to modern JA, as at 光#Japanese), I want the font to match the IPA strings that immediately follow on the same line, and this font configuration might not be the ideal for other use cases. ‑‑ Eiríkr Útlendi │Tala við mig 20:07, 8 December 2017 (UTC)
I’d support the creation of such a template; it’s also needed for Egyptian entries like tꜣwj, where the reconstructed pronunciation is generally IPA but also includes a wildcard V for unreconstructible vowels. — Vorziblix (talk · contribs) 14:44, 11 December 2017 (UTC)
Actually, the error messages seem to suggest IPAchar is complaining about the numbers, not the HTML: invalid IPA characters (1). —suzukaze (tc) 00:36, 8 December 2017 (UTC)
For reasons of both aesthetics and consistency, I'd rather this ojp transliteration used the Unicode subscript numerals ₁ and ₂ rather than normal 1 and 2 with subscript markup, but since ₁ and ₂ are also not valid IPA characters, doing so won't solve the immediate problem. —Mahāgaja (formerly Angr) · talk 13:27, 8 December 2017 (UTC)
Hmmm, I find that the Unicode subscripts are too small -- I have trouble seeing them clearly, and my eyes aren't that bad. I also find they scan less well -- 1 extends below the line somewhat, thereby standing out better, whereas ₁ is mostly within the line of the text and thus (in my opinion) too unobtrusive. Either way though, as you note, we need to find something other than {{IPAchar}}. ‑‑ Eiríkr Útlendi │Tala við mig 20:07, 8 December 2017 (UTC)

Mandarin tone-related phenomena[edit]

I'd like to know whether tone-related phenomena is explained somewhere, and if not I propose creating some notes for users. Secondly, 小姐 shows xiǎojie as a "toneless variant", yet A Grammar of Mandarin by Jeroen Wiedenhof states that in a bisyllabic word written with 2 characters, both with citation 3T, modern Mandarin varies: 小姐 Miss [2.0] xiáojie, 表姐 elder female cousin [2.3], 姐姐 elder sister [3.0]. Xiáojie is also shown by Colloquial Chinese A Complete Language Course --Backinstadiums (talk) 11:18, 8 December 2017 (UTC)

You are focusing too much on the details. It's great that you are looking up reference phonetic material on the pronunciation of Mandarin, but as a learner of Mandarin, please bear in mind that the '3-3 → 2-3' tone sandhi in Mandarin is a natural process that even native speakers may not be able to notice or characterise. For '3-3' words with non-obligatory toneless second syllables, there is nothing that will make you un-understandable by pronouncing the tones clearly without sandhi. In fact, if your tones are accurate (which is absolutely paramount for learners), pronouncing the words 小姐 and 表姐 slowly and clearly, without sandhi, will give the unfamiliar listener the impression that you are a learned speaker. The sandhi will come naturally when you have become sufficiently familiar with pronouncing full '3-3' sequences such as 表姐; it should not precede the latter. Actually, intentionally pronouncing '3-3' as '2-3' as a learner would lead to confusions. e.g. 網友 could be understood as , especially considering that learners generally tend to enunciate the syllables very slowly. When the second syllable of a '3-3' sequence is optionally reduced, both the 3-3 and 2-3 forms can be weakened, resulting in 3-· and 2-·, the former used in careful speech and the latter in fast speech. In normal speech it is probably somewhere in between the two. I don't really think it needs to be further explained- learners should try to use the unreduced pronunciations unless the word is obligatorily toneless like 姐姐. Plus please avoid the word 小姐 altogether because of its negative connotations. Wyang (talk) 14:03, 8 December 2017 (UTC)
@Wyang: Since the author said "historical compounds now highly lexicalized" I think it's worth classifying such a group (to which terms such as 小姐 Miss [2.0] belong) withing Category:Mandarin_words_containing_toneless_variants --Backinstadiums (talk) 15:13, 8 December 2017 (UTC)

Happy Birthday Wiktionary![edit]

Happy Birthday Wiktionary! Message from Katherine Maher, Executive Director of the Wikimedia Foundation

VGrigas (WMF) (talk) 14:39, 8 December 2017 (UTC)

Thank you! —Justin (koavf)TCM 23:12, 8 December 2017 (UTC)
Cheers! How many candles on the birthday cake? DonnanZ (talk) 00:56, 9 December 2017 (UTC)
15, I should have listened to the audio. DonnanZ (talk) 01:00, 9 December 2017 (UTC)
🎂 It depends on your platform! [5] Equinox 04:39, 9 December 2017 (UTC)

Proposal: public polls[edit]

Sometimes there are matters that strongly affect the user experience, and it would be valuable to ask the ordinary users what they want. I therefore propose that we implement an option to hold public polls, which are shown to all users who visit Wiktionary, whether logged in or not. In these polls, we would ask simple questions such as "which layout do you prefer" or "do you think this feature is valuable". There would be a maximum of one public poll at a time, and they would run for a duration of two months (subject to discussion of course). Starting a public poll should not require majority consensus, to prevent reactionary users from sabotaging the process.

I have no idea how this would actually be implemented, but I'm sure there are people who can help with that. —Rua (mew) 22:38, 8 December 2017 (UTC)

In principle, it's not hard to put a banner on the top of each page--we already have one: MediaWiki:Sitenotice. —Justin (koavf)TCM 23:12, 8 December 2017 (UTC)
But a poll is quite different. It would involve saving people's answers somewhere, and also remembering who voted. —Rua (mew) 23:14, 8 December 2017 (UTC)
Are you suggesting that the poll be in the header? I am suggesting that the site notice have a link to a poll and that is documented elsewhere. —Justin (koavf)TCM 23:42, 8 December 2017 (UTC)
Hmm. I figured that the poll would be directly located on the page somewhere, like in the bar on the left. That way users can just click their option without being taken away from where they want to be. —Rua (mew) 23:57, 8 December 2017 (UTC)
Ah. I see what you mean now. MediaWiki can certainly have polls and record user answers--e.g. see Wikia. Not sure if it's desirable or if we want some barrier to entry of some kind but it's definitely possible. —Justin (koavf)TCM 00:04, 9 December 2017 (UTC)
  • Good idea. Probably the best we can do and still continue to bend over backward to convey the idea that WMF projects respect and guard user privacy. Would we limit participation to registered users? Would a checkuser be available and willing to make sure there wasn't sock-puppetry skewing the results?
"Majority consensus" conflates two decision principles. Consensus usually means well more than a simple majority. In practice, we have had various levels for "consensus" here, varying over time and across types of decisions. I would think that a simple majority would suffice for something like this. We could start with no vote required and see how it goes. DCDuring (talk) 15:35, 9 December 2017 (UTC)

vulgar passages in quotes[edit]

I don't know if this has been discussed already but why do so many of the quotes for English terms have to reference very vulgar or obscene sexual material, often from homosexual novels and the like? Is this just meant to be provocative and "edgy" for the sake of it, or to show that it's okay and normal, or to push the envelope? Is it part of some agenda? Is it some statement about the nature of this site being one where people can freely contribute? I don't get it. Not that I have anything against homosexuality but some of these passages (equally including those that reference straight interactions) are a bit much for people to read if they're just casually looking at a dictionary, and I feel it may make some people take Wiktionary less seriously, making it rather juvenile and akin to something like Urban Dictionary. Word dewd544 (talk) 04:50, 9 December 2017 (UTC)

Any examples? If a term itself is vulgar the quotes will probably also be vulgar. DTLHS (talk) 04:51, 9 December 2017 (UTC)
In some cases Wonderfool has added this kind of thing for a joke (e.g. the erotic passages from Fanny Hill, and I remember a news article about a kitten being microwaved). In other cases (slang) some words just tend to appear in these contexts. I try to favour "neutral"-feeling citations where possible. Equinox 04:55, 9 December 2017 (UTC)
The The Fanny quotes are all excellent! Especially for amorous/old-fashioned terms like straddle, indriven, unbonneted, house of accommodation, throb, supinely. But the sexual quotes for daily words like prove, unnecessary etc. are probably not the best ideas. As for the quotes about the cat in the microwave, that was pretty funny. This Wonderfool character seems like a cool type of chick (I assume she's a chick, anyhow...). --Lirafafrod (talk) 11:08, 12 December 2017 (UTC)
I definitely think we should give a strong preference for non-shocking quotations (cf. w:en:WP:EGG). There is no reason for vulgar or graphic quotations for words other than vulgar and graphic ones. —Justin (koavf)TCM 05:00, 9 December 2017 (UTC)
It might be worth saying: we're not a corpus, and we don't have an obligation to keep any particular quote if it can be replaced and if it's not notable in some way, like the first known usage of a word. DTLHS (talk) 05:01, 9 December 2017 (UTC)
Vulgarity seems to cast too wide a net. To clarify what I imagine is the intent: Don't we mean "obscene", "disgusting", and/or "not suitable for small children"? I've felt and mostly repressed the urge to remove such quotes.
A problem arises with certain polysemous terms which have many ordinary definitions but some that are disgusting or luridly sexual. For such problematic definitions a practice of not having any usage examples (which display by default) and no excessively disgusting citations (which are hidden by default) might suffice. DCDuring (talk) 15:50, 9 December 2017 (UTC)
I could add much more vulgar quotes as I use to hear rap music, like I have done on dog bone.
I think the general solution is to move quotations to citation pages – I don’t want a moral cleansing to be started because “we don't have an obligation to keep any particular quote”. Do not be a puritan. Sexual references form a great part of what people talk and have useful subtile differences. The measurement line might be: A reference should not be moved because of being boorish, but if it is contra bonos mores, as would be enough for a contract to be void. Palaestrator verborum (loquier) 16:37, 9 December 2017 (UTC)
Ah yes, wrapping oneself in the flag of free expression. I think we lavish much more attention on some "subtle" differences for sexual terms than on, say, those involving a word like, say, seem. I suspect that the entire reason for the differential attention is a differential in hormonal response within the contributors to the prospect of working on the two types on entries. I rather doubt that any consideration of the users of an entry, especially those of an age different from the contributor becomes involved. DCDuring (talk) 18:23, 9 December 2017 (UTC)
I am not sure what you mean with those hormonal responses and with the “free expression”. If I hear rap music I, I add quotes from rap music, and users who hear Pop add Pop music quotes. The former is even more valuable because there are the gaps of Wiktionary whilst there is else hardly an English word found not in Wiktionary (consider Grime or Drill with Multicultural London English). But I am not free to change what music pleases me and I doubt that you know much about how hormones lead the editing habits of Wiktionarians. And what I am particularly not free in is to choose the sources which I stumble upon. Better give that durable quote for dog bone than to leave it out because some people are more sensitive and there could be a less edgy one. There should be more cases when people should be thankful for seeing the quote than pitying themselves for having endeavored to read it – and disgust can also be mixed with thankfulness for having read an example. That is another way how you could discriminate the cases considering the user. Palaestrator verborum (loquier) 22:31, 9 December 2017 (UTC)
I also dislike censorship but I think the point here is to avoid vulgarity if it is unnecessary, e.g. when citing an everyday word like "umbrella". Equinox 06:22, 10 December 2017 (UTC)
Sorry, I meant excessive obscenity rather than vulgarity. That more accurately describes what I'm getting at here. I actually had a feeling much of it was part of some kind of practical joke by some user a while ago and then no one really bothered to change them. It doesn't really bother me that much personally (in fact I'm far from puritanical in my daily life and don't hesitate to use some of this language) but I could see how that would annoy some people and draw them away from the project. It almost seems like some of the editors were purposely going for shock value. I could also invoke the whole "not safe for work and not safe for kids" thing, but realistically, it's hard to keep kids away from seeing certain kinds of content online. And yes, of course words that are meant to be obscene by definition would obviously have these kinds of quotes, but I do recall coming across several where it was uncalled for. I'll have to go and find some specific examples. And I also get that there is freedom of speech, which is perfectly fine, but this is still a user-modified project, like Wikipedia, one in which a consensus of informed people generally decide on what ends up being presented. Word dewd544 (talk) 07:06, 12 December 2017 (UTC)

Doubt about recent Persian, Middle Persian, Yaghnobi, Tajiki and Arabic entries and edits[edit]

I'm really worried about recent edits and entry creations in these languages. Kaixinguo~enwiktionary (talk) 18:19, 9 December 2017 (UTC)

@Kaixinguo~enwiktionary Me too, even though I don't speak Persian, Hindi entries need good Persian entries for etymology. I think @Rajkiandris should explain himself, since he has added thousands of Yaghnobi, Tajik, and Persian stubs with incorrect formatting and etymologies, and now he doesn't respond to queries on his talk page. Some of his edits are, frankly, totally wrong.
As for Arabic, I actually think the entry quality has improved a lot recently, thanks to the better treatment of dialects and good work by new contributors. —AryamanA (मुझसे बात करेंयोगदान) 22:53, 9 December 2017 (UTC)
So what are you worried about in Arabic entries? The increase in quality I have felt for Arabic since I have registered two months ago has been according to my gut-feel 30%. I have always patrolled the edits in Arabic, corrected the template usage (even added and edit reference templates), added many good etymologies (see ت ر ج م (t r j m), this has not been seen before), removed the {{etyl}} completely from it, emptied Category:Arabic entries needing vocalization (though this some random IP did too), Category:Arabic terms needing Arabic script, Category:Arabic form-I verbs with missing non-past vowel in headword, and added about 400 additional entries of high quality belonging to the 9200 in Category:Arabic lemmas now, and almost 200 quotes with translations, and a significant number of images. I use all sources available and as a rule add only words I read.
I had on that occasion also cleaned up some Persian etymologies. Today you have changed the transcriptions of the Persian in إِبْرِيق (ʾibrīq) and its reborrowed descendant ابریق but I have only copied the transcription of the Persian word as it was found before, this plays surely a role in that you talk here now. I don’t know Persian to say what transcriptions are good and Wiktionary:About Persian#Transliteration does not say anything meaningful about it. Perhaps you should mention the minimum standards in it. I have just three days ago cleaned it up from some instructions that were wrong, and I have much improved Wiktionary:About Arabic. Also, who will clean up {{etyl}} in Persian? Now I have removed it from Arabic it can’t be used anymore, but Persian? You seemingly refer to edits Rajkiandris (talkcontribs) but I have not seen him adding Arabic. @Kaixinguo~enwiktionary Palaestrator verborum (loquier) 22:55, 9 December 2017 (UTC)
I'm not referring to those romanisations; that kind of thing happens all the time. No one can monitor everything that's going on, perhaps it was wrong to include Arabic. I'm just talking about a general impression. I am sorry if I have given you the impression that I am referring to you. Kaixinguo~enwiktionary (talk) 23:26, 9 December 2017 (UTC)
So how have you formed the impression? I know what has been going on the last two months in Arabic and there hasn’t been anything needing reproval. Palaestrator verborum (loquier) 23:42, 9 December 2017 (UTC)
I literally just said maybe I shouldn't have included Arabic so let it go.Kaixinguo~enwiktionary (talk) 23:45, 9 December 2017 (UTC)
Ok, I let it go, but your submission is still underspecified. I don’t know what you want people to do. People probably prefer not to extract the notions you know but others don’t. You won’t get sudden contributors proficient in those languages who will perform some thorough reviews of the language treatment. Palaestrator verborum (loquier) 00:06, 10 December 2017 (UTC)
@Kaixinguo~enwiktionary: If you complain about quality in a public place, you have to give some examples. Which of the recent entries in CAT:Persian lemmas, CAT:Tajik lemmas, CAT:Arabic lemmas, etc. seem wrong? Or is it some translations from English? --Anatoli T. (обсудить/вклад) 00:26, 10 December 2017 (UTC)
@Atitarev: See User talk:Rajkiandris and Special:Contribs/Rajkiandris. While most of the entries and edits don't have wrong definitions per se, the quality of edits is not up to par (not using templates, wrong Proto-Iranian reconstructions, incorrect sorting of descendants, no transliterations for Middle Persian, etc.). Combined with the massive volume of edits that (s)he has done, the overall quality of Yaghnobi and Tajik entries especially has deteriorated. Also, much like Gfarnab, they edit in languages that don't even know anything about; I had to revert a dozen Konkani entries of his a while ago. —AryamanA (मुझसे बात करेंयोगदान) 00:33, 10 December 2017 (UTC)
I see, thanks. Having an editor editing in a language nobody can check, like Yagnobi is even more dangerous. --Anatoli T. (обсудить/вклад) 00:38, 10 December 2017 (UTC)
I have left a warning on his talk page. I ask that any of you with expertise or resources in any of the languages he has worked on to help assess or clean up his entries. —Μετάknowledgediscuss/deeds 00:56, 10 December 2017 (UTC)
We should require @Rajkiandris to proffer some quotations with translations in Yaghnobi or at least Tajik where he should find enough – I mean, speaking to @Rajkiandris, you should add quotes with translations. If you do, you can affirm an impression of knowledge of these languages; if not, it is also good, for Wiktionary, because it only increases the notion that you only copy linguistic material without sufficient exposal to the language itself, and we can ostracize you. So add quotes if you want to be taken seriously and your entries to have a long life. For now it is in the realm of the possible that “created by Rajkiandris” will be an argument in itself in proposals for deletion. Palaestrator verborum (loquier) 01:34, 10 December 2017 (UTC)

Synonyms under corresponding senses - stop of switching[edit]

In Wiktionary:Beer_parlour/2017/May#Poll: putting "nyms" directly under definition lines, there is a preliminary consensus for using a new synonym format but only under the condition that the synonyms become hidden, meaning collapsible. There is not consensus, not even a supermajority, for non-collapsible synonyms under corresponding senses. An example entry that I think currently looks horrible due to the new format is cat.

I propose that switching to the new synonym format stops until the collapsing of synonyms is implemented. --Dan Polansky (talk) 13:24, 10 December 2017 (UTC)

I agree with cat looking horrible. However it would not be a solution to use the synonyms section. It looks bad too and would look worse without {{syn}}. This template kin need fixed. And before a hiding can be made, it would work out well to decrease font-weight and font-size. But {{sense}} + synonyms looks worse than {{syn}} with arguments does.
For reference only I link here Wiktionary:Beer parlour/2017/November#Independent Synonyms section, or {{synonyms}} under each relevant sense?. Palaestrator verborum (loquier) 15:03, 10 December 2017 (UTC)
this revision of cat entry (31 December 2016) looks okay as for synonyms, using the old/current format. What looks even better is this revision (26 December 2011), where the some of the rather dubious synonym lines are absent. --Dan Polansky (talk) 15:15, 10 December 2017 (UTC)
If I apply the arguments consequently, I reason that we should not list synonyms at all in pages as long as they are not hidden in the Thesaurus namespace or in a drop-down menu. Thesauri are else separate products from dictionaries that are not included even in the greatest dictionaries. Palaestrator verborum (loquier) 15:29, 10 December 2017 (UTC)
I don't know what to say or where to begin; the above does not make any sense to me. --Dan Polansky (talk) 15:47, 10 December 2017 (UTC)
What’s so complicated? Currently both the synonyms section and {{syn}} look bad. If these things are hidden, they look better. Thus there is an argument for not adding synonyms at all as long as {{syn}} is not fixed (for one does not make a Thesaurus entry for all things either). Which does not mean that other reasons – the usefulness – outweigh the aesthetic argument leading to the conclusion to use a synonym section or {{syn}} anyway. Palaestrator verborum (loquier) 15:57, 10 December 2017 (UTC)
Re. "Thus there is an argument for not adding synonyms at all as long as syn is not fixed:" There is no such argument. I am not proposing to stop adding synonyms. I am proposing to continue the original practice of adding synonyms to their dedicated sections, as still codified in WT:ELE. I am proposing that all switching should stop until collapsibity is implemented, consistent with the referenced poll. I said these things above. --Dan Polansky (talk) 16:02, 10 December 2017 (UTC)
Help me test nym-hiding by adding the following line to your custom javascripts:
importScript("User:Ungoliant MMDCCLXIV/synshide.js");
Ungoliant (falai) 17:49, 10 December 2017 (UTC)
What do I have to do for it? I haven’t ever used custom javascripts, and when I search for it I find plenty. Palaestrator verborum (loquier) 18:31, 10 December 2017 (UTC)
@Palaestrator verborum: click here, and copy paste what Ungoliant wrote. --Per utramque cavernam (talk) 18:37, 10 December 2017 (UTC)
@Ungoliant MMDCCLXIV It works on cat, but not on Geck or anmachen – there the synonyms and antonyms just vanish. Palaestrator verborum (loquier) 19:06, 10 December 2017 (UTC)
Another issue: cottage cheese DTLHS (talk) 19:26, 10 December 2017 (UTC)
@Palaestrator verborum, DTLHS, thanks. It was a really dumb mistake... should be working now. Please use my talk page to report problems, and we’ll announce here when everything starts working properly. — Ungoliant (falai) 19:30, 10 December 2017 (UTC)
@Ungoliant MMDCCLXIV Thank you! Having synonyms displayed so prominently under definition lines was driving me crazy. Andrew Sheedy (talk) 22:09, 10 December 2017 (UTC)


Hello. When a French term is a borrowing of an English term, which itself is a borrowing of an Old French term, does it qualify as a "reborrowing"? I don't know if I can add French square to CAT:French twice-borrowed terms. --Per utramque cavernam (talk) 21:20, 10 December 2017 (UTC)

You don’t have to add to the category yourself. It happens when you use {{der|fr|fr|}}. Palaestrator verborum (loquier) 22:14, 10 December 2017 (UTC)
And if doesn’t happen with {{der|fr|fro|}}, I think it is an error. Palaestrator verborum (loquier) 22:15, 10 December 2017 (UTC)
It seems like the collection of doublets and of reborrowed terms overlaps. Palaestrator verborum (loquier) 22:17, 10 December 2017 (UTC)
Yes, I think that these are reborrowings. The word reborrowing presupposes the identity of the language, because the prefix “re” signifies retreat to a state the subject had, i. e. when it existed as such. So words which English has from the Latin spoken in Gallia cannot be reborrowings because French does not represent the successor of Latin; but if Old English has taken a word from Old French it can be a reborrowing, because French represents the successor of Old French (the people then thought of Old French as French, it has the same identity, though we shall see it ex post) – not relevant if English is the sole successor of Old English –, and words which Indo-European has borrowed from Proto-Semitic cannot be “reborrowed” by Arabic. Palaestrator verborum (loquier) 22:26, 10 December 2017 (UTC)
That argument makes no sense. There is no notion of successors with languages the way there is with countries. Basing it only on the name is unlinguistic. There is nothing that entitles French to more than say, Walloon. Both are linguistically descendants of the same language. —Rua (mew) 23:00, 10 December 2017 (UTC)
Which means the things OP described are not reborrowings. Question solved. Palaestrator verborum (loquier) 00:13, 11 December 2017 (UTC)
But it looks like it is not easy to fix with the current system of language data to cause {{der|fr|fro|-}} to categorize into reborrowings but {{der|fr|itc|-}} not. Palaestrator verborum (loquier) 22:31, 10 December 2017 (UTC)

request to add to WT:AWB[edit]

user:rajasgored, because I don't like flooding Recent Changes. —suzukaze (tc) 07:11, 12 December 2017 (UTC)