Wiktionary

Wiktionary:Beer parlour/2015/November

< Wiktionary:Beer parlour

"Headword line" vote started edit

FYI: Wiktionary:Votes/pl-2015-10/Headword line started today. --Daniel Carrero (talk) 02:05, 1 November 2015 (UTC)[reply]

Renaming Wiktionary:Normalization of entries (WT:NORM) → Wiktionary:Entry source code (WT:ESC) edit

What do you think about renaming Wiktionary:Normalization of entries (WT:NORM) into Wiktionary:Entry source code (WT:ESC)? (while keeping the old name and shortcut as usable redirects, naturally)

The name would be more intuitive as to the actual purpose of the policy.

I apologize since I'm the one who had chosen the current name of the policy ("Normalization of entries") in the first place, based on that old discussion called "Normalization of articles". But I've been thinking a lot about this policy and I believe it would be an improvement for the reason above.

It would also match the name of the policy Wiktionary:Entry layout. (rather than "layout of entries")

Finally, the name "Normalization of entries" is unclear. Since Wiktionary:Entry layout, too, provides rules for "normalization" of "entries", the uninformed reader cannot tell at a glance why we have two different policies currently named as "Entry layout" and "Normalization of entries". If the names were "Entry layout" and "Entry source code", it would be easier to make that distinction. --Daniel Carrero (talk) 03:32, 1 November 2015 (UTC)[reply]

I think a better name would be Wiktionary:Wikicode normalization. —CodeCat 14:13, 1 November 2015 (UTC)[reply]
Between "Entry source code" and "Wikicode normalization", I prefer the former. As a secondary, not much important reason, the acronym WT:ESC looks nice. The main reason is this:
IMO, the word "Normalization" is superfluous in the same way that the word "explained" was superfluous in WT:ELE. You could have: Wiktionary:Normalization of entry layout, Wiktionary:Normalization of criteria for inclusion, Wiktionary:Normalization of blocking policy, Wiktionary:Normalization of page deletion guidelines and Normalization of bots. --Daniel Carrero (talk) 17:15, 1 November 2015 (UTC)[reply]
@CodeCat: That said above, I'm going to add "Wikicode normalization" in the proposal of my vote per your suggestion. I am going to oppose "Wikicode normalization", but I don't know what other people will vote. I'm going to use "WCN" as the proposed abbreviation, please edit the page or propose another one if you disagree with "WCN". --Daniel Carrero (talk) 17:20, 1 November 2015 (UTC)[reply]
The presence of source code in the name may scare non-programmers from reading it. — Ungoliant (falai) 17:34, 1 November 2015 (UTC)[reply]
What about Wiktionary:Wikicode style guide? --WikiTiki89 17:36, 1 November 2015 (UTC)[reply]
Excellent. I support that. — Ungoliant (falai) 17:38, 1 November 2015 (UTC)[reply]
Ungoliant's comment about scaring non-programmers is true, maybe the name really should have "wikicode" and not "source code". A few possibilities:
--Daniel Carrero (talk) 17:47, 1 November 2015 (UTC)[reply]
the hell is wikicode?--Dixtosa (talk) 18:53, 2 November 2015 (UTC)[reply]
@Dixtosa: w:Help:Wiki markup. --WikiTiki89 19:01, 2 November 2015 (UTC)[reply]
wikicode (currently a redlink) = wikitext (currently a bluelink) --Daniel Carrero (talk) 19:05, 2 November 2015 (UTC)[reply]
The chances of wikicode to be understood as related to language code is high. Lets stick to plain easy wt:norm which coincidentally has a good shortcut ?:/
Also, the Wikipedia's page on wiki markup mentions wikicode once for a reason. --Dixtosa (talk) 19:30, 2 November 2015 (UTC)[reply]
If we're going to use "wiki-[something]", "wikitext" seems both more common and 'friendlier' to a non-programmer than "wikicode". "Normalization of entries" does sound like it should be about rules on e.g. using accents vs macrons vs nothing for Old English vowel length. - -sche (discuss) 19:42, 2 November 2015 (UTC)[reply]
What about using "wiki markup" or "markup" in the policy name?
--Daniel Carrero (talk) 19:56, 2 November 2015 (UTC)[reply]
I like "Entry markup". "Wiki markup" sounds a bit like a how-to guide, how to use wiki markup. - -sche (discuss) 20:20, 2 November 2015 (UTC)[reply]

Created Wiktionary:Votes/pl-2015-11/NORM: 10 proposals edit

I created Wiktionary:Votes/pl-2015-11/NORM: 10 proposals.

This vote is larger than average, so I've set it up to start in 14 days and last for 2 months.

Feel free to discuss. --Daniel Carrero (talk) 07:21, 1 November 2015 (UTC)[reply]

I got these 10 proposals from CodeCat's reverted edits, from the Beer parlour, the NORM talk page and the NORM votes. The "Discussions" part of the vote should be able to link all the sources. --Daniel Carrero (talk) 03:01, 2 November 2015 (UTC)[reply]

Proposal: exclude non-printing characters, encoding variants of characters, and combining characters edit

Combining diacritics are really just variants of their non-combining equivalents. They are not lexicographically different characters. They also pose many technical problems because of how they are handled. Non-printing characters like control codes are also difficult to work with, and also have no lexicographical value since they do not appear in text by definition. We currently have some control codes as redirects, but these redirects are themselves inaccessible and can't be edited (not even by a bot, as I found). As for "encoding variants", I'm talking about things like Ⅽ versus C. These are the same character, merely encoded with different code points in Unicode and displayed a bit differently by the font. I think Ⅽ should redirect to C. —CodeCat 14:12, 1 November 2015 (UTC)[reply]

  Support Redirect Ⅽ ("Roman numeral" C), Ｃ ("Fullwidth" C) and probably others to C, then place a complete list of codepoints for varities of "C" on the main entry. --Daniel Carrero (talk) 16:49, 1 November 2015 (UTC)[reply]
Are you talking about entries for the individual characters only? Some languages need combining characters because they use unencoded character + diacritic combinations. — Ungoliant (falai) 17:37, 1 November 2015 (UTC)[reply]
Yes, just for the single characters. Links to combining characters go wrong in all kinds of ways, just try clicking on this link: ̅. —CodeCat 17:39, 1 November 2015 (UTC)[reply]

Context label "North America" edit

Currently, {{lb|en|North America}} produces the text (Canada, US). I think this is wrong. If someone puts "North America" as a context label, it should show up as (North America); if they wanted to say "Canada, US", they would have. --WikiTiki89 16:36, 1 November 2015 (UTC)[reply]

It would be quite funny is {{lb|en|UK}} produced (England, Northern Ireland, Scotland, Wales). Seriously though, Wikitiki89 is right. Renard Migrant (talk) 23:53, 1 November 2015 (UTC)[reply]
I agree. This generates wrong information when, i.e., used in a sense is used in Mexican and US Spanish. — Ungoliant (falai) 00:01, 2 November 2015 (UTC)[reply]
The behaviour was implemented because template was being used as a shorthand for "Canada, US" in French and English entries, and it was agreed that it was bad to split and have only some entries in "Category:Canadian English"+"Category:American English" while others were in "Category:North American English". I oppose going back to "North American" and splitting the entries up again. Deprecating the label altogether and making bot or AWB runs periodically to clean up uses could work. - -sche (discuss) 01:15, 2 November 2015 (UTC)[reply]
I would be against a bot cleaning these things up. We could automatically put anything tagged with "North American" into all three categories. Either that or have "US" and "Canada" also put words into "North American English". If this is a categorization issue, it should be solved with categorization. --WikiTiki89 16:54, 2 November 2015 (UTC)[reply]

Changes to Template:votes edit

Template:votes has been recently edited to cause the enddate in past votes to be formatted yellow, and some icons have been added to past votes and votes near the enddate.

IMO it would look better without the icons. If there's no support for the icons, I request them to be removed.

Also, I don't know if the yellow text should stay. Making a distinction for past votes could be useful, and I know yellow text in this case means "past vote", but this meaning is not intuitive. Sometimes, a vote past the enddate remains open for voting because nobody closed it yet, so red text would still be appropriate and yellow text would be misleading. --Daniel Carrero (talk) 17:05, 1 November 2015 (UTC)[reply]

I agree, the icons should be removed. Perhaps the past votes should be red and the "ending soon" votes should be yellow? We would also need to use a darker yellow so that the date is actually readable on a white background. --WikiTiki89 17:14, 1 November 2015 (UTC)[reply]
I prefer to keep the icons. —CodeCat 17:40, 1 November 2015 (UTC)[reply]
The icons are too distracting. I went ahead and removed them and made the color scheme more intuitive. Now, votes ending soon will be orange, votes ending today will be red, and votes that have already ended will be gray. --WikiTiki89 18:41, 2 November 2015 (UTC)[reply]

Separate, simplified pages for letters edit

I suggest moving all the definitions of letters into separate, simplified pages to try and fix the problem of cluttered letter pages.

For instance, Letter:D or Appendix:Letters/D could have the following contents. I didn't take the trouble to link all the letters of the alphabet to other pages, but in the end they should be linked.

 
Capital and lowercase versions of D, in normal and italic type.

D uppercase, d lowercase

English: 4th letter. Name: dee.
  • Aa, Bb, Cc, Dd, Ee, Ff, Gg, Hh, Ii, Jj, Kk, Ll, Mm, Nn, Oo, Pp, Qq, Rr, Ss, Tt, Uu, Vv, Ww, Xx, Yy, Zz
Esperanto: 5th letter. Name: do.
  • Aa, Bb, Cc, Ĉĉ, Dd, Ee, Ff, Gg, Ĝĝ, Hh, Ĥĥ, Ii, Jj, Ĵĵ, Kk, Ll, Mm, Nn, Oo, Pp, Rr, Ss, Ŝŝ, Tt, Uu, Ŭŭ, Vv, Zz
Finnish: 4th letter. Name: dee.
  • Aa, Bb, Cc, Dd, Ee, Ff, Gg, Hh, Ii, Jj, Kk, Ll, Mm, Nn, Oo, Pp, Qq, Rr, Ss, Šš, Tt, Uu, Vv, Ww, Xx, Yy, Zz, Žž, Åå, Ää, Öö
Latvian: 6th letter. Name: dē
  • Aa, Āā, Bb, Cc, Čč, Dd, Ee, Ēē, Ff, Gg, Ģģ, Hh, Ii, Īī, Jj, Kk, Ķķ, Ll, Ļļ, Mm, Nn, Ņņ, Oo, Pp, Rr, Ss, Šš, Tt, Uu, Ūū, Vv, Zz, Žž
Portuguese: 4th letter. Name: dê.
  • Aa, Bb, Cc, Dd, Ee, Ff, Gg, Hh, Ii, Jj, Kk, Ll, Mm, Nn, Oo, Pp, Qq, Rr, Ss, Tt, Uu, Vv, Ww, Xx, Yy, Zz
Spanish: 4th letter. Name: de.
  • Aa, Bb, Cc, Dd, Ee, Ff, Gg, Hh, Ii, Jj, Kk, Ll, Mm, Nn, Ññ, Oo, Pp, Qq, Rr, Ss, Tt, Uu, Vv, Ww, Xx, Yy, Zz
Turkish: 5th letter. Name: de.
  • Aa, Bb, Cc, Çç, Dd, Ee, Ff, Gg, Ğğ, Hh, Iı, İi, Jj, Kk, Ll, Mm, Nn, Oo, Öö, Pp, Rr, Ss, Şş, Tt, Uu, Üü, Vv, Yy, Zz

Thoughts? I've added an image for neatness, it would be optional. --Daniel Carrero (talk) 02:26, 2 November 2015 (UTC)[reply]

I’d rather see appendices for every letter in a given language rather than the opposite (otherwise a page like Appendix:Letters/D will eventually end up having thousands of entries), but I support anything that stops them from cluttering the entries of real words. — Ungoliant (falai) 02:31, 2 November 2015 (UTC)[reply]
PS: with the exception of translingual. — Ungoliant (falai) 02:31, 2 November 2015 (UTC)[reply]
Perhaps we could keep the Translingual letter definition in all entries, and link the Translingual definitions to the separate pages like Letter:D or Appendix:Letters/D. --Daniel Carrero (talk) 02:35, 2 November 2015 (UTC)[reply]
I think it's a great idea! It would certainly clean up the letter entries. Aryamanarora (talk) 12:42, 2 November 2015 (UTC)[reply]
I prefer Ungoliant's approach, with per-language pages rather than per-letter pages. We should include links to all of these pages, or a category containing them, in the Translingual section. —CodeCat 17:23, 2 November 2015 (UTC)[reply]
Ungoliant is right that per-letter appendices won't reduce clutter (they will themselves become crowded), so per-language appendices seem better. I would definitely keep translingual sections on all of the letters, from which to link to the per-language appendices. (I would also include a ===See also=== link to a language's appendix any time we happened to have an entry for a single-letter word in that language, e.g. a#English, n#Aromanian, e#Hungarian.) - -sche (discuss) 17:58, 2 November 2015 (UTC)[reply]
Will, for instance, the entry Ğ link only to alphabet appendices that use that letter, or will it link to the full list of alphabet appendices?
Is there going to be some way to know what are the alphabets that use Ğ? Or Ñ? --Daniel Carrero (talk) 18:06, 2 November 2015 (UTC)[reply]
If we decide to link to individual appendices, then presumably Ğ#Translingual will link only to the appendices of languages that use Ğ. But then whatever section we put the links in (say, ===See also===) could easily grow to contain a hundred lines, and have to be updated any time a new appendix was created... we're probably better categorizing the appendices and then linking from entries to the category, an idea CodeCat mentioned above. Per-language appendices would allow us to give pronunciations / notes on orthography, letter names, etc... perhaps, especially for the many small languages where the info is just "the Foobarese alphabet is ABCD...YZ", the appendices could just be the WT:About X appendices. - -sche (discuss) 19:46, 2 November 2015 (UTC)[reply]
We could also put each language's appendix in a category for each character it uses, then on the entry for a, we could a put an {{also}} link to Category:Languages that use the character "a". --WikiTiki89 20:42, 2 November 2015 (UTC)[reply]
That sounds like the most workable solution. —CodeCat 21:03, 2 November 2015 (UTC)[reply]
But the English alphabet has 26 letters, from A to Z, so the categories would look like this:
Categories: Languages that use the character "a" | Languages that use the character "b" | Languages that use the character "c" | Languages that use the character "d" | Languages that use the character "e" | Languages that use the character "f" | Languages that use the character "g" | Languages that use the character "h" | Languages that use the character "i" | Languages that use the character "j" | Languages that use the character "k" | Languages that use the character "l" | Languages that use the character "m" | Languages that use the character "n" | Languages that use the character "o" | Languages that use the character "p" | Languages that use the character "q" | Languages that use the character "r" | Languages that use the character "s" | Languages that use the character "t" | Languages that use the character "u" | Languages that use the character "v" | Languages that use the character "w" | Languages that use the character "x" | Languages that use the character "y" | Languages that use the character "z"
That is too long, and also a bit hard to find the right letter inside that wall of text. Couldn't we use just Category:A, Category:B, etc. as the category names? That way, the categories would be:
Categories: A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
--Daniel Carrero (talk) 21:39, 2 November 2015 (UTC)[reply]
Well the point is more that at each letter in the mainspace, there will be a link to just one category. They aren't intended to all be listed on each language's page. Of course this long list will appear on the bottom of the page, but that's not really a big deal. Maybe we should make them hidden categories? --WikiTiki89 03:27, 3 November 2015 (UTC)[reply]
But if we move all the letter definitions into individual language appendices like Appendix:Letters/French, then the categorization above would apply to the appendix, right? --Daniel Carrero (talk) 05:07, 3 November 2015 (UTC)[reply]
But also I don't see anything wrong with the single-letter category names either. --WikiTiki89 03:29, 3 November 2015 (UTC)[reply]

Suppose we create a simple appendix for all the letters in a single language.

Appendix:Letters/English could have:

Alphabet

Aa, Bb, Cc, Dd, Ee, Ff, Gg, Hh, Ii, Jj, Kk, Ll, Mm, Nn, Oo, Pp, Qq, Rr, Ss, Tt, Uu, Vv, Ww, Xx, Yy, Zz

Letter names

a, bee, cee, dee, e, ef, gee, aitch, i, jay, kay, el, em, en, o, pee, cue, ar, ess, tee, u, vee, double-u, ex, wye, zee/zed

A few questions and comments:

  1. Or should we use a table format?
  2. Should the appendix include IPA pronunciations? Sound files too?
  3. We already have a number of randomly-formatted alphabet appendices like Appendix:Mapudungun alphabet, Appendix:Polish alphabet and Appendix:Polish alphabet. Can all the appendices follow the same format?
  4. Appendix:Latvian alphabet has long texts with information and Appendix:English alphabet has a list of letters using certain ligatures, do we need all that in the appendices? I'd rather each alphabet appendix was basically just a simple, standardized list of letters. I mean, Wikipedia has w:English alphabet to fill with lots of historical information and we already have categories for words in English spelled with the ligatures.
  5. Suppose the appendix could be called any of those: Appendix:English letters, Appendix:English alphabet, Appendix:Letters/English, Appendix:Alphabet/English... But the words "Letters" and "Alphabet" don't apply to all languages, do they? What about Persian, Korean, Chinese, etc.? Is there a more comprehensive name for all writing systems? Appendix:Writing/English or Appendix:Characters/English, maybe?

--Daniel Carrero (talk) 05:48, 3 November 2015 (UTC)[reply]

Several issues with the categorisation of placenames edit

I’ve recently finished going through Portuguese-language toponyms, and in the process I came across several inconsistencies, issues and uncertainties in our category scheme:

— Ungoliant (falai) 19:41, 2 November 2015 (UTC)[reply]

All of these are good points and I support fixing it up. —CodeCat 19:52, 2 November 2015 (UTC)[reply]
Yes, merge same-level subdivisions (so, Category:en:Provinces and territories of Canada; and merge Category:en:Autonomous oblasts of Russia into Category:en:Oblasts of Russia).
Yes, towns should also be categorized by country if cities are, and given that the distinction may be nebulous for many countries, or that inconsistent metrics may apply between countries, it may be best to lump them all into one category.
"State capitals of the United States", maybe?
Cities in the Crimea could go into both Ukrainian and Russian categories. (How do we handle cities in Palestine/Israel? In the Golan Heights?)
Modern usage is "in Ukraine" and we lemmatize [[Ukraine]], so let's be modern in the categories, too.
- -sche (discuss) 20:18, 2 November 2015 (UTC)[reply]
Russia also has krais, okrugs, autonomous okrugs and federal cities. I was hoping we could pick a name that encompasses all of them (Federal units of Russia?) — Ungoliant (falai) 20:21, 2 November 2015 (UTC)[reply]
In any case, I’ll have to start RFM discussions. I’m just checking if there is support for the general idea that there should be a single category for all subdivisions of a given country. — Ungoliant (falai) 20:27, 2 November 2015 (UTC)[reply]
(Two edit conflicts later) Be careful about cleaning them up: "States" and "Territories" in Australia are two different things in both law and common speech. Victoria, New South Wales and South Australia are states, Northern Territory, Australian Capital Territory are not states. (Although, to be extra confusing, there has been talk of promoting Northern Territory to statehood, but possibly keeping the name "Northern Territory".) --Catsidhe (verba, facta) 20:22, 2 November 2015 (UTC)[reply]
@Ungoliant MMDCCLXIV Just a note, you should check Special:WantedCategories, as there are a bunch of Portuguese-related place name categories that need to be created. Benwing2 (talk) 22:02, 2 November 2015 (UTC)[reply]
Perhaps we ought to make a project or appendix page of possibly difficult-to-categorize place names or types of place names. DCDuring TALK 17:00, 3 November 2015 (UTC)[reply]
  • Comment on a few of these:
  1. The oblast category you mention is in a gots-to-go situation; I'll even nominate it for deletion myself
  2. I don't really see the need to combine Canadian provinces and territories (or Australian states and territories). If we do, the resulting category, likely titled Category:en:Provinces and territories of Canada, would a) contain two different types of political entities, and b) be a longer title than the existing categories.
  3. Nothing "hideous" about Category:US State Capitals. a) There should be a category containing the 50 items currently in this category, and b) that's the shortest way to unambiguously title said category.

I would remind people that moving a category or template is not an action to be taken lightly; we've been a little too cavalier about it in the past. Purplebackpack89 21:16, 4 November 2015 (UTC)[reply]

Script appendices edit

FYI: I populated Category:Script appendices with the help of a new template {{script appendix}}, added at the top of the appendix to generate the introduction and standardize the categories. I renamed some pages from "Appendix: X alphabet" into "Appendix:X script" for consistency with category names. Feel free to discuss. --Daniel Carrero (talk) 04:54, 3 November 2015 (UTC)[reply]

