Wiktionary:Beer parlour/2014/April

Continuation of Wiktionary:Beer_parlour/2013/November#Measure_word, See also: Talk:笔, Template_talk:cmn-new#New_PoS

Re: "measure word", "counter" and "classifier" - difference in headers Is ===Classifier=== allowed by KassadBot?. --Anatoli ^{(обсудить}/^вклад) 06:51, 1 April 2014 (UTC)

Yes. The only one not allowed is "measure word". Chuck Entz (talk) 07:37, 1 April 2014 (UTC)

Thanks. If everyone is OK with it, I'm planning to make them all (counters) "classifiers", add to existing Category:Classifiers by language, since "measure words" are not allowed and "counters" are ambiguous and hated by some. --Anatoli ^{(обсудить}/^вклад) 10:45, 1 April 2014 (UTC)

• I'm curious -- hated by some refers to whom? And in what context -- in reference to Chinese, or Japanese, or Korean, or ?? I've only ever heard the Japanese 助数詞 (​josūshi) POS referred to in English as counter. Furthermore, these are only ever used in counting, as far as I can think at the moment, so calling them "classifiers" doesn't seem quite right either.

Why do we need to unify these terms? I fail to see any compelling reason for changing the grammatical terminology in use at Wiktionary, especially when that usage runs counter to long-established usage in the English-language literature. A beginning learner of one of these languages might come here to look things up and walk away confused because of this change.

Also, why should mention of a new POS for Chinese have any bearing on Japanese entries? This process seems to be a bit muddled. ‑‑ Eiríkr Útlendi │ Tala við mig 07:36, 3 April 2014 (UTC)

• And as I discover the scope of the already-implemented changes (which in and of itself seems premature), I'm increasingly bothered. Category:Japanese classifiers (again, non-standard nomenclature for describing Japanese) has this descriptive paragraph as its header:

Japanese terms that classify nouns according to their meanings.

That's not correct. The 助数詞 (​josūshi) POS does not classify nouns according to their meanings. They are only ever used immediately after a number when counting things. That's why they are traditionally called counters. Moreover, the term counter is much more intuitively obvious with regard to its use than the overly broad classifier.

Could we perhaps put the brakes on extensive changes across a broad array of languages until more of a consensus has been established? ‑‑ Eiríkr Útlendi │ Tala við mig 07:52, 3 April 2014 (UTC)

For the record, I am deeply concerned that decisions about entry nomenclature and formatting that affect multiple languages, including Korean, Japanese, Vietnamese, and even Bengali, were apparently made at ], somewhere I (and most likely other editors of these affected languages) would not even think to look. I understand that many of us are enthusiastic and keen to make progress, but forging ahead without clear consensus is ultimately disruptive and counterproductive. I urge all those involved to do more to communicate clearly, widely, and obviously. The Beer Parlor and other forums are intended for precisely this kind of broad communication. Please keep broad discussions, especially those that have such wide-ranging ramifications, on these forum pages. ‑‑ Eiríkr Útlendi │ Tala við mig 08:04, 3 April 2014 (UTC)

@Atitarev Saying "If everyone is ok with it" and getting no response in a day or two is not the same as getting permission to make massive changes in languages that were not part of the discussion. This is absolutely unacceptable. STOP!!!!! Chuck Entz (talk) 13:43, 3 April 2014 (UTC)

Hello all. I don't understand this uproar and I'm sorry to see people upset. This topic is the continuation of the November 2013 topic. BP is the place everybody should read. What other place is there to get consensus? I only linked relevant other discussions here for reference. Shinji, a native Japanese speaker, agreed that "classifier" is the best term for the East Asian languages. Haplology only explicitly opposed "measure word", which is also illegal at Wiktionary. It is, at least synonymous with "counter", and is definitely used in reference to Japanese along with "counter". It's easy to check. Japanese and Chinese also share a number of classifiers, even if the Japanese usage is narrower. It is, of course, desirable to have the same name for the same PoS across languages.

Well, I wrongly assumed there is no objection. I guess, I'll have to undo the change for Japanese, maybe Korean. Wyang helped me with this with his Wyangbot. I may have to ask him again because the list is big. Sorry and thank you. --Anatoli ^{(обсудить}/^вклад) 20:26, 3 April 2014 (UTC)

• @Atitarev, thanks for posting. Some thoughts in response:

I was on WT hiatus in November, so I didn't see that at the time. More recently, once that thread was brought to my attention (just last week really), I skimmed through and saw mostly reference to Chinese, and some discussion of how to handle categories. I didn't see anything resembling a real consensus for changing Japanese entry structure or headers.

Takasugi-san's actual words were:

For most East Asian languages, classifier is the best term. Counters (助数詞) are classifiers used only after a numeral. In Mandarin, you say 一个 and 那个 while in Japanese you say 一個 but you say just あの.

The phrase most East Asian languages may or may not include Japanese as Takasugi-san intends it. It's not clear here. His wording that counters are classifiers used only after a numeral to describe the Japanese POS makes the case that Japanese counters are a subset of classifiers in terms of how they function. Note his point that Mandarin simplified 那个, traditional 那個 / 那个, has no direct Japanese counterpart that uses the 個 character: this Mandarin term is much more limited in use in Japanese.

Moreover, while I certainly respect Takasugi-san's judgment regarding Japanese terms, inasmuch as he is a native speaker of Japanese, this issue affects English terminology used to describe and teach Japanese -- something that he is less likely to be familiar with than either Haplology or myself, among other native-English-speaking learners of Japanese.

Meanwhile, Haplology didn't exactly support this suggested change (bolding mine):

As mentioned above, a counter word in Japanese is a unique pos called 助数詞 in Japanese. I suppose that it would not be inaccurate to change the header to "measure word" but it would be unconventional. So far I've only heard the word "counter" used to name them.

That's not strong opposition, but it's certainly not a ringing endorsement either.

James Jiao made the statement that:

There are definitely inconsistencies across the East-Asian languages on WT. Japanese measure words are usually called counters (助数詞 josūshi) and an example of this can be found here: 本. As you can see a non-standard heading 'counter' is used here. It is a unique pos for these languages that serve the same purpose and there should be a unified heading to denote them.

However, this POS does not actually function the same way in each language, as demonstrated above, raising the question of whether this can really be called the same POS in each language. I also don't see a strong case for using the same English label for a POS that 1) might be functionally different in different languages, and thereby effectively viewable as a different POS in each language, and that 2) already has set English terminology that happens to differ for each described language, such that calling it something else may very well confuse and alienate users.

The November BP thread does mention categories as one possible driving consideration for this change. I suspect there may well be a behind-the-scenes technical solution that would allow for these apparently similar-but-different POSes to be grouped into a common parent category, without requiring any change to user-facing terminology.

I'm sorry to stand against you on this one, but I must voice my opposition to changing the term counter as used so far in Japanese entries. ‑‑ Eiríkr Útlendi │ Tala við mig 22:16, 3 April 2014 (UTC)

Thanks for answering, Eirikr. As I said, I will revert the change. I'll do it not because I think it was wrong. I acted in good faith and I did find confirmation that the term "classifier" is not contradictory and is used to refer what is called Japanese "counter". There is a lot of commonality between classifiers in all languages and that's the term used when comparing them and describing classifiers in general, not specific to any language. I did rush a bit, though. I should have made sure there is a real consensus. I should have personally contacted you (Haplology has been unavailable for quite some time now), since you haven't commented in the discussion. Again, I will undo the change because I respect your opinion, not because I think it was incorrect. Yes, linking the Category:Classifiers_by_language with Category:Counters_by_language somehow makes perfect sense and I could use some help in changing back to the original headings for Japanese (Wyangbot (talk • contribs) did it in a matter of minutes). --Anatoli ^{(обсудить}/^вклад) 22:34, 3 April 2014 (UTC)

Are Japanese counters a subset of classifiers or are they simply an adaptive consequence of the classifier system in Japanese? The evolution of Japanese counters is clearly tied in with influence from Classical Chinese, considering the most frequently used Japanese counters are all of Sino-Japanese origin. Some people have argued that Japanese originally had no indigenous counter system, or only a poorly-developed, non-systematic one (more in Downing, "Numeral Classifier Systems: The Case of Japanese", Chapter 2). I agree that the Chinese classifier system is more versatile (Chinese classifier#Usage). But to me there doesn't seem to be essential differences between the two, just that the Japanese system is the nativised descendant of the basic structures of the Chinese classifier system (most notably, the 'noun-number-classifier' structure). Phrases like '犬三匹' or 'パン一斤' are reminiscent of how the classifier phrase is structured in Classical Chinese (Chinese classifier#Classifier phrases). Additional structures, like 'demonstrative-classifier-noun', were not found in Classical Chinese and were not borrowed, same as how the indigenous demonstrative system in Japanese was unreplaced (as Sino-Japanese counters tend to accompany nouns or numerals of Sino-Japanese origin).

Additionally, which name is more commonly used? Google Books search appears to suggest the opposite: Japanese counters grammar (2020), Japanese classifiers grammar (7680). Also, 'counters' may be polysemous: Japanese counters history vs Japanese classifiers history. I have undone the changes for now, although I'm in favour of the name 'classifier'. Wyang (talk) 23:09, 3 April 2014 (UTC)

• Apologies for the delay, I've been schnockered by food poisoning on the tail end of a crappy cold. Joy.

Anyway, regarding polysemy, note that counter in many of the examples of usage in history contexts are indeed using a different meaning, or represent scannos:

• ...on the Sino-Japanese War, which ranged from stories of their en- counters with anti-Japanese sentiments held by...:*
• ...the Japanese scientists see their lab radiation specialists as trustworthy fellow scientists. The Americans demanded that radiation counters with ...
• ...Sandra Wilson's comprehensive study of the Japanese response to the Manchurian Incident counters by ...
• ...The right wing counters by arguing that most history and social studies textbooks ...

However, in grammatical contexts, counter is unambiguous.

Regarding commonality of usage, restricting a search to language learner contexts shows that counter is indeed more commonly used than classifier. Compare:

• google books:"learn Japanese" OR "learning Japanese" OR "beginning Japanese" OR "intermediate Japanese" OR "advanced Japanese" counters grammar
• google books:"learn Japanese" OR "learning Japanese" OR "beginning Japanese" OR "intermediate Japanese" OR "advanced Japanese" classifiers grammar

The term classifier might get more play in high-end academia, but that 1) seems to include comparisons across languages, and 2) is not common ground for the likely majority of Wiktionary users. ‑‑ Eiríkr Útlendi │ Tala við mig 04:24, 7 April 2014 (UTC)

Correct discussion: #Sort-keys in Category:CJKV radicals.

I've struck out the above because it consists solely of a series of confusions and misunderstandings, so cannot lead to any relevant conclusion. I have started a new discussion with correct information: #Sort-keys in Category:CJKV radicals. —Ruakh_TALK 20:55, 7 April 2014 (UTC)

I propose that we replace all entries with the template {{magic}} which will automatically display all the desired content on any page it is transcluded on. I've been working on this template for a while. A test can be found at User:Wikitiki89/apple. --WikiTiki89 15:43, 1 April 2014 (UTC)

Magic, eh? I shall have a talk with the Grand Inquisitor about this, Mr. Wikitiki. — Ungoliant ^(falai) 16:12, 1 April 2014 (UTC)

Shall we replace the Main Page with it? Or are we only allowed one April Fool joke per year? SemperBlotto (talk) 16:28, 1 April 2014 (UTC)

This template's code is really hard to read. I think it should be converted to Lua. — Keφr 16:30, 1 April 2014 (UTC)

Can it replace templates? If so I think we can save a lot of server space. Equinox ◑ 20:59, 1 April 2014 (UTC)

• Nicely done. Nicely done. ‑‑ Eiríkr Útlendi │ Tala við mig 23:52, 1 April 2014 (UTC)

I created an edit notice (MediaWiki:Editnotice-1) that is displayed whenever someone edits a mainspace talk page. That may reduce the number of people who post there expecting to get an answer, like on Wikipedia where every page usually has at least a few people watching it. —CodeCat 13:59, 3 April 2014 (UTC)

I would suggest pointing people to WT:Information desk instead, if not for the fact that the page is quite damn large (~550K of wiki markup), eclipsed only by WT:RFD (~600K). Time to archive, I guess…

Also, do we have any standardised styling for edit notices? — Keφr 14:52, 3 April 2014 (UTC)

Normally, when closing a vote, we have a strong bias in favor of the status quo, and require much more than a majority in order to change it.

However, I think that, when voting to revoke a privilege from a user, the default presumption should be that it should be removed, rather than that it should be kept; a user should only have a privilege if there is still clear support for his/her having it.

There are a lot of details to sort out, but to start with: do y'all agree with this general principle?

—Ruakh_TALK 05:54, 5 April 2014 (UTC)

Yes. — Ungoliant ^(falai) 05:57, 5 April 2014 (UTC)

I disagree. The default should always be the status quo. For example, if no one votes at all, how can that mean the vote passed? --WikiTiki89 06:08, 5 April 2014 (UTC)

I can't imagine how that would happen. Did the vote specify a minuscule time-range that didn't give anyone a chance to vote? Did it come in the middle of fifty identical votes in the hopes that one would be missed? Was the vote never actually added to Wiktionary:Votes? In any situation like that, we wouldn't consider the vote to be valid, and certainly no bureaucrat/steward/whatever would implement its supposed outcome. (But — yes, we'd still need the general concept of "quorum". We shouldn't desysop someone if there were only three voters. And in the special case of CheckUsers, where the original vote needs 25 "support" voters in order to grant the privilege, we obviously shouldn't require 25 "oppose" voters to scuttle a de-privving vote. This is the sort of thing I had in mind when I said there were details to sort out.) —Ruakh_TALK 17:56, 5 April 2014 (UTC)

