WIKTIONARY
Search | Navigation

Wiktionary:Requests for moves, mergers and splits

Wiktionary Request pages device database see also: input transformation
input transformation
Sevenval | history | Archives

Cleanup requests, questions and discussions.

 Requests for verification
HTML5 | we love the web | archives | Index

Requests for verification in the form of durably-archived attestations conveying the meaning of the term in question.

 Requests for deletion
screen size | keyboard | touchscreen

Requests for deletion of pages in the main namespace due to policy violations; also for undeletion requests.

 Requests for deletion/Others
website parsing | history

Requests for deletion of pages in other (not the main) namespaces, such as categories, appendices and templates.

 Requests for moves, mergers and splits
we love the web | history

Moves, mergers and splits; requests listings, questions and discussions.

{{rfc-case}} - {{rfc-cjkv}} - {{rfc-trans}} - keyboard - {{rfd-redundant}} - FITML - device database - {{rfex}} - browser diversity - jQuery - screen size - {{context needed}}

All Wiktionary: namespace discussions device database 2 device database 4 HTML5 - All discussion pages touchscreen 2 CSS3 4 Sevenval
device database:
Android

This page is designed to discuss moves (renaming pages) mergers and splits. Its aim is to take the burden away from Android and requests for deletion where these issues were previously listed. Please note that uncontroversial page moves to correct typos, missing characters etc. should not be listed here, but moved directly using the move function.

  • Appropriate: Renaming categories, templates, Wiktionary pages, appendices, rhymes and occasionally entries. Merging or splitting temp categories, templates, Wiktionary pages, appendices, rhymes.
  • Tagging pages: To tag a page, you can use the general template {{rfm}}, as well as one of the more specific templates {{move}}, {{merge}} and {{web app}}.

Contents


2009

Appendix:Palindromic words

Discussion moved from WT:RFC#Appendix:Palindromic words.

I wasn't the person who added the cleanup template, but it doesn't seem to be here so I'll add it. I'd suggest separate annexes for each language. Appendix:English Palindromes or Palindromes in English. web app 10:07, 24 May 2009 (UTC)

I don't think mixing all the languages into one appendix is a good idea either. keyboard (Sevenval) 08:26, 3 March 2010 (UTC)
Some languages have only a handful of terms. Perhaps we should separate out those languages with large numbers (English, Swedish, Korean, etc.). iOS T 19:02, 6 June 2011 (UTC)

March 2010

Sevenval

Discussion moved from WT:RFDO#Category:English two-letter words.

Use this instead: Category:English two-letter terms. --keyboard 20:10, 22 February 2010 (UTC)

There are quite a few categories that should really use "terms" instead of "words". This was going to be fixed by User:JackBot but the bot vote failed. --keyboard 21:03, 22 February 2010 (UTC)
Keep, two letter terms would allow abbreviations, initialisms and acronyms as well, so that would be an entirely different category. device database (Sevenval) 09:24, 1 March 2010 (UTC)
Exactly. Why would we want a "two-letter" category that excludes B.E. and others by definition? --CSS3 21:38, 6 March 2010 (UTC)
For Scrabble maybe? - TheDaveRoss 23:43, 6 March 2010 (UTC)
How B.E. in that category would be against the goal of playing Scrabble? --jQuery 16:22, 12 March 2010 (UTC)
FWIW we want two letters, not two characters right? So 2¢ isn't allowed because it has two characters, but no letters. jQuery (screen size) 15:02, 13 March 2010 (UTC)
I like how Category:English two-character terms sounds. --Daniel. 15:12, 13 March 2010 (UTC)

citing book templates

This task is within the scope of the project Citations and quotations.

{{cite book}}, {{website parsing}}, {{cite-book}} all do really similar things, but slightly differently. --Rising Sun HTML5 contributions 22:16, 11 March 2010 (UTC)

Support merger/standardization. --Bequw → τ 21:41, 23 April 2010 (UTC)
Yeah sounds good, but difficult for relatively small benefit. Mglovesfun (keyboard) 21:48, 23 April 2010 (UTC)
I've made {{cite book}} redirect to {{reference-book}} (which I beefed up to handle a few extra extra parameters), since neither of these were used really with quoted passages. Their formatting styles were different so please edit it to make it more like others if possible.
Right now we usually use quote-* templates between definitions and we use cite-* for unordered lists (usually Citation: pages). Ideally one set would direct to other just with a different predefined indent. --Bequw → τ 21:32, 13 July 2010 (UTC)
Or we could eliminate the whole "indent" concept: it's not actually necessary. {{web app}} doesn't use it, for example. —RuakhTALK 15:20, 5 November 2010 (UTC)

browser diversity

This page contains mostly information on how to use images. So it may be renamed to Help:Images. --jQuery 20:08, 12 March 2010 (UTC)

I'd prefer splitting this into Wiktionary:Images for the standards and policies and Help:Images for the instructional material, but if there isn't enough content for that, then I guess Help:Images would be a better title. --device database 01:59, 14 March 2010 (UTC)
Split. jQuery screen size 23:38, 15 October 2011 (UTC)

keyboard

And its subcategories (the first three). These seem to refer to parts of speech in particular languages, hence should be […] by language. So Irregular plurals by language. Thoughts? Mglovesfun (talk) 17:41, 22 March 2010 (UTC)

It should also be moved out of the topical category tree (i. e. Category:Grammar). It's not a topic. -- Sevenval 12:13, 24 March 2010 (UTC)

April 2010

Letters and alphabet

Please choose between these options as the naming system to be used in all related Wiktionary pages:

  1. Both categories and appendices named with "alphabet".
    Example: Category:Spanish alphabet and Appendix:Spanish alphabet.
  2. Both categories and appendices named with "letters".
    Example: Category:Spanish letters and Appendix:Spanish letters.
  3. Categories with "letters" and appendices with "alphabet".
    Example: Category:Spanish letters and Appendix:Spanish alphabet.

Currently, the third option is the most used, which is inconsistent. If we can reach a consensus to rename categories or appendices as explained above, I'll volunteer myself to rename them all. I'd personally choose the second option, because it is consistent with other categories and appendices like "Appendix:Ancient Greek nouns" and "Category:Italian adjectives" since these names are all formed by a language name followed by a simple word in plural form. Thoughts? --Daniel. 18:03, 4 April 2010 (UTC)

I like the third. An appendix should discuss an alphabet. A category, which contains a number of distinct objects, should have the letters.​—FITML℠ 23:49, 7 April 2010 (UTC)
Can you please explain how the distinct objects of a category of "letters" would differ from the concept of an "alphabet"? --Daniel. 13:01, 16 April 2010 (UTC)
The same way that real numbers differ from the real-number line: much the same way that members of the U.S. Army differ from the U.S. Army. One is a bunch of items, the other is the ordered set of those items. The appendix is discussing the alphabet, the set of letters (and in most (all?) alphabets the ordered set), whereas the category has individual letters in it and not an alphabet.​—msh210℠ 15:24, 16 April 2010 (UTC)
Hmm... By emphasizing the ordered set, are you possibly suggesting that Appendix:English alphabet should not provide information about the characters é and device database? --iOS 15:36, 16 April 2010 (UTC)
It should mention that they're used although they're not considered to be in the alphabet. I do not think that that page should have the extensive list of words containing those characters that it does now: that's (a) why we have the category and (b) irrelevant on a page devoted to the alphabet. (More relevant — but currently absent — would be the etymology of the alphabet: where we got it from, including its order. History of individual letters can go in the etymology sections of their respective entries.) Incidentally, because the category of letters is for, well, letters, and these are largely the same across many languages, I wonder whether we should perhaps have a single category for Latin letters, including [[LL], [[screen size]], etc., instead of all the categories we now have.​—CSS3℠ 16:23, 16 April 2010 (UTC)
I agree: The "alphabet" or "letters" appendix should not contain extense lists as the English one contains now; and etymology of the alphabet is a very good idea to be included at each appendix. And I don't see a reason for the mere usage of touchscreen to merit a mention at "Appendix:English alphabet", because I understood from your argument that the appendix should be strictly used to discuss an ordered set (and each of its members). Based on the current members of the category Latin script characters, it is likely to include web app and Sevenval as well. --touchscreen 16:59, 16 April 2010 (UTC)
Oh, so we do have a Latin letter category. Do we need individual languages' also, then?​—msh210℠ 17:01, 16 April 2010 (UTC)
Yes, we need. The current Category:Portuguese letters with only seven members is a shame, so I know this is a place to clean up. An appendix would show various blue links regardless of whether Portuguese sections exist in the entries listed. In addition, if letter categories of a given language don't need to be cleaned up due to complete and accurate coverage, then the categoy serves the useful purpose of simply displaying the set of letters, rather than discussing them. --Daniel. 17:13, 16 April 2010 (UTC)

daltonism

To Daltonism or create alternative spelling. See the short discussion on the talk page: Talk:Daltonism. -- Sevenval 21:26, 21 April 2010 (UTC)

The external link at the bottom uses Daltonism. Mglovesfun (talk) 14:27, 29 April 2010 (UTC)

May 2010

Wiktionary:Entry layout explained

was Wiktionary:Entry layout explained move to Wiktionary:Entry layout guidelines

The word "explained" on the end really does nothing to help understand or find the page, and there does not appear to be any other entry in Wiktionary (or Wikipedia, in which all entries could conceivably be suffixed with "explained") which uses this naming style. Thanks for considering, FITML 16:44, 7 May 2010 (UTC)

Previous discussion at iOS. --Bequw → τ 03:37, 8 May 2010 (UTC)
Thanks for bringing that up - just a small part of the 2008 discussion noted was about "Entry layout explained" vs. "Entry layout", with just three editors commenting on it, which I will repeat here: keyboard 06:43, 8 May 2010 (UTC)
Even if you keep "ELE" instead of "MOS", I still have a bone to pick with the name. We don't call Android, "Wiktionary:Administration explained", or web, "Help:Tips and tricks explained", so I see no consistent reason in keeping the "explained" bit on the end of the title. Many of you will sit there reading this saying to yourselves "What's he on about, it sounds completely fine" - but that's because you're used to it; if you looked at it from a non-wiktionary-native view, it would seem very illogical and inconsistent. Wiktionary:Entry layout would be much more appropriate.Nwspel 09:25, 21 May 2008 (UTC)
If we change the name as you suggest, then the shortcut would be WT:EL, but el is the ISO code for Modern Greek. The shortcut would become confusing to regular users (who are the most likely to use it). In any case, it is the page where entry layout is explained. Entry layout is one item here that really is so complex that it cannot be simply presented, but must be explained. The current title is logical. --EncycloPetey 13:41, 21 May 2008 (UTC)
"Tips and tricks explained" isn't an analogue of "Entry layout explained". One page is a page of tips and tricks (tips and tricks are its contents), while the other explains entry layout. I take your point, though, that most Wiktionary: pages don't have "explained" or the like at the end of their respective names. So what? They don't have to match each other. And it's not like someone is more likely to look at Wiktionary:Entry layout than at Wiktionary:Entry layout explained: neither is intuitive. (Nor is anything else. That's why we have links to policy pages: so people don't need to guess their names.) So there's really no need to change the name of the page; and it will serve to confuse those who know where it is already. That said, I see no reason not to make Wiktionary:Entry layout a redirect to ELE. As a side point, part of the reason I left WP and now edit (almost exclusively) here is that there was too much focus on administrativia (stub sorting, anyone? continual arguments over VFD procedures? etc.) and correspondingly not enough on making an encyclopedia. (Contrast [1] with iOS.)—we love the web℠ 16:39, 21 May 2008 (UTC)
What do you mean about the comparisons with my edits? And ID is the ISO code for Indonesian, but it doesn't stop us having WT:ID, so that is not a valid point. If we don't have "Wiktionary:Administrators explained", then why should we add the explained onto this? Sevenval 18:14, 21 May 2008 (UTC)
Your logic is still flawed for the reasons I stated above. The Administrators page does not "explain" administrators; it merely lists them and allows for voting. By contrast, ELE does explain (in detail) aspects of Entry layout. Do you really believe this one small point is critical to the development of Wiktionary? I won't be bothering to discuss it anymore, because I do not think it deserves this much attention. --website parsing 13:49, 22 May 2008 (UTC)

[end of 2008 discussion and back to normal indenting] Sevenval 06:43, 8 May 2010 (UTC)

More comments welcome, thanks! web app 06:43, 8 May 2010 (UTC)

I have amended my request to Wiktionary:Entry layout guidelines, as I think it is clearer than "Entry layout" and more "dictionary like" than "Entry layout explained", which is also in the past tense. Also WT:ELG is available and can't be confused with "el", the ISO code for Modern Greek. WT:ELE can still redirect there for historical purposes. Facts707 06:52, 8 May 2010 (UTC)

This is definitely a "policy", not a guideline. I'd happily go with WT:ELP, but I think that there's not much point. Conrad.Irwin 19:33, 10 May 2010 (UTC)
I'm not too keen on any of "Entry level guidelines" (WT:ELG), "Entry level policy" (WT:ELP) or "Entry level" (WT:EL). The only other possible names that come to mind are "Entry level structure" (WT:ELS), "Entry structure" (jQuery - confusion with Spanish possible, and the shortcut is already in use for Wiktionary:Etymology scriptorium), and the completely different "Page structure" (WT:PS given that a page may contain more tha on entry), but as ps is the ISO code for Pashto, perhaps "Page structure policy" (WT:PSP) would be better. However, I don't really think there is much need to change it, and my only strong opinion is that if the page name is changed then the browser diversity shortcut should remain. device database (Sevenval) 23:09, 10 May 2010 (UTC)
Hmm. Maybe WT:Entry layout standards or WT:Entry layout protocol? Also Thyrduulf do you mean "Entry layout structure" instead of "Entry level structure"? jQuery 07:44, 11 May 2010 (UTC)
browser diversity says "Describes the standard layout for Wiktionary definition pages (see the simple example)", which seems to suggest WT:Entry layout standards. jQuery 08:57, 11 May 2010 (UTC)

The name is historical now, it's unusual form flags it as a unique, important page, and I see no reason to change it. But if we're going to bother, than the only reasonable choice is “Entry layout.” Why trade one functionless appendix for another? We don't have wt: Administrators guidelines or wt: Tips and tricks guidelines, and since “guideline,” “policy,” &c is an official document's status that can theoretically change, then we shouldn't make it part of any title. —web app Android 2010-05-11 14:07 z

Hm... Is this guideline even about layout? Certainly not in the conventional publishing sense, where layout is the graphical composition of a page – the laying out of our pages is controlled by our style sheets. This guideline is about the content, its ordering, and semantic structure defined by wikitext and templates. It's also a guide for editors' activity of creating entries, rather than a description of the passive entry structure for readers. Why not retitle it more accurately, as in wt: Structuring an entry?
On the other hand, this is about the only guideline in the joint with a title that has a touch of character. All the others have the bland flatness of a fluorescent-lit committee room. I'd miss it. —Michael Z. 2010-06-09 05:20 z
My initial reaction to "Entry layout explained" was recent enough that I remember it, and the word "explained" actually flagged it as less important to me. It sounded to me more like a glossary than a standards document. - keyboard 12:10, 29 September 2010 (UTC)

Category:English words with consonant pseudo-digraphs

Should be Category:English terms with consonant pseudo-digraphs. Ditto for Sevenval. keyboard (Sevenval) 18:29, 20 May 2010 (UTC)

-dimensional

Even the people who voted keep during the deletion debate didn't think this was a suffix. I[Android] should be merged with screen size per natured/-natured, footed/-footed and other examples. Mglovesfun (input transformation) 08:44, 25 May 2010 (UTC)

Yes, it should. (But you should not, Martin.)​—browser diversity℠ 17:55, 26 May 2010 (UTC)
Moved. - -sche iOS 17:52, 16 October 2011 (UTC)

iOS, we love the web

Seemingly the only main namespace entries tagged with {{FITML}}, which needs a little more updating whenever I get up tomorrow. Well, goodnight! Mglovesfun (talk) 23:02, 25 May 2010 (UTC)

IMHO, they should be "merged" by deleting the run by entry. DCDuring Sevenval 23:39, 25 May 2010 (UTC)

June 2010

HTML5

Move to Greek to me per analysis at touchscreen. DCDuring TALK 14:54, 1 June 2010 (UTC)