Written-out fractions edit

Pursuant to the discussion at Wiktionary:Requests for deletion#three quarters, I would like to propose the inclusion of a specific, limited set of eighteen written-out fractions (counting fourths and quarters as the same fraction). The reasons that I propose this particular set are as follows:

  1. These are probably the most common fractions in use (particularly given the tendency to use fifths in parliamentary procedure, and to divide inches into eighths for measurement).
  2. All of these are fractions for which the numerical form is available in Unicode, particularly ½, ⅓, ⅔, ⅕, ¼, ¾, ⅖, ⅗, ⅘, ⅙, ⅚, ⅛, ⅜, ⅝, ⅞, ⅐, ⅑, and ⅒ (See Appendix:Unicode/Number Forms). If we have the Unicode form, we should have the written out form as an alternate spelling.
  3. I do not know if these exist as single-word forms in other languages, but I would not be at all surprised if at least some of them do, given their commonality.

The fractions I propose to include are in two groups:

Singular fractions from one half through one tenth:

Multiple fractions for thirds, fourths, fifths, sixths, and eighths:

I note that "one tenth" is often used in an idiomatic sense of asserting that person a is "not one tenth the man" (or other property) as person b. I also propose adding the hyphenated form of each as an adjective form (one-half, one-third, etc.). If we can agree on this specific set of eighteen fractions, that will set both the floor and a ceiling on the written-out fractions that can be included in Wiktionary. Cheers! bd2412 T 14:20, 3 November 2015 (UTC)[reply]

  • Go for it! By the way, is "three fourths" the US usage? It seems very strange to UK ears. SemperBlotto (talk) 14:34, 3 November 2015 (UTC)[reply]
  • Done with the basic entries. Hyphenated forms and translations will follow. Cheers! bd2412 T 21:03, 3 November 2015 (UTC)[reply]
  • Re: "the inclusion of a specific, limited set of eighteen written-out fractions" There is, of course, no reason to keep all of these if they are challenged in RfD and no reason to exclude any that are attestable if we decide that such fractions are, in general, to be excluded. It would be bad precedent to make some kind of exception to our policies without a vote.
An alternative would be for each language's (or group of languages') fraction-naming system to be documented in an appendix with redirects from attestable forms that someone finds necessary to add. DCDuring TALK 13:32, 4 November 2015 (UTC)[reply]
  • As noted above, these happen to be the 18 fractions for which Unicode versions of the numerical forms exist. I think, actually, that this speaks volumes about the set. They are, at least, alternative spellings to entries that we already have due to the inclusion of the Unicode forms. Arguably, we could have a few more fractions if they were particularly significant, like twenty-two sevenths (which is approximate pi), but I think that either the addition of any more or the exclusion of any of the above would be difficult to justify. I note that "one tenth" gets twenty times as many Google Books hits as "one eleventh", and (with the exception of the unusually popular "one twelfth") would presume the trend continues in that way. Of course, I have no objection to an appendix documenting fraction naming systems. However, we have many appendices that collect information that is also reflected in individual entries, a luxury that we have the storage space to afford. bd2412 T 16:02, 6 November 2015 (UTC)[reply]

Wiktionary-l mailing list edit

Hi everyone, I'm unsure if this is the correct board for this (if not, please do move it). The wiktionary-l mailing list[1] has not had active list administrators it seems and during a migration, we had to clear out a lot of emails form the list unfortunately (possibly legitimate ones). As such, we're asking for someone to take over the list so emails sent to the mailing list are moderated and handled within an appropriate time-frame. A phabricator bug[2] is open for this. Interest can be shown either here or there - both places will be monitored. If there is no interest shown by Friday, I will close the list as inactive and it can be re-opened in future if the community want it.

Thanks, John F. Lewis (talk) 16:47, 3 November 2015 (UTC)[reply]

I don't think any regular Wiktionarians still use that mailing list. We have a small community compared to en.Wikipedia, and we tend to communicate on-wiki or by direct e-mails. - -sche (discuss) 19:36, 6 November 2015 (UTC)[reply]
I didn't even know we had a mailing list. --WikiTiki89 19:54, 6 November 2015 (UTC)[reply]
Hypothetically, I believe it's supposed to encourage communication and cooperation between the various Wiktionaries, but that doesn't happen much in any case. I see no problem in letting it die. —Μετάknowledgediscuss/deeds 17:35, 7 November 2015 (UTC)[reply]

About the "Entry name section" vote edit

Wiktionary:Votes/pl-2015-10/Entry name section is scheduled to start in 7 days. (it was going to start in 2 days but I delayed the start a bit)

As some people know, the vote introduces an expanded "Entry name" section in the WT:EL.

Some changes to the proposed text have already been made based on suggestions in the talk page. Please review and see if you disagree with anything in the proposed text. I suggest making any changes before the vote starts, especially if it can avoid possible opposing votes in the future.

If there's any piece of text that's controversial or unwanted by some people, I'd rather cut that out and vote about the rest, so that it can be further discussed/voted later. --Daniel Carrero (talk) 23:15, 3 November 2015 (UTC)[reply]

Proposal: Add a text box to give a search term for "terms starting with" in categories edit

Currently, we have table-of-contents templates for a few languages, which let you click on letters to skip to that letter in the category. But this system is wholly inadequate for a dictionary. A paper dictionary lets you skip quickly to a particular term, often using indexing terms that appear at the top of the page. For example, a paper dictionary might show that a pair of pages includes terms ordered alphabetically between "lazy" and "lecture". Something like this is sorely needed for our categories, which are currently pretty much unsearchable. The only thing you can do is manually edit the URL to skip to a particular term, there's nothing on the page itself allowing for this, other than the aforementioned TOC templates. So I think that there should be a text box which lets you say "show me terms starting alphabetically from here".

A difficulty is that I have no idea how this might be implemented. The InputBox extension only has a fixed set of things it can do, and setting the start of a category listing isn't one of them. —CodeCat 15:45, 4 November 2015 (UTC)[reply]

  Support It seems like we could do it fairly easily with JavaScript, but I really hope we can do it without JavaScript. Maybe we should ask the developers? --WikiTiki89 15:58, 4 November 2015 (UTC)[reply]
I wouldn't count on them too much. We've been waiting for years to have custom category collation orders implemented, but it's still not done. —CodeCat 15:59, 4 November 2015 (UTC)[reply]
German Wiktionary has been there, done that. See de:Kategorie:Aragonesisch for an example. We could take their script, examine it and take the good parts. It is also a good idea to show the range for a category... --Dixtosa (talk) 16:17, 4 November 2015 (UTC)[reply]
Perfect example of why I would prefer doing this without JavaScript. The text box only loads sometimes and I have to refresh the page. --WikiTiki89 16:28, 4 November 2015 (UTC)[reply]
Only loads sometimes? Hows that? Your javascript engine is stochastic? You must be using IE. --Dixtosa (talk) 16:53, 4 November 2015 (UTC)[reply]
I often have issues with scripts not working. Sometimes the buttons to expand inflection tables and translation tables go missing. —CodeCat 16:57, 4 November 2015 (UTC)[reply]
Nope, Chrome. Sometimes JS fails to load due to faulty internet connections, sometimes it fails to run because of random JS errors. JS always has lots of problems on all browsers. --WikiTiki89 18:56, 4 November 2015 (UTC)[reply]
Yes, something along these lines would be good. Equinox ◑ 16:45, 4 November 2015 (UTC)[reply]
  •   Support, and consider similar measures for ending with and containing. Purplebackpack89 21:10, 4 November 2015 (UTC)[reply]
    I think "starting with" is the best we can do for now, it's the only thing that the software supports in the URL. I'd love it if categories could be dynamically sorted, either ascending or descending, and from beginning to end or end to beginning. Sorting by the end of the word is very useful especially for suffixes. —CodeCat 21:40, 4 November 2015 (UTC)[reply]

Name of the namespace for reconstructed terms edit

As the vote on whether to create a dedicated namespace for reconstructed terms is nearly over is will in all probability pass, I would like to draw attention to the poll on the vote's discussion page regarding the name of the namespace. If you have not voted and have an opinion, please do so at Wiktionary talk:Votes/2015-09/Creating a namespace for reconstructed terms#What should we name the namespace?. --WikiTiki89 21:17, 4 November 2015 (UTC)[reply]

Deleting trademark categories? edit

These categories have been emptied and deleted in 2014 with the text "empty category; should stay empty per WT:TM":

Some terms which pertained to these categories in the past: Durex, Air France, Skidoo, Spezi, Pampers, Pepsi and Coca-Cola.

But these categories still exist:

Should all trademarks categories be emptied and deleted because of WT:TM? --Daniel Carrero (talk) 09:33, 5 November 2015 (UTC)[reply]

  • I could see us having categories for words originating as trademarks - but we should not be in the business of maintaining the current trademark status of words. If this is all these categories do, they should be dispensed with. bd2412 T 14:05, 5 November 2015 (UTC)[reply]
Consider moving the trademark info to the entries' etymology sections, rather than just wiping the category out entirely. Equinox ◑ 15:39, 5 November 2015 (UTC)[reply]
I agree with BD, delete these categories: I have been deleting them, per WT:TM and the discussions which preceded it, in which a representative of the WMF legal team participated and it was concluded that current legal/trademark status should not be noted. For entries which originated as trademarks, that lexical information should be noted in the etymology, as Equinox says. - -sche (discuss) 21:34, 6 November 2015 (UTC)[reply]
They look of marginal utility, and there is a horrendous ambiguity in the titles chosen: does "English trademark" mean a trademark registered in England, or one registered anywhere(?) which happens to look like an English word? Similarly "Japanese trademarks" fits beautifully with the conception of the world in which countries and languages are the same thing, but not with the real one. Imaginatorium (talk) 08:26, 3 January 2016 (UTC)[reply]

All entries ending in -sman edit

Would it possible to find all English entries ending in -sman (-swoman, -speople, -sfolk...)? I think that most of these are really -s- + man, and I'd like to correct the etymologies (although of course not all of them are (talisman, chessman, hillsman are not) so an automatic change would be inappropriate). Smurrayinchester (talk) 16:17, 6 November 2015 (UTC)[reply]

Also, -shead, -sfoot and -stail. Smurrayinchester (talk) 16:20, 6 November 2015 (UTC)[reply]
I've always wished there was a Special:SuffixIndex like the existing Special:PrefixIndex. --WikiTiki89 16:24, 6 November 2015 (UTC)[reply]
I wish Special:PrefixIndex had a different name, since you can put any string there regardless of whether it's a prefix or not. And I also really wish Wiktionary had some functionality as a language-specific reverse dictionary. —Aɴɢʀ (talk) 18:34, 6 November 2015 (UTC)[reply]
They could call it Special:YouWillNeverGuessWhatThisDoes for all I care as long as we have the functionality. --WikiTiki89 20:04, 6 November 2015 (UTC)[reply]
Today I 've requested the permission to use WM databases on wmflabs. If they grant me a membership, that functionality is going to be a piece of cake.--Dixtosa (talk) 21:00, 6 November 2015 (UTC)[reply]
It would be preferable to add that functionality to individual categories, rather than to all pages on a Wiki. Then you could apply it to subsets of words, like English nouns alone. This was mentioned on the Grease Pit a few days ago too. —CodeCat 21:02, 6 November 2015 (UTC)[reply]
Which option is preferable depends on what you're using it for. --WikiTiki89 21:22, 6 November 2015 (UTC)[reply]
@Smurrayinchester User:DTLHS/sman DTLHS (talk) 19:52, 6 November 2015 (UTC)[reply]
Wow, thank you! Smurrayinchester (talk) 19:58, 6 November 2015 (UTC)[reply]
Cannot this be done using the DynamicPageList extension, which creates list of articles based on their category membership? - Amgine/ t·e 22:49, 18 November 2015 (UTC)[reply]

Formatting of ellipses to indicate elisions in attestations edit

Apologies if I've asked this in the wrong place, I'm still learning my way around Wiktionary.

I noticed that in egg on, where part of the passage in the attestation from In the South Seas was omitted, the periods in the ellipsis are spaced out . . . like so. I know that the English Wikipedia's Manual of Style prefers unspaced ... ellipses (and gives several reasons why), but I couldn't find the equivalent style guide for Wiktionary. Is there a preference here, and if so, where would I find it? —GrammarFascist (talk) 19:36, 6 November 2015 (UTC)[reply]

We have the template {{...}}, which seems to be a good way of achieving uniformity. —Aɴɢʀ (talk) 19:40, 6 November 2015 (UTC)[reply]
Thanks, Aɴɢʀ! Template applied, looks great. —GrammarFascist (talk) 22:25, 8 November 2015 (UTC)[reply]

Expanding on WT:COALMINE edit

Right now, WT:CFI has the following text: "Unidiomatic terms made up of multiple words are included if they are significantly more common than single-word spellings that meet criteria for inclusion". The canonical example is that coal mine is allowed because coalmine is. But I think the phrasing here misses the point of what it really should convey, which I think is:

If there is a lemma, of which at least one of the alternative forms is includable under the idiomaticity criterium, then all of them should be considered includable under that criterium.

The idea here is that idiomaticity shouldn't depend on orthographic representation, so if a form has different spellings, it makes sense to treat the collection of them as idiomatic if at least one of them is. Should CFI be modified to this effect? It would have the consequence of removing the "significantly more common" part, meaning that if coalmine were the most common form, then coal mine, being an alternative form of it, should also be includable. —CodeCat 00:48, 7 November 2015 (UTC)[reply]

Wouldn't that mean that coalmine would not be includable, since "coal mine" isn't idiomatic? DTLHS (talk) 01:08, 7 November 2015 (UTC)[reply]
No, it would work in both directions. coalmine is idiomatic, therefore all alternative forms of it are also includable, coal mine too. So it only expands on what's includable, it doesn't remove anything that's includable now. —CodeCat 01:10, 7 November 2015 (UTC)[reply]
  •   Support We need to expand CFI. CFI as it's written is too restrictive and is costing us readers. Purplebackpack89 02:11, 7 November 2015 (UTC)[reply]
    @Purplebackpack89 Any evidence that CFI "is costing us readers"? DCDuring TALK 03:58, 7 November 2015 (UTC)[reply]
    @DCDuring The way I figure it, people come to an online dictionary to learn the meaning of a particular word. If that particular word isn't on Wiktionary, they go someplace else for that word...and there's a strong chance they never come back to Wiktionary. If we don't have entries people are looking for, particularly if other dictionaries have them, we will lose readers. And we know that we're not the most-read online dictionary. Purplebackpack89 13:57, 7 November 2015 (UTC)[reply]
    @Purplebackpack89 I get the argument, but I'd like some evidence to support your bold, unqualified presentation of a theory as a fact. I wonder if it isn't this and other violations of Gricean maxims that makes so many of your contributions to talk pages so irritating to me. DCDuring TALK 02:06, 8 November 2015 (UTC)[reply]
    @DCDuring
    1. Did you read what I wrote below about readership?
    2. Do you have any evidence to contradict my theory? (Because I seriously doubt you do) Purplebackpack89 02:55, 8 November 2015 (UTC)[reply]
    He also doesn't have evidence to contradict any theory that the readers are Presbyterians who like to take long walks. And you don't have any evidence for the assumptions that you're using to derive your theory. It may make perfect sense to you, but it has no more to back it up than an out-and-out assertion. Chuck Entz (talk) 03:51, 8 November 2015 (UTC)[reply]
    Same with DCDuring's theory, if he has one. The bottomline, @DCDuring @Chuck Entz is:
    1. What words we have and what words we don't should be based on how our readers think, but
    2. We don't know how our readers think

Purplebackpack89 04:08, 8 November 2015 (UTC)[reply]

To recap history: The COALMINE vote was based on one of the set of Pawley criteria that in his opinion supported finding an MWE idiomatic. We made it a sufficient criterion to eliminate some of the more pointless debates about inclusion, without regard to occasional instances of what might be considered errors of inclusion. It has succeeded in this regard, IMO.
I'd be a bit concerned that such very rare alternative forms like cole mine might be deemed includable should they be found attested. Making them automatically includable seems like another invitation to obsessive compulsive would-be contributors to add valueless bulk to Wiktionary. DCDuring TALK 13:06, 7 November 2015 (UTC)[reply]
If cole mine meets CFI (at least three attestations from independent sources over the space of more than a year) I see no reason not to include it. We're not paper, and our usefulness is not determined by dividing the number of valuable entries by the number of total entries. —Aɴɢʀ (talk) 13:50, 7 November 2015 (UTC)[reply]
Can you give an example of something that would be included under this rule but not under the current WT:COALMINE? I lean towards oppose for the same reasons as Dan. On WT:RFD Dixtosa suggested that free throw percentage met COALMINE because of FT%, which Wikitiki noted (and I agree) is not the case. (A lot of unidiomatic phrases have abbreviations.) Btw, if something like this is added, I suggest rephrasing to "...at least one of the alternative forms meets the idiomaticity criterion, then of them should be considered to meet that criterion" (the term may still not be "includable", if it fails to meet other criteria). - -sche (discuss) 20:41, 7 November 2015 (UTC)[reply]
FWIW, @-sche, I think we need to explore having a CFI that allows us to include phrases, such as free throw percentage, that are commonly abbreviated. It seems odd that there are many instances where an abbreviation can be included, but the thing it's abbreviating can't. IMO both should be included. Would what you are suggesting achieve that? Purplebackpack89 20:56, 7 November 2015 (UTC)[reply]
As I said above, that would give us entries like I am not a lawyer and deformities, contusions, abrasions, punctures / penetrations, burns, lacerations, swelling, tenderness, instability, and crepitus. Would the extra effort it would take to verify these terms, clean and maintain them, and find some way to define them in a useful but non-encyclopedic way be the best way to spend our (often busy and rather tetchy) volunteers' time? Smurrayinchester (talk) 22:02, 7 November 2015 (UTC)[reply]
If people want to spend their time that way, they should be allowed to. It's not like expanding CFI automatically means a lot of work for all concerned. It doesn't mean people automatically have to go out and create entries; rather, they are allowed to do it at whatever pace they want. And if your question is "does it improve the project to have those entries", IMO it does. As I said above, we lose editors who are looking for things like "I am not a lawyer" and can't find it. Purplebackpack89 23:31, 7 November 2015 (UTC)[reply]
How do you know we lose them, or that people want to look up full sentences? DCDuring asked for evidence and you seemed to dodge the question. Equinox ◑ 23:32, 7 November 2015 (UTC)[reply]
How do you know we don't, Equinox? Follow my logic here: UrbanDictionary has more readers than we do. However, UrbanDictionary has (on average) lower-quality entries than we do. If UrbanDictionary has lower-quality entries than we do, how come they have more readers? The answer seems to me to be because UrbanDictionary has entries for words and phrases we don't, in particular whole-phrase and whole-sentence entries. And the conclusion from this seems to be that a lot of editorsreaders value quantity over quality; they would rather have a bad entry than no entry at all. Purplebackpack89 23:40, 7 November 2015 (UTC)[reply]
You have no logic. Because we value quantity over quality we aren't including more phrases? And the entire reason that urban dictionary has more users than us is because they have a CFI, nevermind the host of other reasons that that could be the case? It couldn't be that urban dictionary was designed from the ground up to actually be usable, as opposed to trying to shoehorn a dictionary into software that was designed for creating an encylopedia. That would be crazy. DTLHS (talk) 23:58, 7 November 2015 (UTC)[reply]
'Cuse me, did I say editors? I meant readers. Also, I think you have us and UD mixed up, we have a CFI and they don't. Also, I'm not sure I blame the lack of success of this project as being too much like Wikipedia; if anything, I think we're not enough like Wikipedia. After all, Wikipedia is like Wikipedia and they're viewed more than UD. I'd also reiterate that CFI is something that makes us less usable. @DTLHS, it's never made sense to me that somehow we'd have more readers with fewer entries, at least not at the point in the project we are now. Worry only about quality at this point in our project will not get us increased readership, or increased editorship. Purplebackpack89 00:06, 8 November 2015 (UTC)[reply]
Statistics just tell you how many people visit either site, not why they go there. UD gets a lot of its readers by being outrageous, provocative, and entertaining. People make up words and definitions there for the fun of it, or for the attention, and that's more entertaining than information about plain old ordinary usage.
We may be losing readers of the same sort as the TV viewers that watch car chases and reality shows, but that's unavoidable if you want to be a reference work that focuses on accuracy and reliability- and I, for one, don't miss them. Chuck Entz (talk) 01:45, 8 November 2015 (UTC)[reply]
I fully agree with Chuck. I like us to be sensitive to serious learners at virtually any level, but not to those whom we often end up blocking as vandals because they insert UD-quality entries and definitions. DCDuring TALK 01:59, 8 November 2015 (UTC)[reply]
OK, where's the evidence that most of the people who choose to read (yes, read, not edit) UD over Wiktionary are sensationalist vandals? That seems like a quite extraordinary claim, much more so than the claims I've advanced in this thread. Do you really believe that there's no middle ground between sensationalist vandals and you yourself, i.e. are there not people who don't create or read the most questionable of UD entries, but would like to see more two-word entries at Wiktionary, because they don't know what those words mean and would like to? Also, your attitude toward UD-but-not-Wiktionary users is quite elitist...it seems you want a well-written dictionary, and you care not if anybody reads it. Isn't having a well-written dictionary pointless if nobody reads it? Purplebackpack89 04:08, 8 November 2015 (UTC)[reply]
It looks to me like he was referring to a certain group of undesirable editors as an example of the sort of user he wouldn't be concerned with losing, not making blanket assertions about everybody. At any rate, the answer is, as usual, somewhere in between: if we try to be just like Urban Dictionary, we'll lose out to them, anyway, since they're better at being Urban Dictionary than we are. Even if we are losing some readers, we're also retaining some who would be turned off by lowered standards and/or pandering to Urban Dictionary constituencies. I also question how many people would be looking up "I am not a lawyer" that would be satisfied with a wordier paraphrase as a definition- after all, the best definition of "I am not a lawyer" is "literally: 'I am not a lawyer'". A lot of our proverb entries have this problem: the proverb is usually the most concise and efficient way to express the idea, so the definition tends to be much more wordy and technical-sounding, often to the point of being unreadable sludge. Chuck Entz (talk) 04:47, 8 November 2015 (UTC)[reply]
I think you and DC overestimate the amount of people who prefer no definition to a poor definition, and underestimate those who prefer a poor definition to no definition. Again, I say, "If there are so many people who care about quality of definitions out there, then why do more people use UD than us?" I don't think that UD's success can be explained away by its different format (which, IMO, is MORE confusing than ours) or by the fact that some of its entries are jocular. A great deal of it has to be due to its lack of an arbitrary, overly-strict CFI. Purplebackpack89 05:16, 8 November 2015 (UTC)[reply]
Also, on your I am not a lawyer argument, I'm looking at CFI/RFD from a different angle than you are. You look at the things you think we don't need and say CFI is fine. I look at the things we've deleted or come way too close to deleting (television show was deleted for over a year, field goal percentage will probably get deleted next week) and am appalled. And if you think I'm pushing for lots and lots of bad definitions that have to be kept, remember that we'll still have RFV. Purplebackpack89 12:04, 8 November 2015 (UTC)[reply]
COALMINE aside, I agree that “idiomaticity shouldn't depend on orthographic representation”. Our non-following of this idea leads to some problems:
  • words written without a space are considered idiomatic by default. While this works well enough for English (with some caveats), it falls short for languages with more rigid orthographic standards, such as German (compounds written together, no matter how unidiomatic), Spanish (clitic pronouns written together), Latin (-que) as well as for ancient languages that used scriptio continua.
  • words that would otherwise be citable fail RFV. I specifically remember two cases: years ago I was trying to find citations for Copenhagenisation/-ization, I found that one spelling had one cite and the other had two; the other case was a slang two-word compound for clitoris that was being RFVed (I don’t remember the exact word), I found two citations using XY, two using X-Y and two using X Y. The word failed RFV because each spelling had fewer than three cites, even though the word itself had 6.