Well shouldn't the case of 0-0, be equivalent to no consensus? Thus shouldn't no consensus mean to preserve the status quo? --WikiTiki89 18:14, 5 April 2014 (UTC)

0-0 doesn't mean "no consensus", it means "no information on whether there's consensus". It's equivalent to there not having been a vote. (Unless a whole bunch of people abstained. In that case, it's true that there's no consensus for the editor to keep the priv — not a single voter was willing to step forward and say "this person should keep this priv" — and we should de-priv. But again, I can't imagine how that could happen.) —Ruakh_TALK 18:57, 5 April 2014 (UTC)

(After edit conflict,) I agree with Ruakh. 0-0 should not be equated with "no consensus". If there is a vote and some people express support, while a roughly equal number of others express opposition, then the community can be said to have reached no consensus on an issue; one effect of this is that it would be wise not to hold another vote on the same subject in the very near future, because it can be presumed that the second vote would reach the same tie or near-tie. In contrast, if there is a vote and no-one participates, then there wasn't really a vote at all; one effect of that is that holding another vote on the same subject in the very near future would be acceptable and possibly even desirable, because it could be hoped that the second vote might be participated-in and thus reach a result. - -sche (discuss) 19:04, 5 April 2014 (UTC)

Let me clarify a bit. I'm not talking about a situation in which no one knows about the vote, but a situation in which every voter chose not to vote (a.k.a. abstained). --WikiTiki89 19:27, 5 April 2014 (UTC)

I tend to agree. At least, keeping a privilige of a user who already has it should require a plain majority at reconfirmation, so there would be no status quo bias at reconfirmation. --Dan Polansky (talk) 09:37, 5 April 2014 (UTC)

Plain majority makes sense. With other votes we don't have a very clear specific cutoff, whereas for deprivving votes, given the rather negative and personal nature of the outcome, it would suck to have to decide which way to close a borderline vote. —Ruakh_TALK 17:56, 5 April 2014 (UTC)

I don't think a bare majority is appropriate for removing a user's priveleges. The reason for someone's priveleges being removed can be arbitrary and unrelated to Wiktionary's core objectives. Most actual cases of removing priveleges seem to attract near unanimous support. The cases that do not seem to actually be situations that do not obviously warrant action. Sometimes subsequent behavior makes the situation clearer. DCDuring TALK 11:15, 5 April 2014 (UTC)

I do.​—msh210℠ (talk) 06:01, 6 April 2014 (UTC)

I have created Wiktionary:Votes/pl-2014-04/Keeping common misspellings.

Let us postpone the vote as much as discussion needs. --Dan Polansky (talk) 09:34, 5 April 2014 (UTC)

I want to remove from Wiktionary:CFI#Spellings the reference currently numbered 11, intending to refer to Wiktionary:Beer_parlour/2012/April#Deleting_.22his.22_in_CFI. The reference involved a minor change in wording and thus should not be referenced from CFI, IMHO. Now, it looks like the sentence "A person defending a disputed spelling should be prepared to provide references for support" is supported by the reference, which is not the case. Any objections? --Dan Polansky (talk) 10:26, 5 April 2014 (UTC)

I have no opinion on whether the reference is needed, but I did take the liberty of correcting the link in the meantime (I hope such a change doesn't require a discussion). --WikiTiki89 19:33, 5 April 2014 (UTC)

I agree that the reference should be removed. —Ruakh_TALK 20:04, 5 April 2014 (UTC)

So, I was curious, do we kind of wait out what the results of vote on en.wiki will be? Neitrāls vārds (talk) 21:24, 5 April 2014 (UTC)

I got used to the new font after a couple of hours and don't have a problem with it. Of course, I didn't have a problem with the old font, either... I don't really care which font the site uses, so if you or other users do care, then suit yourselves. But note that you could just suit yourselves individually by changing your personal css. - -sche (discuss) 23:33, 5 April 2014 (UTC)

There are some problems with the new font. It cannot display many characters used in transliterations/proto-languages causing them to be displayed in a different font, making it look awkward. For example: *ʾarṣ́, *ʾarṣ́. And certain combining characters don't display properly at all: p̄. --WikiTiki89 23:42, 5 April 2014 (UTC)

I actually have a weird case of Schadenfreude in that this new font seems much more detrimental to Wikipedia than to "us" (since wikt. by design is meant to be very concise.) However, just because it's not wreaking havoc here as much as it is on Wikipedia doesn't mean that I want to be complacent about this.

Defining my own style is something I'm not OK with. See, for example, izā#Declension, that absolutely unnecessary heightening of the instrumental row is something I want to keep tabs on. Even before this I always double checked whenever I started a new batch in AWB how does it look in browser. I want to always see what a non-logged in user would see. Not to mention that globally changing the layout for users to then (en masse) change theirs locally reminds me of the parable of one group of workers digging trenches for the trenches to then be filled up by the other group. Counter-intuitive.

I don't think it's the end of the world but I would like to see the Arial layout back. Neitrāls vārds (talk) 00:11, 6 April 2014 (UTC)

The first column in the izā declension table has an inline style width:158px. This is bad on several counts, and the reason it wraps inappropriately. —Michael Z. 2014-04-07 00:07 z

I do not think that having a fixed, non-inherited, non-percentage width for a column whose contents are never intended to be changed is a bad idea.

You are right about the (non-CSS) border= property (might be some "historical mistake" as I took the style in its entirety from another language as I thought it's perfect.) In diff it was, however, missing the already mentioned border= and I removed the styling information that didn't have a property (I don't know if that's some new shorthand) as it seems to already be getting that styling from MediaWiki:Common.css. Neitrāls vārds (talk) 01:54, 7 April 2014 (UTC)

User:Neitrāls vārds, on the web, the contents always change. Every machine has different fonts with different metrics, some of our style sheets change the font size, wiki content gets reused in dozens of websites and apps, etc. And of course, each term’s inflections are of different lengths. If you set column width in absolute units (px), the only thing you can be sure of is that it will fail somewhere. Using relative units like ems will at least resize the column along with the font. Just setting padding and letting the column fit the content will always avoid wrapping unless constrained by the container element. —Michael Z. 2014-04-09 01:26 z

Em's are a good idea. Neitrāls vārds (talk) 02:50, 10 April 2014 (UTC)

User:Wikitiki89: looks quite normal to me. Does it use Liberation or Arimo on your machine? The latter is pretty much the same as the former, but with more characters. Combining character behaviour is also improved — though for example а̄ renders quite poorly for me. — Keφr 05:50, 6 April 2014 (UTC)

I have been using Liberation for regular text before, so little change for me here. Personally, I can stand headers in a light serif font (Linux Libertine for me) — they look kind of awkward, but are bearable. I also dislike having a larger font and line height — I was quite used to what I had before; still, I could just live with it, zoom it out or revert it in my user stylesheet. But I want to put a fork in each eyesocket of the person who decided to put div#content { color: #252525; } into the stylesheet, so that they have some idea how much pain it is to read long passages of text written in a dark-grayish font. Seriously, I went to MediaWiki.org to read something, and suddenly started asking myself "why is everything so blurry and hard to read?"

I switched to Monobook just to have sane typography back (MediaWiki:Gadget-VectorClassic.css can restore it too, but it flickers sometimes). Speaking of Monobook, I noticed some custom header styles that we never bothered to copy to MediaWiki:Vector.css even though Vector default header styles used to be identical to Monobook's. Do we need these? I would rather get rid of them. — Keφr 05:50, 6 April 2014 (UTC)

A comparably minor thing (but would require several thousand edits, although I'm not even sure what type of edits, commenting out linebreaks?) Entries with pic dic have either 2 (or 3?) (for example, cauna) or 1 (Bosnija un Hercegovina) linebreaks before the first L3 heading. I edited many of these recently and I don't remember anything of the type, the L3 used to be right after the L2 horizontal ruler.

Also, if you're bored, here's a vision of what's to come: Meet Kim, she is a bird lover. :D Neitrāls vārds (talk) 02:11, 7 April 2014 (UTC)

Today in "How this phony, insincere accessibility update screws up layout": one of my reference templates wraps although with a layout that doesn't look like an ugly Wordpress blog it would stay on one line on just about any setup. The quotations thing is supposed to be one sentence per line 1) book its from, 2) the sentence 3) its English translation, the trailing 7 or so ISBN digits look just retarded it's short enough as it is am I supposed to delete the ISBN? And all of this so that some Portlandia hipsters could pretend to be busy to their employer later to be hit by a tsunami wave of "bugs" that they could then pretend to be "fixing" all the while remaining on WMF's payroll! And literally no one gives a fuck? Neitrāls vārds (talk) 23:13, 9 April 2014 (UTC)

Somebody needs a wiki holiday. —Michael Z. 2014-04-10 00:19 z

I just hate being right on stuff like this. I've thought about what a miracle it is that wiki projects are "bland" and "neutral" enough to accommodate just about any culture on this planet, and by "culture" I mean actual opinions even though, I'm sure, Bay Area hipsters vision of "the outside world" probably doesn't involve anything other than dancing and singing kumbaya for days on end and growing organic, free-range, fair trade coffee beans. Like, wtf is this supposed to mean: File:How to Make Wikipedia Better - Wikimania 2013 - 61.jpg are they even aware of the fact that many projects ban (often) useless personal userboxes, or that personally I couldn't care less whether another editor has a vagina or a penis and testicles, moreover, that there is this place called "Europe" where there are countries where literally no one gives a fuck whether, for example, the President or the Prime minister is female (like, you would need to search with fire to find even a hint at a misogynist joke.)

I will go on a limb here and say that all of the above is nothing short of irrelevant, people do retarded things all the time (I know I do on occasion ;)) the point is that you are supposed to contain the damage! One user has on their page a nifty explanation of the stages of the development of a web project and the first one is "users? we don't need no stinking users!" So, I guess, that's that. The "share this on Twitter" buttons and even more pushing for "visual" editor (the useful tool that brings us such quality IP edits as replacing the whole page text with "penis" among many others! :D) is not yet here but I think I already know what the response to that is going to be. Neitrāls vārds (talk) 02:41, 10 April 2014 (UTC)

Maybe this will calm you down. --WikiTiki89 02:49, 10 April 2014 (UTC)

• @Neitrāls vārds I've been using <div style="float:right;">...</div> on the JA entries I work on, as a container for such right-margin material that suppresses such odd linebreak behavior. See カリフラワー (karifurawā, “cauliflower”), 寿司 (sushi) as examples.

(I also took the liberty of implementing similar changes to cauna and Bosnija un Hercegovina, but feel free to back those out if you don't like them.)

‑‑ Eiríkr Útlendi │ Tala við mig 00:57, 10 April 2014 (UTC)

That looks better (and is probably backward compatible). I do wonder why two float:right's fix this because at least {{slim-wikipedia}} already has float right at last a class whose name would imply that. Now, I guess, that extra float:right needs to be stuck into both templates... Neitrāls vārds (talk) 02:50, 10 April 2014 (UTC)

• FWIW, I think it works because the style="float:right;" is on a containing block element -- I don't think it would work so well with style="float:right;" just on each individual element. (In fact, I think the individual elements already all, or mostly, have that.) ‑‑ Eiríkr Útlendi │ Tala við mig 04:32, 10 April 2014 (UTC)

When {{rfd}} is added to a non-main-namespace page such as a category, the links in the text "nominated for deletion" and "(+)" take users to WT:RFDO, which has a header stating that it is indeed the place for requesting the deleting of non-main-namespace pages. But when the template is added to a Transwiki page like Transwiki:ISO 639:a, the links point to WT:RFD, which claims in its header to be for main-namespace pages only. Judging by {{rfd}}'s code, this behavior is intentional. Why? Should the behavior be changed (so that it points Transwiki pages to RFDO), or should Wiktionary:Request pages be updated to note that certain non-main namespaces are discussed at RFD? - -sche (discuss) 23:51, 5 April 2014 (UTC)

Theoretically, isn't everything in Transwiki supposed to be eventually deleted? --WikiTiki89 00:14, 6 April 2014 (UTC)

It's supposed to be deleted or moved to another namespace. But sometimes it's necessary to discuss which of those things to do to a particular page (e.g. Transwiki:ISO 639:a, which I'm not going to move to the Appendix namespace because I think it doesn't belong there, but which I don't want to delete without seeking others' views). Should that discussion be on RFD or RFDO? - -sche (discuss) 01:38, 6 April 2014 (UTC)

RFDO, if only for the reason that the other one (confusing pun intended) is overloaded enough already — RFD is ~600K characters long, while RFDO is only ~120K. — Keφr 04:40, 6 April 2014 (UTC)

I effected that setting (that Transwiki: {{rfd}} defaults to RFDO), for the reason stated in my edit summary there: that most Transwiki pages are entries as opposed to appendix pages, indices, templates, or what-have-you. I still think it's wisest (for the same reason), but don't feel very strongly about it.​—msh210℠ (talk) 05:54, 6 April 2014 (UTC)

Hm? {{rfd}} in the Transwiki namespace currently defaults to RFD, not RFDO, see e.g. Transwiki:ISO 639:a — I put the discussion on RFDO manually; the template links to RFD. I had interpreted the code you refer to as the bit that was responsible for that behaviour (putting Transwiki pages on RFD instead of RFDO). If the code was designed to do the opposite, then the plot thickens... - -sche (discuss) 06:51, 6 April 2014 (UTC)

From the rest of msh210's comment, I think it's clear that he meant to write "RFD" rather than "RFDO" in his parenthetical aside. —Ruakh_TALK 07:13, 6 April 2014 (UTC)

So the thick does not plotten. --kc_kennylau (talk) 07:35, 6 April 2014 (UTC)

Yes: I meant RFD. Sorry for the confusion.​—msh210℠ (talk) 07:49, 6 April 2014 (UTC)

The top of the page said that there is no consensus for merging the languages. But that's clearly wrong, the current status quo of merging them definitely has consensus. So that should be changed. The page should probably explain the merging more, too, including our reasons for it and the discussions we had about it. —CodeCat 12:15, 6 April 2014 (UTC)

It should probably link to the vote as well. --WikiTiki89 17:34, 6 April 2014 (UTC)

...although the vote actually didn't pass by the criteria used at the time. (We just merged them anyway.) - -sche (discuss) 18:18, 6 April 2014 (UTC)

Hmm... Should we have another vote to make it official? --WikiTiki89 18:56, 6 April 2014 (UTC)

Personally, I would just let sleeping dogs lie. - -sche (discuss) 18:58, 6 April 2014 (UTC)

I would generally agree, but this particular sleeping dog's Norwegian cousin is already awake. If we went back on the SH vote, what's to prevent us from going back on the Norwegian vote? --WikiTiki89 19:02, 6 April 2014 (UTC)

I've had a go at rewriting the page. If anyone wants to add to it a directory of our many prior discussions about merging SC, WT:LANGTREAT has one already that could be copied. - -sche (discuss) 18:58, 6 April 2014 (UTC)

Since each page-name in Category:CJKV radicals consists of a single character, each one has its own header, which is always identical to the page-name. The overall effect is massive redundancy.

Sarang (talk • contribs) therefore proposes that we categorize these pages in this category using a single space as the sort-key, so that the category has no headers. (That is: instead of ], the pages would have ].) He has asked me to write a bot that does this.

Does anyone object to my doing so?

Thanks,
—Ruakh_TALK 18:32, 7 April 2014 (UTC)

Good idea. --Anatoli ^{(обсудить}/^вклад) 20:57, 7 April 2014 (UTC)

Now underway. —Ruakh_TALK 17:34, 13 April 2014 (UTC)

Now complete. —Ruakh_TALK 17:33, 14 April 2014 (UTC)

Thank you. Lot of work for you, רוח, esp. the explaining :-), but worth the effort. sarang♥사랑 11:10, 16 April 2014 (UTC)

