Wiktionary:Beer parlour

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:BP)
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 +/-


May 2014[edit]

Proposal: Simple Template for Categorization[edit]

As has been noted many times, using {{context}} to categorize often leads to strange things like common names for plants being labeled with (botany) even though botanists are the ones least likely to use them.

Why don't we create a template called "cat" to make topical categories that takes two positional parameters: the language code and the category name (maybe additional parameters would be additional cat names), with maybe a named parameter for the script.

Aside from the really obvious and intuitive name, that would have the advantage of not having to type [[Category: in front of everything, and it would allow checking of the language code and standardization of cat names via Module:labels. People would be able to categorize without cluttering the definition line, and context abuse would be reduced.

Thoughts? Chuck Entz (talk) 16:39, 2 May 2014 (UTC)

I like this idea, but I think the template should be named {{topic}} or similar. --WikiTiki89 16:47, 2 May 2014 (UTC)
We already have {{catlangcode}} and {{catlangname}}. —CodeCat 16:51, 2 May 2014 (UTC)
But those are even longer to type. --WikiTiki89 16:52, 2 May 2014 (UTC)
We can rename them or make redirects. I was just pointing out that we have templates already, in case anyone decides they want to make something. —CodeCat 17:00, 2 May 2014 (UTC)
So do you think we should redirect {{topic}} (and perhaps also {{top}}) to {{catlangcode}}? --WikiTiki89 17:03, 2 May 2014 (UTC)
I like the idea. Any short name would do, at least for a redirect, but "cat" seems very appealing. DCDuring TALK 21:29, 2 May 2014 (UTC)
"cat" is too vague, it doesn't have anything apparent to do with topical categories specifically. {{topics}} would probably be most fitting (plural because it can take multiple names), and it's still shorter than typing the categories out manually. —CodeCat 22:01, 2 May 2014 (UTC)
Oh, apparently I already created that... —CodeCat 22:02, 2 May 2014 (UTC)
That'll do fine. DCDuring TALK 22:10, 2 May 2014 (UTC)
What about just {{c}}? DTLHS (talk) 22:19, 2 May 2014 (UTC)
Note also the existence of template:categ (which must be substed and works for all sorts of language-specific categories, not only topical categories).​—msh210 (talk) 06:06, 4 May 2014 (UTC)
…and which doesn't seem to work any longer. (?!)​—msh210 (talk) 06:10, 4 May 2014 (UTC)

Automatization of German conjugation table[edit]

This discussion is put in both BP and GP because it involves both policy discussions and technical issues.

I am planning to make the German conjugation tables automatic. Module:de-conj has been built to realize this, but one must note that the module is not yet complete. For whatever reasons, Angr became the first user other than myself to actually use this template in an entry. Kephir helped me to simplify the codings of the module. The template calling this module is Template:de-conj-auto. The discussion below (if any exists) shall be about a few things:

  1. To actually use automatization or not.
  2. The usage of this template. It has been put in Template:de-conj-auto/documentation as a reference. The main rule I follow is to let the concatenation of all the parameters be equal to the page name itself. However, I am open to all potential changes which can improve it.
  3. Where to put the template. Currently, the template is located at Template:de-conj-auto instead of Template:de-conj because it already exists. However, if all German conjugation tables are automatized, it can be actually moved to Template:de-conj.

Of course, the discussion can be about anything related to this topic, other than the three points listed above. Examples of usage is located at Special:WhatLinksHere/Module:de-conj. --kc_kennylau (talk) 10:00, 10 May 2014 (UTC)

Categorize German compounds by components[edit]

Does anybody support adding Haushaltgerat to the categories Category:German words compounded with Haus, Category:German words compounded with halten and Category:German words compounded with Gerat? Does anybody support adding abtun to the category Category:German words compounded with tun? Or should the words "compounded with" be replaced with "derived from"? I'm aware that it would create many new categories. --kc_kennylau (talk) 04:09, 11 May 2014 (UTC)

First of all, I think you meant Haushaltsgerät. More importantly, your naming scheme is based on a misunderstanding: when you say "compounded with x", you're really saying "added to x", not "containing x": Haushaltsgerät would only be in Category:German words compounded with Haus if there were a compound such as "*Haushausaltsgerät". Chuck Entz (talk) 04:27, 11 May 2014 (UTC)
I thought it's Haushalt +‎ Gerät so it should be in Category:German words compounded with Haushalt and Category:German words compounded with Gerät? If "compounded with" isn't the phrase to be used, then can you suggest one? I'm not a native English speaker. --kc_kennylau (talk) 04:34, 11 May 2014 (UTC)
A better naming scheme would be Category:German compounds containing Haus, but I'm not sure if it's a good idea: It's so easy to form compounds in German that we should avoid even the possibility of encouraging the creation of SOP entries for the purpose of filling out categories. Chuck Entz (talk) 04:44, 11 May 2014 (UTC)
Even English compounds aren't organized by the words they contain; Category:English compound words has subcats for the type of compound, but not for the terms used in compounding. —Aɴɢʀ (talk) 14:43, 11 May 2014 (UTC)
But English doesn't have as many compounds as German. See tun. --kc_kennylau (talk) 16:14, 11 May 2014 (UTC)
Abtun is definitely not a compound, it is a trennbares Verb. Compound (Zusammensetzung) infers syntactic comparability, whereas a trennbares Verb is built by means of a præfix. The latter case is comparable to English phrasal verbs in structure. The uſer hight Bogorm converſation 15:20, 23 May 2014 (UTC)
I oppose creation of these or similar categories. Haushaltsgerät can be placed to Derived terms section of Haushalt and Gerät. --Dan Polansky (talk) 19:02, 11 May 2014 (UTC)
Why do you oppose? —CodeCat 19:11, 11 May 2014 (UTC)
I generally oppose creation of a huge number of rather small categories that are intended to supplant the direct content of Derived terms sections. There was a similar discussion before: Template_talk:derv#Deletion_debate. I am not sure I can articulate why I dislike having hugely many small categories; at least as a matter of taste, I just don't like it. --Dan Polansky (talk) 19:31, 11 May 2014 (UTC)
I concur with Dan Polansky and æqually oppose the creation of numerous superfluous categories, in virtue of the applicability of the derived terms section. The uſer hight Bogorm converſation 15:20, 23 May 2014 (UTC)

Wiktionary:Requests for moves, mergers and splits/Unresolved requests/2011#Category:English nouns ending in "-ism"[edit]

Although I was involved in this discussion, I do not see how it can objectively be read other than as expressing a consensus to merge Category:English nouns ending in "-ism" into Category:English words suffixed with -ism. Does anyone disagree with this reading of consensus? If not, I will begin to implement this merge within the next few days (or, of course, anyone else who wants to can beat me to it). bd2412 T 18:45, 12 May 2014 (UTC)

Hearing no objection, done. Cheers! bd2412 T 20:35, 14 May 2014 (UTC)
I just realized that I used the wrong AWB edit summary for the entire run, but, oh well. bd2412 T 02:07, 15 May 2014 (UTC)

Template:sense changes[edit]

Ignoring the lack of consensus exhibited in the major discussion of {{sense}} at WT:Beer_parlour/2013/April#Template:sense, CodeCat has, without bothering to try to build a consensus, simply imposed her favorite change. That change was not even the most favored one at the discussion. The change shows a lack of awareness of the nature of the problem.

The change is unsatisfactory in the numerous cases where {{sense}} uses a label rather than a gloss.

The template now yields results like (zoology): for {{sense|zoology}}.

Some technical effort that went into allowing users to customize the appearance was wasted as the problem is not user preferences as much as it is variation in the nature of the content of {{sense}} as it is now used. Until some consensus on a good design for this is reached, could this simply be reverted? DCDuring TALK 13:26, 21 May 2014 (UTC)

CodeCat's change was made in good faith, but I agree with DCDuring that it yields undesirable results. The output produced by {{sense}} was already entirely clear and, in addition to being unsatisfactory for use with labels, CodeCat's change adds needless verbiage to every single gloss. Glosses should be as brief as possible. The change should be undone. -- · (talk) 06:15, 23 May 2014 (UTC)
It wasn’t entirely clear. People would often change the glosses of {{sense}} in antonym sections to match the meaning of the antonym. — Ungoliant (falai) 14:56, 23 May 2014 (UTC)
Yes, I've noticed anons doing that relatively often. Equinox 22:31, 23 May 2014 (UTC)
The CodeCat's change should be undone, at least since it is not supported by consensus and is actually opposed. No consensus => status quo ante. --Dan Polansky (talk) 19:10, 23 May 2014 (UTC)
I don't actually have any problem with it being undone. What gets me though is that people are undoing it for the sake of it, not giving any reason. Wikipedia explicitly forbids "I don't like it" arguments, and I think the same should apply on Wiktionary. There should be reasons, and those reasons should be scrutinised. I've seen Dan do this particularly often (just voting "oppose" with no further rationale), but it's a general tendency that others have as well. It goes against the whole process of consensus building if everyone justifies things based purely on personal preference. Consensus can only be formed if everyone understands and accepts the motivation of changes, despite personal preferences to the contrary. Remember that consensus and "liking" are very different things, Wikipedia makes this abundantly clear, and I don't see why Wiktionary needs to have its own distinct definition of what consensus is about. —CodeCat 19:24, 23 May 2014 (UTC)
Re: "people are undoing it for the sake of it, not giving any reason": Except that they're starting discussions wherein they give their reasons. And that you're replying to. While claiming that they don't exist. —RuakhTALK 22:09, 23 May 2014 (UTC)
Well, DCDuring only came here after he undid the change without any kind of explanation about why. That screams "I just don't like it" to me. And Dan still hasn't given any motivation for preferring the original version either. —CodeCat 22:15, 23 May 2014 (UTC)
I absolutely detest this continental pseudo-rationalism, requiring people to give reasons for their preferences in spite of the preferences being most often empirical givens, while the alegged reasons for them are quite often invented implausible falsities. But if you want to have a "reason", I dislike your change since it makes something that was nicely short needlessly long. Why is long bad? I don't know. In any case, I object to the idea that my dislike of a change not supported by consensus is not good enough if it does not come supplied with a reason. I reserve my right to oppose a change while giving no reason whatsoever; if there actually is a consensus for the change, I should easily get outvoted. That said, by cursory browsing votes, you will see how many votes come with no reasoning at all, and how often my votes--in a proper voting process that deserves that I give it some though, where my giving something a thought is my use of my scarce resource--come equipped with a summary of a reason. --Dan Polansky (talk) 22:26, 23 May 2014 (UTC)
I'm not sure what point you're trying to make. When the change was made there was no established consensus that I was aware of, in either direction. It only became apparent that there was no consensus afterwards when there was a revert followed by this discussion. So it doesn't seem fair to complain that I acted against consensus. Advance consensus isn't needed to make edits; the assumption on any wiki is that making changes in good faith is ok, and the edits or discussions that follow are what establishes consensus or lack of it. So I don't see anything being done wrong here, and I don't fault DCDuring either since he did the most reasonable thing in face of a conflict. You on the other hand are coming down on me very heavyhandedly and seem more concerned with "dealing with" me, than with the issue DCDuring presented regarding {{sense}}. —CodeCat 22:38, 23 May 2014 (UTC)
When DCDuring reverted you in diff, that was enough evidence of lack of consensus. You reverted him in diff. Why don't you just undo your change to status quo ante bellum? Please do so now, since there is no consensus for your change, and I oppose your change since (a) I don't like the change, and since (b) the change is not supported by consensus of other editors. --Dan Polansky (talk) 22:44, 23 May 2014 (UTC)
On Wikipedia, from what I've seen, it's quite common for unexplained reverts or other changes to be undone. Also, in consensus building on Wikipedia, votes aren't counted, but the arguments are. I've seen votes pass despite a majority opposing, based on the strength of the arguments. Since I consider that a good way of forming and determining consensus, I followed that line here too. I motivated my change, DCDuring didn't, so based on that I considered my argument stronger and reinstated the edit. A single unexplained revert does not demonstrate a lack of consensus, it just means that one editor felt like reverting for some undetermined reason, which leaves me free to reinstate the edit for equally undetermined reasons. Consensus only follows once there is a discussion of arguments for or against the change. Reinstating may not have been the best course of action, but that's what happened and why. —CodeCat 22:53, 23 May 2014 (UTC)
Since I oppose the change and since I even stated a reason for you (the change makes the result of the template too long), please stop the "you have given no reason" game, and revert to status quo ante. --Dan Polansky (talk) 23:01, 23 May 2014 (UTC)
Re: "I've seen Dan do this particularly often": Diffs please. If I do it quote often, I figure you should have no difficulty finding 7 such diffs. Furthermore, liking is important; you cannot reduce all decisions to objective reasoning. On yet another note, it is you that perform countless illegal bot runs with no justification or reasoning at all, since many of them are run without even a notice at Beer parlour. Here is an example of your "reasoning" (although the link to those horrible liquid threads where one cannot find anything probably does not quite work): A guy asked why did you delete so many categories? And you answered "They seemed kind of pointless to me, like categorising for the sake of categorising." Your pretense that you are somehow providing objective reasoning that justifies your actions is a delusion. --Dan Polansky (talk) 20:19, 23 May 2014 (UTC)
With respect to Dan's behavior, I know of few editors more reasonable and circumspect than Dan Polansky, and it was distinctly unhelpful for CodeCat to steer her remarks into an ad hominem attack on Dan. That's sure not how one conducts a consensus-building exercise. -- · (talk) 22:19, 23 May 2014 (UTC)
Let's just say we differ on that point, then. —CodeCat 22:38, 23 May 2014 (UTC)
What reason do your have for differing on that point? --Dan Polansky (talk) 22:45, 23 May 2014 (UTC)
My past experiences with you. —CodeCat 22:53, 23 May 2014 (UTC)
Do you have any objective evidence to support your experience with me, such as diffs? Am I right to suppose that any past experience with me are on-wiki, and thus diff for that exists? --Dan Polansky (talk) 23:01, 23 May 2014 (UTC)
The message above is just an example. The evidence doesn't need to be objective because it's subjective by nature. I just don't like how you've treated me in the past and present on Wiktionary. Especially not the personal attacks I've had to endure from you. I'm not going to give diffs, but I recall that several people were absolutely disgusted by it. I also received a private email from another well known and respected active sysop with similar complaints about you, from which I quote: "He [Dan] evidently hates you as well, and I think you've got to acknowledge him as an annoyance but not a real threat to your immense value to the community." So I can at least rest assured that my dislike of you is not a personal grudge, but a grievance shared by others as well. And I'm going to leave this discussion at that as I don't think anything I could still contribute to it would be productive in any way. —CodeCat 23:14, 23 May 2014 (UTC)
Do you agree that you have provided no evidence to support your claim that I often oppose with providing no reasoning? Would you agree that talk about personal attacks is off-topic for the purpose of the claim under investigation, viz. that I often oppose without any reasoning? --Dan Polansky (talk) 23:19, 23 May 2014 (UTC)

Per this discussion, I've now reverted.​—msh210 (talk) 08:27, 25 May 2014 (UTC)

@Ungoliant MMDCCLXIV: I agree that the label without "Of the sense" seems to cause contributors confusion, most conspicuously when applied under the Antonyms header. Are the benefits of avoiding the confusion worth the cost in extra verbiage in all the applications where no confusion is apparent? Is there an alternative way to reduce confusion, at least with regard to use under the Antonyms header? DCDuring TALK 13:24, 25 May 2014 (UTC)
My preference is the creation of a new template with the extra verbiage to be used only in antonym sections. But the extra verbiage in every {{sense}} was not so bad considering it fixed a major problem no one else was willing to fix. — Ungoliant (falai) 18:53, 25 May 2014 (UTC)
The only drawback to having different wording for the Antonyms header (whether an option in {{sense}}, eg, ant=1, or a separate template) is the loss of consistency. I wouldn't object to implementation of such a change. If it turned out to be an unsuccessful attempt, the option could be disabled or the separate template could be redirected to {{sense}}. DCDuring TALK 19:59, 25 May 2014 (UTC)
I oppose creating a separate template for antonyms. I acknowledge the existence of the problem of anons sometimes misunderstanding the purpose of the output of the {{sense}} template, but the problem is not serious enough to warrant adding extra wording. I disagree that the fix under discussion was one of a "major problem" (I quote); the problem is quite minor indeed. --Dan Polansky (talk) 20:10, 25 May 2014 (UTC)

Breaking news from Merriam-Webster[edit]

Merriam-Webster has announced the addition of 150 new words - all of which Wiktionary has already had in its compendium for years. Point. Laugh. Yawn. Shuffle off to find a sandwich. bd2412 T 19:41, 21 May 2014 (UTC)

It would be cool if we could trace down the actual earliest cites they mention. For example, they say that fangirl goes back to 1934; it would be great if we could actually find the 1934 cite and add it. (Also, "find a sandwich"? Just lying around in the kitchen or something? Ew. I'd make a fresh one.) —Aɴɢʀ (talk) 14:02, 25 May 2014 (UTC)

Merging some of the category boilerplate templates[edit]

I managed to make a few changes to these templates and it's now technically feasible to merge many of these into a single template. It concerns the following:

Merging wouldn't really change much in the way the templates are used. The main difference would be that you could no longer leave the second parameter empty for root categories. So you'd have to type "parts of speech" and "etymologies" and such explicitly. But that shouldn't be a major drawback I think. The process of merging wouldn't be too difficult, mainly a matter of moving all the current subtemplates to become subtemplates of the new merged template. It's mostly work intensive and time consuming but not really error prone. There might be some errors appearing during the move process, though?

We would need to think of a new name for the merged template. I don't really have any immediate suggestions, but I would prefer something resembling {{topic cat}}. That is, something ending in a space followed by "cat", rather than ending in "catboiler" with no space. We could adopt this name scheme for templates more widely too if there's support for it.

I have also been working on a Lua replacement for these templates, but that's a much larger task and I haven't worked it all out yet. In the meantime, I think this would be a welcome simplification for editors, as it means less template names to remember. —CodeCat 00:52, 22 May 2014 (UTC)

If no one has better suggestions, I think I will merge them all into {{poscatboiler}} for now. It's the largest and most widely used of the templates, and we already call categories named in this way (language name + category name) as "POS categories" in Module:labels/data, so it kind of fits with that, even if it's not the best name. —CodeCat 17:49, 28 May 2014 (UTC)

Done. See WT:NFE for more information. —CodeCat 14:39, 2 June 2014 (UTC)

New L3 for Chinese[edit]

User:Wyang suggests to introduce a new L3 header (at least for single-character) entries - ===Definitions===. Please take a look at this version of , the Chinese section.

It does make sense in complicated cases, when a character has a variety of senses and uses and not all can be easily fit into usual notion of parts of speech. With some effort, perhaps considerable and the result may still be imperfect, it may be possible to split the current definitions into several PoS headers. However, it may be easier to allow this header, similar to the way "translingual" sections were - no PoS, just basic meanings. Thoughts? --Anatoli (обсудить/вклад) 07:02, 23 May 2014 (UTC)

I support for all languages, because WT:FEED has often shown us that newbies have trouble finding our definitions. But I don't know any reason Chinese entries should be different from others.​—msh210 (talk) 05:30, 25 May 2014 (UTC)
Support getting rid of all POS headings. DTLHS (talk) 06:09, 25 May 2014 (UTC)
Potentially ditto, though I'd like to see a specific proposal. Simply replacing all POS headers with ===Definitions=== is not necessarily the best approach. (I note that msh210's proposal does not actually involve getting rid of POS headings; it would just nest them under ===Definitions===.) —RuakhTALK 06:13, 25 May 2014 (UTC)
Well I think my ideal layout would be something like User:DTLHS/export- basically group as many things as possible with their respective definitions (synonyms, translations, etc), put the part of speech information preceding the definition, make the definitions larger and first on the page. DTLHS (talk) 06:35, 25 May 2014 (UTC)
And obviously if there is only 1 etymology you could do away with the Homograph header, and if there are synonyms or antonyms that cannot be mapped to a specific sense they can get their own header as well. DTLHS (talk) 06:42, 25 May 2014 (UTC)
Makes sense. How would quotations and example sentences look? —RuakhTALK 07:22, 25 May 2014 (UTC)
Quite right (Ruakh, 06:13, 25 May 2014 (UTC))! I did not propose being rid of all POS headers. My "I support", above, was for the general idea of a Definitions header as implemented with "it may be possible to split the current definitions into several PoS headers" and not for the other details. Sorry for any confusion.​—msh210 (talk) 08:20, 25 May 2014 (UTC)
Oppose. I don't think we should do away with parts of speech for all senses just because a few may be hard to classify. I think it would make entries considerably messier and harder to look over and understand. We do have at least one catch-all POS header, for things that don't fit any other part of speech: ===Particle===. Whether or not to have a Definitions header in conjunction with POS headers, as msh's page proposes, is a separate question. - -sche (discuss) 05:43, 25 May 2014 (UTC)
I oppose this, at least for now. For one thing, changing the current heading structure specifically for Chinese and not for other languages has not been justified in the proposal. The proposal uses the difficulty of assigning a part of speech as a rationale, but I think that is a truly poor one; no case of such a difficulty has beeing mentioned in the proposal. The best rationale that I can think of is that it would make it easier to find all definitions at one place. However, it would be a sharp deviation from the previous dictionary pratice, at least for English dictionaries; the entry would no longer be structured by words. Yes, that is the point of the current manner structuring, to separate by headings what are different words. On an another note, currently breaks WT:ELE. Ideally, you should now update the entry to align it with WT:ELE and create an example for discussion in your user space. I fear such an update is not going to happen; for the record, I find this manner of procedure fundamentally uncivil. Let me emphasize that the discussed proposal is to get rid of part of speech headings rather than only to introduce Definitions heading; when the section heading says "New L3 for Chinese", that is very misleading, to me anyway. --Dan Polansky (talk) 08:39, 25 May 2014 (UTC)

My ideal format is the one linked to by User:DTLHS. This discussion is proposing that the L3 header "Definitions" be allowed for analytic languages, in which the SoPness of a sense is given an undue amount of emphasis under the current guidelines (i.e. as L3 headers themselves!). The dictionary senses of a Chinese word in other dictionaries are not divided into the SoPs the belongs to before they get divided into senses, but directly by the senses the word has. The issue of fragmenting senses as a consequence of the SoP header constraints becomes more prominent in the case of Chinese characters, as one character may have tens or even hundreds of senses.

For example, ("one") has at least tens of senses. Instead of the current format:


# [[one]]


# [[one]]


# [[first]]
# [[single]]


# [[one by one]]


# [[some]]


# to [[unify]]


# as soon as, once ...

, it would be more logical to show it as:


# (num./n.) [[one]]
#: ...
# (adj.) [[first]]
#: ...
# (n.) [[piece]], [[item]], [[part]]
#: ...
# (adv.) [[one by one]]
#: ...
# (adj.) [[single]]
#: ...
# (adj.) [[same]], [[identical]]
#: ...
# (n.) [[unity]], [[alliance]]
#: ...
# (v.) to [[unite]], to [[combine]]
#: ...
# (adv.) [[once]]
#: ...
# (det.) [[some]], [[several]]
#: ...
# (det.) [[all]], [[every]]
#: ...
# (n./v.) [[start]], [[beginning]]; to [[start]] to, to [[begin]] to
#: ...

. The headword templates (previously, "inflection-line templates") for analytic languages are unnecessary templates, as they do not add any real value to the entry. WT:Templates shows that the intended genuine rationale for the sense division by SoP in the L3 headers (and hence, the formulation of WT:ELE) is to account for differently inflected senses - a Eurocentric stance which has not taken non-inflecting languages into account at all. Wyang (talk) 09:37, 25 May 2014 (UTC)

The format of User:DTLHS/export still structures the entry by different etymologies even if stopping to structure it by different part of speech. Is there a Chinese entry with multiple etymologies? If so, which one is it? How do you propose to format a Chinese entry that has multiple etymologies?
The idea that what you propose is "more logical" (I am quoting) is implausible; it has no bearing to logic AKA study of correct inference at all. What you propose gives, I admit, an interesting and quite neat presentation of information; "neat" is not "logical".
By "SoPness of a sense" you probably mean "PoS of a sense" AKA "part of speech of a sense".
You want to allow a different format for what you called W:analytic languages, but you would probably realize that English is often considered an analytic language (low-inflected language) as well. In Wiktionary, English does not have inflection tables. The neatness (or lack of it) of presentation in what you propose applies to English as well. For highly inflected languages, to format them on the model of what you are proposing, the headword line would no longer contain inflection information and there would be a separate section "===Inflection===" (probably after "===Definitions===", on the same level) in which inflection tables per part of speech would be given, so there really is no Chinese-specific consideration that I can see; the neatness (or lack of it) of your proposal applies to Chinese no less than to English, German and Finnish, as far as I can see.
Re: "The issue of fragmenting senses as a consequence of the SoP header constraints becomes more prominent in the case of Chinese characters, as one character may have tens or even hundreds of senses.": I don't follow this at all. Why does the multitude of senses make the fragmenting into PoS sections more prominent? I think the contrary: in an English entry with 4 etymology sections and only couple of senses per etymology, the separation of definitions by the section headings is often quite annoying, to me anyway. However, to solve this, the structuring by both etymology and part-of-speech would have to be removed. --Dan Polansky (talk) 10:10, 25 May 2014 (UTC)
Words with multiple etymologies would be split by etymology first, each etymology having its own substructure (pronunciation, definitions). The issue of multiple etymologies is less of an issue for Chinese, as one character typically represents one etymology, and mono- and mulisyllabic homophones are usually represented by heterographs.
By logical I mean the formatting ignores the unnecessary (for analytic languages) split-by-PoS-first-then-by-sense guideline. The definition information is kept centralised and users are less likely to be distracted by PoS headers and "inflection-line" templates.
English is definitely not analytic (enough). For instance, reducing the level of inflection information in English headword templates to nil, by setting those templates to {{head|en|PoS}}, would result in a loss of information, whereas doing the same for Chinese headword templates would not.
The fragmentation is more prominent when there is a multitude of senses, because (as said above) it discentralises the information in a way originally devised for inflecting languages, and distracts users with the SoP information by overemphasising them. My proposal (at least originally) does not cover inflecting languages like English, as the headword templates are still not of null importance and the split of senses by SoP is at least somewhat justified. Wyang (talk) 10:37, 25 May 2014 (UTC)
I will again point to my argument above about inflected languages like German or Finnish and how they would be treated under your scheme: there would be an ===Inflection=== section showing the inflection in inflection tables; the same thing could be done for English. Therefore, I still do not see the thing that differentiates Chinese from, say, German for the purpose of the presentation that you propose; the lack of inflected forms in Chinese is not the sought differentiator, since, as I pointed out, inflection info can be separated into a dedicated section. I repeat that the split of senses by part of speech is no more justified in German than in Chinese; it come down to whether one wants to group senses by part of speech, and prominently so. Furthermore, dictionaries that split senses by part of speech often do not present any inflection information; their reason for the split is that they consider part of speech important; an example is Century 1911 (triggs.djvu.org/century-dictionary.com), which does not supply their "paper" entry with "papers", "papered" and the like. --Dan Polansky (talk) 11:06, 25 May 2014 (UTC)
I think I know what differentiates Chinese from German and English, at least believing what you posted above: if Chinese hardly ever has multiple etymologies, removing the part-of-speech structure without removing the etymology structure provides much larger benefit for Chinese, leading to definitions all being found in one place for Chinese, unseparated by headings. --Dan Polansky (talk) 11:13, 25 May 2014 (UTC)
Instances of dictionaries splitting the senses by SoP first and not showing the inflected forms do not disprove the proposition that the fundamental rationale for such practice is to account for differently inflected forms, especially when the inflection paradigms are mostly regular as in the case of English. I agree that the headword templates for inflecting languages could potentially be made redundant through your method of localisation, but I would imagine that at least some people working with inflecting languages would object to nullification of headword templates for their languages, since the templates, as imitations of the practice in most dictionaries, typically serve to identify some key forms in the paradigm (eg. Haus). Such objection would not exist for Chinese, since the inflection-line templates are truly of no value. It makes more sense there to deemphasise the PoS information by demoting PoS from the header and inflection-line template level to the individual line level. Wyang (talk) 00:33, 26 May 2014 (UTC)
I am still undecided about PoS for Chinese. I have always thought they were useful and I got used to using them when creating Chinese entries. Sometimes it's a challenge to decide, which part of speech a Chinese term belongs too or they can simultaneously belong to several PoS, like this one 裡頭 (inside) - noun, verb, adjective. The choice is almost random indeed. Some linguist will say they are all nouns, some will say they are postpositions but in fact, it doesn't really matter much, they just have this common idea of "inside" and the role is assigned depending on the context. I don't think we should get rid of PoS headers for Chinese altogether, it's probably Wyang's idea. Definitely not for other languages. However, the valid points he has provided should be given consideration. --Anatoli (обсудить/вклад) 07:16, 27 May 2014 (UTC)
Another big example of an entry without PoS headers (L4 header Definitions) is this version of . @Wyang: Yes, it looks neat and is simpler but it's still non-standard (at the moment). I might agree to get rid of PoS headers (for Chinese only), if you insist so. Thank you for adding the definitions. You still need to get the agreement of the rest of the community, though and other Chinese editors. It might violate some rules, e.g. is Definitions header allowed? I don't know. Will this methods be embraced by other editors? What about other languages with similar grammar. It's important to consider these things, too. --Anatoli (обсудить/вклад) 06:59, 4 June 2014 (UTC)

Media Viewer[edit]

Greetings, my apologies for writing in English.

I wanted to let you know that Media Viewer will be released to this wiki in the coming weeks. Media Viewer allows readers of Wikimedia projects to have an enhanced view of files without having to visit the file page, but with more detail than a thumbnail. You can try Media Viewer out now by turning it on in your Beta Features. If you do not enjoy Media Viewer or if it interferes with your work after it is turned on you will be able to disable Media Viewer as well in your preferences. I invite you to share what you think about Media Viewer and how it can be made better in the future.

Thank you for your time. - Keegan (WMF) 21:29, 23 May 2014 (UTC)

--This message was sent using MassMessage. Was there an error? Report it!

You are forgiven for using this awful language. Keφr 06:46, 24 May 2014 (UTC)

Language of entries marked with Template:no entry (formerly "only in")[edit]

Currently most of the pages which use this template have no language section at all. I think this is a mistake because it's certainly possible for a word to be unattested in one language but attested in another. And even if the word is not attested in any languages, the use of language headers would still allow users (and editors) to verify which languages this applies to. For example, if an English term is marked as not having any entry, but there is no German section on the page, then that would simply mean that we haven't gotten around to adding an entry for it yet. On the other hand, if there were a German entry with a "no entry" template, then that would be a positive confirmation that it's not attested. So I think we should add language headers to all of these pages. —CodeCat 22:57, 25 May 2014 (UTC)

Makes sense. The template has a lang parameter which suggests it should be used in language sections anyway. — Ungoliant (falai) 23:06, 25 May 2014 (UTC)
There's currently a list of all cases of {{no entry}} which lack a language parameter at Category:Language code missing/no entry. There are over 2000 of them right now. These may coincide with the entries lacking language headers, but they don't necessarily correspond exactly. —CodeCat 23:25, 25 May 2014 (UTC)
They may not correspond exactly, but if you ever want to add headers by bot from WhatLinksHere, they're the ones you would want to get out of the way first.Chuck Entz (talk) 00:26, 26 May 2014 (UTC)
I've done most of them by bot, and some others by hand. There are 8 entries left that I don't know what to do with. I can't even click on them, for starters. Can anyone try? —CodeCat 22:19, 27 May 2014 (UTC)
Here they are with links: 1, 2, 3, 4 ,5 ,6 ,7 ,8 DTLHS (talk) 22:28, 27 May 2014 (UTC)
And if you ask me they should be deleted (the control characters at least). DTLHS (talk) 22:29, 27 May 2014 (UTC)
The second one is translingual (I've labelled it accordingly). - -sche (discuss) 22:31, 27 May 2014 (UTC)

Request for template protect[edit]

Can I request that the template Template:User committed identity be protected with full protection. This would be because it is a high-risk template and has the potential to be vandalized to surpass the security that it creates. It has already been protected on the English Wikipedia and the next logical step would be to protect it on Wiktionary as well. I don't think the code will change soon since I just updated it to the latest code on WP. Thanks, Negative24 (talk) 14:13, 28 May 2014 (UTC)

Not such a huge deal. Even if the template is vandalised, the hash can still be read from the user page's markup. And I think our RC patrol should catch that rather quickly. Keφr 17:17, 28 May 2014 (UTC)
True, I just thought it might be good to do if the template would be shown on a high number of user pages. Negative24 (talk) 17:37, 28 May 2014 (UTC)

Context tags for impolite terms[edit]

What should be the tag used for こいつ? --kc_kennylau (talk) 15:59, 29 May 2014 (UTC)

The closest I can find is "pejorative". You can add various words in the context/label but whether it adds to categories is controlled by Module:labels/data. --Anatoli (обсудить/вклад) 09:37, 31 May 2014 (UTC)
What about "vulgar"? - -sche (discuss) 22:23, 31 May 2014 (UTC)

CJK ideographs composition indication[edit]

@Atitarev, Kephir, Lo Ximiendo, Wyang: Should we use ⿰ as suggested in or ⿲ as suggested in to describe the character ? --kc_kennylau (talk) 07:47, 30 May 2014 (UTC)

That was not a description but an alternative form. It's used, because of the limitation of the input.--Anatoli (обсудить/вклад) 00:04, 31 May 2014 (UTC)
Okay, I've changed the example. --kc_kennylau (talk) 00:32, 31 May 2014 (UTC)
Well, the category of says that it's for description. --kc_kennylau (talk) 01:00, 31 May 2014 (UTC)

Pregenerating entries[edit]

What does the community think about pregenerating a huge number of entries for various languages, to eliminate all of the unnecessary typing waste? For example, for Ukrainian I have 116k nouns of the form:


* {{IPA|[{{uk-pron|держпо́зика}}]|lang=uk}}


# {{rfdef|lang=uk}}


* {{R:uk:SUM-11}}

Basically everything except definitions gets generated. I was thinking of having a bot that would generate them on a request page, but that seems a rather unnecessary middle step. It would be similar to how CJK ideographs were generated in the early days, but with a bit more content (refs, pronunciation, inflection). It would enable existing editors to better focus on definition lines and examples, plus possibly bring in new ones who would be otherwise intimidated by huge number of templates. --Ivan Štambuk (talk) 09:42, 30 May 2014 (UTC)

On the other hand, we would not be able to tell whether a blue link contains an actual definition or not. (Some tweaks to the "orange links" gadget may alleviate that, though.) Myself, I prefer to approach this through better editing tools and automatic inflection modules (i.e. changing the typing waste to clicking waste). Something that would incorporate WT:EDIT and User:Yair rand/newentrywiz.js. I might not have the time for making that, however.
Also, welcome back. Where have you been??! Keφr 09:55, 30 May 2014 (UTC)
I’ve been doing it for a few months and no one complained, so I guess it’s fine. — Ungoliant (falai) 10:16, 30 May 2014 (UTC)
  • I oppose mass creation of entries that lack definition. Definitions are the key content, the one thing that it should not be lacking in an otherwise stubby entry. Compared to definitions, pronunciation and inflection are trivia. --Dan Polansky (talk) 17:43, 30 May 2014 (UTC)
    • Is no entry better than an entry with everything but a definition? I'm not so sure. It kind of goes against the idea of building and improving entries over time, which is the main principle of a wiki. —CodeCat 17:52, 30 May 2014 (UTC)
      • I think having a huge number of definitionless entries in various languages in Wiktionary is a poor state of affairs. Above, Ivan reports to have 116 000 nouns in Ukrainian. Wiktionary should not report to have 116 000 Ukrainian entries when the only thing it would have are algorithmically generated pronunciations and inflection tables. By my lights, at least one definition (or translation) is the minimum content, from which the entry can be incrementally expanded. I recall people complaining about Tbot entries (I like Tbot enties), when the only deficiency of these was that a human had to confirm what Tbot entered; Tbot solved precisely the problem of providing the formatting structure while at the same time providing what often turned out to be a correct translation. --Dan Polansky (talk) 18:32, 30 May 2014 (UTC)
        • Maybe a possible solution is to have some kind of formal definition of how complete an entry is. Entries with no definitions would of course get a low score on that. A bot could generate such a score on a large number of entries, which would allow us to pinpoint problems more easily maybe. Of course a bot can't decide whether information is correct or useful, only if it's present. But it's a good start. —CodeCat 18:37, 30 May 2014 (UTC)

I support this idea and not just for Ukrainian. Definitions are the most important part of entries, without them language entries are incomplete but the proposed example doesn't claim to be a complete entry, it asks user to add a definition. I would add more to the bottom, some message like autogenerated entry and another category to keep track of these. Complexity of entries scares off beginners. Besides, if pronunciation, inflection, headers are already there, it's a big step. Inflection, word stress, gender, part of speech, animacy are all non-trivial information for a language like Ukrainian. Russian Wiktionary also mass-generated entries. Now this policy pays off and definitions have been rapidly added. @Ivan Štambuk: please generate sample entries as an example and to check the quality. There's nothing new in this approach, people do import entries, request definitions. --Anatoli (обсудить/вклад) 09:27, 31 May 2014 (UTC)

So can you show us how the Russian Wiktionary policy has paid off? How many definitionless entries were originally created in Russian Wiktionary, and how many of them are no longer definitionless? --Dan Polansky (talk) 11:00, 31 May 2014 (UTC)
No, that's only my observation and what I saw in the discussions in the Russian Wiktionary. I can't give numbers. Most our Tbot entries were cleaned up eventually, so did many imported or generated entries here or in the Chinese Wiktionary. --Anatoli (обсудить/вклад) 12:45, 31 May 2014 (UTC)
Is there a category for definitionless entries in Russian Wiktionary? If so, can you post a link to it? If not, can you give us an example of a definitionless entry in Russian Wiktionary? --Dan Polansky (talk) 12:52, 31 May 2014 (UTC)
[стыковка] A while ago I've added a translation into English ("docking") there but didn't add a definition. --Anatoli (обсудить/вклад) 13:09, 31 May 2014 (UTC)
Entry ru:стыковка contains # {{пример|}}. There does not seem to be any category for definitionless entries in Russian Wiktionary. ru:Template:пример is one for an example sentence; the category for entries lacking an example sentence (which is not the same as lacking a definition) is ru:Категория:Статьи без примеров употребления. I downloaded a dump from http://dumps.wikimedia.org/ruwiktionary/20140519, "ruwiktionary-20140519-pages-articles.xml.bz2". I unzipped the dump. I ran "grep -P "# *{{\xd0\xbf\xd1\x80\xd0\xb8\xd0\xbc\xd0\xb5\xd1\x80\|}}" ruwiktionary-20140519-pages-articles.xml >t.txt. The number of lines in t.txt is 102 239. These scary \x items are just the binary of the UTF-8 string for пример and I really search for "# *{{пример\|}}". So there seem to be 102 239 definitionless entry lines of the format "# *{{пример\|}}"; but since they don't even bother to categorize them, who knows how many definitionless entries they have in another format. In any case, I do not like what I see there, like a page full of empty section headings including Синонимы, Антонимы, Гиперонимы, Гипонимы. What a bad joke, if you ask me. --Dan Polansky (talk) 14:41, 31 May 2014 (UTC)
Re: "please generate sample entries as an example and to check the quality": What the heck? Check the quality? What quality? Algorithmic formatting of an entry? We know what is being discussed from the example posted at the beginning of the thread; no need to start generating "sample entries" before there is consensus for this deviation from status quo ante. --Dan Polansky (talk) 11:13, 31 May 2014 (UTC)
Did all entries in require someone's sanction? They don't violate any format, do they? And opposition to the idea doesn't mean that discussion can't go on or we should stop editing. The example entry looks fine but I want to see how accurate everything else is and whether entries need other tags/categories. My only criticism is the location of the stress mark in the way Ivan has done (but I couldn't do it better). It should be /derʒˈpɔzekɐ/, not /derʒpˈɔzekɐ/ but that's a minor issue, it's not easy to determine the syllable onset.
I have just created держпо́зика (deržpózyka) as per the suggested format above, leaving it definitionless for now. --Anatoli (обсудить/вклад) 12:45, 31 May 2014 (UTC)

Support. Makes achieving the eventual goal quicker. Chinese Wiktionary sort of used the same strategy: zh:知了, zh:獨立. Wyang (talk) 10:21, 31 May 2014 (UTC)

Status quo: I contend that the status quo in English Wiktionary is to avoid having large masses of definitioness entries. {{rfdef}} is used in less than 1500 entries. --Dan Polansky (talk) 11:04, 31 May 2014 (UTC)

  • oppose' -- Liliana 12:32, 31 May 2014 (UTC)
  • I oppose too. Add the terms as you get definitions for them, even if it's just a one-word gloss. To save typing, you could create a pseudo-template in your userspace and just have your bot create pages with something along the lines of {{subst:User:Ivan Štambuk/uk-entry|держпо́зик|а|f-in|gloss}}. —Aɴɢʀ (talk) 13:29, 31 May 2014 (UTC)
  • Strongly oppose. I don't want us to end up like the Russian Wiktionary with tons of entries that fool you into thinking they exist but really lack definitions. --WikiTiki89 13:49, 31 May 2014 (UTC)
  • Oppose per Wikitiki and Keφr: it would mean we could no longer tell based on blueness vs orangeness vs redness of link whether an entry existed (with a definition) or not, and hence whether we still needed to define it or not. If there were a way to distinguish definitionless entries from complete entries (say, by modifying the gadget that creates orange links), I wouldn't mind as much, though I'd still think it best practice to include definitions in one's entries, and not create entries without definitions, except in rare cases where you e.g. add citations but can't figure out what they mean, and so add {{rfdef}}. The reference to the zh.Wikt is interesting, since it brings up the point that about thirty thousand of en.Wikt's Chinese-character entries (a majority?) have had many definitionless language-sections ever since they were created eight years ago. - -sche (discuss) 16:47, 31 May 2014 (UTC)
  • Strongly oppose per Dan Polansky and Kephir. —Mr. Granger (talkcontribs) 18:28, 31 May 2014 (UTC)
  • Vahag is on the fence. I hate Russian Wiktionary's empty pages, that cheat you into believing there is content down the link. But Ivan's pregenerated are not empty; they have a lot of useful content that can be valuable even without a definition. --Vahag (talk) 19:32, 31 May 2014 (UTC)
    Well, ru:стыковка is not entirely free from information either. It tells you that (a) it is a Russian word, (b) a noun, (c) inanimate, (d) it is feminine, (e) inflection table. What Ivan adds is (f) pronunciation, and (g) a link to possibly a good dictionary. Of all these, (g) might be most valuable, from my standpoint, since taking the reader to a page that has a lot of the sought info about the specific word is quite worthwhile. --Dan Polansky (talk) 19:51, 31 May 2014 (UTC)
    That useful stuff was added to Russian Wiktionary pages incrementally, over time. Ivan is providing them in version 1.0. --Vahag (talk) 20:09, 31 May 2014 (UTC)
Support. The advantages (presence of useful content that wouldn’t be there otherwise and making it easier for people not familiar with the Wiktionary entry format to add definitions) override the disadvantages (uselessness of link colouring). As for “report[ing] to have 116 000 Ukrainian entries”, I can update the program that calculates the statistics to ignore {{rfdef}}s. — Ungoliant (falai) 20:06, 31 May 2014 (UTC)
  • To address some of the points raised and extend the rationale further:
    • Definitions are not necessarily the key content. We have many users that exclusively come because Wiktionary is the only place on the Internet you can look up e.g. inflections or IPA transcriptions for words in many foreign languages. For example, on feedback often there are students thanking for Latin inflections.
    • Entries are never complete but are instead a permanent work in progress. We have many entires that consist entirely of a PoS header and a single-word definition. These entries are much more useless in terms of value provided than the prototypical stub I listed above. Not to mention that 90%+ of Wiktionary entries are inflected forms that don't have any definitions at all.
    • The suggestion to check whether the blue link contains definition or not is intriguing. But this is already the situation for everyone unless they have User:Yair rand/orangelinks2.js imported. So there is no difference for 99.9% of Wiktionary users. The {{rfdef}} templates inserts the entry into a language-specific category, so the script could be modified to check for it.
    • The push toward "automatic inflection", i.e. reimplementing the language's generative phonology and inflectional morphology in Lua, is IMHO ultimately not worth it. The user doesn't care how the content was created, and creating dependencies that span the entire individual language's specific PoS category with complicated execution logic like Module:ru-verb for Russian verbs is just begging for accidental runtime errors and bugs in the future. Inflection is just static and immutable data and it should be treated as such. Perhaps one day it could be relocated to e.g. WikiData, because WMF decided to implement lemmatization-enhanced search box across all wikis (both pedias and other wiktionaries), or all wiktionaries decided to pull inflections from a single storage.
    • Personally I think Tbot was the best thing to happen on Wiktionary ever. Checking and expanding its entries is very fun and was adopted by many casual editors. If necessary, these pregenerated entries could have their definition lines changed to have meanings and glosses from the translations of the corresponding English entry if it exists (for vast majority unfortunately it doesn't), or taken from e.g. Google Translate. This could be done in a second pass and it's really easy to do.
    • Scoring entries similar to Wikipedia is an excellent idea, that has already been suggested before. It would be nice to have entries tagged by completion and missing data, as well as having a language-wide average score reported in statistics. The mere number of entries is a very poor metric. But this is really irrelevant for this discussion.
    • I think that the attitude of rather having a small number (a few thousands) of quality entries done by a limited number of editors rather than 200k (a lower figure for any language with a developed literature) of which 90% are likely to be stubs is detrimental to the chief purpose of dictionary which aims to list every used (and unused) word. There are too many words, too many languages, and too few editors. Speeding things up is essential, and that includes lowering the bar on participation to editing only the missing/incomplete definition line, disincetivizing the costly creation of automatic inflection modules by eliminating the problem which they are trying to solve, and leveraging existing architecture such as definition extraction from FL entries in translation tables and the corresponding other-language wiktionaries (like Tbot used to do) to reduce the average editing time per entry. Stubbing on a mass scale would eliminate the number of entries worshiping altogether and would instead incentivize adding quality content. --Ivan Štambuk (talk) 21:14, 31 May 2014 (UTC)
    • So instead of reimplementing the language's generative phonology and inflectional morphology in Lua, you suggest reimplementing these in bots, in which systematic errors are just as probable (if not more), harder to correct (because someone has to run a bot again to fix template invocations, and mine dumps to find out which pages are affected by an error) and harder to notice (for one, because bots' source code is usually not open to public scrutiny the way modules are)? Keφr 17:50, 1 June 2014 (UTC)
      No, but rather taking them from morphological lexicons, inflection engines or digitized dictionary headwords which are available on the Internet. The problem is already solved by taxpayer-funded research, and there is no need to reinvent the wheel. I mean you could do it, but it seems wasteful. I'm sure that writing Module:pl-verb would be loads of fun, but life is too short. --Ivan Štambuk (talk) 18:05, 1 June 2014 (UTC)
StubCreationBot (talkcontribs) has started to created stub entries despite notable lack of consensus. --Dan Polansky (talk) 11:49, 1 June 2014 (UTC)
I'll be running it in small batches and manually checking each entry. That seems to be the least "controversial" solution. --Ivan Štambuk (talk) 18:05, 1 June 2014 (UTC)
I worked on these small batches just now by adding definitions. It's very easy and a lot of efforts were saved. So I'm switching to support. --Vahag (talk) 18:11, 1 June 2014 (UTC)
If it is so easy to fill-in the gaps left in the definitionless entries, why does Russian Wiktionary have over 100 000 definitionless definition lines? Also, why does none of the supporters present an accurate and verifiable report on how well this worked in Russian Wiktionary, so we can learn from their experience? --Dan Polansky (talk) 19:33, 1 June 2014 (UTC)
Currently, there are about 60,000 definitionless Russian entries in the Russian Wiktionary, down from 108,000 in 2008. They have much some smaller number of editors. I doubt this 48,000 entries woud be created otherwise.--Anatoli (обсудить/вклад) 20:35, 1 June 2014 (UTC)
Is it correct that those definitionless entries are in the native tongue of the Russian Wiktionary, while the planned definitionless entries in English Wiktionary are in languages that have only few contributors in English Wiktionary, such as Ukrainian? So do you really think that the overall number of editors of English Wiktionary helps definitions of Ukrainian terms here being entered faster than the definitions of Russian terms were entered in Russian Wiktionary? --Dan Polansky (talk) 05:49, 2 June 2014 (UTC)
I don't know, Dan, I just support the idea, hoping to attract more/new editors. It's not just Russian words that were auto-generated - Ukrainian, English were imported as well but I don't know the original number to check the progress. There are a lot of enthusiastic editors with some knowledge of Slavic languages here who spend more time in the mainspace, not in the Beer parlour. To add a definition, you don't need to be fluent in a given language, suffice to consult a dictionary and many are obvious. Some words can already be confirmed by existing translations from English, Swadesh lists, etc. There are many obvious loanwords, how hard is it to translate e.g. авока́до (avokádo) or австрі́єць (avstríjecʹ) from Ukrainian into English? Gradual importation seems like a compromise, doesn't it? --Anatoli (обсудить/вклад) 06:22, 2 June 2014 (UTC)
Putting such definitionless entries in the mainspace and making them searchable and visible to casual users seems very unwise to me. Equinox 19:42, 1 June 2014 (UTC)
It’s not very elegant, but it’s an improvement on having absolutely nothing on a word. — Ungoliant (falai) 20:15, 1 June 2014 (UTC)
I don't think having them searchable and visible to non-editors is an improvement. As a user I would think, "oh, it's that site that has pages for words it can't even define" — similar to the feeling I get when Google "corrects" my spelling and gives irrelevant results rather than admitting there are no results. Equinox 15:01, 2 June 2014 (UTC)
Even if users think that, they may also think “but they have pronunciation and inflection so I can count on Wiktionary whenever I’m in need of that” (better yet: “I know the definition, I’ll add it”), which is better than “they have absolutely nothing on this word, why bother coming here at all?”. — Ungoliant (falai) 15:16, 2 June 2014 (UTC)
Maybe instead of conjecturing what users consider useful or not, we should do a reader survey? Do we have resources for that? Keφr 18:23, 4 June 2014 (UTC)
I'm changing my vote to weak support. I guess I got caught too up in the flaws of the Russian Wiktionary to realize that our situation is different. Ivan makes some good arguments here. I still think that we have to be cautious with this. We should only do it if there are people willing to be actively working to fill in the definitions, and we should only do this for languages for which we have editors capable of adding definitions. --WikiTiki89 22:20, 1 June 2014 (UTC)
Yes- I'd support if the bot doesn't create any new entries after some threshold of definitions needed is reached- maybe 500. That makes sure it isn't creating entries when there is nobody looking at them. DTLHS (talk) 22:21, 1 June 2014 (UTC)
I weakly support the proposal, but I definitely oppose abandoning automatic declension tables, for the reasons that have been given by Kephir. Templates and modules are not just there for convenience of editors; otherwise we'd just subst them all. They are a huge asset to maintenance and should definitely continue in use. —CodeCat 22:30, 1 June 2014 (UTC)
I wouldn't support it either, if abandoning automatic declension tables was the plan. --Anatoli (обсудить/вклад) 06:22, 2 June 2014 (UTC)
I agree with DTLHS's notion of limiting the total number. If there already are more than one thousand entries with missing definitions in a language, perhaps the other missing definitions merit attention first. DCDuring TALK 19:01, 2 June 2014 (UTC)
I agree now with setting the limit but 500 and 1000 is too low. It should be at least 5,000, IMO. Preferably for words starting with various letters, not just "А". One reason: It happens that majority of Ukrainian, Russian words starting with "А" are loanwords and not the most common, useful words. --Anatoli (обсудить/вклад) 00:08, 3 June 2014 (UTC)
We could use a frequency list to determine the order to add words. --WikiTiki89 05:05, 3 June 2014 (UTC)
@Ivan Štambuk: What is the source of the Ukrainian data that you are proposing to upload, those 116 000 nouns including gender, inflection, and animacy? --Dan Polansky (talk) 06:45, 3 June 2014 (UTC)

Support  How can we object to adding information to the dictionary? How is no definition worse than no entry at all? If you want orange links to indicate missing definitions instead of missing entries, then let’s ask someone smart to make them do that.

Can someone smart make a widget that gives me a notification in the red box at the top, offering a random definitionless Ukrainian entry every time I visit Wiktionary? Michael Z. 2014-06-03 07:34 z

Re: "How is no definition worse than no entry at all?": If you Google a word, find it has an entry in English Wiktionary, click it, and only find trivia, you may feel as cheated as I do when this happens to me with Russian Wiktionary; consequently, your esteem of the English Wiktionary project is negatively impacted, a negative outcome from the standpoint of those editors who have donated considerable resources to build it. The key disagreement seems to be that what I consider to be trivia some other editors consider to be "useful content". On another note, if Russian Wiktionary and other Wiktionaries are already busy creating definitionless stubs, then users will be able to find what they were looking for there, the Wiktionaries will massively outperform the English Wiktionary in their ability to provide this "useful content" (trivia by my lights), and if this is what dictionary users are really looking for, then it should ultimately show up in page view statistics in http://stats.wikimedia.org/wiktionary/EN/ReportCardTopWikis.htm. --Dan Polansky (talk) 09:20, 3 June 2014 (UTC)
If I search for a word in Wiktionary and find its gender, part of speech, translations, or pronunciation, &c., I may feel less cheated than if I find a null. I may also add a definition. We’re a repository for lexicographical information, not only definitions, and we are a work in progress. If an editor has some of that information, I would be grateful if he would add it to the project instead of sitting on it. Michael Z. 2014-06-04 13:06 z
Trivia or not, it's still occupying a large chunk of every entry. It should be added sooner or later, and I really see no point in arguing that it should be added later rather than sooner solely because it would otherwise cheat the user out of what they would deem the most relevant part of the entry, in most cases should they end up reading it. Why? Because the purpose of this project is not user satisfaction. There are specialized dictionaries that only provide accents or inflection of words, some that only provide etymology - there is no problem in having only etymology, inflection or pronunciation section without definitions because it's supposed to be there regardless. --Ivan Štambuk (talk) 20:49, 4 June 2014 (UTC)
  • Support - it is better to have some of the possible information being sought than none at all. The rest can and will be filled in over time. However, perhaps as an interim measure the entries could be created in Wiktionary space (e.g. Wiktionary:autogenerated/word) and moved to mainspace when the definition is added. bd2412 T 18:47, 3 June 2014 (UTC)
  • User:Ivan Štambuk: Question — does your bot try to import translations from tables? Because right now, when Special:Searching for a redlinked word, at least User:Yair rand's gadget will generate a list of places where the word appears in translation tables (e.g. [1]). Creating an entry disables that. So this is another advantage of having redlinks. I am not sure how many Ukrainian translations it would impact, however. Keφr 13:55, 4 June 2014 (UTC)
You can still search, even if an entry is created - [2]). In the search window, need to linger longer and select containing .... @Mzajac: Not a smart widget but Ukrainian entries asking for definitions are here: Category:Ukrainian definitions needed. --Anatoli (обсудить/вклад) 14:02, 4 June 2014 (UTC)
I know that. This is to point out yet another piece of our infrastructure that is built with the assumption that if the entry exists, it already contains the definition you need. Which is not always right, but mass generation of definitionless entries would thwart it even more. (Also, note the additional cumbersomeness of searching for a term for which an entry already exists.) Keφr 18:00, 4 June 2014 (UTC)
That gadget is obviously poorly written and that's not my problem. --Ivan Štambuk (talk) 20:25, 4 June 2014 (UTC)
How about this variation on my above thought: we autogenerate all the entries in a Wiktionary:subpage/ space, with a blank definition line, and then have a bot comb the entries and move them to mainspace whenever a definition is added. The entries will be made and will require nothing by editors beyond the addition of definition lines. bd2412 T 22:57, 4 June 2014 (UTC)
Changed the script to work even when the entry exists. One still has to go to the search page, though. --Yair rand (talk) 21:49, 8 June 2014 (UTC)
Oppose (in case the discussion is still going). I think, the intermediate request page will do better. Besides, the 116k articles Ivan talks about are mainly outdated or combined words, with a great number of regionalisms. I doubt the great part of them will be populated any time soon. On the other hand, there are hundreds words used in the modern language absent in that dictionary, so having option to autocreate articles one personally is going to work with is worth doing.

By the way, speaking of ru.wiktionary, one should also looked at the Ukrainian or French parts of it to have an illustration of what will be here in case of mass creation (save lesser number of total crap of entry parts). Alexdubr (talk) 18:09, 12 June 2014 (UTC)

Uhm, all of the words are taken from the published Ukrainian corpus and are currently generated in the frequency of appearance in normalized form in modern newspapers. Just because you personally haven't heard of some words it doesn't mean that they don't exist, or that they should be treated as of lesser importance. Regionalisms and outdated words are of particular importance because that's what gives Wiktionary an edge over paper dictionaries who can't afford to list them. Experiences from desperately understaffed sister wikiprojects are irrelevant. --Ivan Štambuk (talk) 18:35, 12 June 2014 (UTC)
Implying we are not desperately understaffed. Keφr 19:02, 12 June 2014 (UTC)
From Category:Ukrainian definitions needed: авансодавець, for example is a possible word, I really doubt it exists in practice. авансик and автобусик are diminuatives, do you propose to add a diminuative form of every word or just at random? авіахім is istoricism, which has no correspondence in English, I think. After letter A though, the entries do really seem from a contemporary corpus. Alexdubr (talk) 19:11, 12 June 2014 (UTC)
These are all real words that were taken from written and published (non-Internet) corpus, all of them passing CFI. The remaining A-words were generated alphabetically, the rest by frequency of appearance. --Ivan Štambuk (talk) 19:37, 12 June 2014 (UTC)
@Kephir: There are levels of desperateness. What is much worse however is this blind idolatry of manual labor in face of new and exciting technologies that offer a significant productivity boost. Rather than leveraging opportunities that would be inexcusable to ignore, neo-Luddites prefer to stick to the stone age methodologies that on average produced a new dictionary edition once a decade (if that often). --Ivan Štambuk (talk) 19:37, 12 June 2014 (UTC)
Despite my previously-noted opposition to creation of masses of definitionless entries, I think the way things have been proceeding is OK: StubCreationBot (talkcontribs) has created ~630 entries, but Ivan and possibly other users have then defined the majority of them, such that there are only ~230 entries in Category:Ukrainian definitions needed. I like the suggestion made by several users above of allowing the bot to create stubs, but having it pause after making ~500 or so and wait until people defined some of those before proceeding. - -sche (discuss) 19:41, 12 June 2014 (UTC)
@Alexdubr. I confirm that all pregenerated terms are valid Ukrainians words (if this confirmation is required). As I previously mentioned, they are not necessarily the most common, useful or otherwise "interesting" words. Dated, regional, rare and diminutives also qualify as words and are, of course, includable. Words without English equivalents can be described, you don't have to give a one-word definition. You're under no obligation to help, though. Ivan has already promised to use frequency lists, which are already making adding definitions easier and more motivating. --Anatoli (обсудить/вклад) 23:50, 12 June 2014 (UTC)
A small update. Currently at only 104 entries and I haven't worked hard on Ukrainian. There are still many quite rare (but REAL) terms. Some terms have multiple rare etymologies. I think it's OK to remove them and add later, if they are found. E.g. I have no idea what type of plant can be called "роман" in Ukrainian and I'm no expert in plants. --Anatoli T. (обсудить/вклад) 07:47, 21 July 2014 (UTC)
It's in Bilodid (see references) - a rare alternative form for ромен (romen).
Anyway, I'm exploring other options now:
  1. loading those skeletons via JavaScript from my server when you click them in the redlinked translations, along with translation + gloss from the base entry. This would however force editors to first add translations to English terms and then create the main entry. I'm not sure that we want that, because many FL words don't have exact English equivalents. Many English terms also don't have translation boxes and it's PITA to add them.
  2. Dumping all of the skeletons in a format that GoldenDict can read, so that when you do Ctrl+C (or merely point your mouse if you configure the program that way) you can just copy the preformatted entry from the popup window to clipboard and paste it into the Wiktionary edit box. This has the benefit of also looking up uk words in installed dictionaries for GoldenDict (such as Bilodid, or other uk-en, uk-ru dicts).
What would be the optimal workflow? --Ivan Štambuk (talk) 10:40, 21 July 2014 (UTC)
I also use accelerated entry creation from translations User:Ruakh/Tbot.js (it needs some small fixing), which work OK for Russian - just generating the language header, PoS header, a translation with a gloss. It would for Ukrainian with addOnloadHook(function() { Tbot.greenifyTranslinks('uk'); });. What you're suggesting is quite interesting. So the formatted entry you're talking about can be generated from a translation? Could you demonstrate with a red-linked Ukrainian translation, such as квито́к (kvytók) at ticket? --Anatoli T. (обсудить/вклад) 23:14, 21 July 2014 (UTC)

Mass creation of definitionless entries[edit]

For those who have not notices, a proposal to create definitionless entries en masse is being dicussed at #Pregenerating entries thread. --Dan Polansky (talk) 19:35, 1 June 2014 (UTC)

June 2014[edit]

Template:cx vs. template:context[edit]

I prefer {{cx}} over {{context}}. Nonetheless, MglovesfunBot (talkcontribs) is replacing the former with the latter. Was there a discussion from which this action follows? Any links to the discussion? --Dan Polansky (talk) 09:25, 3 June 2014 (UTC)

They're equivalent, one is a shortcut to the other. So there is no problem with replacing one with the other. —CodeCat 11:35, 3 June 2014 (UTC)
Is there is discussion supporting this? They are not visually equivalent in the wiki markup; one is much shorter, so the actual context like "colloquial" is visually much more outstanding with it. --Dan Polansky (talk) 12:27, 3 June 2014 (UTC)

Prescriptivism as to common lay transliterations.[edit]

According to Wiktionary:Neutral point of view: "On Wiktionary, neutrality directly implies that a descriptive approach is taken towards the documentation of languages, and not a prescriptive approach. This is one of the primary tenets of how Wiktionary works". We do not adhere to this principle, however, when it comes to common lay transliterations (i.e. commonly used translations for terms originating in foreign scripts, created without necessarily having or following an authoritative scheme of transliteration). This is exemplified by entries like tovarich (English, really?), ayubowan (decided through RfD to be kept as an English word derived from Sinhalese), and the current discussion at Wiktionary:Requests for deletion‎#mahā.

We generally decide whether any unbroken string of letters is "a word" by looking to see if it is used in print to convey a consistent meaning. Our CFI is built around this principle. We do this because the existence of the word in print is what makes it likely that a reader will come across it and want to know how it is defined, or possibly how it is pronounced, derived, or translated into other languages. I see no reason consistent with our CFI or our NPOV tenet to exclude any unbroken string of letters used in print to convey a consistent meaning, certainly on the basis that this string of letters is not formed by some official arbiter of transliteration. I would propose that our current CFI and NPOV language requires that we include attested words created by lay transliteration, whether or not these words appeal to our own sense of propriety. bd2412 T 19:03, 3 June 2014 (UTC)

Even transliteration from Latin to other scripts? — Ungoliant (falai) 20:19, 3 June 2014 (UTC)
Like フロリダ州 and Флорида? bd2412 T 20:21, 3 June 2014 (UTC)
Those are written in their native scripts. — Ungoliant (falai) 20:29, 3 June 2014 (UTC)
Like гуд морнинг. — Ungoliant (falai) 20:38, 3 June 2014 (UTC)
Those are hardly their "native scripts"; they are transliterations which have been adopted into the language, probably through length of use. As for "гуд морнинг", that's a two-word phrase. I am referring to the "unbroken string of letters", so in addition to use, idiomacity of the transliterated phrase would need to be shown. Assuming it can be, the question then is whether "гуд морнинг" is used in print to convey a consistent meaning over a sufficient span. If it is, then it is entirely plausible that a reader might come across it and want to know its meaning. This is scarcely different than including non-Latin eye dialect entries like падонки and キレる (or Latin eye dialect like dayum and innerduce, for that matter). I assume that at some point someone will make an entry for тверкинг, also. bd2412 T 21:27, 3 June 2014 (UTC)
Yes they are; Katakana is a native script of Japanese and Cyrillic is the native script of Russian. フロリダ州 is a Japanese word that has been loaned from a language whose native script happens to be Latin, not a mere transliteration like гуд морнинг (or just морнинг, if you prefer), which is the English phrase (good) morning written in Cyrillic script instead of Latin. If you think that гуд морнинг occurs in Russian as a loanword from English, feel free to add it as a Russian. My question is: if your proposal is accepted, would we create things like an English entry for морнинг? — Ungoliant (falai) 23:12, 3 June 2014 (UTC)
Is морнинг even attested? I can see that it exists, but since I can not read Russian, I have no idea whether it is attested with the same meaning as morning in English, or whether the cites that exist are even uses as opposed to mere mentions. Assuming that all of these criteria are satisfied, and there are a CFI-worthy number of uses of морнинг in running text consistently conveying the meaning "morning", then we should have an entry defining the term for the benefit of the reader. Should it be defined as English? It seems absurd to call it Russian when it is merely an English word written in Russian characters. If a new kind of entry is required to accommodate the existence of such words, then we need to put one in place. We would not be able to claim that Wiktionary is a descriptive work, rather than a prescriptive work, if we were to pretend that "морнинг" did not exist, or conveyed no intelligible meaning. bd2412 T 23:59, 3 June 2014 (UTC)
I'm not quite following the purpose of this discussion. What is this for? Is it about allowing transliterations in various languages? We have allowed, on a limited basis Roman transliteration of a few languages - after a vote or by consensus. I don't think we should spread to any non-Roman based language, unless they are a part of another language. New additions should be allowed after a vote and should never be on the same level than terms in the native script. --Anatoli (обсудить/вклад) 00:39, 4 June 2014 (UTC)
Wouldn't that require us to repeal the more fundamental policy of the above-quoted language of Wiktionary:Neutral point of view? After all, it is a purely prescriptivist position to exclude attested words (using our definition of "word": A distinct unit of language (sounds in speech or written letters) with a particular meaning, composed of one or more morphemes, and also of one or more phonemes that determine its sound pattern). bd2412 T 00:52, 4 June 2014 (UTC)
Yes, believe it or not we don't just record every attested combination of letters ever put on paper (and yes, that means we have a point of view and that we aren't purely descriptivist). DTLHS (talk) 00:55, 4 June 2014 (UTC)
If a word is attested in a language, then it can be included in that language in that script, not its transliteration. Transliterations are also attestable but their usage is well - mere transliteration, when it's not possible or difficult to use proper native scripts or to teach the script or pronunciation. sijakhada is only transliteration of Korean 시작하다. It's useful and can be found in published books but its purpose is different. Transliteration is not a substitute for native scripts. --Anatoli (обсудить/вклад) 01:02, 4 June 2014 (UTC)
How are you defining "word" to permit that distinction? Certainly not the way it is defined in our own corpus. bd2412 T 01:10, 4 June 2014 (UTC)
It depends on the word and on the language, what writing systems are used in a given language. For example, "Я читаю книгу, а она смотрит телевизор." are Russian words (I'm reading a book and she's watching TV.), "Ja čitáju knígu, a oná smótrit televízor" is the transliteration of the Russian phrase, they are not words. यह लड़की बहुत सुंदर है । is a Hindi phrase (This girl is very beautiful.). Hindi is written in Devanagari. "yah laṛkī bahut sundar hai." is a transliteration of the Hindi phrase, none of these: yah, laṛkī bahut sundar hai are Hindi words and none of Ja čitáju knígu, a oná smótrit televízor are Russian words, even if it's a standard transliteration and can be attested. There can be plethora of standard, chat, practical, textbook, specific dictionary transliterations. Is that enough? I don't know if I can explain better. --Anatoli (обсудить/вклад)
How does this help our readers when they come across such things? None of this explains how, for example, laṛkī or televízor are not distinct units of language with a particular meaning. They have as strong a claim to being words as ндрав. There must be some way that we can assist readers who come across these in print (assuming they occur with a sufficient degree of attestation to meet our CFI) in understanding their meaning. If we can't, if readers must turn to some other resource to determine the meaning of these, then we're not fully functioning as a dictionary. I would not oppose stricter constraints on the number and type of references to be required for such things, or a form of presentation that makes it clear that the transliteration is not the native form, but there must be some way to avoid turning a blind eye to the existence of these lexical units and their potential to require defining for our readers. This is perhaps even more pressing in the case of a word like bahut, for which we have a definition that will only confuse and frustrate the person reading transliterated Hindi, if it exists. bd2412 T 02:13, 4 June 2014 (UTC)
It may not be possible to cover all possible transliterations, including scientific, phonetical, practical (čto vs što vs shto for Russian "что"), chatroom (Arabic "3iid mubaarak" for عيد مبارك instead of "ʿīd mubārak"), with or without stress indication (televízor vs televizor), with or without vowel length indication (mahā vs maha), suppressing unpronounced letters or transliterating as they are written (laṛkī vs laṛakī). If users are not able to separate proper words in a proper script from their transliterations/transcription or loanwords from the phonetic representation, they may not be able to use our dictionary. We have an advanced search facility and it's more of a technical question, rather than policy. --Anatoli (обсудить/вклад) 02:34, 4 June 2014 (UTC)
I don't see why this is any less possible than covering all untransliterated words (particularly if we are including common misspellings and eye dialect terms in multiple languages). However, my concern is focused on words found in books in print, and particularly to words used in running English text without italics, quotation marks, or other distinct presentations designed to indicate their "foreignness". I think the typical reader can be forgiven for not being able to separate those words from proper words in a proper script. Such a limitation would obviously substantially shrink the set of words to consider, probably excluding most of the examples that you have provided here. Would that bring us closer to a resolution where you would feel comfortable having some commonly used "unofficial" transliterations? bd2412 T 02:45, 4 June 2014 (UTC)
Wait, do I understand correctly that you've just said you want to take certain things that are "used in running English text without italics, quotation marks, or other distinct presentations designed to indicate their 'foreignness'" and include them as romanizations/transliterations rather than as English? If so, what basis do you have for saying that strings used in running English text without any indication of foreignness are not English, other than a prescriptivist view of what constitutes English? - -sche (discuss) 03:20, 4 June 2014 (UTC)
I want to include them, period. I'm not picky about how, but I think it's silly to treat mahā as an English word when it is being used no differently than महा would be, except that various authors have transliterated it so their readers will find it more familiar. bd2412 T 03:38, 4 June 2014 (UTC)

I still don’t get what is being proposed, BD. We include all attested words, whether their spelling is determined by standard or non-standard transliteration, transcription, or whatever else (which is probably impossible to determine in most cases). As far as I know, there is nothing written or unwritten preventing the use of ones “created by lay transliteration”. Tovarich, for example, might be based on a French transcription of Russian or something. It doesn’t matter. It is included as English because (I presume) it is used three times in English sources. Michael Z. 2014-06-05 09:33 z

  • I recently proposed to restore the previously deleted mahā, a widely-used transliteration of a Sanskrit word. In the discussion, some editors are opposing the inclusion of this word on the grounds that it is "not a word" because it is a transliteration from Sanskrit. I think it should be included in some form, and don't see why we include transliterations of Chinese and Japanese, for example as Chinese and Japanese, but will not include this at all (perhaps not even as English). bd2412 T 11:56, 5 June 2014 (UTC)
I have four separate issues about this. For one, I think when something like Moskva comes up in English text, whether we consider it English or Russian is not so important as the fact that someone might want to look up that spelling. This applies to relatively rare cases, with words that are sort of edging across boundaries. On the other hand, I'm not thrilled with the concept of citing linguistic transliterations into Latin for whatever reasons; between search and manual transliterations, users of such works should be able to find the words they're looking for, and it seems like that could lead to a huge boost in the number of words. On the flip side, I do believe that we should use scripts that the language is actually published in. Gothic, for example, is published in Latin script; I do not believe that non-trivial amounts of the language have ever been published in Gothic script. We should (and do) support Gothic in the script that it's published in, no matter what purism leads us to using the script it was once written in. I don't know enough about Sanskrit; I believe it can actually be published in any number of Indic scripts, and if people actually read Sanskrit in Latin script, then Latin script as well as all of those Indic scripts it's actually read in should have entries for Sanskrit. Lastly, I'm more worried about this the harder the script is. Russian or Greek transliteration shouldn't be hard to get back into its native script, but ideographs are generally going to be impossible, with Sanskrit being challenging for many users but not hopefully impossible.--Prosfilaes (talk) 01:03, 6 June 2014 (UTC)
I do find this concept that mahā is not a word and महा is to be confusing. They're both a unit of communication clearly corresponding to the same Platonic word. abba, 𐌰𐌱𐌱𐌰, and αββα are the same Gothic word, practically spelled with the same letters with a different font (and there's serious argument that the Gothic script is merely Greek with a few extra letters and should be treated that way[3]; in practice it's treated as Latin with a few extra letters, because it's Germanic and thus was handled by German philologists.)--Prosfilaes (talk) 01:03, 6 June 2014 (UTC)
The issue is not at all abstract to me. Maha is a disambiguation page on Wikipedia. I recently set about fixing the large number of links to that page, and discovered that most of them were from articles referencing mahā. Most did not provide the Sanskrit script, and the editors who wrote them may well have been unaware of their presentation Sanskrit script, because there are plentiful sources using only the latter. I initially though maha would have the answer but it did not. It took an extensive amount of poking around - and my ability as an administrator to see the content of the deleted page, mahā, for me to figure out what was going on here. bd2412 T 01:49, 6 June 2014 (UTC)
Yeah. I think part of the problem is that we have incredibly strict formatting and structure; we generally require that each word belong to a precise language, that each sense belong to a precise POS, that each quotation belong to a precise sense, that everything be templatizable and Luacizable and MewBottable six ways from Sunday. The strictness of structure not only appeals to the aesthetic sense of programmers (myself included), but also has practical benefits; but it also has drawbacks, one of which is that it does not allow us to do a great job capturing the messy reality of real language, and it forces us to adopt POVs when we would rather not (or at least, should rather not). —RuakhTALK 02:35, 6 June 2014 (UTC)
I would include this with Moskva then; whether or not mahā is English shouldn't get in the way of providing an entry for a word that people may look up.--Prosfilaes (talk) 03:14, 6 June 2014 (UTC)
+1 to what Ruakh said.
A few entries already use ==Undetermined== as their language header. We could start using that header more, although I'm not sure that's the best solution (or even a good solution). - -sche (discuss) 03:35, 6 June 2014 (UTC)
It's not so much that the language is undetermined as that we seem compelled to treat anything transliterated and placed in English text as English. Suppose we had headers that literally read, e.g., ==Transliterated Sanskrit== or ==Transliterated Sinhalese== - would that be an improvement? bd2412 T 17:57, 6 June 2014 (UTC)
Nah, for things like mahā, I don't think we need any new L2 headers; the best approach IMO would be to do what we've done for all other languages for which we've wanted to include romanizations: have a vote to allow romanizations, and then have entries using the language's usual header (in this case, ==Sanskrit==). ==Undetermined== might still be worth considering for a few other things, though, which actually do slip "between the cracks" of other languages. For example, Gott in Himmel occurs only in supposedly-German snippets (often italicized) in English works; it doesn't occur, or at least isn't truly related when/if it occurs, in German works. (But even with that, I'm not sure an ==Undetermined== header would be any less unsatisfactory that our current arrangement of calling it ==German== and/or the other obvious possibility, of calling it ==English==.) - -sche (discuss) 18:38, 6 June 2014 (UTC)
I would definitely support allowing transliterations of Sanskrit, generally, but that's a band-aid. There are still many other languages with common Latin-alphabet transliterations of forms originally written in other scripts - Russian, Ukranian, Armenian, Arabic, Sinhalese, Hebrew, etc. This entire book collects stories in transliterated Sinhalese, peppered with English explanations. This one has Hebrew transliterated at length. If words in these running text can be found having the same transliteration in other sources, do we need a separate vote to allow Sinhalese transliterations? Won't the end result be a series of votes allowing all attested transliterations? bd2412 T 19:25, 6 June 2014 (UTC)
Someone could start a series of votes, but I don't think all the votes would pass. For example, I'm sceptical there would be support for allowing romanized entries for Russian or Ukrainian (especially given how very many romanization schemes there are — cf. Wiktionary:Beer parlour/2013/November#Including_multiple_transliterations.2C_from_multiple_systems.2C_in_entries). Having someone type a romanization into our search bar and be taken to an entry which defines the string as a romanization of [whatever] is only one of several ways of getting that person to the native-script form of the word. Another is having the search function find the romanization in the native-script entry and bring that up as a search result. (In this case, a search for mahā brings up మహా, महत् and महा as search results. A user who sees those search results gathered on the search page should, IMO, have no more trouble figuring out which one she is looking for than a user who sees those things gathered into an entry.) For some languages, another way of having the user find the native-script form is having an appendix (here or on WP) detailing the conversation between various romanization schemes and the native script. When the issue of romanizations of Phoenician and some other dead languages came up, my impression was that one reason so many people were OK with allowing romanizations of those languages to have entries is that those languages are indeed dead, and no-one is natively writing them in any script, and modern discussion of them often is in Latin script. For a language like Russian, which people are still natively writing in the Cyrillic script, I could see users preferring to skip having entries for the romanizations, and either use the search-bar functionality, or just rely on users to use the appendix to convert between romanization and native script. That's why I think it's useful to discuss each language on its individual merits (Anatoli seems to feel the same way). - -sche (discuss) 22:32, 6 June 2014 (UTC)
It seems to me that we are approaching two separate problems. Your take on this addresses the question of how we should provide readers with the ability to find the native-script entry for a particular romanization, which I grant is a reasonable question to consider. My take, however, is that if a "word" (broadly defines) is used in print to the extent that people might come across it and want it defined, we should have an entry for it, whether that word is violono or Portsmouth or mahā. The only remaining question is what form should this entry take. I am thinking, at this point, about drafting a proposal for a vote laying out a series of options (allow all such entries but treat them as loanwords, allow them and treat them as their language of origin, redirect them to the entry for the language of origin if there is a unique target, allow only select languages as approved individually by the community). bd2412 T 16:25, 7 June 2014 (UTC)

How is mahā different from fēngshuǐ?[edit]

We have an entry on fēngshuǐ which identifies it as a Mandarin romanization. However, it is easily possible to find examples of "fēngshuǐ" used in running English text. Why is this entry labelled Mandarin and not English? Should the existence of citations in English text lead us to have entries for both Mandarin and English "fēngshuǐ" (as we do for aloha? If not, then why would a comparable entry on mahā be labelled English rather than Sanskrit? Why not both, since citations can be found both in running English and in long selections of transliterated Sanskrit? If we are not prescriptive, why do we care if there is an "official" transliteration system, so long as we know such a system is in use? With such inconsistencies in our coverage of transliterated terms, it seems to me that we should err on the side of at least covering well-attested phonemes. bd2412 T 00:36, 6 June 2014 (UTC)

This is why fēngshuǐ should be violently killed. Wyang (talk) 00:42, 6 June 2014 (UTC)
@BD2412 You have to be clear about what you're proposing, rather than demanding - I want to include them, period.. If it's all about romanised Sanskrit or specifically the form mahā.
  1. Do you suggest to allow romanised Sanskrit entries? Please specify, which transliteration standard, what format. Why do we need them? E.g. Devanagari is too hard to learn/to type, there are too many homophones (I seriously doubt that). AFAIK, it has to be decided by a vote, the way Mandarin standard pinyin and Japanese rōmaji were decided. Note that pinyin and rōmaji are soft-redirects and disambiguations, they have no definitions, merely links to standard Chinese and Japanese forms. It's not allowed to have a pinyin or rōmaji entry if no single a Han character (or Japanese kana) don't exist.
  2. If it's an English word (borrowed from Sanskrit), citations should be provided. --Anatoli (обсудить/вклад) 00:52, 6 June 2014 (UTC)
@Wyang. I respect your opinion on the matter but... Well, that was decided by a vote, which actually heavily reduced the role of Pinyin, not without a very strong opposition. Similarly, the vote on Romaji reduced the role of Romaji, rather than introducing it for the first time. There can be different opinions on the importance of Pinyin or Romaji but they serve as disambiguation of various homophones and favoured by other Chinese, Japanese editors. --Anatoli (обсудить/вклад) 00:52, 6 June 2014 (UTC)
Re "Why is this entry labelled Mandarin and not English?": this is a conflation of two questions; let me separate them and answer each.
  1. Why do we have an entry for fēngshuǐ labelled as Mandarin? Answer: in Wiktionary:Votes/2011-07/Pinyin entries, the community decided to allow pinyin romanizations "using the tone-marking diacritics, [...] whenever we have an entry for a traditional-characters or simplified-characters spelling"; that vote cited [[yánlì]] as an example of how such entries would be formatted (note the ==Mandarin== header). In a subsequent vote, the community decided that various Chinese lects, including Mandarin, would be unified under the header ==Chinese==. It appears that fēngshuǐ has not yet been updated to use ==Chinese== rather than ==Mandarin== as its header; this can be ascribed to the fact that Wiktionary is a work in progress and is not complete or finished yet.
  2. Why do we not have an entry for fēngshuǐ labelled as English? Answer: either because fēngshuǐ is not attested in English, or because Wiktionary is a work in progress and is not complete or finished yet. If fēngshuǐ is attested, unitalicized, in English text, then it is a loanword and we should have an English entry.
Re "why would a comparable entry on mahā be labelled English rather than Sanskrit": if mahā is comparable to fēngshuǐ in that it is attested, unitalicized, in English text, in a way that conveys meaning (which I am not convinced is the case), then we should have an English entry because it is a loanword from Sanskrit used in English. If mahā is comparable to fēngshuǐ in that the community has voted to allow romanized Sanskrit the way it voted to allow Chinese pinyin, then we should have a Sanskrit entry for mahā per that vote. However, the community has not AFAICT held any vote to allow romanized Sanskrit. The comments I've seen in the BP and at RFD have suggested that such a vote would pass, but no-one has stepped forward to draft such a vote. - -sche (discuss) 01:07, 6 June 2014 (UTC)
(Re ==Mandarin== header in Pinyin entries) Good point. There are a few things to change, though. Our main Chinese editor Wyang, though doesn't support pinyin but we can still ask him to help to change it or get anyone else. Strictly speaking, Pinyin only applies to Mandarin=standard Chinese but it can still have ==Chinese== header and the templates could display Mandarin Chinese Pinyin reading of ... --Anatoli (обсудить/вклад) 01:15, 6 June 2014 (UTC)
@Anatoli, I am not proposing any specific solution per se; this is a discussion to figure out a solution. We have a lot of things going on here - transliterations from some languages presented as words in those languages, transliterations from other languages presented as English words, entries for various languages of "eye dialect" spellings (and a well-attested lay transliteration is basically an eye dialect spelling of a word from another alphabet). I would like to see some solution arrived at that allows us to cover all words in the way that our own corpus defines words, and to provide the most accurate description of what kind of word it actually is (a Chinese word, a Sanskrit word, a Russian word). I'm fine with this being done by redirect, but that only works to the extent that the only meaning of the word is as a transliterated form from the target language. I'm not convinced that allowing Sanskrit solves the problem. There are many languages and scripts for which these kinds of transliterations are well-attested.
@- -sche, citations of mahā attested, unitalicized, in English text, can be found at Citations:mahā. More can be found with a Google Books search, but there are also many instances of mahā being used in running transliterated Sanskrit text. Also, suppose a word is well-attested but exists only in italics? Suppose it is attested only in block of transliterated text from the same language? In that case, it is still an attested phoneme, and one that a reader might look up in a dictionary. Cheers! bd2412 T 02:14, 6 June 2014 (UTC)
I'm not sure I share the view that we have "transliterations from other languages presented as English words". We have entries for loanwords, and we allow romanizations for certain languages. In some cases, a string is both a valid romanization in Chinese or another language and a loanword, but then there are two L2 headers, and only the loanword is [or: should be] presented as English. If you find an ==English== entry that is only a transliteration/romanization, RFV it.
The 1991 citation in Citations:mahā is of Mahā Yogi, not mahā; the 1910 citation is of Mahā Bhārata, the proper name of a work (possibly not includable: we have Iliad, but we don't have The Fault in Our Stars). The 2004 and 2007 and 2014 citations (yes, I added the last of those — it was the 'least unconvincing' one I could find at the time) are italicized. The 2009 citation does not have an intelligible meaning, IMO: "the classification of mahāyoga into three parts, starting with the [great] of [great]"? What does that mean? The 2013 citation is arguably a good "jib"-type citation, although it explicitly uses a somewhat different definition than other citations ("greater" as opposed to "great"). - -sche (discuss) 02:40, 6 June 2014 (UTC)
PS, you seem to be using a sense of [[phoneme]] that our entry lacks; does our entry need to be expanded? - -sche (discuss) 02:45, 6 June 2014 (UTC)
I should say an unbroken collection of phonemes (although this could be read as excluding monosyllabic constructions). We have tovarish and tovarich as English "loanwords", and many others like those, but they are really only thinly disguised transliterations. What other dictionary in the world includes them as words in English? (Okay, this one might, but still.). If we ignore the italicization issue, then there are a great many uses of mahā (Mahā Bhārata is the name of a work, but it is still composed of individual words, just like Holy Bible; we do have the more modern form, Mahabharata). bd2412 T 03:01, 6 June 2014 (UTC)
  • Wiktionary:Neutral point of view is not a policy. WT:CFI is the inclusion policy. WT:CFI does not forbid attested transliterations from being in the mainspace. The claim "transliterations are not words" is hogwash. No discussion or vote has been produced to show that there is a consensus for forbidding attested transliterations from the mainspace. WT:CFI does not trade in the term "native script". There is no policy concerning native and non-native scripts, AFAIK. --Dan Polansky (talk) 17:50, 8 June 2014 (UTC)
    • I think NPOV is beyond policy even, it is one of the five pillars (on Wikipedia), and it is my understanding that it is indented to run through all Wikimedia projects as a guiding principal. That said, I think that both NPOV and the CFI would permit inclusion of all attested transliterations (and I agree that it is nonsensical to call them "not words"), and that we should have a vote if we are going to come up with a specific scheme for the limitation of these, and for the presentation of those that are included. bd2412 T 03:48, 9 June 2014 (UTC)
Hogwash, nonsensical? If you're both so sure that no vote is necessary and transliterations are "words" and are already allowed by current policies, why don't you create some transliterated entries and observe the results? --Anatoli (обсудить/вклад) 04:08, 9 June 2014 (UTC)
If romanizations were by default allowed, we wouldn't have had one vote to allow romanized Gothic, and then a second (more successful) vote after the first was judged to have failed. The fact that such votes have been held for every language for which someone has wanted to include romanizations is, to put it mildly, normative. If you want to change the status quo — you're in the right place doing the right thing (having a BP discussion).
Incidentally, I find it notable that that first vote is the only vote on allowing romanizations which I recall failing, and it failed because people like User:Msh210 objected to the suggestion that we start allowing romanizations of just any old language. - -sche (discuss) 05:01, 9 June 2014 (UTC)
Devanagari is also a living script with a number of languages, apart from Sanskrit, using it. If, for various reasons, after votes, transliterations were allowed for some languages, reasons for keeping transliterations specifically for Sanskrit have not been presented yet in this discussion, if we don't count arguments "transliterations are already allowed by CFI" or "I want them included, I don't care how". It's not even clear if this discussion is specifically about Sanskrit transliteration or any transliteration for any language written in non-Roman script. --Anatoli (обсудить/вклад) 06:42, 9 June 2014 (UTC)
bd2412 I don't think you could be more wrong, to be honest! We're just applying our own rules and because the people who participate in RFD's vary, decisions aren't always consistent. That's no different to a court of law where it depends what jury you get! What you seem to be saying is "I don't like this community decision, please change it" with the emphasis on the "I" (that is, you don't like it). Renard Migrant (talk) 10:39, 9 June 2014 (UTC)
In fairness, aren't most proposals for change made by people who say "I don't like the existing state of affairs"?
I'm somewhat surprised by how bristly this debate is getting. I apologize if I'm complicit in that to any extent. - -sche (discuss) 13:05, 9 June 2014 (UTC)
The English word feng shui is normally written without tone marks, since tone marks make no sense in English. —Stephen (Talk) 13:21, 9 June 2014 (UTC)
If someone had, in the past, called a vote to include the a common noun like cow in the dictionary, would that mean a vote is now required to include common nouns? There needs to be some standard by which a word is excluded before action needs to be taken to allow its inclusion. There is no actual rule being applied here that anyone has pointed to, and no definition of "word" that anyone has provided that would not include transliterations. The 2011 vote on allowing romanization of languages in ancient scripts, by the way, says nothing about the application of this rule to currently existing languages, and nothing about whether the words at issue meet the CFI. The illusion that an unwritten prohibition represents the "existing state of affairs" is about as reliable as the claims currently made in this dictionary that dagoba, khakkhara, and haramzada are actually words of the English language. I am not content to have us misleading our readers, either about our goal to have "all words in all languages", or about the actual language to which a word belongs. bd2412 T 14:14, 9 June 2014 (UTC)
ᛋᛏᚩᛈ ᛏᚱᚣᛁᛝ ᛏᚩ ᛗᚪᛣᛖ ᚢᛋ ᚠᛖᛖᛚ ᛒᚫᛞ ᚠᚩᚱ ᛏᚫᛣᛁᛝ ᛁᚾᛏᚩ ᚪᚳᚳᚩᚢᚾᛏ ᚦᛖ ᛠᛋᛁᛚᚣ ᚩᛒᛋᛖᚱᚠᚪᛒᛚᛖ ᚠᚫᚳᛏ ᚦᚫᛏ ᛚᚫᛝᚷᚢᚪᚷᛖᛋ ᚫᚱᛖ ᚹᚱᛁᛏᛏᛖᚾ ᛁᚾ ᚫ ᛚᛁᛗᛁᛏᛖᛞ ᚾᚢᛗᛒᛖᚱ ᚩᚠ ᛋᚳᚱᛁᛈᛏᛋ. ᛁᛏ ᛁᛋ ᚾᚩᛏ ᛈᚩᛁᚾᛏ-ᚩᚠ-ᚠᛁᛖᚹ, ᛁᛏ ᛁᛋ ᚾᚩᛏ ᛗᛁᛋᛚᛠᛞᛁᛝ, ᛄᚢᛋᛏ ᚳᚩᛗᛗᚩᚾ ᛋᛖᚾᛋᛖ. — Ungoliant (falai) 16:43, 9 June 2014 (UTC)
For the sake of convenience: running the above through Module:Runr-translit (with the language code "ang") gives "stóp tryiŋ tó maᛣe us feel bæd fór tæᛣiŋ intó accóunt þe easily óbserfable fæct þæt læŋȝuaȝes ære written in æ limited number óf scripts. it is nót póint-óf-fiew, it is nót misleadiŋ, just cómmón sense." The module may need some improvements. Keφr 06:53, 10 June 2014 (UTC)
On my computer, this shows up as a string of boxes. Obviously (like the transliterations I would propose to include) it would be much more helpful to the reader for this to be readable in Latin script. Has Wiktionary stopped caring about helping readers find definitions that they are likely to search for? bd2412 T 18:30, 9 June 2014 (UTC)
Languages may be written in a limited number of scripts, but I would practically bet that all of them have been written in the Latin script. I can try and think of possible exceptions, but if there are any, I'd be surprised if we had any vocabulary in any of them.--Prosfilaes (talk) 07:31, 10 June 2014 (UTC)
Re: "If romanizations were by default allowed, we wouldn't have had one vote to allow romanized Gothic, ...": This argument fails to distinguish attested transliterations from all transliterations. The vote allowed the inclusion of unattested transliterations (as long as the native-script form corresponding to the transliteration is attested), so went beyond the current CFI. Furthermore, an existence of a vote is no proof at all that there already exists policy that the voted proposal overrides; many a vote takes place in a policy vacuum, especially if it serves to confirm an uncodified common practice. --Dan Polansky (talk) 16:51, 9 June 2014 (UTC)
As I've said several times, the only real way to attest Gothic is in the Latin script. The Gothic script Gothic entries we have are most likely transliterations from the Latin script. There's a one-to-one correspondence, but still. If you find a book of Gothic text, it will be in Latin script. Unless you're into paleography, you will not find Gothic in the Gothic script. And no, I do not accept that citing published works transcribed from handwritten originals is acceptable for English but not Gothic.--Prosfilaes (talk) 22:13, 9 June 2014 (UTC)
Re: "If you're both so sure that no vote is necessary and transliterations are "words" and are already allowed by current policies, why don't you create some transliterated entries and observe the results?" This is just power talk: when the speaker cannot point to a policy--as he cannot--he instead threatens to delete transliterations, or have them deleted by another admin. There may be a consensus among admins that attested transliterations should be deleted (I don't know), but there is no policy supporting such deletions. --Dan Polansky (talk) 16:51, 9 June 2014 (UTC)
I'm not threatening anyone. It's you who is behaving as if there is nothing to discuss, as if it's a done deal because it matches your opinion on the matter and ridiculing those who disagree with you. There is no secret "agreement" among admins to talk about but entries in the wrong script (not native if you wish) are usually marked as such, converted to native script or deleted. --Anatoli (обсудить/вклад) 05:55, 10 June 2014 (UTC)
I dunno, Anatoli, denying the existence of the Deletionist Cabal seems like exactly the sort of thing a member of the Deletionist Cabal would do. I may have to report you to the Delete the 'Deletionist Cabal' Cabal... ;)   - -sche (discuss) 21:54, 10 June 2014 (UTC)
As for the Runic script (ᛋᛏᚩᛈ...) above, this entirely misses the point that we are talking attested romanizations; this use of runes is not attested.
As for cabal and secrecy, the only people claiming something is done in secret are those claiming that romanizations are already forbidden from the mainspace, since they were so far unable to provide references to a public record showing consensus for their exclusion.
FYI, I have created Wiktionary:Votes/pl-2014-06/Excluding romanizations by default. --Dan Polansky (talk) 09:49, 15 June 2014 (UTC)

A vote on allowing entries for romanized Sanskrit[edit]

I have drafted a vote: Wiktionary:Votes/pl-2014-06/Romanization of Sanskrit. I used basically the same wording as previous votes used; suggest improvements if you have any. The vote can be postponed as much as necessary. - -sche (discuss) 13:32, 9 June 2014 (UTC)

This vote began a while ago, FYI. - -sche (discuss) 16:20, 23 June 2014 (UTC)

A vote on allowing all attested romanizations[edit]

I drafted a vote: Wiktionary:Votes/pl-2014-06/Allowing attested romanizations. I tried to reflect, as best I could, what was proposed in this thread (see my notes on the talk page); however, as I am an opponent of blanket inclusion of romanizations, I welcome people who actually support the proposal to reword it as necessary. I am particularly interested in your views on which of these citations could be used to cite/attest (=support the existence of) a romanization entry, vs which, if any, could not. In cases where I only bothered to type up 1 or 2 citations of a given string, please assume for the purposes of discussion that there are enough other citations available to add up to 3: what I am interested in is what kind of citation "counts" as "attesting" a romanization. - -sche (discuss) 07:33, 10 June 2014 (UTC)

FYI: Wiktionary:Votes/pl-2014-06/Excluding romanizations by default. --Dan Polansky (talk) 09:51, 15 June 2014 (UTC)
Both votes' start dates were a couple of days ago, so I have removed the 'premature' tags from both, and voting has begun on both. (Some users had suggested merging the votes, but none showed any interest in drafting a merged vote, so the votes remain separate.) - -sche (discuss) 16:23, 23 June 2014 (UTC)

What are romanizations for?[edit]

This seems a deeper question to me than what I've read so far in this thread. What are romanizations for, in the first place? If romanizations are intended to solve a problem, what is that problem?

From my past experience here and from what I've seen mentioned above, the core issue appears to be findability or discoverability. (NOTE: This is setting aside the entire question of attestations.) If a language is generally written in Script X, it can be difficult for EN WT users, who can only be assumed to be able to type using the Latin alphabet, to find entries in that script.

Assuming that users would want to be able to search for entries using the Latin script, do we need to have separate entries just for the romanized forms? Is it enough now to simply include the romanization right there within the entry in Script X? Can our search software now find such entries? My own brief testing suggests that yes, our search software can find an entry in Script X when searching on a Latin-alphabet string, provided that said Latin-alphabet string is included in the page. Importantly, this Latin-alphabet string can be provided by a template, and does not seem to be needed as-is within the wikitext. C.f. this search for kamau, which does find the 構う entry, even though the string "kamau" does not appear anywhere directly within the wikitext, and is instead provided by the {{ja-verb}} template.

So long as our search feature allows users to find Script X entries when searching on Latin strings, I fail to see any need for separate entries just for romanized forms that only serve to redirect users to the Script X entries. As such, separate romanized entries looks like a solution in search of a problem. Is my understanding correct? Are there other problems that romanized entries are intended to solve? ‑‑ Eiríkr Útlendi │ Tala við mig 20:32, 10 June 2014 (UTC)

There's more to it than that. The search can find entries based on romanization, yes, but how well does it do that job? Is it obvious to readers how to provide their search query in such a way that the result they need appears first? How well does it perform if users simply type in the romanization and press "search", like they are accustomed to doing for other languages? What if the search term they entered exists, but does not lead them anywhere closer to their goal (and they don't realise there are really two types of search)? Furthermore, how practical is it to do this for every word they want to look up (which may be dozens if not hundreds per day)? All these are problems that having dedicated entries for romanizations will reduce if not eliminate altogether. A user looking for Gothic can now simply type dags in the search box, press enter, and be on their way. —CodeCat 21:15, 10 June 2014 (UTC)
"What are romanizations for" is not really a Wiktionary question, any more than "what are verbs for" or "what are place names for". Writers use romanizations to convey meaning, they are found in print, and they may be read by people who turn to Wiktionary to find out what mean is intended. It is a dicey proposition to ask readers to rely on our search system. What are they to do when a romanization of a word from one writing system happens to closely match an entry from a word in another language? Look at the Hindi दक्षिण (meaning southern), romanized as dakṣiṇa, just a few diacritic variations away from dakšiņa, the Latvian word for "fork". Not all romanizations have distinct diacritics, even. There will be romanizations for which the word exactly matches some other existing word. What are readers to do then, if we have no entry for the romanization? bd2412 T 21:26, 10 June 2014 (UTC)
  • Re: "What are romanizations for" is not really a Wiktionary question, any more than "what are verbs for" or "what are place names for". -- there is no reason to be obtuse, this is entirely within the context of the EN WT and more specifically this very thread. To be entirely explicit, I'm asking, what are romanizations for, with regard to EN WT entries.
Re: not all romanizations have distinct diacritics, it seems you've presented one more obstacle, rather than reason for adding separate romanization entries. If someone searches for daksina, say, the system should show both the Hindi and Latvian -- as it already does. Having a separate entry at [[dakṣiṇa#Hindi]] won't change that situation at all, other than to require users to click through one more level of abstraction (the romanized redirection page) before finally getting to the entry page. ‑‑ Eiríkr Útlendi │ Tala við mig 21:46, 10 June 2014 (UTC)
Sorry, I was not trying to be obtuse, but we don't generally ask the purpose behind having any kind of entry for a word that meets the CFI. The purpose is always to help the reader define the word. With respect to the obstacle I raise, I actually came into this issue because I was disambiguating "mahā" at Wikipedia, and needed to find a Wiktionary entry to link to when it was being used as a dicdef. Typing "maha" into our search engine took me straight to the unhelpful entry, maha, which only has completely unrelated meanings from completely different languages. The only way that I was able to find the Hindi word at issue was to use my admin bit to look at the deleted entry, mahā. bd2412 T 21:55, 10 June 2014 (UTC)
Thank you for clarifying, I clearly had the wrong end of that stick. Your reply also makes it clear that I needed to clarify that I am thinking past the bounds of CFI: any term in any non-Latin script should ideally have some romanized form included in the entry for better searchability, regardless of whether that romanized term can be attested anywhere.
FWIW, clicking the magnifying glass icon to go to the secondary search and entering mahā gets me this. From there I see the महा#Sanskrit entry, but no independent listing at all for the Hindi entry that you were looking for. (The Hindi term does show up in the etymologies of compounds, such as महेश्वर.)
Perhaps then the root issue isn't necessarily that EN WT should include separate romanizations for the sake of having them, but that the EN WT search feature is still inadequate (doesn't allow specification of languages when entering search strings, doesn't show language names in results, ordering of entries seems a bit arbitrary, etc.), and adding separate romanization entries is one workaround. Is that a good restatement of this issue? ‑‑ Eiríkr Útlendi │ Tala við mig 22:07, 10 June 2014 (UTC)
Come to think of it, I don't know whether the word as used in Wikipedia articles is meant to be Hindi or Sanskrit. All I, as the lay reader, can know for sure is that several Wikipedia articles on topics in Hinduism use the word "mahā", and that many books in print also use this word. The search function is only as useful as our ability to convey the means of using it to the average user, who may have very little experience with Wiktionary. If at all possible, it might be helpful to generate a list of transliterations that theoretically would be made under this proposal, and see how many of those are blue links having existing articles with other meanings in other languages. bd2412 T 01:16, 11 June 2014 (UTC)

Oh, wow.

I have tried my best to go through all of this discussion and the related votes. It is absolutely confused, the terms are used to mean different things by various participants, and the proposals and examples are vague and undefined to the point of meaninglessness.

If you guys can’t come up with something even a bit cogent, I’m just going to vote against all of it. Michael Z. 2014-06-16 22:51 z

@Mzajac: In my understanding, one rationale for allowing romanizations is "having entries for romanizations is the best way (or a good way) to get users to the native-script forms of words"; one rationale for excluding romanizations is that "romanizations are not the best way (or a good way) to get users to the native-script forms of words; it is better to have the search function find the native-script entries directly by finding the romanizations in them". An additional rationale for allowing romanizations is that "romanizations are words in the same languages as the native-script words they romanize, and as such merit inclusion" (so, e.g., in these citations, linked-to from the 'allow romanizations' vote, "svobodnyx" is [asserted to be] a Russian word); while a rationale for excluding romanizations is that "romanizations are not words, they are merely shadows of words, and as such are not intrinsically/automatically inclusion-worthy". Each side disagrees with the other side's rationales; each side further disagrees on whether the status quo is that romanizations like "svobodnyx" are allowed or excluded. - -sche (discuss) 23:10, 16 June 2014 (UTC)
It seems that now arguments are used like in Wiktionary_talk:Votes/pl-2014-06/Excluding_romanizations_by_default#Clarification_needed that if we exclude romanisations, then words like "judo" will be excluded. I agree with Michael that the whole discussion in various places is messy and confusing. If "... to get users to the native-script forms of words" is used then it should be clear they are soft-redirects and should only exist if native script entries also exist. BTW, instead of "svobodnyx", could you use the lemma form, rather than inflected, see свобо́дный (svobódnyj)? --Anatoli (обсудить/вклад) 23:40, 16 June 2014 (UTC)
Re "arguments are used [...that] 'judo' will be excluded": such arguments don't hold water, IMO. Re "свободный": If the vote to allow attested romanizations passes, and "svobodnyj" is attested, then both it and "svobodnyx" will be allowed, presumably pointing to свободный and свободных, respectively. - -sche (discuss) 23:53, 16 June 2014 (UTC)
OK. Are you able to provide an example of a romanised entry (which is not English but a romanisation only) for the vote(s)? Doesn't have to use any (final) templates but I need to see the structure. --Anatoli (обсудить/вклад) 01:48, 17 June 2014 (UTC)
I'm not one of the people who want to allow romanizations (I just drafted the votes, since it looked like no-one else had the time/intention to), so I'm all ears if either of them has a different idea of how romanizations' entries should look. However, in both the Sanskrit vote and the 'allow romanizations' vote, I specified that romanization entries "will contain only the modicum of information needed to allow readers to get to the native-script entry"; that's the same clause that was used for the vote on pinyin. For the Sanskrit vote, I spelled out that entries will look basically like the Gothic romanizations' entries (e.g. qino), except with "Sanskrit" (or in the case of svobodnyx, "Russian") headers instead of "Gothic". So, like User:-sche/svobodnyx. - -sche (discuss)
Thanks. I see. I am against romanisation entries (except for those, which are already allowed by a vote) but qino looks OK to me and User:-sche/svobodnyx is not. It goes way beyond "modicum of information...". If citations are required, they should be on citation page, IMO. --Anatoli (обсудить/вклад) 02:58, 17 June 2014 (UTC)
Okay, I’ll quickly summarize some of what is frustrating me:
  1. Why does this only apply to romanizations? What about Cyrillizations, &c.? Is it because the intent is to serve readers of English-language texts? If that is the case, then why not only accept romanizations attested in English texts?
  2. The wording makes it sound like any term that can be considered a romanization is allowed/disallowed an entry based on this proposal. That’s silly. Thousands of entries are loanwords that are arguably romanizations, in a narrow or broad sense. The wording has to be more specific to account for this conflict.
  3. Why does this refer to romanizations at all? Are we talking about loanwords in English texts whose spellings may be considered transliterations or transcriptions? Does it mean foreign words that are being mentioned in English texts? In other Latin-alphabet language texts like German or Lithuanian? And if so, why not Cyrillicized, Arabicized or Siniticized forms too? Why this level of specificity?
  4. What about words attested in spoken sources? Why does whatever principle is being applied here apply only to the written word?
  5. The given examples don’t help determine what is being proposed (Citations:mahā, User:-sche/svobodnyx). Some of them are proper names used in English. Others are words in transliterated titles of works. Some are accompanied directly in the text with a gloss, indicating that they are foreign terms being mentioned, and not used in an English text. They appear in their sources for various reasons that don’t relate to any rationale for this proposal that I can divine.
Perhaps a Romanizations section in the native-script entry would satisfy whatever needs this is meant to satisfy. It’s already been discussed and sort-of accepted twice. It could be limited to attested romanizations, or to standardized romanizations, or perhaps to the superset of both. (Actually, better a more general “Converted forms” section, including any foreign-language, other-script conversions or transcriptions makes better sense.) Michael Z. 2014-06-17 22:28 z
  1. At the very beginning of this discussion, BD did propose allowing entries for all transliterations, even cyrillizations, etc. The proposal got narrowed early on to only romanizations (see the initial exchange between BD and Ungoliant, and then BD's comment to Anatoli at 02:45, 4 June 2014), as some of the people involved seemed to recognize that the idea of allowing entries for cyrillizations, arabicizations, etc was so much more controversial than the already controversial idea of giving entries to romanizations that it would probably act as a poison pill.
  2. I personally think the wording of the vote is clear, particularly when taken together with the examples, which show that the vote is to take sequences like svobodnyx (in the Latin script) and include them under ==Russian== (not e.g. ==English==) L2 headers. How would you change the wording to make it clearer?
  3. See point 1.
  4. Huh? Audio has sometimes been cited to attest words (e.g. in [[Qapla']] we record that that word was uttered in the film Team America: World Police). I don't see how it could attest a particular spelling or script. In the case of Qapla', we used common sense / Occam's razor to assume that the word was in the script that the dialogue it was in it would normally be in (the dialogue was English, so: Latin script), just as we routinely assume books that seem to use words like "Москва" are in fact using those (Cyrillic) letters, and not using e.g. "Mоcквa" (a mix of Latin and Cyrillic letters).
  5. Re "Some of them are proper names used in English. Others are words in transliterated titles of works.": Yes. The main proponent of allowing romanizations, BD, has argued that those citations are still using the "words" to convey meaning; see his comment of 21:19, 10 June 2014 on the 'allow romanizations' vote's talk page, and this comment.
Now that we have Lua and transliteration is largely automatable (and now that Lua- and template-generated text is findable by our search engine), I agree that the inclusion of romanizations sections in the native-script entries is a reasonable idea, preferable to the idea of making entries for romanizations. - -sche (discuss) 23:27, 17 June 2014 (UTC)
Re: inclusion of romanizations sections in the native-script entries is a reasonable idea, preferable to the idea of making entries for romanizations. That's my point too. You don't need an entry for akīrtikara if अकीर्तिकर (akīrtikara) shows "akīrtikara" in the transliteration section. Further, if our searches allowed to select specific languages, then finding a foreign-script term would be even easier. For transliterations with complex diacritics we should develop reverse transliteration system, e.g use "jaaGgala" to search for जाङ्गल (jāṅgala) as is used by Spoken Sanskrit site. --Anatoli (обсудить/вклад) 01:55, 19 June 2014 (UTC)
I am curious about your opinion of cyrillizations. I have imported these tables from Wikipedia's article on Cyrillization of Chinese (there is a similar table on Cyrillization of Japanese), and would like to see the entries made for the Cyrillic phonemes (and here I mean all of the one-syllable phonemes). bd2412 T 04:07, 19 June 2014 (UTC)
Well, (Russian) Cyrillisation of standard Chinese (Palladius) or Japanese (Polivanov) (there's also Korean (Kontsevich)) is only needed to understand how Chinese, Japanese or Korean people's or place names, concepts are usually written in Russian or can be written or transliterated for education (other Cyrillic based language have similar but less systematic standards). E.g. it's Хиросима (Hiroshima), not "Хирошима", "гоюй" (Guoyu), not "гуою", Korean "ханча", not "ханджа" - hanja. There are some exceptions (Токио, Иокогама, not Токё, Йокохама/Ёкохама - Tokyo, Yokohama) and traditional spellings (Пекин, not Бэйцзин - Beijing), variants (Аомынь not Аомэнь - Aomen, Macau). They can stay in appendices, I don't know if we need entries for them, unless they are words, like proper nouns, loanwords. I actually think that Cyrillisation is a bit of a misnomer here, they are rather Russifications, these systems are partially used in other languages or sometimes used as a base but they definitely won't fit for Ukrainian, Belarusian, Bulgarian, Serbian and Macedonian without changes. --Anatoli (обсудить/вклад) 04:30, 19 June 2014 (UTC)
An appendix would be suitable, so long as the appropriate redirects were made. Something would need to be done about the many existing entries for Russian words having different meanings that coincide with these Cyrillizations (if that's the wrong word, than Wikipedia's article needs fixing also). This leads to wonder, by the way, are our romanizations of Chinese and Japanese characters and words universal to all languages using the Latin alphabet? bd2412 T 17:26, 19 June 2014 (UTC)
I suggest Cyrillization for Russian, etc., just like there are romanizations that are characterized as “international,” “English,” “German,” etc. Russification (Russianization?), Anglicization, etc., are very broad terms, and as far as I know, they don’t conventionally refer to script conversions. Michael Z. 2014-06-27 18:09 z

@Michael Z., my entire consideration here is that if there is a reasonable possibility that a reader will come across a "word" while reading books in print (and by "word" I mean something that the average person would look at and believe to be a word), and may want to find out things about that word (definition, etymology, pronunciation, etc.) for than word, then that word should be included in our corpus to offer these kinds of information. Whether there is a reasonable possibility is why we have a CFI. We should do these thingsbecause our goal is to provide "all words in all languages", and we do not have the limitations that other dictionaries have. Of course, words found only in spoken sources aren't going to be come across in print until some author chooses to write about and transliterate them. bd2412 T 17:23, 19 June 2014 (UTC)

Well, our framework treats “all words (used) in all languages,” that is, each term meriting an entry, as a word of a particular language. Specifically, every attested term used as a native or naturalized expression.
What you are proposing is broadening our general principle, and accepting every mention too (“all words ever mentioned”). This is a much bigger discussion than just “accepting transliterations,” and should be discussed as a fundamental change to the principles of CFI. Michael Z. 2014-06-27 18:09 z
Where in any policy do we define "word" as limited to a "native or naturalized expression"? That certainly is not our practice, which already includes tens of thousands of entries that do not fall within that limitation, including all Latinized entries from words with dead scripts or languages without scripts, all translingual terms, all of our existing romanizations of Chinese and Japanese words and characters, and many words like tovarish/tovarich that are in reality transliterations from other scripts, even if they are listed as "English". bd2412 T 18:26, 27 June 2014 (UTC)
  • It bears noting that all Japanese and Chinese romanized entries (and, I think, all romanized entries for Gothic as well, among others) are there purely to aid in finding the lemma entries. These are not, nor should they be regarded as, entries unto themselves -- they are no more than workarounds for our profoundly inadequate search features. ‑‑ Eiríkr Útlendi │ Tala við mig 21:55, 27 June 2014 (UTC)
  • I would not envision entries for attested romanizations as serving any other purpose than that. bd2412 T 00:55, 28 June 2014 (UTC)
Bd2412, Nope. At best, you are listing a set of explicit exceptions to the principle that I mentioned.
  1. Dead scripts handling is an explicit exception. They are largely used academically in romanized form.
  2. Translingual is the combining of entries for expressions used natively in more than one language – and arguably, many violate CFI because they are not terms, or words, or lexical items (are 3, , , 𝄇, and “words”, to be “defined” in dictionaries?).
  3. Chinese and Japanese romanizations are native forms used in Chinese and Japanese, are they not?
  4. Tovarish is an English word: I don’t understand how saying that such words “are in reality transliterations from other scripts” contradicts that – a naturalized or semi-naturalized borrowing remains a borrowing, regardless of what script the donor language relies on: tovarishes of the tsar is no less English than three cappuccinos. Furthermore, the argument for picking out only “transliterations” this way makes no sense. The set of spellings of the term tovarish is a result of the combined influences of transliteration, direct transcription, English transcription of utterances, and re-borrowings from other languages. For evidence, the OED entry’s citations include tavarisch, tovarisch, tovaritch, tovarich, and Tovarishch. A spelling is not a term, and the surmised source of a spelling doesn’t determine the identity of a term.
The whole proposal presupposes that “a transliteration” is a kind of term, but it is not. A transliteration is one expression of a term, derived from another expression of a term. Also, don’t forget that although we have a web page for every variant spelling, capitalization, hyphenation, or other orthographic form (form-of entries, “soft redirects,” &c.), our proper entries actually represent terms, not spellings. Michael Z. 2014-06-28 16:28 z

Civility and formatting of citations[edit]

Yesterday, I politely reminded Spinningspark at RfV to format cites per our guidelines when adding them to citations pages, rather than posting a string of unformatted links. Spinningspark told me to die. I told Spinningspark that such hostility was "uncalled-for and completely unacceptable," and in response I was informed "my comment was completely called for."

Such incivility is unacceptable and should not be tolerated. -Cloudcuckoolander (talk) 16:52, 5 June 2014 (UTC)

I agree. It's a very reasonable request to ask a user to format citations correctly. We inform new users when their formatting is off all the time, so an experienced user like Spinningspark should have no problem in handling that. His reaction was definitely not acceptable. —CodeCat 17:14, 5 June 2014 (UTC)
Right. If one is going to add citations to a citations page or an entry, one ought to take the time to properly format them. Otherwise post whatever Google Books/etc. links you find in the RfV discussion so that someone else can step in and do the formatting. Does someone also want to inform Spinningspark of this discussion? I don't want to do it myself due to involvement/conflict of interest. -Cloudcuckoolander (talk) 17:28, 5 June 2014 (UTC)
Strictly speaking, "go hang" is a relatively mild oath, and not one that I would equate with literally telling you to die. bd2412 T 17:34, 5 June 2014 (UTC)
Well, I don't think everyone who adds citations has to know how to format them correctly. Everyone has to learn. But I think if someone asks to format them, it's a very reasonable request that someone who is willing to cooperate with the Wiktionary community (and its practices) should have no problem with fulfilling. So if the user just flat out refuses in such a hostile manner, it's more or less implying that they don't want to take responsibility for their work, hence willful disruption of Wiktionary ("I know how to do it because I have been told, and I know that if I don't do it it gives others more work, but I'm still not doing it"). —CodeCat 17:39, 5 June 2014 (UTC)
I was not aware that "go hang" had an idiomatic meaning roughly equivalent to "take a hike" or "pound sand." To me it read as an instruction to "drop dead" or "go kill yourself." However you cut it, though, it's hostile language, and and hostility (especially unprovoked hostility) is not conducive toward a collaborative project. -Cloudcuckoolander (talk) 21:13, 5 June 2014 (UTC)
You coming to the Beer Parlor to blow the whistle on a fellow Wiktionarian is uglier than Spinningspark's incivility, IMO. Grow a pair. --Vahag (talk) 17:54, 5 June 2014 (UTC)
We don't have any formal dispute resolution processes or noticeboards etc. like they do on Wikipedia (at least none of which I am aware). This is the only place I could think of to bring this incident to the community's attention, because the alternative, of course, was to ignore it, and incivility has been passively tolerated for way too long around here. Something needs to change. Preventing editors from getting tired of incivility and leaving is more important in the long-term than not stepping on anyone's toes by daring to call out unacceptable conduct. -Cloudcuckoolander (talk) 21:13, 5 June 2014 (UTC)

I always take the time to correctly format any kind of material that I place on an entry page to the best of my abilities. That is our "product" and is the part of the project on display to the public. That is expected of anyone and I am not an exception. However, RFV is a page requesting someone to find citations. I have found some, as requested. That is helpful. Me not formatting them and not putting them in the entry is no more unhelpful than anyone else not doing it. Just because I found some citations does not oblige me to do anything with them. This is a volunteer project and I am choosing not to volunteer.

The citations were placed on the citations page rather than the RFV page because I have repeatedly been asked to do that.[4][5][6][7][8] I am happy to go back to placing them on the RFV page if that is what is wanted, but I really don't understand this attitude that we really don't want to hear about cites unless they are perfectly formatted. SpinningSpark 23:44, 5 June 2014 (UTC)

  • Citations pages are a product too; they exist to show the reader examples of use in historical context. A citations page is not necessary to resolve an RfV discussion, but they tend to be made because the cites have been collected. Therefore, if you are only going to provide bare links, it is probably best to post them in the RfV discussion itself. If you are up to fully formatted cites, those don't need to be on a citations page, but may as well. bd2412 T 00:09, 6 June 2014 (UTC)
    The previous requests that the unformatted links be placed on the Citations page was an effort to put them one step closer to being usable in the face of Spinningspark's failure to format them as the rest of us do. In those locations a dump run could at least find them easily and someone else could clean up Spinningspark's mess. DCDuring TALK 00:42, 6 June 2014 (UTC)
    If I had been running around spoiling nicely formatted citation pages by dropping bare urls on to them then you might have a point, but I would never do that. Where others have already begun the work of producing a formatted page of citations then I am always careful to follow. But then, there is rather less need to find citations if others are already doing it. It is unfair to characterise me as a misfit who is refusing to conform to site standards. What I am really doing is the work of finding cites when no one else has the time, can be bothered, or wants to save the entry. Would you rather have the cites or not?. "Fitting in", in the case of most of the entries I have responded to, would not be formatting the cites I provide, it would be doing nothing and leaving the page blank like everybody else has.
The real unacceptable behaviour here is the opprobrium that is being heaped on me for doing this work. I'm not looking to turn this into a dick measuring contest, but if someone were to do some stats of RFV I am pretty sure that a very significant percentage of the cites found in response to those requests would be from me. I should be thanked for fulfilling this task when no one else wants to do it, but instead I am being hounded and criticised for it. SpinningSpark 07:16, 6 June 2014 (UTC)
I agree that you deserve thanks for the work that you do. I do disagree with the rationale enunciated by DCDuring, and would still have bare links put in the RfV discussion rather than on a citations page, regardless. bd2412 T 11:47, 6 June 2014 (UTC)
@Spinningspark: Relatively speaking, finding the citations is the fun part of the task of documenting our definitions. Formatting them, though not difficult and not painful, is definitely less fun. Using our various "quote" templates makes it much less tedious than it could be — but not fun. Therefore we follow the simple fairness rule of allocating to the person having the fun of finding each quotation the less fun task of formatting the quotation in the entry. This is simple plays-well-with-others schoolyard justice.
@BD2412: Because, 1., the final resting place of the citations will be in the entry or its citations page, 2., the definition being "cited" is always part of the problem and is always in the entry but not always in the RfV, and sometimes 3., because the context of multiple definitions in a PoS helps us better grasp a particular definition, it has always seemed more efficient to me to just insert the citations where they will ultimately be, thereby enjoying the benefits of seeing how citations fit in the entry, rather than in an out-of-context argument on the RfV page. DCDuring TALK 12:28, 6 June 2014 (UTC)
Exactly where is this guideline that says the person reporting a cite is allocated the work of formatting it? RFV is a page asking for citations. Providing them I would have thought is exactly what is wanted. You might consider that to be only half the job, but at least I have left the task only half undone when everyone else left it fully undone. Frankly, if such a guideline actually exists, or you manage to get one created, then I will probably unwatch RFV and not bother in the future at all.
As for fun, there are two extremes here. At one end is the case of wifty (which led to this thread in the first place). Cites for wifty are so easily found with the simplest of gbooks searches—no need for complex search terms or scrolling through pages of results, they just leap out at you—that I would have thought that all that was needed was to point that out for the RFV to be settled. I am sure if the proposer of the thread had done that search there wouldn't have been an RFV in the first place. In cases like that I really don't feel inclined, or see the need, to do a lot of work on the entry. It's these kinds of drive-by requests that are the make-work at RFV, not me finding cites for the make-workers. And playground responses along the lines of nah nah nah we're not listening unless you do it properly [9] are really not going to change my mind.
At the other extreme are obscure words that are really difficult to cite. A search term that zeroes in on that exact sense is hard to come up with and many pages of false hits have to be examined. It is not exactly fun to go through page after page of google results. It is quite satisfying when one finds something, but not fun. I am much more inclined to put cites in the entry under those circumstances (properly formatted of course) to preserve a record of what I found. If others feel I am hogging all the fun, then by all means jump in and find some cites yourself! SpinningSpark 16:27, 6 June 2014 (UTC)
Speaking of tiresomeness of formatting citations: some time ago I wrote a gadget (Quiet Quentin) which can assist in finding citations on b.g.c and format them accordingly. It is at the bottom of Special:Preferences#mw-prefsection-gadgets. The generated markup often needs manual corrections, but nevertheless the tool takes much of the burden away. Unfortunately, there will be probably no Usenet support, because I could not find a public JSONP API for searching it anywhere. Keφr 16:43, 6 June 2014 (UTC)
@Spinningspark: re: "Exactly where is this guideline [] ". Certain aspects of behavior don't actually require documentation among well-socialized mammals (animals?). Humans usually pick up basic civility (tit-for-tat, golden rule, taking the good with the bad, etc) in the schoolyard, though application in new realms often proves challenging. Admittedly, the online environment seems to require more explicit norms than some other environments. And some folks may not have had good schoolyard experiences. DCDuring TALK 18:37, 6 June 2014 (UTC)
I didn't learn anything like that in my schoolyard. Maybe I learnt that if someone starts ordering you about tnen you should hit the fucker first before the fight starts properly, but nothing in etiquette that would actually be useful at a dinner party. SpinningSpark 23:27, 6 June 2014 (UTC)
That explains it. DCDuring TALK 23:45, 6 June 2014 (UTC)
This is a bit painful to watch: two people who unselfishly make massive, high-quality contributions to rfv fighting each other, and a general atmosphere of negativity in the comments posted by others.
Although I tend to side with Spinningspark on substance in this issue, he can be a bit rude at times- though I would say describing it as "extreme incivility" is a bit much. The paradoxical effect is that, of all the people who contribute searches to rfv without adding formatted cites to entries, Spinningspark is the only one consistently singled out for criticism for doing so.
I think everyone here needs to take a step back and look at the big picture: this is a community effort which requires the voluntary efforts of real people, with all their quirks and flaws, virtues and vices. Negativity tends to lead to more negativity, not to the kind of results we want. Too much negativity, and people stop participating.
I would say to Spinningspark: please consider biting your tongue every once in a while and being more civil, even when people make unreasonable or unfair demands. Otherwise, you're moving the focus away from what you're responding to and onto your response- letting the others off the hook.
I would say to those criticizing Spinningspark: don't look a gift horse in the mouth. Maybe Spinningspark should be more careful about what gets put on the citations page if that forces others to fix things, but Spinningspark shouldn't be criticized for not putting things there in the first place. Sure, someone has to prepare and enter the cites, but Spinningspark could just not contribute anything, and then someone would still have to prepare and enter the cites anyway, but they would also have to do Spinningspark's part, too. I don't see the point in criticism over this. It's one thing to make sure that people are aware that there's more to it than just finding the cites, but if someone already knows this and makes it clear they just don't want to do it, nothing good will come of making it an issue- criticizing a volunteer for not volunteering enough is more likely to to lead to less volunteering, not more.
Not that I'm accusing anyone of hypocrisy: everyone who's participated in this discussion has contributed many times more than enough to the project to have every right to speak on this issue. Cloudcuckoolander, particularly, isn't appreciated enough for doing what Spinningspark has been doing, but doing all of it and doing it right. My point is that having the right and the standing to say something doesn't make it a good idea- if people see that their contributions will be met with criticism for not contributing enough, they'll just not contribute at all. Chuck Entz (talk) 19:44, 6 June 2014 (UTC)
I also wish Spark would play ball regarding formatting — and if he/she can't, then post citations to some other location where they can be fixed by us before adding to the entries (which won't help our already huge workload) — but I still think that conflicts and disagreements are something that happens, and something that human beings should be raised to deal with. Offence is taken, not given. Some people are rude; it may mean you don't want to deal with them very often; but most people in the world are not you. Usenet policed itself perfectly well long before the WWW, when there were no "moderators" or "administrators", just common sense and a majority who supported netiquette. I don't see incivility as a serious project problem unless it's abuse and threats. Equinox 21:02, 6 June 2014 (UTC)
@Chuck Entz — The choice of the description "extreme incivility" was the result of my initial thought that "go hang" was an instruction to die rather than an idiom roughly equivalent to "take a hike." I went ahead and changed the section title above.
If I'd been catty in my initial request to Spinningspark, I could understand receiving a defensive response. But I wasn't catty. I didn't complain about having to finish what he'd started. I thanked him for taking the time to collect cites and politely requested that in the future he remember to format cites before putting them on the cites page.
This was the first time I ever asked Spinningspark to format cites. I walked into this unaware that there is apparently a history of Spinningspark being asked to format cites. So I didn't know that my request might open an old wound, as it were. Being one of the relatively small pool of editors who regularly do legwork at RfV, I will admit that I've occasionally experienced a sense that the important contributions I'm making toward the project are going unnoticed. But I'm still receptive to polite requests to do things differently, and if I don't agree with a request, I try not to take it personally, and state my objections in a non-confrontational manner.
One of the concerns raised about Luciferwildcat was that he didn't properly format the entries he created, and this meant more work for someone else. This drove home to me that "if you're going to do something, do it right" is a philosophy by which Wiktionary operates. I don't think Spinningspark should be given a free pass in this regard. No, I'm not suggesting that Spinningspark is under any obligation to gather or format cites if he does not wish to do so, but if you are going to post citations in an entry or on a citations page, you are obligated to do it properly. Asking someone to correctly format cites when posting them to a citations page is not an "unreasonable or unfair demand."
And, frankly, I find it troubling that you would request we refrain from calling out Spinningspark on the grounds it might drive away a valuable contributor, and yet not take into consideration that having to endure hostility might also drive away valuable contributors. Do I really need to point out that I am also a volunteer and am under no obligation to "grow a pair" as Vahag suggested above and tolerate hostile treatment? -Cloudcuckoolander (talk) 17:36, 7 June 2014 (UTC)
I think we all feel like our valuable contributions go unnoticed. How often do you see any contributor here thanking another for anything? Maybe it's because of the small size or relative wonkiness of this community, but we don't really have the culture of appreciation that Wikipedia tends to have. There are some rough edges here, and there are likely to continue to be, but all that said, we have managed to build one hell of a dictionary. bd2412 T 18:02, 7 June 2014 (UTC)

Translingual entries and Chinese entries in the new format[edit]

We have tens of thousands of Mandarin, Cantonese, etc. entries lacking definitions, also with ===Hanzi===, ===Han character=== requesting definitions but Translingual entries have imported definitions, rather generic and vague, obviously without part of speech info.

As a first step, I suggest to merge all or most single-character definitionless Chinese (i.e. currently Cantonese, Mandarin, Hakka, Min Nan, Wu) entries using this entry (see this revision) as an example. The last edits removed ==Cantonese== and ==Mandarin== sections with nothing particularly useful (only request for definitions and transliterations, which are not lost), created ==Chinese==, merged definitions requests (with {{defn}}) into one language, all definition requests would now be in Category:Chinese definitions needed. If this format is accepted, perhaps a bot might bring all similar entries into this format (or similar, depends what readings/topolects are available, whether Old Chinese and Middle Chinese information can be obtained). Please comment (hopefully without trolling about "destruction of Sinitic languages", we are not destroying anything). Another point is, the example entry uses ===Definitions=== header, which is still under discussion in the 2014 May page. Since not only definition is unknown but PoS, ===Definitions=== may be the best choice in this case.

@Wyang: please join. --Anatoli (обсудить/вклад) 03:51, 6 June 2014 (UTC)

And this is an example of a single-character entry WITH definitions - this revision of . @Bumm13: I have edited just after you, please check. --Anatoli (обсудить/вклад) 04:17, 6 June 2014 (UTC)
The principle seems good to me. The technical side could be very challenging after 12 years of scattered edits. Wyang (talk) 07:27, 6 June 2014 (UTC)
It's understandable, partial recreation of entries may be required. Entries without definitions and sometimes erroneous transliterations have little value. --Anatoli (обсудить/вклад) 08:08, 6 June 2014 (UTC)
Spot-checking a few of the approximately 30 000 Chinese-character entries which use {{defn}} leads me to suspect that even after all these years, a large number of them have only been edited by bots making changes to all of them en masse. So, don't be discouraged from trying to sic a bot of your own on them ... the percentage of them that follow a predictable format and thus can be cleaned up by bot may be larger than you expect. :) - -sche (discuss) 05:17, 9 June 2014 (UTC)

Tone and register used in Wiktionary content[edit]

On my talk page here, another editor complained that we should use "whom" because it's "correct", which I disagree with for the reasons I gave in the discussion. But I wonder what others think of this. We have occasionally had complaints that definitions are terse and complicated, or use words no longer in normal use (thou is notorious), and they can't easily be understood. So I think that we should avoid using language that is no longer widely used in speech. —CodeCat 10:43, 7 June 2014 (UTC)

Thou is in a different class from whom. Whereas "thou" is genuinely archaic and is never used except when one desires to be deliberately archaic, "whom" is still used somewhat extensively in formal contexts. Just my 2p. If I may not take part in this discussion, I shall abstain from doing so. Velociraptor888 10:49, 7 June 2014 (UTC)
While I agree that "for who" is not an error, it is less formal and therefore less appropriate than "for whom" in the context of a dictionary definition. Although we are a descriptive and not prescriptive dictionary in our scope, our readers have a right to expect a certain degree of formality and adherence to the prescriptive rules of edited written English in our content. —Aɴɢʀ (talk) 11:27, 7 June 2014 (UTC)
We have every right to be prescriptive for ourselves, and I completely agree that we should use formal language (including whom) in our definitions (but not necessarily usage examples). --WikiTiki89 14:40, 7 June 2014 (UTC)
Formality, yes; words [ie, lemmas] less frequent than the top 30,000 or so of current English, not unless the definiens itself is technical. DCDuring TALK 16:33, 7 June 2014 (UTC)
The overall frequency of whom is irrelevant. What matters is its frequency in the place where you would expect it, which in informal settings is probably nearly 0%, but in formal settings I'd expect it to be around 90%. --WikiTiki89 17:25, 7 June 2014 (UTC)
I've never used it, no matter what the context. It feels very pretentious and unnatural to me. —CodeCat 17:31, 7 June 2014 (UTC)
Yes, but you live in the Netherlands. --WikiTiki89 19:28, 7 June 2014 (UTC)
So when you have a sentence that would be ungrammatical if it used who (e.g., "an unrepentant criminal on whom the court imposes an additional penalty"), do you just make it ungrammatical, or do you rephrase it to avoid whom? —RuakhTALK 00:11, 8 June 2014 (UTC)
I use who. Although I think I would rephrase it anyway, not to avoid whom but just because it sounds more natural: "an unrepentant criminal (that/which) the court imposes an additional penalty on". whom just isn't in my normal vocabulary at all, it feels more or less like an archaic synonym for who, and so who doesn't strike me as ungrammatical in the slightest. It's simply my own feel for the language as a native speaker; it's how I learned to speak and have always spoken and been spoken to in English. —CodeCat 01:37, 8 June 2014 (UTC)
Then you should consider editing your user-page to remove your claim that you're a native speaker. I do not think *" [] criminal on who the court [] " is English. (And I think that this use of "which" is actually archaic, unlike "whom" which is merely formal; but I'm not sure, it may just be dialectal.) —RuakhTALK 07:18, 9 June 2014 (UTC)
That sounds like a w:No true Scotsman argument to me. —CodeCat 10:02, 9 June 2014 (UTC)
Well, sure. English is defined as the native language of native English speakers, and native English speakers are defined as those who have English as their native language. Your English is excellent, but if you've internalized a rule that it's always grammatical to substitute "who" for "whom" without making any other changes, then I believe you are, in that respect, at variance with native speakers. (Of course, English has many dialects, and your difference from an actual dialect seems to be less than many dialects' differences from each other. I'm not saying "OMG yur t3h suck", I'm just saying that I think you're wrong about this point of usage.) —RuakhTALK 17:55, 9 June 2014 (UTC)
I consider myself a native speaker of Russian. However, since I did not grow up in Russia (but in the US), many things that sound outdated or archaic to me, I am often surprised to find are actually still in common use in Russia. This does not mean I'm not a "true" native speaker, but just that I grew up in a different environment and therefore cannot always judge what is archaic or not in Russia itself. --WikiTiki89 13:42, 9 June 2014 (UTC)
That's fair. I recently had a similar realization for Hebrew. (Though unlike you and CodeCat, I've chosen not to list my Hebrew as "native" on my user-page.) —RuakhTALK 17:55, 9 June 2014 (UTC)
I think the issue isn't whether we should use "who" or "whom" in entries, but whether you should be reverting someone for making what you consider to be the wrong choice. Sure, I've reverted edits that added an obsolete 16th-century term to a definition- but that's because it would make it harder for an ordinary person to understand. "Whom" is different: it's still in use, especially in more prescriptive contexts. People may not identify with those who use it, and they may not remember the rules about when to use it, but they still understand it just fine.
With all of the truly awful stuff that gets added to entries, I'm simply not going to bother with borderline issues like this. If someone wants to replace "who" with "whom", or vice versa, I leave them alone unless it looks like it's going to degenerate into an edit war (sometimes I'll revert pondian color/colour edits for that reason). The same goes for hyphens vs. dashes, ending sentences with prepositions, etc. Unless it's going to make it harder to understand, or it's going to make many of our readers cringe (e.g. possessive "it's"), I let people do what they think is best. Chuck Entz (talk) 20:07, 7 June 2014 (UTC)
Re who/whom: These ngrams suggest whom is still dramatically more common than who as the objective case of who following a preposition. Anecdotally, I've often seen objective-case use of "who" deprecated, while I've never until now heard anyone oppose "whom". Therefore, I'd say that while contributors can create entries with whichever of "who" vs "whom" they personally feel more comfortable with, I wouldn't revert someone who cleans up the "who"s to "whom"s. PS, "whom" passes DCDuring's test: oxforddictionaries.com lists it as one of the top 1000 words in its corpus, and in the Corpus of Contemporary American English it's the 1021st most common word. - -sche (discuss) 20:21, 7 June 2014 (UTC)
I'm not surprised. I even feel that "The person to who it was given" sounds really awkward since a formal context would use "whom" and an informal context would use a dangling preposition. --WikiTiki89 06:56, 8 June 2014 (UTC)
In the edited works at Google N-gram "who it was given to" does not appear whereas "whom" variations with and without dangling "to" do. In speech I'd expect the absent version to be more common.
In any event "whom" would seem to be required to give the impression that Wiktionary definitions are written in English. DCDuring TALK 12:12, 8 June 2014 (UTC)
Steven Pinker mentions whom specifically in his book The Language Instinct. He says it's a relict of a dying Germanic case system and shouldn't be mandatory. My words now not his, but try objecting to someone who doesn't use the -est ending for second-person singular forms like sayest and talkest. They'll probably say that's ridiculous, to which you say it's the same principle just -est forms died out longer ago. Renard Migrant (talk) 10:29, 9 June 2014 (UTC)
I must disagree with Pinker. Are we to similarly discard him, them, her, me? ‑‑ Eiríkr Útlendi │ Tala við mig 20:42, 9 June 2014 (UTC)
I have learned that whom is BE, and AE uses who exclusively. -- Liliana 11:21, 9 June 2014 (UTC)
AM uses whom in formal literary language, but who in spoken language. Usually when someone uses whom in spoken language, they are being humorous. —Stephen (Talk) 12:02, 9 June 2014 (UTC)
I doubt there is much actual difference between American and British English on this, despite common perception (but I may be wrong). --WikiTiki89 13:42, 9 June 2014 (UTC)
Whom is used in spoken American English, but not in some situations, especially where there is a separation between the preposition or verb of which who/whom might be the object. Usages such as "Who did you see?" and "Who did you give it to?" are very common in spoken American English and not rare in written American English. I suspect that other varieties of English show a similar pattern, though frequency may differ. DCDuring TALK 16:38, 9 June 2014 (UTC)
As another anecdoctal point on the graph, my experience of US English matches DCDuring's. ‑‑ Eiríkr Útlendi │ Tala við mig 20:42, 9 June 2014 (UTC)
MWDEU devotes 2 full pages to use of who and whom. It notes object use of who and subject use of whom. They cite Shakespeare for instances of all of the four main uses. They specifically say that there is not evidence of the decline of whom in written English. I don't think that Garner's (2009) is entirely accurate, but they strongly defend objective whom and nominative who, except in intentionally casual writing. I commend any good descriptive style book or grammar from Jespersen and Mencken to the present for details on use in both speech and writing. DCDuring TALK 23:52, 9 June 2014 (UTC)
My experience in CanE is similar to DCD’s.
Let’s avoid any construction that would look like an error to readers. It’s distracting, possibly confusing, and probably harmful to readers’ confidence in the dictionary’s reliability. Please use whom where it is conventionally used in formal writing. Michael Z. 2014-06-16 20:53 z

Module:category tree[edit]

I created this module to replace {{catboiler}}. Right now it does exactly the same as the template did, so nothing has changed when it comes to creating new category names for existing templates like {{poscatboiler}}. The module just uses the existing subtemplates, there is no data module yet. So for most editors nothing has really changed, but I just wanted to let them know anyway. —CodeCat 22:39, 9 June 2014 (UTC)

boldfaced forms of invariant lemmata in headword lines[edit]

(Already mentioned at module talk:headword; now I'm bringing it here, where it belongs.)

At [[bonefish]], {{en-noun|bonefish|bonefishes}} displays

''plural'' <span class="form-of lang-en plural-form-of"><b class="Latn" lang="en"><strong class="selflink">bonefish</strong></b></span>

rather than

''plural'' <span class="form-of lang-en plural-form-of"><b class="Latn" lang="en">bonefish</b></span>

as it (IMO) should, because it 'tries' to link to the plural. I propose this be changed. Thoughts? (I guess function format_parts can be modified somehow to fix this.)​—msh210 (talk) 17:38, 11 June 2014 (UTC)

As I mentioned to you in the talk page, it's not the module that is responsible for the extra "selflink" tag, it's the wiki software itself. It does that whenever you link to the current page, like here: Wiktionary:Beer parlour/2014/June. —CodeCat 17:45, 11 June 2014 (UTC)
Hrm... doesn't adding an anchor like "#English" stop the software from thinking that it is in fact linking to the same [exact place on the] page, like here (where only the last link is bolded)? I presume headword templates add such anchors, so er... why are the links still bolded? (And why is it a problem that the invariant plural is bolded, when the '-es' plural is also bolded? I think either bolding all plural forms or bolding none of them is good. Am I just totally misunderstanding what's being discussed here?) - -sche (discuss) 18:06, 11 June 2014 (UTC)
It does, but that anchor is not added if the final parameter to full_link is provided. —CodeCat 18:22, 11 June 2014 (UTC)
Well, yeah, of course. But it's the module that links! I'm proposing that it not do so when the form is the same as the lemma.​—msh210 (talk) 23:05, 11 June 2014 (UTC)
Why does it make a difference? The software already handles links that point to the current page. —CodeCat 23:09, 11 June 2014 (UTC)
Because there's an extra <strong>, which looks awful (bonefish (plural bonefish)).​—msh210 (talk) 04:52, 12 June 2014 (UTC)
Aha, after some testing I can see what you mean. Those two instances of "bonefish" are identical on my computer (Windows 7) if I use Firefox v30 or Opera v12, but I can see the difference if I use Internet Explorer v11. - -sche (discuss) 06:16, 12 June 2014 (UTC)
They look very different on Firefox for me: file:Bonefish msh210.png.​—msh210 (talk) 06:39, 12 June 2014 (UTC)
For me, the second "bonefish" (when it is different from the first, i.e. when I use Internet Explorer) is bigger/bolder, but not underlined. How odd that things would display so differently not just from browser to browser but from user to user! - -sche (discuss) 14:32, 12 June 2014 (UTC)
There are more than two levels of font weight. I remember reading somewhere about Firefox having different font weight for <strong> and <b>Keφr 21:55, 12 June 2014 (UTC)
Would this be solved by specifying this in the CSS?
b strong { font-weight: inherit; }
—This unsigned comment was added by CodeCat (talkcontribs) at 22:51, 12 June 2014 (UTC).
If there's a class used for all headword lines, then .classname strong.selflink{font-weight:inherit} would probably work. And it'd not inadvertently affect other places b strong may appear.​—msh210 (talk) 04:59, 13 June 2014 (UTC) Stricken.​—msh210 (talk) 07:11, 15 June 2014 (UTC)
Fixing an HTML issue with a CSS hack seems like a bad idea. Why not just test to see if the plural is the same word as the current page and if so don't make it a link? Kaldari (talk) 08:50, 14 June 2014 (UTC)
I agree.​—msh210 (talk) 07:11, 15 June 2014 (UTC)
On the contrary. The issue isn't even in the HTML, as "strong" nested within "b" is perfectly fine as far as HTML is concerned. Rather, the problem is how that combination is displayed, which is what CSS is supposed to take care of. Trying to fix this issue by changing the HTML is a bit like breaking down a wall because you don't like its colour. The wall wasn't the problem, the paint was. —CodeCat 23:36, 17 June 2014 (UTC)
I'm not sure I follow that logic. Isn't <i> nested within <b> fine as far as HTML is concerned? Yet if you don't want any of the bold text on your site to be italic, the solution is not to use CSS to change how <b><i>foo</i><b> displays, it's to drop the <i> from the places where it occurs inside (or outside) <b>. - -sche (discuss) 01:13, 18 June 2014 (UTC)
Actually no, in your example that is what you'd do. That is why CSS exists; to separate presentation from the underlying content. In other words: the content should not contain information about how to display it. That's a very fundamental HTML principle which was not strongly enforced when HTML was new, but is now much more rigid. Hence, in the modern HTML5 interpretation, <b> doesn't actually mean "bold", despite that it is commonly used to bold text. It's perfectly valid to make text in that element not display bolded. See this link for an explanation on what these elements actually mean. —CodeCat 01:21, 18 June 2014 (UTC)
According to that page, we don't want inflected forms that are the same as their lemma forms to get <strong>: <strong> is for more emphasis/importance (than, in this case, the lemme form has), which we have no reason to prescribe for the inflected form. It just makes sense for the module to check whether the inflected form matches the lemma form and, if so, not generate a link.​—msh210 (talk) 07:29, 18 June 2014 (UTC)
Then that should be addressed to the MediaWiki developers. They are the ones that decided that "strong" would be appropriate to indicate a link to the current page. We shouldn't try to work around that, because we would never be able to catch all cases anyway. —CodeCat 16:47, 19 June 2014 (UTC)
Or we can fix Module:links (lines 214-216) so that it does not replicate this behaviour. Keφr 18:04, 19 June 2014 (UTC)
But we need to replicate it. Otherwise links to the current page won't show in bold. —CodeCat 18:24, 19 June 2014 (UTC)
The above discussion suggests the opposite. Keφr 18:30, 19 June 2014 (UTC)
The above discussion is only about headword templates. The code you referred to is used in many other places too. —CodeCat 19:03, 19 June 2014 (UTC)
Personally, I would get rid of the boldface in inflection tables too. I think it might be quicker to list places where boldface on self-links is desirable, actually. How about changing language_link so that the bolding would depend on the link face? (By which I mean whatever is currently passed as the face argument to full_link.) Keφr 19:08, 19 June 2014 (UTC)
That's probably the best solution. —CodeCat 21:14, 19 June 2014 (UTC)
If we choose to change it only in headword lines, then the fix would be a conditional in the definition of part in function format_parts in module:headword, I think.​—msh210 (talk) 07:10, 20 June 2014 (UTC)

A small improvement for languages with the same name[edit]

We currently have a variety of ways to disambiguate language names so that they're unique, but they may not always help people find the language they're looking for. So what if we created categories like Category:Buli language, and categorise all languages called Buli in there? @-sche: I think this would interest you. —CodeCat 22:45, 12 June 2014 (UTC)

I think that's a good idea. In addition to languages that are distinguished by parenthetical disambiguators, like Buli (Ghana) and Buli (Indonesia), this could be especially helpful for languages that are distinguished by prepended family info, like Austronesian Gimi vs Papuan Gimi. Someone who comes here knowing that a language is called Gimi might look in Category:All languages under 'G', or might start typing "Category:Gim..." into our search bar; right now the search suggestion function won't find anything to suggest, but if there were a Category:Gimi language, it would. (For languages that are distinguished by the use of alternate names, this method isn't possible; they will just have to keep cross-linking via {{also}}.) - -sche (discuss) 02:40, 13 June 2014 (UTC)

Using ISO 639-3 private use codes for custom language families[edit]

A little while ago I mentioned in passing (I don't remember where) that it might be good to change the way we devise codes for language families lacking one. I suggested using the ISO 639-3 private use area for this. Private use codes are in the range qaa-qtz, so there would be 520 codes for us to use, which I imagine is plenty if we use them for language families alone. The main reason I propose this is so that we can avoid really long 9-letter codes like "ine-bsl-pro" for Proto-Balto-Slavic, or "qfa-kor-jjm" for Jeju. If the family is at most 3 letters, then the whole code will never be more than 6, which is a bit more manageable.

I propose the following for our existing "exceptional" family codes:

Name Old New
Admiralty Islands poz-aay qai
Anatolian ine-ana qan
Andamanese qfa-adm qad
Arabic sem-arb qar
Aramaic sem-ara qam
Arandic aus-rnd qac
Araucanian qfa-ara qau
Arnhem aus-arn qah
Atayalic map-ata qal
Aymaran sai-aym qay
Bahnaric aav-ban qba
Balto-Slavic ine-bsl qbs
Bantoid nic-bod qbd
Benue-Congo nic-bco qbc
Borneo-Philippines poz-bop qbp
Brythonic cel-bry qbr
Bungku-Tolaki poz-btk qbt
Bunuban aus-bub qbn
Burmish tbq-brm qbm
Canaanite sem-can qca
Cariban sai-car qcb
Central Chadic cdc-cbm qcc
Central New South Wales aus-cww qcn
Central Semitic sem-cen qcs
Central-Eastern Oceanic poz-occ qco
Chapacuran qfa-cpc qch
Chinookan nai-ckn qci
Chukotko-Kamchatkan qfa-cka qck
Chumashan nai-chu qcm
Daly aus-dal qdl
Dardic iir-dar qda
Dogon qfa-dgn qdg
Dyirbalic aus-dyb qdy
East Barito poz-bre qeb
East Chadic cdc-est qec
East Semitic sem-eas qes
Edoid alv-edo qed
Eskimo esx-esk qek
Ethiopian Semitic sem-eth qet
Finisterre ngf-fin qfn
Finnic fiu-fin qfi
Finno-Permic fiu-fpr qfp
French Sign Languages sgn-fsl qfs
Frisian gmw-fri qfy
Fur ssa-fur qfu
Garawan aus-gar qgw
German Sign Languages sgn-gsl qgs
Goidelic cel-gae qga
Grassfields nic-grf qgf
Guahiban qfa-gua qgh
Guaicuruan sai-gua qgc
Gunwinyguan aus-gun qgy
Gur nic-gur qgu
Halmahera-Cenderawasih poz-hce qhc
Hurro-Urartian qfa-hur qhu
Inuit esx-inu qiu
Iwaidjan aus-wdj qia
Iwam paa-iwm qiw
Japanese Sign Languages sgn-jsl qjs
Jivaroan qfa-jiv qjv
sai-jee qje
Kadu qfa-kad qka
Kaili-Pamona poz-kal qkp
Kainantu-Goroka paa-kag qkg
Kainji nic-knj qkj
Karnic aus-kar qkr
Keresan qfa-ker qks
Kiowa-Tanoan qfa-kta qkt
Korean qfa-kor qko
Kukish tbq-kuk qkk
Kwa alv-kwa qkw
Kx'a qfa-kxa qkx
Lakes Plain paa-lkp qlp
Lampungic poz-lgx qla
Left May qfa-mal qlm
Lencan qfa-len qln
Macro-Chibchan qfa-mch qmh
Macro-Jê sai-mje qmj
Maiduan nai-mdu qmd
Malayic poz-mly qml
Malayo-Chamic poz-mcm qmc
Malayo-Sumbawan poz-msa qms
Masa cdc-mas qma
Mascoian qfa-mas qmo
Mataco-Guaicuru qfa-mgc qmg
Matacoan qfa-mtc qmt
Mbum alv-mbm qmu
Micronesian poz-mic qmn
Mien hmx-mie qmi
Misumalpan qfa-min qmm
Mixe-Zoquean nai-miz qmz
Mixtecan omq-mix qmx
Muna-Buton poz-mun qmb
Muran sai-mur qmr
Muskogean qfa-mus qmk
Nahuan azc-nah qnu
Nambikwaran sai-nmk qnk
New Caledonian poz-cln qnc
Ngayarda aus-nga qny
North Athabaskan ath-nor qna
North Bahnaric aav-nbn qnh
North Bornean poz-bnn qnb
North Sarawakan poz-swa qnw
North-Central Vanuatu poz-vnc qnv
Northeast Caucasian cau-nec qkc
Northwest Caucasian cau-nwc qpc
Northwest Semitic sem-nwe qns
Northwest Sumatran poz-nws qnm
Nyulnyulan aus-nyu qnn
Oceanic poz-oce qoc
Ok ngf-okk qok
Old South Arabian sem-osa qoa
Pacific Coast Athabaskan ath-pco qpk
Palaihnihan qfa-pal qph
Pama-Nyungan aus-pam qpn
Paman aus-pmn qpm
Pano-Tacanan qfa-pat qpt
Panoan qfa-pan qpa
Polynesian poz-pol qpl
Pomoan nai-pom qpo
Sabahan poz-san qsh
Sahaptian nai-shp qsp
Saluan-Banggai poz-slb qsb
Sama-Bajaw poz-sbj qsj
Savanna alv-sav qsv
Senegambian alv-sng qsg
Sepik paa-spk qse
Siouan-Catawban qfa-sca qsc
Sko paa-msk qsk
South Arabian sem-sar qsa
South Bird's Head ngf-sbh qbh
South Semitic sem-sou qsm
South Sulawesi poz-ssw qss
Southeast Solomonic poz-sls qsl
Southwest Pama-Nyungan aus-psw qsn
Southwestern Tai tai-swe qst
substrate qfa-sub qsu
Sunda-Sulawesi poz-sus qsi
Tacanan qfa-tac qta
Tai-Kadai qfa-tak qtk
Tocharian ine-toc qto
Tomini-Tolitoli poz-tot qtt
Torricelli qfa-tor qtc
Tucanoan qfa-tuc qtn
Tuu qfa-tuu qtu
Tyrsenian qfa-tyn qty
Ubangian nic-ubg qbg
Ugric fiu-ugr qgr
Vietic mkh-vie qfv
Volta-Congo nic-vco qcv
Volta-Niger alv-von qng
West Barito poz-brw qbw
West Chadic cdc-wst qcw
West Semitic sem-wes qsw
Western Oceanic poz-ocw qow
Wintuan qfa-wtq qin
Wotu-Wolio poz-wot qqw
Xincan qfa-xin qic
Yeniseian qfa-yen qey
Yidinyic aus-yid qiy
Yok-Utian qfa-you qou
Yolngu aus-yol qoy
Yuin-Kuric aus-yuk qky
Yukaghir qfa-yuk qqy
Yuman-Cochimí nai-yuc qcy
Zaparoan qfa-zap qrz
Zapotecan omq-zap qpz

(I don't know how to make the table collapsible so that it takes up less space. If you know, please edit my post.) —CodeCat 23:10, 15 June 2014 (UTC)

The previous discussion was at the end of this GP thread from April. As I did then, I oppose this now because I don't think it's workable. The ISO has been relatively stingy when it comes to granting codes to families and subfamilies, and our own Module:families/data is (even after I started working on it) sadly incomplete. In the GP thread I said that, as a ballpark guess, I'd expect us to end up with maybe four times as many exceptional (non-ISO) family and subfamily codes as we have now, by the time Module:families is 'complete'. In particular, our treatment of African, Asian and American languages is often coarse; we're lacking a lot of subfamilies. And I wasn't even thinking of sign language families at the time, but there are probably dozens of those that don't have ISO codes. The list above contains 167 families. If my estimate is correct, we'll end up needing ~660 codes, which means we'd run out of possible codes. Moreover, long before that happened, we'd run out of codes that were memorable approximations of their families' names. Just looking at the last few codes in the list, I see that due to the restriction on codes higher than "qtz", you've already had to resort to things like "qqy" for Yukaghir, "qrz" for "Zaparoan", "qpz" for "Zapotecan", "qky" for "Yuin-Kuric", etc. - -sche (discuss) 00:14, 16 June 2014 (UTC)
There is no disadvantage for us to have more than three characters in a language code. In fact, it makes it easier to come with more meaningful and memorable codes. --WikiTiki89 00:36, 16 June 2014 (UTC)
Using non-standard language codes invalidates the HTML of our pages. Private-use extension codes are okay, of course, because they are standardized.
And I agree that longer codes might be better. Instead of Yukaghir = qaa, why not use the BCP47 private-private use subtags, allowing, e.g., Yukaghir = x-yuk or x-yukaghir? Michael Z. 2014-06-16 20:14 z
I think we should do this only for the roots, not for the branches. Using a q code for something like Benue-Congo is just wasting a limited resource, IMO- especially since some of the entries in your table are bogus (several of the subdivisions of poz are figments of Blust's questionable methodology, for instance).
We should concentrate first on the codes starting with dummy families such as qfa and und- those are the main source of the unwieldy and non-mnemonic clutter you're talking about. Next we might think about regional ones like aus, nai and sai, but they do have a little bit of mnemonic value, even though they have no linguistic merit at all.
Any time we have a three-letter code, everything below it on the tree should start with that code, unless it has its own ISO code- in which case everything below it should have the iso code. There may be a few cases such as nic and alv where we may decide to make an exception, but that should be the general rule. Chuck Entz (talk) 02:09, 16 June 2014 (UTC)
Hmm, I had considered this idea myself, of giving q__ codes only to top-level families that currently have qfa-___ codes. It's probably workable, but it wouldn't change much. At present, there are 38 codes with "qfa-" prefixes, and only some of their proto-languages' codes would get shorter: "Pano-Tacanan" is currently "qfa-pat", its subfamily "Tacanan" is "qfa-tac" (NB not "qfa-pat-tac"), and their associated proto-languages would be "qfa-pat-pro" and "qfa-tac-pro" (not "qfa-pat-tac-pro") if they existed; if "Pano-Tacanan" were "qpt", its proto-language code would be "qpt-pro", but "Tacanan" would still be nine letters, as "qpt-tac-pro". - -sche (discuss) 20:22, 16 June 2014 (UTC)

Naming scheme for templatized usage notes[edit]

Sometimes, it's useful to put the same usage note on several entries. When that happens, the usage note is made into a template. However, we don't have a consistent naming scheme for such templates. Many start their names with language codes followed by 'note' or 'usage', like Template:he-usage-begedkefet and Template:de-note obsolete spelling. A few start with 'usage', like Template:usage less fewer and Template:usage ize. Template:U:Latin stop+liquid poetic stress alteration exists in a 'U:' pseudonamespace, apparently inspired by the 'R:' pseudonamespace that reference templates exist in. I actually quite like that last idea, especially if coupled with the use of language codes, as it groups all templatized usage notes together in Special:AllPages, just like the reference templates are grouped under 'R:'.
I suggest the following naming scheme for templatized usage notes: Template:U:[language code]:[brief identifier]. Template:de-note obsolete spelling would become Template:U:de:deprecated spelling (or similar); Template:usage ize would become Template:U:en:ize (or similar).
My second choice would be to fix the half-dozen outliers to use the [language code]-['note' or 'usage']-[identifier] format that it seems everything else uses.
Thoughts? - -sche (discuss) 05:45, 17 June 2014 (UTC) corrected a typo/thinko in my original post: switched from U:[langcode]- to U:[langcode]: (compare: the reference templates use a colon after the langcode, not a hyphen) - -sche (discuss) 19:12, 18 June 2014 (UTC)

Support. We also need a category for these templates. — Ungoliant (falai) 13:26, 17 June 2014 (UTC)
I like the U:langcode: prefix approach, though, as always, I don't think that the langcode is a needless waste of keystrokes for langcode=en. It should dramatically increase the likelihood that one could find the template by typing something in the search box. DCDuring TALK 17:20, 17 June 2014 (UTC)
Support. The Hungarian usage templates can be found here: Category:Hungarian usage templates. --Panda10 (talk) 12:19, 19 June 2014 (UTC)
Oh, and it seems we even have a Category:Usage templates, we just need to be sure to use it(s subcategories) on all the templates. - -sche (discuss) 15:47, 19 June 2014 (UTC)
Using Special:AllPages, I found every template that had "usage" or "note" in its name. I've moved about half of them; these remain to be moved. I haven't categorized many of the templates into Category:Usage templates yet, but it should be easy to find all the templates that need categorizing now that they all begin with "U:" (or are listed here). - -sche (discuss) 21:24, 3 July 2014 (UTC)
Some more candidates: {{rank}}, {{season name spelling}}, {{who vs. whom}}, {{ga-analytic}}, {{oikein väärin}}, {{HTML char}}, {{Hiragana informal}}, {{he-begedkefet}}, {{el-freq-Google}}, {{el-freq}}, {{katakana-in-science}}, {{preferred IUPAC name}}, {{trademark erosion}}, {{sh-coll-link}}, {{arabdialect}}, {{1990}}, {{el-T-Vs}}, {{el-T-Vp}}, {{ja-kun-vs-on}}, {{be-у-ў}} DTLHS (talk) 02:11, 4 July 2014 (UTC)
Thanks for finding those. "1990"? Youch; as terrible names for usage-note-templates go, that one is exceptional... - -sche (discuss) 03:12, 4 July 2014 (UTC)

chapter in quote-book[edit]

I recently asked in the Grease Pit for what seemed a minor change in a template that would make a major improvement to the display of quotations from books (see here). It was about shifting the presentation of the chapter number from before the book title to after it. It seemed to me to be an important change of minor coding difficulty to anyone familiar with the templates and their encoding (I am familiar with neither).
Nothing has been done about it, and nobody has even commented on it. Should I have raised the matter here ? Or in the Tea Room ? ReidAA (talk) 07:25, 19 June 2014 (UTC)


IMO « “Soup from a Sausage Peg”, in The Snow Queen and Other Tales » looks good.​—msh210 (talk) 07:20, 20 June 2014 (UTC)

That's fine if the chapter has a name, but not if it only has number, as in choc-a-bloc. And I don't understand why your example brings up the word in while mine doesn't. I've tried to find out about the internals of templates but to call the documentation mind-boggling is a gross understatement. What I would appreciate is a quote-novel template, much like the quote-book one, that puts a chapter number (which the quote-book seems able to detect) after the title of the novel and it would be useful to have also a time parameter that can be used to convey when the story is set. ReidAA (talk) 06:47, 24 June 2014 (UTC)
I like the format at [[choc-a-bloc]]. In any event, you can do what I do and what I suspect most editors do: not use the templates, instead formatting the quotations as in [[Wiktionary:Quotations#How to format quotations]].​—msh210 (talk) 19:04, 24 June 2014 (UTC)
Hey, that's a great link. I only wish I had found it for myself long ago. But I'm not sure that using templates mightn't allow easier coding. What I would like to be able to do is to code those RQ templates (i.e., make my own), preferably without embedded template usage. Can you tell me where there is an explanation of how to code them?—ReidAA (talk) 01:12, 25 June 2014 (UTC)
I don't think there is. Do you know the basics of coding wiki templates? In that case, perhaps find one that does similarly to what you want yours to do and copy and modify it. Otherwise, ask for help coding one in this section of this page or in the Grease pit.​—msh210 (talk) 05:34, 25 June 2014 (UTC)
I fancy I could handle the coding, provided I could look at example template coding. My attempts to get to see one have been fruitless, though I have no difficulty looking at their documentation code because it's easy to pretend to be editing it. So how do I get to look at an example RQ template source code?—ReidAA (talk) 09:40, 25 June 2014 (UTC) Fixed indenting.​—msh210 (talk) 00:37, 26 June 2014 (UTC)
Go to any such template and click "Edit" or "View source" atop the page or add ?action=edit to the URL; e.g., http://en.wiktionary.org/wiki/Template:RQ:Hardy_Laodicean?action=edit.

If you need to edit someone else's post on a discussion page, it's courteous to indicate you did so (as I've done to your last post, just above); I'd even say it's obligatory if (as was not the case here) the edit is substantive.​—msh210 (talk) 00:37, 26 June 2014 (UTC)

Hey, that link looks great! I think it's just what I needed. I presume I'll be able to copy that, edit it, and put it in the same location. Should I add a link to it to https://en.wiktionary.org/wiki/Category:Reference_templates or is that automatic? (I notice that your example doesn't seem to be there, and there doesn't seem to be a button to allow me to put a change in.)

As to my editing, all I meant to do was change the indentation so that more text would be visible at one time (see boldfaced forms of invariant lemmata in headword lines about 4 items above to see the kind of thing I was trying to avoid). If I did more it was accidental, for which my apologies. In fact, I think it would be preferable merely to alternate the message indentations, but in future I'll just go along with what seems to be the accepted practice.—ReidAA (talk) 11:09, 26 June 2014 (UTC)

It's not automatic.​—msh210 (talk) 07:38, 29 June 2014 (UTC)

Media Viewer is now live on this wiki[edit]

Media Viewer lets you see images in larger size


The Wikimedia Foundation's Multimedia team is happy to announce that Media Viewer was just released on this site today.

Media Viewer displays images in larger size when you click on their thumbnails, to provide a better viewing experience. Users can now view images faster and more clearly, without having to jump to separate pages — and its user interface is more intuitive, offering easy access to full-resolution images and information, with links to the file repository for editing. The tool has been tested extensively across all Wikimedia wikis over the past six months as a Beta Feature and has been released to the largest Wikipedias, all language Wikisources, and the English Wikivoyage already.

If you do not like this feature, you can easily turn it off by clicking on "Disable Media Viewer" at the bottom of the screen, pulling up the information panel (or in your your preferences) whether you have an account or not. Learn more in this Media Viewer Help page.

Please let us know if you have any questions or comments about Media Viewer. You are invited to share your feedback in this discussion on MediaWiki.org in any language, to help improve this feature. You are also welcome to take this quick survey in English, en français, o español.

We hope you enjoy Media Viewer. Many thanks to all the community members who helped make it possible. - Fabrice Florin (WMF) (talk) 21:54, 19 June 2014 (UTC)

--This message was sent using MassMessage. Was there an error? Report it!

To turn Media Viewer off (which you will probably want to, since it's incredibly annoying), go to Special:Preferences, select the Appearance tab, scroll down to Files, and unclick "Enable Media Viewer". If you don't have an account, I don't think you can turn it off, so you're just out of luck. Despite all appearances to the contrary, it's a feature, not a bug. —Aɴɢʀ (talk) 06:55, 20 June 2014 (UTC)
Oh, great. Another misfeature to turn off. But it is not that pictures are critical to us, anyway. Keφr 07:07, 20 June 2014 (UTC)

Category:Place names and topical subcategorisation in general[edit]

Category:en:Place names and its subcategories are presumably meant to contain place names in English. But among its various subcategories are categories like Category:en:United States of America. This is a place name itself, yes, but this category is intended and used for anything related to the US, not just places in the US. What bothers me here is that this category is nonetheless a subcategory of Category:en:Place names. I like to think that any subcategory is a strict subset of its parent category, so that any terms placed in a subcategory would be valid in the main category as well. How do other editors think of this principle. And if we should apply it, how would we do so here? There are other areas within the category tree where this applies too, like Category:en:Hydrology and Category:en:Snow being subcategories of Category:en:Liquids. —CodeCat 22:00, 19 June 2014 (UTC)

Place names is a lexical category. If it is to be subdivided further, it should probably not be by geography. We don’t have Category:en:Adjectives in the United States of America.
If Category:USA is supposed to categorize referents, i.e., the things represented by terms, then it doesn’t belong under Place names at all.
And in my opinion, it belongs in Wikipedia, not in Wiktionary. As long as we continue to categorize terms by qualities of their referents, there will continue to be such confusion among 1 lexical/grammatical categorization of terms, 2 technical/subject-field categorization of terms’ usage, 3. encyclopedic categorization of things. Why should we put so much energy into creating a far lamer copy of Wikipedia’s categorization? Instead, let’s keep adding Wiktionary links to Wikipedia articles. Michael Z. 2014-06-27 18:22 z
@Mzajac: Are you saying that something like Category:nl:Days of the week does not belong on Wiktionary? I don't think I agree with that, it's a very useful category. —CodeCat 20:19, 29 June 2014 (UTC)
I see that this is a leaf in the branch » Dutch language » All topics » Nature » Time » Days of the week. I guess this relates to meanings, the way a thesaurus classifies words? I don’t even know if these topics relate to or overlap with the technical vocabulary categories that are applied using usage (“context”) labels. I do see it as a problem that this is not called Category:nl:Names of days of the week or Category:nl:Terms for days of the week, because our entries represent terms, not their referents.
But if that is useful, aren’t the following also: Category:nl:Colours of the rainbow, Category:nl:Apostles of Christ, Category:nl:Blackletter fonts, or Category:nl:Dog breeds that are good with childrenMichael Z. 2014-06-29 23:56 z
Presumably yes, except that there's not as strong a need to look up those terms. I've been working on the topical tree for a few days now, reorganising and moving things around a bit to what seems more workable to me. What I noticed is that there are two basic types of category: categories of topic or relationship ("Chemistry", "Weather", "Food and drink"), and categories of types or sets ("Days of the week", "Organic compounds", "Countries of Africa"). The actual entries contained in them may not be so strictly separated, however. The former generally have names in the singular, while the latter mostly have plural names. What I've tried to do is to make sure that relationship categories are not subcategorised into type categories, to avoid the scenarios I described above. —CodeCat 00:05, 30 June 2014 (UTC)
I see we have Category:Colors of the rainbow, just no Dutch there.
Well, thanks for working on better organizing these. Michael Z. 2014-06-30 01:14 z
To go back to what you said, though. Our entries represent terms rather than their referents, and that's specifically why topical categories exist. To categorise by their referents instead. Of course you can put "terms related to" or "terms for" in front of every category name, but that doesn't really change anything in the end, the category structure will still be the same and so will the entries in them. So I wonder what you would suggest that wouldn't diminish the utility of these categories. —CodeCat 01:32, 30 June 2014 (UTC)
Of course naming the categories properly would change something. Some editors have only the vaguest idea of what dictionary entries are or how this is fundamentally different from Wikipedia, and imprecise or incorrect language built into the project just increases the confusion.
I’m not sure, but I think there is confusion because topical categories exist for several different reasons, which are not wholly compatible. Editors have been shuffling these around non-stop for years now, with no overall plan as to how they should look. I have a feeling this can’t be resolved without defining exactly what these are, and possibly creating two or three separate category trees for them.
  1. For example, since usage is documented by specialized subject labels like “chemistry,” logic tells me that there should be a category containing technical vocabulary used in the field of chemistry. We have a zillion labels categorizing usage, but no usage categories.
  2. Since editors are adding [[Category:en:Chemistry]] to entries, I suppose there should also be a more general subject-field category for “English terms related to chemistry,” after we define exactly what that means.
  3. If we are also categorizing by definition, distinct from usage or subject field, then I suppose we should settle on some scheme like that of Roget’s Thesaurus, where all words are grouped by concept (unlike most of today’s alphabetical thesauruses) – so Category:Chemical elements would be somewhere in section 635 “Materials.”
Maybe nos. 2 and 3 are the same thing, but they are certainly distinct from no. 1. But since all three are mixed up in a soup, our categories will continue to be shuffled around because they don’t seem right. Michael Z. 2014-07-02 00:34 z
I definitely agree with your first point. If terms are used within specific fields, or certain senses are, then that's lexically significant and not really any different from many of the categories currently in Category:English lexicons. What you mention in point 2 is a general problem with these categories in that "related" is not well-defined, and can be interpreted rather broadly. Some people might consider water to belong in Category:en:Chemistry just because it's the name of a chemical substance and hence related to chemistry. Others might disagree but think carbon dioxide belongs there. And if I understand your third point correctly, it refers to what I called "categories of types" above. They group things by common hypernyms; that is, by what their referents are. —CodeCat 00:46, 2 July 2014 (UTC)

Chinese most basic words are still undefined![edit]

Calling on Chinese-aware editors (natives and learners) to pull up their socks and make some effort to add missing Chinese contents. HSK Beginning level, first few hundred most frequent Chinese words (e.g. Appendix:Mandarin_Frequency_lists/1-1000 still miss definitions, lack formatting and have been neglected since their creation many years ago. I don't think there are obstacles for doing them now (translingual sections, difference in topolects), even basic senses for single-character words are still missing - This entry needs a definition. Please add one, then remove {{defn}}. And they are most frequent everyday words! I have just added "to do" - one of the most frequent Chinese verbs. Recently added "water", "year", "mountain", many other basic words. Even if definitioneless Mandarin entries get definitions, it's a step in the right direction, no need to work with a dialect you don't speak, if you're not confident.

@Tooironic:, @Kc kennylau:, @Bumm13:, @Meihouwang:, @Wyang: - not such a small group, huh? I may have missed some people. --Anatoli (обсудить/вклад) 02:02, 20 June 2014 (UTC)

The complexity of Mandarin/Chinese entries put off people but now they're not so complicated. Here's an example:




Wyang also suggested using:


for terms with complex semantics. --Anatoli (обсудить/вклад) 02:09, 20 June 2014 (UTC)

I've deliberately put off doing 字 entries because they seem such a big undertaking. Is anyone else up for this? I suppose we could get the basic ones done first. ---> Tooironic (talk) 02:10, 20 June 2014 (UTC)
I know that you put off doing them. Thanks. That's what I argue - first - they are not THAT complicated, second - the definitions don't need to be exhaustive, e.g. see is good enough, IMHO. :). One definition is better than nothing at all. Besides, you don't have to have to do stroke orders, canjie, anything that goes into translingual, just semantics is fine. --Anatoli (обсудить/вклад)
I've been following other people's leads and doing some occasional edits to them... Wyang (talk) 03:52, 20 June 2014 (UTC)
You've been most productive and leading in the Chinese editing. Aren't all the new modules, templates, bot work your doing? :) I only included you in the list to invite you to the topic. Thanks to the new structures you made it has become much easier to add non-Mandarin contents too. (I'm not taking credit for what I haven't done myself, in case it sounded like I do, LOL). --Anatoli (обсудить/вклад) 04:01, 20 June 2014 (UTC)
Forgot to ping @Jamesjiao:. You've been very quiet. :) --Anatoli (обсудить/вклад) 07:59, 20 June 2014 (UTC)
LOL... yes.. Let's just say I am no longer alone in my life now, so I have been spending a lot less time on the dictionary lately! Character entries just put me off for some reason; maybe it's because I like to be comprehensive and edit in all the possible definitions all in one go. I could change that attitude and just add in the basic stuff first... JamesjiaoTC 03:17, 24 June 2014 (UTC)
When will the "definitions" thingy be official? I can't wait to see that day! --kc_kennylau (talk) 09:04, 20 June 2014 (UTC)
Probably not in the foreseeable future. —CodeCat 12:12, 21 June 2014 (UTC)
Should we put compound only definition in this header? for , I separated it into noun and verb header. But this is wrong because this character will never be used as a noun or verb by itself. Should the part of speech correspond to the use of the character in a sentence or to the meaning? Meihouwang (talk) 08:40, 21 June 2014 (UTC)

Using rollback to revert good-faith edits[edit]

...needs to stop immediately. It violates numerous policies. The undoing of good faith edits should only be done while leaving edit summaries Purplebackpack89 (Notes Taken) (Locker) 00:00, 22 June 2014 (UTC)

Which policies? Also, if I recall, you left no edit summary on your own revert of Chuck's (good faith and correct) edit. —CodeCat 00:03, 22 June 2014 (UTC)
Look again, CodeCat. You'll see I DID leave an edit summary. And, at the time, the module was not working, so Chuck's edit removed a category, and was therefore wrong. If you don't understand the policies governing rollback, CodeCat, you shouldn't be using it. Purplebackpack89 (Notes Taken) (Locker) 00:06, 22 June 2014 (UTC)
"BRD" is just some letters. It's not an edit summary, nor does it explain your reasons for reverting. And again I ask, which policies? Furthermore, if the module was not working, that doesn't mean Chuck's edit was incorrect. It means that the module needed fixing, which he did as far as I can tell. Either way, that category didn't belong on that page whether the module was fixed or not. —CodeCat 00:07, 22 June 2014 (UTC)
BRD has a distinct meaning in the Wikimedia universe. It means bold, revert, discuss. Chuck made an edit. I reverted. Per BRD, instead of reverting, you should have discussed. But this particular edit is beside the point. The point is that edit summaries should be left except in case of vandalism. You going on and on about how right you are doesn't give you an excuse to not leave an edit summary when making a clearly controversial edit. Purplebackpack89 (Notes Taken) (Locker) 00:14, 22 June 2014 (UTC)
CodeCat, before you continue editing, please read this, it's the Meta blurb on rollback. We don't have a blurb on rollback, so in the absence of one, I defer to Meta and to Wikipedia. Purplebackpack89 (Notes Taken) (Locker) 00:16, 22 June 2014 (UTC)
BRD is a Wikipedia concept, not a Wiktionary concept. It's not used in Wiktionary and people here generally are not familiar with it unless they happen to edit Wikipedia too. Furthermore, even on Wikipedia, "BRD" is not a valid justification for any edit, as it is a common Wikipedia practice, not a policy nor a reason for making an edit. In any case, if you want to set up an official policy to make edit summaries required when not reverting vandalism, you're free to do so. But I don't think there's much chance of it succeeding. Regardless of what Meta says, on Wiktionary a revert simply means the same as an undo. It means "I think the page was better before". —CodeCat 00:20, 22 June 2014 (UTC)
The ideal solution is to get the same tool that Wikipedia has to easily revert both good and bad faith edits and optionally leave an edit summary. --WikiTiki89 00:09, 22 June 2014 (UTC)
And until Twinkle arrives on Wiktionary, rollback shouldn't be used for anything except vandalism Purplebackpack89 (Notes Taken) (Locker) 00:14, 22 June 2014 (UTC)
Why does Purplebackpack have rollbacker rights anyway? He is unfamiliar with Wiktionary’s practices and doesn’t seem interested in becoming familiar with them. — Ungoliant (falai) 00:38, 22 June 2014 (UTC)
User:Ungoliant MMDCCLXIV, That's painting with too broad a brush. However, there are a number of "policies" and not-having-policies that seem just plain arbitrary. Some policy even seem like they're different solely to stick a finger in Wikipedia's eye. Also, the general reason for taking rollback away is abuse. If I am found to have abused rollback and you use that as justification for taking mine away, you'd have to also take away CodeCat's and probably other people's as well. Purplebackpack89 (Notes Taken) (Locker) 00:57, 22 June 2014 (UTC)
Because? Keφr 15:20, 22 June 2014 (UTC)
Well if he keeps up this I-don’t-like-your-practices-so-I’ll-just-follow-Wikipedia’s attitude I will request the removal of his rights. — Ungoliant (falai) 17:14, 22 June 2014 (UTC)
And, as Kephir noted, you would have no basis for doing so. Not liking practices and abusing rollback are two completely different issues. Since how rollback should be used on this Wikipedia is ambiguous, I have not abused it, and therefore there's no reason to remove it. Purplebackpack89 (Notes Taken) (Locker) 00:05, 23 June 2014 (UTC)
Where did I note that? Keφr 00:09, 23 June 2014 (UTC)

Proposal: Require edit summaries for reverting non-vandalism edits[edit]

Keeps us in line with many other Wikimedia projects. Not having it makes editors who use rollback on good-faith edits come off as discourteous. Purplebackpack89 (Notes Taken) (Locker) 00:57, 22 June 2014 (UTC)

  1. Purplebackpack89 (Notes Taken) (Locker) 00:57, 22 June 2014 (UTC)
  1. “Reverted edits by Foo. If you think this rollback is in error, please leave a message on my talk page.” I see this as humble instead of discourteous, due to the admission that the the reversion may be in error. — Ungoliant (falai) 05:04, 22 June 2014 (UTC)
  2. What Ungoliant said. (And that default text is editable if the community so desires.)​—msh210 (talk) 05:50, 22 June 2014 (UTC)
  3. I don't see anything discourteous. The text as Ungoliant quoted it does not seem offensive in any way, especially compared to "Undid revision". —CodeCat 10:36, 22 June 2014 (UTC)
  4. --Yair rand (talk) 05:35, 23 June 2014 (UTC)
  5. For one thing, the 'line' between "vandalism sensu stricto" and "misguided, malformed edits which need to be undone" is quite blurry. Take this diff, for instance, which added a malformatted, vaguely worded, apparently redundant definition onto the headword line. - -sche (discuss) 13:36, 23 June 2014 (UTC)
    "malformatted, vaguely worded, apparently redundant definition". There's your edit summary right there lol. The 'line' is good-faith-but-you-don't-know-what-you're-doing vs. bad-faith-and-you-do-know-what-you're-doing. One is permissible, but not a great idea, and one isn't. You can be blocked for a few instances of one and not for a few instances of the other. Purplebackpack89 19:57, 27 June 2014 (UTC)
  • What matters isn't rather you the experienced editor doesn't think it discourteous, it's rather whether the (probably less-experienced) editor thinks it is. It's clear none of you have read this, which explains why other editors would find it discourteous. Please read it before commenting further. Purplebackpack89 (Notes Taken) (Locker) 14:50, 22 June 2014 (UTC)

Proposal: Get Twinkle[edit]

We haven't had a serious discussion about getting Twinkle in years. If people are concerned about not being able to make edits fast enough, getting Twinkle could solve those problems. Purplebackpack89 (Notes Taken) (Locker) 00:57, 22 June 2014 (UTC)

Does importScript('User:AzaToth/twinkle.js','en.wikipedia.org','431551787'); not work here? (I haven't tried it.)​—msh210 (talk) 05:56, 22 June 2014 (UTC)
It still does, but I marked it as deprecated in favour of mw.loader.load('//en.wikipedia.org/w/index.php?action=raw&oldid=431551787') (or a longer version, you get the idea). I probably should have been more explicit about it. The reason being that importScript from our MediaWiki:Common.js clashes with MediaWiki's built-in importScript, and I think we have no good way to guarantee that either version will run at a given moment. (Also, I have been trying to clean up our scripts mess lately. I think introducing inconsistencies between MediaWiki installations in this way is a bad idea, and this is just waiting for a good moment to bite someone in a vaguely specified body part.) However, the built-in importScript only accepts one argument, and can only load scripts from the local wiki. Keφr 07:19, 22 June 2014 (UTC)
Well, in any event, some sort of importation is possible. So those who want Twinkle can use it already, can't they? This discussion is only about whether to host it locally also (and customize it to our local desires)?​—msh210 (talk) 07:34, 22 June 2014 (UTC)
No, I don't think they can Purplebackpack89 (Notes Taken) (Locker) 14:57, 22 June 2014 (UTC)
Why? Keφr 15:14, 22 June 2014 (UTC)
  1. Purplebackpack89 (Notes Taken) (Locker) 00:57, 22 June 2014 (UTC)
  2. Twinkle provides the ability to do things that are very difficult to do otherwise, such as revert an arbitrary string of edits by multiple editors and leave an optional edit summary behind. Frankly, I don't see any downsides. If we are worried about too many people having access to it, then I'm sure there is a way to restrict its use to users who have rollback privileges. --WikiTiki89 20:15, 22 June 2014 (UTC)
    Like applying maintenance tags to articles, doing all three required steps of starting an AFD/MFD/RFD, initiating a request for page protection, applying protection templates… oh wait, we have none of that nonsense. Keφr 21:03, 22 June 2014 (UTC)
    So we won't use those features. Maybe they can be disabled? --WikiTiki89 21:36, 22 June 2014 (UTC)
    Or we could just use them for RfD/RfV instead. Purplebackpack89 (Notes Taken) (Locker) 00:02, 23 June 2014 (UTC)
    Might as well. On the other hand, starting RfVs and RfDs here is much less of an exercise in bureaucracy than XfD on Wikipedia (add the template, click the "+" link, write the nomination rationale, submit, done; versus editing three or four different pages while manually pasting different template magic in different places on each), and I cannot remember the last time anyone complained about the tedium of our nomination process, so… meh. The amount of work that would need to go into that would be simply not worth it. Or again, do you want to volunteer? Keφr 00:31, 23 June 2014 (UTC)
  1. Equinox 01:00, 22 June 2014 (UTC)
  1. I oppose until sufficient reason to install the gadget here is supplied. I haven't seen such yet.​—msh210 (talk) 05:56, 22 June 2014 (UTC)
  2. Abstaining until someone explains what Twinkle is. —CodeCat 10:37, 22 June 2014 (UTC)
    See w:WP:WikiSpeak#Twinkle. And w:WP:Twinkle for amusement. Most of its functionality makes sense only for Wikipedia, though. Keφr 10:44, 22 June 2014 (UTC)

User:Equinox, care to give rationale rather than just voting? Wouldn't Twinkle mean faster editing and fewer situations where CodeCat et. al misuse rollback? Purplebackpack89 (Notes Taken) (Locker) 01:04, 22 June 2014 (UTC)

Twinkle does not solve the problem because you can still have good edits reverted by Twinkle with no explanation if none is filled in: see [10]. This has happened to me. So it is essentially no different from our pre-existing features (e.g. the "red D" in Recent Changes — not sure whether you've seen this, as it is only available to admins). Equinox 13:01, 22 June 2014 (UTC)
I usually keep this disabled, because I find it too annoying, but I re-enabled "Patrolling enhancements" just so I could see what you are talking about… but no red "D" appeared. Only a blue "M". Keφr 15:14, 22 June 2014 (UTC)
Twinkle isn't like patrolling, and why should either be limited to administrators? Why can't joe schmos like me have tools? Purplebackpack89 (Notes Taken) (Locker) 15:26, 22 June 2014 (UTC)
Because "joe schmos" like you lack the good judgement to use them well. Keφr 15:43, 22 June 2014 (UTC)
That is a very elitist stance, Kephir. It's also untrue: nobody has ever come up to me on this project and said: "You make too many edits in too short a time". Purplebackpack89 (Notes Taken) (Locker) 15:53, 22 June 2014 (UTC)
Correct, it is the contents of your edits that raise our objections. (Also, they almost did tell it to me. Not that I am complaining, just noting.) Keφr 16:04, 22 June 2014 (UTC)
There you go again redefining what people say so it's easier for you to answer it. Of course no one here has said that, but they have pointed out numerous errors in judgement on your part, which you would be able to propagate much more quickly with more tools. Chuck Entz (talk) 16:11, 22 June 2014 (UTC)
  • User:Msh210, it enables us to do more stuff in regards to reverting vandalism or tagging articles, and enables us to do things quicker. What more rationale do you need? And, User:CodeCat, you'd never heard of Twinkle before? Really? Purplebackpack89 (Notes Taken) (Locker) 14:56, 22 June 2014 (UTC)
    • We do not have articles here. We have entries. Twinkle's tagging module would need significant rework before it could be rendered usable for Wiktionary. Which very few here have time for. Or do you want to volunteer? Keφr 15:14, 22 June 2014 (UTC)
    • So it allows anyone to be a rollbacker, even without the rollback right? Sounds like a poor idea to me. There's a reason it's a right granted (easily but) not to everyone.​—msh210 (talk) 04:32, 23 June 2014 (UTC)
  • @Kephir: The red 'D' appears next to the blue 'M' if and only if an unpatrolled edit has created a page; that probably doesn't happen often on your watchlist, and may not even happen in recent changes at any given time you look. The 'D' allows you to delete the page with no edit summary (unless you provide one in a little box which also appears iff an unpatrolled edit has created a page). - -sche (discuss) 19:51, 22 June 2014 (UTC)
    • Hmm. I opened Special:RecentChanges, plenty of unpatrolled new pages there, but no "D". It can see it on Special:NewPages, however. By skimming the source code, I guess it does not work with the "Group changes by page in recent changes and watchlist" option enabled. Still, I am going to keep the gadget disabled. The buttons look too distracting and just feel too easy to misclick. Keφr 20:05, 22 June 2014 (UTC)

Proposal: Codify the BRD practice[edit]

General jist: If you make an edit, another editor can undo it, and after that point, discussion must take place, or else both editors are in error Purplebackpack89 (Notes Taken) (Locker) 00:59, 22 June 2014 (UTC)

To clarify, BRD only applies to good-faith edits. Vandalism can still be reverted without discussion, and an unlimited number of times Purplebackpack89 (Notes Taken) (Locker) 00:00, 23 June 2014 (UTC)
  1. Purplebackpack89 (Notes Taken) (Locker) 00:57, 22 June 2014 (UTC)
  1. Chuck Entz (talk) 22:49, 22 June 2014 (UTC)
  2. --Yair rand (talk) 05:35, 23 June 2014 (UTC)

Nice in theory, but the additional required steps will make patrolling hundreds of edits at a time every day all the more time-consuming. This looks suspiciously like yet another technique PurpleBackpack89 can use to change the subject and shift the blame in order to continue to avoid admitting to ever being wrong or making a mistake.Chuck Entz (talk) 22:49, 22 June 2014 (UTC)

User:Chuck Entz, that is an assumption of bad faith and a DICK-ish comment. BRD doesn't apply to vandalism, it only applies to good-faith edits, so it wouldn't slow down patrolling. Purplebackpack89 (Notes Taken) (Locker) 00:00, 23 June 2014 (UTC)
P89, you are being much more "DICK-ish" than anybody else by constantly resorting to tedious legalistic interpretation of policies — often ones from Wikipedia that don't even apply here. Read the DICK page yourself, especially the top part, and consider how much you are annoying everybody, as is evident from recent discussions, and just shut up for a minute and think about it. Your modus operandi seems to be to attack everybody for not sharing your personal opinion, based on legalistic policies (which half the time don't even exist here), but if anyone ever attacks you for not sharing their opinion, the rules go out of the window and you are suddenly the injured party who needs soothing and pacifying. It's pretty pathetic and disgusting and hypocritical as hell. Equinox 00:04, 23 June 2014 (UTC)
Equinox, you don't get to tell me to shut up. I don't give a damn if you don't like my opinions on things, I am entitled to them as much as you are to yours. I don't attack people for not sharing my opinion, I don't attack people at all. I merely point out that it is wrong to make the broad generalizations people do about me. Take a look at how often I say "User X is always...". You'll find it's never. I only comment on other people's INDIVIDUAL edits. Other people comment on ME. Purplebackpack89 (Notes Taken) (Locker) 00:09, 23 June 2014 (UTC)
Are you saying that we should be prohibited from noticing detrimental patterns in your behaviour? Keφr 00:51, 23 June 2014 (UTC)
Not exactly. I'm saying the way Equinox and Chuck characterized the edits I made was inaccurate. If you think every edit I make is bad (which is damn near what people have been saying), that's inaccurate. If you think every comment I make toward another user is an attack, that's inaccurate. Frankly, everything said about me in this thread is hyperolization at best and completely inaccurate at work (this is in no way reflection on edits outside this thread). Purplebackpack89 (Notes Taken) (Locker) 01:04, 23 June 2014 (UTC)
I think you will find that the community here has a relatively thicker skin than yourself. Not that we tolerate gratuitous offence, but most regulars here will probably not care that much about most instances of what you are oh-so-ready to term "personal attacks". We have not been accusing you of "attacking" anyone. "Attacks" are irrelevant. We are accusing you of gross incompetence with regard to our practices and policies (not understanding that Wikipedia's policies may be not applicable here), elementary courtesy (shifting the blame and burden of proof, claiming you cannot be stripped of rights merely because you have not technically violated any written policy, or some imaginary policy — see previous) and reading comprehension (regularly misconstruing other editors' statements and questions, e.g. just above), and not just inability, but an outright refusal to change this state of affairs. Is every single edit of yours wrong? I guess no. But enough of them that the community has decided to watch you closely, and is seriously considering stripping you of your editing privileges. Keφr 01:42, 23 June 2014 (UTC)
(edit conflict) Would you care to cite one example in which you have ever assumed good faith from your opponents in discussions? To my memory I have never seen you admit you were wrong, and I have never seen you assume good faith. I have, however, seen dozens of marginally off-topic rants about why everyone is out to thwart you. Chuck Entz (talk) 00:14, 23 June 2014 (UTC)
Chuck, you need to divorce assuming someone is wrong from assuming someone acted in bad faith. When I ask, "Why did you do X" (as I did with CodeCat yesterday), I assume that that person has a perfectly good reason (and therefore acted in good faith) for doing so. I don't assume that anyone who disagrees with me is a vandal or is doing what he/she did for nefarious reasons; I have no idea where you got the idea I did. You'll also notice that when I comment on a person's particular edits, I ONLY comment on those edits; I make no generalizations. Purplebackpack89 (Notes Taken) (Locker) 00:28, 23 June 2014 (UTC)
As usual, you're not answering the question you were asked. I asked you to cite an example of assuming good faith for opponents in discussions. I didn't ask if you could point to examples where you didn't assume bad faith about someone's edits outside of discussions. As for generalizations: you do it all the time in discussions here. You may not point to individuals most of the time, but you do talk about how people around here are finding fault because they don't like how you dare to disagree with them. And you do spend lots of time implying all kinds of things, without explicitly saying them.
As for you actions yesterday: you saw my edit, and reverted it without asking why I made it. You were reverted. You reverted the revert without asking why you were reverted. You were reverted again, etc. It was only after it was clear you weren't going to prevail that you bothered to ask, and then it was more like demanding to know why than asking. If you had assumed good faith and asked, the whole episode would have been avoided. I'm not saying I've never done anything to make you think I might be acting in bad faith- but you clearly weren't assuming good faith. Chuck Entz (talk) 01:27, 23 June 2014 (UTC)
You are wrong: Had you bothered to look at the timing of reverts, you'll see that several CodeCat reverts occurred after I asked why she was doing what she was doing. She continued reverting before answering my question, so it's on her, not me. Also, "not assuming bad faith" and "assuming good faith" are the same thing. To claim they aren't is pedantic. Purplebackpack89 (Notes Taken) (Locker) 01:37, 23 June 2014 (UTC)
You didn't really ask, you came right at me with a rather aggressive tone. "What's the big idea" is not asking, nor is it a civil way to start a reasonable discussion. Furthermore you did not even wait for me to answer before reverting me anyway. I'm sorry but I agree with Chuck, that is more of a demand ("stop interfering, you do you think you are?") than an honest attempt to work out a problem to me. —CodeCat 01:41, 23 June 2014 (UTC)
For the record, I blocked P89 (per WP:DICK, lol). No, mainly because he doesn't really do anything useful, and just sows discord. If anyone who's also dealt with this person for several years thinks this was bad judgement, feel free to undo it. Equinox 03:05, 23 June 2014 (UTC)
It's been undone, and the manner in which you did it was highly inappropriate and frankly a personal attack (for crying out loud, you made an lol about a block you made). It's also inaccurate. Have you actually LOOKED at my contributions in mainspace recently? Have you LOOKED at my "pages created" list? Furthermore, it's probably not the greatest of ideas to block someone just because of how their contributions pie falls. Purplebackpack89 (Notes Taken) (Locker) 03:51, 23 June 2014 (UTC)
Cry us a river. Out loud. So what? Nobody is going to treat you nicely merely because you keep crying about "personal attacks"; in fact, this only worsens your position. But since you failed to learn this until now, I doubt you ever will. Your days here are numbered. Keφr 08:27, 23 June 2014 (UTC)
  • This really shouldn't be in the same thread as a BRD proposal. The discussion over the last four hours has been nothing at all about whether or not BRD is a good idea or not, it's using me as a pinata. I tried to split this into another thread, but Ungoliant undid it. Purplebackpack89 (Notes Taken) (Locker) 04:09, 23 June 2014 (UTC)
    For reference, here’s the title of the new thread PBP had added: “Various comments about the behavior of User:Purplebackpack89 that don't really have much to do with whether or not BRD is a good idea”. — Ungoliant (falai) 12:43, 23 June 2014 (UTC)
  • @Purplebackpack89: You can use Wikipedia's "Twinkle" tool by adding importScriptURI("//bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.gadget.Twinkle"); to your personal Special:MyPage/common.js, if you'd like. Please don't assume that users here have heard of Wikipedia's tools or policies, and definitely don't act as though their policies have any sort of relevance here; it's pretty ridiculous, moderately offensive, and generally unacceptable. --Yair rand (talk) 05:35, 23 June 2014 (UTC)

The {{l|en|word}} stuff[edit]

Please see User_talk:Ready_Steady_Yeti#The_.7B.7Bl.7Cen.7Cword.7D.7D_stuff. Ungoliant seems to think that I'm a moron. Do other regular editors not agree with me that it's bad enough to have to struggle through a lot of redundant "lang=en" every time we edit an English entry, and it would be worse to have the "l/en" stuff in every single linked word in a definition? Perhaps I sound paranoid or silly, but I do a lot of editing here (second most active editor) and I am genuinely concerned because this kind of stuff could double the amount of time it takes me to create an entry — and make it much more painful and less pleasant. Equinox 01:17, 23 June 2014 (UTC)

I think there's two issues: should editors be discouraged from using the {{l}} template, and should editors be discouraged from not using the {{l}} template. I would say no to both. It's true that RSY has, in typical fashion, taken the practice to extremes, but I don't think there's anything inherently wrong with it. All the same, wikilinking is fine for most purposes when linking to English terms, and for many editors the extra work of using templates isn't worth it- and that should be respected. There are parts of the entry where categorization, formatting and script handling tilt the balance in favor of templates, but that doesn't include definitions. Chuck Entz (talk) 01:50, 23 June 2014 (UTC)
You will not find an ally in me, sorry. I think |lang=en is not redundant to begin with, and that we generally should not treat English much differently from other languages — apart from the fact that the definitions, entry layout and all the documentation of the infrastructure around them are written in English. And I like definitions to have anchors pointing to the right language, although I prefer to accomplish that by just wrapping the whole definition inside {{l|en|...}} — then at least the inside of the template looks more like plain markup.
Related discussion: Wiktionary:Beer parlour/2013/September#A new way of formatting definitions I saw someone use Keφr 01:52, 23 June 2014 (UTC)
Personally, I prefer simple links in definitions, but I tolerate {{l}} links as well. I don't think they are detrimental as long as we are not forced to use them. --WikiTiki89 01:57, 23 June 2014 (UTC)
I don’t think you’re a moron. Also, while I strongly support the use of {{l}} and think it should be encouraged, I don’t think it should be forced on editors. — Ungoliant (falai) 02:22, 23 June 2014 (UTC)
To put it another way, which might be clearer or more convincing to computer people: when you write an HTML document, you can apply an entire property to a section, e.g. <p style="color:red">. This means you can then do anything inside the paragraph, and not care about the colour, because it's already been set. I feel we should be able to do this, language-wise. So all generic links in an English section would link to English, and all generic links in a Spanish section would link to Spanish, etc. I can see the point of specifying the language in a link where it isn't otherwise obvious, but having a default seems very useful and time-saving. I'm honestly amazed nobody agrees. Of course I will bow to consensus but wow! Equinox 03:03, 23 June 2014 (UTC)
Links inside foreign-language definition lines link to English most of the time though. — Ungoliant (falai) 03:27, 23 June 2014 (UTC)
I have always assumed that those whose main contributions are not in English entries simply don't care about any possible time-saving from dispensing with lang=en as it doesn't much effect them. There may also be some kind of fairness/equality ideology at play: "Why should English get special treatment?" "I have to do these extra keystrokes so why not those arrogant English-native yokels?" And then there is the technological uniformity-is-easier-to-code-for factor. DCDuring TALK 03:38, 23 June 2014 (UTC)
Well, exactly. Which is pretty much what I wrote above. Keφr 08:28, 23 June 2014 (UTC)
In my opinion, foreign words should be marked up with the HTML lang attribute (to indicate to screenreaders and search engines and so on what languages the words are), and the easiest/briefest way to do so is by use of {{l}} (or {{head}}), which has the added benefit of linking to the correct section. (Actually, it'd be nice if any 'nyms or 'nyms-like section in a FL L2 would have a <div lang=…>. But we don't have that (yet).) However, English words don't need that attribute: the default language for the page is English. Moreover, we don't need a template to ensure linking to the correct section when it's English, as English is the top section on each page where it exists (pretty much). So {{l/en}} is pretty useless: I generally replace it with plain square brackets when I see it.​—msh210 (talk) 04:41, 23 June 2014 (UTC)
Translingual sections and tables of contents prevent plain links from linking directly to the English section, as well as a same-language section in the page being linked to when Tabbed Languages is being used. — Ungoliant (falai) 05:10, 23 June 2014 (UTC)
Ah, right, I knew there was some issue I was forgetting. Yes, I agree: if and when we decide to enable Tabbed Languages by default, then we should switch English links to {{l}} in FL sections.​—msh210 (talk) 05:52, 23 June 2014 (UTC)
I already fix links to use {{l}} even for English. Mainly because I use Tabbed Languages. It seems a bit strange that we don't take TL users into account when we do support it as an option on our wiki. Why would we need to wait until it becomes the default? Even non-default options should still at least work correctly, shouldn't they? —CodeCat 12:04, 23 June 2014 (UTC)
TL would be a reason to use {{l}} for English only in FL sections, not in English sections. (I switch it to square brackets where I see it only in English sections, actually.)​—msh210 (talk) 16:42, 23 June 2014 (UTC)
So then we've been undoing each other's work. I'm not sure if I like that... —CodeCat 16:55, 23 June 2014 (UTC)
I agree with Equinox. I oppose using "{{l|en|" or "{{l/en|" in English definition lines of English entries. Wiki markup is the user interface; it has to be pleasant to use, which includes not only initial creation but also reading and revising. --Dan Polansky (talk) 20:53, 23 June 2014 (UTC)


Jamaican Creole font[edit]

I assume that there's a rational reason for writing Jamaican Creole and some other languages with larger font than others (sc=Deva), but what is it? Jamaicans do not have worse eyes than the average citizen of the world, do they? --Hekaheka (talk) 09:18, 28 June 2014 (UTC)

Jamaican Creole shows up in the same font (and same size) as English for me, and in Module:languages/data3/j its script is set to "Latn", just like English's. - -sche (discuss) 02:26, 29 June 2014 (UTC)

No Fun Allowed[edit]

Hi. Please make this an official policy A.S.A.P. --Æ&Œ (talk) 10:04, 28 June 2014 (UTC)

A reminder to myself and others: DFTT. --Dan Polansky (talk) 10:30, 28 June 2014 (UTC)
SUOA. TATSOOM. But seriously, just because a topic is “trolling” doesn’t mean that you can’t have fun with it. Congratulations on ignoring the humour and supporting my exaggerated perception that having fun on Wiktionary is wrong. --Æ&Œ (talk) 13:34, 28 June 2014 (UTC)
Silly boy- creating valuable content for an online reference that educates and enlightens the public is all the fun anyone could ever want. Why, just yesterday, correcting an etymology to reference the correct Proto-Indo-European root so filled me with joy that I just had to laugh out loud! I have lots of fun (I understand my neighbors in the apartment building are concerned, though). Chuck Entz (talk) 14:28, 28 June 2014 (UTC)
  • If people get their "fun" making generalizations, low-level digs, and sarcastic remarks, then "fun" should be disallowed Purplebackpack89 14:49, 28 June 2014 (UTC)
  • Mandatory fun? DCDuring TALK 15:39, 28 June 2014 (UTC)
    Admittedly it is difficult to make fun mandatory, but we could make attendance at a Wiknic next weekend mandatory. A selfie/usie with other attendees and signage would be required to prove attendance. DCDuring TALK 16:13, 28 June 2014 (UTC)
Clearly the real issue is that we have too many toasters. -- Liliana 21:20, 28 June 2014 (UTC)

Über-template with tabular output for pronunciation section (2)[edit]

Older discussion: Wiktionary:Beer parlour/2014/March#Über-template with tabular output for pronunciation section

The hard parts have been mostly done, here's a prototype:


variety IPA Rhymes Optional column Audio Homophones Hyphenation
Netherlands /ˈrɛizə(n)/ -ə(n) VALUE
rijzen rei‧zen
Belgium /ˈrɛːzn/ [ˈrɛːzn̩] rei‧zen
/ˈrɛːzə/ rijzn
Sandwich Islands /gumbalagumba/

Click on "less ▲" or "more ▼" to switch between the views. (This approach has been stolen adopted from User:Atelaes' Template:grc-pron) There was always feedback from readers that they can not find definitions, pronunciation sections are especially big, so I had proposed to have a show/hide button, but why not showing some of the info instead of hiding everything completely?

Regarding the full view:

  • There's a set of predefined columns with predefined displaying text and order. These columns, including the first column (variety/accents), can be omitted, though. In templates/entries, users can define additional columns in their desired order. The hyphenation column will probably be removed from this template. We may predefine enPR column as well. We may want to create separate templates for different languages, similar to headword templates. Any comments would be appreciated.

Regarding the brief view:

  • What information should we put in this mode? I only put accent name, IPA, and audio, and kept them as brief as possible. Should we also include enPR?
  • Should it be a list or a table? How should we arrange and display the information?
  • Some accents are less important. For English, for example, there is usually little demand for pronunciation in accents other than American and British. Should we include all accents in this mode?
  • I made the audio box smaller, but the buttons (play, volume) sometimes disappear or being misplaced, maybe a CSS-related issue or something?

--Z 17:54, 28 June 2014 (UTC)

If enPR is included, it should be hidden along with the other extended content until someone clicks 'more', IMO; likewise for SAMPA.
Personally, I prefer bulleted lists to tables (for both the expanded and the condensed views).
- -sche (discuss) 16:50, 29 June 2014 (UTC)
I'm glad to see it stolen. I did my best to make it broadly pilferable. -Atelaes λάλει ἐμοί 20:20, 29 June 2014 (UTC)
  • Is the lack of colons after the dialect name deliberate?
  • Perhaps throw in some use of rowspan when certain content will be identical across accents?
  • Something to consider: We might want to build "About" pages for various accents. Could be some helpful content, and possibly useful for delineating where accents start and end.
  • Something we might not want to consider if it's likely to get too complicated and/or annoying: Flags.
  • This looks like it'll likely kill visibility of the very interesting Rhymes content on Wiktionary. Not in favor.
  • Perhaps Module:IPAc could be integrated, at least for English? Many readers don't know IPA.
  • How should accents that have identical content for a particular word be handled?

--Yair rand (talk) 05:04, 30 June 2014 (UTC)

Module Errors on Empty Input[edit]

Is there a good reason to have templates like {{l}} go to a module error is there's no content? I can understand a module error for a missing language code when there's content to be displayed, even if I find it annoying, but it seems to me that {{l|}} or even {{l|en|}} is a minor omission that shouldn't be dealt with by throwing scary-looking module errors.

It would seem to make more sense for the module to test for empty input and simply return nothing for nothing (I suppose a hidden tracking category would be ok). That would also mean it could be used in inflection-table templates without extra code to test for a null parameter.

In general, I think we should move away from using module errors as the way to deal with simple data-entry errors wherever possible- it gives the illusion of their being technical errors that only experts can fix. Chuck Entz (talk) 16:04, 29 June 2014 (UTC)

I disagree that "{{l|}} is a minor omission" — it's the most major omission that it's possible to make from that template, the total omission of all content. But I do note that {{IPA|}} merely categorizes into Category:Pronunciation templates without a pronunciation and Category:Language code missing/IPA, without throwing a module error. Perhaps we should even add a superscript "please add a (link|pronunciation) or remove the template" message, similar to the message Dutch headword-line templates use when diminutives aren't provided. - -sche (discuss) 16:44, 29 June 2014 (UTC)
I also disagree, but I furthermore disagree that not displaying errors is an improvement. There are parts of the site which display big red errors even for relatively minor mistakes, like adding references to a page but nowhere to display them. Showing the errors makes them clearly visible and gives editors more of an incentive to fix them. "Out of sight, out of mind" definitely applies here. Errors that only add categories generally don't get fixed; just look at how big some cleanup/request/attention categories are. —CodeCat 17:23, 29 June 2014 (UTC)
How hard would it be to make the error message depend on the status of the person logged in and on 'type' of error?
I would argue that unregistered users, at one extreme, and admins, at the other benefit from different approaches. Non-contributing unregistered users probably benefit from suppression of error messages. Our ability to recruit contributors may be enhanced by only gradually revealing how finicky we have made the process of contributing. In any event it seems highly likely that we are making the passive (ie, normal) user's experience worse by exposing such users to raw Module error messages without in any way leading to a better Wiktionary by eliciting valuable corrections from such users. ::Further, I am reasonably sure that not all errors merit the same approach, even. Some thought should lead to an architecture allows discrimination along both the user dimension and the error-class dimension.
I am sorry if (probably that) discriminating by user and specific error situation makes the task of designing modules and templates more complicated, but we already have a situation in which very few contributors can do any editing of modules and therefore cannot readily alter the behavior of templates without begging. I would hope that our talent could conceive of some simplifying architecture to enable this kind of discrimination in the main cases. DCDuring TALK 18:46, 29 June 2014 (UTC)
It's very easy to hide module errors to anonymous using CSS; I did it before. But at the time I think people didn't like it because it made text look strange with odd gaps were the errors should be. I don't think CSS can be used to actually change the text "Module error" itself, but it can change how it appears. —CodeCat 20:11, 29 June 2014 (UTC)
I take it that it is not possible to close up the gaps by setting character width to be 0 or very small or selecting a font or pseudofont that has the property of being of zero width.
Another thing that may be useful is {{REVISIONUSER}}, which allows one to test whether a(n) (anonymous) user made an edit. That would allow us to provide a message (on previewing or saving the edit) to an anonymous user who otherwise would not get a message. DCDuring TALK 22:15, 29 June 2014 (UTC)

July 2014[edit]

Category for all lemmas again[edit]

Previous discussion: Wiktionary:Beer parlour/2014/January#A category for all words or lemmas in a language

The previous discussion seemed to have general support, so I would like to make this change, but there are a few details I'd like to ask about first. We can either have just a category for all lemmas, but nothing else changes, or we could split off all "form" categories into their separate tree and have another category for non-lemmas (which may not be all that useful in the end?). A third option would be to have a category for lemmas alongside a category for all terms in a language regardless of lemma status. However, this last option could also be achieved by mentally merging the lemma and non-lemma categories, so this does not have much added value over the second option. —CodeCat 11:34, 1 July 2014 (UTC)

I prefer the idea of having a per-language category with all words (not just lemmata/headwords), rather like the way the Official Scrabble Words is presented. When I've used Index:English in the past — of course, it's years out of date now — I've wished it had all words and word forms. Equinox 13:25, 6 July 2014 (UTC)
I think we should have both: one category for all words, and another category for all lemmata. Fr.Wikt and De.Wikt already have categories for all words in each language. Both categories would have many uses. A category of all words would be useful for scrabble players, and for finding entries in the event that we needed to (a) make some change to all words in a certain language, or (b) examine all words in a certain language to see which of them met a certain criterion (e.g. used an acute accent, if we decided that they were all actually supposed to use a macron). (On De.Wikt I used to use the "all words" categories to look for words I didn't recognize, check Google Books and other dictionaries for them, and 'RFV' them if necessary.) A category of all lemmata would be useful for finding words to alliterate, and would also probably be more useful for any other practical purpose, for highly inflected languages where inflected forms would otherwise swamp the lemmata. Both categories would allow Wiktionary to be used like a paper dictionary, where all words can be seen in alphabetical order regardless of POS. - -sche (discuss) 16:22, 6 July 2014 (UTC)
Would a category for all lemmas, and another for all non-lemmas also be ok? That way, you could still look through all words, by searching through both categories. —CodeCat 16:34, 6 July 2014 (UTC)
No, I think there are advantages to having a category that already contains all words, vs having to merge two categories oneself. And I don't actually see a benefit to having a category for all non-lemmata at all, besides that it might provide a more up-to-date count of "form[-of] definitions" than WT:STATS does.
It's also worth noting that a category for all words will be simpler on a philosophical level, and presumably also on a technical level, to implement than a category for all lemmata, because for the "lemmata only" category we will have to wrestle with questions like: are Template:alternative spelling ofs lemmata? Are Template:standard spelling ofs lemmata? What scalable way is there to know which category to use for entries that only contain {{head|foo}} with no POS set? What scalable way is there to know which category to use for entries like messages (q.v.)? Etc, etc. Whereas, anything with {{head|en}} can go into the "all words" category. - -sche (discuss) 16:58, 6 July 2014 (UTC)
It's more that if we have a category for lemmas and all words, then every lemma in every language will have two more categories added to it. If we split them, it will only be one. As for the question of what is a lemma, I think it's relatively simple: if it would probably be listed as a lemma in a paper dictionary, we would do the same. My intention was to create separate category trees for lemmas and non-lemmas, Category:English lemmas and Category:English non-lemma forms. The former would contain Category:English nouns, Category:English verbs etc, while the latter would have Category:English plurals, Category:English verb forms and so on. I would consider an alternative spelling a lemma, because it is the lemma form of a word, and would presumably be found in a paper dictionary with a "see (other lemma)" notice. —CodeCat 17:31, 6 July 2014 (UTC)

FWIW, De.Wikt and Fr.Wikt both use their equivalents of Category:English language as their "all words in English" categories. We could either follow that model, or come up with a separate category, like Category:English words. - -sche (discuss) 16:58, 6 July 2014 (UTC)

A plea for more scrupulous patrolling[edit]

Rather sloppy content has been slipping through RC patrol recently. I have found some through second-hand monitoring pages like Special:UncategorizedPages and Special:Shortpages. Apparently User:SemperBlotto has been inactive lately, which means that someone else has to do what he has been doing. I urge all sysops and patrollers to visit Special:RecentChanges more often.

On request, I can grant rollback and patroller rights to trusted regulars. Keφr 06:56, 2 July 2014 (UTC)

Rollback and patroller rights AFAIK have in the past been done at WT:WL, requiring two admins' input, not one.​—msh210 (talk) 05:55, 6 July 2014 (UTC)
Given the lack of interest, this question is kind of academic anyway, but: Wiktionary:Beer_parlour/2013/October#Purplebackpack89 Rollback request. And for some (if not most) users listed at Special:ListUsers/rollbacker the rollback or patroller right has been granted without any process at all (just because Stephen sees someone undo a lot of edits). Of course, for me an autopatrolled flag (which is granted at WT:WL with input from two admins) is a prerequisite here. And given that I am announcing this in public, and it can be undone in case someone disagrees with my judgement, I think it should not pose a problem. Keφr 06:49, 6 July 2014 (UTC)
Sounds good to me.​—msh210 (talk) 07:40, 6 July 2014 (UTC)
@Kephir: Please make me a patroller. I don't promise anything, but becoming the patroller will create the temptation for me to actually patrol. Let the patroller flag be removed from me as soon as anyone disagrees. --Dan Polansky (talk) 09:00, 6 July 2014 (UTC)
Granted. Keφr 09:09, 6 July 2014 (UTC)
Wait, Dan doesn't have the mop? If he doesn't, he should. Purplebackpack89 15:02, 6 July 2014 (UTC)
He shouldn’t be an administrator if he still can’t deal with editors peacefully. I don’t think that he’s merited patroller rights either. --Æ&Œ (talk) 18:59, 6 July 2014 (UTC)
To be clear, I am hardly a big fan of Dan's, but given his, shall I say, very critical attitude to other people's editing, I doubt he is going to abuse the "mark as patrolled" button too much. About the rollback button, I am less sure. Keφr 20:08, 6 July 2014 (UTC)
AEOE, If dealing with editors peacefully is a criteria for adminship, there are some admins who should have their mops taken away. Purplebackpack89 22:49, 6 July 2014 (UTC)
Too bad SemperBlotto drove away all the new users that could have picked up the slack :P Kaldari (talk) 08:38, 13 July 2014 (UTC)

Converting WT:Information desk to monthly pages[edit]

Moved from Wiktionary:Grease pit/2014/July#Converting WT:Information desk to monthly pages

Can we do this now? The last time this was proposed there was some contention that new users might be confused by the monthly pages system and post things to the wrong page. However, I cannot recall a single such incident, so this seems to be a non-issue. Shall we switch WT:ID to the monthly page system as well? The benefits are quite obvious.

Keφr 21:14, 1 July 2014 (UTC)

There are plenty of examples of people (and in some cases the "+ (add section)" button itself—see [14]) getting confused and mistakenly posting to the main page rather than the monthly subpages, e.g. [15] and [16]. (There are also examples of people posting to the wrong monthly subpage.) However, I no longer feel that this is much of a problem. - -sche (discuss) 22:44, 1 July 2014 (UTC)
Is this worth even asking the question. The page doesn't get very big and shows no signs of growth AFAICT. DCDuring TALK 23:31, 1 July 2014 (UTC)
Yes it does. --WikiTiki89 23:35, 1 July 2014 (UTC)
I think all these were submitted while MediaWiki:Common.js was broken. So assuming it will not break too often, we are rather safe. Keφr 05:13, 2 July 2014 (UTC)
This is a WT:BP question now, since we know we are technically capable of it. --WikiTiki89 22:49, 1 July 2014 (UTC)
Yes, I see. The method used for BP would work for ID, but not for request pages without further complications. DCDuring TALK 00:28, 2 July 2014 (UTC)

It looks like -sche is for it, DCDuring has been convinced(?), and Wikitiki89 seems kind of supportive. One more supporter and if no one objects I go with it. Keφr 13:32, 5 July 2014 (UTC)

  • I oppose this. The benefit that I can see is no need to archive the page anymore, but the page is low-profile enough that archiving is not really a problem. The subpaging seems less intuitive than having a single page. --Dan Polansky (talk) 15:52, 5 July 2014 (UTC)
    • I think one of the reasons it is "low-profile" is that nobody wants to visit it, because it is so annoyingly large. (See WT89's diff above.) Keφr 16:01, 5 July 2014 (UTC)
      • I don't think so; the information desk is a rather unimportant page, especially compared to Beer parlour, so it gets low traffic; nothing to do with the size. As an aside, you said "I knew I could count on you." in the edit summary. If you want to say such things, be enough of a man and put them in the discussion, or, better yet, drop that juvenile behavior. --Dan Polansky (talk) 16:37, 5 July 2014 (UTC)
  • How about automating the current archiving method by archivebot.py (docs)? There will need to be slight (and probably good, I'd say) changes, though; the month headings need to go, and archiving will be done section by section, not all sections in a period at once. For an example, see ArchiverBot working on [17]. I can volunteer to run it, if there is interest. Whym (talk) 10:53, 6 July 2014 (UTC)
    • Not workable in my opinion. We have rather few bots, and for all I know, there is no one who can afford to run a bot full-time. And even if, they would probably prefer it to handle mainspace tasks. Also, I never liked Wikipedia-style archives. With monthly pages, you know that if you started a thread in one place, it stays there, unless expressly moved. Keφr 13:34, 6 July 2014 (UTC)
      • Just to clarify, I am an operator of the archive bot for two other wikis. It costs almost nothing to me to add one wiki. Whym (talk) 16:05, 6 July 2014 (UTC)
        • And who will replace you if you stop running it? (Which is another problem here. High rotation and little staff.) Keφr 16:43, 6 July 2014 (UTC)
          • (Just responding to "if you stop running it" for the record, not objecting to the other concerns Kephir and -sche noted) My bot uses Tools Lab. [18] Co-maintainers are welcomed. It could also be useful for archiving user talk pages. Whym (talk) 03:09, 7 July 2014 (UTC)

{{look}} Asking User:Æ&Œ, User:Equinox, User:-sche, User:Angr, User:Stephen G. Brown for further input. (Anyone else is also welcome.) Keφr 16:43, 6 July 2014 (UTC)

  • I have no strong opinion on the issue one way or the other. —Aɴɢʀ (talk) 19:13, 6 July 2014 (UTC)
  • I also have no strong feeling about monthly subpages. In the past, I opposed converting the Information Desk to subpages, out of concern for teh noobs, but as evidenced by my comment above, I no longer feel that people posting to the main page rather than the subpages is much of a problem, given how easy it is to move threads. The suggestion that a bot could archive threads on an individual basis is interesting, but the number of pages on which that might conceivably be useful is small (BP, GP, ID, ?TR?), and I think the benefit Kephir notes (of knowing that if you started a discussion on the July subpage, that's where it's staying) outweighs the small potential benefits of per-thread archiving. - -sche (discuss) 19:29, 6 July 2014 (UTC)
  • I don’t have a strong feeling about it. It gets very little traffic, so I don’t think it matters either way. —Stephen (Talk) 03:29, 7 July 2014 (UTC)
    • In the last archived batch, ID had 16 threads per month on average. Which seems rather typical, and is not that small in my opinion. The Etymology Scriptorium often has fewer topics.
    Anyway, what we have here seems to be three "welllll, sure, if you want to" (WT89, -sche, DCD), one oppose (DP), and two strong lacks of opinions (Angr, Stephen). I am going to convert it now. Revert me if you give a shit. Keφr 09:38, 9 July 2014 (UTC)

New Word of the Day feed[edit]

Featured Feeds for Word of the Day are now available: rss, atom. If you have a suggestion to better format the feed, I'd like to help implementing. Otherwise, enjoy. :) Whym (talk) 15:30, 2 July 2014 (UTC)

I just set up a FWOTD feed, when should I expect it to appear? Also, it would be nice if the feed item contained the actual word for its title. I already know how to set that up, but it requires running a bot over WOTD/FWOTD pages, which I am too lazy to do right now (basically, the same way we solved the problem with context templates). Otherwise, wooooooo! Keφr 16:00, 2 July 2014 (UTC)
Feed names need to be added on the server side; see gerrit:136316. Should FWOTD be added for all Wiktionaries or only for English Wiktionary? Whym (talk) 11:19, 3 July 2014 (UTC)
I have no knowledge of other projects having a FWOTD. Keφr 11:21, 3 July 2014 (UTC)
Ok, I have made the request in bugzilla:67563. Whym (talk) 11:02, 6 July 2014 (UTC)
And it has been resolved: [19][20] Whym (talk) 09:32, 11 July 2014 (UTC)

Recent "Tbot" entries[edit]

I've been finding a few entries here and there that are tagged with the {{tbot entry}} template that date to 2013 and 2014. They had redlinked categories, and I created a few of those categories using the {{tbotcatboiler}} template before I realized that these were for new entries.

Not that I have anything against the type of entries Tbot used to create, but if we're going to be doing this sort of thing again, we should change the documentation so we're not listing someone who's no longer here as the contact, and talking about how things are different now that it's 2007. Chuck Entz (talk) 07:44, 6 July 2014 (UTC)

If these entries are not by Tbot… where do they come from? Keφr 13:36, 6 July 2014 (UTC)
See this. One user making a few. I'd ask User:Liuscomaes. --Type56op9 (talk) 00:37, 9 July 2014 (UTC)



Does the {{deprecated}} headband is still available on that template? The template seems to be very used and no replacement is proposed. — Automatik (talk) 15:48, 7 July 2014 (UTC)

The replacement is to use a real part-of-speech header like "noun" or "verb". —CodeCat 16:06, 7 July 2014 (UTC)
What would be the replacement for IANAL? Keφr 16:08, 7 July 2014 (UTC)
Did you even look at the entry? :) —CodeCat 16:09, 7 July 2014 (UTC)
Oh, me stupid. Previous time I checked, the header was "Acronym". But truth is, even "Phrase" does not seem very fitting. Keφr 16:13, 7 July 2014 (UTC)
Well, in any case, the replacement is whatever header you would use for the fully spelled out form. So if "I am not a lawyer" is a phrase, then so is this. If not, then this needs to be changed, but I don't know what into. —CodeCat 16:15, 7 July 2014 (UTC)
And for the categorisation? {{en-noun|-}} doesn't seem to be correct for Mbps, neither {{en-noun}} because there is no inflection for this word. — Automatik (talk) 17:12, 7 July 2014 (UTC)
{{en-plural noun}}? (Which I still think to be a stretch.) Keφr 17:15, 7 July 2014 (UTC)
I don't think, because we can say 1 Mbps. — Automatik (talk) 17:19, 7 July 2014 (UTC)
I guess it's safe to say that it stands for both "megabit per second" and "megabits per second". --WikiTiki89 17:33, 7 July 2014 (UTC)
{{en-noun|Mbps}}? Keφr 17:35, 7 July 2014 (UTC)
Thank you, I used it. — Automatik (talk) 14:43, 8 July 2014 (UTC)
Realistically I don't think this template will ever be orphaned because it always needs human intervention. That is, a bot can't tell if it's a 'noun', a 'verb', (etc.) so a human editor is always needed. Meanwhile the template is still being used in new entries. But in principal 'noun', 'verb' (etc.) offers more information to the user, while things like 'acronym' should be in the etymology, as 'acronym' explains how the word was formed in the first place. Renard Migrant (talk) 10:13, 17 July 2014 (UTC)
We could make an abuse filter for it. —CodeCat 11:08, 17 July 2014 (UTC)

"Definitions" header in Chinese entries[edit]

Apparently, people have been adding this header to Chinese entries instead of part-of-speech headers. But I recall that there was no support for this in the previous discussion. Why is this being done anyway? These entries should be fixed. —CodeCat 11:58, 8 July 2014 (UTC)

Can we just have a real vote on it? Otherwise people are just going to keep going back and forth. DTLHS (talk) 21:53, 8 July 2014 (UTC)
Because the validation of a language-specific header does not require consensus by vote (Wiktionary:Entry layout explained/POS headers#Other headers in use). It only needs the agreement between editors who regularly deal with such entries. The "definitions" header is no different from the "Han character" header in use in the hundreds of thousands of Chinese character entries (e.g. ). Wyang (talk) 03:23, 9 July 2014 (UTC)
Inventing a new part of speech header for languages where it's appropriate (I've done this too, I added the "Relative" POS for Xhosa and Zulu) is not a problem. It's a very different story when you're introducing a new header to remove part-of-speech information altogether. That is my objection here. —CodeCat 11:33, 11 July 2014 (UTC)
Regardless of bureaucracy, what exactly is the reason for replace POS headers with ===Definitions===? --WikiTiki89 13:54, 11 July 2014 (UTC)
I'm with CodeCat and DTLHS here. Why not just split the meanings by part of speech like we do for literally every other language. If there's a case to be made for not doing this, set it out in a vote where we can all see it. Renard Migrant (talk) 10:43, 15 July 2014 (UTC)
  • Re: what is the reason, there's the simple fact that 1) Chinese doesn't inflect at all, so there's no useful information provided by the POS header other than the POS itself, which can easily enough be included inline; and 2) many Chinese terms have basically the same meanings applied in different POS ways. Take , for example. We've got 13 senses listed under 5 different POS headers. The headers really only serve to break up the page in ways that are unintuitive for Chinese. ‑‑ Eiríkr Útlendi │ Tala við mig 18:52, 15 July 2014 (UTC)
    Thank you for explaining your reasoning. Here's what I think: The POS headers are useful because they make it easier to find the definition you are looking for. Most of the time when you are looking up a word, you already have a good sense of its POS because of how it was used in a sentence, and so you can use the headers to narrow down your search for the definition. It would be very redundant to list "(noun)" before every noun sense, etc. BUT I think it may be a good idea to remove the requirement for "inflection lines" after each POS header, since they serve no purpose other than to duplicate the same information over and over. --WikiTiki89 18:59, 15 July 2014 (UTC)
Some of the reasons were also mentioned here: Template_talk:zh-pron#Why_does_this_categorise_in_part-of-speech_categories.3F. The choice of PoS is often arbitrary, based on the translation into English, dictionaries either mix up PoS or ignore it. By any system, listed PoS's do not sufficiently represent the actual usage. --Anatoli T. (обсудить/вклад) 05:28, 17 July 2014 (UTC)
I oppose "Definitions" header in Chinese entries, now as before. I already posted this, albeit to what is now ranked by someone as "off-topic", below. --Dan Polansky (talk) 18:05, 23 July 2014 (UTC)

Abbreviated Authorities in Webster[edit]

I have recently discovered the Abbreviated Authorities in Webster Table, and, noticing that a few of the early entries have been linked to Wikipedia, I have been adding a few such links myself. It's interesting, though there are occasionally mismatches of dates (should the Wikipeida date be moved in?). But it's a bit inconvenient for navigation. I feel that the table should be divided by initial letter. If this seems to be generally agreed upon, is it something I would need to do myself or is it something that should be done by a coding whizz ? —ReidAA (talk) 08:08, 9 July 2014 (UTC)

Excellent! That table could be quite useful in resolving some of the {{rfquotek}} entries.
I started manually splitting the table by initial letter. It is not hard. It just requires copying the wikitable formatting surrounding the "W" or Y" headers and inserting it in the appropriate place in the undivided table.
What might be a great help would be adding links to Wikisource, Google Books, or Project Gutenberg versions of some of the specific works. As an example I did so for Hawking and Hunting. To make sure that the work is useful we should extract from the XML dump a list of how often each authority is used within {{rfquotek}}. DCDuring TALK 10:12, 9 July 2014 (UTC)
The table is now initialised. I've done a bit more wiki-referencing some of the authors. --Catsidhe (verba, facta) 12:23, 9 July 2014 (UTC)
Thanks. A dump run would help us see which authorities were actually in use, so, for now, we may as well just pursue what is interesting. DCDuring TALK 14:01, 9 July 2014 (UTC)
As we would want to use this to source citations, the best forms of a work to link to would be those that allowed search at once of the entire range of the authority in question. Wikisource often breaks the work into chapters, which is unsatisfactory for search, though arguably good for linking. It is not so handy to have to download the work to search it. DCDuring TALK 14:22, 9 July 2014 (UTC)

Proper nouns[edit]

I just came across Bible and Qur'an, which are labelled proper nouns. But at the same time, these have plurals and can take an indefinite article. I just read through w:Proper noun, which suggests that real proper nouns (or proper names) can't take indefinite articles nor have plurals. If they do, then they're not proper nouns, but refer to a class of things rather than a unique entity. The article uses "Toyota" as an example that can be either: the company itself as a proper noun, or a car made by the company as a common noun. In this sense "Bible" is a common noun because it's a book that many copies can exist of. It doesn't act grammatically the same as other book or story titles, whether old or modern. Compare for example "Odyssey", which takes a definite article like "Bible", but doesn't normally have an indefinite article: a Bible versus a copy of the Odyssey, not *an Odyssey. So I wonder what kind of criteria we should apply to proper nouns on Wiktionary, and whether we shouldn't consider relabelling some. —CodeCat 18:33, 11 July 2014 (UTC)

Are given names not proper nouns? They can be pluralised: "All the Jameses in the room raised their heads.", and they do not seem to have a distinct meaning in the plural. Keφr 18:44, 11 July 2014 (UTC)
(e/c) In particular, we currently label personal names as proper nouns, while simultaneously admitting (in many though not yet all entries) that they pluralize. Ditto country names (Germany : Germanies, Germanys, America : Americas, France : Frances). - -sche (discuss) 18:46, 11 July 2014 (UTC)
These words can be both common and proper nouns. Compare the following sentences:
  1. The Bible says to honor one's parents.
  2. Jack read the Bible.
  3. Jack put the Bible he had just bought under his pillow.
In the first sentence, "the Bible" is indisputably a proper noun, while in the third, it is indisputably a common noun; in the second, however, it can be interpreted either way. --WikiTiki89 19:01, 11 July 2014 (UTC)
In cases such as Bible and Qur'an, I think we should include both POS sections, which is what Bible already does. — Ungoliant (falai) 18:54, 11 July 2014 (UTC)
Yes, in the case of books, I think including both sections (Proper noun, and Noun) is best. In the case of personal names, on the other hand, I think including two sections would be unjustifiable; as Kephir notes, the singulars and plurals have the same sense (differing only in number): "one Richard" means one person named Richard, "two Richards" means two people named Richard. Whether that means it would be better to relabel all personal names plain nouns, or live with pluralized proper nouns, I don't know. - -sche (discuss) 19:07, 11 July 2014 (UTC)
"One Richard" is a common noun. "Richard" by itself is a proper noun. However, I think it would be overkill to create common noun sections for every name. --WikiTiki89 19:14, 11 July 2014 (UTC)
We could also just call them all nouns, couldn't we? We could keep the category if needed, but just use the normal "Noun" header. —CodeCat 19:34, 11 July 2014 (UTC)
(@Wikitiki) I don't necessarily disagree that "Richard" can be a proper noun, but I note that whatever parts of speech "Richard" can have, "Richards" can also have. The very reason that given names' definition-lines are italicized is that they are in most uses non-gloss; "and then Richard arrived" means "and then a person named Richard arrived", not *"and then a male given name arrived". An exception would be a hypothetical use like *"not long after the first scribe began to spell the adjective which had been hart as hard, the change spread to instances of the word in compounds, and with that, Richard had arrived", where "Richard" really would be a proper noun meaning "a male given name" — but NB Richards could (equally hypothetically) be used the very same way, e.g. *"and when 'd'-final words began to pluralize with '-s' rather than '-es', Richards arose". - -sche (discuss) 19:36, 11 July 2014 (UTC)
Mentioning a word is an entirely different story. I was not referring to that at all. I also disagree that the plural exists as a proper noun (except in cases where a group of people who are all named "Richard" are collectively named "Richards"; e.g. Richards are coming for dinner, where "Richards" refers to a specific group of people). --WikiTiki89 19:48, 11 July 2014 (UTC)
FWIW, here's how de.Wikt handles it: common names are common nouns, e.g. de:Angela's POS is "noun - first name" and de:Fritz has one POS "noun - first name", another "noun - last name", and a third, labelled "noun", which covers in one section the slang uses that our entry on Fritz split into a "noun" and a "proper noun" section. When a name is defined as referring to only one specific person, e.g. de:Archimedes, it is labelled "noun - proper noun" (but contrast de:Platon). - -sche (discuss) 19:36, 11 July 2014 (UTC)
[e/c] A basic distinction is between proper names (of specific entities, eg, "The White House", "Mack the Knife", "Germany", "The Federal Republic of Germany", "Deutschland", my late dog "Hayek" [short his full name "Friedrich Augustus von Hayek"]) and proper nouns. CGEL (Huddleston and Pullum) hold that ""Proper nouns, by contrast, are word-level units belonging tho the category noun. Clinton and Zealand are proper nouns, but New Zealand is not." and "Proper nouns are nouns which are specialised to the function of heading proper names. There may be homonymy between a proper noun and a common noun, often resulting from historical reanalysis in one or other direction." Their examples are sandwich and Sandwich and rosemary and Rosemary.
Our L3 header "Proper noun" is applied both to terms that serve as names of specific entities and to "nouns which are specialised to the function of heading proper names". Even a term such as White House, which is often considered the name of a specific entity, ie, a proper name, can be shown to be attestably made into a plural. Are the uses of White House to be taken as nicknames for the specific entities Roosevelt White House or the Franklin Delano Roosevelt White House?
Whether in a given case we have under the L3 header "proper noun" a proper name or a proper noun (in the CGEL sense), there is no reason not to show plurals, if attestable. Showing a word like Bible as both a common noun and a proper noun seems fine as the common noun meanings are not entirely predictable from any of the meanings of the proper noun and are attestable, but both common and proper noun meanings are likely to be pluralizable, some attestably so. DCDuring TALK 20:09, 11 July 2014 (UTC)

Reading all of the discussion here, I wonder if things would benefit from an approach like the German Wiktionary, with all of them treated as nouns. Our header structure is different, so it would not fit in exactly the same way. So how about relegating proper name-ness to the actual definition line? For given names, we already have a template to do the job, and for others, the definition already implies properness in most cases. So there's nothing that the header "Proper noun" really adds beyond what the definition already tells the user. It would also allow us to list plurals without problems, while labelling the real proper names as uncountable, and we could also merge Noun and Proper noun sections together in entries when the distinction is not so clear anyway (like in Bible). Furthermore, we need to distinguish nouns that are used without the definite article (such as names) from those that are used with it. There is nothing in the current Bible entry that indicates this to the user. —CodeCat 20:59, 11 July 2014 (UTC)

Uncountability, as we use it, is not the same as not having a plural, though many use {{en-noun}} as if that were true, either through lack of understanding of uncountability, not reading the {{en-noun}} documentation, or being defeated by it. The problem would seem to be that we use "uncountable" both in reference to mass nouns, specific entities, and nouns whose plural form is the same as the singular form. If we could find attestation for expressions like "too much/little White House" (which we probably can), that wold show White House to be uncountable in the sense of mass noun.
Nothing in a template should per se prevent us from making a decision to show plurals for things that appear under the proper noun header. We would just have to revise {{en-proper noun}} and search instances were the plural shown by the template ("tail") did not conform to usage ("dog").
OTOH, none of the OneLook dictionaries call (the) White House a proper noun. (Most call it a noun; some seem to dispense with PoS labels.) We could either take that as an indication that we have bitten off more than we can chew or that we are making an un-lemming-like advance over other dictionaries.
Use with the is usually grammatical information (eg, no the in attributive use; the used to emphasize that a named entity was the famous one of bearing the name), but may also be sense-level information (examples to follow).
It seems to me that we are still some distance away from having a sufficient shared appreciation of the issues involved in altering the thousands of English proper noun L3 headers, let alone those in other languages. DCDuring TALK 22:10, 11 July 2014 (UTC)
  • I dissent from Wikitiki and CodeCat on this. It is possible for a proper noun to have both singular and plural forms. You can have one James or a lot of Jameses, one Henderson or a lot of Hendersons. I also don't understand where CodeCat is coming from with her Wikipedia argument: I read the article last night, and I came out of it thinking the opposite. Purplebackpack89 17:45, 23 July 2014 (UTC)
    @Purplebackpack89: See the section w:Proper noun#Capitalized common nouns derived from proper nouns. --WikiTiki89 17:51, 23 July 2014 (UTC)
    Jameses is the plural form of a common noun. It's very easy to see this just by back-forming the countable singular. A James is not the same thing as James, and there is certainly a big difference between saying you don't look like James and you don't look like a James. Furthermore, the statement James is a James is true, which illustrates that a single specific person called James is a member of the class Jameses (people who have the name James). Compare this to a car is a vehicle which has the same semantic structure. —CodeCat 18:35, 23 July 2014 (UTC)
    The problem, though, is that "Jameses" can be definite or indefinite. "a James" (indefinite) might be common, but "the James" is proper. Purplebackpack89 18:41, 23 July 2014 (UTC)
    "The James" is still a common noun, unless it is turned into a name/nickname. For example: Here "The James" is a common noun: "The James I met yesterday was taller than the James I met the day before." But here "The James" is a proper noun: "There are five people named 'James' at school, but only one of them—the biggest and baddest one—we call 'The James'; Everyone is afraid of The James." --WikiTiki89 18:49, 23 July 2014 (UTC)

Example sentences in ELE, linking of words and delinking of transliterations[edit]

What's the history of the rule behind Wiktionary:ELE#Example_sentences? Who said we can't link individual words? Now that transliteration is (unintentionally) wikified in {{usex}}, see Wiktionary:Grease_pit/2014/May#Transliteration_linked_to_individual_parts_in_usexes_when_hyperlinked, my request to delink it, is brushed by - we shouldn't link words, anyway. Can we change this rule - "not contain wikilinks" for words used in usage examples? Do we really need a vote for that? Can somebody help delink usex transliterations, as in this revision or this revision ? --Anatoli (обсудить/вклад) 00:28, 14 July 2014 (UTC)

Someone needs to edit Module:usex to delink transliterations- removing links by hand is a waste of time. DTLHS (talk) 00:39, 14 July 2014 (UTC)
Yes, I agree (thanks for agreeing to fix!) but the rule itself doesn't reflect the reality and I think it's not helpful. A lot of Russian usexes are linked (not my edits but I don't see it as a problem, in fact, it may quite useful for learners to link to lemmas or some difficult words) and most Chinese usexes are linked and it's very useful for languages with no straightforward word boundaries. Anyway, editors should be free to choose, if they want to wikify individual words in usexes. --Anatoli (обсудить/вклад) 00:58, 14 July 2014 (UTC)

Gender templates for French inflected forms[edit]

{{fr-adj-form}} has been edited so that it no longer accepts gender. I understand that adjectives do not inherently have their own gender but agree in gender with what they are describing. I also understand that in with the 'definition', it says 'feminine singular of' or 'masculine plural of'... but I still think we should encourage having the gender in the head word wherever possible.

My proposal is to enable gender in {{fr-adj-form}} and to add back the gender to French adjective forms wherever possible. This is very doable by bot, for example \{\{fr\-adj\-form\}\}\n\n# \{\{feminine of\|([\ -9\;-\\\^-z\}-ퟻ]+)(\||\}) is a regex that finds all the uses of {{fr-adj-form}} with no gender, followed by {{feminine of}} on the following line (with a single blank line in between). Renard Migrant (talk) 16:49, 14 July 2014 (UTC)

Why should the gender information be in two places, both on the headword line and in the definition? - -sche (discuss) 18:28, 14 July 2014 (UTC)
I oppose this for the reason -sche gave, and the reasons you yourself gave too. —CodeCat 18:29, 14 July 2014 (UTC)
I find it quicker to understand with the gender in the head word. I say quicker, probably by a few tenths of a second. Renard Migrant (talk) 21:57, 14 July 2014 (UTC)

How about going the other way then? Actively removing the gender from the headword template? That's even easier to do! Renard Migrant (talk) 11:03, 15 July 2014 (UTC)

Software update: <ref> without <references/> no longer shows an error or categorizes[edit]

As was announced on Wikipedia but oddly not over here yet, "With the deployment of 1.24wmf12 on July 10, missing reference markup will no longer show an error; the reference list will show below the content [...] without adding a category, so there's no way to find and fix the affected pages." See this WP thread (permalink) and this WP thread (permalink) for discussion, and diff for an example of the phenomenon. Note that our abuse filter still (correctly) discourages adding <ref> without <references/>. - -sche (discuss) 17:18, 14 July 2014 (UTC)

If a page has multiple language sections, and un-<references/>ed ref tags are added to one of the upper language sections, the references appear in the last language section. This has the potential to be especially confusing for people who use Tabbed Languages. - -sche (discuss) 18:26, 14 July 2014 (UTC)


In a discussion above, DCDuring noted something that (I think) implied we're not using the term "uncountable" the way we should. But I'm not quite sure what this means, as to me uncountable just means having no plural. Is this not what it means, and what does it mean in that case? I came across a few categories named "singulare tantum", is that the term we should be using instead of "uncountable"? —CodeCat 18:34, 14 July 2014 (UTC)

Uncountable does not mean having no plural, it means that quantities of the noun are not measured in discrete amounts. Theoretically, a noun could be countable, but not have a plural if, for example, there is only one in existence and no one ever speaks of any others. For an uncountable noun, it is impossible to say that "there is only one in existence". Proper nouns can be countable but not have a plural: there is only one William Shakespeare (barring metaphorical usage, or others who happen to have the same name), but William Shakespeare is most certainly countable. --WikiTiki89 18:57, 14 July 2014 (UTC)
What I understand, then, is that uncountable words have no plural for semantic reasons (it makes no sense to speak of a plurality) while the remainder have none only because it is simply rarely used or not at all. —CodeCat 19:04, 14 July 2014 (UTC)
Well I think that proper nouns such as William Shakespeare also don't have a plural for semantic reasons, but it's a different semantic reason. --WikiTiki89 19:23, 14 July 2014 (UTC)
"Paint" is uncountable when you talk about "some paint" but countable when you talk about "three different red paints". If something has no plural but is singular, I tend to use the "plural not attested": {{en-noun|!}}. Equinox 19:30, 14 July 2014 (UTC)
Yes, but the "paint"s in your two examples are different senses. --WikiTiki89 19:34, 14 July 2014 (UTC)
I think CodeCat is thinking about the inflection line for common nouns and {{en-noun}}, ie, not definition-level of countablity/uncountability distinctions.
The prevailing pattern of usage of "uncountability" by English native contributors at Wiktionary coincides with the mass noun concept. However, many uses of various early incarnations of {{en-noun}} used features of the template intended to mark uncountability (mass noun) to suppress the display of plurals, for whatever reason the contributor felt justified that suppression, eg, user didn't-know-how/couldn't-be-bothered to get plural ending in "es" or a truly irregular form to display, user didn't think noun had or should have a plural form, plural form was not attested. If you combine that with the changes to {{en-noun}} wrought by contributors with an imperfect understanding of the concept, you can understand why we have not made much progress in rectifying this. I hope we can come up with some scheme so that our inflection-line displays can be made correct without thousands of hours of tedium and are not too misleading in the interim. I doubt that bots can be relied on however, except perhaps for narrowly circumscribed cases.
At the sense level we use "labels" or "contexts" to distinguish. There is nothing that prevents understanding usually if someone uses a countable noun uncountably or an uncountable noun (mass noun) countably, but we have invested a great deal of effort in attempting to distinguish uncountable from uncountable senses, which effort is worth preserving. The task of marking each English noun sense as countable or uncountable (or both) is quite incomplete.
At the inflection-line level, we do not usually get data to support our claims that a given common noun is always or never countable or that countability of uncountability is the prevailing usage, relying mostly on native-speaker intuition, as most other dictionaries do not expend resources on this matter. DCDuring TALK 20:59, 14 July 2014 (UTC)
Would it be ok then if we adopt the practice of showing "no plural", "singular only" or the like in the headword line, and leave countable/uncountable information to the individual senses? That way the headword line is agnostic about countability, which makes sense if this can be different for different senses anyway. It would also mean changing the categorisation of many nouns, emptying out "uncountable nouns" categories in most cases and substituting it with something else. Possibilities might be Category:English singular-only nouns or Category:English nouns with no plural. We may want to revise the use of "plurale tantum" as well. —CodeCat 21:09, 14 July 2014 (UTC)
CodeCat said "as to me uncountable just means having no plural". Oh come on I find it hard to believe you're not better educated than that. There's such a thing as countable singular use, e.g. "I have a grain" is a countable singular use of grain. "I have some grain" is uncountable use of grain. Some countable nouns will be attested in the singular but not the plural. Renard Migrant (talk) 22:04, 14 July 2014 (UTC)
WT:AGF says we should take CodeCat's word for it. DCDuring TALK 22:15, 14 July 2014 (UTC)
No, it only says that we should assume CodeCat's intentions were in good faith. --WikiTiki89 15:00, 15 July 2014 (UTC)
@CodeCat: If eliminating inflection-line information would make things simpler for you, who am I stand in your way? Why don't we eliminate the display of regular plurals (ending in "s", "es", and "ies") too? Oh, wait, users might value the information.
The logic of our entry display is that inflection-line information is assumed to carry over to definition lines unless there is something contrary indicated on the definition line. Thus exceptional plurals are sometimes displayed at definition lines, sometimes only at definition lines. It is a major change to depart from that formulation for one attribute of one PoS in one language, especially where the language is the wiki's host language.
So, before we start changing modules and templates of wide use, I would like to understand an implementation plan that preserved the correct information that was now in the inflection lines and transferred it to the definition lines for each type of headword-line, whether implemented using {{en-noun}} or {{head}} directly or by other means. A dump-processing run that took a census of the options used in {{en-noun}} would be useful for that. We must have at least a dated one to support the major changes you previously made to {{en-noun}}.
It would be nice if the changes were carried out with more care and knowledge than the changes made to {{en-noun}}. DCDuring TALK 22:15, 14 July 2014 (UTC)

Context Label: Reflexive[edit]

I have recently edited the module code for the context labels (https://en.wiktionary.org/wiki/Module:labels/data) so as to have it automatically send entries marked with the label "reflexive" into a category named "-LANGUAGE NAME- reflexive verbs". I did this in an attempt to have the Macedonian reflexive verbs compiled into a list, since I didn't see any other way to do this other than add "[[Category:Macedonian reflexive verbs]]" under each entry, which didn't seem like an ideal solution - I wanted something automatic, just like the automatic system that works for intransitive and transitive verbs. I also thought that if I merely wrote "[[Category:Macedonian reflexive verbs]]", it may end up erased in the future, whereas some automatic mechanism would be operable on a longer term. However, things have gone awry.

Apparently, the context label "reflexive" has been used for various entries in various languages to mark reflexive pronouns as well. It has also been used to denote reflexive senses of verbs which are not truly reflexive and thus don't belong in a reflexive verb list. Now, I suppose these things need mending, so I have come here to announce what has happened in hope that someone will be able to restore things the way they were before the change (and possibly advise me as to how to solve the problem I had with the Macedonian reflexive verbs, i.e. how to have them automatically go to a list of reflexive verbs). Martin123xyz (talk) 14:59, 15 July 2014 (UTC)

As far as I understand, you could have a label 'reflexive verb' that displays reflexive but categorizes in reflexive verbs. I don't know about other languages (much) but in French, almost all transitive verbs can be used reflexively, and almost no verbs are always reflexive, so you could talk about reflexive usage but not reflexive verbs (because they're not inherently reflexive, just they can be used that way). Renard Migrant (talk) 15:02, 15 July 2014 (UTC)
I noted before you made this change that calling verbs where one or more senses are used reflexively "reflexive verbs" is silly. Just look at Category:English reflexive verbs now. Almost none of them are actually reflexive, they just happen to have a sense that is used reflexively. The same applies to Category:English transitive verbs and Category:English intransitive verbs as well, which also had categorisation added recently for some reason. And Category:English countable nouns and Category:English uncountable nouns are a similar problem, which prompted me to start the discussion above. —CodeCat 15:03, 15 July 2014 (UTC)
That's the argument for categories with names like Category:English nouns with countable senses. Even then, it would seem even better to just not categorize at all. Renard Migrant (talk) 15:19, 15 July 2014 (UTC)
Probably, yes. Most of the time these labels are only used when it's not clear from the definition, or to contrast with other definitions. So paradoxically, the nouns labelled "countable" are primarily those which are also labelled "uncountable". —CodeCat 15:21, 15 July 2014 (UTC)
I know that many think it pointless to have a reflexive verb category, but in Macedonian there are some verbs that are always reflexive, i.e. whose reflexive form is inherent. For example, "се кае" means "to regret", but "кае" doesn't anything. Also, there are many cases where a reflexive form of a verb is unrelated to the basic one when it comes to meaning. Thus, "дере" means "to skin" whereas "се дере" means "to scream". I think that these verbs deserve a separate category. Finally, many of the reflexive verbs in Macedonian have one-word equivalents in English - in those cases, English doesn't convey reflexivity explicitly. For example, Macedonian "се движи" and "движи" both correspond to English "move", but they have different meanings - the former means to be in motion whereas the latter means to cause something to be in motion. I think that in these cases too, the reflexive verb deserves its own category.
It's not as though I created separate entries for all reflexive forms in Macedonian and then declared them unique verbs. For example, I haven't created an entry "се допира" beside "допирa", because I don't feel that there is anything special about the reflexive form - it is marked explicitly in English too. Namely, the difference is that between "to touch oneself" and "to touch". This is because "се допира" is a true reflexive verb, whereas the point is that I am not really focusing on the true reflexive verbs. I am more interested in a separate category for the autocausative, anticausative and inherent ones. The true reflexive, reciprocal, and universal passive verbs are predictable and as you pointed out, derivable from any transitive verb. I really don't know why all of these are under the umbrella term "reflexive verbs"...
Anyway, I have a potential solution. I would create a new context label in the module code, called "mkreflexive", which would send entries to "Macedonian reflexive verbs", and I would mark Macedonian reflexive verbs with it. Meanwhile, I would set the display to simply "reflexive", which is what users actually need to see. Then, only I (and possibly someone who chooses to continue my work in the future) would use this label, and there would be no categories for reflexive verbs for other languages and no problems with reflexive pronouns or pseudo-reflexive verbs. However, could the problem I have caused already be fixed, i.e. could all the unnecessary (and defective) categories be undone? Martin123xyz (talk) 15:24, 15 July 2014 (UTC)
{{fr-verb}} covers this by allowing type=reflexive. There are some, s'agir differs in usage from agir for example. Renard Migrant (talk) 15:28, 15 July 2014 (UTC)
I don't agree with creating such a label. A better solution would be to let the inflection table add the category. —CodeCat 15:31, 15 July 2014 (UTC)
How would I let the inflection table add the category? I use the same inflection table for reflexive verbs, except that I use the parameter "ref" to have it add the reflexive marker "се" where appropriate. 16:08, 15 July 2014 (UTC)
You (or someone) can edit the template and have the "ref" parameter trigger a category. --WikiTiki89 16:48, 15 July 2014 (UTC)
Could you tell me how to have the parameter trigger a category? I have no idea where to code that, as I've never even defined the "ref" parameter anywhere. I just automatically used it in an if-statement and it worked. Martin123xyz (talk) 16:55, 15 July 2014 (UTC)
Exactly the same way. You use it in an if-statement, and have the true-clause add a category: {{#if:{{{ref|}}}|[[Category:WHATEVER]]|}}. You can add that anywhere really, but the end is the best place I think. --WikiTiki89 17:06, 15 July 2014 (UTC)
How very simple - thank you. I didn't think it could just work like that. I'll see to it soon enough. Martin123xyz (talk) 17:08, 15 July 2014 (UTC)
I prefer refl in general to avoid confusion with reference. Renard Migrant (talk) 20:58, 17 July 2014 (UTC)

Script or language: let us reduce ambiguity and prevent confusion![edit]

On pages such as https://en.wiktionary.org/wiki/Appendix:Proto-Slavic/-ica and in many translations lists, spellings of one word in one language are given in multiple scripts. These scripts are indicated by names that sometimes coincide with language names, such as with "Latin" and "Hebrew". That easily creates ambiguity and, with it, confusion, at least with me. I have changed such references several times by adding the word "script" where a script is meant, but such contributions have also been reverted. I do insist that tables where language( groups) may be branched into several languages and where languages may be branched into several scripts, it is difficult for the eye to make out if the final branch concerns a language or a script.

I propose adding the word "script" to all occurrences of script names near language names. I do not know how to do it, but there seem to be scripts (of a different kind, this time) that can help us do this in a rather automated way.

Please help a language enthousiast, and his colleagues!

(I am trying to find my way, and just found out that this divided into month parts. This is the second place where I added my plea, because I put the first one in a month part somewhere in 2013.Redav (talk) 20:27, 17 July 2014 (UTC)

Support. Before I started using targeted translations, I used to come across some really strange Latin translations, only to find out it was Latin-script Ladino. It was my fault for skimming through the translations too quickly, but it won’t hurt to add script to the lines. — Ungoliant (falai) 20:35, 17 July 2014 (UTC)
(e/c) I don't see where the confusion can come from, since Latin is not a sub-language of Serbo-Croatian. In some places, we do use the word "Roman" instead, but this does not solve the problem in the general case, since some multi-scriptal languages use scripts like Hebrew and Arabic, which are also languages. --WikiTiki89 20:38, 17 July 2014 (UTC)
"Roman" is a misnomer anyway. The script is called Latin; "roman" is one variety of the Latin script, the other being called "italic". —Aɴɢʀ (talk) 20:44, 17 July 2014 (UTC)
By that logic, romanizations would be de-italicizations. "Roman" has both meanings. --WikiTiki89 20:50, 17 July 2014 (UTC)
Would they even be de-italicizations, if they were presented (as they sometimes are) in italics? Would they not then be italicizations? Why, this puts a whole new spin on the debate over whether or not to italicize Cyrillic! lol
As WikiTiki says, "Roman" has both meanings. - -sche (discuss) 20:55, 17 July 2014 (UTC)
For some languages, such as Cree, script names are (in my experience) not provided at all. One sees simply Cree: ᒪᐢᑲᐧ / maskwa. Providing script names, especially with "script" spelled out, would be quite unwieldy:
- -sche (discuss) 20:55, 17 July 2014 (UTC)

For Beer parlour people who work more in discussions than on translations or in the main namespace, it IS confusing to have "Latin" and "Hebrew" to mean both the script and the language (also script tags Roman and Cyrillic). If you used User:Conrad.Irwin/editor.js quite a lot, you'd notice that the name conflict is quite frequent. When a translation into Hebrew, Aramaic, Serbo-Croatian, Latin appears not where it's expected, either from this tool, a bot or a human error. I'm not suggesting any specific solution but just letting you know that I have also experienced these problems firsthand and I am also very interested in the resolution. --Anatoli T. (обсудить/вклад) 00:49, 18 July 2014 (UTC)

You're right that it causes bugs in some of our tools, but I don't think it's confusing to people (at least when everything is formatted correctly). --WikiTiki89 13:13, 18 July 2014 (UTC)


This bot, which belongs to User:JackPotte, has been active on Wiktionary in the past, but in December I noticed that it has no bot flag, so I followed our current procedure as I understand it, and blocked the account. Since a protest of the block has now been posted on the talk page, I thought it would be a good idea to expedite things by bringing it up here. I also want to know if I should have dealt with the matter differently, and if I should handle bot accounts differently in the future.

I should mention that, although most of the edits have been interwikis, a run was performed in March of 2013 that created a large number of entries for Geological era names, at least some of which (if memory serves) ended up in rfv. I don't have any objection to those entries as a whole, and they may very well be a one-time exception to the bot's normal interwiki tasks, but I thought they were worth mentioning, just to be complete. Chuck Entz (talk) 21:58, 19 July 2014 (UTC)

Hello, just to precise that my March summaries were pointing to their BP permission. JackPotte (talk) 22:48, 19 July 2014 (UTC)
I think JackBot failed either two or three bot votes. Renard Migrant (talk) 21:20, 23 July 2014 (UTC)
Precisely and objectively I had already proposed here two bot jobs which had been judged unnecessary by a minority:
  1. Wiktionary:Votes/bt-2009-12/User:JackBot
  2. Wiktionary:Votes/bt-2010-11/User:JackBot2
But they could also have been useful as on 21 other wikis as you can see, and are not linked to the test for which I was indefinitely blocked after without a message (which is not praised in the current recommendations as I've already demonstrated in the dedicated template).
Moreover I used to published my scripts on the bot subpages and Github, if you want to make your own idea of the whole context apart from that. JackPotte (talk) 19:30, 24 July 2014 (UTC)

Russian pronunciation - standard, alternative, regional, dated or simply individual[edit]

User:Wikitiki89 has been persistently adding alternative Russian pronunciations, which I consider not only non-standard but individual and rare, possibly limited to immigrants. He has been very persistent in his edits, so any reversals just results in edit wars. I have no problem with having alternative non-standard forms but Russian is much more phonetic than he claims it to be, so if you pronounce it irregularly, you can spell it so, there are notable (well-documented exceptions), which also follow certain rules or patterns but there is some limit to irregularities. I tried to compromise by creating alternative non-standard forms but he insists on adding these irregular pronunciations on the regular entries. In particular he claims that these words are alternatively pronounced:

  1. капюшо́н (kapjušón) as капишо́н (kapišón)
  2. двою́родный (dvojúrodnyj) as двою́рный (dvojúrnyj)
  3. во́доросль (vódoroslʹ) as во́дросль (vódroslʹ)
  4. не́который (nékotoryj) as не́кторый (néktoryj)
  5. сейча́с (sejčás) as щас (ščas) (I'm OK with this one but still the casual pronunciation should belong to the alternative forms, since it exists)

Another claim was that бюрокра́тия (bjurokrátija) can be also pronounced as бирокра́тия (birokrátija), which I find quite ridiculous and he's using кверх нога́ми (kverx nogámi) as the first translation for upside down, "кверх нога́ми" sounds very rustic and illiterate to me (even if this form can be found on the web), вверх нога́ми (vverx nogámi) is the common and standard form. These alternative forms do exist but they are not as common and these pronunciations are neither standard nor common. In any case, the alternative pronuncations, IMO, belong to alternative forms. I am creating a request on gramota.ru, since I don't know how to handle this situation. The English Wiktionary doesn't have enough native Russian speakers, so I'm not sure this argument can be resolved. On the Russian Wiktionary such edits would be ultimately reverted. I don't claim to be the ultimate source for the Russian language but some Russian edits of Wikitiki89 surprise me. Sorry, I don't mean to insult him or something. My goal is accuracy. --Anatoli T. (обсудить/вклад) 00:43, 21 July 2014 (UTC)

Let it be known that (1) Anatoli's Russian and my Russian are from different regions, (2) I was raised in a highly educated environment and could not possibly have picked up any "illiterate" Russian, and (3) I have been willing to discuss each of the above cases individually with Anatoli and don't see a need for BP discussion. --WikiTiki89 01:44, 21 July 2014 (UTC)
1) My family's accents are a mixture of south Russia, Ukraine and Siberian accents. Due to education exposures and self-discipline as far as the language I speak standard and common Russian, not southern or Ukrainian Russian, travelled a lot in Russia, read many books and watched a lot of movies, videos, etc. My Russian is not regional at all and I can tell when Russian is regional or non-standard. And since I lived till I was 30 in Russia, speak Russian with my family, friends and communicate with Russians in Russia, I have been exposed to various accents. I'm sure I can judge what is right and what is wrong in Russian to a high degree but as I said, by no means, I don't consider myself an ultimate source. Having said this, I humbly consider my Russian significantly better than his. 2) It is quite commendable for a long-time emigrant, who left Russia in the young age to preserve the language but there are still small problems, which show in the edits and I don't think we should allow misleading info. 3) the discussions so far have not been very fruitful and edit-warring has happened on a number of entries. As an interim solution, I suggest to source irregular pronunciation with something other than plain Google searches. As I said, I don't oppose any non-standard form entries, which I have also created. --Anatoli T. (обсудить/вклад) 02:05, 21 July 2014 (UTC)
And how should I do that? With links to YouTube videos? --WikiTiki89 02:17, 21 July 2014 (UTC)
Not sure yet. Maybe Youtube, if the pronunciation is clear and the speakers are native speakers. --Anatoli T. (обсудить/вклад) 02:23, 21 July 2014 (UTC)

I support moving non-standard pronunciations to the entries with non-standard spellings. --Vahag (talk) 08:57, 21 July 2014 (UTC)

This would resolve some disagreements, since Russian pronunciation is much more regular and most irregularities are documented. It doesn't matter that much if a spelling is used more often than pronunciation or the other way around. Just need to create those non-standard forms. The irregular spelling is used quite often used to render the irregular pronunciation and the existence of irregular spellings can usually be easily found. --Anatoli T. (обсудить/вклад) 09:11, 21 July 2014 (UTC)
On the other hand, most people who use the colloquial pronunciations, use only the formal spellings. --WikiTiki89 11:55, 21 July 2014 (UTC)
Yes but even if a person reads "what's up" as "wassup", it doesn't mean that "what's up" should have the same pronunciation. It's better to separate regular and irregular pronunciations and spellings, especially when a form is definitely a different (older, colloquial, regional) of another one, like капюшо́н (kapjušón) and капишо́н (kapišón). --Anatoli T. (обсудить/вклад) 22:52, 21 July 2014 (UTC)
"What's up" and "wassup" is a bad example, because it is colloquial either way and so people will write it exactly as they say it. This is more like environment being pronounced like enviorment (which is citeable in google books:"enviorment"). Most people who say enviorment, still write environment, which is why it makes sense to have the pronunciation right there. --WikiTiki89 23:32, 21 July 2014 (UTC)
Well, it depends on the case and if you can make this type of judgement. If you consider "wassup" a bad example, then "капишон" is worse. It's a dated form, not an alternative pronunciation, since "пю" is never read as "пи" as you insisted. --Anatoli T. (обсудить/вклад) 23:51, 21 July 2014 (UTC)
I said that "wassup" is a bad example, because "what's up" is also colloquial. "Капюшон" is not colloquial, so that reason does not apply. Compare it to my example of environment. --WikiTiki89 23:58, 21 July 2014 (UTC)
I think you misunderstand. "wassup" (colloquial) should have its own pronunciation, so should "капишон" (dated) and "двоюрный" (irregular) but the regular forms shouldn't include them. "водросль", "некторый" may be considered similar to the "enviorment" case. --Anatoli T. (обсудить/вклад) 00:14, 22 July 2014 (UTC)
I did not misunderstand you. You misunderstood me. All I am saying is that "wassup" is a bad analogy because "what's up" itself is also colloquial, while "enviorment" is a much closer analogy. Would you say that the pronunciation /ɪnˈvaɪɚmɪnt/ doesn't belong at environment? --WikiTiki89 00:25, 22 July 2014 (UTC)
It does, I have already said so, so does "сечас" belong to "сейчас", "пожалуста" to "пожалуйста", also "водросль", "некторый", even if pronunciations are less common. --Anatoli T. (обсудить/вклад) 00:33, 22 July 2014 (UTC)
Am I missing something or are you agreeing with me now? --WikiTiki89 00:39, 22 July 2014 (UTC)
What I'm saying is, one needs to judge whether a pronunciation is indeed alternative or it should belong to a different spelling. /ɪnˈvaɪɚmɪnt/ and /ɪnˈvaɪɚnmɪnt/ can belong to "environment" entry. Same with some Russian words I mentioned above, e.g. сейчас as /sʲɪˈt͡ɕæs/ (=сечас). However, "капюшон" and "капишон" should definitely have separate pronunciations, like "wassup" and "what's up". --Anatoli T. (обсудить/вклад) 00:48, 22 July 2014 (UTC)
Ok, so you agree with me for "водросль" and "некторый", but not for "капишон". I'm willing to concede "капишон" for now until I get some more data on it. I have already found a few YouTube examples of the pronunciations "водросли" and "проволка" used with the spellings "водоросли" and "проволока". --WikiTiki89 01:10, 22 July 2014 (UTC)
Yes, "водросль" and "некторый" are OK, even if I don't think they are common, I found that people were surprised like me with these accents but these can be considered alternative pronunciations with a drop of vowel, which does happen. So, I'm conceding on these. I put "двоюрный" into the same bucket as "капишон", although they differ in etymology. Note, even if you find pronunciation "капишон", it still belongs to this different spelling. Just making sure you agree on the distinction. --Anatoli T. (обсудить/вклад) 01:19, 22 July 2014 (UTC)
It depends. For example, if I find a video titled "мой классный капюшон" where it is clearly pronounced "капишон", then that is (one piece of) evidence that the pronunciation does belong at "капюшон". I also think there is some confirmation bias going on. When I listen to someone say "капюшон", I hear "капишон"; and I'm sure that if you listen to someone say "капишон", you will hear "капюшон". These vowels are very close and in a short unstressed syllable, they are hard to distinguish. --WikiTiki89 01:27, 22 July 2014 (UTC)
I know what you mean. There are ways, as I suggested one can use a tool such as Audacity where you can listen in a very slow speed (you can adjust the speed). The audio should be available as an MP3 or OGG file, for example. Yes, your example with "мой классный капюшон" would work. As an example, I used Audacity to determine Chinese tones and prove my point that Chinese tones are pronounced even in quick speech. "Hard" is not impossible with technologies. --Anatoli T. (обсудить/вклад) 01:42, 22 July 2014 (UTC)
As a longtime student and user of the Russian language, I consider the Russian entries on English Wiktionary to be intended for native English speakers who are interested in a Russian word or who are studying Russian. As such, I see no value in putting these anomalous pronunciations here, and I think American students of Russian will take away the wrong thing from them. Such pronunciations belong in the Russian Wiktionary for the enjoyment of a native Russian audience. This reminds me of w:Charles Robert Jenkins, an American defector to North Korea. Jenkins got a job teaching English at a North Korean university, since the North Koreans wanted to learn English well enough to pass as South Korean. However, Jenkins was from North Carolina and spoke with a strong southern accent. Once the Koreans learned his English pronunciation was very odd, he was fired from his job. When people study a foreign language, they usually want to learn the best standard pronunciation. —Stephen (Talk) 03:31, 22 July 2014 (UTC)
I have nothing against properly indicating which pronunciations are standard and which are colloquial, but there is no reason to suppress information. --WikiTiki89 04:00, 22 July 2014 (UTC)
We’re not suppressing information, it’s a matter of putting the information where it belongs. This information belongs on the Russian Wiktionary. There are three major accent areas in spoken Russian ... if we wanted to see nonstandard pronunciations here, it would be far more preferable to show the pronunciations of the other two major accents, northern (with оканье among other features) and southern (with аканье/яканье among other features). But even this is really not useful to indicate on every page, and would be likely to cause confusion and damage. The northern and southern Russian accents should be described and explained with sufficient examples on Appendix pages. But the idiosyncratic pronunciations you are adding are not so useful or interesting and I would not include them on English Wiktionary at all. —Stephen (Talk) 05:55, 22 July 2014 (UTC)
I will not comment on the specifics of this discussion, as I’m very little familiar with Russian, but I support the inclusion of regional, nonstandard and colloquial pronunciations in the English dictionary. They should be tagged as such, of course. — Ungoliant (falai) 21:48, 23 July 2014 (UTC)
It's about specifics of various pronunciations. It's not so much about whether we include regional, nonstandard and colloquial pronunciations but whether they are frequent enough for inclusion (not individual, used by limited overseas communities), belong to the same spelling as the standard pronunciation. Yes, labelling is important and we do include variants. Major variations - northern "okanye" and southern "h" for "g" could be considered as well, if they are needed. --Anatoli T. (обсудить/вклад) 22:59, 23 July 2014 (UTC)

User:Wikitiki89 and proper nouns[edit]

User:Wikitiki89 has been going around changing things from proper noun to common noun. In particular, he has been doing it with political factions such as Libertarian and Democrat, plus the California separatist group known as the Osos. I believe that he is in error, and I have reverted him pending discussion here. Purplebackpack89 17:34, 23 July 2014 (UTC)

Democrat, Libertarian and Oso are proper nouns
  1. Purplebackpack89 17:34, 23 July 2014 (UTC)
Democrat, Libertarian and Oso are common nouns
  1. Sure, Democrat, Libertarian and Oso are common nouns. Just like many of the items at Category:English words suffixed with -ian. Just like Frenchman, Popperian, or Clintonite. --Dan Polansky (talk) 17:58, 23 July 2014 (UTC)
Please take a look at our POS for Englishman, American, Frenchman, and many more, none of which I have ever edited. --WikiTiki89 17:37, 23 July 2014 (UTC)
But you have mass-edited a number of pages in the last hour or so after I mentioned Democrat was tagged as a proper noun, and have edit-warred with me to keep them common nouns. You should stop changing pages until this discussion is over or you've linked me to another beer parlor discussion that supports your POV. Purplebackpack89 17:43, 23 July 2014 (UTC)
I do not need your permission to make changes that we have had a consensus on for a long time. --WikiTiki89 17:45, 23 July 2014 (UTC)
If you claim such consensus has existed for a long time, the least you can do is provide a link to that discussion (and the discussion from earlier this month is a) still going, and b) not at consensus at the moment). And if the last discussion with consensus was indeed a long time ago, then it may not hold now and it is perfectly acceptable to revisit it. Particularly if the discussion was about some subset of nouns that are different from this subset. Purplebackpack89 17:50, 23 July 2014 (UTC)
Take your pick. --WikiTiki89 17:55, 23 July 2014 (UTC)
Wikitiki89 is correct; these are common nouns, like Briton and Nazi. - -sche (discuss) 18:01, 23 July 2014 (UTC)
I agree, and so do the professionally edited dictionaries in which I just checked Frenchman (Chambers, Merriam-Webster, OED). The test of "properness" of a noun is not, of course, just whether it has a capital letter! Equinox 18:56, 23 July 2014 (UTC)
So a user has been going round making correct edits. Why are we discussing this? Are there so few correct edits nowadays we need to have threads to discuss them in? Renard Migrant (talk) 21:19, 23 July 2014 (UTC)
Democrat isn't the faction (as you put it) Democratic Party is the faction, perhaps that's what's causing the confusion here. Renard Migrant (talk) 21:26, 23 July 2014 (UTC)

Can we get 'particularly useful translation target' into CFI?[edit]

From Wiktionary:Requests for deletion#emergency physician (later: Talk:emergency physician) two users want to keep outside of CFI as a translation target. I worry about translation targets as a bit of a slippery slope issue. Do we want an entry in English for everything that can be expressed as a single word in one other language? No. Because then we'd end up with he had had in his possession a bunchberry plant (I'm not kidding, see xłp̓x̣ʷłtłpłłs). Is there any way to regulate this? There's a further issue, translation is necessarily subjective so what one person might translate with a two-word noun, I might translate with a slightly different two-word noun. It's tricky.

As a completely separate issue, I've noticed that entries de facto don't need to meet CFI. They just need to not get nominated for deletion or get nominated and pass with a consensus even if they don't meet CFI. I suppose that's why serious efforts to amend CFI into something usable have failed. It's easier to just keep on ignoring it. Renard Migrant (talk) 21:16, 23 July 2014 (UTC)

You're setting up a strawman. No one has ever been proposing to have he had had in his possession a bunchberry plant only because there is a single entry like xłp̓x̣ʷłtłpłłs. If we were after a formal strict set of criteria for translation targets, we would take care to handle these sorts of languages. --Dan Polansky (talk) 21:36, 23 July 2014 (UTC)
I'm not setting up a strawman. I'm saying we would need criteria and you seem to be agreeing. Renard Migrant (talk) 21:45, 23 July 2014 (UTC)
I agree; this practice should be codified. My first suggestion is that it should be used for lexemes, not individual forms, with distinct meaning (i.e., let’s not add I will do because farei, haré etc. exist nor translations of the “sentence-words” of polysynthetic languages). — Ungoliant (falai) 21:40, 23 July 2014 (UTC)
Thirded. We should codify "hot words" too. The problem always is that there are so many issues and so few people willing to tackle them. And often people get distracted before we reach anything conclusive. Keφr 22:10, 23 July 2014 (UTC)
  • Support: Purplebackpack89 22:12, 23 July 2014 (UTC)
  • Support as well. I would also support clarifying CFI in general to make it less opaque and more friendly to people not familiar with Wiktionary. Ideally, it should be written in such a way that someone who has spent only a day using Wiktionary (as a reader, not a contributor) should be able to understand enough of it to not do anything really bad. —CodeCat 22:16, 23 July 2014 (UTC)
  • Support as well. Also, I think we need to include Wiktionary:Lemming_principle#Lemming_test. What about back-translations from English (for lexemes only, as per Ungoliant's comment above)? Terms such as па́лец ноги́ (pálec nogí) and 足の指 (ashi no yubi), etc. have passed RFD, both non-idiomatic translations of toe, literally "finger of the foot". Such terms do penetrate various dictionaries, since "toe" exists in English, what's the word for it in language X? --Anatoli T. (обсудить/вклад) 22:59, 23 July 2014 (UTC)
    • To note: the closing comment at Talk:палец ноги and Talk:足の指 are "Kept: no consensus to delete either entry" and "Kept: no consensus to delete" respectively. Keeping due to "no consensus" is a rather weak outcome in my opinion, and I always had the impression that these "no consensus" entries are more open to renomination than those with clear consensus to keep. This is hardly "passing RFD". Keφr 23:17, 23 July 2014 (UTC)
I know. "No consensus" is not a strong case for closing RFD. Still, they are kept for now. With proper formatting (a soft redirect?) and labelling, they may be a bit more palatable. They are not idiomatic by definition and if they are only there to point users to how an English term is translated, there may be some room for them here. --Anatoli T. (обсудить/вклад) 06:59, 24 July 2014 (UTC)

Looking to get AWB privileges[edit]

Hello. I'm relatively new to Wiktionary but I've been active on Wikipedia for a long time. I've been working on Old French verbs and there are a bunch of changes I'd like to make that are too painful to do without an automated regex tool like AWB -- basically, to change the templates used for conjugating a number of verbs. Could someone add me to the list of registered AWB users? Thanks.

Benwing (talk) 05:32, 24 July 2014 (UTC)

I have added you to Wiktionary:AutoWikiBrowser/CheckPage#Approved_users. —Stephen (Talk) 06:59, 24 July 2014 (UTC)
Awesome, thank you. Benwing (talk) 08:50, 24 July 2014 (UTC)

Are phrases lemmas?[edit]

Entries marked as {head|xx|phrase} are currently listed in the main lemmas category. Are they really lemmas? I think they should be in a Phrases subcategory under the main lemmas category. --Panda10 (talk) 12:33, 24 July 2014 (UTC)

They are lemmas because they are not a form of another lemma. —CodeCat 12:40, 24 July 2014 (UTC)
I agree, though it is sometimes hard to identify the lemma properly, as such multi-word entries, especially with verbs, are, at essentially defective, or at least have a dramatically different distribution of use across inflected forms. DCDuring TALK 13:51, 24 July 2014 (UTC)
The problem is really that we're not using the term "phrase" properly on Wiktionary. In many cases, it seems that "sentence" is the more appropriate term. See w:Sentence (linguistics). —CodeCat 14:05, 24 July 2014 (UTC)
I'm not sure about the "They are lemmas because they are not a form of another lemma" argument. Phrasebook entries such as I don't understand or this morning clutter up the lemma category and will contribute to an inaccurate count of lemmas. --Panda10 (talk) 13:05, 25 July 2014 (UTC)

Including sum-of-parts terms[edit]

One of the reasons against including sum-of-parts terms is that they are counter-productive in defining the term by picking and choosing some of the senses of the component parts, thus under-emphasizing the other senses. Listing all possible combinations would cause too much duplication of information, which is bad for a number of reasons; for example, adding or modifying a sense of the component parts would require also adding or modifying one or more senses of the whole term as well. When we include sum-of-parts terms, we often try to make them sound more idiomatic by making the definition more specific than it needs to be.

On the other hand, there are many reasons to include some sum-of-parts terms:

  • They are defined in other dictionaries and/or people are likely to look them up: random number
  • They have useful translations into other languages: last year
  • They happen to be spelled as one word or have alternative spellings as one word: coal mine, unhelpful (un- + helpful)
  • They have unusual etymologies, pronunciations, or other useful information: (can't think of any at the moment, but I know they exist)
  • They are non-obvious in the encoding direction, even if they are obvious in the decoding direction: and so on and so forth

We have provisions, some of which are controversial, for keeping some of the types of words listed above, but not for all. We also have endless RFD debates about keeping words "outside of CFI".

I think a compromise is needed and I propose allowing the inclusion of some sum-of-parts terms that we decide would be useful to include, but without real definitions, similar to what we already do for translation targets. This can apply to terms included through WT:COALMINE, as well as simple cases of prefixes and suffixes, where a full definition has very little benefit over linking to the component parts. Here are some examples I created: User:Wikitiki89/coal mine, User:Wikitiki89/unhelpful, User:Wikitiki89/and so on and so forth.

--WikiTiki89 15:35, 24 July 2014 (UTC)

The problem I see with your example for "coal mine" is that it requires prior knowledge of the term to understand how to interpret the parts of the term. There is nothing in your entry that specifies that it's the sense "excavation" that is meant, rather than "explosive device". This is exactly why we need a full definition for it and other similar entries. If a term were truly SOP, then it could be validly be interpreted and used as any possible combination of its parts' meanings. But the reality is very different, such terms usually have much more restricted uses. —CodeCat 15:48, 24 July 2014 (UTC)
Another more general issue is that we seem to treat "idiomatic" and "SOP" as antonyms where they often are not. and so on and so forth is definitely idiomatic, even if it may also be interpretable as a sum of parts. Idiomatic phrases often translate into idioms in other languages, but we are sorely lacking translations for such terms thanks to our overly strict focus on deleting SOP terms. —CodeCat 15:50, 24 July 2014 (UTC)
But that's the thing about SOP, a "coal mine" could be an explosive device made of coal (also, as I said, we will only do this "where a full definition has very little benefit over linking to the component parts"). As to your second point, that is why I did not use the word "idiomatic" here. --WikiTiki89 15:54, 24 July 2014 (UTC)
I think we need to consider whether a term is a term of art in a specified field. For example, genuine issue of material fact is SoP to one who knows which senses of each term are intended, but is also a set phrase used in the law, and one that can not be substituted for other phrases. I think that if a general dictionary has a phrase, we should have it, and if a specialized dictionary (legal, medical, engineering, slang, etc.) has a term, then we should have it with the appropriate context label. Context labels go a long way towards eliminating the problem of "picking and choosing some of the senses of the component parts" because they indicate that when this phrase is used in this field it only refers to the specified senses of the words included. bd2412 T 15:59, 24 July 2014 (UTC)
That's the idea here: we will have the phrase, but we will link it to the component parts. Note that we can consider "material fact" to be one part rather than two, and possibly likewise for "genuine issue" if it is in fact a set phrase outside of this term. --WikiTiki89 16:03, 24 July 2014 (UTC)
For that example, I'm not aware of "genuine issue" being used outside the complete phrase. Our definition of genuine actually doesn't really capture the meaning used here (an actual controversy between the parties, rather than the facade of a controversy designed to test the law). It is sense 11 of issue. However, I generally think that a veneer definition requiring readers to look at two or three different entries to figure out the complete meaning of a term would be a needless inconvenience. bd2412 T 16:28, 24 July 2014 (UTC)
It's less of an inconvenience than the inconvenience of finding incomplete information presented as if it were complete. --WikiTiki89 16:32, 24 July 2014 (UTC)
That is where I think a context tag helps. If you are talking to a geologist or a civil engineer or a utility company about a coal mine, then there is only one relevant meaning, and the information presented is complete within that context. We could, for all of SoP definitions that are set phrases within a particular context, have an &lit sense, so that we can inform readers that when used other than in the sense of industry or geology, "coal mine" can mean any combination of coal and mine. bd2412 T 17:04, 24 July 2014 (UTC)
The word there is only one relevant definition of "mine" when talking to a geologist or civil engineer; this has nothing to do with the preceding word "coal". --WikiTiki89 17:22, 24 July 2014 (UTC)
Coal mine is a bad example for this point, since it only exists due to coalmine. If "coalmine" didn't exist, I would agree to deleting "coal mine" as readily as "copper mine" or "uranium mine". However, this principle is directly applicable to random number, which in the context of mathematics will never mean a "slapdash and seemingly directionless performance of a dance routine within a larger show". bd2412 T 13:24, 25 July 2014 (UTC)
That's one of my points. Since we are only including coal mine because of coalmine, it does not need a real definition, so we can just link to its parts. --WikiTiki89 13:29, 25 July 2014 (UTC)
Are we still going to have a complete definition at coalmine? I wouldn't object to coalmine being an "alternative spelling of" template and coal mine being bare links, but I don't think coalmine can be used to describe a military mine that runs on coal, so something would be getting lost in the sequence there. bd2412 T 15:16, 25 July 2014 (UTC)
I think there's a bit of a slippery slope here. Your test page decomposes "unhelpful" into [[un-]] + [[helpful]], but there's nothing stopping it from being decomposed into [[un-]] + [[help]] + [[-ful]]. Is [[electricity]] then SOP too, as [[electric]] + [[-ity]]? Is [[nothing]] just [[no]] + [[thing]]? Are full definitions only for monomorphemic words? —Aɴɢʀ (talk) 16:32, 24 July 2014 (UTC)
Most multimorphemic words are not simply SOP of their morphemes. Out of your examples, only [[nothing]] can actually be defined as just [[no]] + [[thing]], but then it is for us to decide whether it is beneficial to do so in each specific case. --WikiTiki89 16:37, 24 July 2014 (UTC)
I disagree that "nothing" is the only one that is SOP of its morphemes, but either way, I think it would create far too much work for us to decide on a case-by-case basis which polymorphemic words are SOP of their morphemes and which aren't. It's hard enough for us to decide that for multi-word expressions as it is. —Aɴɢʀ (talk) 17:20, 24 July 2014 (UTC)
There isn't much deciding to do. If the definition at the term is clearly equal to the component definitions, then you can replace it with a reference to each component. If someone later decides that that definition is inadequate, he could replace that with an adequate definition. No huge RFD discussions are even required. --WikiTiki89 17:26, 24 July 2014 (UTC)
@Wikitiki89: It can be used with that meaning, yes, but Wiktionary concerns itself only with attestable meanings. So the question we should be asking is: is it used with that meaning? Does coal mine ever mean "explosive device made of coal"? I would be very surprised if it did, precisely because its main sense "excavation for mining coal" is so much more common and using it in any other sense would cause confusion. So in reality, "coal mine" is much more restricted in meaning than its parts allow, which makes it idiomatic and hence includable per CFI. —CodeCat 17:17, 24 July 2014 (UTC)
It's probably possible to attest that meaning. --WikiTiki89 17:22, 24 July 2014 (UTC)
"Probably" isn't good enough for an RFV, though. If our current entry was like your proposal, I could validly RFV all senses that arise from the possible combinations of meanings of its parts. And many of them would likely fail, which would then mean we would have to put in a more specific, limiting definition. —CodeCat 10:17, 25 July 2014 (UTC)
If you want to find citations, I will. Anyway, something like "see coal, mine" (however we choose to format it) does not imply that all combinations exist, so it is not necessary to narrow it down. --WikiTiki89 10:57, 25 July 2014 (UTC)

My feeling about a set phrase is a bit like the US Supreme Court judge's feeling about hard-core pornography: I can't define it, but I know it when I see it. Some are little more than common collocations, but when they are common enough, especially within a particular field or arena, then to me they start to ‘feel’ like single concepts and not two concepts stuck together. This is unscientific but I'm just trying to explain my process. The CFI tests are good ways to check if something is a set phrase, but sometimes a term can fail all of them and still demand coverage (at least to my mind). DCDuring's ‘lemming test’ is, I think, valuable because it gives us a rationale without having to explain exactly why something should be kept. The weird thing is that when I first joined Wiktionary, I was a firm deletionist. I thought that entries like fried egg and Egyptian pyramid were a waste of time. But over the years I have slowly done almost a complete 180. My feelings in general now are that if there is a significant minority of people who see value in an entry, then we lose nothing by keeping it. Ƿidsiþ 16:58, 24 July 2014 (UTC)

The whole point of my proposal here is to allow us to keep these set phrases, without duplicating their wide range of definitions from the component parts. --WikiTiki89 17:02, 24 July 2014 (UTC)
I don't object to it on principle in some cases, though not necessarily routinely. There is also the issue that if a multi-word term has more than one meaning, we would presumably want to split the two senses so as to show quotation evidence for each one, and then you would have to write some kind of meaningful definition. Ƿidsiþ 17:14, 24 July 2014 (UTC)


Misspellings are recognised as lemmas by {{head}}, but that doesn't quite seem right. They have their own parts of speech of course, so they should probably use the normal POS categories and templates like {{en-noun}}. But I imagine some might object to this because they are supposedly not "proper". Recently I created rediculous, which is the spelling I normally use, and which is quite easily CFI-attestable. But I opted to call it an alternative spelling, because it didn't seem right to label a spelling I use normally a "mistake". So I have been wondering whether labelling things as "misspellings" does not go against the descriptivist philosophy of Wiktionary. What we really mean is that these spellings are commonly proscribed, but they are probably not considered misspellings by the people that use them. So what do other editors think of this situation? Should we categorise them simply as misspellings, or should we give the proper POS? And should we continue to label them as "misspellings" or change the wording to something more descriptive?

As a side note, the template {{misspelling of}} originally said common misspelling, but I removed this because it looked silly for entries like animalike. —CodeCat 10:25, 25 July 2014 (UTC)

Rediculous is certainly a misspelling. I think the criteria for that should have something to do with whether most people who use it would admit that it is a misspelling if shown the correct spelling. --WikiTiki89 11:02, 25 July 2014 (UTC)
Well that doesn't include me, because I think the spelling "rediculous" makes more sense. It better reflects how it's pronounced, and that's probably what all the other people think too. —CodeCat 11:04, 25 July 2014 (UTC)
I realize that it does not include you, but I do think that it includes most people. I also think that the main influence of this spelling is not the pronunciation, but the abundance of word initial re- compared to the relative rarity of ri-. --WikiTiki89 11:12, 25 July 2014 (UTC)
That's bizarre: "littel" (little) would make more sense for pronunciation, but everybody knows that's not how English spelling works. Which other words do you respell for this reason? Equinox 12:07, 25 July 2014 (UTC)
The difference is that it was not a conscious effort to change the spelling based on some reasoning. I just wasn't acutely aware of how other people spelled it, and I spelled it the way I figured it would make the most sense. It's only after I found out how people write it that I figured, my way is fine too. —CodeCat 12:11, 25 July 2014 (UTC)
As to the question of whether something we agree is a misspelling should count as a lemma. I would think the answer to that is simply NO.
Perhaps we need to also review items in our English alternative spellings categories to root out miscategorized entries. We serve users well by misleadingly characterizing common misspellings as alternates. After all we are supposed to only have common misspellings. AFACIT rediculous is not even a "common" misspelling. It occurs 3 times in BNC/COCA combined vs nearly 8,700 occurrences of ridiculous. Results are similar in Google Books and Google N-gram. DCDuring TALK 11:17, 25 July 2014 (UTC)
Why only common misspellings? Why not just any that are attestable per CFI? And why should misspellings not be lemmas? They have plurals and other inflections like any other lemma might have. —CodeCat 11:34, 25 July 2014 (UTC)
It has been our practice to do so because the number of attestable misspellings of common words probably exceeds by far the number uf axepted [spelins. DCDuring TALK 12:02, 25 July 2014 (UTC)
I do hope that reasoning distiguishes between accidental mistakes, deliberate respellings, and deliberate and consistent spelling variants that are intended as normal use. We should definitely have the latter no matter how common, per descriptivism. For the former two, I think a criterium for commonness is ok. —CodeCat 12:07, 25 July 2014 (UTC)
No it does not and should not. We are documenting the set of conventions called language. DCDuring TALK 12:12, 25 July 2014 (UTC)
That would make sense if everyone followed the same conventions, but clearly they don't. If labelling something a misspelling is a matter of one group disagreeing with another group about the spelling, then why can we not label things like color as misspellings? My point is just that: Wiktionary cannot and should not decide what is a misspelling, and clearly mispelling-ness is not strictly defined as there are varying opinions about it. So what I ask for is clear criteria, which are verifiable, that can be used to decide when the label "misspelling" should be used. If Wiktionary is descriptive (which it is), then a label like "misspelling" should describe some objective verifiable reality, not subjective opinion. —CodeCat 12:17, 25 July 2014 (UTC)
I completely agree with CodeCat here. There is a difference between a misspelling most likely caused by the writer's clumsy typing alone (e.g. typign), a misspelling caused by the writer most likely not knowing how to spell the word (e.g. independance), and a misspelling most likely caused by the writer's intentional choice to use a variant in order to achieve a literary effect like showing snarkiness or dialect (e.g. rediculous, "gawn to the sto'"). The only typo we should include is teh, because its commonness has turned it into a word intentionally used in jest. The second kind we should include if they are common enough that a reader would want them defined, so we can inform the reader in our definition that this is not the correct spelling. The third kind we should include if they are attested, because their specialized use makes them subtly different words in terms of the definition itself. bd2412 T 12:52, 25 July 2014 (UTC)
Yes but CodeCat isn't saying that exactly, he's saying he (or she, not sure) continues to use ‘rediculous’ because he thinks it's ‘more logical’ and therefore it shouldn't be called a misspelling. Ƿidsiþ 13:00, 25 July 2014 (UTC)
I mean to agree with CodeCat's comment immediately preceding my response. But his earlier point is also valid. Isn't that why we have thru and tho? bd2412 T 13:19, 25 July 2014 (UTC)
My objection concerning "rediculous" specifically is that it didn't seem like a misspelling to me, just an uncommon alternative spelling. The "misspelling" part lies only in the proscription against it. This is why I consider "misspelling of" to be equivalent to "(proscribed) alternative/rare spelling of". Whether something is a misspelling is subjective, but widespread proscription against a certain spelling is objective and can be verified at least in theory. Proscription can wane as forms become more accepted, and people will no longer consider them wrong. So I think we should replace "misspelling of" with something else that makes that more clear. Something like "proscribed spelling of" - this fits with how "(dated)" + "alternative spelling of" gives "dated spelling of" and similarly for other usage labels. —CodeCat 13:41, 25 July 2014 (UTC)
I would consider something an "alternative spelling" if a significant number of people believe that it is the correct spelling, even if others proscribe it. --WikiTiki89 13:43, 25 July 2014 (UTC)
Then what about {{rare spelling of}}? —CodeCat 13:48, 25 July 2014 (UTC)
I would consider that an equivalent of {{cx|rare}} {{alternative spelling of}}. If a spelling is considered by almost everyone to be a misspelling, then it we should label it as such. --WikiTiki89 13:53, 25 July 2014 (UTC)
Do you think there is a difference between {{context|proscribed}} {{alternative spelling of}} and {{misspelling of}}? —CodeCat 14:18, 25 July 2014 (UTC)
Yes, something can be proscribed by some people and accepted as correct by others. --WikiTiki89 14:24, 25 July 2014 (UTC)
Does that mean that to you, a misspelling is accepted by nobody? —CodeCat 15:01, 25 July 2014 (UTC)
By no significant group at least. Note that I'm saying what the intrinsic criteria are, even if it may be impossible for us to determine whether this is the case or not. --WikiTiki89 15:17, 25 July 2014 (UTC)

Use of babel templates from other wikis[edit]

I was going to create Category:User eml, but saw that it's based on a language code we don't recognize (it was split into egl and rgn). That led me to wonder why we had Category:User eml-3 and Category:User eml-N. It turns out that there are a couple of user pages that have {{#babel:it| which means they're using the Italian Wiki's babel system, which apparently recognizes some language codes we don't, and that this prompts User:Babel AutoCreate to re-create categories that we had deleted.

Is this ok, and, if not, what should we do about it? Chuck Entz (talk) 19:19, 25 July 2014 (UTC)

The script was actually blocked twice for creating categories like this, once by someone who though it was a bot and once by someone who seemed to think it was a live user. As I noted when I unblocked it, the solution that's most obvious to me is to salt the categories we don't want by protecting them such that only admins can re-create them. Alternatively, we could allow people to specify fluency even in things we don't consider languages, and specially categorise the categories, e.g. we could allow Category:User eml and put it in Category:User egl and Category:User rgn. - -sche (discuss) 20:15, 25 July 2014 (UTC)
We also ended up with Category:User simple, Category:Romany language, Category:Traditional Chinese language, Category:British English language and Category:Simplified Chinese language thanks to this script. The categories don't exist, but they do have entries in them. —CodeCat 20:46, 25 July 2014 (UTC)

br:Wikeriadur:Wikiakademiezh ca:Viccionari:La taverna co:Wikizziunariu:Cumunità cs:Wikislovník:Pod lípou cy:Wiciadur:Tafarn de:Wiktionary:Teestube eo:Vikivortaro:Diskutejo es:Wikcionario:Café fi:Wiktionary:Kahvihuone fr:Wiktionnaire:Wikidémie ga:Vicífhoclóir:Halla Baile gl:Wiktionary:Taberna he:ויקימילון:מזנון hi:विकिपीडिया:गाँव का पम्प hu:Wikiszótár:Társalgó id:Wiktionary:Warung Kopi is:Wikiorðabók:Potturinn it:Wikizionario:Bar ja:Wiktionary:居酒屋 ko:위키낱말사전:자유게시판 la:Victionarium:Taberna lt:Vikižodynas:Baras ms:Wiktionary:Kedai Kopi nl:WikiWoordenboek:De Kroeg no:Wiktionary:Tinget oc:Wikiccionari:La tavèrna pl:Wikisłownik:Bar pt:Wikcionário:Esplanada ru:Викисловарь:Организационные_вопросы scn:Wikizziunariu:Cìrculu sv:Wiktionary:Bybrunnen vec:Wikisionario:Ciàcołe vi:Wiktionary:Thảo luận vo:Vükivödabuk:Kafetar zh:Wiktionary:啤酒馆