About Urban Dictionary: even if Wiktionary had a readership of zero, that would be a situation preferable to becoming more like UD. They can market themselves however they like, but UD is as much a dictionary as a porn website is an educational website about anatomy. — Ungoliant (falai) 18:16, 8 November 2015 (UTC)[reply]
If Wiktionary's readership is zero, we've all wasted our time. And there are definitions on UD that not only could easily pass RfD and RfV, they are better-worded than some of the definitions we have. People around here paint UD with far too broad a brush. Purplebackpack89 23:33, 8 November 2015 (UTC)[reply]
Talk:gaplapper is similar to what you're talking about. - -sche (discuss) 07:04, 9 November 2015 (UTC)[reply]
Can't support the proposal in its current form. There have been too many counter examples given to the proposed rule, such as "free throw percentage", "cole mine", DCAPBLSTIC, and the lawyer one. Perhaps CFI could be expanded in a similar but more restrictive way to the proposal, such as by explicitly excluding acronym expansions and very rare forms (or making them case-by-case), but there clearly is far from unanimous support for their inclusion. Also, I would not be sad if no one ever engaged in a back-and-forth about what is or is not "costing us readers" ever again. Please just stop. —Pengo (talk) 07:19, 9 November 2015 (UTC)[reply]
I didn't read this proposal as including acronym forms. bd2412 T 15:00, 9 November 2015 (UTC)[reply]
Pengo, it's important to have a strong theoretical basis when voting in proposals like these. There's nothing wrong with saying you want policy changed to increase readership; there's nothing really wrong with saying you want policy changed to increase quality either. Purplebackpack89 15:34, 9 November 2015 (UTC)[reply]
  Oppose since we do not have a clear definition of "alternative form" and this would then lead to the inclusion of all kinds of things that should not be included. --WikiTiki89 15:03, 9 November 2015 (UTC)[reply]
@Wikitiki89, your comments beg the questions "what things shouldn't be included", and "why shouldn't they?" Purplebackpack89 15:34, 9 November 2015 (UTC)[reply]

Terms with audio links and IPA pronunciation -- where should they go in the category tree? edit

There are now two category types, e.g. Category:Russian terms with audio links and Category:Russian terms with IPA pronunciation, that are currently placed under "entry maintenance" , but this doesn't seem right, since that mostly concerns mistakes that ought to be corrected. Where should they go? Should we create a new category tree section for pronunciation? Benwing2 (talk) 07:36, 8 November 2015 (UTC)[reply]

Are phrases not listed in lemmas? edit

Most categories are listed under lemmas, but I can't find one for phrases. Are they hidden somewhere? [3] Donnanz (talk) 13:16, 8 November 2015 (UTC)[reply]

Added. — Ungoliant (falai) 17:58, 8 November 2015 (UTC)[reply]
Thanks a lot. It only appears in the "subcategories" list though, and not in the list at the top. I checked English lemmas as well. Donnanz (talk) 21:08, 8 November 2015 (UTC)[reply]

Community Wishlist Survey edit

Hi everyone!

The Community Tech team at the Wikimedia Foundation is focused on building improved curation and moderation tools for experienced Wikimedia contributors. We're now starting a Community Wishlist Survey to find the most useful projects that we can work on.

For phase 1 of the survey, we're inviting all active contributors to submit brief proposals, explaining the project that you'd like us to work on, and why it's important. Phase 1 will last for 2 weeks. In phase 2, we'll ask you to vote on the proposals. Afterwards, we'll analyze the top 10 proposals and create a prioritized wishlist.

While most of this process will be conducted in English, we're inviting people from any Wikimedia wiki to submit proposals. We'll also invite volunteer translators to help translate proposals into English.

Your proposal should include: the problem that you want to solve, who would benefit, and a proposed solution, if you have one. You can submit your proposal on the Community Wishlist Survey page, using the entry field and the big blue button. We will be accepting proposals for 2 weeks, ending on November 23.

We're looking forward to hearing your ideas!

MediaWiki message delivery (talk) 21:30, 9 November 2015 (UTC)[reply]

Proposal: Disallow votes to be created by someone who intends to vote oppose edit

Wiktionary:Votes/pl-2015-07/Nesting inflected form definition lines was created by User:Dan Polansky who immediately voted oppose. Although he claimed that "the supporters were given enough time to tweak the vote", the vote was not crafted in a way that enough editors would have supported it. Several of the voters who voted oppose or abstain expressed that they would have supported a similar but less restrictive vote. Thus, the measure was not given a fair chance at succeeding. Therefore, I would like to propose that votes must be written by an editor or editors who intend to support the vote and thus should be willing to put enough effort into its phrasing to make it passable. --WikiTiki89 22:35, 9 November 2015 (UTC)[reply]

I wonder whether there is any precedent in real-world political systems for banning this kind of voting strategy. Equinox ◑ 22:38, 9 November 2015 (UTC)[reply]
Long ago when I was in Middle School, we were voting for class representatives and one student asked if they were allowed to vote for themselves. The teacher replied that on the contrary if they do not vote for themselves then they should not be running. I'm sure someone more into politics than I am would be able to give more concrete examples from real politics. --WikiTiki89 22:51, 9 November 2015 (UTC)[reply]
  • This is votes only? It doesn't apply to RfDs and RfVs? Purplebackpack89 23:05, 9 November 2015 (UTC)[reply]
    Votes only. We already have a similar unofficial policy at RFD that you should not nominate something you intend to vote keep for (of course you're allowed to change your mind after the fact); and there is no voting involved at RFV. --WikiTiki89 23:11, 9 November 2015 (UTC)[reply]
    And we don't enforce it lol. I've seen a number of "courtesy" or "administrative" RfDs and RfVs that were filled out by editors after somebody tagged an entry for RfD or RfV but never filled out the RfD or RfV. Purplebackpack89 23:14, 9 November 2015 (UTC)[reply]
    That's different, because whoever tagged the entry is effectively the one nominating it. But this discussion is not meant to concern RFD, so let's please stay on topic. --WikiTiki89 23:16, 9 November 2015 (UTC)[reply]
    • People raise Rf[DV]s all the time because they honestly don't think a term is attest(ed|able), but are giving people a chance to prove them wrong. Indeed, that's kind of the whole point of them. This proposal, on the other hand... I can see the point being made, that people shouldn't raise a vote in order to make it fail in order to create a precedent they like, or to make a political point, or to grief their opponents. (The Australian Republican Referendum comes to mind, where exactly that happened: it was set up by people who wanted it to fail, in such a way to force it to fail, when most people actually supported the idea.) But then, making the legality of a proposal dependant on the intent of the proposer is a really, really bad idea. Because then we'll get counter-griefers claiming that "the proposer wasn't doing this in good faith: this vote is void" if it looks like going against them. Will you nullify a vote if the proposer didn't write it well enough? If they don't defend it well enough? (How do you decide "enough"?) If they change their mind? --Catsidhe (verba, facta) 23:19, 9 November 2015 (UTC)[reply]
      • This rule does not have to affect the outcome of votes. We can start with having this be an unenforceable, but official, request to anyone creating a vote. If it remains a problem we can discuss how we can penalize creators of such votes. Keep in mind though, I am not assuming any ill-will on the part of creators of such votes. Even if they have good intentions, they do not have the same incentives to make reasonable proposals or compromises. --WikiTiki89 00:11, 10 November 2015 (UTC)[reply]
I agree it is problematic, but I'm opposed to making a hard rule against it. What if the proposer changes his or her mind? What if the proposal is simply written in the negative saying we "shouldn't" do something, either because it makes sense to do so or to avoid this rule? What if the question is very simple and already discussed elsewhere? I think it might make a good guideline to suggest proponents of a change be the one to put it forward, as should have been done in this case, but I don't think it would make sense to make a hard rule about it without some very careful consideration. Pengo (talk) 01:40, 10 November 2015 (UTC)[reply]
Where did I say above that the proposer can't change his mind? --WikiTiki89 01:57, 10 November 2015 (UTC)[reply]
@Wikitiki89: If the proposer can change their mind, then they can get around this rule by proposing something, saying they're supporting it, and then changing their mind shortly afterwards. It might seem silly, but it demonstrates a problem with this rule. Pengo (talk) 09:32, 11 November 2015 (UTC)[reply]
That's assuming bad faith on the part of the proposer. I don't see it as a huge problem, since most editors involved in votes generally act in good faith. --WikiTiki89 15:24, 11 November 2015 (UTC)[reply]
I think it's worrisome, but I don't know if it's really a big deal. The current vote in question makes the criteria rather narrow, yes, but that means the opposition votes are equally narrow in scope. As it stands now, we could just change the separator in the template from ; to something else, to comply with the vote. The vote outcome only indicate that people don't want the particular combination Dan proposed, but it says nothing about any others. —CodeCat 01:53, 10 November 2015 (UTC)[reply]
It wastes people's time and it misleads people who look back at it in the future. It's better to have the supporters craft a better proposal to begin with. --WikiTiki89 01:57, 10 November 2015 (UTC)[reply]
  • This is a generally good idea, but it could be abused if made a rule. I think at present we really only have one editor who does this, and making legislation against him individually is absurdly heavy-handed. But as an informal expectation, I agree that I'd prefer if all editors were to avoid doing this. —Μετάknowledgediscuss/deeds 04:19, 10 November 2015 (UTC)[reply]
  • I naturally oppose that "votes must be written by an editor or editors who intend to support the vote". I have never intentionally made a bad wording for a vote. Actually, specific defects in the wordings that I have created have not been stated, only that, in principle, as an opposer, I have an objectively existing interest in creating a bad wording. People can still create other votes, with their preferred wording. Even now. They can make wording improvements. By creating votes for CodeCat's proposals and for CodeCat's undiscussed (not even proposed) changes visible in the mainspace, I make sure non-consensual volume changes by CodeCat are limited at least to an extent. Wiktionary:Votes/pl-2015-07/Nesting inflected form definition lines is a great example of such a vote; I did not really expect so many opposes, and we how have clear objective evidence of the scope of support for that proposal. CodeCat proceeded to make changes anyway, e.g. in diff, evidence of the need to determine the scope of support in a transparent manner enabled by the vote. By the way, I support to use my continuing extension algorithm on Wiktionary:Votes/pl-2015-07/Nesting inflected form definition lines to give it a chance rather than closing it as failed. --Dan Polansky (talk) 09:11, 14 November 2015 (UTC)[reply]
    @Dan Polansky: Of you course you wouldn't intentionally provide bad wording for a vote. My whole point is that if you don't support the vote, then you are not in a good position to provide the best wording. Even unintentionally, your wording will most likely be worse. --WikiTiki89 16:08, 14 November 2015 (UTC)[reply]
    @Wikitiki89: "your wording will most likely be worse": I don't think that to be true. My wording can turn out to be worse, but not "most likely". Whether my wording will be better depends not only on my potential bias but also on my drafting skills. For the discussed vote, no specific proposal of alternative wording has been made. We really have no tangible material or evidence to support the hypothesis that I create poorly drafted votes that fail not because of lack of support but rather because of poor drafting. In fact, Wiktionary:Votes/pl-2015-08/Templatizing usage examples looks like passing despite my opposition. --Dan Polansky (talk) 16:26, 14 November 2015 (UTC)[reply]
    @Dan Polansky: Good point about Wiktionary:Votes/pl-2015-08/Templatizing usage examples, it does look passable.
    That said, I am worried about the "Nested inflection lines" vote. I am inclined to agree with @Wikitiki89 on the statement: "My whole point is that if you don't support the vote, then you are not in a good position to provide the best wording." At diff, Dan Polansky argued that the supporters had enough time to improve the vote but they failed to do so. I think this further proves Wikitiki89's point: If someone is planning to create a vote with the intention of opposing it, then help from supporters of the vote is a requirement, otherwise it is likely that the vote is not going to have the best wording.
    Suggestion: @Dan Polansky, if you want to create a vote with the intention of preventing something to happen, IMO it would be okay being straightforward and proposing just that. See example below.
    "Voting on:
    • Disallowing the mass creation of nested inflected forms, until clear consensus is reached on the acceptance of nested inflected forms, and also what exactly should be the wikicode for that, and what exactly should appear on the entries as a result."
    I think this way you could express your points of view more clearly and openly. The fact that you oppose edits being done en masse without consensus would be the real rationale for the creation of your vote, which you could further elaborate in your words, as you have done to justify the votes you created with the intention of voting oppose. --Daniel Carrero (talk) 16:50, 14 November 2015 (UTC)[reply]
    • That is not an acceptable proposal. The whole point is that I do not need consensus to prevent non-consensual changes. The person making a volume deviation from status quo ante needs to gain consensus. When that person does not create the required vote, and does not provide wording input to a vote created by someone else, I end up with little option left other than creating a vote that I oppose. The proposal plays into CodeCat's non-consensual-volume-change cards in ways that really make it not workable, and that contradict the consensus principle. --Dan Polansky (talk) 16:57, 14 November 2015 (UTC)[reply]
    • Another thing is that if none of the supporters are willing to draft a vote themselves, then the vote is unlikely to have enough supporters to pass. If a vote is unlikely to pass, then it is a waste of time. I also agree with Daniel Carrero that a potential solution is to reword the vote in the negative. A negative vote that passes is entirely different from a positive vote that fails (and vice versa). --WikiTiki89 16:58, 14 November 2015 (UTC)[reply]
    Let me register my disappointment with the lack of disciplinary action against CodeCat, for the likes of diff. Under the regular circumstances of the rule by consensus, there really would be no need for me to create such votes. The votes are a slightly unusual measure to deal with the problem of non-consensual volume changes that for some reason that I do not know have not been deal with by the bureaucrats and admins. I believe CodeCat's actions exeplified by diff generally constitute a blockable offence. --Dan Polansky (talk) 09:15, 14 November 2015 (UTC)[reply]
  • Let me note that the wording is not so narrow as CodeCat above suggested. The specific wikicode format is not part of the voted proposal, since the vote text says "possibly like" before it gives the example, emphasis on "possibly". What was part of the proposal was "creating the new formatting by means of a single template invocation instead of multiple ones as before". --Dan Polansky (talk) 10:06, 14 November 2015 (UTC)[reply]
  • I don't think we need to ban this. Discourage is using dialogue, sure, outright ban, no. Renard Migrant (talk) 16:55, 14 November 2015 (UTC)[reply]

Closing RfDs...we need floors edit

At present, we have no floors for when an RfD is closed. I'd like to propose the following:

  • If there are three votes of unanimous opinion, or five votes of unanimous opinion with only one dissent, the RfD can be closed immediately.
  • If an RfD has gone on at least a week and has at least five votes, it may be closed if 65% or more of the votes are of the same opinion
  • Any RfD can be closed after a month, regardless of the number of votes or how the votes are distributed.

Of course, we could go longer if we wanted, but we wouldn't have to. This would have the added benefit of de-cluttering RfD of discussions that haven't been commented on in months, or have clear outcomes. Purplebackpack89 23:41, 9 November 2015 (UTC)[reply]

Oppose. People commenting on RFDs should be encouraged to take their time to analyse the situation and form an opinion. I mean, it’s one thing to try to speed up the bureaucracy, but your suggestions (especially the first one) will mean that a discussion can be closed within minutes of being opened, or after a new point is posted. The practical result of this is that people will tend to rush to a conclusion and skip careful reading and research. — Ungoliant (falai) 00:02, 10 November 2015 (UTC)[reply]
Ungoliant, would you like me to up the number of votes on the first one, or the percentage on the second? Also, I doubt that the result of this will be lots of deletion discussions being closed very quickly...after all, half of deletion discussions don't even get five votes in the first week. If a discussion is 5-0 or 5-1 one way, is it likely to go the other way? No! For one, you'd need about 13-14 total votes to get them to go the other way, and 80-90% of the RfDs on this project don't even have ten votes. There's no point in prolonging the inevitable. Purplebackpack89 00:08, 10 November 2015 (UTC)[reply]
Furthermore, the "careful reading and research" should take place before a person votes, so if something is closed quickly, it's because the people who voted came to a decision to vote quickly. And in many RfD cases, people can and do vote quickly, because questions of "research" generally end up at RfV rather than RfD. Purplebackpack89 00:14, 10 November 2015 (UTC)[reply]
It’s no wonder you think that, since rushing to a conclusion and skipping careful reading and research is what you already do anyway. — Ungoliant (falai) 00:16, 10 November 2015 (UTC)[reply]
Oppose. I would favor a rule stating that an RFD discussion cannot be closed if there has been a new vote or a new contribution to the discussion (barring filibustering) in the past seven days. --WikiTiki89 00:25, 10 November 2015 (UTC)[reply]
But, Wikitiki, that means that if seven people vote delete on an article in the first 72 hours, you still can't close it until a week after the last vote. Why is it so necessary that a discussion be dead for a week? Isn't how long the discussion is open more relevant then how long it's dead? Purplebackpack89 00:29, 10 November 2015 (UTC)[reply]
Partly to make sure you don't get a team of editors to quickly put in seven delete votes, close the discussion, and delete the entry before anyone else notices. If it's been dead for a weak, there is a good chance no one else has anything to say. --WikiTiki89 00:32, 10 November 2015 (UTC)[reply]
Wikitiki, that particular example ignores the practicalities of the situation: a) Seven votes will carry the vast, vast majority of RfD discussions, regardless of length; b) considering the make-up of RfD participants, a team of seven editors is bound to include a sysop who could delete the entry whenever anyway. Purplebackpack89 00:38, 10 November 2015 (UTC)[reply]
It's better to be on the safe side. It's not harmful to let a 7-0 lead sit there for a week. It is, however, harmful if the discussion is closed before someone who wanted to vote got a chance to. Keep in mind also that the ratio of votes also matters, there is a significant difference between a word deleted 7-3 from one deleted 10-0. --WikiTiki89 00:44, 10 November 2015 (UTC)[reply]
That's why you let them run a week unless there's a huge pile-on consensus. The way to make sure people have time to vote is to let it run a week, not let it be dead a week. Purplebackpack89 01:03, 10 November 2015 (UTC)[reply]
But you also have to give people who already voted a chance to read any new information or arguments and rethink their position. --WikiTiki89 01:35, 10 November 2015 (UTC)[reply]
Also, per DCDuring, this is a solution in search of a problem. ‑‑ Eiríkr Útlendi │Tala við mig 18:17, 10 November 2015 (UTC)[reply]