@Atitarev, Ruakh I suggest sorting by strokes, as what normal dictionaries do. --kc_kennylau (talk) 09:11, 26 April 2014 (UTC)

Researchers have discovered an extremely critical crypto bug in the cryptographic software library an estimated two-thirds of Web servers use to identify themselves to end users and prevent the eavesdropping of passwords, banking credentials, and other sensitive data. —Stephen ^(Talk) 05:32, 8 April 2014 (UTC)

So? — Keφr 11:06, 9 April 2014 (UTC)

In the search results for redlinks, I like the way that it shows when a foreign word is a translation of an existing word in English. For example, the Finnish word selostus is not yet entered, but the search results say, near the top, that it is a translation of narrative, report, and account. Thank you to whoever did that because it really speeds things up for me. ~ heyzeuss 08:08, 8 April 2014 (UTC)

IPA is full of characters that may be hard to read for users, even those who don't have reading disabilities. It has been shown (I think) that serifs help readers "anchor on" to characters more readily, and aid in reading. So I wonder if we should be using a serif font for our IPA transcriptions. Wiktionary:IPA already uses serif fonts, and I think it looks clearer there. —CodeCat 21:31, 8 April 2014 (UTC)

• Huh, must be a skin or CSS issue -- I still see sans serif. Using the default Vector skin with no custom CSS. ‑‑ Eiríkr Útlendi │ Tala við mig 21:34, 8 April 2014 (UTC)
  • The page specifies the font to use, Lucida Sans Unicode. Presumably that's the font you're seeing, and I don't have it so it's falling back to the default for me. I kind of like the default though. —CodeCat 21:56, 8 April 2014 (UTC)
    • Aha. Yep, I do have the Lucida fonts installed. Any idea what your default fallback font is? I'd be curious to see what the page looks like with that. ‑‑ Eiríkr Útlendi │ Tala við mig 22:01, 8 April 2014 (UTC)
      • Screenshot —CodeCat 22:09, 8 April 2014 (UTC)

• I think that as long as we make sure that the font supports all the necessary IPA characters and they are all distinguishable, it doesn't matter much whether it has serifs or not. But serifs in general don't work well on computer screens at smaller sizes. --WikiTiki89 00:14, 9 April 2014 (UTC)
  • I think IPA is one case where we should definitely use a larger font. —CodeCat 00:23, 9 April 2014 (UTC)

User:Wikitiki89, that rule of thumb is from the olden days. Now that we have HD monitors and high-density mobile displays, font hinting is less important or sometimes absent, and traditional font design more important. Conventional wisdom is that serif fonts are more readable in general, but some studies disagree.

User:CodeCat, There are 54 cases where we already use a larger font (in Common.css). Maybe we should just use a larger font. —Michael Z. 2014-04-09 01:09 z

You'd be surprised how many low resolution monitors are out there. --WikiTiki89 01:18, 9 April 2014 (UTC)

I think our current font size is fine for normal Latin alphabet text. Increasing it on a case-by-case basis is fine, that doesn't mean we have to make it bigger altogether. —CodeCat 01:21, 9 April 2014 (UTC)

“Normal” Latin represents a minority of our Latin, much less other scripts, IPA, and transliterations. Basically, we are making 90% of the site’s text bigger in dribs and drabs. May as well make all text bigger and about six languages smaller then.

Varying font sizes leads to inconsistent line heights, font sizes, and harms readability. And looks like pants. —Michael Z. 2014-04-10 00:23 z

We have standard templates for prefix, suffix, etc. Should we have one for words formed by spelling another word backwards? They are quite rare, but I've seen some electrical units of measure (yrneh, daraf, mho), the female name Nevaeh, the slang words riah and tink, and the fictional Erewhon (we have Erewhonian). Equinox ◑ 15:16, 9 April 2014 (UTC)

I don't think this is common enough to need a template. All templates do is save time when writing the same thing over and over. --WikiTiki89 15:22, 9 April 2014 (UTC)

They also create categories, so it would allow all such words to be viewed as a group. Equinox ◑ 15:23, 9 April 2014 (UTC)

They don't magically "create" categories. They just add the category to the page automatically, which can be done manually as well:

===Etymology===

Backwards spelling of {{term/t|en|oof}}.]

--WikiTiki89 15:31, 9 April 2014 (UTC)

We do etymologies for them as you will see in yob and yobbo. —Stephen ^(Talk) 04:49, 10 April 2014 (UTC)

• I think there may be enough to justify a template. There may also be enough for etymology based on anagrams of other words Purplebackpack89 ^{(Notes Taken) (Locker)} 03:35, 14 April 2014 (UTC)
  • Hardly. I'd like to see a list of candidates first. Also, backwards spellings are a subset of anagrams. —CodeCat 03:37, 14 April 2014 (UTC)

...rather than the infinitive? I know this is standard but I have no idea about the reasoning behind it. Equinox ◑ 20:11, 9 April 2014 (UTC)

You could also ask why do we use the infinitive for most other languages? --WikiTiki89 21:14, 9 April 2014 (UTC)

In English you can generally produce the person inflections from the infinitive (walk+s, walk+ing, walk+ed), so the infinitive "feels like" the base form. Is it totally arbitrary? Equinox ◑ 21:16, 9 April 2014 (UTC)

The infinitive is not the base form in most languages. For many Indo-European languages, the base form is the first- or third-person singular, or the second-person singular imperative. I think what matters for Latin is that it's the first of the four principal parts of a Latin verb. —CodeCat 21:18, 9 April 2014 (UTC)

But what makes it the "first" of the four principal parts? --WikiTiki89 21:26, 9 April 2014 (UTC)

Tradition, probably. —CodeCat 21:37, 9 April 2014 (UTC)

No, tradition explains why it still is, but not why it originally was. --WikiTiki89 21:39, 9 April 2014 (UTC)

Freund, Andrew, Lewis, and Short did Latin verbs that way. I don't know what earlier lexicographers of Latin did. Perhaps there are fewer homonyms in Latin if one uses the first person as the lemma. DCDuring TALK 22:18, 9 April 2014 (UTC)

The Romans themselves had some grammatical traditions, too. And presumably medieval scribes as well. What did they use? —CodeCat 22:23, 9 April 2014 (UTC)

Donatus's Ars Minor (4th century) seems to view the first person singular present as the lemma. —Mr. Granger (talk • contribs) 00:21, 11 April 2014 (UTC)

In fact, Lewis, and Short defined Latin verbs using English infinitive. And Equinox asks "Why are Latin verbs defined in first person". --Dan Polansky (talk) 08:13, 12 April 2014 (UTC)

Here is a past discussion on this:

• Wiktionary:Tea_room/2009/November#nāscor, 6198 words
• Wiktionary:Votes/pl-2009-12/Definition layout, a vote spawned by that discussion
• Wiktionary talk:Votes/pl-2009-12/Definition layout, 3467 words

--Dan Polansky (talk) 08:30, 12 April 2014 (UTC)

Personally I think defining it using the infinitive would be more useful, for etymologies in particular, but also because it matches how we categorise verbs by conjugation (Latin conjugations follow the infinitive). I don't think it's necessary enough to change what we have, though. —CodeCat 12:57, 12 April 2014 (UTC)

There doesn't seem to be a standard for choosing the next number in an ordinalbox.

Most languages I've poked at seem to just give up once the question gets tricky.

For example, if the next number after 30 is 31, and there's not a separate word for 31, you get a dead link and the utility of the ordinalbox is greatly diminished.

My proposal is that these boxes always point to the previous and next numbers for which there is a word.

English would have all the number through 20, then 30, 40, ... 90. Then do we stop, or link next to "hundred" which is not quite a cardinal number?

In Latin, one would count ..., 11, 12, 18, 19, 20, 28, 29 30, 38, 39, 40, ...

I will admit it's not a great solution, but I can't find a better one.

Any suggestions? Avjewe (talk) 17:17, 10 April 2014 (UTC)

Many of these have already been deleted, as they weren't used by anything. We have Lua-based alternatives now like {{lang}}, and even the non-Lua-based {{script helper}}, which all script code templates already invoke. I've been working on converting out the remainder, but I want to make sure everyone is ok with it before I start deleting (formerly) widely used templates like {{Latn}}. —CodeCat 18:54, 11 April 2014 (UTC)

Maybe, but you've been breaking things in the process of orphaning them because you apparently didn't think everything through. That's not a good way to do things. Chuck Entz (talk) 23:13, 12 April 2014 (UTC)

What did I break? —CodeCat 23:43, 12 April 2014 (UTC)

Well, for one thing you ever so slightly broke {{grc-conj-aorist-blank-am}}. Mind you, it was an easy fix, and I definitely still support abandoning the old templates and converting to Lua, but you asked.  :-) -Atelaes λάλει ἐμοί 00:01, 13 April 2014 (UTC)

I see what you did, but I'm not sure how that fixed anything. Or rather, I don't see what was wrong with my original change. —CodeCat 00:09, 13 April 2014 (UTC)

Well, to be completely honest, I don't fully understand what happened myself, and perhaps I should have investigated the matter further, but I didn't. If you preview οἰδέω (oidéō) with your version, you'll notice that, since transliterations weren't suppressed, they were produced, and produced rather oddly. The only thing I can think of is that, given multiple linked targets as the primary input into {{term/t}}, the auto-transliterate engine had some sort of spasm and included line breaks in its output for some reason. I imagine that simply suppressing the transliteration would have fixed it equally well, but I modeled my version after one of the similar templates. -Atelaes λάλει ἐμοί 00:19, 13 April 2014 (UTC)

I fixed it. The problem was really in {{grc-conj-aorist-1}}, which had a long string of unnamed parameters, but there were no comment tags around the line breaks. The wiki software doesn't strip whitespace (including line breaks) in unnamed parameters, only in named parameters. I added comment tags around the line breaks, and I also added in the names of the parameters. The latter wasn't necessary to fix the problem, but it helps with future maintainability, because I had a hard time figuring out just which of those parameters was number 105! —CodeCat 00:34, 13 April 2014 (UTC)

I've reverted your latest. The switch to commented-separated numbered parameters was a good one. It will definitely make understanding and maintaining the template easier. However, your switch to {{term/t}} is still not workable. For starters, it still breaks entries, ἄγω (ágō) for example, possibly because we still have line-breaks in the other templates which feed into the blanks. Additionally, I don't want transliterations in there; we're already jamming a lot of info into a fairly compact space, and the transliterations just make it that much trickier to parse. Now, perhaps {{term/t}} with suppressed transliteration might work, but I suspect we'd have to do it for all the templates, so they'd look uniform. I don't feel like doing that kind of overhaul at the moment. -Atelaes λάλει ἐμοί 02:04, 13 April 2014 (UTC)

Microsoft stopped supporting MSIE 6 on Tuesday. I can’t believe I forgot to stop and dance a little jig on its fresh grave.

Microsoft is celebrating with a little treat. —Michael Z. 2014-04-11 22:43 z