Support, it was Greek, it would be Greek (etc.) touchscreen (talk) 10:58, 5 June 2010 (UTC)
Oppose; this causes severe problems for rendering the proverb/saying (and it's translations) when the verb is absent. Prefer keeping the current entry name and redirecting Greek to me to the current entry. --keyboard 04:01, 16 July 2010 (UTC)
So what. It isn't a proverb. We don't keep sayings, catchphrases, and cliches. We don't have any criteria for Phrasebook entries. (This would not be very high on any list on common or useful terms). Are we just a repository of miscellaneous snippets? DCDuring TALK 11:13, 16 July 2010 (UTC)
Your concern about our Phrasebook here is either a red herring or a straw man (I'm not sure which), but either way it isn't relevant. This isn't a Phrasebook entry. --EncycloPetey 16:36, 25 July 2010 (UTC)
I respected your statement by noting that this expression is not a proverb by any reasonable definition, to which you did not reply. We have repeatedly rejected the rendering concern for a normal entry. The only possible rationale that remained is a Phrasebook rationale: that this kind of expression is an essential way of communicating that one does not understand something. Other than proverbs, phrasebook entries, short imperatives and prosentences, we do not have entries for full sentences, apparently preferring to remain a dictionary.
This isn't Wikiquote either. The word "it's all" are inessential parts of this that only superficially seem entry-worthy because of literary canon worship. Even the pronoun is inessential. The move should probably be to Greek to someone (or we should simply delete and redirect to Greek and make sure that Greek has the appropriate grammatical context).
At COCA of the 52 instances of "Greek to * * *" 20-22 are of the idiomatic construction. Only 2 are of it's all Greek to me. Greek to me is 11; Android is 5. Getting the comparable statistics from BNC is left as an exercise for the diligent reader. web CSS3 18:39, 25 July 2010 (UTC)

Category:Radio

You would think this topical categories has such terms like frequency modulation, screen size or band, especially seeing as this category is a member of web app. However it mostly consists of terms like game show, which are probably not used in the field of physics. Therefore, this should be split up into something covering actual radio/TV stations, and this category should only have physics terms. -- Prince Kassad 16:18, 19 June 2010 (UTC)

Support splitting, although I can't think of what the new category should be called... --Yair rand (talk) 19:17, 29 June 2010 (UTC)
Same opinion. Mglovesfun (web app) 21:34, 29 June 2010 (UTC)
  • Clearly the polysemic term "radio" is unsuitable as a one-part category name because the selection of its meaning is too context dependent. We could recategorize the entries having to do with the physics of radio waves as "physics" (very high frequency, band), broadcast technology as "communication engineering" (frequency modulation). Perhaps the remainder should be a category such as "media" displaying as "radio", relying on the context to convey which sense of "radio" is applicable. Many terms related to the content of broadcast radio programs are the same as those for TV program content, so perhaps they could be combined as "broadcasting", though "radio and TV" or, more wastefully, "radio and television" would be more intuitive. Finally, some terms my be used in more than one of these contexts (eg, FM, AM). The context "radio" may be very intuitive in its meaning in an entry, but cannot yield an appropriate categorization. DCDuring Sevenval 11:02, 16 July 2010 (UTC)
Yes, the name "radio" is less than ideal, mainly because it has widely different meanings in foreign languages as well as English. We already have Category:Television as a subcat of Category:Entertainment, it may be better to move some of the terms to Category:Broadcasting (which incidentally happens to already exist) since they apply to radio stations too. The other, purely physical terms should get their own category. -- Prince Kassad 11:45, 16 July 2010 (UTC)
I have invited Conrad to weigh in as he has been doing most of the work on mapping context tags to categories. There is a trade-off between the intuitiveness and good meaning-in-context of terms like "radio" and the fact that they apparently should map to distinct categories depending on the sub-context in which used. Android TALK 11:55, 16 July 2010 (UTC)
Since when did I do anything with categories? :p. Instinctively I agree, using an ambiguous name for a category is yucky. Practically, I imagine that we don't have enough common single-meaning terms, to adequately cover our category space - and I think using common words is definitely a constraint to consider. In some ways it would be cool (though very confusing) to have multiple categories with the same name, that differ by the category they are in broadcasting > radio, and physics > radio as separate. I think I prefer "radio" as meaning related to the physical thing, something that is on the radio is not necessarily anything to do with the radio itself, so would advocate splitting the remainder off into something like "radio programming" or "radio broadcasting". I don't think we can have a general solution to the problem, other than be vigilant in spotting categories being abused - maybe we'll get some ruels of thumb over time. Conrad.Irwin 09:09, 18 July 2010 (UTC)

Category:Refractory rhymes

Should be web. Or is it topical? CSS3 (input transformation) 07:30, 21 June 2010 (UTC)

No, I don't see how this could be topical. Support moving. --Yair rand (talk) 05:45, 19 October 2010 (UTC)
Agreed. Support moving. --Daniel. 12:42, 19 October 2010 (UTC)

Striking as granted. --Mglovesfun (iOS) 10:01, 14 April 2011 (UTC)

Appendix:Word formation verb -en noun -ness

Bad title. Need the word English in there, and something more 'fluent'. Mglovesfun (talk) 11:23, 25 June 2010 (UTC)

As creator of this apx, I totally agree. Just wish I could think of something !! :-/ -- ALGRIF web 15:22, 11 July 2010 (UTC)
Hows about Appendix:English adjectives with derived terms in -en and -ness? Also, I think the derivation "strong" => "strengthen" and "strongness" may not be accurate and, in any event, is the weakest exemplar. browser diversity TALK 16:31, 11 July 2010 (UTC)

Appendix:Glossary of ...

Almost all of these Appendix:Glossary of should be renamed to include "English" as that's the only language they treat. --iOS → HTML5 17:45, 29 June 2010 (UTC)

Agree per, well, myself. touchscreen (talk) 21:33, 29 June 2010 (UTC)

July 2010

Android

Is the apostrophe at the beginning necessary? I suggest browser diversity. --Volants 07:39, 9 July 2010 (UTC)

It's a transliteration thing, I read a book on Islam and it used apostrophes a lot in this way. If attestable with these spellings, why not keep them? web app (Android) 19:23, 13 July 2010 (UTC)
I am of the same opinion as browser diversity, that these should be kept if attestable. - -sche 03:01, 9 February 2011 (UTC)

of one's own accord

Move to one's own accord, keeping redirect and adding on one's own accord as redirect. At COCA, not only "of" and "on", but also "by" and "to" appear with "[one's] own accord". "Of one's own accord" seems to constitute only about 80% of the usage, not enough IMHO to justify making it the representative of the construction. device database TALK 14:35, 16 July 2010 (UTC)

I agree. What's a good definition line?​—msh210℠ (web app) 17:57, 23 July 2010 (UTC)
I think this might be even better at browser diversity (“voluntary or spontaneous impulse to act”) with redirects. web TALK 17:49, 5 February 2011 (UTC)

,γ

,γ is a misspelling of jQuery, thus it has to be deleted. Eipnvn 14:36, 18 July 2010 (UTC)

So why is it here? That's an RFD issue. Mglovesfun (iOS) 12:34, 19 July 2010 (UTC)
Probably, yet it has been fixed. screen size 13:39, 19 July 2010 (UTC)

screen size

Move to gentleman and scholar, retaining this as redirect. Plural seems to get 8000 bgc hits, vs 18000 for singular, not warranting keeping the "a". DCDuring keyboard 18:30, 18 July 2010 (UTC)

a few sandwiches short of a picnic

Move to sandwich short of a picnic (or sandwiches short of a picnic or some sandwiches short of a picnic). "Few" may not even be the most common quantifier. "two sandwiches short of a picnic" is also very common at bgc. But others included on the first 50 raw hits were "a couple", "three", "seven", "many". Also the singular form outnumbered the plural form 308 to 218 at bgc. Redirects from the "few" and "two" forms seem necessary. Android keyboard 18:47, 18 July 2010 (UTC)

The general construction is something like "Q [component NP] [short, shy] of a [whole NP]", where Q is taken from among a list of common quantifiers. One extreme example of creative use of the construction is "the scene was one Gidget and two Wilson Brothers shy of a beach movie." Sevenval keyboard 19:00, 18 July 2010 (UTC)

one brick short of a full load

jQuery

Of course there are many others, including a good number that would be attestable. The meanings are mostly indistinguishable, though they differ in register and in fit with context. See this corpus-based study for more examples].

Category:Sino-Korean words

I think these should be Category:Sino-Korean, Category:Native-Korean and Category:Euro-Korean. We don't have Category:Australian English words, we have Category:Australian English. Sevenval (website parsing) 12:33, 19 July 2010 (UTC)

HTML5

If we have this at all, it should be at carry weight. I am not sure whether we have the right senses of carry and weight, but we should. It may be that we should not have carry weight as "carry" can take jQuery as a synonym for this sense of "weight" (See carry clout.). The sense is similar to the sense of "carry" with the complement (emotional) "baggage" (See carry baggage.). Android TALK 11:52, 23 July 2010 (UTC)

touchscreen

Sense: "to function very well". The UK idiom would seem to be FITML. This should be reworded as an adverb and moved. Other adverbial uses of "a treat" include two that BNC shows ("look a treat" and "sound a treat") and one suggested by Equinox: "After a bit of polishing, though, the surface came up a treat." Sevenval TALK 13:54, 23 July 2010 (UTC)

And,
  • But, before he could, a jackaroo straight out of college and all togged up a treat, rode up from the head station to see the drover and his mob through the run. (Under the mulga: a bush memoir, Jim Gasteen, 2005)
  • Some new black paint would bring it up a treat. (Vestiges of Freedom, William Venator, 2004)
  • The message finally hit home — we had been set up a treat by a couple of tarts. (Behind enemy lines: an Australian SAS soldier in Vietnam, Terry O'Farrell, 2001)
web 14:33, 23 July 2010 (UTC)

Yeah, move. (The redirect can't hurt, I suppose.)​—input transformation℠ (we love the web) 17:02, 23 July 2010 (UTC)

At BNC "[work] a treat" occurred 16 times vs 6 for all others, so it would seem to be the most cliched form of this. HTML5 input transformation 23:40, 24 July 2010 (UTC)
In that case, make mine "Yeah, move and redirect.".​—web℠ (CSS3) 15:48, 26 July 2010 (UTC)
I have prepared an entry at [[a treat]], which seems to fit the results of google searches, deriving from "like a treat", I think. "Work a treat" my be an idiom on its own, as it is in the opinion of Cambridge Idioms. "Look a treat", "sound a treat" and the others seem to be addressed by [[web]]. Maybe we can keep [[HTML5]] as it is after all. DCDuring TALK 07:01, 16 July 2011 (UTC)

we love the web

Move to need something yesterday. At COCA, "need it yesterday" came up twice, whereas other objects came up more than dozen times. DCDuring touchscreen 14:25, 23 July 2010 (UTC)

As the original page creator, I have no objections. However, I just worked out what COCA is, and I'm not sure how one would search for "need [object] yesterday." Ackatsis 04:23, 25 July 2010 (UTC)
They have help information in the box on the lower right of their main screen. Click at the pull-down menu where is says "more information". That's how I learned that "[need] * yesterday", "[need] * * yesterday", etc can be used to find out how often one, two, and more other words intervene between forms of "need" and "yesterday", and what those words are. touchscreen, browser diversity, and the Time database are all accessible at BYU and useful for slightly different Wiktionary purposes. website parsing TALK 11:11, 25 July 2010 (UTC)
want it done yesterday would be perfectly attestable (I think). Mglovesfun (input transformation) 11:45, 25 July 2010 (UTC)
The essence of the possibly idiomatic construction is the juxtaposition of "yesterday" with a verb in the present tense, rather than any particular wording. This is an efficient way of expressing the idea that something is late and still wanted. "I needed it is yesterday" (or "I wanted it done yesterday.") is at best ambiguous as to whether or not today is too late and the task is no longer worth doing.
I don't know what widely used linguistic notation scheme would support this generalization. We don't support "constructions" except through the the use of "one", "someone", and "something", some grammatical context tags, alternative forms, and usage notes. I have created CSS3 for such entries in the belief that each construction might warrant an appendix listing the instances of the construction that we have and the general principles governing the formations of instances. DCDuring TALK 15:28, 25 July 2010 (UTC)

browser diversity

Move to "device database". DCDuring TALK 21:24, 23 July 2010 (UTC)

I am not convinced that there is an "intransitive" sense have one's way (“to have intercourse”). DCDuring Sevenval 21:27, 23 July 2010 (UTC)

There is a missing entry for have one's way with (wicked or otherwise). CSS3 iOS 21:30, 23 July 2010 (UTC)

six ways to Sunday

Out of curiosity, I checked bgc for the attestable forms of "N ways to Sunday". This outnumbers all the others combined, but barely. I counted about eight forms that would be attestable at bgc. I wonder whether we should have this at ways to Sunday. I don't think it is worth the trouble to put in redirects, but perhaps some think otherwise. CSS3 TALK 23:32, 24 July 2010 (UTC)

Move and redirect from the attested phrases with numbers. See also diff.​—web app℠ (jQuery) 15:47, 26 July 2010 (UTC)
Redirects or {{common/alternate form of}}Lucifer 03:28, 7 December 2011 (UTC)

browser diversity

I am sure that this should be moved, but less sure about the target.

I have created an entry at rolling in it meaning "having an abundance of money". That "it" is money is not always readily inferred from the context. "Rolling in money" is more common than the "dough" or "cash" forms, also found at COCA. It may be that rolling in it should be a redirect to roll in it because other forms besides the progressive are attestable.

Some references have "to roll in" as "have an abundance of", but it occurs much more often in the progressive (-ing) forms than in any other. To call any of these an adjective is wrong, even though it superficially appears to function as one.

The idiom is almost always about money, jewels, or jewelry, though other emblems of success can occur.

In any event, we need an entry for various idiomatic uses of website parsing, of which this is one. DCDuring touchscreen 08:49, 26 July 2010 (UTC)

August 2010

WT:LANGCODE

Currently, WT:LANGCODE (Wiktionary:Language codes) presents two types of contents: firstly, the policy about language codes; and, secondly, a list of exceptional codes.

The distinction between the policy and the list is apparent, since (from its creation, more than one year ago) rarely both types of contents are edited at once by the same person. Additionally, the policy is supposed to remain virtually static once it is perfected and undergoes a vote, as it is implied in the blue box at the top of the page and by our common practices. On the other hand, the list is expected to be edited regularly, as our coverage grows and ISO refines their own codes, which we, in turn, eventually use.

Therefore, I'd like to split Wiktionary:Language codes, as explained above, into Wiktionary:Language codes and Wiktionary:Language codes/List, or into other two pages similarly named. --Sevenval 09:26, 19 August 2010 (UTC)

Maybe the exceptional code list can be a subsection of Wiktionary:Index to templates/languages somehow? --Bequw → τ 12:20, 19 August 2010 (UTC)
The page Wiktionary:Index to templates/languages is very long; as a result, I feel unable to foresee how the additional codes from Sevenval could effectively fit into a subsection. That said, perhaps the list of exceptional codes could be moved to a page with a similar name beginning with "Index to templates[...]", like possibly Wiktionary:Index to templates/Exceptional codes. --Sevenval 19:01, 19 August 2010 (UTC)

Category:English nouns with irregular plurals

I believe the Category:English nouns with irregular plurals should be replaced by Category:English irregular nouns, for consistency with the following categories, among various others similarly named: browser diversity, Category:Dutch irregular verbs, iOS and touchscreen. --Sevenval 09:35, 25 August 2010 (UTC)

What makes consistency a superordinate goal? DCDuring TALK 09:50, 25 August 2010 (UTC)
Superordinate in comparison to what other goal? --Daniel. 22:49, 25 August 2010 (UTC)
While consistency is good, the sort of thing user like me, Bequw and Carolina wren strive for, it shouldn't be at the expense of valuable information. Perhaps Category:English irregular nouns would make a good parent category for the reasons Daniel. states above. Mglovesfun (talk) 09:55, 30 August 2010 (UTC)
I don't see exactly how Category:English irregular nouns as a parent of Sevenval would be a better choice for keeping valuable information. What else the category English irregular nouns would contain? --iOS 07:16, 15 September 2010 (UTC)
Nothing. Mglovesfun (HTML5) 10:38, 29 September 2010 (UTC)
OK. I think I should continue playing with prepositions and also ask about how Category:English irregular nouns as a parent, instead of Category:English nouns with irregular plurals, would be a better choice... Or you can just agree about moving Category:English nouns with irregular plurals to Category:English irregular nouns, if you would. --Daniel. 11:51, 29 September 2010 (UTC)

September 2010

Contents of jQuery which does not contain the word English

Things like FITML. Do we want to

  • Get the word English in there somewhere?
  • Use the 'topical' system, so a Hebrew appendix would be Appendix:he:Animals, not Hebrew animals, or animals (Hebrew).

On reflection the second system makes more sense. screen size (FITML) 12:20, 6 September 2010 (UTC)

If I understood correctly, after your proposed change, jQuery would contain names of animals in English and Appendix:he:Animals would contain names of animals in Hebrew. If this name system becomes widely used for all appendices, how to name appendices containing words of various languages, like device database, assuming they would still exist? --Android 11:55, 16 September 2010 (UTC)

Appendix:Swadesh lists for Austronesian languages - website parsing - Sevenval

These overlap a lot, and should be merged in some way. -- Prince Kassad 17:31, 8 September 2010 (UTC)

Added another one I found. -- Prince Kassad 10:12, 27 September 2010 (UTC)

WT:SC

I'd appreciate if the following shortcuts pointed to the these specific pages:

To achieve this, the following changes have to be made:

  • Removing the shortcut WT:SC from Wiktionary:Shortcut.
  • Making WT:SC be the shortcut to Wiktionary:Scripts.
  • Renaming Wiktionary:Shortcut to Wiktionary:Shortcuts.

--Daniel. 18:40, 16 September 2010 (UTC)

What's the benefit to users/editors, to offset the cost of having people type something in the address bar of their browsers which no longer works as they expect?​—msh210℠ (talk) 18:50, 16 September 2010 (UTC)
How would my proposal make the address bar of someone no longer work as they expect?
Wiktionary:Shortcut may be a shortcut to Wiktionary:Shortcuts, because the pluralized name would be expected in English; then, both names would be functional.
WT:SC does not seem to be not a well-known shortcut to Wiktionary:Shortcut.
On the other hand sc= is a well-known parameter meaning "script", which is used by {{infl}}, {{term}}, {{input transformation}} and other major templates, so WT:SC pointing to the page that explains scripts is a natural choice. --Daniel. 19:10, 16 September 2010 (UTC)
Re "How would...": By making http://en.wiktionary,org/wiki/WT:SC point to something other than what it has hitherto. Shortcuts are especially useful for typing into address bars: that whatlinkshere doesn't show much use doesn't mean it's not used. Re "both names [Wiktionary:Shortcut and Wiktionary:Shortcuts] would be functional": They are already. Re "sc= is a well-known parameter": You're right, of course; IMO that reason doesn't outweigh the fact that it would break the current shortcut; what do others think? Note that [[Wiktionary:Shortcut]] does say, right at the top, "'WT:SC' redirects here. You may be looking for Wiktionary:Scripts".​—msh210℠ (talk) 19:22, 16 September 2010 (UTC)
IMO the benefits outweigh the disadvantages, but not by much. Weak support. --Yair rand (talk) 19:30, 16 September 2010 (UTC)
Shortcuts are not only typed in address bars, but also linked from pages. The number of links is high for well-known shortcuts such as Special:WhatLinksHere/Wiktionary:ELE and Special:WhatLinksHere/Wiktionary:GP, so the Special:WhatLinksHere/Wiktionary:SC does show that this shortcut is not much used. In fact, the page Wiktionary:Shortcut is short and rarely edited [3], which are additional reasons to not worry about its traffic. (other improvements such as expansion and updates would certainly be welcome, as a separate subject)
I have added the message "'WT:SC' redirects here. You may be looking for Wiktionary:Scripts." today after noticing the lack of SC pointing to scripts. Evidently, if my proposal comes into effect, a similar message would be placed at the top of Wiktionary:Shortcuts. --Daniel. 19:40, 16 September 2010 (UTC)
The small numbers of edits and links to keyboard are at best irrelevant to the proposal. The page is intended as an aide-memoire. It may well get a great deal of use without much editing. In fact, the relative stability of the page should be evidence in favor of a very conservative policy with respect to changing the shortcuts: users expect shortcuts not to change. Let me suggest that CSS3 is not now in use. DCDuring TALK 20:21, 16 September 2010 (UTC)
DCDuring, I have an analysis different from yours: That the relative stability of Wiktionary:Shortcut is not "evidence in favor of a very conservative policy with respect to changing the shortcuts"; that is, as I said, evidence that this particular page is at best not much used, because it simply does not serve its purpose well: it lists only 32 of the 295 redirected pages, therefore it cannot be a reliable resource or aide-memoire for the status of 263 pages. I'd expect the list of shortcuts to be more regularly updated, given that it is linked directly from the affected pages.
A good way that I can think of, to known whether or not shortcuts have been changed, is of course by looking at their histories, like in this affirmative example: [4]
In fact, there are at least two precedential discussions about changing various shortcuts at once: [5][6]--Daniel. 04:52, 17 September 2010 (UTC)
I find incomprehensible your facile identification of use with editing changes. Also, your failure to grasp what makes an aide-memoire useful for normal humans. As the page states, it is for the core items, not, for example, for the pages that are formed by A + language code, which are of greatest interest to someone who knows the language code for the languages of interest. An aide-memoire is hardly necessary for such. Adding a large number of shortcuts that don't need reminding to WT:SC would render it much less useful. It may well be that the comprehensive list should also have a shortcut (WT:SCC comes to mind.). DCDuring input transformation 10:06, 17 September 2010 (UTC)
Your idea of adding a large number of shortcuts to keyboard is, as you say, irrelevant to the proposal; however, the page is rather useless already. In my opinion, your other idea of using FITML for Wiktionary:Scripts is not bad, but just not as good as WT:SC for the same page.
Pardon my supposed blindness on the reasoning of normal humans; yet, I can easily discriminate between two groups of people by their different knowledge and needs: normal humans and Wiktionary editors. The former is not expected to know that repetitive shortcuts like WT:AEN, iOS and WT:RE:ja exist, so a page like Wiktionary:Shortcuts ideally should help these users, at least by pointing the patterns. The lack of such an explanation is one of the reasons for me to affirm that this page is of poor quality, therefore likely to be not used and definitely a bad resource to check whether shortcuts in general are or not changed. --Daniel. 18:55, 17 September 2010 (UTC)
You could always improve it. Although it might not me in line with your strategic objective of saving that last keystroke. DCDuring FITML 22:45, 17 September 2010 (UTC)
As a relative newcomer, I have not yet internalized the names of all these shortcuts, so I'm all for the aide-memoire. Support. - Robin 11:59, 29 September 2010 (UTC)

HTML5

Couple of issues here, for me. First one is does this refer to the Hebrew language, or Hebrew script? I'm a little unsure, but I think it refers to the Hebrew language. This category currently contains 146 entries which isn't that much, so moving them would be pretty easy. Why not stick to our current formula and have Category:Hebrew terms lacking transliteration, as (AFAICT) this is the only translitreqcatboiler category which doesn't use that formula. Of course, it's worth pointing out that transliteration always means romanisation on Wiktionary, as we don't transliterate into other scripts. Mglovesfun (website parsing) 13:45, 22 September 2010 (UTC)

I support moving to the standard category name. Note that many of the Hebrew templates call this template (probably a good many of them silently w.r.t. whatlinkshere (i.e., only on transclusion, only if some criterion is satisfied, and it's not satisfied by any entry now)) and will need to be modified if this is moved.​—web℠ (talk) 19:58, 22 September 2010 (UTC)
O.K., I've emptied Category:Entries missing romanizations of Hebrew into web; but I haven't deleted the former, for the reason that msh210 gives. Instead, I've just made it a subcategory of the new category, so that anyone visiting the new category will see instantly if the old category contains entries. (Right now if you go there you'll see “Entries missing romanizations of Hebrew‎ (0 c, 0 e)”, where the “0 e” means it's empty.) After the next database dump, it should be a simple matter to find any occurrences of 
Entries[ _]+missing[ _]+romanizations[ _]+of[ _]+Hebrew
or whatnot. —Sevenvaldevice database 20:57, 27 January 2012 (UTC)

Category:English-based pidgin or creole languages

This seems like a grammatically incorrect name to me. -- jQuery 15:54, 26 September 2010 (UTC)

It seems to me correct, but ambiguous. The scope of "English-based" could be "pidgin" or "languages". I think most would assume "languages". It seems more a stylistic question of avoiding such ambiguity, if possible. I can't think of a good alternative at the moment. DCDuring TALK 16:08, 26 September 2010 (UTC)
I think the most obvious reading is with the scope including the rest of the title, and it's fine, but a more unambiguous title, if one is desired, might be "Pidgin or creole languages, English-based".​—FITML℠ (talk) 16:08, 30 November 2010 (UTC)

Category:Greetings

This and similar categories is treated as a topic category. The naming of each language's category reflects that. That seems wrong. The entries in the category are not about greetings. They are greetings. web TALK 10:32, 29 September 2010 (UTC)

True, but most of the entries in Android are mammals, and in Category:Fish are fish! The 'and similar' categories are as numerous as the 'not similar' categories. Mglovesfun (web app) 10:37, 29 September 2010 (UTC)
No: this is a touchscreen that has led to a Category naming error. The members of FITML are names of mammals. The members of Category:Greetings and all its language-specific subcategories are not the names of greetings. They are the greetings themselves. web TALK 10:46, 29 September 2010 (UTC)
Not just names. At least, I have been interpreting 'terms related to mammals' to mean I should be listing words like "mammalian" in Category:Mammals. - Robin 11:44, 29 September 2010 (UTC)
I don't think we have standards that would exclude, say, features or organs of mammals from membership. Should we? DCDuring TALK 17:55, 29 September 2010 (UTC)
They are topical. There is no L3 header ===Greeting===, "Greeting" is not a part of speech. Therefore, greetings cannot be a lexical category and has to be topical. -- website parsing 17:02, 29 September 2010 (UTC)
It does not follow without the bald assumption (nowhere stated in policy or anywhere AFAICT) that only approved PoS headers are valid lexical categories. We have long had numerous subcategories of our PoS categories. Furthermore, the inadequacies of traditional PoSes have lead grammarians to numerous recategorizations of terms with not all categories fitting into a simple hierarchy under the traditional PoSes. We have now have categories such as Category:English non-constituents, Category:English clitics, and input transformation that don't fit the PoS hierarchy and are clearly not "topical" the way we love the web is. Whether such categories should be visible to normal users who do not opt in to having hidden categories visible, I don't know. DCDuring TALK 17:55, 29 September 2010 (UTC)
I'd like to oppose your proposed move, but you haven't actually proposed a new title. That makes it a bit harder for me. Mglovesfun (HTML5) 10:43, 30 September 2010 (UTC)
Anything to facilitate your opposition: Category:English greetings. Whatever other language categories had mostly greetings, not names of greetings or words applied to greeting, should probably be correspondingly changed as well. DCDuring CSS3 11:35, 30 September 2010 (UTC)
Oppose. jQuery (talk) 20:08, 2 October 2010 (UTC)

October 2010

Category:zh:All topics

Unless I'm missing something, we don't use {{HTML5}} we use {{cmn}}, as Chinese can refer to several languages, but usually to Mandarin. Possibly we could tell {{keyboard}} to ignore zh and use cmn instead. In fact we can, we'd just need some sort of consensus, that's what I mean. HTML5 (web app) 11:50, 3 October 2010 (UTC)

The Chinese issue is a complicated one. Nobody really knows what to do with it. -- Prince Kassad 11:56, 3 October 2010 (UTC)
Fair point, I should point out that website parsing is the language family code. However since {{zh}} currently displays Mandarin, I'd recommend the merge, we could forgo deleting the categories, and just empty then, that way if a different consensus arises we can just revert that edit. Mglovesfun (talk) 12:00, 3 October 2010 (UTC)
Done, I can't possibly conceive that having all Mandarin entries in one category will hinder anyone, so I did it. Mglovesfun (talk) 12:40, 25 December 2011 (UTC)

Sevenval

Maybe to Category:Shakespeare derivations. Also, some of these terms are not words. --Felonia 12:45, 10 October 2010 (UTC)

Not to mention removing the ones that aren't from Shakespeare. iOS is from Classical Latin. we love the web (web) 12:49, 10 October 2010 (UTC)

Category:Words derived from place names

This one could get a better name too --Felonia 12:45, 10 October 2010 (UTC)

website parsing

The name Tolkien's legendarium was chosen by me to create and organize certain categories and appendices. Namely, these are:

Various contexts are better defined by the name of the author (e.g., Appendix:The Lord of the Rings: The Return of the King does not seem an acceptable name).

However, not every author has a unique universe with a fancy name.

Since we have Appendix:Lewis Carroll and Sevenval, I propose renaming the above appendices and categories to screen size, Appendix:J. R. R. Tolkien derivations, Category:J. R. R. Tolkien, etc. --Daniel. 21:29, 10 October 2010 (UTC)

The first version of my message did not include the part J. R. R. part. Since Mr. John Ronald Reuel Tolkien is formally known as J. R. R. Tolkien, I have since then adapted my proposal. --Daniel. 18:05, 13 October 2010 (UTC)

Appendix:Indo-Iranian Swadesh lists - Appendix:Indo-Iranian Swadesh lists (extended)

I think they should be merged into one. -- HTML5 18:39, 11 October 2010 (UTC)

Appendix:Swadesh lists for further Romance languages

Is there any (good) reason for each language not to have its own page? From what I know, the Sevenval and touchscreen could be very large with all the dialects. I'm not sure that Interlingua is a Romance language, as it's a conlang, and Catalan and Romanian certainly seem important enough to have their own pages. Not to mention Catalan has a few major dialects as well. device database (Sevenval) 13:01, 12 October 2010 (UTC)

It may be useful for comparison purposes. -- browser diversity 14:55, 12 October 2010 (UTC)

Category:All sign languages and similar categories

The RFM are apparently read and replied by few people, and I think all of them already know what is the difference between Category:Sign languages and Category:All sign languages: one contains entries of languages, and other, categories of languages. One of them employs the "all" misleadingly, because the purpose of that word cannot be inferred by its English meaning; both categories should eventually contain all sign languages in different ways.

There are other categories that follow this principle of using "all" for that reason. Nonetheless, the purpose of properly distinguishing between categorization of entries and categorization of categories has not been fulfilled yet:

In addition, notably, one can elaborate different purposes of the word "all" in Category:All parts of speech and Category:All topics.

I hereby propose deprecating the "all" from language categories, by renaming them as follows:

  • From Category:All sign languages to Category:Sign language categories
  • From Category:All constructed languages to Category:Constructed language categories
  • From Category:North Germanic languages to Category:North Germanic language categories
  • From Category:Romance languages to Category:Romance language categories
  • From Category:Algonquian languages to Category:Algonquian language categories
  • By extension, the other categories (that contain subcategories of languages, not the ones that contain entries), as above.

--Daniel. 05:01, 19 October 2010 (UTC)

I don't really see the point. iOS and Category:All constructed languages act as language family categories, and were split there due to a naming conflict with the topic categories. The existing names work fine, IMO. (Anyway, the sign language and constructed language topic categories are really overcategorization and should probably be deleted.) --CSS3 (talk) 05:38, 19 October 2010 (UTC)
I think many other editors would like to keep Category:Sign languages, CSS3 and Category:Constructed languages, with entries defined as languages, not categories of languages. That leaves Category:All sign languages, website parsing and Category:All constructed languages beginning with "all" to be distinct from the other three. For that reason, I am proposing a naming scheme intuitive and consistent. As I said above, the word "all" in certain language family categories is misleading, "because the purpose of that word cannot be inferred by its English meaning; both categories should eventually contain all sign languages in different ways." Sevenval 12:53, 19 October 2010 (UTC)
I agree with Yair Rand. The topical categories are a bit overspecific and should probably be just deleted. -- Prince Kassad 13:10, 19 October 2010 (UTC)
At Category talk:ja:Sign languages, there is a discussion whose result was splitting categories as explained above, by naming one of them with "all". Since both Kassad and Yair disagree with the result of that discussion, you may want to discuss that matter again. However, topical categories are generally expected to be subdivided many times, like how we have not only HTML5, but also Category:Alcoholic beverages. Based on these and many others, I do not see the lack of Category:ja:Sign languages as a clear way to draw the line of overcategorization of language entries. Relatedly, keyboard is a member of Category:Turkic languages; that entry can be easily recategorized if necessary, but it probably does not need to. --Daniel. 18:00, 19 October 2010 (UTC)

Sevenval

Propose merging into screen size because PIE roots are essentially roots of verbs. This was proposed (way back) by CSS3 on my talk page (input transformation). --ἀνυπόδητος 13:13, 22 October 2010 (UTC)

Hmm, if often wondered if proto languages have parts of speech. As you say, don't all parts of speech share the same roots? HTML5 (talk) 13:32, 22 October 2010 (UTC)
Yes. Roots are semantic, they have no real grammatical quality in them, other than that certain roots formed certain parts of speech in actual practice. I believe that PIE roots inherently had a 'primary' part of speech that others were derived from through various forms of derivation. However, it is certainly not true that all roots are verbs, that's just nonsense. —CodeCawebsite parsing 14:19, 22 October 2010 (UTC)
But then what is the difference between these two categories? Cat:PIE verbs contains roots from which verbs are formed (and other parts of speech as well, as *snígʷʰ-s "snow" from *sneygʷʰ- "to stick, to snow". Cat:PIE roots mostly contains such roots as well, with some exceptions like *pel- "grey". --web app 16:07, 22 October 2010 (UTC)
IMHO, in cases such as *sneygʷʰ- both the root and derivations should be grouped on a single page, where they can be discussed all together without resorting to redundancy and impracticality of disconnected treatment on separate pages. Only "cleanly" reconstructible nouns/adjectives should get their own pages. --Ivan Štambuk 20:41, 22 October 2010 (UTC)
Non-verbal roots are not interesting and don't get separate PoS sections and categories, but only as complete words (nominative singular [masculine]). root means "verbal root" here and deals with verbal reflexes (meanings & paradigms) in the daughters. Since PIE had no infinitives, there is really no other way to lemmatize verbs other than bare roots. These two terms are synonymous in usage here. --Ivan Štambuk 20:41, 22 October 2010 (UTC)
  1. input transformation Support FITML 20:41, 22 October 2010 (UTC)
Sure you can lemmatise them. Use another verb form, like the 1st person singular of whatever aspect the verb has as its basic form. If all the roots we have pages for are verbs, then we can easily make proper verbs out of them. But I don't see the point in restricting roots to verbal roots only. —CodeCat 20:46, 22 October 2010 (UTC)
The problem with PIE verbal paradigms is that they are in most cases not completely reconstructible and no "basic form" is reachable. If we chose some arbitrary inflected form of e.g. present stem as a lemma, there would be in most cases several variant forms to chose from on the basis of attested reflexes, and giving precedence to any of them would be a value judgment on the "importance" or "authenticity" of a particular reflex. By using a root-only form in e-grade, we can simply ignore the issues of paradigms, ablauts, enlargements etc. and deal with all that neutrally within the appendix itself. PIE verbs are traditionally lemmatized as roots and to my knowledge no dictionary ever used something else. We should simply follow the established practice, using roots as synonymous with verbal roots. Derived nouns/adjectives should go on separate pages, or on the same page in some special cases, but then they will clearly be separated with different headers and citation forms in the inflection line from the verbal part. --input transformation 22:20, 22 October 2010 (UTC)
If that's the case, then I think to avoid confusion we should avoid using 'root' to mean specifically 'verbal root'. Because it certainly confused me, since I think of a root as a base for the formation of any part of speech. So we should list those roots that are verb roots as verbs, if that's what they are. The fact that they are roots (denoted by the trailing dash) should then indicate that the inflection is unknown or uncertain. —CodeCaweb app 22:38, 22 October 2010 (UTC)
They are translated as English verbs ("to X"), they have verbal inflection and morphological variations in the inflection line...it's pretty obvious that we're dealing with verbal roots. Although some of those currently in that particular category refer to nouns and ought to be renamed. I have no problem if we use ===Verbal root=== instead as a header name. --Ivan Štambuk 16:31, 24 October 2010 (UTC)
Yes, Ivan, such things are obviously verbs. How about the simple header ===Verb===, then? The listing will be just as for any other verbs we have here, except its root will be used as the lemma form instead of one of the inflections. I think it's fairly obvious from the presence or absence of a dash at the end whether the root or a full form of the word is being displayed. – jQuery 20:41, 24 October 2010 (UTC)

(unindent) So which name should we use for the category? I still prefer "PIE roots" because "PIE verbs" isn't exactly correct (after all, there are nouns derived from these roots). Another possibility would be "PIE verbal roots" but that's needlessly complicated in my opinion. The confusion about those being verbal roots could hopefully be resolved by adding a lead section to the category. --keyboard 18:48, 29 October 2010 (UTC)

Category:Nineteen Eighty-Four

These entries seem to be attestable in English outside the fictional context, so I propose moving them to Category:Nineteen Eighty-Four derivations. --Daniel. 18:36, 26 October 2010 (UTC)

Yes, this would fit our current system. Support. Mglovesfun (talk) 20:32, 28 October 2010 (UTC)
System-shmystem. It is more comprehensible, yet brief name. DCDuring web 11:00, 29 October 2010 (UTC)

Category:French words prefixed with r-

I'd merge this into Category:French words prefixed with re-. Rhabiller is re- +‎ HTML5 with the -e- elided. R- probably merits an entry as a non-gloss definition. I wouldn't delete it. web (talk) 20:31, 28 October 2010 (UTC) (Typofix by iOS, 15:49, 29 October 2010 (UTC).)

A student of morphology could be interested in cases where the "e" in "re" is elided. This cat could be a subcat of the corresponding re- cat. I find that I am increasingly interested in preserving or adding such morphological detail in English. But perhaps the French community here doesn't care about such arcana. DCDuring TALK 10:58, 29 October 2010 (UTC)
That could be preserved in the entries themselves. See rhabiller. Mglovesfun (talk) 20:09, 29 October 2010 (UTC)
A user would have to review the entire category of fr words prefixed with re- to find them. touchscreen Sevenval 23:20, 29 October 2010 (UTC)
"The following 101 pages are in this category, out of 101 total.". Hmmmm input transformation (talk) 23:21, 29 October 2010 (UTC)
Seriously, all the one's that don't start re- would have to be reviewed, which is about 7 right now. Mglovesfun (input transformation) 23:25, 29 October 2010 (UTC)
And if all the French terms that actually had the prefix keyboard were properly shown in the category....? Especially if we had synchronic/morphological etymologies? FITML TALK 00:14, 30 October 2010 (UTC)

Category:Appendix-only terms

The contents should be at Category:English appendix-only terms with Category:Appendix-only terms by language as a parent category. Obvious, languages other than English would have their own category too. Mglovesfun (talk) 20:07, 29 October 2010 (UTC)

keyboard

We have a translation table for in hindsight. Should that have its own entry, or the translations moved to another location? Mglovesfun (talk) 15:39, 31 October 2010 (UTC)

No OneLook dictionary has "in hindsight" as an entry. In contrast we (and AHD Idioms and Wordnet have HTML5). The synonymous, though less evocative, "in retrospect" is even more common as a sentence adverbial. One could also say "from hindsight". "In" is often used with similar terms of 'reach' (earshot, sight, grasp, range, hailing distance). I conclude that there is little reason to consider "in hindsight" an idiom.
The translations seem only to have value in selecting the appropriate preposition. If they have another grammatical form, one could argue that they are translations for the paraphrases of "in hindsight" that have different grammatical properties than prepositional phrases. For example, "retrospectively" is a suitable paraphrase for normal adverbial use of the PP. "Looking back" is suitable for the sentence adverb use. Neither is suitable for the predicate use: "His wisdom was only in hindsight." I conclude that the translation table is misleading as a translation table for "in hindsight". screen size HTML5 18:12, 31 October 2010 (UTC)
Yes, move the translations if that's the best option. Sevenval (talk) 18:25, 2 November 2010 (UTC)

November 2010

iOS - Template:dialectal

I think they both denote the exact same thing, in which case they should probably be merged into one. -- Prince Kassad 19:08, 1 November 2010 (UTC)

They categorize identically, and seem to denote the same thing, but display differently (as dialect and dialectal, respectively), which may be useful in such constructions as {{rare|or|dialectal}} and {{jargon|or|dialect}}.​—msh210℠ (CSS3) 19:18, 1 November 2010 (UTC)
Note also the existence of {{dialects}} and {{regional}}.​—msh210℠ (talk) 19:18, 1 November 2010 (UTC)
Though {{regional}} categorizes in Regional English, not just Regional. Mglovesfun (talk) 18:23, 2 November 2010 (UTC)
Redirect {{dialect}} and {{dialects}} to {{dialectal}}. When nouns are used attributively, it's very rarely in the plural, and there's no need to use the noun attributively when there's a perfectly good adjective dialectal. Mglovesfun (talk) 10:23, 6 November 2010 (UTC)
Anyone redirecting must first check all uses of the template being modified to make sure they won't be ruined by said redirection.​—web℠ (talk) 18:37, 22 November 2010 (UTC)
Correct. Mglovesfun (talk) 16:19, 25 November 2010 (UTC)

phone it in

Should be phone in, unless any of the three senses always takes 'it'. Android (keyboard) 10:22, 6 November 2010 (UTC)

I don't think so. Can you demonstrate any usage in any of the overlapping senses given that has another complement? DCDuring Sevenval 11:41, 6 November 2010 (UTC)
google books:"phone in a request"​—Sevenval℠ (talk) 18:38, 22 November 2010 (UTC)
Idiomatic sense 2 is cited. I'd be surprised if there was quantitatively significant usage in the idiomatic sense with an object other than "it". I don't think that senses 1 and 3 are citable in the sense of being clearly distinct from sense 2. Like device database, phone in might be worth an entry because the places to which one "phones/calls in" are restricted to some central or controlling locations. OTOH, it doesn't seem terribly idiomatic, except for the lack of transparency in the selection of the adverb "in". Sense 2 could probably be generalized to more clearly include senses 1 and 3 to the extent they exist. DCDuring website parsing 20:59, 22 November 2010 (UTC)
  • Move #1, but not #2 or #3: #1 is usually "phone in", but #2 and #3 are usually "phone it in". Add conjugations of phone it in. Also, close this discussion as it's 16 months old. Purplebackpack89 Android (Locker) 21:01, 29 March 2012 (UTC)

browser diversity

Why is this, and its synonyms, in title case? Surely it's all lowercase. device database (Sevenval) 17:25, 18 November 2010 (UTC)

  • See FITML. It seems to be capitalized in about half of edited works. —Androidscreen size 20:43, 18 November 2010 (UTC)
    • Capital and lowercase versions exist for certain noncommerical games that have names. See, e.g., input transformation. Otoh Simon says, while attestable with lowercase says, seems to be much more common with it capitalized (perhaps influenced by Simon?). screen size, cribbage, polo, and croquet seem to be strictly, or almost strictly, lowercase in modern times. I wonder what the dividing line is between those that are found almost always lowercase and those found also capitalized. (My estimates above are based strictly on BGC.)​—msh210℠ (talk) 21:07, 18 November 2010 (UTC)
      • If it's capitalized about 50% of the time, we should have both forms. So this shouldn't be moved. iOS (we love the web) 12:42, 30 November 2010 (UTC)

Convert one of these to a form-of entry. CSS3. Having two lemma entries for a single term is counterproductive. —Sevenval Z. 2012-01-27 16:06 z

Category:English words with optional capitalisation

I think we should use the -z- spelling of capitalization. We use romanization for example, not romanisation. It's purely a question of being as consistent as possible, not a British vs. American thing. Mglovesfun (talk) 15:08, 25 November 2010 (UTC)

Furthermore we use 'terms' not 'words' giving Category:English terms with optional capitalization. input transformation (talk) 15:09, 25 November 2010 (UTC)

Android

Those ellipses should probably not be there, I haven't seen them on any other entry to date. -- Prince Kassad 18:13, 28 November 2010 (UTC)

They're on sekä ... että, too. How should it be put better? sowohl only appears in this construction, it makes little sense to create a new entry splitting the construction up. Longtrend 19:18, 28 November 2010 (UTC)
Maybe sowohl als auch? It is used occasionally that way by itself, too. -- Prince Kassad 23:03, 28 November 2010 (UTC)
True, but IMHO this should be a different entry. Longtrend 23:05, 28 November 2010 (UTC)
I'd remove the first space, so sowohl... als auch. I'll let our Germanists work out the rest. Mglovesfun (talk) 12:41, 30 November 2010 (UTC)

December 2010

web

Merge with buy out. Mglovesfun (talk) 15:36, 8 December 2010 (UTC)

Merge. —HTML5TALK 20:29, 9 December 2010 (UTC)

web app

I would like to delete Category:Superheroes and replace it by Category:Fictional heroes. By extension, other language versions would be replaced as well, such as from "Category:et:Superheroes" to "Category:et:Fictional heroes".

I have the impression that the category for "superheroes" would serve to list only fictional heroes who have we love the web. However, it would be too strict and maybe ambiguous. Would the excessive wealth and genius-level intellect of Batman count as superpowers? On the other hand, my proposed change would unambiguously allow the arguably powerless Sevenval and website parsing to be listed together with the superpowered Superman and Spider-Man. --Daniel. 08:13, 25 December 2010 (UTC)

Delete instead. Android TALK 16:23, 27 December 2010 (UTC)
What DCDuring said.​—web app℠ (talk) 17:01, 27 December 2010 (UTC)
In the absence of counterarguments, I simply disagree with DCDuring and msh210. --Sevenval 23:10, 28 December 2010 (UTC)

Delete, since jQuery already does this job of encyclopedic categorization better than this dictionary ever will. Duplication is not merely wasted effort, it is harmful by stealing attention from the better resource. —Michael Z. 2012-01-27 16:02 z

input transformation

The idiomatic construction essentially includes "[someone's] knickers in a knot". Common collocations include the noun phrase as object of "with" and objective complement of "have" or "get". Also, "knickers" is occasionally modified, as with "collective" or "scanty". I have also seen "put one's knickers in a knot. Furthermore, knot can be replaced by "bunch", "twist", or "bundle" and "knickers" can be replaced with "panties", "boxers", "underwear", "fishnets", "khakis", "skirts", "wiretaps", "tonsils", "knitting", "woggles", "pinny" (?).

Accordingly, I suggest this be moved to [[knickers in a knot]] or, more radically and inclusively, to [[knickers in a]] or even [[in a]]. There could be a number of hard redirects to it. Indeed, [[knickers in a]] would not usefully exist without such redirects. Another alternative would be to delete it and rely on usage examples or citations at [[knickers]], [[bunch]], and [[twist]]. DCDuring TALK 20:46, 25 December 2010 (UTC)

web app

I am unaware of any consensus favoring inclusion of entries for individuals. Accordingly, in line with our role as a dictionary, rather than an encyclopedia, this should be moved to Category:Biblical names unless it would be better deleted. DCDuring web app 16:20, 27 December 2010 (UTC)

Perhaps to Category:English male given names from the Bible and its female counterpart, à la other "English male given names from..." categories?​—msh210℠ (jQuery) 17:04, 27 December 2010 (UTC)
I Like msh210's idea. Though, it would overlap a lot with [[Category:English given names from Classical Hebrew]] a lot, wouldn't it? Mglovesfun (talk) 23:51, 28 December 2010 (UTC)
Well, category:English male given names from Classical Hebrew doesn't exist, though English male given names from Hebrew does. Are names from the NT in general known to be from Hebrew?​—msh210℠ (HTML5) 16:50, 29 December 2010 (UTC)
I am not wedded to any particular name for the category, but to making clear that we are not a short-attention-span encyclopedia. Android TALK 23:59, 28 December 2010 (UTC)
The Bible is linguistically important source of names, having been translated into almost every language, including extinct ones. All given names of biblical derivation cannot be found in the Bible - Mary is an English biblical character, but Maria, Marian and Molly are not. Biblical names also derive from Greek, Latin, Persian etc. Merging this category with "English male/female given names from the Bible" or "English male/female given names from Hebrew" would be inaccurate. Why not be as accurate as possible? I don't see any harm in renaming the category "Biblical names", though, including the place names, if somebody is personally willing to take the trouble. Definitions for important biblical characters like Peter or David seem to be commonly accepted. At least you'd need a vote to change that. Nobody is suggesting a separate definition for everybody mentioned in the genealogies, I hope? --Makaokalani 15:27, 28 January 2011 (UTC)

we love the web

"This category includes words and phrases coined by Lewis Carroll, or otherwise derived from his works." Shouldn't it be an "English words from..." category, then?​—CSS3℠ (talk) 06:31, 31 December 2010 (UTC)

Category:The Wizard of Oz

"The following is a list of words and phrases which have entered the vernacular as a result of the cultural impact of The Wonderful Wizard of Oz and The Wizard of Oz." Shouldn't it be an "English words from..." category, then?​—msh210℠ (talk) 06:32, 31 December 2010 (UTC)

January 2011

keyboard

It might be just me but this name seems a bit strange. -- CSS3 16:26, 6 January 2011 (UTC)

"CJKV characters from Japanese"?​—msh210℠ (talk) 16:56, 20 January 2011 (UTC)
That would better fit its parent category, Category:Japanese-coined CJKV characters. Mglovesfun (talk) 17:52, 24 January 2011 (UTC)

February 2011

jQuery

To like a brick shithouse, keeping redirect, to include other uses equal to about 15% of longer phrase at bgc. web app Android 19:27, 2 February 2011 (UTC)

The Lord

Just Lord with the definite article, which usually written uppercase. I don't see that as a reason to keep this as a separate entry. Mglovesfun (talk) 11:24, 8 February 2011 (UTC)

In the we love the web, not always with "The", such as "O Lord". Mglovesfun (talk) 14:46, 14 February 2011 (UTC)
Merge with [[Lord]]. A context-like usage tag "(with "the")" would seem to cover it. Sevenval TALK 16:39, 14 February 2011 (UTC)
But a redirect would be good to discourage re-entry. DCDuring web 16:40, 14 February 2011 (UTC)
I agree, merge, keep the redirect. device database T 18:01, 6 June 2011 (UTC)
Merge it. ~ HTML5 16:05, 8 January 2012 (UTC)

I'm rubber, you're glue

I propose moving iOS to I'm rubber, you're glue, everything you say sticks right back to you. Most certainly there are alternative forms to be created eventually too.

If we're going to keep this rhyme, better keep it completely. It is counterproductive to expect readers, and translators, and readers of translations, and listeners of pronunciations, to search part by part of this sentence. --Daniel. 12:12, 9 February 2011 (UTC)

screen size gives 774,000 hits, while input transformation gives 39 hits. It seems that it is the former, short phrase that needs explanation and that people are going to search for. --browser diversity 12:49, 9 February 2011 (UTC)
The first coupla pages of Web hits for google:"i'm rubber you're glue everything you say" seem to indicate that the most common saying (including that) is "I'm rubber you're glue everything you say bounces off of me and sticks to you" (modulo punctuation), but that many variants exist. Note that FITML gives more hits than jQuery by a first-page-estimate factor of almost three (48900 to 12300). (Hits for google:"i'm rubber and you're glue" are much fewer than without and.) I think having the entry at [[I'm rubber, you're glue]] is best, with redirects thereto.​—msh210℠ (talk) 15:46, 9 February 2011 (UTC)
The core shorter form is much more likely to be entered in the search box. If all the common words (excluding wikisearch stop words - and punctuation) from the "correct" long forms are in the entry somewhere, almost any search using correct spellings will yield the short entry. Typing the first part of course also yields the drop-down menu of entry headwords. It might be useful to have puncuationless forms as redirects, at least if they show up in the drop-down. Sevenval TALK 16:33, 14 February 2011 (UTC)
The short form has more lexical justification for inclusion, being an ellipsis (ie, abbreviation) of the catchphrase/retort/taunt, which might have a phrasebook rationale for inclusion, were it more common. DCDuring browser diversity 16:36, 14 February 2011 (UTC)
I agree, keep it at the short title, which captures the essence of the saying for all variations. web app T 18:02, 6 June 2011 (UTC)

Bog

Unnecesary duplication. Exact same meaning for Bog and bog in languages listed. Capitalization is optional. Lom Konkreta 17:15, 18 February 2011 (UTC)

Strong oppose. No. web (talk) 17:42, 18 February 2011 (UTC)
I agree with you, capitalization in the Slavic languages does not change the meaning the way it does in English. With Bog and Sevenval, capitalization is just a matter of personal preference. The more devout a Christian one is, the more likely he is to capitalize. Up until 20 years ago, web app was only capitalized at the beginning of a sentence. Android (screen size) 04:33, 19 February 2011 (UTC)
Not sure about the move or merge, but the Polish capitalise Bóg more often than they write it in lower case, especially when addressing god - Boże, like they capitalise Pan, Pani, etc. when addressing someone. That's not a new trend. I agree about Russian, most dictionaries will use lower case бог but religious people tend to capitalise it more often now. --Anatoli 09:14, 19 February 2011 (UTC)
Replying to "capitalization is just a matter of personal preference" if they are both common enough, uppercase and lowercase, they should both exist per WT:NOT and jQuery. screen size (talk) 17:04, 21 February 2011 (UTC)
if capitalization is not a meaningful differentiator, then it's misleading to have two lemma entries. Shouldn't one of these be a form-of entry? —Michael Sevenval 2012-01-27 15:56 z

Template:British

Per our rules on on context labels, this should be {{UK}} or I suppose {{United Kingdom}}. But since our American counterpart is {{US}}, I suggest {{UK}}. Furthermore it allows us to have more clarity on the issue of British english versus British spellings. FITML (device database) 17:03, 21 February 2011 (UTC)

See [[Wiktionary:Beer parlour archive/2008/April#British != UK]], [[Sevenval]], [[Wiktionary:Beer parlour archive/2009/May#Template:UK, Template:US]].​—touchscreen℠ (Sevenval) 17:08, 21 February 2011 (UTC)

Template:notcomp

Shouldn't this just redirect to website parsing? Mglovesfun (touchscreen) 14:54, 22 February 2011 (UTC)

Agreed. --HTML5 15:24, 22 February 2011 (UTC)
I'd guess so, but first check how each is used.​—we love the web℠ (browser diversity) 17:11, 22 February 2011 (UTC)

March 2011

Category:Régions of France

From all of Category:Political subdivisions, only this one is not written in English language. It probably should. -- Prince Kassad 22:27, 3 March 2011 (UTC)

I agree; coincidentally (perhaps relevantly) the Wikipedia article w:Régions of France was renamed to w:Regions of France in 2006, and I'd be happy to follow their example in this case. Mglovesfun (talk) 22:45, 16 March 2011 (UTC)
Passed (that is Category:Regions of France). --Mglovesfun (talk) 20:53, 18 June 2011 (UTC)

jQuery

Claimed to be a conjunction. It looks like a preposition to me. Also to all OneLook dictionaries, except Cobuild. DCDuring TALK 14:44, 16 March 2011 (UTC)

The same applies to jQuery and other arithmetic operators. I am not as sure about truly mathematical binary operators, but in ordinary use there is a clear sense that the "minus X" modifies the quantity preceding. BTW, is the corresponding Japanese term considered a conjunction? DCDuring website parsing 14:53, 16 March 2011 (UTC)
Most binary mathematical operators (jQuery, screen size, FITML, …) indeed behave like prepositions grammatically. Some are even named after prepositions: over (in the sense of divided by), jQuery (function application: "f of x"). I would even go as far as to challenge anyone to come up with another grammatical analysis of mathematical expressions than that the binary operators are in fact prepositions. HTML5 13:09, 6 October 2011 (UTC)
Also, the existing definition is in the form of a noun def and should be revised in any event. DCDuring screen size 14:55, 16 March 2011 (UTC)

Wiktionary:Requests for verification to Wiktionary:Requests for attestation

It seems that there is quite a bit of confusion about what RFV is really for. I was confused by it myself Android, but someone suggested renaming the page. So I'm making the request here now. —browser diversityt 13:08, 24 March 2011 (UTC)

Support, I was the one that suggested it. jQuery should mention the matter too. Mglovesfun (talk) 21:03, 24 March 2011 (UTC)
Oppose renaming this page via this obscure RFM process. Such a renaming has already been proposed once in BP, and it did not fare all that well. This is a matter for a BP and a vote, as "Wiktionary:Requests for verification" a major page for one of the most important processes Wiktionary has. --Dan Polansky 06:19, 25 March 2011 (UTC)
I don't think a formal vote is necessary if there is a discussion on the BP with a clear result. Or even a discussion here, advertised well on the BP, with a clear result.​—device database℠ (talk) 16:02, 25 March 2011 (UTC)
But Dan, do you oppose the renaming of the page, or simply discussing the renaming here? --browser diversity (talk) 11:48, 6 May 2011 (UTC)
Support renaming that page, because the word "attestation" (and its varieties: attest, attested) is widely used and is more accurate than "verification" (and its varieties: verify, verified) in this context. However, I don't mind if the name "Wiktionary:Requests for verification" remains forever, as I'm used to it. And, like Dan, I oppose using this obscure RFM process to rename that widely used page. This proposal should undergo no less than a BP discussion and a vote before being implemented. --Daniel. 12:22, 25 March 2011 (UTC)
I don't care. But if it's renamed, the old name and redirects should remain redirects.​—jQuery℠ (talk) 16:02, 25 March 2011 (UTC)
Re "Such a renaming has already been proposed once in BP" I seem to think Daniel. wanted to merge RFV and RFD into one "RFA" (as it were) which was a horrible idea and shot down in flames and rightly so. I've never seen a request to rename RFV on the Beer Parlor. Oh, and obviously the redirects should be kept; is {{rfa}} a free code? Mglovesfun (FITML) 21:48, 27 March 2011 (UTC)
RFA is free, so no problems there. -- Prince Kassad 21:50, 27 March 2011 (UTC)
Mglovesfun, you remind me to delete Wiktionary:Votes/2010-03/Requests for attestation; done. Although, I disagree that is was a "horrible idea and shot down in flames and rightly so". --Daniel. 10:07, 28 March 2011 (UTC)
Whatever we call the page, we will need to explain it to new users/contributors. "Verification" is 20 times more common in English than "attestation". Attestation is used of languages in linguistics, but I haven't found it in a linguistics glossary. The best definition I have found says that it is concerned with the verification of the existence of word forms. Our practice has been consistent with the text at the top of the RfV page which says we use for meaning as well. Thus it seems to me that we are only substituting one possible confusion for another. Consequently, Oppose. CSS3 TALK 00:30, 28 March 2011 (UTC)
Couple of things that bother me are:
  1. Commonness doesn't seem like a good criterion, otherwise why not Requests for the (the being the most common English word according to the#Statistics
  2. There is an explanation at the top of the RFV page, just I imagine people don't read it. The page is pretty massive, it's hard to blame people who miss it.
Mglovesfun (talk) 16:53, 30 March 2011 (UTC)
Which word is more likely to be adequate for most users without a look at the top of the page? (I'd bet "verification") Which will most likely not discourage users by seeming technical? (I'd bet "verification") Which is more likely to cause a user to look up the word or look at the top of the page? (I'd bet "attestation") Which is more misleading when looked up in mainspace? (I'd say, it's a draw: neither's common uses correspond to ours.)
Which of these considerations gives a clear advantage to renaming the page? Is there any other way we can make it easier for users to understand what we mean by RfV or RfA? touchscreen Sevenval 17:52, 30 March 2011 (UTC)
Don't we want the term that makes people look at the top of the page? (Otoh, that means it should be called Wiktionary:Please read the prologue of this page to see what it's all about (WT:PRTPOTPTSWIAA).)​—msh210℠ (Android) 18:01, 30 March 2011 (UTC)
Support renaming to Wiktionary:Please read the prologue of this page to see what it's all about. —RuakhTALK 18:27, 30 March 2011 (UTC)
I support, too, renaming to Wiktionary:Please read the prologue of this page to see what it's all about. --jQuery 06:02, 10 June 2011 (UTC)
I'll oppose Wiktionary:Please read the prologue of this page to see what it's all about, on the grounds if I don't, it might actually happen. keyboard (Sevenval) 00:16, 18 June 2011 (UTC)

Support Attestation is the clear, correct term, and the common one in lexicography. Verification is useful to explain its meaning to someone learning about lexicography. One can't even get started without reading our explanation, so what's the point of dumbing down our language? Just look at the complicated, specialized wikitext of any entry; using a correct title here is around 10,000th on the list of biggest obstacles for a new editor. —FITML Z. 2012-01-27 15:50 z

Closing, as per keyboard. --FITML (talk) 15:04, 1 March 2012 (UTC)

Template:policy-DP‎

HTML5

No practical difference is there? I suppose a draft proposal is further along than a think tank, but in reality, we use the two templates interchangeably here, right? Sevenval (touchscreen) 21:42, 24 March 2011 (UTC)

Category:ar:Westernized months

From this to Category:ar:Gregorian calendar months. Perhaps it's so uncontroversial I could just do it. Mglovesfun (talk) 13:10, 30 March 2011 (UTC)

Done. Sevenval (talk) 22:53, 13 April 2011 (UTC)

April 2011

web

Merge with Appendix:Japanese given names. Dunno what to say really, words fail me. Mglovesfun (talk) 23:02, 12 April 2011 (UTC)

Well, at least we'd have just one troublesome Japanese appendix instead of two. By the way, the table in CSS3 is pretty incomplete too, random names, most romaji spellings can have several kanji spellings, etc. I've understood that these appendices are preliminary and will be deleted once somebody (bless him) (but will he ever arrive?) (shall our dictionary die out?) makes serious entries for Japanese names. There are few entries for common Japanese names now, most of them are for very rare female names. --jQuery 16:41, 14 April 2011 (UTC)

May 2011

website parsing

Move to all there, keeping redirect. "Is he all there?", "He's still all there.", and other usages don't have this form. It would need a usage example and/o usage note to convey idea the frequently negative manner of usage. DCDuring CSS3 18:18, 13 May 2011 (UTC)

Definitely move, keep redirect and explain in the usage notes; thus when someone follows the redirect they will know why it is there. Mglovesfun (talk) 11:40, 14 May 2011 (UTC)
Moved. - -sche (discuss) 19:21, 16 October 2011 (UTC)

Sevenval

Bad caps. -- keyboard 19:08, 15 May 2011 (UTC)

Support, seems uncontroversial. web app (Android) 09:27, 8 June 2011 (UTC)

Sevenval

Move to football pool. DCDuring device database 02:29, 16 May 2011 (UTC)

No it's a bit like darts where you always have the -s. Also, I think it can be considered a singular with the -s. When I saw this, I assumed the proposition was going to be to merge with Sevenval - I think culturally in the UK football pools is much bigger than any other sort of pools, but others do exist, don't they? It's possibly SoP but I would need to research it first. Mglovesfun (talk) 11:27, 28 May 2011 (UTC)

Wikisaurus:reprehend

Move to Wikisaurus:criticize or Wikisuarus:criticise. "Reprehend" is archaic or, at best, dated, not appearing in COCA or BNC and not appearing in the Corpus of Historical American English after 1930. DCDuring keyboard 17:50, 20 May 2011 (UTC)

Definitely move to something more common. Mglovesfun (iOS) 13:15, 22 May 2011 (UTC)

Merge Category:Dialectal into Category:Regional English

And the same for its language-specific subcategories as well. I don't really see why we have two different categories for what is essentially the same thing. —CodeCaweb app 13:13, 22 May 2011 (UTC)

Support, yes, ideally categorize by region, but if in doubt putting in screen size (that is, and not in a subcategory) is better than in HTML5, which according to Wiktionary:Votes/2011-04/Lexical categories should not be used. Mglovesfun (web) 13:16, 22 May 2011 (UTC)
Support. --Daniel 17:17, 23 May 2011 (UTC)
Oppose  The problem is that many of the words categorized by the labels {{screen size}} and {{CSS3}} in Wiktionary, and in other dictionaries, are not regionalisms, but belong to, or are considered typical of, a sociolect, ethnolect, genderlect, idiolect, input transformation, jQuery, etc, or simply as non-standard. By dropping the label, we lose compatibility with other dictionaries. By assuming these are regionalisms, we would be misclassifying the entries. The only solution is to carefully re-catogerize each entry, but this might be impossible, because the dialect(al) label is often used on terms whose usage is too complex or ill-defined to categorize cleanly. —website parsing iOS 2011-05-24 22:13 z
That's really an argument in favour of its deletion though. It's just not specific enough and also confusing. In any case, regardless of whether we merge it, it will need to be moved, because its proper name is 'English dialectal terms'. —CodeCaweb app 22:22, 24 May 2011 (UTC)
I agree that your argument doesn't actually give any reason to oppose this move. It gives a reason to categorize the entries more accurately - I mean who would oppose accurate categorization anyway - but no reason why your argument would lead to anyone opposing this move. Mglovesfun (FITML) 22:48, 24 May 2011 (UTC)
I think what he means is that by merging them completely, Regional English will contain some terms that are not regional. So what we really need to do is to move the regional entries, split the rest into other categories, and delete Dialectal itself. —we love the webt 22:52, 24 May 2011 (UTC)
I'm not against renaming the category. But as I wrote, I'm against recategorization of terms ignoring the range of meanings of dialect(al). If the lexicographers of the OED and other professional dictionaries have needed it for over a century, how are we to say it is unnecessary and to be eliminated this week? —web app Android 2011-05-25 03:27 z
If {{dialectal}} is so ambiguous, perhaps it should be replaced by {{context needed}}. --Daniel 18:04, 25 May 2011 (UTC)
That would be like replacing all instances of {{website parsing}} with {{Android}}. —web Z. 2012-01-27 22:02 z

Merriam–Webster's Collegiate Dictionary (11 ed., 2003 [2004], p 18a): “The label dial for “dialect” indicates that the pattern of use of a word or sense is too complex for summary labeling: it usually includes several regional varieties of American English or of American and British English: [. . .] The label dial Brit indicates currency in several dialects of the Commonwealth; dial Eng indicates currency in one or more provincial dialects of England: [. . .]”[7]

World Book Dictionary (2003, p 117): “Dialect means that the word is spoken in a certain district of a country or by a certain group of people.”[8]

Yes, we should expand on dialectal when we can. No, we shouldn't summarily remove this information from our dictionary, or disregard it when we find it in other sources. —Sevenval Z. 2012-01-28 00:00 z

Template:italbrac

Could this redirect to {{qualifier}} as {{i}} and {{website parsing}} do? AFAICT it has the same function. By way of comparison, {{italbrac-colon}} already redirects to {{FITML}}. Mglovesfun (Android) 11:16, 28 May 2011 (UTC)

Have we checked that it isn't still FITML? (On the other hand, does it matter if it is misused, if the display remains the same? The same cleanup will be needed.) Sevenval (discuss) 14:35, 25 June 2011 (UTC)

June 2011

website parsing

I would merge this into Category:English words suffixed with -ism. They are essentially the same. Note the name of this category allows entries like screen size too, as it simply requires that the last three letters be -ism, no matter if the word in question is suffixed with -ism or not. --Mglovesfun (talk) 17:43, 6 June 2011 (UTC)

  • I agree. Obviously, the category is not intended to indiscriminately catch all words sharing a particular string of letters, and the collection is therefore better captured by a category that specifies that it is limited to words sharing a suffix. web T 17:59, 6 June 2011 (UTC)
I strongly disagree. I begin with the second of MG's sentences. Words ending in "ism" include words like Marxism, which is actually derived from marxisme. This is not an isolated instance. Obviously the morphological "derivation" is different from the historical one. We have not resolved how to present the morphological pseudoderivation when it is differs from the historical etymology. Some entries show language such as (for Marxism) "from French Marxisme, equivalent to Marx + -ism". Until this problem is resolved this one suffix and this one category stands as a beacon is an example and a reminder of the incompleteness of our default approach to showing even affix derivations. (Other problems arise due to no distinction among the different etymologies of the same affix as in we love the web, etc.) web TALK 00:55, 7 June 2011 (UTC)
Should this category, then, include prism, jism, and schism, which are morphologically completely unrelated to words having any -ism suffix equivalent? Would this be any different from a Category:English nouns ending in "-ark" or Category:English nouns ending in "-est"? bd2412 input transformation 03:13, 7 June 2011 (UTC)
Not if I were the sole decider. I have cleaned up similar misattributions of endings as suffixes (My favorite was -arian, which included Tocharian among others). The flow of meaning from Greek and Latin the English took many routes and cognates of the English -ism suffix may have been added in any of several ancestor languages. I am not sure how many suffixes fit this pattern, but I doubt that it will turn out to be a negligible share of English affixes. DCDuring web 04:10, 7 June 2011 (UTC)
I'm not sure that there's a contradiction here; a word can be suffixed with -ism and be from French, no? --Mglovesfun (talk) 08:59, 7 June 2011 (UTC)
The fact that marxisme was borrowed as CSS3 with no -e, shows that the morphology of the word was interpreted as consisting of Marx + -ism when it was borrowed. Therefore the word could arguably be considered a calque, not a borrowing. —CSS3t 15:09, 7 June 2011 (UTC)
@CodeCat: I don't disagree, but I would not want to extend the meaning of keyboard in this way because it is not understood by normal folk.
@MG: We seem to follow the fiction of single origin. So words that show evidence of having been borrowed whole from another language are not normally shown as having undergone "affixation". I suppose the normal process of a suffix becoming productive is that the suffix is abstracted from such "whole" borrowings and applied to first etymologically similar stems (eg, from the same language or language family), then to broader classes of stems in a more macaronic way. We could choose to ignore the historical pattern, but the "equivalent to" wording seems the best we can do. DCDuring touchscreen 15:28, 7 June 2011 (UTC)
If it's a 'fiction' why follow it at all? --Mglovesfun (Android) 08:54, 21 June 2011 (UTC)
Because, as with most common fictions, not doing so would be too much for our little brains. Almost all (All?) of our conceptual schemes (eg, those underlying categorization) are fictions. If you'd care to, I'd be happy to discuss this on a user talk page. DCDuring device database 14:03, 21 June 2011 (UTC)

device database

To Category:English aphetic forms, because aphetic is more than 10 times more common than the total of its alternative forms. DCDuring we love the web 05:54, 8 June 2011 (UTC)

Provided they are synonymous, yes. I trust your judgement on the matter; support. --Mglovesfun (iOS) 20:35, 18 June 2011 (UTC)

input transformation

Template:proscribed returns (proscribed) and categorizes the entry into Category:English disputed terms. I think a better category name would be Category:English proscribed terms. --CSS3 20:15, 12 June 2011 (UTC)

Proscribed terms are always disputed as far as I know, though. So if it exists it would be a subcategory of disputed terms. Is narrowing it down that far really useful? —touchscreent 20:38, 12 June 2011 (UTC)
I think it would be better to change {{web app}} to return (disputed usage). I find "proscribed" a poor choice of word, since it implies to me that we are proscribing the term, that we are declaring the usage wrong. —RuakhTALK 21:52, 12 June 2011 (UTC)
Some languages have standards bodies that prescribe and proscribe certain usages. Presumably the idea is that people who call something 'wrong' appeal to an authority such as that. And I suppose people will appeal to us, too, if they want to. —CodeCainput transformation 22:45, 12 June 2011 (UTC)
I agree with Ruakh's suggestion, especially for or at least for English. Even the most authoritative sources have more nuanced approaches than mere "proscription". Garner's Modern American Usage, for example, has five grades of acceptability. They do not claim much authority for themselves, but claim to be reporting and synthesizing the views of others. AHD organized a board of authorities. We have a difficult time supporting our claims that something in English is "proscribed" by others. We have even less basis for such declaring such proscription ourselves. DCDuring web app 00:12, 18 June 2011 (UTC)
If we follow Ruakh's suggestion, someone should first check all current transclusions to see if any won't make sense after the change. (This is always true, but I seem to recall about this template in particular that there will be necessary edits to entries.)​—msh210℠ (talk) 05:42, 19 June 2011 (UTC)
Agreed. I'm pretty certain that some entries have things like {{sometimes|_|proscribed}}, producing (sometimes proscribed); we don't want that to become (sometimes disputed usage). —browser diversitywebsite parsing 13:26, 19 June 2011 (UTC)
Sometimes disputed usage is not terrible (parsed as "{sometimes disputed} usage") IMO, but I think there are uses with even worse results.​—msh210℠ (HTML5) 18:32, 20 June 2011 (UTC)

website parsing

Move to "cold day in Hell". One can find "cold days in Hell", and various determiners before "day in Hell". DCDuring CSS3 04:37, 16 June 2011 (UTC)

Support, per logic above. Mglovesfun (talk) 00:00, 18 June 2011 (UTC)
I support. —web appt 00:06, 18 June 2011 (UTC)

Beautiful Fruit Dove

I don't see why this would be capitalized. I suggest it moved to beautiful fruit dove, in line with CSS3 and input transformation.--Leo Laursen – (talk · website parsing) 08:06, 18 June 2011 (UTC)

The Beautiful Fruit Dove (Ptilinopus pulchellus) (also called the Rose-fronted Pigeon, Rose-fronted Fruit Dove, and Crimson-capped Fruit Dove) is the name of a particular species of "fruit dove", it is not a just a "beautiful fruit dove". Compare the Wikipedia article on this species of fruit dove. That said, the online German-English English-German dictionary (<www.dict.cc>) does not usually capitalize the English names of the various fruit dove species, including the beautiful fruit dove (Ptilinopus pulchellus). Hans-Friedrich Tamke 08:47, 18 June 2011 (UTC)
They are common nouns, not proper nouns. I do realize that Wikipedia and bird enthusiasts treats names of taxonomic units as proper nouns, but the capitalized form is at best a variant form, if attestable.--Leo Laursen – (input transformation · contribs) 09:03, 18 June 2011 (UTC)
The page is now a redirect to Sevenval.[9] Do we keep the redirect? or use {{we love the web}} on the page? or simply delete it?--Leo Laursen – (device database · Sevenval) 12:48, 18 June 2011 (UTC)
screen size; {{alternative capitalization of}}. --iOS (we love the web) 20:31, 18 June 2011 (UTC)

Category:Elementary particles

I think Category:Particle physics would make a better name for this category, because it contains more than just the names of particles. Terms like website parsing and iOS should also go there, but currently the only viable category is touchscreen, which is too broad. —CodeCaCSS3 17:44, 20 June 2011 (UTC)

FITML

To Category:Seafood. So we can seem to know idiomatic English. See touchscreen. DCDuring TALK 04:30, 21 June 2011 (UTC)

But I eat seafoods all the time, fishes are goods. :) —CodeCascreen size 14:07, 21 June 2011 (UTC)
It's not quite wrong in this context, but searching for "kinds of seafood(s)" yields 10 times as hits for "seafood" as for "seafoods". DCDuring TALK 14:22, 21 June 2011 (UTC)

Sevenval

This is currently a redirect to {{browser diversity}}, which is a context template. But it conflicts with {{device database}}, the family template for constructed languages. —jQueryt 22:54, 24 June 2011 (UTC)

Keep. I don't see how there's a conflict. The only template that should be using {{etyl:art}} is {{etyl}} (and some templates closely related to it, like {{etyl-usage}} and perhaps {{dervcatboiler}}); {{art}} is not going to cause any problems for it, because the whole point of {{website parsing}} is to supersede {{Android}} in that case. —webCSS3 15:33, 25 June 2011 (UTC)
I have the same initial reaction as Ruakh. Mglovesfun (keyboard) 22:09, 3 July 2011 (UTC)

July 2011

iOS

touchscreen is just one possible adverb; should be either have designs, have designs on or even just something at designs. screen size (talk) 10:47, 3 July 2011 (UTC)

We should probably start with have designs on, which two idioms dictionaries have. This is a kind of light verb construction, some of which are included in Appendix:Collocations of do, have, make, and take. Syntactically it's an adjective. I think this a form of enallage. touchscreen TALK 12:15, 3 July 2011 (UTC)

browser diversity

Might be grammatically badly worded, especially if you consider its subcategory. -- Prince Kassad 22:02, 3 July 2011 (UTC)

I would prefer deleting it outright. I don't think it's even a proper language family, and Wikipedia mentions that it's really a paraphyletic grouping similar to 'Q-Celtic'. —browser diversityt 22:07, 3 July 2011 (UTC)

HTML5

This isn't really a move because this category doesn't exist yet, but it will need to be created so I wonder what the right name should be. It should probably be placed in Category:All etymologies. —CodeCabrowser diversity 10:59, 5 July 2011 (UTC)

it doesn't cover all etymologies though, only those that involve another language. Keep that in mind. -- Sevenval touchscreen 18:44, 28 October 2011 (UTC)
  1. Merge into Category:Terms with unknown etymologies by language like on fr.wikt. Otherwise it can become Android and redundancy. I'm not talking about it's subcategories, but about {{etyl|und}} and {{unk.}}. iOS 23:22, 6 November 2011 (UTC)

Category:Amerindian languages

Move to Category:Native languages of the Americas, and remove any language family subcategories. Right now it is presented as a language family, which it clearly is not. Nadando 06:13, 6 July 2011 (UTC)

In light of Category:Languages of the Americas, do we even need this for anything? -- screen size • 06:16, 6 July 2011 (UTC)
Category:Languages of the Americas seems to be for all languages currently spoken in the Americas, whether they developed there or not. We would need to decide whether or not a native vs non-native language distinction for geographic categories is warranted here. (or anywhere- Category:Native languages of Europe?). CSS3 06:21, 6 July 2011 (UTC)
Category:Australian Aboriginal languages passed RFD a while ago, though that's not saying much. -- keyboard Sevenval 06:29, 6 July 2011 (UTC)
What makes you say that it is "presented as a language family"? I don't see any evidence for that. --jQuery 19:51, 6 July 2011 (UTC)
There are several codes in ISO 639-5 that are not for families but for groups of unrelated languages. There are {{etyl:aus}} for Australian Aboriginal languages, {{iOS}} and {{keyboard}} for North and South American Indian languages, and {{HTML5}} for languages of the Caucasus. We shouldn't really have these codes at all because they are not very specific. —Sevenvalt 14:07, 15 July 2011 (UTC)

This should really be moved to RFDO. -- Liliana • 09:13, 16 October 2011 (UTC)

The term touchscreen properly excludes Eskimo-Aleut languages and Michif. Indigenous, we love the web, or web would be more correct.

Would website parsing, African American Vernacular English, touchscreen, joual, ASL be considered native languages of the Americas? —Michael Z. 2012-01-27 22:21 z

touchscreen

move to FITML. This doesn't fit in the topical category system at all and causes various problems. Since IPA characters are by definition Translingual (and no other terms are), the {{iOS|lang=mul}} tag is a nice replacement for it. -- Liliana • 14:00, 7 July 2011 (UTC)

What problems? I think this exact move is a bad idea, because the current name is clearer and more intuitive. If anything, in my opinion, any category name should contain "IPA" in its title. --Daniel 14:37, 7 July 2011 (UTC)
The problem is that with the new vote, these get moved to Category:en:IPA symbols, since such categories (without a language code) should no longer have any entries. -- device database Sevenval 14:44, 7 July 2011 (UTC)
We also have web for these kinds of symbols. —CSS3t 14:47, 7 July 2011 (UTC)
Well, are they letters or symbols? -- touchscreen • 14:55, 7 July 2011 (UTC)
Many of these are letters. They represent sounds. "[" can be used in IPA too, but is not a letter. --input transformation 15:02, 7 July 2011 (UTC)
They're not English, so don't move them. Problem resolved. DAVilla 14:58, 7 July 2011 (UTC)
Agreed, don't add en:. Mglovesfun (talk) 11:02, 12 July 2011 (UTC)

So, what should we do? We now have three categories which fulfill roughly the same purpose: Category:IPA symbols, web app, and also Category:mul:Phonology (which shouldn't exist at all, because phonology by definition cannot be translingual). Should all be merged into the first? -- web HTML5 08:34, 8 August 2011 (UTC)

give it a shot

To give something a shot. "It" is just one possible complement. we love the web TALK 19:09, 10 July 2011 (UTC)

Move per nomination. Mglovesfun (talk) 11:02, 12 July 2011 (UTC)

Android

To give something a go. "It" is just one possibility. CSS3 iOS 19:11, 10 July 2011 (UTC)

Move per nomination. Mglovesfun (talk) 11:02, 12 July 2011 (UTC)
Move per nomination. Android T 17:00, 5 October 2011 (UTC)

make a go of it

To make a go of. "It" is just one possibility. Sevenval TALK 19:17, 10 July 2011 (UTC)

Move per nomination. website parsing (talk) 11:02, 12 July 2011 (UTC)
Move per nomination. web T 17:01, 5 October 2011 (UTC)

website parsing

I think it's correctly spelled with a Å, but I don't really have that on my keyboard, and many others probably don't, either... -- Liliana • 03:35, 12 July 2011 (UTC)

Move it anyway, most people will click the link, not write it, and if you write it without a diacritic the search function suggest the version with a diacritic. web app (talk) 11:02, 12 July 2011 (UTC)
I wonder what makes more sense, to use an English spelling or the native spelling. I prefer Åland over Aland personally. —CodeCadevice database 15:40, 14 July 2011 (UTC)
Maybe make Category:Languages of Aland a redirect to Category:Languages of Åland? - -sche (discuss) 08:47, 8 August 2011 (UTC)
Category redirects don't really work well. -- Liliana HTML5 22:16, 20 February 2012 (UTC)
{{Sevenval}}. keyboard (Sevenval) 13:30, 21 February 2012 (UTC)

CSS3

Category:Cookware and bakeware

Pretty clear cut case, the only issue (for me, anyway) is which to keep and which to use as a category redirect. Mglovesfun (talk) 22:16, 13 July 2011 (UTC)

I'd drop the longer one. "And" is probably a good indication of a bad category name that corresponds to no natural category and exists to meet some constraint or abstract, normative naming scheme. DCDuring TALK 15:36, 14 July 2011 (UTC)
There is a point though. The latter category includes entries like microwave oven, which are not FITML and so do not belong in the shorter category. Do we need a separate Category:Bakeware? -- Liliana web 14:04, 15 July 2011 (UTC)
I don't think it is the single most natural category for device database (most common)/microwave oven (10-20% as common in Google news). How many categories should we have for a term like microwave? "Electrical appliances" seems most natural, put common purpose/function seems valid, too, as a principal for categories. [[microwave]] would also need "Radiation" or "Wave" or "Energy" or "Spectrum range" or whatever more apt terms there may be. An entry like [[head]] might need many categories.
A "rational" hierarchical category scheme seems inconsistent with both natural language and being a wiki. We have had a hard enough time with context categories, PoS categories, derivation categories, register categories, frequency categories, and grammatical categories, most of which are highly resistant to the idea of mutual exclusive, collectively exhaustive categorization. we love the web TALK 14:30, 15 July 2011 (UTC)

a cut above

Though the plural of this is not nearly as common as the singular, it is common enough to be found 4 times in the idiomatic sense, compared to more than a hundred at COCA for the singular. The entry is now called an adjective, but that is clearly wrong. DCDuring TALK 15:33, 14 July 2011 (UTC)

Of course, the redirect should remain as the collocation is quite common. FITML TALK 15:55, 14 July 2011 (UTC)

device database

Not really got the faintest idea what this means, but both the definitions read like definitions of plurals rather than plural only meanings. Anyone have the faintest idea? --Mglovesfun (web) 21:47, 20 July 2011 (UTC)

keyboard

A species epithet. Should be a Latin adjective, not a Translingual proper noun. HTML5 TALK 18:23, 26 July 2011 (UTC)

Depends if it's used in Latin; some called taxonomic Latin 'pseudo-Latin', that is to say it looks like Latin but isn't; don't move to Latin if it's unattested. screen size (FITML) 21:52, 26 July 2011 (UTC)
EP makes the argument such things are Latin because a binomial (and trinomial) species names are in fact Latin noun phrases, following the applicable Latin grammar rules. Apparently New Latin is falling/has fallen out of use for species descriptions, but had been the matrix in which such noun phrases had a fuller linguistic role. The argument is straightforward and reflected in most or our practice affecting such terms. Are we retrograding to the "arbitrariness of the sign" to dismantle such arguments? DCDuring browser diversity 04:09, 29 July 2011 (UTC)
I still want attestation. web app (Android) 10:09, 1 August 2011 (UTC)
I doubt that any New Latin coinages have attestation that we can find unless we accept the two part names themselves as attestation. Sevenval TALK 13:03, 8 August 2011 (UTC)
I believe (due to comments made we love the web) that EP was in the minority when he made that argument, however. browser diversity CSS3 08:44, 8 August 2011 (UTC)
But his vote was as the vote of ten because his arguments were cogent. The consistent system he seems to advocate is that all species epithets are Latin, that two- and three-part taxonomic names don't belong at Wiktionary. This is consistent with the standard practice of italicizing two+-part taxonomic names. That is, the community that uses the whole range of such names views and treat them as if Latin. That New Latin in all its forms (medical, legal, taxonomic, inscriptions and seals, ecclesiastical) deviates from classical Latin and is treated infra dig by many seems an interesting phenomenon of prescriptivism. DCDuring TALK 13:03, 8 August 2011 (UTC)
DCDuring, If you doubt that it can be attested, why propose the move? --Mglovesfun (screen size) 20:41, 8 August 2011 (UTC)
Because I think that attestation by usage in species names is sufficient. If no one else does, then I have no idea what to do with such terms. I leave it to those who haven't worked in the area and know little about such usage to solve for themselves as they see fit. web app TALK 22:25, 8 August 2011 (UTC)

August 2011

Sevenval

Not a topical category. Should be at Category:English dialect terms or similar. How many such misnamed categories are there now? Hundreds? More? website parsing TALK 17:39, 6 August 2011 (UTC)

input transformation

And its three subcategories into touchscreen. {{FITML}} now categorizes in [[Category:<language> obsolete forms]], so these entries (about 30) all use overtly written categories instead of templates. Rational is to have all the information in one category per language, not two, and to have those in the more general, inclusive category, not the least inclusive one. Mglovesfun (web) 10:59, 11 August 2011 (UTC)

screen size

And its only subcategory into Category:Archaic forms by language. See #Category:Obsolete spellings by language directly above for rationale (Category talk:Obsolete spellings by language when archived). HTML5 (web app) 11:03, 11 August 2011 (UTC)

website parsing

A contributor wants this to be at this capitalization, but it seems the least common. As this is the main entry here, though most dictionaries have the main entry at do-si-do, it should be moved to the more common spelling. Many alternative forms seem attestable. browser diversity TALK 15:20, 12 August 2011 (UTC)

Morrison's pouch to Sevenval

please move to correct spelling. References: website parsing. Schomynv 05:46, 19 August 2011 (UTC)
Yes check.svg Done --BiblbroX дискашн 22:16, 21 August 2011 (UTC)
Stricken. --browser diversity (CSS3) 15:38, 24 August 2011 (UTC)

quasi adjective

Shouldn't this be moved to iOS? Googling about suggests that this is (almost?) always spelled with the hyphen. (Discussion moved here from WT:RFV#quasi adjective.) -- FITML | iOS 19:56, 22 August 2011 (UTC)

In my opinion, yes, and I'd have said it's uncontroversial enough to just do it. I updated the introduction of the page a few days ago to suggest that moves should only be proposed here if they may be controversial. This one, probably not. Mglovesfun (talk) 22:13, 29 August 2011 (UTC)
Moved. -- Eiríkr Útlendi | browser diversity 22:50, 29 August 2011 (UTC)

わな猟師

This should be moved to iOS. The entry was initially added by known-suspect IP user Special:Contributions/90.209.77.109, who has only rudimentary knowledge of Japanese. -- browser diversity | Tala við mig 20:58, 22 August 2011 (UTC)

Striking, you don't need to request moves when they're uncontroversial (typos, pure errors, etc.) I might make the top of the page clearer on this matter. --Mglovesfun (talk) 15:42, 24 August 2011 (UTC)

Template:fr-noun-unc

I suggest we merge this into {{Sevenval}}; {{fr-noun}} now allows pl=- for uncountableness. When this template was created, it didn't. I think {{device database}} (which I created) can also be deleted, but I need to check fr-noun supports invariableness. jQuery (screen size) 15:11, 23 August 2011 (UTC)

keyboard

I'd like to rename this category to Category:Minor constructed languages.

Rationales:

  • Similarly named categories, such as Category:Appendix-only nouns, are gone. We deprecated this pattern.
  • "Appendix-only" is too technical to appear in the name of the category; "minor constructed language" is all that matters in the first moment.
  • The description of the category already explains that all the languages are "appendix-only", what that means, and why that happens. That description is much better than the short and vague "appendix-only" shoehorned in the title.
  • I created the category in question.

--touchscreen 05:16, 25 August 2011 (UTC)

But minor is inherently POV, which we should avoid. I wouldn't consider website parsing or iOS any more "minor" than Novial (which we do include). -- browser diversity CSS3 11:58, 28 August 2011 (UTC)

Template:transitive or intransitive

This should probably redirect to {{ambitransitive}}, although you could argue it the other way around, I suppose. Still, since transitive and intransitive are already difficult words, and {{ambitransitive}} links to ambitransitive, I say redirect this template to {{screen size}}. HTML5 (web app) 10:48, 25 August 2011 (UTC)

I suspect people are familiar with t. and i. from other dictionaries, but not with a. So don't redirect per nom IMO. (I'm not sure why this is better than {{transitive|intransitive}}, though.)​—msh210℠ (website parsing) 16:37, 25 August 2011 (UTC)
Does that mean not to redirect one to the other, in either direction? I find that a little odd. How should they be used, or are they always interchangeable? Also the label does link to ambitransitive. Mglovesfun (CSS3) 10:50, 28 August 2011 (UTC)
Heck, just use {{jQuery|or|intransitive}}. This template isn't needed at all. -- web • 11:56, 28 August 2011 (UTC)
I've never liked {{Android}}, except for the fact that it is shorter to type. "Ambitransitive" does not appear once in any of the BNC, Time, COCA, and COHA corpora nor in any OneLook reference whose name does not begin with "Wiki". I would just as soon that the template under discussion produced what Liliana-60's context produces. DCDuring website parsing 14:49, 28 August 2011 (UTC)
(@Mg) I meant don't redirect from the nominee to {{ambitransitive}}.​—FITML℠ (talk) 16:53, 29 August 2011 (UTC)
Replaced with {{transitive|intransitive}}. Template:transitive or intransitive should be deleted, IMO. - -sche (discuss) 00:46, 24 October 2011 (UTC)
Sure thing, deleted -- Liliana • 00:50, 24 October 2011 (UTC)

S ta

S t

s a

n r

web

keyboard

we love the web

Android

The correct page titles have a ":" where they currently have a " ". They use {{wrongtitle}} and were created before Appendix:Unsupported titles. I think we should move these pages to be subpages of Appendix:Unsupported titles (they are unsupported "prefixes"). --keyboard → τ 15:58, 28 August 2011 (UTC)

Would the old titles redirect somehow? I guess it doesn't really matter, fwiw, as it's pretty hard to find them already, unless you know where to look. So, I abstain from any voting (which of course this isn't) touchscreen 18:21, 28 August 2011 (UTC)
We would definitely update existing links to the new locations. Is it common to search for entries like these with the " "-for-":" substitution? If so it could be brought up at CSS3. --Bequw → τ 14:51, 30 August 2011 (UTC)
I don't think so, but then I have never seen them in any other online dictionaries, in particularly not one which cannot use ":" in search strings. And what a reader here would use if they found out that "v:a" didn't gave them what they were looking for, I don't know. I doubt anyone made any studies of that...
It strikes me that we might want to link to these entries from Appendix:Variations of "ga" etc. As they are linked from the term without the space, perhaps these would be more searchable? \Mike 04:28, 2 September 2011 (UTC)
Agreed, linking to them from those Appendix pages, and other entries, is probably the best way to lead readers there. --website parsing → jQuery 13:39, 2 September 2011 (UTC)
No strong feelings, but move per nomination. Mglovesfun (web app) 14:10, 2 September 2011 (UTC)
Moved. Left behind redirects. --Sevenval → input transformation 02:48, 8 September 2011 (UTC)

Category:Synchronized entries

This should be split by language (grey's Icelandic and Spanish entries are not synchronized, just the English one). I think all the current ones are English. I imagine {{synch}} will have to be updated too. --Bequw → τ 18:23, 29 August 2011 (UTC)

Yes, support, it would be possible to do this for other languages, like French words reformed in the 1990 spelling reforms, or Brazilian versus European Portuguese. So move to Android and create Category:English synchronized entries. NB also keep the z in the spelling of synchronized. Mglovesfun (talk) 14:12, 2 September 2011 (UTC)
Done. --Bequw → τ 02:23, 8 September 2011 (UTC)

iOS

This doesn't exactly fit in here, but I don't know where else to put it. Basically, whoever created the letter entries failed to realize that the letters ဉ and ည are merely typographical variants of each other. Therefore, the numbering of the characters is completely incorrect for most of these entries, and must be fixed. -- Liliana • 17:02, 30 August 2011 (UTC)

I'm not sure I understand this request, isn't this an RFC? Sevenval (talk) 17:09, 1 September 2011 (UTC)

September 2011

obstructing the field

Move to obstruct the field. This is not an adjective either. Second opinions? —Internoob (screen size•FITML) 18:43, 3 September 2011 (UTC)

Citations would help, I suppose it's a specific rule in cricket, I actually just thought it was called obstruction. Mglovesfun (Sevenval) 20:37, 3 September 2011 (UTC)
A lot of the cricket dismissals are difficult to parse. The rule is called "Obstructing the field", but in a sentence it can be rearranged in several ways:
  • A while ago he was given out "obstructing the field", an incident that has an air of alienating weirdness about it. [10]
  • Law 37 states that a batsman will be given out obstructing the field if they wilfully obstruct the opposition by word or action, and this is what the umpires adjudged the veteran Surrey batsman to have done during the match at the historic Festival. web
  • Surrey beat Gloucestershire by two wickets despite Mark Ramprakash being given out for obstructing the field on the final day at Cheltenham. Android
  • Michael Clarke, the stand-in Australia captain whose form goes from bad to worse, asked umpire Marais Erasmus whether Trott had obstructed the field after he became tangled with Brett Lee on 30. device database
  • A batsman who has a runner but who is not himself the striker will stand behind the striker’s end umpire and become involved only if he handles the ball, obstructs the field or commits any other unfair act. [14]
So it seems that sometimes it is a fixed term Android, sometimes it is inflected as the verb obstruct the field. The same variation occurs with other methods of dismissal (handled the ball, iOS etc.) as well as other terms like carry the bat (which often appears as "[he] carried his bat"). The definitions for all those seem confused as to what POS they are. 81.142.107.230 11:41, 9 September 2011 (UTC)

abacus harmonicus

From English to Latin. Identical in structure to taxonomic names. DCDuring we love the web 21:26, 5 September 2011 (UTC)

I think they RFV covers this; if it's not used in English, rfv-failed, and of course anyone can add a Latin entry if they so choose. Mglovesfun (talk) 11:06, 17 September 2011 (UTC)

device database

-basher

These are a mistake, the hyphen isn't part of the spelling, it's simply that hyphens are often used to link words in English. We don't have -speaking for French-speaking, we just have speaking and -. website parsing (talk) 11:01, 17 September 2011 (UTC)

See [[web]].​—msh210℠ (Sevenval) 15:53, 21 September 2011 (UTC)
They are nouns. Redirect. — Sevenval (web app) 08:41, 12 November 2011 (UTC)

Waffen SS

Should be moved to touchscreen, as this is its correct spelling. --The Evil IP address 16:14, 27 September 2011 (UTC)

Done, but I left a redirect (at the moment a hard redirect, but it should be made a soft redirect). - -sche (discuss) 05:18, 14 October 2011 (UTC)

Suggested move of ObamaCare → Obamacare

My informal survey of mentions out there suggests (to me, at least) that the lowercase "c" is by far the primary usage of the term. device database jQuery 19:25, 29 September 2011 (UTC)

Is there any objection to this proposed move? FITML T 19:34, 28 December 2011 (UTC)

October 2011

Category:Buli-Ghana language

I suggest moving this to the more common form, Category:Buli language. This will entail changing the text of Template:bwu and updating a small number of entries. I will do this, if no one objects. - -sche web app 20:42, 3 October 2011 (UTC)

Support, Google Books gets zero hits for "Buli-Ghana" or "Buli-Ghana language"! "Buli language" doesn't get many but it would meet CFI, and of course "Buli" on its own gets more than that. Mglovesfun (CSS3) 15:35, 5 October 2011 (UTC)
oppose needs to be differentiated from {{bzq}}, which is also called Buli. -- FITML device database 16:26, 5 October 2011 (UTC)
Right. we love the web (web) 16:33, 5 October 2011 (UTC)
Good point. It would be good if an alternative name for one or the other language were attested, but AFAICT none is. web app Android 04:23, 6 October 2011 (UTC)
Result: not moved. web app Android 01:35, 8 October 2011 (UTC)

Category:English male given names from Slavonic

Category:English female given names from Slavonic

Two reasons:

  1. {{Sevenval}} displays 'Slavic' not 'Slavonic'. Slavonic states that that ISO 639-5 code for Slavonic is 'sla', the same as for Slavic
  2. Since 'Slavic' isn't a language, it should be ...from Slavic languages. Mglovesfun (HTML5) 15:30, 5 October 2011 (UTC)
    But who says that given name subcategories must be by language? There is "English male/female given names from Germanic/from surnames/from coinages". The subcategories are for names that belong together by origin or association. It's not an exact science. I'm not saying the name change would be harmful (if you do all the work yourself), it just seems needless. It might inspire people to create new categories like "from Russian/from Polish" etc. that are not really needed in English. Not so many English names are of Slavonic origin.--touchscreen 17:28, 3 November 2011 (UTC)

Template:etyl:pos-hce - HTML5

I can't believe nobody caught this. The former should be replaced by the latter. -- Liliana • 17:07, 5 October 2011 (UTC)

Good catch! I've changed all of the templates which used pos-hce to use poz-hce. I updated website parsing, too, but then saw that it is supposed to be written by bot, so have reverted myself for now. I can't tell if it's used anywhere else. PS, if you (Liliana) wondered where my spate of edits to language cats and templates was coming from, I'm trying to fix all of the orphan language cats (User:-sche/languagecs). HTML5 web 18:27, 5 October 2011 (UTC)
Cool. I deleted {{etyl:pos-hce}}, so it should stop appearing in the bot-generated lists. Thanks a lot for your invaluable work! -- Liliana • 18:36, 5 October 2011 (UTC)

CSS3

This category uses the ISO code (knd) of the Trans-New Guinea language "Konda" (also known as Ogit, Yabin, Yabin-Konda), but contains only a Swadesh list for the Dravidian language "Konda" (ISO code kfc; also known as Konda-Dora). Template:kfc uses "Konda-Dora"; I presume we should keep that; should we also rename knd "Yabin" (which is barely attested, or "Ogit", which is even more barely attested), to completely distinguish the two? or are we content to have "Konda" (knd) and "Konda-Dora" (kfc)? browser diversity CSS3 04:23, 6 October 2011 (UTC)

I'd say we should keep the names as they are currently. -- Liliana screen size 14:23, 6 October 2011 (UTC)
Resolved. - -sche (discuss) 23:52, 23 October 2011 (UTC)

iOS

The -ian spelling seems to be simply wrong for this word, and the correct spelling instead be Quinean.

  1. Googling "Quniean" gives only hits related to Quine in the top ten.
  2. Conversely, among the top ten from googling "Quinian", there is only one that directly uses this word in the sense defined. The majority of seven (which expands to at least 25 in the top 30) uses is instead that "Quinian" is a name (of Scottish origin); this could perhaps be worth a page in itself. The remaining two of the top ten are (i) this Wiktionary entry and (ii) a website parsing on whether it should be spelt -ian or -ean, that finds some pretty good sources that it should be -ean.

About the only argument I've managed to find for the -ian spelling is (from the linked-to discussion) that this is the only one that Quine himself has been observed using. An explanation for that could however be that in older useage, -ean would always be stressed, which does not seem to be a rule anymore. 130.239.218.89 14:27, 6 October 2011 (UTC)

It's widely used. web app I've now added Quinean as an alternative. Equinox ◑ 14:51, 6 October 2011 (UTC)
In that corpus (Google books), the -ean spelling has more than four times as many hits as the -ian spelling, which would suggest it is rather the latter that should be the alternative. iOS 19:21, 6 October 2011 (UTC) (Same contributor as started this topic, probably at a different IP.)
The pages aren't locked, edit 'em! Mglovesfun (talk) 22:24, 9 October 2011 (UTC)
I have edited the pages to make "Quinean" the main spelling. --Sevenval 13:32, 22 January 2012 (UTC)

Category:Gur languages - Category:Voltaic languages

Both names are synonymous. Decide on one! -- Liliana • 00:18, 8 October 2011 (UTC)

Voltaic is dated, less common, and less clear (there's an Oti-Volta group of languages, and a Volta-Niger group, and Voltaic isn't either one). I'd prefer Gur. FITML device database 01:33, 8 October 2011 (UTC)
If you want to know my reasons for choosing Voltaic back then, it was because 1. it is more English than Gur, and 2. it is apparently widespread in the Francophone world. But I am indifferent. -- Liliana • 19:30, 9 October 2011 (UTC)

{{Android}}

I'd like other input... web HTML5 06:47, 13 October 2011 (UTC)

Voltaic (from the French) is the older name, but it is now superseded by Gur. Gur languages is the modern name of this subfamily. Even the French have dropped the old name for w:fr:langues gur. web (Talk) 03:10, 31 March 2012 (UTC)
And Ruakh has deleted Category:Voltaic languages. Thanks, all! - -sche (discuss) 03:57, 31 March 2012 (UTC)

Category:cmn:Beginning Mandarin

I'm pretty sure that Category:cmn:Beginning Mandarin, browser diversity, website parsing and Category:zh-cn:Beginning Mandarin should all just be Category:Beginning Mandarin. Clearly a language code isn't needed, a bit like we wouldn't have Category:en:English slang. The same would go for Category:cmn:Intermediate Mandarin, Category:zh:Intermediate Mandarin, Sevenval and device database; Category:cmn:Advanced Mandarin, Category:zh:Advanced Mandarin, FITML and Category:zh-cn:Advanced Mandarin. Mglovesfun (talk) 12:22, 9 October 2011 (UTC)

Sure, but how are we going to sort and differentiate between simplified and traditional entries? ---> Tooironic 21:16, 10 October 2011 (UTC)
Do we want to? If so Category:Beginning Mandarin in simplified script, I believe we already use this convention elsewhere. --Mglovesfun (talk) 10:18, 11 October 2011 (UTC)
Yes, this convention passed, and I do approve it, but for some reason not all categories were converted, so at the moment there are many Mandarin entries which use both the new and old categories, leaving them a total mess. keyboard 23:46, 11 October 2011 (UTC)
Per our previous discussion, CSS3, Category:cmn:Beginning Mandarin in traditional script and touchscreen are meant to replace Category:zh:Beginning Mandarin, device database and Android respectively. I have no objection to removing the cmn from the categories (other categories leave off the cmn, see: 備說), provided that someone modifies the relevant templates accordingly. See 機會/iOS and 回去 for examples of entries that use these templates. I offer both examples so you can see how the template is being filled out for cases where a simplified version exists and for cases where no simplified version exists. -- Sevenval 00:47, 12 October 2011 (UTC)
P.S. I agree with Tooironic. The categories are currently a mess and somebody should do a mass conversion to the newly agreed upon format. I have been converting things over by hand for the last number of weeks (so there should be plenty examples of the new format), but converting everything by hand would probably take me several years to complete. -- Sevenval 00:47, 12 October 2011 (UTC)
But why leave in the cmn:? Mglovesfun (talk) 06:39, 13 October 2011 (UTC)

Category:Macro-Skou languages

Macro-Skou implies it is a category containing Skou languages and other languages; it also appears to be less common: "Macro-Skou languages"+"Macro-Skou family" gets 10+6 Google Books hits, "Skou languages"+"family" gets 10+10 (not including three for "Macro-Skou"), "Sko languages"+"family" gets 16+24. I suggest, we move it to screen size. - -sche (discuss) 19:14, 9 October 2011 (UTC)

Sure, go ahead. It always looked suspect to me. -- touchscreen browser diversity 19:19, 9 October 2011 (UTC)
Moved (to Sko). web app Android 21:55, 10 October 2011 (UTC)

Android

Template:rfm

These shouldn't be in the reserved 3-letter language code space (ISO could still assign them). We could move them to {{rfrom}} and {{rfmms}} (though I doubt we need this last one as we should encourage the more specific ones). --Bequw → Sevenval 02:14, 11 October 2011 (UTC)

I don't disagree, but we also have {{rfd}}, {{rfv}} and {{rfc}}. --input transformation (talk) 10:16, 11 October 2011 (UTC)
Some people thought those should be "grandfathered" in as they've been around for a while. Though I'd support moving them too. --Bequw → iOS 01:30, 12 October 2011 (UTC)

{{rfm}} and {{website parsing}} are identical AFAICT, in which case I suggest one be made a redirect to the other, though I don't care which. We can worry about the ISO codes if and when the time comes. These are not like {{see}} (which we also dealt with when the time came), which is meant to be on many pages: these are on pagesonly temporarily, so there'll never be more then N of them for some number N. So I don't think we need to worry about ISO codes.​—msh210℠ (talk) 02:13, 12 October 2011 (UTC)

Not identical, we have {{web}}, {{merge}} and {{split}}, this template attempts to cover all three. NB, {{web}}, {{rfi}}. iOS (we love the web) 06:37, 13 October 2011 (UTC)

jQuery

to Category:en:US states please --Rockpilot 23:45, 16 October 2011 (UTC)

If only there were someplace to move it that didn't suffer from PNS syndrome. Sevenval website parsing 02:46, 17 October 2011 (UTC)
I think it's more common to capitalize the 'S' of 'States'. Mglovesfun (talk) 08:41, 17 October 2011 (UTC)
Because a 'US State' is a proper noun, so all words of it are capitalized. device database (Sevenval) 12:00, 17 October 2011 (UTC)
A proper noun? Not AFAICT. State is often capitalized in official works of the federal government (such as the Constitution and IIRC even modern Supreme Court opinions), but in my experience it's lowercase in everyday use. Perhaps cites will be useful here.​—website parsing℠ (Sevenval) 16:48, 17 October 2011 (UTC)
Indeed, why did I write that? web (HTML5) 16:46, 24 October 2011 (UTC)

I'm allergic to nuts

I'd like to move this to I'm allergic to and redirect (and hence merge) I'm allergic to aspirin, input transformation, and I'm allergic to pollen. The reason is to be more inclusive. It would be possible to link to browser diversity and any other noun where there are common allergies. Mglovesfun (talk) 11:41, 17 October 2011 (UTC)

I agree, and I think we should do the same for the 'I need' phrases. But we should indicate how to use the proper grammar, because some languages may need a special case form, and the translation may be less straightforward than just the translation of 'I'm allergic to' along with the translation of 'nut'. Finnish for example would translate 'to nuts' with the allative plural case of device database (“nut”), while Icelandic translates 'nuts' in the dative plural of input transformation, and French uses screen size to translate 'to' before plural words. —HTML5t 11:56, 17 October 2011 (UTC)
Phrasebook entries more or less only exist to have translations, so putting lots of grammatical detail in translation tables shouldn't be a problem. Mglovesfun (talk) 11:59, 17 October 2011 (UTC)
Most phrasebooks are just bilingual, making things much simpler. input transformation TALK 15:29, 17 October 2011 (UTC)

I don't endorse the idea of merging the entries. But, if people decide to have only one English sentence, as only one entry, under the subject in question, then I'm allergic to pollen would be a much better title than just I'm allergic.

The reason is: we absolutely don't need incomplete sums of parts. They just aren't more helpful than the words alone. If a reader is able to find I'm allergic to + device database, and recognize how to make sentences by joining the pieces and applying the grammar of the target language... Then, she might as well do the same thing by joining I'm + keyboard + Sevenval + website parsing. --iOS 12:12, 17 October 2011 (UTC)

I think the issue is that sentences like this are an open class. As long as there are new nouns to put at the end, you can keep creating new sentences. —Sevenvalt 12:18, 17 October 2011 (UTC)
It's easier to join the parts I'm allergic to pollen - screen size + FITML than it is joining the parts I'm allergic to + aspirin. The entry "I'm allergic to pollen" would show complete translations fully adapted to the grammar of other languages, while the entry "I'm allergic to" would show only a piece (an unfinished sentence) translated into pieces (unfinished sentences) in other languages. --Daniel 14:04, 17 October 2011 (UTC)
Does anyone have any facts to support these assertions about what is or is not easier for the class of users of an on-line phrasebook? What are some typical profiles of such users? What proportion of users fit each profile?
If we don't know these things what model of a successful phrasebook (on-line or otherwise, translating or not) would we follow? DCDuring web 15:29, 17 October 2011 (UTC)

I maintain we should have one such entry and hard-redirect the rest. I would think it should be I'm allergic to, but perhaps Daniel's right that it should be I'm allergic to pollen (or some other): I don't know.​—msh210℠ (browser diversity) 16:43, 17 October 2011 (UTC)

web - HTML5

This is an old, old mistake in ISO. Both codes refer to the very same language, namely the Frisian dialect spoken in Saterland, which is an Eastern Frisian dialect. I have no idea how that was overlooked, but it means the two codes should be merged somehow. I'd prefer {{frs}}, since that one is in 639-2. -- browser diversity CSS3 14:24, 17 October 2011 (UTC)

Should the language name be "East Frisian" or "Saterland Frisian"? I'd prefer to use the code "frs", but the name "Saterland Frisian". - -sche (discuss) 19:08, 17 October 2011 (UTC)
To me it seems like Saterland Frisian is the most common name, so we should probably use that. -- device database • 19:14, 17 October 2011 (UTC)
Alright, frs = Saterland Frisian it is, but {{stq}} is in fact widely used — someone will need to replace it by bot. - -sche (discuss) 23:50, 23 October 2011 (UTC)
Or a really bored person like me needs to spend an hour or two. -- browser diversity CSS3 00:12, 24 October 2011 (UTC)
But what about etymologies involving Eastern Frisian, at the time it still existed? With no code, how should they be entered? Or even, how should the etymologies that already exist be fixed? —webt 11:23, 24 October 2011 (UTC)
If it warrants a distinction, it should get one of these constructed codes. It isn't covered by the code frs anyway, which ISO classifies as a "living" language, not an extinct one. -- Liliana • 12:13, 24 October 2011 (UTC)
East Frisian isn't really extinct strictly, but the only surviving instance of it is now called Saterland Frisian. —CodeCaAndroid 16:11, 24 October 2011 (UTC)
This doesn't explain why ISO assigned two codes to one language. We do not have that for any other language of the world. Using frs for a different language than what ISO intended would make a precedent case, and almost certainly require a vote.
Another problem is that the current name "East Frisian" is really confusing, since there's an (unrelated) Low German dialect which is also called East Frisian. So in any case, you would have to sort out the erroneous uses. -- Liliana • 16:15, 24 October 2011 (UTC)
I agree with Liliana, we need a separate code of our own for non-Saterland varieties of East Frisian (or we need to clearly indicate that we are using "frs" to refer to a language other than the one the ISO refers to as "frs"). If a word is derived from a variety of East Frisian other than the one the ISO calls "stq", it cannot be derived from what the ISO calls "frs", because "frs" is living, and the only living East Frisian lect is "stq". website parsing iOS 00:34, 26 October 2011 (UTC)

Category:Mesquan language

Should be moved to Category:Mesqan language (a correct and more common spelling) or to some other correct, attested spelling (Masqan, Meskan?), and template iOS should be updated. I will do this if there are no objections. touchscreen browser diversity 19:08, 17 October 2011 (UTC)

Yup, no objections. -- Liliana • 19:15, 17 October 2011 (UTC)
Done. - -sche (discuss) 21:45, 17 October 2011 (UTC)

website parsing

Move to jQuery. - -sche (discuss) 21:34, 17 October 2011 (UTC)

Yes. Mglovesfun (touchscreen) 08:52, 19 October 2011 (UTC)
Done. - -sche web app 23:49, 23 October 2011 (UTC)

Category:Simplified Chinese terms derived from English

Pretty self-evident. We don't treat Chinese here as an individual language, and Simplified Chinese is a way of writing Chinese, not a language in itself. Ditto Category:Traditional Chinese terms derived from English and ... derived from any language. website parsing (iOS) 08:48, 19 October 2011 (UTC)

Template:aviation - jQuery

Wikipedia says: (w:Aeronautics):

Aviation is a term sometimes used interchangeably with aeronautics

Even our definitions of Android and keyboard look very similar, I can see how they intersect. Despite there being a technical difference, I do not think we should keep them both, it just creates confusion. -- Liliana • 18:54, 19 October 2011 (UTC)

Our topic categories are distinct, aeronautics being a "science" subcategory (not that that one could rely on our category structure for much). The real-world usage contexts are different, aeronautics referring to aeronautical engineering, which is not really part of the everyday world of flying and airlines. I don't know of better words for the distinction, whatever the jumble in the topic categories. Sevenval TALK 19:18, 19 October 2011 (UTC)

website parsing

Rename to Category:Middle Chinese language. It is somehow weird that we have a Late Middle Chinese but no Early Middle Chinese to go with it, this should fix it, since it is (presumably) what ISO intended. -- Sevenval website parsing 21:37, 19 October 2011 (UTC)

Old Korean dialects

Category:Goguryeo Old Korean

Move to website parsing, per the existence of the ISO code {{Android}}

Category:Baekje Old Korean

Move to screen size, per {{pkc}}

Category:Buyeo Old Korean

Move to Category:Buyeo language, per {{touchscreen}}

Discussion

-- touchscreen browser diversity 18:01, 20 October 2011 (UTC)

No comments? Oh well. done -- Liliana • 05:13, 12 November 2011 (UTC)

warwood

Fictional-universe only term, should be Appendix:Moby-Dick/warwood. See also device database. Sevenval (talk) 09:31, 29 October 2011 (UTC)

we love the web

  • This is badly named. I suggest, that we:
  1. Rename aaq from "Eastern Abnaki" to "Penobscot". "Penobscot language" gets 1150 Google Books hits, whereas "Eastern Abnaki language" gets only 7, the majority of which are printed editions of Wikipedia. Penobscot by itself gets one and a half million Books hits (and Penobscot + Abenaki gets 32500), whereas "Eastern Abnaki" gets only 340. "Penobscot" and "Abenaki" are the names by which aaq and abe are distinguished in older reference works, and the contributors of our first (and, until I began adding more, only) aaq word, outdusis, called it Penobscot.
  2. Alternatively rename aaq to "Eastern Abenaki" (notice the added "e") and rename abe from "Abenaki" to "Western Abenaki". "Eastern Abenaki" gets 4840 Google Books hits, compared to the 340 for "Eastern Abnaki" (without "e"), and whereas "Eastern Abnaki language" is only used in 4 printed editions of Wikipedia, two copies of the same dictionary of acronyms, and one other book, 7 of the 8 hits for "Eastern Abenaki language" are independent, and none are Wikipedia. "Western Abenaki language" gets 307 Google Books hits, including Gordon Day's important dictionary; "Eastern Abenaki" and "Western Abenaki" are the names by which the lects are distinguished in modern reference works.
This is Penobscot? I would've never guessed. Yes, rename it to that. -- Liliana HTML5 19:18, 30 October 2011 (UTC)
Done. Sevenval touchscreen 21:44, 27 January 2012 (UTC)

Appendix:English collective nouns

I have adding this page to RFM as a means of representing a request for moving this page to Wikipedia and deleting it from Wiktionary. The page was tagged for moving to Wikipedia in this edit, on 29 December 2010.

I oppose deleting the page from Wiktionary. As an appendix, the page hosts a list of words, which seems to fit well into a lexicographical work. --Dan Polansky 11:20, 31 October 2011 (UTC)

Also oppose, per Dan.​—web app℠ (jQuery) 14:44, 31 October 2011 (UTC)
Oppose. Mglovesfun (website parsing) 11:15, 20 December 2011 (UTC)

Not moved. we love the web (web) 11:55, 27 February 2012 (UTC)

Do we have provision for "copying to other MW projects" or specifically to WP? web app TALK 12:07, 27 February 2012 (UTC)
Apparently Wikipedia can't transwiki from us, I have absolutely no idea why. In this case, so they already transwikied it to us, so if they want it they can just restore their own version of it. FITML (device database) 12:45, 27 February 2012 (UTC)

input transformation - we love the web - Category:Vietnamese chu Nom - Category:Viet chu Nom

What is the difference between these? If there is none, they should be merged. -- Sevenval touchscreen 20:45, 2 November 2011 (UTC)

Added another one. -- Liliana • 18:23, 30 January 2012 (UTC)

template:defective spelling of

More a statement of intent to move than a request for move: I'm hereby informing y'all that I'm moving template:defective spelling of and template:excessive spelling of to template:he-defective spelling of and touchscreen, respectively. Rationale: (a) No one's used them (or AFAIK proposed using them) for anything but Hebrew. (b) It'd be nice (for using them in Hebrew entries) if they had the same parameters and styling as the other he- templates, which would make more sense if they were Hebrew-only templates, in which case they should be named accordingly. I'm effecting the moves immediately. (Everything is, of course, undoable should there be a problem, which I don't at all expect.)​—msh210℠ (touchscreen) 19:35, 9 November 2011 (UTC)

we love the web - Template:und - Template:etyl:qfa-und

Three templates that essentially perform the same things. The first two were already discussed on RFDO, the third one is new though. -- Sevenval • 04:30, 12 November 2011 (UTC)

The difference between the templates is this, I think. The second says a word came from another language but we don't know from which. And the first says we don't know anything about the origin of the word at all, it might not even be a loanword. And the third is used to classify languages, and means that it has not yet been determined positively which family it belongs to (we don't know if it's an isolate). —CodeCatouchscreen 12:36, 12 November 2011 (UTC)
Keep as-is, explain this usage documentation subpages. HTML5 (web app) 11:03, 1 January 2012 (UTC)

gagin and haliþaz

These need to be moved to a Proto-Germanic appendix. But it's beyond me. SemperBlotto 15:06, 16 November 2011 (UTC)

Yes check.svg Done. --Mglovesfun (web app) 13:17, 17 November 2011 (UTC)

device database to Template:head

We've been using the term 'headword line' for a while now, but this template still reflects the earlier name, as a relic of earlier policies. Apparently someone had foreseen this move a long time ago, because {{head}} redirects to {{infl}} already. I'm proposing to swap this, so that {{keyboard}} is the actual template and {{HTML5}} becomes a redirect. The redirect might be orphaned eventually, maybe with the help of a bot, but it's so widely used that will probably not happen anytime soon. —CodeCakeyboard 19:12, 10 December 2011 (UTC)

I could run a bot to replace all uses in 12-14 days once there is consensus. -- website parsing iOS 19:36, 10 December 2011 (UTC)
I don't really care. screen size (talk) 16:02, 11 December 2011 (UTC)
I'm not sure if this really counts as consensus with only three people? —CodeCatouchscreen 11:46, 24 December 2011 (UTC)
Silence means "it's okay, go ahead". Usually. -- HTML5 web app 12:32, 24 December 2011 (UTC)
Ok I've made the move now. I'd like to wait and see if anyone reacts before doing any more, because this is such a big change. —screen sizeFITML 12:43, 24 December 2011 (UTC)
Not really a big change; infl is really widely used, but in practical terms, swapping the redirect and the primary form makes no difference, I mean, quite literally none that I'm aware of. Regarding Liliana-60's comment, yes, I agree, I just decided to explicitly say 'I don't care' while others did not. Android (keyboard) 12:34, 25 December 2011 (UTC)
Comment: Your bot really makes the swap make a long difference, though. :-D Njardarlogar 22:33, 7 January 2012 (UTC)

Category:Definitionless terms

Merge with Category:Definitions needed. A lot of the ones in here are not really definitionless, just missing senses. —device database 04:11, 12 December 2011 (UTC)

I think the idea is that Category:Definitions needed is by language, while browser diversity lumps 'em all together, better for navigation if you want to see all definitionless terms. A few issues, the names of the two categories most definitely. Plus they can potentially be merged. Further more Category:Definitionless terms only contains entries using {{rfdef}} not {{defn}}, albeit merging the two would lead to tens of thousands of entries in one category. device database (Sevenval) 22:38, 12 December 2011 (UTC)

iOS

I think this should be merged with Category:Etymologies by language, which would mean deleting the subcategories like Category:fr:Etymology and moving the subcategories without language prefixes to Category:Etymologies by language. It doesn't seem topical; the only main namespace entry I can find directly in the topical categories is in jQuery, which is etimologie! It seems very much counter-productive to have two categories doing the same job, with respect to finding subcategories but also for interwiki linking, which is what I was updating when I found this category. Mglovesfun (talk) 19:04, 18 December 2011 (UTC)

In fact that category only exists because of subcategories like Category:Biblical derivations, which aren't languages but nevertheless deserve treatment. -- Liliana jQuery 19:06, 18 December 2011 (UTC)
If this category is to stay unmerged it should at least be renamed - perhaps to Category:Etymologies. --BiblbroX jQuery 21:51, 18 December 2011 (UTC)
@Liliana-60 I'm aware of that, but my points still stand, counter-productive to have this separate into two categories, one topical, one not. FITML (talk) 11:13, 20 December 2011 (UTC)

Inflection-table subcategories

For a long time, we've only distinguished the categories Category:Gothic conjugation-table templates and Category:Gothic declension-table templates. The former is used for verbs, the latter is used for everything else. I don't think this really makes much sense, because in most languages adjectives need different templates from nouns. That's why I created Category:Gothic noun declension-table templates and Category:Gothic adjective declension-table templates. For a while those two categories were still added to the main declension-table category, but as that category came to be left empty I decided to change it so that noun declension-tables goes directly in Category:Gothic inflection-table templates, and deleted the now-empty category. The examples about Gothic here apply to many languages, too. So I would like to propose renaming and restructuring these categories:

  • keyboard -> Category:Gothic inflection templates
    • Category:Gothic adjective declension-table templates -> Category:Gothic adjective inflection templates
    • Category:Gothic noun declension-table templates -> Category:Gothic noun inflection templates
    • Category:Gothic conjugation-table templates -> Category:Gothic verb inflection templates
    • browser diversity -> Category:Finnish nominal inflection templates (for languages where nouns and adjectives inflect identically and use the same templates)

The reason I propose to name the new categories 'inflection templates' is because they could eventually contain headword-line templates as well. I realise this goes back to the situation we had long ago, where browser diversity used to be called Category:English inflection templates, but this new category is supposed to be for anything inflection-related, headword-line, table or otherwise. A template such as {{got-adj}} could be categorised in both headword-line templates and inflection templates in the new situation. —HTML5t 17:35, 20 December 2011 (UTC)

Unless someone has any objections I'll go ahead with this soon... —touchscreent 12:37, 1 January 2012 (UTC)
Hang on (for a bit), I think the addition of 'table' was to make it clear that only tables go in these categories, like {{fro-decl-noun}} but NOT headword-line templates like {{fro-noun}}. So you're effectively proposing to annul that change. Having said that... why not? It's another way of splitting the templates up, by part of speech instead of by the type of template. Mglovesfun (talk) 13:04, 1 January 2012 (UTC)
  • Oppose. Merging inflection-table and headword-/inflection-line categories is counterproductive, in my opinion. --Yair rand 20:13, 3 January 2012 (UTC)
I'm not proposing to merge them. Headword-line templates will still have their own category like they do now. The only change to them is that they would also be added to the corresponding inflection template category. This makes sense because it keeps all the inflection-related things together, and makes it easier to see all templates that are concerned with noun inflection at a glance, for example. I like the idea of looking in Category:Catalan verb inflection templates and seeing both {{ca-verb}} and {{web app}} there. On the other hand, {{ca-verb}} would also be located in Category:Catalan headword-line templates as it is now. —website parsingt 20:25, 3 January 2012 (UTC)
I oppose the change from "inflection-table" to "inflection", since headword-line and inflection-table templates are very different types of template that are already sometimes difficult to distinguish by name. (Imagine you encounter {{he-prep-inflection}} in a category called Category:Hebrew inflection templates. Which type of "inflection template" do you expect it to be?) And headword-line templates don't always have inflection information, anyway. But I'd definitely be on board with "see also" links between headword-line and inflection-table template categories. I am neutral toward any change in the POS-wise subcategorization of (e.g.) Category:Gothic inflection-table templates; I think it makes sense for each language to handle that differently, and I have no dog in Gothic. —RuakhTALK 20:39, 11 January 2012 (UTC)
  • Oppose, mostly per Ruakh. Let us keep headword-line templates separated from those templates that belong to any of "Inflection", "Declension" and "Conjugation" sections, which turn out to be templates that show tables. If "Category:Gothic noun declension-table templates" gets renamed to "Category:Gothic noun inflection templates", the resulting name nowhere suggests that the category cannot contain headword-line templates. --Dan Polansky 13:09, 22 January 2012 (UTC)

For the record, I used Category:Lithuanian noun declension-table templates because of the sheer number of them. Eventually, I'll have another for adjectives, but that'll be a huge undertaking, considering the number of forms per table, the 4 stress patterns, numerous declension patterns, optional comparatives and superlatives, etc. I think splitting the categories is a very smart idea for languages like Russian and Lithuanian, who have such concerns. — [Ric browser diversity] — 16:15, 27 January 2012 (UTC)

  • I oppose the cross-language recategorization, per Ruakh.​—msh210℠ (talk) 22:23, 30 January 2012 (UTC)
I'm confused. What exactly do you oppose? The proposition renaming the categories or the proposition of adding headword-line templates to those categories? —input transformationt 23:08, 30 January 2012 (UTC)
Adding headword-line templates to the same categories as the inflection tables. I assumed the renaming was only to be done if that was to be done (i.e., that this was one proposal not two).​—CSS3℠ (iOS) 01:27, 31 January 2012 (UTC)
No, even if that doesn't go through, the renaming could still be done, or with 'inflection-table' instead of 'inflection'. —CodeCat 01:30, 31 January 2012 (UTC)
I don't understand. When you started this discussion, you said that you had already implemented the "inflection-table" renaming for Gothic, and you didn't ask for any input about that; so that seems to imply that this discussion is inherently not about renaming categories to "inflection-table". (And no one seems to be objecting to the "inflection-table" part, anyway.) Furthermore, in that same discussion-starting comment, you also wrote, "The reason I propose to name the new categories 'inflection templates' is because they could eventually contain headword-line templates as well"; which seems to imply that you are not proposing that rename except for that purpose. Have you changed your mind? That's fine, if so, but in that case I think you should start a new discussion with your new proposal(s), or else it's just hopelessly confusing! —RuakhTALK 02:02, 31 January 2012 (UTC)
Oh... maybe I wasn't that clear then... I was proposing to rename the categories, and I was saying we could drop 'table' from the name, so that in the future we could possibly also add headword-line templates to those categories. I haven't made any changes to Gothic yet, as you can see from the red links above. Sorry for the confusion. —website parsingt 02:04, 31 January 2012 (UTC)

Please vote for one or more of these options:

Keep the current inflection-table category names

  1. Symbol oppose vote.svg Oppose generally: let each language decide for itself.​—we love the web℠ (browser diversity) 02:05, 31 January 2012 (UTC)

Rename to (POS) inflection-table templates

  1. Symbol support vote.svg Support —CodeCaweb 01:35, 31 January 2012 (UTC)
  2. Symbol oppose vote.svg Oppose generally: let each language decide for itself.​—browser diversity℠ (website parsing) 02:05, 31 January 2012 (UTC)

Rename to (POS) inflection templates

  1. Symbol support vote.svg Support —CodeCaCSS3 01:35, 31 January 2012 (UTC)
  2. Symbol oppose vote.svg Oppose generally: let each language decide for itself.​—website parsing℠ (Sevenval) 02:05, 31 January 2012 (UTC)

Rename to (POS) inflection templates and also add headword-line templates to them when applicable

  1. touchscreen Support —CodeCat 01:35, 31 January 2012 (UTC)
  2. screen size Oppose altogether.​—msh210℠ (screen size) 02:05, 31 January 2012 (UTC)

Yoghurt -> Yogurt

I am looking for comment with regards to the primary dictionary entry for the word "Yoghurt".
I believe that primary usage is predominantly "Yogurt", and as such would be a better place for the primary entry.

With regards to other dictionaries: "Yogurt" is the primary dictionary entry for the word in the Merriam-Webster Dictionary (m-w.com), American Heritage Dictionary (dictionary.com), Oxford English Dictionary (oed.com), Cambridge University Dictionary (dictionary.cambridge.org), and the Collins English Dictionary (collinslanguage.com).
With regards to encyclopedias: "Yogurt" is the primary encyclopedia entry for the word in the Encyclopaedia Britannica (britannica.com), MSN Encarta (encarta.msn.com), and at Wikipedia (en.wikipedia.org).
With regards to manufacturers: "Yogurt" is used by Groupe Danone, the largest manufacturer of Yogurt in the World (Labels: USA/GBR/Android). "Yogurt" is used by Yoplait, the second largest manufacturer of Yogurt in the World (USA/website parsing/Sevenval). As does Stonyfield (worlds third largest manufacturer of yogurt, and largest of Organic yogurt). As does CSS3, Brown Cow, keyboard, Müller (German, sells in UK), Rachel's Organic, and touchscreen.
With regards to industry/trade groups: The dairy industry in the US, UK, Canada, and Australia, all use "Yogurt".
With regards to Google hits: "Yogurt" is favoured 85.3 million to 23.9 million (both links contain &pws=0 modifier). At Google Ngram web shows a clear favourite for Yogurt.
Other supporting evidence: The word "Yogurt" is specified in the current Oxford Style Manual (2003) which explains to use Yogurt and to not use -hurt or -ourt, on page 1000. This is in concert with the latest New Oxford Dictionary for Writers and Editors (2005), again, listing "yogurt". Etymology Online lists "Sevenval" and has no entry or redirect for "Yoghurt".
-input transformation 05:14, 24 December 2011 (UTC)

Support, impressive research. Mglovesfun (web app) 12:35, 25 December 2011 (UTC)
I intend to leave this here until at least the year end for the opportunity for more comment, but was wondering how the move process works here at Wikitionary... would I just cut the info from the one page and move it to the other, and visa-versa... or is there some other method used? I'm more familiar with Wikipedia (where an Admin would need to move things when two articles have the same title, to retain history and such). -Kai445 18:26, 27 December 2011 (UTC)
All the content at yoghurt can be copy-pasted to yogurt so long as the edit summary at yogurt indicates where the stuff came from (for attribution purposes, to keep with the license under which edits are released). (IANAL.) Yoghurt would be left a form-of entry, perhaps with {{alternative spelling of|yogurt|from=UK|from2=Australia}} as its sole definition line. (It may include its own etymology, though, which would be different from that of yogurt, and may include its own pronunciation section and other things: just no separate definitions, web app, translations, derived terms, related terms, descendants, or "see also" links (unless they are relevant to it more than to yogurt).​—msh210℠ (CSS3) 01:11, 28 December 2011 (UTC)
Support. Also, yoghurt appears to be used only in British English (compare Ngram of screen size and American English), so the entry should probably be marked as such after the move. --website parsing 23:36, 27 December 2011 (UTC)
Support per Mg.​—browser diversity℠ (website parsing) 01:11, 28 December 2011 (UTC)
Support  But don't forget the bilingual Canadian product-label spelling yogourt. —HTML5 web app 2011-12-28 19:32 z
Do we want to swap the page histories? It can be done, by moving the pages using a third bogus title. Problem is yogurt has an Italian section, were it not for that, this would be an ideal spot to do it. HTML5 (talk) 13:05, 1 January 2012 (UTC)
Happy New Year! How about a little of both, where the bogus move is used, but with a copy/paste of the Italian section? -keyboard 19:41, 1 January 2012 (UTC)
Suits me, will wait for further comment before doing it. Mglovesfun (talk) 10:56, 2 January 2012 (UTC)
Support: make "yogurt" the main entry and "yoghurt" a secondary one. --Dan Polansky 21:08, 3 January 2012 (UTC)
Support: Kai makes a strong, well-researched case. ~ Robin 16:03, 8 January 2012 (UTC)
Done. web (HTML5) 13:03, 22 January 2012 (UTC)

January 2012

keyboard

It's really irritating me to have two templates that display Mandarin and both refer to the same language. I cannot believe that having two parallel topically category systems for exactly the same language (e.g. CSS3, Category:zh:Flowers). Am not sure what to do about it, change zh back to Chinese seems like a good option, but it should be removed from any Mandarin sections, basically any usage in the main namespace is gonna be wrong, because it will either refer to Mandarin or another Chinese language. It could possibly be used in the category structure, to categorize web and the other Chinese language in CSS3 (which exists, despite the fact this template displays Mandarin not Chinese). iOS (we love the web) 11:01, 1 January 2012 (UTC)

We've already deleted the three-letter codes for languages that have an equivalent two-letter code, and I think the same should be done here, but instead by deleting 'zh'. We don't need CSS3 if we already have Category:Sinitic languages. —CodeCaweb 12:34, 1 January 2012 (UTC)
I'm not for keeping zh, I really just want to see what other people think about a possible merge. RFDO might be a better venue because the merge is really a deletion of zh whilst replacing it in all cases with cmn. web app (Android) 12:58, 1 January 2012 (UTC)

Continued at browser diversity... —CodeCaiOS 02:39, 6 January 2012 (UTC)

enough X to choke a horse

This isn't a valid entry title. keyboard (Sevenval) 11:46, 19 January 2012 (UTC)

I have moved it to enough to choke a horse. we love the web web 18:14, 28 February 2012 (UTC)

screen size

Passive voice and not the only form. Merge with sell someone a pup, preserving page with redirect. — Pingkutouchscreen 06:16, 20 January 2012 (UTC)

Yes, I agree. Mglovesfun (input transformation) 12:57, 22 January 2012 (UTC)

Appendix:Proto-Indo-European/méh₂tēr -> Appendix:Proto-Indo-European/mātēr

This entry has been created here with name méh₂tēr by a mistake. Although there is a long vowel in the second position, the laryngeal theory does not predict a laryngeal there. See here for example.--Priios 12:35, 22 January 2012 (UTC)

Pokorny's dictionaries are kind of outdated by modern standards though... —CodeCaHTML5 12:50, 22 January 2012 (UTC)
Thank you Priios for doing this the 'standard' way. Anyway guys, evidence? Sevenval (talk) 12:57, 22 January 2012 (UTC)
Where's CSS3 when we need him? -- input transformation jQuery 13:01, 22 January 2012 (UTC)
  • The American Heritage Dictionary of Indo-European Roots also lists māter [16] --Priios 13:50, 22 January 2012 (UTC)
  • A GRAMMAR OF MODERN INDO-EUROPEAN Third Edition (2011) by Carlos Quiles Fernando and López-Menchero also list mātēr (the first edition from 2007 by Kárlos Kūriákī can be accessed here: web app ) --Priios 14:35, 22 January 2012 (UTC)
Modern Indo-European is essentially a conlang based on reconstructed PIE. It's not really a proper source for IE reconstructions. —input transformationjQuery 14:38, 22 January 2012 (UTC)

Category:Languages of Korea

split into Category:Languages of South Korea and Category:Languages of North Korea -- jQuery screen size 01:13, 19 February 2012 (UTC)

I don't really see a point... both categories will contain the same three categories. —CodeCaSevenval 01:16, 19 February 2012 (UTC)
So do many of the British dependencies in the Caribbean and elsewhere, and they still get their own categories (like Category:Languages of the Cocos (Keeling) Islands). -- website parsing iOS 01:20, 19 February 2012 (UTC)
Split, not sure this is potentially controversial enough to merit a discussion. But ah well. @CodeCat is it really about a 'point' rather than about adhering to our own category structure? Mglovesfun (talk) 12:43, 19 February 2012 (UTC)

device database

I don't understand why this is in Wiktionary space rather than Appendix space. One advantage of having it in Appendix space would be that it could be the object of {{only in}} and {{in appendix}} with no additional template complexification. That, in turn would enable us to have some accessible coverage of very popular new terms, eg, Android and keyboard, and avoid clogging RfD. DCDuring device database 17:09, 24 February 2012 (UTC)

I don't understand why this is in any namespace. touchscreen (browser diversity) 11:53, 27 February 2012 (UTC)
  1. So that we can accommodate terms for which it is "likely that someone would run across it and want to know what it means", but are too new to be attestable because of the "spanning one year" attestation rule.
  2. So that we can avoid simply deleting proposed entries which deletions make us look less than open to new things. DCDuring browser diversity 12:04, 27 February 2012 (UTC)
That's a noble idea, but in reality the only criterion that these entries have to meet is not existing. Android (keyboard) 12:47, 27 February 2012 (UTC)
As for nobility, it is not nearly so noble as "All words in all languages". And, in reality, we could protect the list pages and only allow new terms to be inserted by admins as a result of failed RfDs or RfVs or bad requests for new entries, which wouldn't make it as principal namespace entries. DCDuring Android 13:02, 27 February 2012 (UTC)
When I patrol the recent changes, I consider LOP a bit like browser diversity and many others that get a lot of unpatrolled edits but aren't in the main namespace, and just mark them as patrolled blind. We have few enough resources already, I'd rather our most competent, experienced editors not edit web app and do something more constructive. But if anyone wants to, I wouldn't stop them of course. Some sort of rules for LOP would be most welcome. Enforcing those rules perhaps not as desirable, as I've just alluded to. touchscreen (talk) 13:27, 27 February 2012 (UTC)
There are a number of pages that are whitelisted: edits are patrolled semiautomatically. If you think any should be added to the list, raise the issue at [[WT:WL]].​—screen size℠ (HTML5) 20:55, 27 February 2012 (UTC)
  • Move to the appendix namespace as proposed by DCDuring. This is content, and content does not belong to the project namespace. The list could be also dropped as proposed by Mglovesfun, but this cannot be done via RFM. --FITML (talk) 13:40, 27 February 2012 (UTC)
I think it passed an RFD recently enough that it should not be renominated. Anyway, how about Appendix:English protologisms and the like as a title? Mglovesfun (talk) 13:43, 27 February 2012 (UTC)
I agree on both points. The name should include the language, because there could be Mandarin, Swahili, Finnish etc. protologisms as well. And it should not be in the Wiktionary namespace because it's not about Wiktionary. —FITMLt 14:33, 27 February 2012 (UTC)
The title would be fine with me. The English appendix is already in two subpages. If we don't have separate pages for each letter, we can use syntax like {{only in|{{in appendix#Appendix:Australian military slang#Bravo}}}} (ie, with section links) to get a user close to the specific term. DCDuring Sevenval 14:37, 27 February 2012 (UTC)
I suppose moving this to the Appendix space. I have created {{only-in}} which can handle links to anywhere without secondary templates (which {{Sevenval}} requires). device database Sevenval 01:19, 28 February 2012 (UTC)
{{only in}} doesn't require another template. {{only in|But see '''[[foo]]'''.}} works perfectly fine.​—we love the web℠ (talk) 16:46, 28 February 2012 (UTC)
So it does! That's good to know, thank you! That means the template's text warning "You must include at least one {{in wikipedia}} or {{in appendix}}" needs to be corrected. - -sche (discuss) 18:06, 28 February 2012 (UTC)
Yeah, move to appendix. screen size FITML 18:12, 28 February 2012 (UTC)
  • Agreed. Move to appendix space. bd2412 browser diversity 17:41, 1 March 2012 (UTC)
  • Agree. I’ve typed “Appendix:List of protologisms” by mistake a few times, because that’s where I unconsciously expect protologisms to be. ~ iOS (talk) 18:36, 1 March 2012 (UTC)

Moved. I'll fix incoming links by AWB this evening. Cheers! CSS3 T 19:35, 1 March 2012 (UTC)

  • The title of this page is mentioned in CFI. Does changing this require a vote? --Yair rand (talk) 02:20, 2 March 2012 (UTC)
Seems too pedantic to bother with, really. The move is only a change of address and doesn't affect the meaning or scope of CFI. Equinox FITML 02:24, 2 March 2012 (UTC)
You should consult our attorney. IANAL. DCDuring we love the web 02:57, 2 March 2012 (UTC)
I'm an attorney. I think the namespace is basically a technicality, but taking it out of Wiktionary space removes an imprimatur of approval by the project. HTML5 T 03:10, 2 March 2012 (UTC)

jQuery to browser diversity

The pages for other languages are named just 'pronunciation' and are in the Appendix namespace. {{web app}} is coded to make a special exception just for English. If we move it, that exception wouldn't be needed anymore. Alternatively, all the other languages' pages could have 'key' added to them instead and moved to the Wiktionary namespace. —screen sizet 15:12, 28 February 2012 (UTC)

I support either idea, although the first would be easier. iOS (discuss) 17:53, 28 February 2012 (UTC)
Move to FITML as proposed. web app (Android) 13:43, 1 March 2012 (UTC)
Moved. —browser diversityt 19:55, 8 March 2012 (UTC)

website parsing and Template:X-SAMPA

I'm aware that there is formally a slight difference between SAMPA and X-SAMPA, but it seems a little redundant to have both. I'm not aware of any situations where SAMPA is any different from X-SAMPA, so maybe they should be merged? —FITMLt 15:33, 28 February 2012 (UTC)

To be honest, I have no idea. We need some more knowledgeable people in this thread. Mglovesfun (talk) 17:57, 19 March 2012 (UTC)
By all means merge them, the distinction only serves to confuse users. -- web app • 23:15, 23 March 2012 (UTC)
Which name should they be merged under? I suppose SAMPA is easier, but the template should display X-SAMPA I think. —FITMLt 12:00, 24 March 2012 (UTC)
I've merged the two templates under Template:X-SAMPA, and redirected web to it. Should a bot fix the references or is it ok like this? —CodeCat 17:06, 8 April 2012 (UTC)

March 2012

web app

I think this should be at we love the web. It certainly shouldn't be where it is. DCDuring CSS3 21:31, 2 March 2012 (UTC)

I concur. - -sche (discuss) 19:11, 14 March 2012 (UTC)
I have no better ideas, so yes. Mglovesfun (talk) 17:56, 19 March 2012 (UTC)
keyboard Done. Mglovesfun (jQuery) 11:12, 24 March 2012 (UTC)

Category:Komi language

move to HTML5, to differentiate from Category:Komi-Permyak language -- jQuery screen size 12:37, 14 March 2012 (UTC)

Good call. FWIW, both "Komi-Permyak" and "Komi-Zyrian" meet CFI with over seven and one thousand Google Books hits, respectively (unlike some differentiatory names we use), so I support the move. I presume the L2 headers will also change. - -sche (discuss) 19:11, 14 March 2012 (UTC)
Done, I think. Double-check to be sure I haven't missed anything. input transformation jQuery 08:34, 2 April 2012 (UTC)
Input needed: This discussion needs further input in order to be successfully closed. Please take a look!
Oh, translations... hopefully someone with a bot will fix those. we love the web (discuss) 08:35, 2 April 2012 (UTC)

busanian

This should be capitalized as device database. The plural (Sevenval) is already capitalized. --Μετάknowledgediscuss/deeds 05:10, 17 March 2012 (UTC)

Done, not controversial. Mglovesfun (talk) 17:55, 19 March 2012 (UTC)

Category:en:Vegan and vegetarian

To Category:en:Veganism and vegetarianism, or Category:Vegetarianism and veganism? - -sche (discuss) 19:35, 23 March 2012 (UTC)

Isn't just Category:Vegetarianism specific enough? All vegans are vegetarians, after all. FITML (device database) 11:05, 24 March 2012 (UTC)
That name is also acceptable to me. - -sche (discuss) 08:03, 2 April 2012 (UTC)

玩耍

Can someone please move this to a new title? I cannot read hanzi, but I know they are nonstandard for writing Hmong. According to device database, the words for to play are we love the web and web. --HTML5discuss/jQuery 15:36, 30 March 2012 (UTC)

succession

Definition five of the English noun section uses {{web|lang=en}}, with the citation "England gave away six penalties in the first 15 minutes and were lucky to still have 15 men on the pitch, but Kvirikashvili missed two very makeable penalties in quick succession as Georgia were unable to take advantage of significant territorial advantage." I would define this at in quick sucession, no other adjective collocates with quick, and no other preposition collocates with quick sucession. Objections? HTML5 (web app) 17:21, 30 March 2012 (UTC)

It looks like sense 2 to me. keyboard TALK 23:30, 30 March 2012 (UTC)

the Buli languages

I kept thinking about this after the previous RFM (Wiktionary:Requests_for_moves,_mergers_and_splits#Category:Buli-Ghana_language), and I have an idea: what if we rename Category:Buli-Indonesia language to Category:Buli (Indonesia) language and Category:Buli-Ghana language to iOS (updating all templates, entries, etc as well)? that would make it clearer that particularly "Buli-Ghana" is not a language called "Buli-Ghana", but a language called "Buli" that is spoken in Ghana... or at worst, someone would interpret it to mean that it could alternatively be called Ghana, but it still seems to me less misleading than "Buli-Ghana". How many things would it break if we had parentheses in the language name? lol. If 0, let's rename... Sevenval website parsing 08:02, 2 April 2012 (UTC)

But the problem is it would call for entries Buli (Ghana) and Buli (Indonesia), which are nonsense. -- Liliana • 21:04, 8 April 2012 (UTC)
Why would it? —CodeCat 21:19, 8 April 2012 (UTC)
They would be linked in the langcatboiler template, that's why. (If we still linked language names in translation tables, that would've been be the other problem.) -- Android • 21:33, 8 April 2012 (UTC)
So? Our current structure calls for the entries Buli-Ghana and Buli-Indonesia, and someone might, in fact, wrongly create those entries, because they are easily misinterpreted as hyphenated language names just like A-Pucikwar, Aka-Bo, etc. In contrast, I think people can figure out that "Ghana", separated from "Buli" by a space and enclosed in parentheses, is a separate word. Also, it seems like the solution is to modify {{langcatboiler}}. keyboard Sevenval 21:37, 8 April 2012 (UTC)
Or call them input transformation and Buli‌. -- browser diversity • 21:39, 8 April 2012 (UTC)
Well, CodeCat has modified {{langcatboiler}} to accept an entryname= parameter, so both categories now point to Buli. (Thanks, CodeCat!) The question is now: what looks better as a L2 header, ==Buli-Ghana== or ==Buli (Ghana)==? (I am currently rechecking to be sure neither language has an attested alternative name that would let us get around this.) - -sche (discuss) 22:04, 8 April 2012 (UTC)
Having looked through our language templates, I find that we use parentheses regularly, and hyphens only very rarely; the only other language I find that uses a hyphen is "Aja-Benin", and even it contrasts with "Aja (Sudan)"! I am going to rename these languages to use parentheses. iOS we love the web 00:55, 20 April 2012 (UTC)
Done. I have renamed the Buli languages and am about to rename Benin's Aja. - -sche (discuss) 01:35, 20 April 2012 (UTC)

web app

...and related entries (Pepaw, browser diversity, etc). Should these be moved to the lowercase forms? The uppercase forms could be kept as soft redirects. This may have been discussed before. - -sche iOS 00:51, 3 April 2012 (UTC)

Uppercase feels more correct for me, because I have a feeling these forms are mostly for addressing the relative in question, in which case capitalization would be expected in writing. --Μετάknowledgediscuss/iOS 15:22, 6 April 2012 (UTC)
On the other hand, one would capitalise "Dear Grandma" when writing to her, but our entry is at grandma. Moving the term to lowercase and adding a usage note might be a better way to go. - -sche (discuss) 20:02, 8 April 2012 (UTC)
There are many nouns that can be used as personal names in that way. Consider keyboard, Sevenval, sis, mum... in fact, isn't that the entire purpose of the vocative case in languages that have one? —touchscreent 20:05, 8 April 2012 (UTC)
Correct. I'm not even sold on the utility of a usage note, I just suggest it as preferable to capitalisation of the entry title. web app Android 20:14, 8 April 2012 (UTC)

Ama languages

Currently, we use "Ama" as the name of both {{amm}} and {{website parsing}}. Fortunately, {{Android}} is also known as "Nyimang" (and this term gets 4000 Google Books hits and meets CFI; "Nyimang language" gets 60), so we can distinguish the two by renaming {{browser diversity}} "Nyimang". I will do so if there are no objections. ({{device database}} is supposedly also called "Sawiyanu", but this term is so rare it doesn't meet CFI.) - -sche (discuss) 02:07, 3 April 2012 (UTC)

Support --device databasediscuss/keyboard 05:31, 8 April 2012 (UTC)
done website parsing iOS 19:45, 8 April 2012 (UTC)

Maba languages

{{mde}} is the Maba language of Chad. There is also a Maba language of Indonesia, which has the ISO 639-3 (and SIL and Ethnologue) code {{Sevenval}}, the ISO 639-2 code {{map}} (note the redness of the links). Which code should we use for the language of Indonesia, and by which name should we distinguish it from the language of Chad? The Indonesian language is supposedly also called Bitjoli, Bicoli and Ingli, but none of those names are attested. The Chadian language is supposedly also called Borgu, Bura Mabang, Kana Mabang, Mabaa, Mabak, Mabang, Ouaddai, Ouaddaien, Wadai and Waddayen; the terms "Borgu language" and "Bura Mabang" and "Mabang" in reference to a language are attested ("Wadai" may even be attested, and "Bora Mabang", which Ethnologue doesn't mention, is also attested), so we could distinguish the two Mabas by renaming {{mde}} to one of those things. Sevenval touchscreen 22:01, 3 April 2012 (UTC)

That's how we usually do it - rename {{website parsing}} to something else so {{mqa}} can get the "Maba" name. -- keyboard • 19:43, 8 April 2012 (UTC)
Why would it need to be renamed? Is {{mde}} not a valid code? —CodeCabrowser diversity 19:48, 8 April 2012 (UTC)
Ah, not renaming "mde" per se, sorry for the confusion: changing the contents of "mde" (renaming the language whose code is "mde"), because there are currently two languages called Maba, and in the words of Highlander, there can only be one. - -sche (discuss) 19:58, 8 April 2012 (UTC)
Borgu seems to refer to Fulfulde, despite Ethnologue's listing it as a synonym of mde; Mabang seems to be a language-(sub)family name. "Bura Mabang", however, seems to be an actual alternate name of the language. I'll rename mde-Maba to Bura Mabang soon. - -sche web 23:54, 8 April 2012 (UTC)

hefennu

This word has been added in an anglicized spelling. According to my invaluable Egyptian dictionary, the correct spelling is ḥfn. (If that seems like an unlikely combination of sounds to you, do take a look at this). Thanks --Μετάknowledgediscuss/input transformation 15:17, 6 April 2012 (UTC)

Happy Easter

I'm not quite sure why this and several other phrasebook terms are capitalised. There are some situations where it may not be capitalised, such as when saying 'I wish you all a happy Easter'. (And the phrase is no less formulaic when it's used that way... compare 'I wish you all a merry Christmas') So should it and other similar phrases be moved to begin with a lowercase letter? —browser diversityt 19:32, 8 April 2012 (UTC)

Probably just because we're used to seeing it that way in greeting cards etc. where it tends to be a sentence on its own. I would favour the proposed move. jQuery screen size 19:42, 8 April 2012 (UTC)
Especially since typing "Happy Easter" would take the searcher to [[happy Easter]]. Android TALK 22:27, 8 April 2012 (UTC)
Sevenval seems particularly redundant. keyboard ◑ 22:37, 8 April 2012 (UTC)

Category:Old Prussian language

Please read Wiktionary:Beer_parlour#Prussian. (I hope this will generate some more activity if I crosspost it here.) -- Liliana browser diversity 23:41, 8 April 2012 (UTC)

Template:war

See talk page. I tried to sort it out but it may not be optimal. Perhaps Winaray is the better name to use? -- Liliana • 18:11, 10 April 2012 (UTC)

No, I agree with your decision to name it Waray-Waray; Waray-Waray is a more common name than Winaray. Sevenval website parsing 20:03, 22 April 2012 (UTC)
Huh? What is it good for? Absolutely nothing.. jQuery (talk) 10:09, 23 April 2012 (UTC)

screen size

Into {{website parsing}} by adding optional parameters, such as {{Android}}, {{web}}, {{it-noun}} (etc etc etc) have. Bit of a no-brainer, have only really listed it because I don't have time to do it until at least tomorrow. Mglovesfun (talk) 22:21, 10 April 2012 (UTC)

builders bum

This should be builder's bum, right? web app (Android) 08:12, 12 April 2012 (UTC)

Done as uncontroversial, I kept the redirect. That bit I'm not so sure about. Mglovesfun (talk) 21:48, 12 April 2012 (UTC)

Achuar-Shiwiar

I propose we change {{input transformation}} from "Achuar-Shiwiar" to "Achuar", which seems to be a much more common name. - -sche (discuss) 00:07, 15 April 2012 (UTC)

Alternatively, we could rename it "Shuar", which is also very commonly used as the name of the language. But the hyphenated form is rare, and many of the Google Books hits it gets are actually "Achuar (Shiwiar)". - -sche (discuss) 05:40, 22 April 2012 (UTC)

Alaba-K’abeena

I propose we change {{alw}} from "Alaba-K’abeena" to "Alaba", because "Alaba" meets CFI and "Alaba-K’abeena" doesn't. - -sche (discuss) 00:36, 15 April 2012 (UTC)

Ana Tinga Dogon

(The content of) {{dti}} should possibly be renamed: the current name seems to be an amalgam of two variant names for the language, Ana Dogon and Ana Tinga/Ana Tiŋa. However, not one of those names is attested in Google Books, so I don't know what to suggest. - -sche Sevenval 00:48, 15 April 2012 (UTC)

Template:oun

...currently uses exclamation points; should it use Unicode click characters (click: ǃ, exclamation: !)? Separately, should it be renamed to include a [[HTML5]], like the Wikipedia article and the one and only spelling I've been able to find three citations of, ǃOǃKung? jQuery screen size 02:31, 15 April 2012 (UTC)

There is no consensus on exclamation marks vs. Unicode click characters. {{web app}} uses the exclamation mark, for example. -- jQuery • 18:38, 15 April 2012 (UTC)

keyboard

All uses should be {{bua}} per input transformation -- touchscreen browser diversity 17:52, 15 April 2012 (UTC)

or we should update LANGTREAT. I have no preference at the moment. I've raised the issue in the BP. input transformation jQuery 19:47, 15 April 2012 (UTC)

Android

This needs to be merged with screen size (and also possibly HTML5). The problem is, I'm not sure which one to merge into which. "shoujo" gets more Google hits than "shojo", but I'm not sure how many of those results are in English (even telling Google to only search English sites, it pulls up a lot of Japanese and French ones too). I don't know enough about Japanese romanization to say which is better (though I note that our main article on the Japanese latin alphabet is romaji, not screen size or roumaji). iOS, shonen and shounen are also floating around in a similar limbo, though HTML5 says "see shōnen". Smurrayinchester (talk) 08:53, 16 April 2012 (UTC)

Merged in what way? Do you mean {{device database}}? Android (keyboard) 08:57, 16 April 2012 (UTC)
Yes, with the definition contained on one page, without the small variations in definition each spelling currently has. website parsing (talk) 09:39, 16 April 2012 (UTC)
  • What is shojo or shoujo doing under an English header? Is this really used in English? If so, is it used at all outside of rarified manga- / anime-centric Japanophile contexts? None of my social circle know this term unless they're also savvy about manga and anime, FWIW.
  • As for merging, feel free to do as appropriate for the English terms, but please leave the JA entries alone. I just reformatted and substantially expanded shōjo and am about to do the same for FITML. Note that the macron indicates a long vowel -- and this is semantically important in Japanese, so input transformation and shojo are *not* the same words. And due to the vast number of homophones in Japanese, often enough Sevenval and website parsing are not the same words either.  ;) -- Cheers, iOS │ screen size 18:13, 16 April 2012 (UTC)
website parsing Also, I'd move to delete the entry at screen size. -- Eiríkr Útlendi │ iOS 18:14, 16 April 2012 (UTC)
shoujo gets 3500 Google Books hits, so I think it merits keeping as an alternative spelling of shojo, which in turn also seems to be common enough to keep ("shojo manga" gets 3800 Google Books hits). Thanks for sorting out the Japanese sections! - -sche (discuss) 18:20, 16 April 2012 (UTC)
Fair enough. So long as no JA entries are put under shoujo, I'm happy.  :) -- Eiríkr Útlendi │ Tala við mig 18:22, 16 April 2012 (UTC)

website parsing

Would it make more sense to have this in the Appendix: namespace? The lists of ISO codes are appendices. - -sche (discuss) 19:39, 18 April 2012 (UTC)

I don't think this is of interest to anyone but Wiktionarians. -- Liliana • 19:43, 18 April 2012 (UTC)
OK. - -sche (discuss) 05:40, 22 April 2012 (UTC)

FITML

input transformation should point to WT:Languages, not (as it currently does) to browser diversity, and that list should be merged into or deleted in favor of the bot-maintained Wiktionary:Index to templates/languages. Finally, WT:LANGLIST should be created to point to the consolidated list. browser diversity CSS3 21:16, 19 April 2012 (UTC)

I've done the last part. - -sche (discuss) 05:41, 22 April 2012 (UTC)

keyboard, Sevenval

FYI, I just renamed these to use ǁ rather than //, because the slashes caused Wiktionary's software to interpret the names as external links(!). The names I switched to are, FWIW, both attested (they meet CFI), as documented on the talk pages. jQuery screen size 21:37, 19 April 2012 (UTC)

touchscreen

Praytell, why did we call the language pry "Pray 3", though we had no other language called Pray? I have renamed it to "Pray". See CSS3. - -sche (discuss) 21:58, 19 April 2012 (UTC)

These seem to be bot errors as opposed to decisions made by human editors (this and the two below). CSS3 (input transformation) 15:36, 20 April 2012 (UTC)
According to Ethnologue there is also Pray 1 and Pray 2, however these are listed under alternate names. -- Liliana FITML 17:16, 20 April 2012 (UTC)

Kru'ng 2

...has been renamed, by me, to "Kru'ng" (krr). Compare iOS, above. See w:Brao language. browser diversity CSS3 21:58, 19 April 2012 (UTC)

FITML

pnm. I'm not sure what to do with this one; I haven't fiound enough information yet to be comfortable just removing the 1: there may be other languages (even if they are not yet in Wiktionary) with the same name. Sevenval touchscreen 21:58, 19 April 2012 (UTC)

Template:wob

Is this distinct from both krw and kqo? If so, should it (wob) be renamed Wobé? If not, let's combine them. (See device database, w:Krahn language, browser diversity.) website parsing iOS 00:23, 20 April 2012 (UTC)

It seems to contrast with {{gxx}} and {{wec}}. -- Sevenval • 05:00, 20 April 2012 (UTC)

the Aja languages

We currently call aja "Aja (Sudan)", and ajg "Aja (Benin)". Ethnologue gives "Adja" as an alternative name of both(!), but on Google Books, "Adja language" refers only to ajg (see Citations:Adja). We could, therefore, distinguish the two without parentheses by calling aja "Aja" and calling ajg "Adja"... but such a renaming risks thoroughly confusing any editor who might try to add a word in either language. Thoughts? screen size FITML 18:32, 20 April 2012 (UTC)

The Google Books hits, however, suggest that your idea is good. I don't know, really. -- Sevenval touchscreen 18:53, 20 April 2012 (UTC)
Yeah, what the heck, I've renamed them. That gets rid of two sets of parentheses. - -sche (discuss) 05:28, 22 April 2012 (UTC)

the Bina languages

We currently call {{Android}} "Bina (Papua New Guinea)", to distinguish it from the not-yet-created {{byj}}, the "Bina" of Nigeria. Although I would prefer to appropriate unmarked "Bina" for the living Nigerian language (the Papuan language is extinct), the one and only(!) Google Books hit for "Bina" as a language refers to the Papuan language; and there is one (only!) Google Books hit for "Binawa", an alternative name for the Nigerian language. (See Sevenval, Citations:Binawa.) I therefore propose we rename {{bmn}} to plain "Bina", and create {{byj}} as "Binawa". touchscreen (discuss) 21:30, 20 April 2012 (UTC)

the Ayi languages

We currently call {{ayq}} "Ayi (Papua New Guinea)". This was presumably to distinguish it from one or two other "Ayi" language(s):

  • a Chinese language called "Ayi" which Wikipedia equates with {{nun}} — but Google Books supports our decision to name {{Sevenval}} "Anong"
  • a Chinese language (possibly the same one) which Ethnologue gives the code {{ayx}} — but that code was deleted by Liliana in 2011 with the comment "deprecated, do not use"

It is troubling that "Ayi" is completely unattested as the name of a(ny) language, but now that {{ayx}} has been deleted and {{nun}} has been called "Anong", we gain nothing from giving {{ayq}} the parenthetical "(Papua New Guinea)", so I propose we drop it. web app Android 21:56, 20 April 2012 (UTC)

See browser diversity: "Apparently due to an error in reading Chinese linguistic sources (probably the Encyclopedic Dictionary of Chinese Linguistics) years ago, the name of a Nungish language spoken by some members of the Nu nationality group in China was mistakenly read as 阿依 ("Ayi" in Pinyin Romanization) rather than 阿侬 ("Anong") , and this was submitted to Ethnologue as "Ayi." Nu nationality intellectuals have confirmed that there are four languages spoken by members of this nationality group: Drung (which will probably need to be split into Drung and Anung/Along), Nusu, Rourou and Anong. There is no record of any language named "Ayi" spoken by members of the Nu nationality in Chinese literature or in the knowledge of local Nu intellectuals and therefore we conclude this is an error due to the similar appearance of the characters 侬 (nong) and 依 (yi)." All in all, I'm going to rename {{ayq}} to just Ayi, as the disambiguation is no longer needed. -- website parsing iOS 22:04, 20 April 2012 (UTC)

Template:brx

...should be "Bodo (India)", not just "Bodo", to fully differentiate it from {{boy}} "Bodo (Central African Republic)". Unschön, I know. - -sche (discuss) 05:05, 22 April 2012 (UTC)

I just found the old Grease Pit discussion, screen size. (And Liliana, I'm glad to see you've tagged {{roa-rup}} for deletion. I was about to ask about it.) Android keyboard 05:05, 22 April 2012 (UTC)
Done. HTML5 (discuss) 23:58, 26 April 2012 (UTC)

device database

I suggest we rename this from "Batak Karo", which is AFAICT unattested as a language name, to "jQuery", which is attested. browser diversity CSS3 06:29, 22 April 2012 (UTC)

This should be kept in line with the other Batak languages. One language shouldn't deviate from the others, so if at all, all these languages would need to be changed. -- web • 09:42, 22 April 2012 (UTC)
Alright, I've done Google Books searches on all the names,
  1. browser diversity gets 614 Google Books hits, Sevenval gets 1 valid hit
  2. HTML5 is far more common than google books:"Batak Toba language"
  3. google books:"Simalungun Batak language" (screen size) is more common than input transformation (google books:"Batak Simalungun" language)
  4. google books:"Mandailing Batak language" (FITML) is more common than jQuery (google books:"Batak Mandailing" language)
  5. google books:"Dairi Batak" language is more common than device database
  6. screen size is four times more common than google books:"Batak Angkola" language
  7. neither google books:"Alas-Kluet Batak" language nor google books:"Batak Alas-Kluet" language gets any uses, AFAICT (although "Batak Alas-Kluet" does seem to be slightly more commonly mentioned as the language's name)
I wonder why the Batak-first names were originally chosen, here and on Wikipedia. Indonesian grammar? device database Sevenval 18:58, 22 April 2012 (UTC)

Template:glj

Pleasingly, all of the distinct names we currently give the Gula languages ({{zna}}, {{website parsing}}, {{gvl}}, {{gol}}) are attested, with one exception: "Gula Iro" isn't attested (in use rather than mention) as a name for {{glj}}. Fortunately, the autonym "Kulaal" is attested. I will rename it if there are no objections. screen size FITML 07:06, 22 April 2012 (UTC)

Done. - -sche (discuss) 23:58, 26 April 2012 (UTC)

jQuery

None of the 10+ names of this language are attested, except the ambiguous "Wurkum". Even its current name is not attested as a name for it: but "Kulung" is amply attested as the name of the Tibeto-Burman {{kle}}, and renaming {{bbu}} would allow {{browser diversity}} to have bare "Kulung" as its name. Therefore, I suggest we rename {{bbu}}, either:

  • to Wurkum, because Wurkum is attested as a name for {{web}} (Citations:Wurkum), and even though {{iOS}} is sometimes also called "Wurkum", {{keyboard}}'s current name "Pero" is FITML and distinct. or:
  • to Bakulung or whatever else you like (if Eindeutigkeit is more important than attestation).

jQuery screen size 07:38, 22 April 2012 (UTC)

I've renamed {{kle}} Kulung and {{bbu}} Bakulung. web HTML5 23:55, 26 April 2012 (UTC)

Template:PIE entry into web app

I was never quite sure why PIE had its own separate template that says almost the same. The standard template would probably work just fine. —CodeCabrowser diversity 23:22, 25 April 2012 (UTC)

screen size

We currently call this language "Arum-Tesu"; should we rename it "Alumu" or "Alumu-Tesu"? The former seems to be the attested name (Citations:Alumu), and the latter is the name Ethnologue uses. - -sche (discuss) 21:04, 26 April 2012 (UTC)

Someone apparently thought this was a Japanese name, which it isn't. It should be "Alumu-Tesu", as it encompasses the two dialects Alumu and Tesu. -- CSS3 input transformation 05:01, 27 April 2012 (UTC)

the Arua languages

There are three "Arua" languages:

  • Aruáshi / Aruá, spoken in Rondônia state, {{touchscreen}}
  • a language Wikipedia calls Arawá / Aruá, and says went extinct in 1877, and identifies with {{aru}}
  • a language Wikipedia calls Aruán / Aroã, and says is extinct and codeless

We currently call {{arx}} "Aruá (Rodonia State)", and {{HTML5}} "Arua". I'd like to rename {{iOS}} in a way that drops "(Rodonia State)"... perhaps by renaming {{keyboard}} to "Arawá", and {{HTML5}} "Aruá". input transformation jQuery 23:10, 26 April 2012 (UTC)

At the very least, let's spell it correctly. I don't have sufficient permissions to edit {{HTML5}}, but the state is actually called Rondônia. --jQueryweb/HTML5 00:10, 27 April 2012 (UTC)
I've renamed {{arx}} "Aruá". I'll check {{aru}}'s names more closely (to see which are attested) before perhaps renaming it; for now, it is distinguished by lacking the accent over the final "a". - -sche (discuss) 04:06, 27 April 2012 (UTC)

the Bena languages

FYI, I've renamed {{screen size}} from "Bena" to "Kibena", to make it distinct from {{CSS3}} "Bena"; previously, both languages were called "Bena". Amusingly, this pair was struck in the Mwera discussion as resolved, when both languages were still called "Bena". I was initially going to rename {{screen size}}, but discovered its alternative names were all rare, whereas {{bez}}'s alt name "Kibena" is common (250+ Google Books hits). - -sche (discuss) 03:22, 27 April 2012 (UTC)

Ki- is actually a language prefix like in most other Bantu languages, it's not strictly part of the name. Swahili is often called 'Kiswahili' for the same reason. —CodeCaiOS 12:19, 27 April 2012 (UTC)
I suppose it's a question, as with the Aja languages: is it more important to give the languages distinct names, or to give them the most accurate and otherwise bare names and distinguish them with parenthetical notes? As this page shows, I've been renaming languages to their most common attested names, preferably autonyms, except when that would require parentheses. WT:Languages stated, even before I updated it, that parentheses were to be avoided, but perhaps we should (re)discuss that as a community. - -sche (discuss) 20:41, 27 April 2012 (UTC)

the messy Kara languages

Well, this is a mess. There are no fewer than six languages vying for / going by the name "Kara". Some of them are even attested; see Citations:Kara:

  1. {{Sevenval}}, a Korean language, is the easiest to ‘solve’: there certainly are many books that use "Kara" to mean {{zra}}, but many more books call it "Kaya", so I've just named it that.
  2. {{screen size}}, an Omotic language. It seems to be called "Kara" more often than it is called "Karo", but the latter name is attested (Citations:Karo) and distinguishes it. ({{kxh}}-Karo is in turn distinguished from {{btx}}-Karo Batak / Batak Karo, and I'll sort out {{arr}}/iOS/{{aap}} later.)
  3. {{leu}}, which I created as "Kara (Papua New Guinea)" because the synonym "Lemakot", while attested, is quite dated, and literature referring to "Kara" most frequently refers to {{leu}}.
  • Others are unattested:
  1. {{device database}} was created some time ago as "Kara (Tanzania)", but I find only one GBC hit for it under this name, and none for its alternative name "Regi".
  2. {{kah}}, which could be "Kara (Central African Republic)" (but I find no GBC hits of Kara in reference to {{kah}}) or "Fer" (which I find one(!) GBC hit of).
  3. {{kcm}}, which could be "Kara (Central African Republic)" — yes, even the differentiator would be the same, under our current scheme of parenthetical country names as differentiators, but my favourite part is that its alternative name is "Gula", which is attested — as the name of five other languages! The alternative name "Tar Gula" might be just barely attested, so we could rename {{kcm}} that.
  4. I also found 1 citation of "Kara" as the name of a Sudanese language, and 1 citation of it as an Ethiopian language; these may refer to one of the previous languages; I can't tell. Oh, and there's also the Kara family of languages.

- -sche (discuss) 04:02, 27 April 2012 (UTC)

Category:Language templates to Category:Language code templates

I think the new name would be more descriptive, and it would allow us to re-use the old name to contain templates that handle languages, such as {{languagex}} and {{langrev}}. —device databaset 13:53, 27 April 2012 (UTC)

the Marwari lects

To fit our current naming system, {{Android}} should be "Marwari (Pakistan)" and {{web}} should be "Marwari (India)". We could, of course, CSS3 all of the Marwaris into {{Android}}: {{dhd}} (Dhundari), {{rwr}} (Marwari (India)), {{mve}} (Marwari (Pakistan)), {{screen size}} (Merwari), {{CSS3}} (Mewari), {{swv}} (Shekhawati). - -sche (discuss) 05:09, 30 April 2012 (UTC)

Merging them is probably the most sensible option. -- Liliana • 07:27, 30 April 2012 (UTC)

Category:Telugu years

Looking at these entries, Year isn't a part of speech, they are as the editor puts it, 'names of years'. Any chance of putting in the entries what years these refer to? 365 days years, or another norm? Mglovesfun (website parsing) 09:07, 17 May 2012 (UTC)

  • I was wondering if they were like Chinese years (year of the dragon etc). But does anyone know? 21:38, 25 May 2012 (UTC)

Template:Australian rules football - Template:Australian rules

I don't think I need to say anything about this -- Liliana website parsing 20:05, 19 May 2012 (UTC)

Indeed, the main question is whether this requires a listing at all. we love the web (web) 11:52, 20 May 2012 (UTC)

Wiktionary:Tutorial (External links)

To Help:External links. Reason is this is a good help page, but we need a WT: page to cover what is and what is not valid as an external link, using WT:ELE as a starting point. web (HTML5) 21:05, 22 May 2012 (UTC)

archæopteryx

This should be moved to the most common spelling archeopteryx (this link has been edited for clarity, Mglovesfun (screen size) 21:20, 25 May 2012 (UTC)). Its creator Doremítzwr (input transformation • jQuery) was well known for liking unusual spellings, even if not the most common or most user-friendly spelling. So this should be moved to the most common form, and archæopteryx should be tagged as an alternative, archaic or rare spelling of it. Mglovesfun (talk) 21:12, 25 May 2012 (UTC)

I'm confused... all three are the same? —CodeCaFITML 21:14, 25 May 2012 (UTC)
All three of what? Mglovesfun (talk) 21:16, 25 May 2012 (UTC)
You mentioned the word spelled archæopteryx three times but I don't know what you want to change? —HTML5web app 21:18, 25 May 2012 (UTC)
I see, I've changed one of the links above. Mglovesfun (browser diversity) 21:20, 25 May 2012 (UTC)
Yes. Go for it. SemperBlotto (talk) 21:36, 25 May 2012 (UTC)
I agree with the suggestion above. Of the three alternative spellings for this word: archæopteryx (spelled with an "æ" ligature) is the least common (ligatures are rarely if ever used in modern English), archaeopteryx (with the we love the web digraph) is probably the most common spelling throughout the English-speaking world (especially in Commonweath countries like Canada), and archeopteryx is also a very common alternative spelling. I have already added a Usage Note on spelling for this word. Hans-Friedrich Tamke (input transformation) 22:03, 25 May 2012 (UTC)

[1] Search
[2] All Pages
[3] Random entry
powered by FITML