WT:RFM#Continuation of #Category:en:Names into Category:English names edit

I'm notifying users of this discussion, since it's not so trivial and needs input from many people. —CodeCat 00:48, 10 November 2015 (UTC)[reply]

German "du contractions" (haste, fährste...) edit

What should we do about colloquial German contractions like hast du > haste, where the sound of the "du" gets lost in the "-st" and the whole thing is reduced to a schwa? It's a fairly universal process, but of course it can only occur with verbs that used in a colloquial context so not all -ste forms will be attested. I've added a sense at haste, and created a page at fährste, but I'd like to get some opinions from other German editors about how far to go and how to format the entries before rolling this out any further. Smurrayinchester (talk) 10:42, 10 November 2015 (UTC)[reply]

Yiddish has a similar problem האָסט דו (host du) > האָסטו (hostu). We have an entry for the suffix ־ו (-u) itself, but I don't really think it is worth creating an entry for each verb with this suffix. --WikiTiki89 16:05, 10 November 2015 (UTC)[reply]
Brabantian Dutch also has this contraction, though it's etymologically different (it's the 2nd person plural in origin). I think there should be entries for them if they are attested. —CodeCat 18:42, 10 November 2015 (UTC)[reply]
Maybe also to consider: es contractions, like geht es -> geht's or gehts. -84.161.30.148 19:13, 10 November 2015 (UTC)[reply]

Wikimania 2016 scholarships ambassadors needed edit

Hello! Wikimania 2016 scholarships will soon be open; by the end of the week we'll form the committee and we need your help, see Scholarship committee for details.

If you want to carefully review nearly a thousand applications in January, you might be a perfect committee member. Otherwise, you can volunteer as "ambassador": you will observe all the committee activities, ensure that people from your language or project manage to apply for a scholarship, translate scholarship applications written in your language to English and so on. Ambassadors are allowed to ask for a scholarship, unlike committee members.

Wikimania 2016 scholarships subteam 10:47, 10 November 2015 (UTC)

Wiktionary:Votes/pl-2015-10/Entry name section - started edit

FYI: Wiktionary:Votes/pl-2015-10/Entry name section started today. --Daniel Carrero (talk) 03:42, 11 November 2015 (UTC)[reply]

I looked through it. It looks mostly like formalizing existing practice. Is there anything controversial or anything being proposed that isn't existing practice? Benwing2 (talk) 04:58, 11 November 2015 (UTC)[reply]
You're right, that was what I had in mind when creating the vote: it's about formalizing existing practice. I believe there's nothing controversial there; also, I'm not proposing anything new. --Daniel Carrero (talk) 05:41, 11 November 2015 (UTC)[reply]

rfi categories edit

I edited {{rfi}} to allow categorization into language-specific categories.

But there are 6,597 entries using {{rfi}} without a language code. Those entries are currently categorized in Category:Entries needing images by language. Can a bot add the language code to all entries, please? Thank you. --Daniel Carrero (talk) 00:13, 12 November 2015 (UTC)[reply]

P.S.: This template has lots of redirects: {{reqphoto}}, {{Reqphoto}}, {{rfimage}}, {{rfdrawing}} and {{rfphoto}}. If a bot can add the language code to all these entries as I requested, I also suggest changing all these to {{rfi}} for consistency. --Daniel Carrero (talk) 00:55, 12 November 2015 (UTC)[reply]
Why is it important that these are categorized by language? An image doesn't have any intrinsic language (unless it contains text). DTLHS (talk) 01:01, 12 November 2015 (UTC)[reply]
I'm with DTLHS. Somethings, adding language codes to templates is more trouble than it's worth. Particularly in this case since pictures can be used in any language. Purplebackpack89 01:07, 12 November 2015 (UTC)[reply]
If we had some Commons-image-mining tools AND Commons had some data that indicated the language a diagram was worded in or the language of text appearing in a photo, then the language code might be useful. Until both conditions are met the language code seems useless. By the time those conditions are met the language code may seem like a quaint relic. DCDuring TALK 02:40, 12 November 2015 (UTC)[reply]
An image doesn't have an intrinsic language, but they sections they appear in do. These requests aren't independent of the language sections they appear in. Renard Migrant (talk) 17:59, 12 November 2015 (UTC)[reply]
One image may contain text in multiple languages, or other complicated scenarios (e.g. a sign that happens to say the same thing in two local languages, so isn't clearly either of them). This feels like categorisation for the sake of it. Equinox ◑ 18:00, 12 November 2015 (UTC)[reply]
This isn't about what languages are in the image, but whether an editor has the knowledge to judge whether an image is fitting for a given word. —CodeCat 18:10, 12 November 2015 (UTC)[reply]
  • I'm having some difficulty understanding how the language code would help in any specific current situation. Are there some specific examples of how this would help? DCDuring TALK 19:27, 12 November 2015 (UTC)[reply]
    • Would you trust yourself in adding images to random words in, say, Finnish? What about a rare language like Ainu? If you didn't speak the language, how would you know the image was appropriate? —CodeCat 22:02, 12 November 2015 (UTC)[reply]
      • Also, if the Finnish entries needing images were grouped together, they would draw the attention of Finnish editors. I could try improving our Portuguese entries by adding images to Portuguese entries needing them, but out current list of entries needing images is mostly a mess of Translingual taxonomic names. --Daniel Carrero (talk) 22:21, 12 November 2015 (UTC)[reply]
      • If the English gloss were accurate, I would. If the gloss were a polysemic English word or an obsolete, archaic, or rare word, I would not make the assumption that the gloss is accurate. Similarly if there were grammar mistakes or poor diction in the English gloss. If our English glosses are of such unreliable quality that these screens are not sufficient, then obviously I should not trust myself. Are these screens insufficient?
      • I look forward to the increased efforts to add images to FL L2 sections that will be unleashed by this categorization. I would have looked forward even more to improvement of the reliable quality of English glosses of FL entries. DCDuring TALK 23:42, 12 November 2015 (UTC)[reply]
        • If you don't speak the language, it's hard to get an idea of the "real" meaning of a word, even with an accurate definition. Therefore, some who is familiar with the language would be able to choose are more fitting image. --WikiTiki89 23:51, 12 November 2015 (UTC)[reply]
          A bad image could even give the wrong impression about the meaning. —CodeCat 23:54, 12 November 2015 (UTC)[reply]
          Also, a native speaker of Finnish navigating Category:Finnish entries needing images would understand most if not all the contents of the category just by looking at the entries listed. She could say: "I don't believe they don't have an image for (thing) yet!"
          With all the 6,500+ requests lumped together, one has to ignore the words in languages they don't know. (The alternative of looking for an English gloss is being discussed above and I don't have anything to add.) I, for one, don't speak Finnish. --Daniel Carrero (talk) 13:24, 13 November 2015 (UTC)[reply]

Wiktionary:Votes/2015-11/Language-specific rfi categories --Daniel Carrero (talk) 14:23, 26 November 2015 (UTC)[reply]

Appendix:Article 1 of the Universal Declaration of Human Rights edit

I just made this - what do you all think? It would certainly be interesting to see how many translations we can get. Aryamanarora (talk) 02:24, 12 November 2015 (UTC)[reply]

Sources I have ported over versions from Wikimedia Foundation projects. Many more can be found here: http://omniglot.com/udhr/. Can these be imported? —Justin (koavf)❤T☮C☺M☯ 03:04, 12 November 2015 (UTC)[reply]
Why can we not just leave these on Wikisource? Do they need to be here? —CodeCat 03:12, 12 November 2015 (UTC)[reply]
Yes, leave them where they are. I don't see that they have any function here. SemperBlotto (talk) 08:57, 12 November 2015 (UTC)[reply]
I agree with CodeCat and SemperBlotto. Wikisource already has the declaration in many languages. English: Universal Declaration of Human Rights, French: Déclaration universelle des Droits de l’Homme. I see no reason why anyone would look for that information here to begin with. --Daniel Carrero (talk) 09:03, 12 November 2015 (UTC)[reply]
RFD it is then! Renard Migrant (talk) 17:57, 12 November 2015 (UTC)[reply]
I'm also not quite sure why we need this. But I did fix some errors in it. --WikiTiki89 18:19, 12 November 2015 (UTC)[reply]
I agree. Doesn't make sense as an appendix to a dictionary. Equinox ◑ 18:26, 12 November 2015 (UTC)[reply]
Incidentally, the Even-Shoshan Dictionary of Hebrew does have the Israeli Declaration of Independence in the back. Although, since it is given in two side-by-side versions one with vowel points and the other in plene spelling, it is probably just there to illustrate the differences between vocalized and plene writing. --WikiTiki89 18:34, 12 November 2015 (UTC)[reply]
Deleted. - -sche (discuss) 21:01, 12 November 2015 (UTC)[reply]

Unnormalized Old French forms edit

I'm starting to get interested in facsimiles of the original manuscripts. It's occurred to me dictionaries (that I know of) don't cover manuscript forms and it could be something we do as a USP. If you don't know the basics of French spelling you might not want to read any further. Anyway. A good starting point would be Talk:aprés where the Old French section was unilaterally removed in 2010 because Old French doesn't have an acute accent.

It does and it doesn't; scholars seem to universally use é to represent /e/ at the end of the word or when the penultimate letter and the final letter is s. I'd argue that these forms are both real and Old French. I have at least four books from my university study that I could use as evidence and take pictures of if anyone wants me to. Also on Google Books

There seem to be no other accents that are consistently used. For example you can find seürté here (a third of the way down, use Ctrl + F) but Godefroy lists it as seurté as does the Anglo-Norman On-Line Hub. Other than that, you do get the odd transcription using à and the odd one using grave accents, but these are rare.

So, does anyone have an opinion on the following? I've been updating WT:About Old French but it feels odd doing it on my own. The options I see are allow, disallow and either list as alternative forms but don't create or list in alternative forms without links (just plain text, no square brackets)

  • No acute accents: seurte for seurté (which we list as seürté)
  • No capital letters: france for France
  • No cedillas: francois for françois (you can see francoise here, second word of the second line in black)
  • u/v distinction: they're visually the same but I think they're worth keeping as separate letters like we do in Latin. For example trouve appears visually as trouue (modern trouve, verb form) but I think they're really separate letters that share a glyph. This comment added 21:31, 12 November 2015 (UTC) Renard Migrant (talk)