Windows 95 was better... --WikiTiki89 02:59, 12 April 2014 (UTC)

• No no no, Windows RG was hands-down the best there ever was. ‑‑ Eiríkr Útlendi │ Tala við mig 03:17, 12 April 2014 (UTC)
  • I am not a huge fan of Windows, but I liked the CEMeNT edition. — Keφr 04:49, 12 April 2014 (UTC)
    • That's pretty brilliant. FWIW, the real-life misbranding of WinCE always made me chuckle, too. And even the modern Windows 8.1 has given rise to certain amusing developments. ‑‑ Eiríkr Útlendi │ Tala við mig 06:28, 12 April 2014 (UTC)

• And I guess the implied question is whether we should drop support for it too? I would rather take a look at market share numbers before answering that. And even then I would be hesitant to answer "yes". We might have some users stuck with it. — Keφr 04:49, 12 April 2014 (UTC)
  • We already don't support it in a lot of areas. We should drop support for it completely. It may be harsh to those few who still use it, but... IE 6 is harsh on anyone no matter who you are. And of course, anyone who still uses it nowadays should be used to things breaking, so it's not going to make much of a difference if we add Wiktionary to that long list. —CodeCat 13:00, 12 April 2014 (UTC)

For perspective, MSIE 6 accounted for 0.24% (1/400) or of all requests, and 0.99% (1/100) of page requests in WikiMedia sites in February. It has 1% usage share in most of the world. It was supported by MediaWiki as a “grade B” browser for reading only, up to May 2013, which meant “support is not guaranteed” and “issues ... might not be resolved.” The Universal Language Selector is not compatible with MSIE 6 or 7. The Visual Editor doesn’t support it for both technical reasons and resource issues.

These levels of support can only be lowered or eliminated now that even its creators refuse to vouch for the browser working at all.

Our framework for providing multilingual fonts is now partly dependent on the ULS. No one tests any of our script classes or javascripts in MSIE 6. When is the last time a reader or editor has asked for MSIE 6 support? en.Wiktionary effectively hasn’t supported this browser for years.

User:Kephir, I don’t think that question is implied at all, unless someone here wants to volunteer hundreds of hours to add support for this completely obsolete browser. I am just pointing out that we can stop paying lip service to the pretence that we support it in any way. —Michael Z. 2014-04-21 15:42 z

Could an admin please deal with the edit request at Template talk:ko-inline? I'm not sure what templates I should be using to call attention from admins so I thought I'd just post it here. Thanks. Wyang (talk) 22:01, 12 April 2014 (UTC)

Thanks, Anatoli. Wyang (talk) 00:17, 14 April 2014 (UTC)

No worries. --Anatoli ^{(обсудить}/^вклад) 00:27, 14 April 2014 (UTC)

Please check for any bugs while I will start to automate all the Latin pronunciation using the module that I just built yesterday. (First module ever built woohoo :D) --kc_kennylau (talk) 03:06, 13 April 2014 (UTC)

Looks good, but is there anything in place to deal with majuscules? I'm not seeing any lowercasing. Also, it's utterly unfair that your language is almost IPA without any conversion. That is all. -Atelaes λάλει ἐμοί 03:32, 13 April 2014 (UTC)

Does it give the lax pronunciation of the short vowels? Short e, i, o, u should be /ɛ, ɪ, ɔ, ʊ/. Does it treat vowel + nasal sequences as nasalized vowels before fricatives and at the end of a word? dēfensum should be /deːˈfẽːsʊ̃/. Does it geminate intervocalic nonsyllabic i? māior should be /ˈmajjɔr/ (or /ˈmaɪjɔr/) and cuius should be /ˈkʊjjʊs/ (or /ˈkʊɪjʊs/). Does it generate Ecclesiastical pronunciations or only Classical pronunciations? —Aɴɢʀ (talk) 05:41, 13 April 2014 (UTC)

We don't actually know if short vowels were indeed lax, and as far as I know, it has been our practice on Wiktionary to only distinguish their length and not their quality. --WikiTiki89 14:24, 13 April 2014 (UTC)

The evidence from historical phonology is clear that they must have been; see my comments below dated 11:52, 13 April 2014. Since we indicate both length and quality differences like /iː/ vs. /ɪ/ in other languages such as English (RP) and German, there's no reason not to do so for Latin. —Aɴɢʀ (talk) 15:42, 13 April 2014 (UTC)

Now I'm hurt that you weren't utterly dissatisfied with {{grc-pron}}. -Atelaes λάλει ἐμοί 06:15, 13 April 2014 (UTC)

I wasn't? —Aɴɢʀ (talk) 07:15, 13 April 2014 (UTC)

You weren't. -Atelaes λάλει ἐμοί 07:39, 13 April 2014 (UTC)

Oh, the new one! I forgot all about that. I mean I really forgot all about it. I recently added pronunciation info to ἰτέα using the old template instead of the new one; I'll go change it now and see what I think. —Aɴɢʀ (talk) 07:56, 13 April 2014 (UTC)

Thanks for all this feedback. I hadn't started the automation yet since I hadn't got time, but I would like to ask one question: would the vowel still be nasalized if it's long? --kc_kennylau (talk) 10:57, 13 April 2014 (UTC) And I don't see any other page turning e,i,o,u to the IPA pronunciation, so should I break the convention? --kc_kennylau (talk) 11:01, 13 April 2014 (UTC) Why was the nasalized e long in your example? --kc_kennylau (talk) 11:08, 13 April 2014 (UTC)

Nasalized vowels before s and f are always long; our page says dēfensum but it should actually be dēfēnsum, and monstrum should actually say mōnstrum in the headword line. We don't seem to be very consistent about that. And I see that Appendix:Latin pronunciation doesn't transcribe the short vowels as lax, but w:Latin spelling and pronunciation#Vowels does (though inconsistently). A lot of people don't bother showing the distinction since traditional Latin grammar makes the length distinction primary, but the Vulgar Latin mergers of ĭ with ē and of ŭ with ō only make sense if ĭ and ŭ were /ɪ/ and /ʊ/ rather than /i/ and /u/, and the fact that ĕ and ŏ avoid that merger only makes sense if they were /ɛ/ and /ɔ/ rather than /e/ and /o/. We know the nasalized vowels were long because of the way they developed in Romance: īnsula and mēnsa develop exactly as if they were īsula and mēsa and not as if they were ĭsula and mĕsa. —Aɴɢʀ (talk) 11:52, 13 April 2014 (UTC)

You can't use Vulgar Latin as evidence of Classical Latin vowel quality. You have proven that at some point before Vulgar Latin, ĭ and ŭ were pronounced /ɪ/ and /ʊ/, but this point may have been after Classical Latin. We also don't know when the change from /ens/ to /ẽːs/ took place (or maybe we do, but you have not given any evidence for it). From what I have read, the fact that in Classical Latin the -um ending did not have an /m/ (or at least had a very light one) and maybe had a nasalized vowel, is only known because of the meter of such words in Classical poetry (i.e. the syllable merges with a following vowel). Using Vulgar Latin alone as evidence would not have been enough. --WikiTiki89 15:58, 13 April 2014 (UTC)

There isn't a time difference between Classical Latin and Vulgar Latin. When Caesar and Cicero were sitting around chatting with their friends over a glass of wine, they were speaking Vulgar Latin and were certainly pronouncing their short vowels lax and nasalizing their vowels before their fricatives. —Aɴɢʀ (talk) 16:21, 13 April 2014 (UTC)

Sorry, I was making the mistake Wikipedia mentions of confusing Vulgar Latin with Late Latin/Proto-Romance. w:Vulgar Latin#Sources lists four types of sources of information about Vulgar Latin, the first and third of which don't really apply to Classical Latin. I was under the impression that we know about the mergers of ĭ with ē and ŭ with ō from reconstructing Proto-Romance, but I may be wrong, which others of the four types of sources Wikipedia lists has evidence of this? --WikiTiki89 16:34, 13 April 2014 (UTC)

Off the top of my head, I don't know, but I'm sure many of the sources listed in the Wikipedia article could tell you. Incidentally, the first source (solecisms) does apply to Classical-era Latin; for example, the graffiti found at Pompeii is full of spelling mistakes that tell us a lot about how the colloquial language was pronounced, and AD 79 isn't "Late Latin", though it's somewhat later than C & C, of course. I don't know offhand whether this particular pronunciation is one of the things those inscriptions tells us, though. —Aɴɢʀ (talk) 16:50, 13 April 2014 (UTC)

Well until such evidence turns up on Wiktionary, I think we should continue transcribing short vowels as /a e i o u/. --WikiTiki89 17:00, 13 April 2014 (UTC)

I think the Romans themselves also marked the vowel length sometimes, so that's another way we can tell. And in case it wasn't clear, what appears to us as lengthening before nasal + fricative is actually the nasalisation process itself occurring. So, when the written form transitions from -ens- to -ēns-, that's actually an indication that the spoken form changed from to . The length is compensatory for the loss of the nasal. —CodeCat 13:01, 13 April 2014 (UTC)

So the current pronunciation transcription in insula and mensa are wrong? --kc_kennylau (talk) 13:32, 13 April 2014 (UTC)

It depends on what you call "wrong". It's correct in a purely phonemic way, as the nasalisation was just allophonic. In the same way, the difference between and was allophonic; the former appeared when long, the latter when short. And final -m also caused nasalisation, but also at an allophonic level. So it depends on how much phonetic detail we want to show. Most of our current pronunciations are purely phonemic and show no nasalisation or differences in vowel height. —CodeCat 13:52, 13 April 2014 (UTC)

As for me, I fancy detailed phonetic transcriptions. There are more symbols I don't understand, so it's funnier! (btw: I've added the macrons in monstrum. I don't know if it's possible to get a list of all entries in which there are lacking?) --Fsojic (talk) 14:04, 13 April 2014 (UTC)

For what it's worth, I prefer phonemic transcriptions (for dead languages like Latin, I mean). I guess we could always give both though, as in IPA^(key): /ˈho.moː/, replace ' with ˈ, invalid IPA characters ('). —Mr. Granger (talk • contribs) 15:43, 13 April 2014 (UTC)

I prefer a balance between broad and narrow transcriptions. To use an English example, a word like keeping ought IMO to be transcribed /ˈkiːpɪŋ/, neither the purely phonemic /ˈkiːpinɡ/ nor the narrowly phonetic . —Aɴɢʀ (talk) 15:49, 13 April 2014 (UTC)

How do you decide which traits you want to display? I mean, you could as well have /ˈkʰiːpiŋ/ as a middle ground option. --Fsojic (talk) 15:58, 13 April 2014 (UTC)

Good question. For languages like English and German where there's a strong history of phonetic transcriptions in dictionaries, it's easy to follow the example of others (though this changes over time -- nowadays most dictionaries and phoneticians transcribe English heat~hit as /hiːt/~/hɪt/ and German biete~bitte as /biːtə/~/bɪtə/ but 75 years ago or so that would have been /hiːt/~/hit/ and /biːtə/~/bitə/, but the actual pronunciations haven't changed). Latin unfortunately doesn't have that history, so we have to make it up as we go along, discussing amongst ourselves what we think the most important aspects to transliterate are. Which is what we're doing now :) ! —Aɴɢʀ (talk) 16:21, 13 April 2014 (UTC)

Right, but I don't see the point of choosing this middle ground, partially accurate option, when we could just have a broad, phonemic transcription, and a narrow, phonetic one. If you include meaningless phonetic variations in a phonemic transcription, isn't it wrong? And in the case of English or German, why should we follow tradition, if our predecessors didn't motivate their choices? (I suppose they did, but I'm curious of knowing a bit more about it) --Fsojic (talk) 15:45, 15 April 2014 (UTC)

So what are we going to display? I'll start the automation as soon as I have time, and when we have a consensus, I will alter the code accordingly. --kc_kennylau (talk) 12:35, 15 April 2014 (UTC)

How would we know if an "i" in a word is a consonant or a vowel? Like I want to know the pronunciation of abiungo without looking at its etymology and stuff. --kc_kennylau (talk)

I don't think there is a way to tell. And I think that the current pronunciation of abiungo may be wrong, because it doesn't have /j/ like iungo does. —CodeCat 16:14, 15 April 2014 (UTC)

How can I know whether or not when ab- and iungo combines, the "i" becomes a vowel? --kc_kennylau (talk) 16:18, 15 April 2014 (UTC)

It doesn't. abiungō is /ab.ˈjʊŋ.ɡoː/, while abiēs is /ˈa.bi.eːs/. You have to know the morphology of the words: abiungō has a prefix ab- and a root iungō, and abiēs is a simple stem. —Aɴɢʀ (talk) 18:33, 15 April 2014 (UTC)

By the way, please tell the module to use ɡ (U+0261) rather than g (U+0067) in IPA transcriptions. —Aɴɢʀ (talk) 18:41, 15 April 2014 (UTC)

Would you happen to know the etymology of -ies by any chance? —CodeCat 18:38, 15 April 2014 (UTC)

No, sorry. Abiēs doesn't have it, though, anyway, since it's third declension, not fifth. —Aɴɢʀ (talk) 18:46, 15 April 2014 (UTC)

The way to force nonsyllabic i after a consonant is simply to use "j" in the parameter that we're already using to mark vowel length. So while {{la-pronunc|abiungō}} produces the wrong result, {{la-pronunc|abjungō}} produces the right one. However, I notice that it transcribes the n as /n/, but before g it should be /ŋ/. —Aɴɢʀ (talk) 07:54, 16 April 2014 (UTC)

Another problem: {{la-pronunc|suāvis}} and {{la-pronunc|svāvis}} both render as (Classical Latin) IPA^(key): /suˈaː.u̯is/,

• (modern Italianate Ecclesiastical) IPA^(key): /suˈa.vis/, , but it should be IPA^(key): /ˈswaːwis/. —Aɴɢʀ (talk) 09:42, 16 April 2014 (UTC)

See fingo and tingo. I had struggled before removing the ng rule out of the module, but well I think this is the consensus (or is it?). --kc_kennylau (talk) 09:44, 16 April 2014 (UTC)

I don't think svavis is a word. --kc_kennylau (talk) 09:46, 16 April 2014 (UTC)

But how do you know that it doesn't change to a vowel? Like is there any evidence or what? --kc_kennylau (talk) 09:49, 16 April 2014 (UTC)

In Latin, 'v' and 'u' were different forms of the same grapheme. As late as Shakespearean English, the two were positional variants. ('v' for word initial, 'u' for medial and final, regardless of phonetic value. Thus the line in Bacon: "vast void vniuerse".) So a literate Roman would be wondering why we even had two glyphs for it. In current practice, we use 'u' for the vowel, and 'v' for the consonental use. In suavis, they're both consonental. Basically, 'uV' = /wV/, 'uC' = /uC/; 'iV' = 'jV', 'iC' = /iC/. (A bit more complicated in the case of words like cuius, and I'm sure Angr and others can improve the algorithm.) --Catsidhe ^{(verba, facta)} 10:15, 16 April 2014 (UTC)

Unfortunately, it's more complicated than that. You can't always tell whether a u/v is syllabic or not, and there are even minimal pairs like seruit (“he joined”) vs. servit (“he serves”) and voluit (“he wanted”) vs. volvit (“he rolls”). That's probably why the u~v distinction is maintained in modern Latin writing, while the i~j distinction (which is much more predictable) is usually not made. As for /ŋ/, the module currently converts /n/ to /ŋ/ before /k/ but not before /kʷ/ and /ɡ/, which is silly. If fingō and tingō are transcribed with /n/, it's because someone was thinking of abstract phonemes rather than surface sounds. If that's the way we want to go, fine, but then to be consistent we also have to transcribe vincō with /n/. It makes no sense to use /ŋ/ in vincō but /n/ in fingō and relinquō. But I see that {{la-pronunc|suāvis}} now gives (Classical Latin) IPA^(key): /suˈaː.u̯is/,

• (modern Italianate Ecclesiastical) IPA^(key): /suˈa.vis/, while {{la-pronunc|svāvis}} gives (Classical Latin) IPA^(key): /ˈsu̯aː.u̯is/,
• (modern Italianate Ecclesiastical) IPA^(key): /ˈswa.vis/, , so we can use the latter for words where u after s is /w/. This isn't predictable either (unless you know the morphology): while suāvis, suādeō, and suēscō all have /sw-/, the inflected forms of sūs all have /su-/, as does suus and its inflected forms. I don't even know whether suīle, suillus, and suīnus have /sw-/ or /su-/. One more thing: if we're going to use /i e o u/ for the short vowels rather than /ɪ ʊ ɛ ɔ/, then for consistency we should be using /y/ rather than /ʏ/ as well. It makes no sense to use /i e o u ʏ/. —Aɴɢʀ (talk) 14:38, 16 April 2014 (UTC)

Another question. Accentuation. I don't know if this edit is correct. --kc_kennylau (talk) 14:43, 16 April 2014 (UTC)

I think so, yes. —Aɴɢʀ (talk) 14:54, 16 April 2014 (UTC)

I posted in the information desk about the inconsistencies on how Latin was being transcribed here and on Wikipedia and was directed to this discussion. I am new here and wouldn't consider myself an expert by any means on the subject but am catching up on the discussion so far and adding my two humble cents.

• Phonemic and/or phonetic transcriptions – I liked the idea of doing both that Fsojic mentioned; however if we really want a phonetic transcription, we would also have to take into consideration l pinguis, l exīlis, sonus medius, and realizing /kʷ/ as before front vowels. We’d also need to decide on a pronunciation of /r/ ( or ), and if we’re going to make /e/ more open before /r/. It would be more difficult to automate.
• Consonantal I and V – As it is not predictable unless one knows the morphology or etymology of the word, can we just make it up to the editor to always enter the vowels as ‘i’ and ‘u’ and consonants as ‘j’ and ‘v’ even if the word itself is not traditionally spelled that way (e.g. SVAVIS)? It's not like the typical user is going to look at the code and see the strange spelling being used for the module. The module could then allow for situations where Latin doesn’t follow some of the automated rules (e.g. “iambus” and “Gaius” according to Lewis and Short). I would still keep the automation of medial ‘j’ becoming ‘jj.’
• How to represent short vowels - /a, e, i, o, u, y/ or /a, ɛ, ɪ, ɔ, ʊ, ʏ/. I favor the latter, but it looks like most of Wikipedia has the former. Maybe put it to a vote?
• – Either we need to get rid of it and treat it as an allophone of /n/ before velars and an allophone of /g/ before /n/ or we need to consistently use it in the transcriptions. I favor the latter, especially if we’re keeping the nasal vowels in the transcriptions.

I was also curious about Aɴɢʀ's thoughts on treating z as two consonants. --Brentypie (talk) 06:58, 17 April 2014 (UTC)

And Aɴɢʀ's thoughts on treating the new /sw/ sound as a single letter, as it looks like it was treated that way in scanning poetry. (see malesuada, (Verg. A. 6.276)). --Brentypie (talk) 07:12, 17 April 2014 (UTC)

Mostly I think the above comments make it more important for us to focus on a phonemic transliteration if it's going to be automated, since so many phonetic details are unknown (such as the exact quality of the sonus medius and the distribution of vs. ). I do think we should transliterate z as /dz/. I do not think we should transliterate /sw/ as a single sound; stop + liquid sequences don't necessarily make position in poetry either, but that just means they were syllabified as onset clusters, not that they were single segments. Incidentally I've corrected the link in Brentypie's message of 06:58, 17 April. —Aɴɢʀ (talk) 06:57, 18 April 2014 (UTC)

If we have to transliterate z as /dz/ which is actually one consonant, shall we treat it as one consonant or two in syllable division? --kc_kennylau (talk) 10:25, 18 April 2014 (UTC)

I've noticed that occasionally, reconstructed terms appear in the list of cognates of some entry. In particular, I've seen Proto-Slavic reconstructions appear as cognates, but there are a few with Proto-Germanic cognates too. I'm wondering whether this is ok. On one side, it seems a bit wrong to include unattested terms as cognates. But on the other side, it's very convenient if we can list the reconstructed ancestor as a stand-in for its descendants. Slavic words often don't differ too much from their Proto-Slavic origin, so showing a Proto-Slavic cognate is probably a concise way to indicate that all Slavic words are cognates, without having to list them all or having to choose which to list. —CodeCat 22:24, 14 April 2014 (UTC)

I guess I don't have any specific arguments for or against, but I like to cite proto-Germanic terms as cognates, when we have an entry for them. -Atelaes λάλει ἐμοί 04:29, 15 April 2014 (UTC)

Reconstructions are abstractions- my guess is that they mean very little to anyone who hasn't studied the history of their language groups. I'm not against using them, but they should be accompanied by a descendant or two to ground them in reality. The problem is, of course, that nobody wants their language to be left out. If you list Swedish as a cognate and leave it alone for a minute, suddenly Danish, Norwegian, Faroese and Icelandic are right there with it. Chuck Entz (talk) 06:51, 15 April 2014 (UTC)

• See how friendly all these words are? They didn't want the Swedish to get lonely. ‑‑ Eiríkr Útlendi │ Tala við mig 07:08, 15 April 2014 (UTC)

I list reconstructed terms as cognates too, though I prefer to list an attested form from Old Church Slavonic instead of Proto-Slavic or Gothic or Old English instead of Proto-Germanic if those words are attested. But if they're not, then using the proto-form is a good shorthand for all the attested modern forms. I would be more inclined to do it for proto-languages whose reconstructions are pretty solid (like Slavic and Germanic) than for those whose reconstructions are themselves kind of shaky (like Celtic and Italic). —Aɴɢʀ (talk) 15:17, 16 April 2014 (UTC)

I don't think reconstructions for Celtic or Italic are any less solid, because the sound changes are still well-known and understood for the most part. What is lacking in those branches is a wide array of languages to use as a base for reconstructions, but that doesn't have to be a problem. In some cases, even just one descendant is enough to solidly reconstruct a term, if it can be regularly derived from a known PIE reconstruction that is itself solid. The principle is that you know two end points, and the rules that derive one from the other are known as well, so the intermediate proto-language is a matter of tying the two ends together in the middle. —CodeCat 15:31, 16 April 2014 (UTC)

There are Proto-Celtic reconstructions that are very solid, but the percentage of them that are very solid is much lower than in Proto-Slavic. Reconstructing PSl. is fairly easy not just because of the large number of attested languages but because of the relatively few and relatively transparent sound changes that have happened between the proto-language and the attested descendants. Hell, the number of changes you have to make to PSl. to get OCS can be counted on one hand. That means PSl. has an enormous, very securely reconstructed vocabulary – even for words with no known cognates outside Slavic. We could never do for Proto-Celtic what we've done at Appendix:List of Proto-Slavic nouns (and its subpages), Appendix:List of Proto-Slavic adjectives, Appendix:List of Proto-Slavic verbs, and so on; the lists would either be full of question marks or would have only a handful of entries each. —Aɴɢʀ (talk) 16:11, 16 April 2014 (UTC)

That's more a matter of time depth though. Of course the further you need to go back from the attested languages, the more the changes are going to compound, and the more things will end up being in an unexplained "dark era". But Germanic certainly has plenty of questions as well, it's not as secure as you think. The general idea is clear, but there are still many specific matters like the class 3 weak verbs, or the curious mixing of masculine and neuter a-stem cognates, that are not at all settled yet. —CodeCat 16:36, 16 April 2014 (UTC)

Entries in Category:Mandarin pinyin with tone numbers are duplication of contents in monosyllabic toned pinyin entries. Many of them contain a large number of characters. Even though they have no definitions, they need to be checked for accuracy and maintained. I suggest to convert each entry to the toned pinyin entry a1 -> ā, which also has Zhuyin ㄚ and editors' support. If someone still has problems, especially certain IP-users, like Special:Contributions/204.11.189.94, they can still find the characters they are looking for. Please understand the duplication and maintenance issues. We have few resources and there's NO information loss. If there was any vote, discussion related to keeping this type of entries, please post here. {{look}}

• Support redirect Mandarin pinyin with tone numbers to Mandarin pinyin with tone marks. --Anatoli ^{(обсудить}/^вклад) 22:45, 16 April 2014 (UTC)

Example: cheng2 (before) cheng2 (after) -> chéng. All information contained in "before" version of cheng2 is duplicated in chéng. --Anatoli ^{(обсудить}/^вклад) 23:38, 16 April 2014 (UTC)

• Makes sense to me, and sounds like a net gain in usability -- tone marks are harder to type than numbers, at least using a US keyboard, so redirecting as described would make sense.

Question -- are there ever any cases where a pinyin + number term might exist for any language other than Chinese? ‑‑ Eiríkr Útlendi │ Tala við mig 23:54, 18 April 2014 (UTC)

Yes. See beng2, for example, which is also a Cantonese transliteration. —Mr. Granger (talk • contribs) 14:18, 19 April 2014 (UTC)

Thanks for reminding me. Something like beng2, dou1. Not sure about the final format. Definitely, there should be no duplication and there should be a link to toned pinyin. There may be still use for template {{cmn-alt-pinyin}}. --Anatoli ^{(обсудить}/^вклад) 07:59, 20 April 2014 (UTC)

• I oppose and point to Wiktionary:Votes/pl-2009-12/Treatment of toneless pinyin syllables. --Dan Polansky (talk) 11:25, 19 April 2014 (UTC)

• @Dan Polansky The old vote was about things like wo, with no tone marks and no numbers. Such markless numberless pinyin is hard to correlate with anything. This current thread is about things like wo3, with no tone marks but with numbers. The numbered versions are one-to-one correlatable with the tone-marked spellings. As such, I think the old vote and the current thread are substantively different, and should be treated differently. ‑‑ Eiríkr Útlendi │ Tala við mig 18:03, 19 April 2014 (UTC)

That's right. It's a different issue. The two types of entries in this discussion contain duplicate info. --Anatoli ^{(обсудить}/^вклад) 07:59, 20 April 2014 (UTC)

It's a different yet related issue. You already proceeded with placing the redirects, starting on 18 April, e.g. in diff, diff, and diff. Let me note for those lacking the background that, in the vote, Anatoli supported this option: "Do not include toneless pinyin syllables at all". If you cannot get your way in a proper and civilized way, there is still the force option, isn't it. --Dan Polansky (talk) 08:23, 20 April 2014 (UTC)

• @Dan Polansky again, I think you're misunderstanding what this thread is about. Toneless pinyin would be things like wo. The vote you linked to was about that, and the community decided not to allow such entries. The issue in this thread is things like wo3, which has tone, just not marked in the "official" pinyin fashion. These entries are currently permitted by the previous vote, as I read it. This thread in which I'm typing is attempting to find a policy direction for how to handle these entries in a way that 1) has decent usability from a reader's standpoint, in terms of finding things, and 2) is easily maintainable from an editor's standpoint, in terms of not having to duplicate info, and then manage duplicated and possibly accidentally divergent info, on different pages that should otherwise be identical. ‑‑ Eiríkr Útlendi │ Tala við mig 17:54, 20 April 2014 (UTC)