How about alternative normalizations:

  • Allow diaereses: traïson for traison (the diaeresis here is to show it's three syllables and not two.)
  • à for a (occasionally used for the same reasons modern French has à and là. But I can't remember where I saw it. I think it was in a modern print Wace)

Renard Migrant (talk) 18:29, 12 November 2015 (UTC)[reply]

Perhaps we can use a Latin-like system for Old French. Meaning, the entry names will not have diacritics that were not actually found in manuscripts, but diacritics will be added on the headword lines and text and stripped from links. --WikiTiki89 18:41, 12 November 2015 (UTC)[reply]
I'd considered that but we'd be going against what apparently every other dictionary does. If you're copying and pasting from another website, it could matter quite a lot. Renard Migrant (talk) 21:55, 12 November 2015 (UTC)[reply]
Other dictionaries don't actually have an entry name vs. headword distinction. --WikiTiki89 22:42, 12 November 2015 (UTC)[reply]
That is the root of the issue really. The fact that all spellings have an individual dedicated page, like color and colour are separate issues. Anyway, a specific example would be like trové being merged into trove (no entry right now) and when you look at the etymology of treasure trove, it says from tresor trové, you go there and it says only Spanish. Sure you can change the Wiktionary entry, but what about other websites that use the standardized spelling trové. And how many people get their hands on actual manuscripts? I've seen a book in Old Frenchl (French in the left-hand column, Old French on the right) in a general book store in France by way of comparison. Renard Migrant (talk) 23:47, 12 November 2015 (UTC)[reply]
And if we automatically strip links, that solves all the problems. The entry will be at [[trove]], and both {{l|fro|trové}} and {{l|fro|trove}} will point to the same page. --WikiTiki89 23:54, 12 November 2015 (UTC)[reply]
Would {{l|fro|trové}} actually go to trove if there was a page with a different language at trové? We certainly have to think about the case where people are entering words from books.--Prosfilaes (talk) 08:10, 13 November 2015 (UTC)[reply]
Yes, it would. {{l|la|jūra}} takes you to [[jura]] since we strip macrons for Latin, but {{l|lv|jūra}} takes you to [[jūra]] since we don't strip macrons for Latvian. —Aɴɢʀ (talk) 11:34, 13 November 2015 (UTC)[reply]
We can get away with the Latin practice because there's very little overlap between Latin words with macrons and entries in other languages that use macrons because the languages are unrelated and have different morphology (see, however Latin dō and Japanese romaji dō (dō)). In this case, there are a number of closely related languages with similar morphology, so there's bound to be a lot of overlap, and whenever there's overlap, searches go to the entry with diacritics and not to the plain form. Chuck Entz (talk) 18:52, 13 November 2015 (UTC)[reply]
I believe that we should have the forms of words that are found in printed text, because that's what people are going to be looking up. Those are the form of the word most commonly found in durably archived forms of the language.--Prosfilaes (talk) 08:10, 13 November 2015 (UTC)[reply]
I agree. What Wikitiki89 says is possible, no doubt, but is anyone in favour of it? Copying and pasting trové from another website, won't get you to trove. Renard Migrant (talk) 12:03, 13 November 2015 (UTC)[reply]
And this is what an unlinked alternative form looks like. Renard Migrant (talk) 12:34, 13 November 2015 (UTC)[reply]

Copyright of images of manuscripts edit

Looking at the link (http://www.kb.dk/permalink/2006/manus/225/eng/4/?var=1) above, can we use this image in any way? I assume while the text is uncopyrightable, the photo of it is copyrightable. Renard Migrant (talk) 18:31, 12 November 2015 (UTC)[reply]

See commons:Commons:When_to_use_the_PD-Art_tag and commons:Commons:Reuse_of_PD-Art_photographs#Nordic_countries. So we can use it.--Prosfilaes (talk) 08:01, 13 November 2015 (UTC)[reply]
Does this come under art? Renard Migrant (talk) 15:10, 13 November 2015 (UTC)[reply]
PD-Art is for photos taken from a distance. I think these images were made on a scanner, so commons:Commons:When to use the PD-scan tag applies. At any rate, we certainly have other scans of old manuscripts at Commons, see e.g. commons:Category:9th-century manuscripts. —Aɴɢʀ (talk) 15:51, 13 November 2015 (UTC)[reply]

WT:EL, should Etymology come after Pronunciation? edit

Currently the most common order of headings is to have Etymology before Pronunciation. But when the Etymology headings are numbered, then we put Pronunciation above if it applies to all of the etymologies. I think this is a bit backwards, to be honest, because it means that whenever you add a second etymology, you have to swap the headings around. It's much more common for a word to have only one pronunciation irrespective of etymology, than to have etymology-specific pronunciations. Therefore I think that this should be changed so that the default order is to have Pronunciation above Etymology. It goes without saying that if the pronunciations differ, then they should be placed within their respective etymology sections, as now. —CodeCat 21:56, 12 November 2015 (UTC)[reply]

I bet more casual users want a pron than an ety, too. Equinox ◑ 21:58, 12 November 2015 (UTC)[reply]
If we considered what users want relevant, we'd put the definition first. —CodeCat 22:01, 12 November 2015 (UTC)[reply]
We should. Equinox ◑ 22:02, 12 November 2015 (UTC)[reply]
Ok, but that's a separate debate. I definitely encourage you to start a new discussion on that, and I'd support it too, but I'd rather not get this proposal muddled up by making it bigger than it is. —CodeCat 22:04, 12 November 2015 (UTC)[reply]
I support CodeCat's proposal. --Daniel Carrero (talk) 22:55, 12 November 2015 (UTC)[reply]
Oppose for aesthetic reasons. It doesn't look good when the etymology section is under the pronunciation section. If you really want to rethink things, it might make sense for the etymology to be at the bottom, but as has been said in previous discussions, this would drastically affect the hierarchy of the entry contents. As far as what users find relevant, it's actually really easy to ignore the etymology section; I never understood why people find it annoying. Also, I'm not sure I buy CodeCat's claim that "It's much more common for a word to have only one pronunciation irrespective of etymology, than to have etymology-specific pronunciations." This just doesn't seem to be the case in my own experience. --WikiTiki89 23:12, 12 November 2015 (UTC)[reply]
Don't you work on Hebrew a lot, which has a nonphonetic writing system? That's why. —CodeCat 23:14, 12 November 2015 (UTC)[reply]
Yes, but even my experience outside of Semitic languages, such as with Russian and English, leads me to doubt your claim. --WikiTiki89 23:20, 12 November 2015 (UTC)[reply]
I agree in part. We have to keep foreign languages in mind too. If a number of languages have different pronunciations depending on etymology, then it may be better to keep the pronunciation first. However, I think it makes more sense for the pronunciation to be first in English entries, except when the pronunciation is distinct for the different etymologies (as for words like wind). Andrew Sheedy (talk) 23:19, 12 November 2015 (UTC)[reply]
wind is a bad example because the current entry fails to show that the verb wind /wɪnd/ derives from the noun, and that the noun wind /waɪnd/ derives from the verb. There should really be four etymology sections, though two of them share a pronunciation with the other two. There is no way to solve this kind of overlap and nesting in the general case. —CodeCat 01:02, 13 November 2015 (UTC)[reply]
Under the proposal how would one present homographs having the same etymology but different pronunciations? DCDuring TALK 23:49, 12 November 2015 (UTC)[reply]
Then they're the same word, just with different pronunciations, aren't they? —CodeCat 00:28, 13 November 2015 (UTC)[reply]
I think the question is if the pronunciation section should be split into two sections (one for the definitions with a certain pronunciation and one for those with another pronunciation), since the etymology would be out of the way, being higher up in the hierarchy than the pronunciations. For an example of an entry this would apply to, see right. Andrew Sheedy (talk) 00:52, 13 November 2015 (UTC)[reply]
But any other number of properties could be shared or distinct, too. I've seen English entries where a single headword line contains two different inflectional patterns, where the choice depends on the meaning. And of course there are cases where synonyms and such also differ by meaning. We solve this with the {{sense}} template. Why can't that be done for pronunciations? —CodeCat 00:59, 13 November 2015 (UTC)[reply]
I'd forgotten about the {{sense}} template. I'll replace the header in the pronunciation section of right with it (though I really should have just added a gloss in the first place). Andrew Sheedy (talk) 01:09, 13 November 2015 (UTC)[reply]
I don't like that the proposal does not link to previous discussions on the subject; there are multiple ones. The discussions contains specific objections. --Dan Polansky (talk) 09:57, 14 November 2015 (UTC)[reply]

Wiktionary:Votes/pl-2015-11/NORM: 10 proposals - starting soon edit

FYI: Wiktionary:Votes/pl-2015-11/NORM: 10 proposals (which was created 2 weeks ago) is going to start in 2 days.

Duration of the vote: 3 months. --Daniel Carrero (talk) 04:58, 13 November 2015 (UTC)[reply]

The vote started. --Daniel Carrero (talk) 03:41, 15 November 2015 (UTC)[reply]

Suggestion: Remove userspace pages from Category:Requested entries edit

Suggestion:

--Daniel Carrero (talk) 03:00, 14 November 2015 (UTC)[reply]

What if we make a subcategory? Category:Requested Entries (Userspace) or the like? Aryamanarora (talk) 03:34, 14 November 2015 (UTC)[reply]
Today, I created Wiktionary:Redlink dumps which looks better than a category IMO, since it is an organized list with a few comments here and there. Personally, I don't want to take the trouble to place every page listed at Wiktionary:Redlink dumps (let alone the hundreds of subpages) in a different category. If anyone wants to do it, I don't have anything to say about that. I only want to remove those from Category:Requested entries. --Daniel Carrero (talk) 14:39, 14 November 2015 (UTC)[reply]
Notably, I listed User:-sche#German at Wiktionary:Redlink dumps#Other languages, because @-sche has plenty of German redlinks in their user page, but I would not place an user page in a category called Category:Requested Entries (Userspace) (at least not without asking), I feel it would be rude. --Daniel Carrero (talk) 14:46, 14 November 2015 (UTC)[reply]
Keep them categorized somewhere like Aryamanarora says. Maybe Category:Requested Entries (user generated). Renard Migrant (talk) 17:21, 14 November 2015 (UTC)[reply]
Sure, but I'd understand "user-generated" to mean manual work. Most of these are the contrary of "user-generated": they are script-generated / computer-generated. Category:Redlink dumps should be a good enough name for that, like WT:Redlink dumps. --Daniel Carrero (talk) 17:26, 14 November 2015 (UTC)[reply]
Yeah, having userspace pages directly in Category:Requested entries is odd. I don't mind if someone categorizes User:-sche/wanted (the subpage of my userpage where the "wanted" terms are) into something like Category:Requested Entries (userspace). I've thought about merging it into the official list of requested entries, but I don't want to swamp that list, especially since many of the entries on my page are relatively less-important terms I just happened to notice we were missing. Using a list like Wiktionary:Redlink dumps rather than a category is also fine, IMO, and that list could be linked-to from a "See also" type section at the bottom of WT:RE:en, WT:RE:de, etc. - -sche (discuss) 23:03, 14 November 2015 (UTC)[reply]
As postscripts: I agree that "user-generated" is liable to be misunderstood and should probably be avoided, since clearer alternatives exist. Also, I don't mind splitting the many German and English words on my "wanted entries" subpage onto separate monolingual subpages, if that would be helpful. - -sche (discuss) 22:18, 15 November 2015 (UTC)[reply]
@-sche Thanks for splitting your lists into English and German pages, they do look better now.
Unfortunately, the name Category:Requested Entries (userspace), too, has the problem of not being the most accurate name possible. At WT:Redlink dumps, there are some pages in the Wiktionary: namespace:
--Daniel Carrero (talk) 13:36, 17 November 2015 (UTC)[reply]

According to my calculations:

I'm not interested in doing the work of placing those 968 entries in a separate category. We already have WT:Redlink dumps listing them, so I'd rather use my time on Wiktionary doing something else. If someone else wants to do it, you have my blessing. --Daniel Carrero (talk) 11:27, 18 November 2015 (UTC)[reply]

  Done --Daniel Carrero (talk) 02:58, 24 November 2015 (UTC)[reply]
I mean, I removed all userspace pages from that category. I didn't place them in any other category, for the reasons I said above. --Daniel Carrero (talk) 14:01, 25 November 2015 (UTC)[reply]

Blocking policy clarification edit

In Wiktionary:Votes/pl-2010-01/New blocking policy, editors seemed to want to simplify blocking policy (WT:BLOCK). To actually achieve the simplification for hasty readers, I think we need to reduce the policy page to the actual policy and nothing else, which would be to reduce it to the following: 

:''See also '''[[Help:Interacting with humans]]'''''
{{policy|draft=The portion of it which is policy may not be modified without a [[Wiktionary:Votes|VOTE]].}}
{{shortcut|WT:BLOCK}}

# The block tool should only be used to prevent edits that will, directly or indirectly, hinder or harm the progress of the English Wiktionary.
# The block tool should not be used unless less drastic means of stopping these edits are, by the assessment of the blocking administrator, highly unlikely to succeed.

Interwiki links can follow the above text.

In the past, I have seen multiple cases where editors cited parts of the page that are not the actual policy, so the above proposed change seems really required and useful.

Comments? --Dan Polansky (talk) 11:10, 14 November 2015 (UTC)[reply]

Maybe the non-policy portion of the page should be moved elsewhere. Possible name: Help:Blocking. --Daniel Carrero (talk) 14:57, 14 November 2015 (UTC)[reply]
Split into Policy and another header, such as Rationale or Explanation. Wouldn't even require a vote to do that as you could leave the policy bit unchanged. Renard Migrant (talk) 17:20, 14 November 2015 (UTC)[reply]
Splitting to headers while keeping non-policy on the wiki page does not really work for me. I want the wiki page to contain the policy and nothing else. I have no issue with there being Help:Blocking but it should probably be written in a way that does suggest that it contains regulations (rules). Tables with specific blocking lengths look like rules. --Dan Polansky (talk) 17:34, 14 November 2015 (UTC)[reply]
Do you think we need a vote for moving the non-policy contents to Help:Blocking? If the answer is yes, then would the contents of Help:Blocking be locked for editing, thus requiring further votes if we want to change something? --Daniel Carrero (talk) 03:53, 15 November 2015 (UTC)[reply]
@Daniel Carrero: I think we need a vote to edit WT:BLOCK. I don't think we need a vote to create a non-policy page Help:Blocking. Admitted, one could argue that it should be possible to edit the non-policy parts of WT:BLOCK without a vote. But I think it much better to use a vote to turn the page into a policy-only page via a vote that removes all non-policy parts. That, of course, presupposes support for changing the page as proposed by me. --Dan Polansky (talk) 08:14, 22 November 2015 (UTC)[reply]
Wait, it is already split to headers: WT:BLOCK#Policy and WT:BLOCK#Explanation. And this splitting seems to do little to prevent confusion. There is even red background in the policy text. In fact, the page contains multiple kludges to make it clear that only part of it is a policy. It looks really clumsy and does not really work, from what I can see. --Dan Polansky (talk) 17:44, 14 November 2015 (UTC)[reply]
It's not up to you, though, is it. Renard Migrant (talk) 14:55, 22 November 2015 (UTC)[reply]

I created Wiktionary:Votes/pl-2015-11/Short blocking policy. --Daniel Carrero (talk) 22:24, 25 November 2015 (UTC)[reply]

What distinguishes a synonym from an alternative form? edit

I've come across several Finnish entries, where one word is defined as an alternative form of another, but the two words have different morphological structure and hence etymologies. An example is kolkkaa vs kolkata, but I've seen examples which differ more substantially. It would be somewhat like having two verbs in English, one with -en and another with -ify, defined as alternatives of the same term. I think these shouldn't be considered alternative forms, but we don't really have clear definitions for what is an alternative form and what is a synonym. Alternative forms, at the very least, are a subset of synonyms, but I would like to set some stricter criteria for distinguishing them. What comes to mind is having the same morphological structure and/or etymology, or forms that differ by dialect or something like that. —CodeCat 18:13, 14 November 2015 (UTC)[reply]

I also find myself in this situation every now and then. The general guideline I apply to myself is that words are alternative forms if they are synonyms and have roughly the same etymology.
I know this is not very helpful, because of the “roughly”. But consider the pair piranha and piraña: both have the same Old Tupi etymon, the only difference is that one entered English via Portuguese and the other via Spanish. — Ungoliant (falai) 22:35, 14 November 2015 (UTC)[reply]
This is one of those things that's easier to decide on a case-by-case basis than with a general guideline. --WikiTiki89 02:57, 15 November 2015 (UTC)[reply]
Kolkkaa only has the third sense listed under kolkata ("to clatter") which seems like sufficient grounds to not list this as an "alternate form". --Tropylium (talk) 19:11, 15 November 2015 (UTC)[reply]

Rhymes navigation edit

I would like to found a couple of rhymes pages so I would like to ask about the preferred format of navigation at the top. I noticed at Rhymes:Czech/ofka that Lo Ximiendo changed it for {{rhymes nav}}, which Dan Polansky has reverted, unfortunately without explanation. The same has happened at about 20 more rhymes pages. I have also noticed that the template itself declares that "this template should be placed at the top of all rhymes pages". So what is the preferred way? Thank you. Jan Kameníček (talk) 21:54, 14 November 2015 (UTC)[reply]

{{rhymes nav}} was installed to rhyme pages by user CodeCat by a bot and without consensus. I oppose its use. It sets up rhyme pages for a hiearchy of categories and index pages, which I find undesirable and confusing. In my view, all Czech rhyme pages should be in Category:Czech rhymes, and subcategories like Category:Czech rhymes/a- should not exist. The subcategories are clumsy, do not add any real value and do not provide a truly useful navigation tool, unlike e.g. the tables at Rhymes:Czech. The markup at Rhymes:Czech/ofka that creates "Rhymes > Czech" is perectly simple, straightforward, does what needs to be done, and is in no need to be replaced with a template that presupposes a page structure that the creators of the rhyme pages do not support such as Rhymes:Czech/o- linked from a templated version of Rhymes:Czech/ofka.
I did a lot of substantive work on Czech rhyme pages, and consider myself to know what I am talking about.
I also object to use of templates where they add close to no value but give power to people who lock templates to be only editable by admins and the like, or even move their content to modules (Module:rhymes) to further raise barier of editing. That said, for some purposes, modules are extremely useful. --Dan Polansky (talk) 22:14, 14 November 2015 (UTC)[reply]
Is the template generating incorrect content? If not, it should be used. — Ungoliant (falai) 22:15, 14 November 2015 (UTC)[reply]
I prefer the non-templated page. There is no need to use a template instead, unless tangible benefits of template can be shown. I still hope that editors at large do not support this type of over-templatization.
The template places the page into a category that IMHO should not exist, and links to an index page that should not exist either. Correct or incorrect is not at stake; editor preferences are at stake. --Dan Polansky (talk) 22:20, 14 November 2015 (UTC)[reply]
An aside: as a remnant of CodeCat's non-consensual changes, we still do not have "-" back in the names of rhyme pages; see also Wiktionary:Votes/2014-09/Renaming rhyme pages. --Dan Polansky (talk) 22:20, 14 November 2015 (UTC)[reply]
As for what the template itself declares, what else do you expect from CodeCat's templates? See also Wiktionary talk:Votes/2014-08/Debotting MewBot. --Dan Polansky (talk) 22:21, 14 November 2015 (UTC)[reply]
I'd say, if you want to change the practice of simple formatting at the top of Czech rhyme entries, and the flat category structure of Czech rhyme entries, please someone create a vote, and do it now. Do it yourself, so that you do not need to accuse me later of poor drafting. --Dan Polansky (talk) 22:23, 14 November 2015 (UTC)[reply]
I do not want to change any practice, I am just asking, because I have not learned anything neither from the summaries of your reverts of Lo Ximiendo's edits neither from the summary of your revert of my edit. I do not care very much which format is chosen, I just want to know so that next time I am not reverted again. You wrote that the template started to be introduced without having been discussed, so this might be an opportunity to find out the general opinion of it. (By the way, your work on rhymes pages was enormous; that is beyond any doubt). Jan Kameníček (talk) 23:00, 14 November 2015 (UTC)[reply]
Nobody seems to oppose Dan Polansky's arguments, so I go on in the way that he promotes. Jan Kameníček (talk) 21:18, 24 November 2015 (UTC)[reply]
You can also go on the way you have done before. There's nothing wrong with your previous edit and they were reverted without ground. Dan is just trying to bully you into doing things his way. —CodeCat 22:01, 24 November 2015 (UTC)[reply]

Wiktionary:Votes/2015-11/Language-specific rfi categories - created vote edit

FYI: I created a new vote about {{rfi}}, the vote is linked in the header.

Also, I think there's no harm in repeating what I said in a previous post: There's an unrelated vote that started today. You can cast your votes on it already:

--Daniel Carrero (talk) 05:19, 15 November 2015 (UTC)[reply]

Removing rfi from talk pages edit

FYI: I intend to remove {{rfi}} from talk pages.

Usage:

  • It is used in 19 talk pages.
  • It is used in 6,500+ entries.

Method:

  • When the entry still needs an image, I am going to move the {{rfi}} to the entry itself, in the correct language section.
  • When the entry already has an image, I am going to remove the {{rfi}} altogether as a request fulfilled.

Reasons:

  1. Numbers suggest that the overwhelming practice is placing the request in the entry, not the talk page.
  2. About half of those entries have images already. The people who added the images did not remove the box, I suspect this happened because the box was hidden in the talk page.
  3. Probably I just got bored enough to make this list rather than just doing the change in the 19 entries, but I'm erring on the side of announcing one's intent at the BP for openness. It would also be nice if this prevented new rfis being added to the talk pages in the future, for better consistency.

(✔ = request fulfilled, has at least one image)

--Daniel Carrero (talk) 05:44, 15 November 2015 (UTC)[reply]

Note: User:DCDuring has been adding images to some entries listed and editing my message above to update the list. And, for that, he has my thanks. --Daniel Carrero (talk) 14:27, 15 November 2015 (UTC)[reply]
Done. I finished moving all the rfis to the main entry, or deleting the ones where the request was fulfilled. --Daniel Carrero (talk) 09:49, 17 November 2015 (UTC)[reply]

Wiktionaries linked at Norwegian language, Norwegian Bokmål language and Norwegian Nynorsk language edit

According to meta:Wiktionary, there are two Norwegian Wiktionaries:

  • Norwegian (Bokmål) = no.wiktionary.org
  • Norwegian (Nynorsk) = nn.wiktionary.org

I don't speak Norwegian, so I'll assume that's accurate.

Our language categories link to Wiktionary editions when they exist, and they are perfectly capable of showing links to multiple Wiktionaries at once. (compare Category:English language and Category:Serbo-Croatian language) But I think our three Norwegian language categories are not linking to Norwegian Wiktionaries accurately.

I believe perhaps they should display:

--Daniel Carrero (talk) 13:46, 16 November 2015 (UTC)[reply]

w:no:Portal:Forside (Bokmål Wikipedia), w:nn:Hovudside (Nynorsk Wikipedia)
no:Wiktionary:Forside (Bokmål Wiktionary), nn:Hovudside (Nynorsk Wiktionary) —Stephen (Talk) 00:59, 17 November 2015 (UTC)[reply]
With my ability, I am unable to do the proposed change to the modules. Maybe it has something to do with Module:wikimedia languages.
Currently, Category:Norwegian language links only to nowikt, not to nnwikt. I think it should link to both. --Daniel Carrero (talk) 18:19, 24 November 2015 (UTC)[reply]

Namespace abbreviations edit

There has been some recent discussion in the BP and in the recent vote adding the “Reconstructed:” namespace about adding more snazzy namespace search bar abbreviations like the preëxisting “WT:” for “Wiktionary:”. It would make things far more convenient to have a few more of these like “TP:” for “Template:”, “AP:” for “Appendix:”, and “MW:” for “MediaWiki:”. I wanted to check to see whether was enough interest to merit a vote and also what abbreviations people would like to see. My initial list would look something like:

  • AP → Appendix
  • C → Citation
  • CT/CA/CAT → Category
  • MD → Module
  • MW → MediaWiki
  • T → Talk/Discussion
  • TP → Template
  • RC → Reconstruction

And potentially many more. These things will make life a lot easy for frequent contributors of this project and delay the impending carpal tunnel syndrome that awaits us all a few years. It would also be cool if there were a way to jump immediately to a talk page by appending “T:” to a namespace (e.g. “AP:T:” → “Appendix talk:” or “TP:T:” → “Template talk:”). —JohnC5 01:28, 17 November 2015 (UTC)[reply]

This would get my vote, although I find myself going to category pages a lot more than citation pages, so I might make C = category and CI = citation. I also might find it easier to remember if you use the first two letters whenever the word isn't clearly two parts, e.g. TE=template, MO=module. Benwing2 (talk) 02:09, 17 November 2015 (UTC)[reply]
I could support behind all these options.
I know it's not that long to begin with but I could imagine “U:” for “User:” to be useful, especially since “U:T:” would be great. —JohnC5 02:17, 17 November 2015 (UTC)[reply]
You could also abbreviate UT=User talk, TT/TET=Template talk, AT/APT=Appendix talk, etc. Benwing2 (talk) 02:51, 17 November 2015 (UTC)[reply]
Also a possibility; though the :T: suffix does avoid ambiguity. —JohnC5 02:59, 17 November 2015 (UTC)[reply]
I support the proposal, but "MW → MediaWiki" and "C: → Citation or Category" are unavailable, because they link to sister projects. Full list: w:Help:Interwiki linking.
Wikipedia uses "WT → Wikipedia talk" (their equivalent of Wiktionary talk), "T → Template", "CAT → Category" and "H → Help". Full list: w:Wikipedia:Shortcut#Pseudo-namespaces. IMO we should use, too, "CAT → Category" and "H → Help". "Cat" is our standard abbreviation of "category" anyway -- many category templates and at least 1 categorization gadget have "cat" in the name. --Daniel Carrero (talk) 09:38, 17 November 2015 (UTC)[reply]
I also prefer CAT over anything else for categories. Equinox ◑ 15:09, 17 November 2015 (UTC)[reply]
So for the sake of listing things, we would prefer something like:
  • AP → Appendix
  • CIT → Citation
  • CAT → Category
  • H → Help
  • MD/MO/MOD? → Module
  • MWK/MED? → MediaWiki
  • RC → Reconstruction
  • U → User
Then the question remains of what we would like for “Talk” and “Template”. I'd prefer:
  • T → Talk/Discussion
  • TP/TEM/TEMP? → Template
The above option allows for the unambiguous “u:t:” for “User talk:”. Alternatively, if we think that we link/navigate to templates more often than talk pages:
  • TK? → Talk/Discussion
  • T → Template
—JohnC5 15:32, 17 November 2015 (UTC)[reply]
Suggestion:
* DOC:en-noun → Template:en-noun/documentation
* MDOC:parameters → Module:parameters/documentation
--Daniel Carrero (talk) 15:54, 17 November 2015 (UTC)[reply]
I was curious about that. Is it possible to have a prefix translated into a circumfix (i.e. “DOC:” → “Template: … /documentation”? —JohnC5 16:03, 17 November 2015 (UTC)[reply]
I support new abbreviations for our unique namespaces, like citations, appendix and reconstructions. But I don't think we should be making ones for modules or templates, as this will only add confusion and incompatibility when copying content between wiktionaries / wikis. If it's only for the search bar it's ok, but we shouldn't be creating ways to reference a template in wiki markup that only work on this Wiki. Pengo (talk) 20:36, 17 November 2015 (UTC)[reply]
@Pengo: to be honest, the “Template” and “Category” namespaces are probably the ones for which I most would like abbreviations, but that is a very valid comment for which I thank you. —JohnC5 20:43, 17 November 2015 (UTC)[reply]
Re: "we shouldn't be creating ways to reference a template in wiki markup that only work on this Wiki."
But aren't some templates kind of like this? When we want to reference a template in a discussion, we often use {{temp}}, so it's like "temp" were a very particular kind of abbreviation for a certain namespace. --Daniel Carrero (talk) 20:49, 17 November 2015 (UTC)[reply]
Maybe if we do it first, all the other wikis will follow. When typing fast, I can never spell Category right on the first try (it usually ends up as Cateogry or something), so it would be very useful to have an abbreviation. --WikiTiki89 21:03, 17 November 2015 (UTC)[reply]
But {{temp}} itself can be copied verbatim to other Wikis still and will still work the same way and you need to know nothing special about en.wikt to do so. Changing Template: to Temp: might seem minor, but it means exporting wikitext requires actually editing the wikitext, and suddenly requires specialized knowledge of English Wiktionary's configuration. I don't think it's an exaggeration to say it becomes an order of magnitude more difficult and error prone. If those abbreviations work their way into module code then it becomes more difficult again and requires more expertise. I'd rather not break compatibility with the other hundreds of other WMF Wikis for the sake of a minor convenience. If we could introduce temp: or mod: across all wikis then that'd be fine, or if it was just for searching it'd be great, or if they were auto-expanded when you preview/save that'd be okay too. but otherwise I'd rather be cautious and not introduce the possibility of breaking things unnecessarily. Pengo (talk) 21:39, 17 November 2015 (UTC)[reply]
Is there somewhere where we can suggest the addition of "cat: -> category:" in all wikis simultaneously? meta.wikimedia.org? --Daniel Carrero (talk) 21:47, 17 November 2015 (UTC)[reply]
But you can't type {{temp}} into the searchbar. I don't care so much about actual wikilinks. --WikiTiki89 21:53, 17 November 2015 (UTC)[reply]
No, templates can be difficult to copy between wikiprojects. For example {{Navbox}} from Wikipedia is impossible to copy without hard work.--Dixtosa (talk) 10:30, 18 November 2015 (UTC)[reply]
@Daniel Carrero:, forget that. Just forget it. Just do it... xD--Dixtosa (talk) 10:30, 18 November 2015 (UTC)[reply]
Regarding "U:T:", is a colon inside a namespace name possible? We currently have links like WT:T:ADE, but that was a workaround not having a true namespace alias — they are actual redirects (i.e. they exist as pages, unlike WT:About German which only exists as Wiktionary:About German) in the Wiktionary namespace which start with "T:". We could, of course, continue that convention. How many namespaces are long enough and sufficiently often linked to that they need aliases? Wikipedia, a much bigger project, gets by with only a few. I don't think MediaWiki pages are linked to often enough that they need an alias. Increasing the number of aliases does have a few (slight) drawbacks, e.g. pre-existing or possible future clashes with interwiki links. "Cat", although a language code, is fortunately not an interwiki; the interwiki to Catalan projects is "ca". "Mod", on the other hand, is the only code for Mobilian, so a "mod:" space would conflict with interwiki links if a Mobilian wiki were created; likewise "Cit" is the code for Chittagonian. Do we need shorthand for citations pages, anyway? I would add "AP → Appendix" and "RC → Reconstruction" and "CAT → Category". If we needed a shortcut to modules, what if we just used "M:" and didn't add a shortcut to MediaWiki pages? Likewise I would use "T:" for template; "Talk:" is not hard to type in full. - -sche (discuss) 02:18, 18 November 2015 (UTC)[reply]
As I've already pointed out, many of these shortcuts would be much more useful for navigation through the search bar than strictly for linking. Also, if it is at all possible that CAT: would not have to be preceded by a colon in links, that would be very, very convenient. --WikiTiki89 02:28, 18 November 2015 (UTC)[reply]


Given all that I've seen above, I would still like to have abbreviations for at least Category, Template, Module, Reconstruction, Appendix since those are the most typed and least convenient. —JohnC5 16:02, 18 November 2015 (UTC)[reply]

I am planning on maybe creating a vote for at least the most wanted abbreviations on this discussion. The ones mentioned by John5 (Category, Template, Module, Reconstruction, Appendix) have my support. Aside from that, I would really like to know if it's possible also redirecting "DOC:" and "MDOC:" as I suggested above. --Daniel Carrero (talk) 19:25, 18 November 2015 (UTC)[reply]
But the documentation pages are really meant to be viewed from the template/module's page itself, so I'm not sure why we would need to link directly to the documentation. --WikiTiki89 19:30, 18 November 2015 (UTC)[reply]
Please do start a vote! I feel that abbreviations for Reconstruction and Appendix are not contentious. It might make sense to have a separate section of the vote for Category, Template, and Module, since Pengo at least seems to have some reservations about those. —JohnC5 18:21, 21 November 2015 (UTC)[reply]
I would even say we should have a separate section for each namespace. --WikiTiki89 21:57, 21 November 2015 (UTC)[reply]
Sounds good to me. —JohnC5 17:29, 22 November 2015 (UTC)[reply]

Wiktionary:Votes/2015-11/Namespace abbreviations --Daniel Carrero (talk) 05:59, 24 November 2015 (UTC)[reply]

Remove the numbers from Etymology sections edit

Why do we have numbers on Etymology sections? The numbers themselves don't mean anything, and are subject to reordering anytime anyway. We also don't number other sections; you don't see "Noun 1" or "Conjugation 2" sections anywhere. The numbers are not necessary to understand the entry at all, since the header structure already gives this information. It's also annoying to have to number and renumber them all the time, when we don't require this treatment for other headers. Therefore I propose dropping the numbering from the headers, so that they are treated like we treat other headers already. —CodeCat 18:42, 18 November 2015 (UTC)[reply]

Previously, they were used for links, such as foo#Etymology 1. They are also useful as an indication to the reader that there are more etymologies to follow. --WikiTiki89 18:45, 18 November 2015 (UTC)[reply]
Most readers don't know or care about etymologies, so it's not very interesting information. The definitions should really come first, and entry information should be grouped by term (like other dictionaries do), not etymology. But since people keep blocking that, we have to find other means to slap some sense into our entry structure. —CodeCat 18:48, 18 November 2015 (UTC)[reply]
Re: "But since people keep blocking that, we have to find other means to slap some sense into our entry structure" -- I don't know about other people, but if someone proposes a solid layout with definition first and makes a vote for it, I would consider supporting it. --Daniel Carrero (talk) 19:32, 18 November 2015 (UTC)[reply]
Sorry, I meant "more etymology sections to follow". What does term mean in "grouped by term"? And aren't you basically saying "this might not be the right thing to do, but no one wants to do the right thing, so let's do this instead"? --WikiTiki89 18:52, 18 November 2015 (UTC)[reply]
I see it as an improvement, which is the point. Wiktionary should be improved. And by "term" I mean part-of-speech headers. I can't say "part of speech" because then people will think I want to group different nouns together. I think that entries should be formatted with etymology and pronunciation nested under the part of speech header. The other way around doesn't make much sense, since every word has its own etymology anyway, there should be as many etymology sections as there are part of speech sections. —CodeCat 19:00, 18 November 2015 (UTC)[reply]
Case in point: diff is way too much administrative work to add a simple etymology. I should just be able to add the etymology under the appropriate POS section, and not have to worry about adding additional numbered sections and adding extra equals signs to all the headers. —CodeCat 19:35, 18 November 2015 (UTC)[reply]
Other dictionaries number the headwords, e.g. ¹wind and ²wind or wind 1 and wind 2 or the like. I think it would be confusing to have avoid numbers altogether (and we certainly have used "Noun 1" and "Pronunciation 2" headers in the past, though bots tend to remove them). Ultimately I think it would be least confusing (though not 100% nonconfusing) to have each entry on a page of its own, i.e. with its own URL, e.g. "/wiki/en/wind_(movement_of_air)", "/wiki/en/wind_(twist)", "/wiki/nl/wind_(wind)", "/wiki/nl/wind_(form_of_winden)", "/wiki/ang/wind", and so on. Then "/wiki/wind" would just be disambig page, as would "/wiki/en/wind" and "/wiki/nl/wind". —Aɴɢʀ (talk) 19:36, 18 November 2015 (UTC)[reply]
It might be tricky for words with ones of meanings - eg, is train1 "/wiki/en/train_(rail_vehicle)", "/wiki/en/train_(long_skirt)", "/wiki/en/train_(procession)", etc? Effectively, the disambiguation pages would just become the entries themselves. Smurrayinchester (talk) 20:42, 21 November 2015 (UTC)[reply]
This is certainly true, and it's a problem I'm already having with categorising suffixes. But the issue with numbers is that they don't allow reordering without breaking links. In most dictionaries, the content is created in advance so the editors know the numbering and can refer back to the numbers. But Wiktionary is always in development, so senses are split and rearranged as we go. We invented {{senseid}} to solve this, but we haven't yet used it at a level higher than a single sense. It certainly needs a solution though. —CodeCat 20:50, 21 November 2015 (UTC)[reply]

Suggestion: make "Vote started" and "Vote ends" agree on the tense edit

Most votes have the dates like this:

  • Vote started:
  • Vote ends:

I suggest editing the vote-generator templates to agree on the tense. I propose:

  • Starting dateStart date:
  • End date:

For reference, the "vote-generator templates" I mentioned are:

--Daniel Carrero (talk) 21:26, 18 November 2015 (UTC)[reply]

Ironically, your suggestion has the same problem, mixing a participle with a noun. It should be either "start date" and "end date" or "starting date" and "ending date" (and I prefer the former pair). --WikiTiki89 21:50, 18 November 2015 (UTC)[reply]
Sure. Striked the "Starting". --Daniel Carrero (talk) 21:59, 18 November 2015 (UTC)[reply]
I find "vote started/ended" (in whatever tense) clearer than "start/end date". The language is more active somehow. Equinox ◑ 14:30, 19 November 2015 (UTC)[reply]

I also suggest retroactively editing all votes to make the "Vote started" and "Vote ends" agree on the tense. I wouldn't mind creating a vote for this. --Daniel Carrero (talk) 04:17, 24 November 2015 (UTC)[reply]

Created a vote: Wiktionary:Votes/2015-11/Fix tense: start/end in votes. --Daniel Carrero (talk) 07:37, 29 November 2015 (UTC)[reply]

redirect pages needed edit

I don't think this is currently allowed, but Wiktionary desperately needs to start making redirect pages for protowords, transliterations, and spelling variants not currently permitted in mainspace. A simple "#redirect [[correct location of term]]" would be a huge help in finding these items on Wiktionary. Words in protolanguages (e.g. Proto-Indo-European, Proto-Germanic, etc.) are often very difficult to find, especially for Proto-Indo-European, for which roots can often be spelled different ways. What is even worse is if someone has a protoword they want to look up in Wiktionary but is not sure for which protolanguage; since protowords are in appendices, it can be very difficult to find. Placing redirect pages to the appendix entries for protowords would be a huge help. Another example is for Russian, Latin, Classical Greek, etc. words, which can often be spelled with or without diacritics (for stress and tone), but are only indexed in mainspace with minimal diacritics. Looking for words by copying and pasting the diacriticked versions into search can make using Wiktionary difficult as well. Redirect links for the diacriticked versions to the main non-diacriticked pages would be a huge help there as well. Trying to search a copied diacriticked term (e.g. νῑ́κη) by removing the diacritics from the copied non-Roman Unicode characters on an ASCII keyboard is often impossible, and requires replacing the characters using a character map instead (νίκη, νικη). Nicole Sharp (talk) 04:46, 19 November 2015 (UTC)[reply]

I agree. The software already redirects to pages that vary only in diacritics, but it needs to be expanded to work with more scripts. — Ungoliant (falai) 17:03, 21 November 2015 (UTC)[reply]
[I]f someone has a protoword they want to look up in Wiktionary but is not sure for which protolanguage — Probably the best approach to this is to start with one of the descendants. If a proto-word has been added on Wiktionary, it's likely linked from its descendants, too. I guess in principle someone could have neither — where you only have something like *fō "hand" and no idea what part of the world this is from — but this seems too unlikely to be useful to account for.
Proto-word redirects for transcription variants would be good to have around, and certainly preferrable to treating them as "spelling variants" with separate entries. --Tropylium (talk) 21:37, 21 November 2015 (UTC)[reply]
We already do that last part. —CodeCat 00:19, 22 November 2015 (UTC)[reply]
I know, I'm just echoing the recommendation to add more. --Tropylium (talk) 02:17, 22 November 2015 (UTC)[reply]
Yes, that is what I usually do now for protowords, is that I have to find a derivative word, then find the protoword from an etymology. That is very inefficient though. Redirects for protowords, transliterations, and spelling/diacritic variants are still needed. Nicole Sharp (talk) 10:49, 28 November 2015 (UTC)[reply]
Expanding a bit more on this, I'd like to also suggest at least as a general practice (possibly policy):
  • Any reconstruction entry that lists alternate reconstructions should
  1. not link to these
  2. set up all listed alternate reconstructions as redirects (provided that this does not clash with other reconstructed entries).
--Tropylium (talk) 16:17, 23 November 2015 (UTC)[reply]
I think links can be helpful just to ensure that the redirects exist. —CodeCat 16:27, 23 November 2015 (UTC)[reply]

A cool Pleco update for Cantonese edit

To Chinese editors: Pleco dictionary now has a new downloadable dictionary for specifically Cantonese terms - 20,000 entries. Such entries are marked as CCY. Previously, only terms that shared the forms with Mandarin were there. Funny enough, these terms still have pinyin readings:

佢哋〔渠-〕
PY qú dì
ZY ㄑㄩˊ ㄉㄧˋ
JP keoi5 dei6

Please spread the news for Chinese editors. No need to go online to Sheik's dictionary any more, which should be larger, actually. --Anatoli T. (обсудить/вклад) 07:13, 23 November 2015 (UTC)[reply]

A def line for phrasal verbs edit

I would like to add a definition line to the main verb for each phrasal verb. I've made Template:phrasal verb for that purpose. You can see it in use at abide right now. I think this will make it easier for people to see that it's there -- if someone is looking for help understanding a sentence that uses "abide by", they won't know they should be looking up the phrasal verb or going down to "Related terms" to find what they're looking for. It might also help reduce the frequency with which people add phrasal verb definitions to the main verb form, since they don't realize that it is part of a different entry. What do you think? WurdSnatcher (talk) 21:43, 23 November 2015 (UTC)[reply]

Ave WurdSnatcher, nos correcturi te salutamus.​—msh210℠ (talk) 19:59, 25 November 2015 (UTC)[reply]

Your input requested on the proposed #FreeBassel banner campaign edit

This is a message regarding the proposed 2015 Free Bassel banner. Translations are available.

Hi everyone,

This is to inform all Wikimedia contributors that a straw poll seeking your involvement has just been started on Meta-Wiki.

As some of your might be aware, a small group of Wikimedia volunteers have proposed a banner campaign informing Wikipedia readers about the urgent situation of our fellow Wikipedian, open source software developer and Creative Commons activist, Bassel Khartabil. An exemplary banner and an explanatory page have now been prepared, and translated into about half a dozen languages by volunteer translators.

We are seeking your involvement to decide if the global Wikimedia community approves starting a banner campaign asking Wikipedia readers to call on the Syrian government to release Bassel from prison. We understand that a campaign like this would be unprecedented in Wikipedia's history, which is why we're seeking the widest possible consensus among the community.

Given Bassel's urgent situation and the resulting tight schedule, we ask everyone to get involved with the poll and the discussion to the widest possible extent, and to promote it among your communities as soon as possible.

(Apologies for writing in English; please kindly translate this message into your own language.)

Thank you for your participation!

Posted by the MediaWiki message delivery 21:47, 25 November 2015 (UTC) • Translate • Get help

About the active votes edit

Planned, running, and recent votes [edit this list]
(see also: timeline, policy)
EndsTitleStatus/Votes
Apr 29User:TTObot for bot status 8  0  0
May 26Allowing etymology trees on entriesstarts: Apr 27
(=2)[Wiktionary:Table of votes](=8)

These are the most recent votes that I created. All 3 of them were based on previous discussions and were announced before, I'm just repeating the announcement here for conveniency/visibility/whatever.

  1. Wiktionary:Votes/2015-11/Namespace abbreviations -- I created it yesterday. Scheduled start date: Dec 1.
  2. Wiktionary:Votes/pl-2015-11/Short blocking policy -- I created it today. Scheduled start date: Dec 2.
  3. Wiktionary:Votes/2015-11/Language-specific rfi categories -- It started on Nov 22, you can vote on it now.

Also I didn't create this, but it is another recently-created vote which may be of interest:

  1. Wiktionary:Votes/bc-2015-11/User:Chuck Entz for bureaucrat -- You can vote here now, too.

On the opposite end, here are the votes that are closest to end, both on Nov 30:

  1. Wiktionary:Votes/pl-2015-09/Using macrons and breves for Ancient Greek in various places
  2. Wiktionary:Votes/pl-2015-10/Headword line

Also, I extended one vote by 1 month:

  1. Wiktionary:Votes/2015-10/Matched-pair naming format: left, space, right -- It currently has 100% support (5-0-0). It was going to end on Nov 22, but I felt uncomfortable closing the vote because only 5 people voted. That said, it's arguably a minor proposal. I guess I could have closed it but I'd rather wait a little more.

I didn't mention all the active votes apart from those that are starting now, ending now or the one that I extended. I'm leaving the vote box here which should contain all the active votes. --Daniel Carrero (talk) 23:05, 25 November 2015 (UTC)[reply]

I don't think there was any reason to extend the matched-pair vote. --WikiTiki89 23:30, 25 November 2015 (UTC)[reply]
  • We don't have any precedent on enforcing a quorum that I know of. It might not be a bad idea; I might previously have thought of it as pointless bureaucracy given our low turnout, but the recent advances in vote visibility (and thus turnout) have made this feasible in protecting the democratic structure. —Μετάknowledgediscuss/deeds 00:18, 26 November 2015 (UTC)[reply]
    In some cases the issues involved in a vote presuppose technical or linguistic knowledge that may not be had by many. Would an abstention on the grounds of ignorance count for quorum purposes? If not, how else would the quorum be adjusted for such cases. DCDuring TALK 00:26, 26 November 2015 (UTC)[reply]
I support counting abstention votes for quorum purposes. --Daniel Carrero (talk) 00:32, 26 November 2015 (UTC)[reply]
Agreed. Benwing2 (talk) 05:24, 26 November 2015 (UTC)[reply]
I take it the quorum would be used as a rationale for extending votes? For example, we could have the rule that we should not close any votes with less than 10 voters; and that such votes should be extended by one month. To prevent an endless loop of extending particularly unpopular votes, however unlikely, we could also have the rule that a number of X months or Y extensions is the maximum alllowed, after which the vote is closed as failed. --Daniel Carrero (talk) 06:04, 26 November 2015 (UTC)[reply]
I think the extension of the 5-participant vote was a very acceptable one. It is not clear that it was really necessary, but if the creator of the vote felt 5 was not good enough, I don't see a good reason to oppose extension. There certainly cannot be any claim of result fishing (or whatever the term is). --Dan Polansky (talk) 19:02, 29 November 2015 (UTC)[reply]

Quorum proposal:

  • If, by the end date, a vote has less than 10 participants, it should be extended by 1 month.
  • A vote can be extended 2 times using the rule above. After which, if the vote remains with less than 10 participants by the end date, it should be closed as failed.

--Daniel Carrero (talk) 09:45, 29 November 2015 (UTC)[reply]

10 might be too many for some sorts of votes. For example, votes enabling bots are often 5-0 or 6-0. It seems like the size of the quorum might depend on how much opposition there is, and whether it's of the type that's potentially controversial (e.g. a policy vote) or usually non-controversial (e.g. a bot vote). Benwing2 (talk) 13:15, 29 November 2015 (UTC)[reply]
@Benwing2 True. Maybe we should close successfully any vote with 100% support, even if there is little turnout?
Random example: Wiktionary:Votes/pl-2014-08/CFI Misspelling Cleanup contains 2 separate proposals, both of which separately passed with 4-0-0.
I suggest this revision of the quorum proposal:
  • Concerning votes with 10 or less participants:
    • If the proposal has enough votes to pass, and 2 or less votes in opposition, it should be successfully closed.
    • If the proposal has more than 2 votes in opposition, it should be extended by 1 month exactly once. If it remains with 10 or less participants at the new enddate, it should be closed.
  • Concerning votes with more than 10 participants:
    • (not sure, maybe this part should be filled with different rules)
Notes:

Module errors on many pages (particularly Portuguese) regarding incorrect genders edit

I added a check to Module:gender and number to make sure someone didn't add some nonsensical gender like "masculine feminine" or "singular plural". These are two separate gender specifications, so they should be specified as such. Apparently, some editors have been making this mistake a lot, and as a result there are a lot of module errors. Can these be fixed? —CodeCat 00:56, 26 November 2015 (UTC)[reply]

It appears that all of these are the work of User:Ungoliant MMDCCLXIV, who has invented his own interpretation of gender codes, against years of consensus and common practice. "m-f" has never been a valid gender, so I don't know why this user started adding it to things without any discussion. The proper way to add multiple genders is, and has always been, to specify the second gender with another parameter, such as g=m|g2=f in {{head}} or {{l}}. —CodeCat 01:53, 26 November 2015 (UTC)[reply]

For the record, the hundreds of module errors are being caused by CodeCat’s edits to Module:gender and number, not by anything I did. — Ungoliant (falai) 01:57, 26 November 2015 (UTC)[reply]
All I did was add a check on incorrect genders. You provided the incorrect genders, and have apparently done so on a huge scale without any discussion. Or can you point me to the discussion where you got consensus for using "m-f" as a gender? —CodeCat 02:02, 26 November 2015 (UTC)[reply]
Can you point me to the discussion where you got consensus for filling Wiktionary with module errors where before we had something working properly that hadn’t gotten a single complaint despite years of use? — Ungoliant (falai) 02:07, 26 November 2015 (UTC)[reply]
There's nothing nonsensical about m-f or mf- it's just shorthand for both genders (see 父母 (fùmǔ), for a real-life example). Ungoliant isn't the only one who does this- I've cleaned up a number of instances over the past year or so (muttering under my breath the whole time). Since this isn't ambiguous, it should be allowed for in the code. Chuck Entz (talk) 04:22, 26 November 2015 (UTC)[reply]
I agree with CodeCat that you should use g=m|g2=f or similar in place of m-f, but I'd suggest having a bot clean these up. Benwing2 (talk) 05:23, 26 November 2015 (UTC)[reply]
g=m|g2=f means something different from m-f in Portuguese templates. This is the second time CodeCat has tried to unilaterally remove this distinction, even though it was discussed in WT:APT. — Ungoliant (falai) 12:17, 26 November 2015 (UTC)[reply]
What is the difference? I see WT:APT mentioning mf and morf but there's no mention of specifying multiple genders using different params. BTW one way to deal with this is to have the relevant template convert mf to g=m|g2=f underlyingly. Benwing2 (talk) 01:52, 27 November 2015 (UTC)[reply]
m-f and mf are used for words that have multiple genders, with the gender used corresponding to the referent’s sex when necessary; multiple gender parameters (and morf, which became unnecessary after {{pt-noun}} was converted to Lua) are for words that have a single gender, but a different gender is used depending on formality, dialectal, chronolectal or idiosyncratic factors (i.e. gangue is masculine in Portugal and feminine in Brazil). — Ungoliant (falai) 02:06, 27 November 2015 (UTC)[reply]
That's not at all obvious, it's just a convention you invented. There are better and more intuitive ways to denote the that the gender of the noun matches the gender of the referent. —CodeCat 02:16, 27 November 2015 (UTC)[reply]
That’s not an excuse to break the template. — Ungoliant (falai) 02:17, 27 November 2015 (UTC)[reply]
You're right, it isn't. So why did you? —CodeCat 02:19, 27 November 2015 (UTC)[reply]
What you've done is like deleting a widely-transcluded template without orphaning it. I don't care how hideous you think the status quo was, it wasn't as bad as the thousands of module errors we're faced with at the moment. This is bad for the function and the reputation of our site, and you have yet to say anything that justifies leaving it this way. Please explain why your edits shouldn't be reverted until the problem with the parameters is resolved. Chuck Entz (talk) 07:16, 27 November 2015 (UTC)[reply]
(edit conflict) It seems to me it's useful to have a difference between X and Y vs. X or Y for multiple genders, which the gender module doesn't support, but AFAIK the intended meaning of g=m|g2=f is X and Y. Maybe the gender module should have a way of supporting this distinction? Benwing2 (talk) 02:22, 27 November 2015 (UTC)[reply]
Maybe the way forward is to create individual gender modules for languages with exceptional considerations. I know of at least two Spanish words that have non-semantically varying gender: puente and samba. — Ungoliant (falai) 02:42, 27 November 2015 (UTC)[reply]
I think it would be better to have consistent usage of gender across languages whenever possible. The distinction of nouns that are multiple genders corresponding to different meanings and nouns that have varying gender by usage without a meaning distinction exists in many languages, probably in all languages with grammatical gender, and it would be good if the gender module supports this. BTW I take back what I said earlier about the intended meaning of g=m|g2=f, I think it's actually intended to cover both situations, or at least I can think of words that use it for both, e.g. in дереве́нщина (derevénščina, “yokel”) it is used to indicate an epicene noun (m or f according to the semantic referent), whereas in طَرِيق (ṭarīq, “road”) it indicates a noun whose gender can vary without meaning distinction. Maybe the gender module can be modified to support something like g=m-or-f and g=m-and-f (for Russian this could potentially be e.g. m-an-and-f-an-and-f-in, with more than two genders possible). Benwing2 (talk) 03:26, 27 November 2015 (UTC)[reply]
I'm just gonna butt in here and say that Hindi has several nouns that can be masculine and feminine based on context, and some that can be both depending on the speaker's choice. This is not just restricted to Portuguese. See Category:Hindi masculine and feminine nouns. Aryamanarora (talk) 17:57, 27 November 2015 (UTC)[reply]
It's now been 3.5 days and we still have 1,757 module errors. Benwing2 (talk) 13:17, 29 November 2015 (UTC)[reply]
The one thing we know is that none of those errors is the fault of any contributor to the module. DCDuring TALK 14:11, 29 November 2015 (UTC)[reply]
  • Why does the OP not undo the changes to the checking code, given there is no consensus for them? --Dan Polansky (talk) 18:57, 29 November 2015 (UTC)[reply]
  • I request that Module:gender and number is unprotected so that autoconfirmed editors can edit the page. --Dan Polansky (talk) 19:07, 29 November 2015 (UTC)[reply]
    •   Done I unprotected the module, feel free to fix things. Probably this will get protected again in the near future as a widely used module, but for now unprotecting is for the best, I believe. --Daniel Carrero (talk) 22:41, 29 November 2015 (UTC)[reply]
      • I reverted CodeCat's edits, so Category:Pages with module errors should be emptied once the server finishes catching up with that. I plan to protect the module again later, if that's okay. --Daniel Carrero (talk) 20:25, 1 December 2015 (UTC)[reply]
        • But what about the problems? —CodeCat 21:01, 1 December 2015 (UTC)[reply]
          • If you refer to the widespread usage of m-f (and mf) in Portuguese, there's no consensus for changing that to something else in the current discussion, and a number of people here expected the changes to Module:gender and number to be reverted, so I believe I did the right thing. --Daniel Carrero (talk) 21:22, 1 December 2015 (UTC)[reply]
            • I think a vote should be made to decide whether a separate notation for epicene nouns is desirable, and what notation is preferred for this. I don't mind having a special notation, but "m-f" most certainly isn't it; it's too easily confused with "m|f" (since for every language but Portuguese, "m|f" is used for epicene nouns). It's also not obvious that "m-f" or the resulting output indicates epicene nouns in particular. I also don't like the idea of having two different gender specifiers in one gender; it's logically contradictory. For all other combinations, we never had any problem specifying two genders as, well, two genders. —CodeCat 21:32, 1 December 2015 (UTC)[reply]
              • Above, I suggested improvements to the gender/number module that would support the distinction that m-f vs. m|f for Portuguese is trying to express, approximately between epicene and varying-gender nouns, where in the former the different genders correspond to semantic differences and in the latter they don't. (There is also the case of non-epicene nouns where different genders correspond to semantic differences, e.g. le tour "the turn" vs. la tour "the tower", but these probably should always be given separate headers.) What do you think of these? Benwing2 (talk) 00:33, 2 December 2015 (UTC)[reply]
                • The hyphen separates different parts of a gender specification, so your idea won't work. I think a new gender tag like epi would be much better, as it's clearly distinct from m|f. —CodeCat 00:53, 2 December 2015 (UTC)[reply]
                • Also, something to take note of is that languages may have nouns that are only epicene in some of their inflected forms. To say it another way, the two genders may share a lemma but have different inflections. Italian is an example I could name. This suggests that epicene nouns are really two nouns with different meanings, but (perhaps only partially) overlapping inflections, and we just happen to lump them together for convenience. —CodeCat 00:56, 2 December 2015 (UTC)[reply]
                  • You seem to be missing the point when you say "hyphen separates different parts of a gender specification, so your idea won't work"; this is mere syntax ... (a) there's no reason we can't redefine the way hyphen works, (b) there's no reason we can't use different syntax that doesn't overload the hyphen (e.g. m_and_f instead of m-and-f). Using epi is also fine; but something should be done (or rather should have been done days ago instead of leaving ~2000 module errors for several days). I don't really think a vote is necessary, certainly not at this stage; first find where the consensus is, and only think about creating a vote if no consensus can be reached. Benwing2 (talk) 04:05, 2 December 2015 (UTC)[reply]

About deleting l/en, l/la, l/de and others edit

In some RFDO discussions dating back to April 2015, (which are still open) there seems to be some consensus towards deleting templates on the format of Template:l/de, Template:l/la, Template:l/en.

See discussions:

I am bringing this up on the BP because that is quite a big project: there are a few dozens of templates like this. Most seem to be superfluous to Template:l. You could type {{l|en|buzzard}} and not {{l/en|buzzard}}. These are the templates I'd like to delete.

Some of these templates have actual language-specific purposes: this includes {{l/he}}, {{ja-l}} and {{ko-l}}, which I propose to be kept even if all others are deleted. (but I'd rather move Template:l/he to Template:he-l and leave a redirect, for naming consistency). --Daniel Carrero (talk) 02:57, 26 November 2015 (UTC)[reply]

My impression from the old RFDOs and RFMs is that there is already consensus for all of what you propose. —Μετάknowledgediscuss/deeds 03:31, 26 November 2015 (UTC)[reply]
I think I'm going to create a vote: "Allow bots to change l/la into l|la" and list the specific templates that would be deleted. Even if we have consensus to do that, this involves editing probably thousands of pages in a repeated fashion, so it is clearly bot work. --Daniel Carrero (talk) 06:30, 26 November 2015 (UTC)[reply]
Aren't {{l/en}} etc. meant to reduce page size? That's what I've seen people saying. Aryamanarora (talk) 17:53, 27 November 2015 (UTC)[reply]
{{l/en}} does not add anything over {{l|en}}, it just adds more indirection and confusion. The only argument I can think of in favour of {{l/XX}} is readability. In most fonts l (L) and | (pipe) look very similar, but you can just switch on a monospaced font in the editor. Don't know why this is not on by default. Jberkel (talk) 01:18, 28 November 2015 (UTC)[reply]
Also, the system of l/XX requires the additional work of creating the language-specific templates. Sometimes, the template l/XX exists for a language; for most languages, they don't.
Case in point: Appendix:Proto-Germanic/hirdijaz has descendantes in 15 languages: 9 are linked using {{l}}, 6 are linked using l/XX templates. This is inconsistent. I assume that the process of editing that page involved the avoidable hassle of having to check whether each specific template exists. --Daniel Carrero (talk) 14:58, 29 November 2015 (UTC)[reply]
Another argument: at WT:RFDO#Template:l/la, it has been pointed out that Template:l/la lacks some functionality of {{l|la}}, so rather than being an equivalent template, it is inferior to it. So, we can't take for granted that all l/XX templates have all the desired functionality. --Daniel Carrero (talk) 15:03, 29 November 2015 (UTC)[reply]

I created Wiktionary:Votes/2015-12/Deleting: l/en, l/la, l/de, etc.. --Daniel Carrero (talk) 04:41, 1 December 2015 (UTC)[reply]

Is it right to vote on this? I mean we already have procedure for deleting templates, why bypass it? Renard Migrant (talk) 16:19, 1 December 2015 (UTC)[reply]
@Renard Migrant All these templates passed RFDO already (to be exact, their discussions weren't closed yet, but they are months old and the consensus is clear that they should be deleted).
I assume we need a vote at least for the purpose of letting a bot fix all the entries, don't you think so? Also "Template:l/xx" are still widely used, and last time I checked, there were some people still using it in new entries (like Stääd today and subcontraoctave), so I think not everyone got the memo yet.
Also, maybe it's not a bad idea sometimes creating votes when deleting widely used templates: if someone had a freaking great reason to delete {{en-noun}}, I'd expect it to be voted, rather than RFDO'd. But that's just my opinion, these are probably less used than {{en-noun}}. --Daniel Carrero (talk) 17:24, 1 December 2015 (UTC)[reply]
We've never needed a vote before for a bot to orphan and delete RFDO'd templates. --WikiTiki89 18:08, 1 December 2015 (UTC)[reply]
I don't know about "needing", but I already gave my arguments concerning why I think creating that vote is okay. @Wikitiki89, I found some votes in which it was proposed orphaning and deleting some specific templates.
--Daniel Carrero (talk) 21:44, 1 December 2015 (UTC)[reply]
Ok, I'll go through them one by one:
I don't think that in this case any of the potential precedents above turn out to be applicable. --WikiTiki89 22:19, 1 December 2015 (UTC)[reply]
What do you think of Wiktionary:Votes/2010-10/Deleting Wikisaurus slash-more pages?
Also I'd like to have the ability to create a new vote even in the case of having no precedent for it. If you disagree with the vote, you can vote oppose on principle.
Note: at Wiktionary:Beer parlour/2015/June#The Index namespace, I promised I would create a vote for deleting most of the index namespace, but I'm late for that. I still plan to create such a vote. (as opposed to a RFDO for that purpose) The way I planned it, I am in the process of seeing the indexes of all languages to see where they would fit on the vote. This part has been taking some time; I never got around to finishing it. --Daniel Carrero (talk) 00:30, 2 December 2015 (UTC)[reply]
But templates are different from content pages. Deleting a whole namespace of pages or a whole set of "Wikisaurus slash-more pages" is deleting content, which is a much bigger issue than changing markup, despite the fact that it involves deleting nearly 100 separate templates, since content-wise this change is invisible. See also Dan Polansky's comment at Wikisaurus talk:penis/more#Deletion debate, particularly that "There has been a long-standing precedent to keep "/more" pages in Wikisaurus." The {{l/en}} templates used to serve a useful purpose, but they do not anymore. --WikiTiki89 01:08, 2 December 2015 (UTC)[reply]
Ok, fine. I suppose there's no problem if I delete the vote and start orphaning some of the l/ templates myself? --Daniel Carrero (talk) 03:49, 2 December 2015 (UTC)[reply]
Go ahead. Benwing2 (talk) 03:56, 2 December 2015 (UTC)[reply]
Go ahead, but remember that there is still no consensus about {{l/he}}, so don't orphan that one. --WikiTiki89 15:34, 3 December 2015 (UTC)[reply]
Note also that /more pages vote was "overriding in part the vote Wiktionary:Votes/2006-10/Wikisaurus_semi-protection." When an action overrides a previous vote, it deserves a vote, I think.
I oppose deleting {{l/en}} since it is used in many pages, and deleting it would make page histories illegible. I am okay with deprecating the template. Let's make page histories legible. Let's use a mechanism of deprecation, not deletion, of once widely used templates. --Dan Polansky (talk) 16:55, 5 December 2015 (UTC)[reply]
I just checked and it's used on 13957 pages. Enosh (talk) 19:45, 5 December 2015 (UTC)[reply]
Is there a way to set up deprecation to prevent new entries getting created with {{l/XX}}, or at least warn users? Otherwise deprecation will be useless, and deletion the only way to spread further use of {{l/XX}}. Jberkel (talk) 19:51, 5 December 2015 (UTC)[reply]
I wouldn't mind deleting {{l/en}} and old templates. But to answer @Jberkel, I though of a plan that might be workable: Suppose we make {{l/en}} categorize entries into Category:Entries with obsolete markup. That way, new entries using obsolete markup are listed and can be fixed and previous uses of l/en are preserved, since past revisions are not categorized. But that would require the work of cleaning up the new category from time to time.
There's one more problem: I don't think there are many readable pages before a certain point in time. Take this old revision: https://en.wiktionary.org/w/index.php?title=candy&oldid=13041028 -- It uses context templates ({{cooking}}, {{obsolete}}), {{SAMPA}}, {{proto}} and has some module errors ("The parameter "lang" is required." and "The parameter "xs" is not used by this template.") --Daniel Carrero (talk) 20:39, 5 December 2015 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ The category would be Category:Entries with deprecated templates or Category:Pages with deprecated templates, easy to check and regularly empty for those who care for such things. Someone might even come up with a mechanism by which the wiki would not allow saving a new page containing a deprecated template or even saving any page containing a deprecated template, new or old.
As for the mentioned context templates, e.g. {{obsolete}} should have never been deleted. As far as I know, it was deleted by CodeCat out of process; Template:obsolete and the talk page do not contain any record of there being a corresponding RFDO or a vote. Yes, our revision histories have already been made less legible, but we should stop the practice rather than expanding it.
The module error on "lang" being required should be undone by editing the relevant module. I even remember a discussion where people supported such change and CodeCat opposed but no one got to implementing it. Since CodeCat is usually locking such pages to be editable only by admins, I cannot do such corrections. AFAIR, Ruakh tried to make such corrections but gave up against CodeCat and one of their helpers.
So again, the effort to make page histories legible still has a good chance to succeed, and there is no need to prematurely give up.
Note further that l/en was kept via RFDO as per Template talk:l/en; you need to provide good evidence of overriding consensus. WT:RFDO#Template:l/..., Template:link/... does not provide such evidence, in part since it has fewer participants than Template talk:l/en and thus does not conclusively show that consensus has changed. Given that, I think you idea to create a vote was a good one, or l/en would be deleted by the decision of two editors participating in WT:RFDO#Template:l/..., Template:link/...: Daniel Carrero (you) and Wikitiki89 (I recently added by oppose.). --Dan Polansky (talk) 08:23, 6 December 2015 (UTC)[reply]
OK, weird that the deprecation categories are empty though. Either this mechanism is not used, or the cleanup process is very efficient. From my experience as a software developer deprecations and warnings usually get added and then ignored, that's why I'm in favour of deleting the pages, unless there's a good reason not to. Regarding page history, by not readable you mean not clickable? The information is still there, it's just inconvenient to follow the links. Not deleting templates also means added burden of maintenance, since any changes in non-deprecated versions might need to get propagated to deprecated templates. If nothing ever gets deleted we'll end up with more cruft than necessary. Maybe the non-readable history problem could be addressed differently, on the MediaWiki level. As I understand pages are not really deleted but still kept around? Then it should be possible to implement something like a time machine mechanism, which can reset the state to any given point in time, including all dependent templates. – Jberkel (talk) 11:40, 6 December 2015 (UTC)[reply]
The deprecation mechanism was not used so far. We can start using it. When experience shows here in en wikt that is does not work, then we can consider other options. There's a good chance it is going to work reasonably well. Many people work by copying what they see around; when the deprecated templates are no longer around in the markup of mainspace pages, this copying will not add any new occurrences of deprecated templates.
In SW development, deprecation rather than deletion is a widepsread practice that works reasonably well there. --Dan Polansky (talk) 12:12, 6 December 2015 (UTC)[reply]
In SW development, if the process works well (which it does sometimes), you deprecate first (to maintain compatibility) and then eventually remove the deprecated code (e.g. when you release a new major version). What you're suggesting here though is deprecate and never remove (since it would always break history). That's a crucial difference. I'm not saying a deprecation process can't work, but you need discipline and good tooling, which we currently don't have (warnings etc). Jberkel (talk) 12:52, 6 December 2015 (UTC)[reply]
My guess is that you gain very little by eventually removing the deprecated templates. Once the template is no longer in the mainspace, my best guess is that it will only rarely be returning. But no need to speculate; experience will show. I don't think we need discipline; there are people around who appearently enjoy switching of templates and similar low-value non-lexicographical edits more than expanding the dictionary. --Dan Polansky (talk) 12:57, 6 December 2015 (UTC)[reply]
Let's give it a try then, but I still think deprecation should only be used in rare cases of high-usage templates. We need to hide / obscure these deprecated templates as much as possible, and make it very clear that they should not get used. Jberkel (talk) 13:37, 6 December 2015 (UTC)[reply]
I hate keeping templates in a usable form for the sake of entry history. These templates are pretty new and not actually widely because of that. Also entry histories are still readable as you can click edit, or, click on the red link and read the deletion summary. The sort of people who read entry histories aren't complete newbies they're experienced editors, who understand what a red link like {{infl}} means in an entry. Renard Migrant (talk) 14:07, 6 December 2015 (UTC)[reply]
You do understand that once l/en is removed, the term entered as its parameter will be invisible in the page history as well, right? And if we ever delete {{usex}} since we favor {{ux}}, the complete usage example becomes invisible in the page history. Like, in diff, search for Template:proto and see how you do not see the term itself after proto; the proto was "proto|Dravidian|kaṇṭu" you have to click "edit" to see that. When I examine revision histories, I get repeatedly annoyed by seeing the waste laid by CodeCat, and I certainly do not want to keep clicking "edit" just to read histories. That is what I mean by legibility. --Dan Polansky (talk) 14:17, 6 December 2015 (UTC)[reply]
  • @Dan Polansky, we have been through this a lot, preserving the history is unattainable. Even if we let l/en live forever. We will encounter cases when one template's usage is changed, or even, its whole purpose is changed. --Dixtosa (talk) 16:01, 6 December 2015 (UTC)[reply]
    Cases where a template's usage is changed are rare; only {{m}} really comes to mind, which used to stand for masculine, and even that would not have happened if {{m}} were not deleted out of process. An argument of the style "things are bad, let's make them worse" or "I can't have it all so I will have none" seem rather uncompelling to me, and contain no logical basis. We can do better as for legibility of history by deprecating templates instead of deleting them, and you presented no argument to the contrary. --Dan Polansky (talk) 20:16, 6 December 2015 (UTC)[reply]

term cleanup in user pages and discussion pages edit

@Angr, CodeCat, Metaknowledge, DTLHS, Jberkel, Equinox, Benwing2:

As per User:Daniel Carrero/term cleanup, I was hired by @Angr to add lang= to all instances of {{term}} as a paid job.

There's also a newly-created vote (Wiktionary:Votes/2015-11/term → m; context → label; usex → ux) which proposes to convert automatically all instances of {{term}} with langcode into {{m}}.

I've been doing it on the entry namespace only. (also Help:Misspellings) But we have cleanup categories for other namespaces, too:

Is it okay if I edit others' user pages and discussions to add the language code?

Editing these pages would be a step in the direction of orphaning and probably deleting {{term}}. If these pages still use it, then the template can't be deleted. If the template is deleted, then it's going to break all pages that use it.

(P.S.: I edited this page and readded my signature a few times to add more people to the ping list. Sorry if the notification appeared multiple times to you, I didn't mean to spam.) --Daniel Carrero (talk) 15:32, 26 November 2015 (UTC)[reply]

The pinging didn't work. Anyway, wouldn't there be cases where people were intentionally showing the difference between two templates? We might not want to make the historical archives harder to read. —Μετάknowledgediscuss/deeds 17:22, 26 November 2015 (UTC)[reply]
History, shmistory. That argument has never stopped such an effort before, even though in many ways it trashes one of the key ideas of a wiki. DCDuring TALK 20:04, 26 November 2015 (UTC)[reply]
As I recall, I hired you (Daniel) to clean up Category:term cleanup and all its subcategories, i.e. including the ones for other namespaces. I don't really care whether {{term}} is deleted or not; if it's kept, then once Category:term cleanup and all subcategories are cleared, I'd prefer {{term}} to output an error message if lang= isn't present. That way Category:term cleanup won't fill up again. —Aɴɢʀ (talk) 21:15, 26 November 2015 (UTC)[reply]
I didn't get your ping either, but it's fine with me if you edit other people's user pages to fix this up. I've done this before when making incompatible changes to templates and I think it's more polite to do it than just leave the pages broken, even if many of these pages are outdated. Benwing2 (talk) 01:44, 27 November 2015 (UTC)[reply]
Honestly seems like a waste of time. How is this really helping the dictionary in any significant way? Can't you add missing Portuguese words instead? Equinox ◑ 11:00, 27 November 2015 (UTC)[reply]
I am deeply concerned that someone is getting paid to do the kind of work everyone here does on a volunteer basis. No one's contributions are more valuable than anyone else's. This completely unacceptable. -Cloudcuckoolander (talk) 11:45, 27 November 2015 (UTC)[reply]
User:Dan Polansky questioned this project before, at Wiktionary:Grease pit/2015/November#Suggestion: "term -> m" by bot. There, some people supported the proposal of migrating {{term}} to {{m}}; the latter requires a language code so I'm adding the codes. In the earlier discussion Wiktionary:Beer parlour/2013/April#Template term and lang parameter, some people supported the proposal of making langcodes mandatory for {{term}}.
Advantages of having the language code that were already mentioned before include: all text without langcode is assumed English apparently, and uses the script "None", so using the right langcode would result in proper formatting from both MediaWiki:Common.css and Special:MyPage/common.css. The orange links gadget only works with a language code; also, if we can convert all instances of {{term}} into {{m}}, then the code would look more consistent, because both are often used side-by-side but they are basically the same template under different names. --Daniel Carrero (talk) 11:49, 27 November 2015 (UTC)[reply]
I have little interest in contributing to a project that does not value quality contributions from all editors equally. Either we all get paid, or our only "reward" for editing is knowing we've contributed to the body of free knowledge. I know the former is infeasible, so the only solution is to ban paid editing on this project. I will not contribute any more until it is. -Cloudcuckoolander (talk) 12:05, 27 November 2015 (UTC)[reply]
I suggested doing cleanup work as a paid job at Wiktionary:Beer parlour/2015/October#Boring cleanup work for money. This was based on the earlier discussion Wiktionary:Beer parlour/2012/July#Reward or bounty board, in which someone said "I see no reason why a person doing boring cleanup work should not be paid with money if someone offers that money." and "appropriately clean up Category:Translation table header lacks gloss" is mentioned as one possibility.
According to meta:Terms of use/Paid contributions amendment, Wikimedia allows paid contributions on the condition that they are publicly disclosed, which I did: it's no secret to anyone that I'm doing term cleanup for money.
Anyone can do the same job. Other people are converting {{term}} to {{m}} basically everyday, but it takes a ton of time to do the whole job of manually emptying a cleanup category with 20,000+ entries, so I offered to make it my personal project. It's not that the work of person A is more valuable than the work of person B, I think it's more about the possibility of offering money for choosing what exactly person B is going to do with their time, as long as the community is okay with it. When I first opened the discussion, I even said, basically: "I need money. Want do you want me to do?" The current project was not originally my idea, it was open for the community to choose something if they wanted. --Daniel Carrero (talk) 12:16, 27 November 2015 (UTC)[reply]
Paid editing is completely antithetical to a volunteer project aimed at creating a free repository of knowledge. If we were going to hire an expert to create entries for an endangered language, that would be one thing. There probably aren't a lot of, say, native Ainu speakers hanging around on Wikimedia projects, so entries that do get created might be unreliable. Hiring an expert to create reliable entries would be a reasonable solution in that case. But paying regular editors to do regular work is not reasonable. It's creating a two-tier system where some contributions are valued more than others. Why is the work you're doing considered "boring" enough to warrant monetary compensation? Finding citations, formatting citations, creating requested entries -- these are all time-consuming and sometimes tedious tasks I regularly do. I don't get paid for any of it, and I don't expect to. The point is that most of the work necessary to build and maintain a wiki is time-consuming and tedious. If you want to motivate people to take on tasks no one seems willing to do, find another way. This is counterproductive and wrong. -Cloudcuckoolander (talk) 12:51, 27 November 2015 (UTC)[reply]
Not that I'm completely happy with it, but what we're talking about here is an arrangement between two editors, not any kind of action by Wiktionary or the community. "The project" isn't assigning a different value, Angr is. As for a "two-tiered" system: it's not cold hard cash, but the system has a provision for thanking other contributors for their edits, and we certainly don't restrict people from offering verbal support for some things, but not for others. Daniel does need to be careful about avoiding conflict of interest in his actions as an admin in relation to this, and we need to keep it in mind in judging his votes and other actions as a community member on related matters, though. I probably would be a lot more concerned if he wasn't already active and contributing without this. Chuck Entz (talk) 22:22, 27 November 2015 (UTC)[reply]
Wikis are founded upon the principle of voluntary contribution. The idea is that people freely volunteer their time, energy, and expertise for the common cause of creating a source of free knowledge. Building and maintaining wikis is often a time-consuming, tedious process, but we're all supposed to roll up our sleeves and do our part for the common good. Editors are allowed to decide the quantity and type of work they do. No one is obligated to do things they do not want to do. But they're supposed to do this work freely, knowing their only "reward" is contributing to the body of free knowledge, and the satisfaction of a job well done. When a wiki allows editors to accept payment in exchange for doing regular wiki-work, it's a wholesale abandonment of the most central value – voluntary contribution – upon which a wiki operates, which inevitably alters the terms of engagement for all other editors. And it does create a two-tier system in which it's okay for editors to accept bribes to perform certain tasks deemed so dull that no one could possibly be willing to do them otherwise, but everyone else is expected to continue performing the equally time-consuming, equally vital work they do for the wiki out of the kindness of their hearts. It's undervaluing the work of the wiki's volunteers and taking them for granted. And do you know what being undervalued and taken for granted usually does to a volunteer? It quickly extinguishes whatever motivation they have to volunteer, as it has done in me. I think people are being myopic in how they're looking at this issue. They're seeing it as a simple, clean solution to the very real problem of this wiki's backlog, but is making a dent in the backlog worth the long-term cost of throwing out the central value of wiki culture? It's a Pandora's box that never should have been opened, and needs to be closed before any more damage is done. -Cloudcuckoolander (talk) 18:34, 28 November 2015 (UTC)[reply]
@Daniel Carrero If you want another project, I have a list of over 200 sets entries that need to be merged (that is, the entries are alternative forms of one another but have full entries). But you’ll have to convince someone else to provide the dough as I’m also unemployed lol! — Ungoliant (falai) 12:30, 27 November 2015 (UTC)[reply]
I'll do it for $10 (dollars) or R$40 (reais) through this PayPal link. :) Also I don't mind if I'm opening a "market" for paid jobs on Wiktionary -- someone else might see my message and offer R$30 to get the job. --Daniel Carrero (talk) 12:53, 27 November 2015 (UTC)[reply]
That said, (like anyone, I suppose) I've been known to do stuff for free as a favor, when people ask me to. The term cleanup is the only project I am doing, or have done in the past, that is an exception to that.--Daniel Carrero (talk) 22:45, 27 November 2015 (UTC)[reply]
I don't see a problem with editing user pages, if an explanatory comment is left in the summary. Maybe it should be done as a last step, just before deleting {{term}}. Which I think should be done, if we keep both {{m}} and {{term}} around there's more confusion on which template to use.
Regarding the payment discussion – I've also contributed money to Daniel's project because I think it is useful, although maybe not in an immediately obvious way. It's sort of long term data hygiene. I really don't see how anyone could object to this, you can't compare this situation to the paid-edit discussion on Wikipedia. We're talking about boring cleanup work, which is almost automatable work but not quite. There's nothing controversial about it, and I'm glad somebody is focussing on it, because it just wouldn't get done otherwise. Jberkel (talk) 01:00, 28 November 2015 (UTC)[reply]
I don't personally have any problem with Daniel getting paid (not a whole lot, it seems), esp. for doing cleanup workof the sort that's useful but people often don't want to do. Benwing2 (talk) 07:52, 28 November 2015 (UTC)[reply]
User:Rodasmith is protected, I was going to do that one. Renard Migrant (talk) 12:38, 4 December 2015 (UTC)[reply]
Migrated. —Rod (A. Smith) 20:23, 23 December 2015 (UTC)[reply]

When is a plural not a plural? edit

<Sorry for the chemistry context - probably more general than that.> The word tripalmitins has recently been added, with the definition of "plural of tripalmitin". Now tripalmitin is a specific organic compound that doesn't really have a plural. But the plural form is easily attestable, in sentences such as "Thin layer chromatography of saturated lipids in the fat indicated the presence of mono, di and tripalmitins." The author here means "the presence of monopalmitin, dipalmitin and tripalmitin" and has chosen to put the "s" on the last member of a list to signify all members of the list. So, is the term (as used in this example) a plural? If not, what is it? SemperBlotto (talk) 08:52, 27 November 2015 (UTC)[reply]

I'd say it's really "mono-, di- and tri-" + "palmitins", like how "hydrochloric and sulphuric acids" isn't really "hydrochloric and" + "sulphuric acids" but "hydrochloric and sulphuric" + "acids". "tripalmitins" itself is not a word in that sentence, any more than "mono" or "di" are. I'd say this is something that we should exclude on a commonsense basis, just as we'd exclude "thes" as the plural of the word "the" ("There were seven thes on the page"). Smurrayinchester (talk) 10:53, 27 November 2015 (UTC)[reply]
I saw examples other than that kind. There are some that are just "tripalmitins" alone. Equinox ◑ 10:58, 27 November 2015 (UTC)[reply]
The only other examples I can see are variants on "labeled tripalmitins" – these would be different tripalmitin molecules which have been synthesized with radioactive isotopes (carbon 14) in order to allow the otherwise indistinguishable tripalmitin samples to be told apart. It's a bit like orange juice – uncountable, but you could say "South American orange juices contained more vitamin C than North American ones" if you did a scientific study that artificially categorized the juices. Smurrayinchester (talk) 12:03, 27 November 2015 (UTC)[reply]
Yes, I'm not questioning its existence as a real plural (in specialised usage); I just thought there might be an aspect of grammar that I wasn't familiar with. SemperBlotto (talk) 12:07, 27 November 2015 (UTC)[reply]
To me it seems like a result of the deepening of analytical knowledge. Someone defines something that is unique in a domain or context. Then someone looks into it further and discovers or invents variations, rendering the plural necessary to encompass the variation, at least in some contexts. For our purposes we should just have a plural without a lot of explanation. DCDuring TALK 16:25, 27 November 2015 (UTC)[reply]
I agree that we have to weed out things like "mono-, di- and tri-palmitins" and e.g. "myristic and palmitic acids", per Smurray; compare Talk:Asperger's syndromes. (But, on the subject of palmitic acids, I can find 2012, Osamu Hayaishi, Molecular Mechanisms Of Oxygen Activation, →ISBN, page 45: "The mechanism in the formation of a-hydroxy acids in the leaf system has been studied with palmitic acids stereospecifically labeled with tritium at C-2 and C-3 (80, 81).")
On the other hand, if uses like "labeled tripalmitins" are attested, then I think it would be reasonable to have tripalmitins as a plural of tripalmitin. If we wanted to, we could expand the definition of "tripalmitin" by adding to the end something like "...; an instance of this triglyceride", but I don't think it would be necessary; happiness lists happinesses as it plural without bothering to expand its definition-line, and likewise other words affected by the routine phenomenon of pluralization of things that might be argued to be conceptually unpluralizable, such as (all attested on Google Books) "oxygens", "uraniums", "carbon monoxides", "angers", "Jewishnesses", etc. - -sche (discuss) 18:12, 27 November 2015 (UTC)[reply]

Category:English proper noun plural forms edit

Given before we just had Category:English plurals, shouldn't we now starts discriminating between noun plurals and proper noun plurals? Plenty of proper nouns have them. Like given names and surnames; Steves; Stephens, Matthews, Dianes and so on. Renard Migrant (talk) 13:05, 27 November 2015 (UTC)[reply]

They're not really any different in nature from regular noun plural forms, so I don't think a distinction is really useful. —CodeCat 16:27, 27 November 2015 (UTC)[reply]
Wiktionary:Votes/pl-2011-12/Merging proper nouns into nouns, a vote to merge proper nouns into nouns, failed. Wiktionary:Requests for moves, mergers and splits#Merge_Category:.28language.29_proper_noun_forms_into_Category:.28language.29_noun_forms showed (!vote-level, by which I mean 2/3rds) consensus not to merge "proper noun forms" into "noun forms". So, yes, "proper noun plural forms" should be separate from "noun plural forms", unless someone can demonstrate enough consensus to merge them to overrule the consensuses I just linked to. - -sche (discuss) 17:39, 27 November 2015 (UTC)[reply]

New Latin vs. Translingual edit

At the entry lycaenid, there is "From New Latin Lycaenidae." in the etymology. I added the code mul to the term, under the assumption that Lycaenidae won't ever have a Latin section, just the Translingual section. I didn't change the "New Latin" part. I've seen some entries saying "From Translingual blablabla.", but "New Latin" is more specific than "Translingual", so I wouldn't want to remove that information from the entry. What I did here is probably what I'd do for other entries, so feel free to suggest if I should do anything different. --Daniel Carrero (talk) 13:16, 27 November 2015 (UTC)[reply]

No, I think that's what I'd do too. Aryamanarora (talk) 17:51, 27 November 2015 (UTC)[reply]
If the etymon is clearly a taxonomic name, as Lycaenidae is, we should call it Translingual, even were it pre-Linnaean. DCDuring TALK 20:29, 27 November 2015 (UTC)[reply]
From New Latin is fine; just use the language code mul with it. Renard Migrant (talk) 20:42, 27 November 2015 (UTC)[reply]
I edited lycaenid and lycénidé to add from "Translingual" as well as "New Latin" and categorize the entries in both derivations categories. --Daniel Carrero (talk) 21:28, 29 December 2015 (UTC)[reply]
@Daniel Carrero The subsequent application of {{der}} wiped out the New Latin display and categorization. DCDuring TALK 16:53, 16 November 2016 (UTC)[reply]

Alternative forms: chains and cycles edit

User:DTLHS/cleanup/alt form chains contains cycles or chains (of length >= 2) of alternative forms. Some of these might be legitimate. DTLHS (talk) 05:32, 29 November 2015 (UTC)[reply]

Thanks for doing this. Reminds me of an old copy of Encyclopedia Americana we had when I was a kid ... I looked up "rabies" and it said "see hydrophobia". So I looked up "hydrophobia" and guess what it said?
The cycles seem clearly wrong; the chains less obviously but I suspect a bot should clean them up, akin to removing double redirects in Wikipedia. Benwing2 (talk) 07:20, 29 November 2015 (UTC)[reply]
Thanks, this is useful. Some chains and even some cycles are legitimate (see e.g. sea-purse vs sea puss, two etymologically distinct terms, each most common with one spelling but also spellable the other way). Other cycles are the result of typos, e.g. sope, which had linked to itself. - -sche (discuss) 08:47, 29 November 2015 (UTC)[reply]
Are you sure about sea-purse vs. sea puss? It looks like 'sea purse' has two meanings, one of which is a rare alternative of 'sea puss', but it's less obvious to me that the meaning "egg case" has 'sea puss' as an alternative; if so, it should indicate this using an "Alternative forms" header. Benwing2 (talk) 09:02, 29 November 2015 (UTC)[reply]
Google is constantly digitizing more old books, and new books, so it's possible the situation now is different than when I created the entries in 2012 — but at that time I found that skate egg cases were usually called "sea-purses", but sometimes by confusion with the other term "sea pusses", whereas rip currents were usually called "sea pusses" (and channels through sandbars were often "sepooses"), but sometimes by confusion with the other term "sea-purses". Looking at it now, I'll add glosses to make that (hopefully) easier to follow. - -sche (discuss) 09:25, 29 November 2015 (UTC)[reply]
The Old French ones all need correcting apart from peis which is an alternative form of pois, while pois in alternative form of poi but a different etymology and gloss. The high number of Old French ones is due to the old merger of Anglo-Norman and Old French, plus a lack of double-checking. FWIW I think there are a couple in there that aren't me. Renard Migrant (talk) 14:19, 5 January 2016 (UTC)[reply]

Wiktionary:Votes/2015-11/Fix tense: start/end in votes edit

FYI: Created Wiktionary:Votes/2015-11/Fix tense: start/end in votes. --Daniel Carrero (talk) 07:42, 29 November 2015 (UTC)[reply]

Wiktionary:Votes/2015-11/Namespace abbreviations edit

I delayed the start of this vote a little, it's going to start in 4 days. (in Dec 4 2015)

Please check to see if you agree with the list of namespace abbreviations before the vote starts. You can suggest abbreviations for other namespaces, you can change the proposed abbreviations, you can edit the vote, etc. --Daniel Carrero (talk) 04:17, 30 November 2015 (UTC)[reply]

Regarding sections such as "Derived terms" and "Hyponyms" edit

There are section such as "Derived terms" and "Hyponyms".
There should also be the possibility to have a section like "Derived hyponyms". See for example the German word Lehrer: Many words are both derived terms and hyponyms, and listing them twice is annoying and redundant.
"Derived synonyms" and "Derived antonyms" could be possible too, but as there should only be a few derived synonyms, if there are any, this shouldn't be needed. E.g. Versfuß is a derived synonym for one meaning of Fuß, but there aren't dozens of derived synonyms. — This unsigned comment was added by 84.161.53.170 (talk) at 22:43, 30 November 2015 (UTC).[reply]

If they are both hyponyms and derived terms, then list them under both, since they are both. —CodeCat 22:45, 30 November 2015 (UTC)[reply]
Having numerous header combinations like "Derived hyponyms", "Derived synonyms", "Related antonyms", etc. would be equally (or more) annoying and redundant. Equinox ◑ 23:02, 30 November 2015 (UTC)[reply]
Hyponyms (and other semantic relations), which appear above Derived terms, thereby have some kind of priority IMO. Thus, I usually have any terms that could be inserted under both headings only under the Hyponyms heading. In any event I normally view Derived terms as less important than the semantic relations. They could probably be added by an automated process, whereas the semantic relations cannot (yet) be so added. DCDuring TALK 23:49, 30 November 2015 (UTC)[reply]
My feeling is that, here, derived terms are more important that semantic relations such as hyponyms, which are more encyclopedic than linguistic, and better added to thesaurus pages. A few ones may be useful in the main page, but long lists (tens or hundreds of words) should be in thesaurus pages: they relate to the meaning, and are shared by all synonyms. On the other hand, a long list of derived words is a good thing in the lemma page, because it's linguistic information about the word. Lmaltier (talk) 21:10, 1 December 2015 (UTC)[reply]
I agree, we don't have to analyse all the semantic relations in intricate detail. Synonyms and antonyms are enough. —CodeCat 21:12, 1 December 2015 (UTC)[reply]

German declension table templates edit

  1. See for example Wikiwörterbuch and Konfix. The dative forms ending in -e should not be attestable, so the declension template creates wrong forms.
    Maybe it would be better to have some parameter to not add dative e, to add dative e and to add dative e and a note.
  2. Maybe it would be better to shorten "see notes". E.g. it could simply be "?" with a link, similar to en.wikipedia.org/wiki/Template:Nihongo . Maybe "i" (for information) or an icon with "i" instead of "?" could be better though. — This unsigned comment was added by 84.161.53.170 (talk) at 22:43, 30 November 2015 (UTC).[reply]
I have made the see notes a footnote. How does that look? —JohnC5 09:55, 4 December 2015 (UTC)[reply]
@JohnC5 It looks fine except that the see notes footnote is a bit confusing; my first instinct was to look for notes elsewhere on the same page. Also, having a footnote symbol refer to a footnote which refers to another page may be needlessly cross-referential. Since we have more space in the footnote, you might want to make it say mostly archaic, see link with the see link text linking to the appropriate discussion. Benwing2 (talk) 01:43, 9 December 2015 (UTC)[reply]
@Benwing2 How about now? —JohnC5 06:05, 9 December 2015 (UTC)[reply]
@JohnC5 Looks good. Benwing2 (talk) 06:07, 9 December 2015 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Beer_parlour/2015/November&oldid=71472519"