@Dan Polansky Could you explain why we need to keep those entries. What is the benefit of having entries like guo2, cha4, dang1? Yes, I have deleted those entries and one example is displayed here as an example. Not sure what sort of crime you're exposing me of. :)

Multisyllabic numbered pinyin entries were explicitly banned. The remaining monosyllabic are left because there is generally little enthusiasm dealing with single-characters, even including vandals like abc123, etc. There are in a big mess, largely due to the lack of consensus whether the definitions should go into Translingual or repeated in each CJKV section under Hanzi/Kanji, etc. I've been working with single-character hanzi and pinyin entries. There are currently the following issues:

1. Monosyllabic pinyin are not standardised and out of sync with Han entries. E.g. they should display simplified/traditional Han character variants on one line, not on separate lines, as they are pairs.
2. There are many cases when a Mandarin reading is taken from the Unihan database, which can't be confirmed with any other dictionary. There can be obscure or obsolete readings but those readings are not present in the character entries.
3. New Han character entries are regularly requested on Chinese request page. When a new entry or a new reading is added, the pinyin entries should be added, updated.
4. Pinyin entries not only serve as indices but also as lists of homophones, which can hopefully be used in Mandarin enrties as well.
5. Some Chinese-aware editors don't work with Pinyin entries at all, for various reasons and would prefer to get rid of pinyin entries altogether. The main one being - they are not a proper native script. So, it's only a few of us who still want to do this job.

All these make maintaining two sets of pinyin entries complicated. I really think numbered pinyin entries are unnecessary burden. I think pinyin entries can be made much more useful if we only have to work with one set. --Anatoli ^{(обсудить}/^вклад) 00:38, 22 April 2014 (UTC)

• Oppose. If this is solely about avoiding duplication, we may as well redirect labour and colour to labor and color, or get rid of all alternative spellings that share the same pronunciation. Strip them down, if you wish, to "alternative spelling of" entries, but these are part of "all words in all languages". bd2412 T 12:19, 22 April 2014 (UTC)

  The only reason we don't redirect labour and colour to labor and color is to avoid having to choose sides. This does not apply here since clearly the proper pinyin is preferable to improper pinyin. --WikiTiki89 12:29, 22 April 2014 (UTC)

  That's not the only reason we don't redirect one of "labo(u)r" and "colo(u)r" to the other. We also don't do it because labor, labour, color, and colour are also words in other languages besides English. It may not happen very often that other languages have words that include numerals in them, but it can't be ruled out (jiu4 is also a word of Cantonese as well as a word of Mandarin; a1 is also a word of English. Like BD2412, I have no objection to reducing these to {{alternative spelling of}}'s, but I can't get behind hard redirects, even in cases where Mandarin is the only language to use a particular spelling. —Aɴɢʀ (talk) 13:00, 22 April 2014 (UTC)

  Sorry, I assumed soft redirect was meant (I guess I should have RTFD). --WikiTiki89 13:06, 22 April 2014 (UTC)

We can discuss a soft redirect as another option, e.g. for tiao2 to have a definition line as See tiáo. I suggested this format above for entries where it's not only Pinyin but something else, e.g. beng2. --Anatoli ^{(обсудить}/^вклад) 13:27, 22 April 2014 (UTC)

Why have a soft redirect (which will merely say that we don't have an entry on this topic, try this other one), when we can provide more information at no extra inconvenience to the reader with an {{alternative spelling of}} template? I'd be all for the latter option. Also, these are not "improper" pinyin, they are a once-widely used alternative form of pinyin. bd2412 T 13:59, 22 April 2014 (UTC)

{{alternative spelling of}} is a soft redirect. --WikiTiki89 14:18, 22 April 2014 (UTC)

I thought a soft redirect was something like this. bd2412 T 14:42, 22 April 2014 (UTC)

They are both soft redirects; the point is that they avoid repeating content. --WikiTiki89 14:51, 22 April 2014 (UTC)

Would one-liner {{alternative spelling of|tiáo}} be more acceptable, with all Hanzi links on tiáo or a new soft-redirect template for numbered pinyin? The alternative forms with numbers were used because of the input and display limitations, the same way Germans used ss, ae, oe and ue instead of ß, ä, ö and ü in telegrams. The numbered pinyin entries also lack "ü" replaced with "v" in the past, it should be "nv3" instead of nü3, this is how Pinyin nǚ was actually represented using numbered Pinyin. --Anatoli ^{(обсудить}/^вклад) 14:16, 22 April 2014 (UTC)

I would prefer to see the existing {{alternative spelling of|tiáo}} used. I hadn't seen substitution of "v" for "ü" before, but if it exists it should definitely be added. I think that numbered pinyin using "ü" may also exist. bd2412 T 20:44, 24 April 2014 (UTC)

MediaWiki:Wikimedia-copyright: Please update the license title to Creative Commons Attribution-ShareAlike License. It is currently like this: "Attribution/Share-Alike". See the official website here: https://creativecommons.org/licenses/by-sa/3.0/ . Also see m:MediaWiki talk:Wikimedia-copyright. Sorry if this is the wrong place but I couldn't find a more suitable place for edit requests. Thanks, --Glaisher (talk) 04:50, 17 April 2014 (UTC)

Done. (And we pretty much have no suitable place for these.) — Keφr 06:17, 17 April 2014 (UTC)

While the Latin pronunciation project is still not finished, I'm going to start a new project. I will upload testcases to Template:es-pronunc/documentation. Anyone may also upload testcases to there. --kc_kennylau (talk) 10:30, 18 April 2014 (UTC)

Why not use Module:UnitTests? (See Category:Module unit tests for examples.) — Keφr 18:17, 18 April 2014 (UTC)

Hi guys,

I brought this subject to CodeCat's attention and I was advised to take it to the Beer parlour.

BAICAN XXX has started being an active contributor again. He has been blocked numerous times from several projects, most recently from Romanian Wikipedia. I noticed that quite a few of his recent translations are incorrect. E.g. gândibil doesn't exist in any Romanian dictionary and sânteți has never been the correct spelling of sunteți. He has a long history of making up words and quite honestly I gave up trying to have a meaningful discussion with him a long time ago.

He also has a tendency of giving definitions instead of translations; for instance prenuptial is translated as prenupțial and antenupțial – "înainte de nuntă" is a definition, meaning "before a wedding". I'm not sure that it's in line with Wiktionary's guidelines. Best regards and Happy Easter, --Robbie SWE (talk) 18:10, 18 April 2014 (UTC)

Translations into sum-of-parts phrases are acceptable (when natural), but each word should be linked separately. Of course now it reduces to determining what can be considered a "natural" translation. — Keφr 18:16, 18 April 2014 (UTC)

Ceea ce face aci Robbie SWE se cheamă în română intrigă injurioasă, un fel de mobbing mascat. Recent a șters (delete) din Wicționar (ro.Wiktionary) categoria introdusă de mine Termeni români proveniți (derived) din Latină, motivând că "nu este necesară..." La Wicționar vrea să scrie numai el, Robbie SWEǃ Majoritatea operațiilor (contribuțiilor) sunt semnateː (signature) Robbie SWEǃ? Este acolo , la Wicționar, un neoficial monopol Robbie. Asta vorbește mult de la sine...BAICAN XXX, 18 Aprilie 2014. — This unsigned comment was added by BAICAN XXX (talk • contribs) at 20:04, 18 April 2014 (UTC).

User:BAICAN XXX: In case you have not noticed, this is the English Wiktionary. — Keφr 20:06, 18 April 2014 (UTC)

ːO.K., You a all rightǃ BAICAN XXX — This unsigned comment was added by BAICAN XXX (talk • contribs) at 20:22, 18 April 2014 (UTC).

Thank you for your answer earlier this evening Keφr. I believe that a large percentage of the sum-of-parts translations added in the last few days are superfluous – I'll try to check as many as possible. As reference to Baican's Romanian message; I've been accused of bullying and managing a monopoly back at the Romanian Wiktionary. I'm going to abstain from commenting in Romanian, because we are partaking in the English language version. I however doubt anyone will get a legible answer in this matter from Baican. --Robbie SWE (talk) 20:26, 18 April 2014 (UTC)

• FWIW, managing a monopoly in and of itself is not anything I would find objectionable, provided that the management is competent. Disallowing non-existent terms sounds like good management to me, anyway.

As a minor devil's advocate, though, is it possible that the alternate spelling sânteți might be in use, for example? Could it count as a common misspelling, or alternate spelling? (I have zero knowledge of Romanian, just asking out of considerations for general policy.) ‑‑ Eiríkr Útlendi │ Tala við mig 23:58, 18 April 2014 (UTC)

Google Books and Google Groups come up with exactly two hits. Google does ask "did you mean sunteti", which suggests there's some systematic orthographical issue at work here. Chuck Entz (talk) 00:55, 19 April 2014 (UTC)

Thank you guys for the input! The only two acceptable forms are sunteți and the obsolete discouraged form sînteți. The only reason to write sânteți, is if the î and â orthographic rule has been misunderstood. I've personally never seen it written like that, possibly because it's considered incorrect by the Romanian Academy and by intellectuals. But I think it's an entirely different subject altogether.--Robbie SWE (talk) 17:47, 19 April 2014 (UTC)

Our definition of eye dialect says "nonstandard spellings, which however do not change pronunciation...", which I take to mean that eye dialect consists of nonstandard spellings of standard pronunciations. Sources on Google Books seem to agree with this. But in our entries, we sometimes use {{eye dialect of}} to label entries for spellings that reflect nonstandard pronunciations, such as ze, you welcome, and wonderfool. It seems like there's an inconsistency here—should we be using a template that says something different? —Mr. Granger (talk • contribs) 19:41, 19 April 2014 (UTC)

I think the definition there is wrong. The intent of eye dialect is to show a different pronunciation in spelling, when the standard spelling would not convey it to the same effect. I suppose it depends on what you call a "nonstandard" pronunciation, and also what the assumed relationship between spelling and pronunciation is. In a language like English where spelling is rather unrelated to pronunciation, it would seem that written words can be pronounced differently as the speaker desires, so in that sense the spelling does not convey those different pronunciations well. But in languages where spelling is more strongly tied to pronunciation, different spellings are more commonly used to reflect different pronunciations. That is, one simply writes as one speaks, and so you can just write in your own dialect. I think "eye dialect" only refers to that first case; the second is just "dialectal spelling". —CodeCat 20:05, 19 April 2014 (UTC)

Showing a nonstandard pronunciation by means of a nonstandard spelling is not eye dialect. Eye dialect is things like sez for says or (in British English) wot for what, where the nonstandard spelling is to supposed to suggest a general nonstandardness in the speaker's language but in fact represents the standard pronunciation. If the pronunciation represented is nonstandard, then it's just a nonstandard spelling, but it's not eye dialect. —Aɴɢʀ (talk) 21:35, 19 April 2014 (UTC)

NB Talk:eye dialect. - -sche (discuss) 16:23, 25 April 2014 (UTC)

What does it mean to have an "intermediate" as opposed to a "basic" or "advanced" knowledge of a script (e.g. latin or greek or cyrillic)? Are there guidelines like there are for language templates? — This unsigned comment was added by R160K (talk • contribs).

Whatever you feel best describes your knowledge. I'm not aware of any systematic guidelines. --WikiTiki89 16:57, 21 April 2014 (UTC)

WT:BABEL is the only guideline we have. —CodeCat 17:15, 21 April 2014 (UTC)

How should we illustrate tonality in languages which have no native tonality indicators? In particular (right now) I am interested in tonality for translations, where we use the {{t}} template. Rich Farmbrough, 22:40, 21 April 2014 (UTC).

What do you mean by "native tonality indicators"? —Aɴɢʀ (talk) 23:48, 21 April 2014 (UTC)

I mean that the normal way of writing the language is without indicating tone.

• And which languages are you working with? ‑‑ Eiríkr Útlendi │ Tala við mig 23:52, 21 April 2014 (UTC)

  The language that prompted the question is Beli (Sudan). Rich Farmbrough, 06:41, 1 May 2014 (UTC).
  

If w:Beli language (South Sudan) is normally written without tones, then the tones can be indicated in IPA in pronunciation sections or in headers with special diacritics, such as done with Serbo-Croatian (e.g. bèzūmno) or Mandarin Chinese Pinyin, e.g. gǎizhèng - using existing or new, custom method. --Anatoli ^{(обсудить}/^вклад) 06:49, 1 May 2014 (UTC)

OK, thanks. Rich Farmbrough, 21:19, 1 May 2014 (UTC).

What if we open pages like BP to let people ask questions about one specific language? There would be so many pages though. --kc_kennylau (talk) 14:11, 22 April 2014 (UTC)

You mean separate BP pages for each language? No one would be watchlisting the ones for the smaller, less well known languages, so the questions would never get answered. —Aɴɢʀ (talk) 14:15, 22 April 2014 (UTC)

I could see one noticeboard for each of the really major languages, plus one for minor languages collectively (or, perhaps, minor languages grouped by region or language family). bd2412 T 14:44, 22 April 2014 (UTC)

Like we have Wiktionary:Translation requests, we can also have pages for asking questions emerged when learning a language. --kc_kennylau (talk) 15:01, 22 April 2014 (UTC)

I really think we shouldn't. There are already websites like Wordreference.com that do this. To be honest, I'm not a big fan of WT:Translation requests either. --WikiTiki89 15:09, 22 April 2014 (UTC)

Pages like Wiktionary talk:About Latin and Wiktionary talk:About Spanish function as discussion pages about Wiktionary's treatment of a particular language, if that's what you mean. —Mr. Granger (talk • contribs) 16:04, 22 April 2014 (UTC)

I still support making portal pages for languages. The "About" pages are aimed at editors, but we have nothing aimed at readers except maybe for categories like Category:English language. —CodeCat 16:17, 22 April 2014 (UTC)

Would it be possible to create subcategories of Category:Documentation subpages by language, such as Category:Ancient Greek documentation subpages? --Fsojic (talk) 18:45, 22 April 2014 (UTC)

What for? —CodeCat 18:51, 22 April 2014 (UTC)

{{m}} now redirects to {{term/t}}. But the latter was always intended to be only a temporary name, so now that we have a more permanent name for it, we should rename it and delete the old name. So I would like to ask if it's ok for me to run a bot to convert all existing uses of "term/t" to "m", and then nominate the former for RFDO.

Some people have complained that names like "m" and "l" are too short, confusing and not descriptive enough, while some people (apparently some of the same) have complained that names are too long and need to be easier to type. I don't think there is a reason we could not settle on a permanent name, like {{mention}}, and keep {{m}} as an "official" shortcut, much like we've already done with {{cx}} > {{context}}, {{lb}} > {{label}}, {{n-g}} > {{non-gloss definition}} and so on. People could then use either name as they prefer. Do you think that {{term/t}} should be moved to {{mention}} rather than to {{m}}, and {{m}} kept as a shortcut redirect to the longer name? (And if so, do you think we should similarly move {{l}} to {{link}}, while keeping {{l}} as a shortcut?)

Finally, we also have the older template, {{term}}. This takes different parameters, but I think most people were ok with converting it into {{m}} (or its old name). So, is it ok for me to convert {{term}} to {{m}}? If there is agreement for this change, but not the change from {{term/t}} to {{m}}, I could also convert {{term}} to {{term/t}} if that is preferred. (There are still 20 thousand transclusions of {{term}} that have no language specified. I'll leave them alone for now, so that we can discuss what to do with those at another time.) —CodeCat 20:07, 24 April 2014 (UTC)

I don't see a pressing need for mass conversion, but I have nothing against it. The fact that {{m}} exists now is enough for me. --WikiTiki89 21:43, 24 April 2014 (UTC)

What does m stand for now? --kc_kennylau (talk) 01:09, 25 April 2014 (UTC)

"mention". It's used for terms that are mentioned in running text. I think it's more descriptive than "term"... {{l}} also links to "terms". —CodeCat 01:10, 25 April 2014 (UTC)

Will you please unprotect {{m}} for the moment thank you. --kc_kennylau (talk) 01:49, 25 April 2014 (UTC)

• Oppose converting "{{term}}" to anything. Wiki markup is the user interface; a significant widespread conversion like this should be done via a vote, IMHO. --Dan Polansky (talk) 06:48, 1 May 2014 (UTC)
• Otherwise I would be for it, but can we resolve the discussion about "the third parameter" first? — Keφr 08:03, 1 May 2014 (UTC)
• Obviously needs a vote of more than our crack squad of technical savants. It has consequences for too many. DCDuring TALK 13:36, 1 May 2014 (UTC)

Who thought it would be a good idea to inflict two giant ugly yellow boxes on (deprecated template usage) olinguito? These are excessive, to say the least, and need to go. -Cloudcuckoolander (talk) 14:10, 25 April 2014 (UTC)

What would you suggest as an alternative? —CodeCat 14:13, 25 April 2014 (UTC)

I say get rid of the boxes. As I predicted, the olinguito is irresistible fodder for children's books. At this point, it is unlikely in the extreme that the word will disappear within a year. bd2412 T 14:22, 25 April 2014 (UTC)

I personally don't see a need to visibly mark "hot words." The main purpose this big box seems to serve is to inform readers that some Wiktionarians object to the term's inclusion on Wiktionary. And I think it's ultimately detrimental to let the internal politics of Wiktionary spill out into entries that way. But if there is a new policy that stipulates "hot words" be visibly marked (I admit I may be out of the loop), then I think something more compact and to-the-point would be preferable:

This English term is a hot word. Its inclusion on Wiktionary is provisional.

This could be right-aligned at the top of language sections like Template:was wotd. Further information could be included on the glossary/policy page to which "hot word" links. -Cloudcuckoolander (talk) 14:42, 25 April 2014 (UTC)

1. Support Definitely a big improvement. The small bit of red and yellow seems enough to attract attention, without providing a lasting distraction. (There may be possibilities for further improvement.) DCDuring TALK 14:49, 25 April 2014 (UTC)

I think they should be visibly marked for the same reason that we mark WT:LDLs with {{LDL}}. It serves to inform readers that the entry does not meet our normal standards, but has been given an explicit concession for the sake of serving the reader. —CodeCat 15:33, 25 April 2014 (UTC)

• I created Wiktionary:Requests_for_deletion/Others#Template:hot_word on 10 March 2014. I think the look of template:hot word is horrible, but some seem to disagree. --Dan Polansky (talk) 15:51, 25 April 2014 (UTC)
  • I agree that it doesn't look so good, but I disagree with trying to make it invisible. It should draw enough attention to be noticed, much like {{LDL}}. —CodeCat 16:17, 25 April 2014 (UTC)
    • I also think that the template as currently written sounds like it is encouraging readers to use the word in print, so that citations will exist to justify its existence. bd2412 T 17:25, 25 April 2014 (UTC)

The wording is an improvement, but it needs to be more noticeable than that. At least add a box (with friendlier colours than the current version). — Ungoliant ^(falai) 17:45, 25 April 2014 (UTC)

The little flame is preferable to the yellow radiation hazard sign. Any warning is still less important than the main content of an entry, and shouldn’t be emphasized over it six ways from Sunday. —Michael Z. 2014-04-25 18:51 z

While we’re at it, we should consider formalising the includibility of hot words into the CFI. It can’t be an experiment forever. — Ungoliant ^(falai) 19:27, 25 April 2014 (UTC)

I agree, but that should be a separate discussion, ending in a vote. Or maybe we can just jump straight to the vote as there seems to be general agreement anyway. —CodeCat 19:55, 25 April 2014 (UTC)

Some intricacies need to be sorted out. I’ll start a discussion later today, if no one gets to it first. — Ungoliant ^(falai) 20:27, 25 April 2014 (UTC)

It's funny that you're all arguing about the template design that I used as a proof of concept. To be clear, I never liked my own design and have been waiting for someone to improve it. I kind of like Cloudcuckoolander's idea, especially the flame icon. --WikiTiki89 23:16, 25 April 2014 (UTC)

I'm a bit less concerned about the template design than about the fact that it is being used on an entry that is highly unlikely to fail to take hold. This is a baby olinguito. Case closed, good day, sir. bd2412 T 23:26, 25 April 2014 (UTC)

And that's exactly why the template is there. To show that it doesn't meet CFI yet, but we think it will in time. —CodeCat 23:30, 25 April 2014 (UTC)

The template says, "It may soon fall out of usage, and its entry may be deleted from Wiktionary in the future". That may be true for some terms, perhaps for a great many novel coinages, but for this particular word it is no more true than it would be for the word raccoon. The word is established, and its use is expanding, not contracting. The World Almanac and Book of Facts 2014 named this as one of the top science stories of the year, while the Britannica Book of the Year 2014 identified it as the "most compelling" species discovered in 2013. Future authors writing about scientific discoveries made in 2013 (and perhaps in the entire 2010s decade) will have little choice but to use this word. bd2412 T 01:02, 26 April 2014 (UTC)

The text on the template is part of its design as well. --WikiTiki89 15:12, 26 April 2014 (UTC)

There are some words for which such text would make sense (the social media sense of catfishing would be an example); for the only common name given to a newly identified species, this outcome is so improbable that different language should be used. bd2412 T 16:20, 27 April 2014 (UTC)

Somebody has recently changed the system so that pos templates such as {{fi-noun}}, {{fi-verb}}, {{head|fi}} automatically create wikilinks for every element of a multiple-element header. See suu- ja sorkkatauti as an example and you'll see what I mean. This may be practical in case of non-agglutinative languages, but at least in case of Finnish it creates unnecessary and, I would say, annoying redlinks. In case of suu- ja sorkkatauti it creates redlinks to suu- and sorkkatauti. What makes it unnecessary and annoying is that neither of these elements exists as independent lexeme, and thus entries for them should not be created. Also, most of the time the Finnish compound terms are written as one word, see e.g. afrikantupsuhäntäpiikkisika which consists of four elements of which one (piikkisika) is a compound term in itself and one (afrikan) does not exist as indpendent lexeme. The Finnish editors have solved the situation so that instead of breaking the terms in their elements in the pos-line we write an Etymology section which aims to explain how the term is composed from its elements. This allows a perfect control on what to wikify and what not.

As Finnish is by no means the only agglutinative language around, I suggest that this change is reverted (i.e. no automatic wikilinking of elements of headers), or, as a minimum request, Finnish is exempted from this practice. --Hekaheka (talk) 04:42, 26 April 2014 (UTC)

The redlink like the above could be converted to whatever makes sense in individual languages. E.g consider converting the links in suu- ja sorkkatauti from suu- ja sorkkatauti to suu- ja sorkkatauti where individual links make sense or if one can't be bothered creating inflected forms (like me). Fixing links is easier than adding new ones, IMO. --Anatoli ^{(обсудить}/^вклад) 07:13, 26 April 2014 (UTC)

Thanks for the idea. Now I only need to go check the hundreds or thousands of entries with multiple-word entries that we have, find those in which this phenomenon occurs and correct them all manually! Any idea how this process could be speedied up? --Hekaheka (talk) 10:14, 26 April 2014 (UTC)

I'm sorry you don't like the idea but shouldn't individual components of multipart words and expressions be linked to individual lemmas? Isn't it what you do as well? --Anatoli ^{(обсудить}/^вклад) 11:26, 26 April 2014 (UTC)

I suggest {{head|fi|noun|l1=suu|l2=ja|l3=sorkka|l4=tauti}}. I'll try to develop a code in my sandbox. --kc_kennylau (talk) 10:24, 26 April 2014 (UTC) Added nowiki tags --kc_kennylau (talk) 10:25, 26 April 2014 (UTC)

{{User:kc_kennylau/head|pagename=suu- ja sorkkatauti|l1=suu|l2=ja|l3=sorkka|l4=tauti}}: {{User:kc_kennylau/head|pagename=suu- ja sorkkatauti|l1=suu|l2=ja|l3=sorkka|l4=tauti}} --kc_kennylau (talk) 10:57, 26 April 2014 (UTC)

No, no, no, no, no. Please no. What I did at {{fi-noun}} would be saner. — Keφr 11:07, 26 April 2014 (UTC)

The pagename parameter is just to make it work here, it'll be omitted. What if I make it automatic for words separated with space and only specify the components of a word? What I mean is {{head|fi|noun|l1=sorkka|l2=tauti}} --kc_kennylau (talk) 12:12, 26 April 2014 (UTC)

What is wrong with {{head|fi|noun|head=]- ] ]]}}? — Keφr 12:24, 26 April 2014 (UTC)

{{head|fi|noun|l1=sorkka|l2=tauti}}: {{User:kc_kennylau/head|pagename=suu- ja sorkkatauti|l1=sorkka|l2=tauti}} simpler huh? --kc_kennylau (talk) 13:05, 26 April 2014 (UTC)

Not simpler at all. —CodeCat 13:19, 26 April 2014 (UTC)

I still maintain that there needs to be a quick and easy way to disable this, for example a head=- parameter or something. --WikiTiki89 15:15, 26 April 2014 (UTC)

One quick way is to write: {{fi-noun|head=suu- ja sorkkatauti}} which results in suu- ja sorkkatauti. One can add wikilinks where one wants to by writing e.g. {{fi-noun|head=suu- ja sorkka]}} which results in suu- ja sorkkatauti. New entries are not really the problem, but the old ones which are somewhat messed up by this change. Finding them is a colossal task unless there's someone clever out there who can create a to-do-page containing "Finnish POS lines with redlinks". --Hekaheka (talk) 00:11, 29 April 2014 (UTC)

I meant something that does not require retyping the headword. --WikiTiki89 04:44, 29 April 2014 (UTC)

CodeCat made the change; they're the one who needs to fix the mistakes it caused. If they can't do that then the changes should be reverted. DTLHS (talk) 00:21, 29 April 2014 (UTC)

It seems that my original complaint has been resolved. At least the template {{fi-noun}} does not automatically produce links to every word in the header anymore. Thanks to the somebody who did it. --Hekaheka (talk) 00:23, 29 April 2014 (UTC)

DTLHS, I made the change following a discussion with broad consensus. I actually felt ambivalent about it and still do. It's not fair to hold me personally responsible. :/ —CodeCat 00:36, 29 April 2014 (UTC)

Sorry- nothing personal. But just because something has consensus doesn't mean it's a good idea. DTLHS (talk) 02:09, 29 April 2014 (UTC)

Can someone please also help delink Mandarin pinyin, e.g. biànzhèng wéiwùlùn template {{pinyin reading of}} and Japanese rōmaji, e.g. akemashite omedetō gozaimasu, template {{ja-romanization of}}? --Anatoli ^{(обсудить}/^вклад) 02:39, 29 April 2014 (UTC)

I can't seem to find the discussion where this was agreed on—can someone post a link to it? —Mr. Granger (talk • contribs) 02:50, 29 April 2014 (UTC)

talk:pithovirus raises an interesting question - what do we do about technical terms set by official bodies which are recently coined? Admittedly, Pithovirus is not a perfect example, since there's no single body that sets taxonomic names, but when ununoctium is officially named by IUPAC, for example, or (307261) 2002 MS₄ is named by w:IAU, do we still have to wait a year before we can add their new names? (In terms of precendents, Sedna, Makemake and Haumea were all created within days of the planets being named, while Quaoar was not. Flerovium and livermorium, the only elements named in the last five years, were also created as soon as they were named. We also didn't wait a year after Cape Verde officially changed its English name to Cabo Verde, although that was marginally attestable before the official renaming.) Smurrayinchester (talk) 13:14, 26 April 2014 (UTC)

{{hot word}}. --WikiTiki89 15:16, 26 April 2014 (UTC)

I'd favor something similar to, but not identical to {{hot word}}. The nature and degree of uncertainty is different. And there is an "ought" associated with the official words that is not associated with 'hot words'. DCDuring TALK 16:48, 26 April 2014 (UTC)

Yes, {{hot word}} seems like a poor fit for technical terms. For one thing, although a few of them may be the centre of media attention, a lot of them aren't hot, they're just new pieces of jargon.

I've put together a possible template at {{User:Smurrayinchester/new-jargon}}, which is perhaps a better fit for official terms. On the right are two (hypothetical) examples: one for an uncontroversial offical renaming (2003 EL₆₁ to Haumea) and one that is very controversial (Burma to Myanmar). Any suggestions are welcome (I'm pretty sure there's a way to get the date parser to put the date in the user's chosen format, but I can't make it work). I think it's pretty clear that if we use this, it needs to have a strong reference in place of the three citations, and clearly flag up entries that aren't referenced. Smurrayinchester (talk) 16:43, 27 April 2014 (UTC)

The fact that Burma-to-Myanmar is politically controversial does not make it linguistically controversial. Even if the name change were reversed in a month, it would still be a matter of historical fact that would continue to be reported for years. We would be better off just amending the CFI to immediately allow official names designated by national bodies and scientific organizations, so long as it can shown in reliable sources that the designation has been made. bd2412 T 17:15, 27 April 2014 (UTC)

Can we just make it a usage note instead of an attention-whoring cyan blue box? —Aɴɢʀ (talk) 18:01, 27 April 2014 (UTC)

Yes, the boxes visual presence is way, way overkill.

We do include technical terms that might not meet CFI, with a technical usage label. Official names could be treated the same way. wasn’t there already a {{neologism}} or something for this? —Michael Z. 2014-04-30 00:44 z

Or we could make it simpler; simply label words that we think will meet CFI in a year as such and put them in a category to be reevaluated in Month of Year, at which point they go to RFV if they don't have the 3 cites spanning a year.--Prosfilaes (talk) 21:26, 30 April 2014 (UTC)

Hundreds of pages of German entries are using the acronym SLDE but nowhere on Wiktionary is the acronym explained. Nor on Wikipedia, or for that matter, anything I easily find with a google search. If we are going to use an expression in mainspace surely we should have an entry for it. After all, that is what a dictionary is for. SpinningSpark 20:03, 29 April 2014 (UTC)

Can you give some examples so that people don't have to read your mind? --WikiTiki89 20:07, 29 April 2014 (UTC)

I just encountered this myself at Mass. It seems to stand for Switzerland and Liechtenstein DE (= German). —Aɴɢʀ (talk) 20:14, 29 April 2014 (UTC)

Then I think we should convert it to: {{context|Switzerland|Liechtenstein}} {{alternative spelling of}}. --WikiTiki89 20:17, 29 April 2014 (UTC)

Using {{standard spelling of}} is more accurate than using {{alternative spelling of}}, and using "from=SLDE" is much easier than using "from=Switzerland|from2=Liechtenstein". I will continue using SLDE rather than messing with all that extra typing, thank you very much. - -sche (discuss) 21:23, 29 April 2014 (UTC)

You're right. I wasn't aware of that template. --WikiTiki89 21:30, 29 April 2014 (UTC)

@Spinningspark: I don't think there are entries displaying SLDE, are there? If there are, it is in error (most likely because some template is not behaving as expected). We don't need dictionary entries for every template code we use (or who wants to define ] as "sometimes countable, sometimes uncountable" according to our usage of it in noun templates). SLDE is defined in Module:labels/data and, until such time as someone can be bothered to expand that module's functionality, also in the temporary stopgap Module:labels2/data. - -sche (discuss) 21:32, 29 April 2014 (UTC)

That's only because Kephir (talk • contribs) fixed it after this thread was started. --WikiTiki89 21:46, 29 April 2014 (UTC)

Ah. There were no entries displaying SLDE a few weeks ago, either, when I last used it, so it seems something broke in the time between my last use of it and the start of this thread (probably to do with the deletion of the regional context label templates). If whatever was broken has now been fixed, that's good. :) - -sche (discuss) 22:09, 29 April 2014 (UTC)

I discovered just now that {{context|currency}} displays (numismatics). This seems to me to be an error -- not all currency is coinage, nor does currency necessarily imply the study or collecting of coins.

For my part, I would expect {{context|currency}} to display (currency), and add the entry to the :Currency category (the categorization part does currently work correctly).

What do others think? ‑‑ Eiríkr Útlendi │ Tala við mig 03:40, 30 April 2014 (UTC)

I agree. Currency and numismatics are not synonyms, and since Category:Currency and Category:Numismatics are separate, the context labels that sort things into them should appear separate too. —Aɴɢʀ (talk) 08:38, 30 April 2014 (UTC)

Oh, I see we don't actually have a topic category Numismatics. Maybe that should be fixed too. At any rate the context label and category name should be the same. —Aɴɢʀ (talk) 08:41, 30 April 2014 (UTC)

Specialist vocabulary warrants a usage label numismatics. But “currency” is not a technical subject or other kind of restricted usage, and probably should not appear in a label.

By the way, now that we are using {{context}}, how do I see the equivalent of What Links Here for {{context|currency}}? —Michael Z. 2014-04-30 18:58 z

@Michael, others --

Perhaps I've misunderstood what context labels are intended for. I don't view currency terms as technical, but they are indeed a specific and restricted context, and as such often merit a label for clarity's sake. For example,

• clam, sense 4
• crown, senses 14 and 15
• guinea, sense 2
• krona, sense 1
• nickel, senses 2, 3, and 4
• peso, sense 2
• 元 (yuán), sense 3

These all have currency senses, but there is no currency context label and almost all of these entries are missing any :Currency categorization.

Have a look at ㌚ (“cruzeiro”). I've formatted that entry manually to do what I think {{context|currency}} should do -- add a label clarifying what context this sense is used in, and add the entry to the :Currency category.

Huh, just noticed I unconsciously compiled that list alphabetically... does that mean I've been spending too much time here?  :)

‑‑ Eiríkr Útlendi │ Tala við mig 21:24, 30 April 2014 (UTC)

If your friend comes up to you and asks to borrow a nickel, you don't need any further context to figure out what he meant. --WikiTiki89 21:27, 30 April 2014 (UTC)

• If you speak English already, sure. If you came here to look up the individual word nickel and you didn't already know the word, context is helpful. Our entries consist of words and definitions in a non-conversational text medium. If we based all our entry formatting decisions on what friends say to each other, we wouldn't need any context labels at all. ‑‑ Eiríkr Útlendi │ Tala við mig 05:05, 1 May 2014 (UTC)

  My point is these words are used in all contexts, so the context is not helpful in determining the definition. --WikiTiki89 16:25, 1 May 2014 (UTC)

The labels that appear at the beginning of a definition, when they aren't about grammar, obsolescence (rarity, datedness, archaicness), or specific scope restrictions (eg, of what might be modified by an adjective), are used at Wiktionary for several things that might be called "context", as I understand it:

1. register (eg, formal, informal, colloquial, technical?)
2. topic (animal, transportation, Hinduism, weaponry, New England, crime)
3. speaker group in which word is likely to be understood (zoology; automotive engineers; Hindus; military; New Englanders; criminals, lawyers, police)

Clearly it is possible for there to be items for which topic and speaker group are in correspondence, but there are many cases where many, even all, speakers would understand a word on a given topic. No necessary implication goes from topic to speaker group. One might expect an implication from speaker group to topic, but that is not the case. For example, military slang includes various terms for civilians of various types.

We have not troubled with the distinction between the second and third of these "contexts". Thus some apply context labels based on topic, others based on speaker group, making such labels unreliable for users in general. In this case "numismatics" would seem to represent a speaker group AND a topic and "currency" only a topic. The sense in which "currency" is a "context" seems really to correspond to "topic". I don't really see how visible topic labels are a great help to ordinary users. They may be a help to someone working on an entry or set of entries, to speed them to specific parts of the entry.

All this is just a long-winded way of reminding everyone why this is essentially not solvable without resolving the ambiguity, which is not easily done as those seeking to save time on editing seem unconcerned about the passive users who, I thought, are the supposed beneficiaries of our efforts. DCDuring TALK 21:05, 1 May 2014 (UTC)

User: DCDuring, I thought we resolved that by having our labels follow normal dictionary conventions, and to use simple category wikitext for simply categorizing.

I wish we would stop saying “context” for labels. It is completely unhelpful. Context means two things in lexicography, neither of them related directly to labels.

re: Hard categories for topics: Until we reverse all the labels that are mistaken, we can expect contributors to imitate what they find. The extra effort to hard-categorize is sufficient reason for some not to want to do so.

re: usage of word "context": I wish it wouldn't rain on my birthday. I call it "context" because of the template name and historical usage here. I will strive to do better.

User: Eirikr, dictionary labels are of two types: grammatical and usage (unfortunately, we lump them together). Usage means usage of the term, not anything about the thing the term refers to (its referent). One category of usage labels are applied to technical or specialist vocabulary, whose usage is chiefly restricted to a particular subject field. So terms used mainly in numismatics, or senses having a special meaning in numismatics, would be labelled numismatics.

We don’t label terms representing currency as “currency”. That fact is part of a term’s definition, and not how it is used. —Michael Z. 2014-05-02 02:04 z

MZajac has consistently advocated this position, which seems sound and consistent with user expectations from other dictionaries. Sometimes others disagree. More often it seems to be ignored or not enforced. It should be enforced IMO. DCDuring TALK 15:55, 2 May 2014 (UTC)

We did indeed so resolve, MZ. DCD, context labels are not for categorizing, or what you call "topic" use: see Votes/pl-2009-03/Context labels in ELE v2. I agree with you that this vote should be enforced; I enforce it whenever I come across a clearly offending (English) entry.​—msh210℠ (talk) 06:00, 4 May 2014 (UTC)

You don't. That's one of the downsides of the Luification. --WikiTiki89 19:01, 30 April 2014 (UTC)

It's not impossible to do, with tracking templates. But that would need to be done on a case-by-case basis, and the module would need to be modified each time we want to track it. —CodeCat 19:43, 30 April 2014 (UTC)

What happens if a "tracking template" doesn't exist? --WikiTiki89 19:45, 30 April 2014 (UTC)

A script error occurs. —CodeCat 19:46, 30 April 2014 (UTC)

We might be able to work around that, though. It's possible to "catch" script errors, and that presumably stops them from being categorised as errors? (This needs testing.) If that works, then we can use that to trigger transclusions on nonexistent pages. —CodeCat 19:48, 30 April 2014 (UTC)

I just tested this and it works. If you do it like this:

pcall(function() frame:expandTemplate({title = "(name of template)", args = {}}) end)

then a transclusion is created even if the page doesn't exist, but there will be no error. I don't know how resource-intensive it is, though, mainly because this is essentially a hack around "ifexist" (like the existing {{does-template-exist}}). —CodeCat 19:57, 30 April 2014 (UTC)

I don't think it would be any more resource-intensive than a real transclusion of a non-existent template. --WikiTiki89 20:01, 30 April 2014 (UTC)

I wonder why the software places a limit on "ifexist" then. In any case, transclusions count as links, so using this widely would quickly flood Special:WantedTemplates. —CodeCat 20:18, 30 April 2014 (UTC)

Well for one thing, we are not determining whether a template exists. Instead we are using it whether it exists or not. I have no idea why "ifexist" is so bad, theoretically it doesn't need to be. --WikiTiki89 20:23, 30 April 2014 (UTC)

To transclude a template still means looking it up to see if it exists, though. We don't normally have to deal with that as editors, but something as simple as a plain wikilink presumably has ifexist-like code behind it, to determine whether the link should be red or blue. Template transclusion is probably no different, except that there's also retrieval, parsing and substitution of the text afterwards. So I don't really understand why ifexist is so bad either, I agree it doesn't have to be. I wonder who could explain that for us. —CodeCat 20:27, 30 April 2014 (UTC)

Yes, but that all happens so far in the backend that ifexist doesn't have access to it, which is not a very smart implementation, but it's possible that they did it that way. --WikiTiki89 20:29, 30 April 2014 (UTC)

My understanding (which may have been wrong) was actually that ifexist is not more expensive than a link or transclusion, it's just that it's considered more likely to be abused. They don't want people using crazy loopy recursion madness to check for the existence of bajillions of templates trying to find the one to transclude. —Ruakh_TALK 21:31, 2 May 2014 (UTC)

That's a reasonable explanation. --WikiTiki89 02:11, 3 May 2014 (UTC)