Wiktionary:Beer parlour/2014/September

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← August 2014 · September 2014 · October 2014 → · (current)

---

English plural nouns: agreement and countability

We tell our users what is mostly obvious by inspection, that a noun is plural in form. The only significant information that is provided is that there is no singular form, which information is sometimes false.

I would expect that it would be more useful to a learner of English would be to know what form of verbs was used for agreement in number and whether the noun was countable, which indicates which set of determiners it would be used with.

1. Apart from the work involved, is there any reason not to try to provide this information?
2. Is there any reason for this information not to be on the inflection line?

If we can agree to the answers to these simple questions, then it should be possible to emend {{en-plural noun}} and/or {{en-noun}} appropriately. {{en-plural noun}} is transcluded in 1454 times in principal namespace and probably should be used in additional existing entries. This may overlap in some cases with the separate phenomenon of British/Commonwealth English requiring that a noun like team take a plural form of verbs for agreement. DCDuring TALK 15:05, 1 September 2014 (UTC)

Responding to your last sentence first, the British use of "team (etc) are" vs the American use of " team (etc) is" seems like a general grammatical phenomenon, perhaps not worth mentioning in individual words' entries. If one inverts a new word, e.g. the country name "Triceleuden", I expect it will be adapted to the existing grammar and hence a Brit will report sporting news as "Triceleuden face Australia in their next match" while an American will say "Triceleuden faces Australia".

Some entries do mention whether they take singular or plural verbs, in varying ways: feces, data, dramatics, bobby socks, grits. I agree that indicating the "verb number preference" of plural-only nous would be useful. Grits and data show why the information cannot always be on the inflection / headword line, and feces shows how the information may be too long to fit into a sense-line {{label}}. Perhaps we could use sense-line labels and just expand on them in the usage notes when necessary, though. Regalia is an example of a plural-only noun that seems to take singular verbs and plural verbs in even measure. - -sche (discuss) 16:28, 1 September 2014 (UTC)

Chinese Medicine Entries

There are hundreds of entries for Chinese medicinal preparations that nobody seems to be aware of. They go beyond encyclopedic into a level of detail that Wikipedia doesn't touch. To illustrate the magnitude of the phenomenon, here's the "definition" for 二十五味珊瑚丸 (èrshíwǔwèi shānhú wán):

1. A reddish-brown pill used in traditional Tibetan medicine to "promote the restoration of consciousness, promote blood circulation and relieve pain, when there are symptoms that include unconsciousness, numbness of body, dizziness, headache, abnormal blood pressure, epilepsy and cranial neuralgia".

Ershiwuwei Shanhu pills have the following herbal ingredients:

Name	Chinese (S)	Grams
Qingjinshi	青金石	20
Os Corallii	珊瑚	75
Margarita	珍珠	15
Concha Margaritifera	珍珠母	50
Fructus Chebulae	诃子	100
Radix Aucklandiae	木香	60
Flos Carthami	红花	80
Flos Caryophylli	丁香	35
Lignum Aquilariae Resinatum	沉香	70
Cinnabaris	硃砂	30
Os Draconis	龙骨	40
Calamina	炉甘石	25
Naoshi	鱼脑石	25
Magnetitum	磁石	25
Limonitum	禹余粮	25
Semen Sesami	白芝麻	40
Fructus Lagenariae	壶芦	30
Flos Asteris	野冬菊	45
Herba Swertiae Bimaculatae	獐牙菜	80
Rhizoma Acori Calami	白菖	50
Radix Aconiti Preparata	制川乌	45
Herba Chrysanthemi Tatsiiensis	打箭薹草	75
Radix Glycyrrhizae	甘草	75
Stigma Croci	红花	25
Moschus	麝香	2

二十五 is Chinese for 25, and, not coincidentally, there are 25 ingredients listed. Though it's no doubt got more ingredients in the list than most of these entries, there are hundreds of them. DCDuring has added hyperlinks to some of the Latin, but other than that, a look at the edit history shows no one but the creator of the entry and some bots, and that seems to be the norm.

I may be wrong, but I think someone listing the names and amount of the ingredients for various standardized foods or beverages would be reverted pretty quickly, but these have been there for half a decade. The question is: do we want to have different standards for entries that no one cares about? Chuck Entz (talk) 07:35, 2 September 2014 (UTC)

Most of those articles need to be deleted. Only the ingredients themselves warrant inclusion. Wyang (talk) 09:57, 2 September 2014 (UTC)

Other than the fact that the tables are not WT:ELE compliant, what exactly is wrong with the entries? The items on all the tables are meronyms of the headwords, with quantification. I know that EncycloPetey has expressed a linguistic interest in Chinese herbal medicine. I have become convinced that the meronyms are themselves not necessarily SoP as they are often short names for ingredients more specific than the names would suggest, either in the species involved, in the form, or the manner of preparation. The large literature on Chinese herbal medicine makes it highly likely that all of the terms involved, headwords and meronyms, are attestable. The subject matter is basically irrelevant to inclusion.

It seems to me that all of the entries with the tables would be worth some effort to bring into greater conformity with WT:ELE and would otherwise be subject to the same RfV and RfD as other entries.

I would also appreciate views about whether "radix Aconiti preparata", as used in Chinese or English works on herbal medicine, are or might be likely to be entry-worthy or, if not, why. DCDuring TALK 13:41, 2 September 2014 (UTC)

Here is a list of them:

These are not considered words by Chinese dictionaries. Apart from SoPness, problems also include: 1) lack of creator's knowledge in Chinese. Many of these entries have been fixed over the years, but numerous mistakes are still present. For example, this nonsense entry 发育迟缓 ("growth retardation"). 2) incorrect formatting. Most of these fall into Category:Chinese terms with uncreated forms, and have weird formatting errors (eg. nonstandard use of the hanzi box, initial or trailing spaces in Pinyin, hidden characters in title). Wyang (talk) 23:50, 2 September 2014 (UTC)

Which ones should be RfDed? Which ones have something that can be saved (ie, should be RfCed)? I would like to at least harvest the taxonomic species or genera referred to in the tables. The English or "Medical Latin" terms seem attestable and not necessary SoP, as they are used as units. DCDuring TALK 02:28, 3 September 2014 (UTC)

Arabic transliteration module enabled, a minor change needed, verb header template needs work

(Notifying Benwing, Wikitiki89, ZxxZxxZ, Mahmudmasri): I have just added Arabic transliteration module Module:ar-translit to Module:languages/data2 to allow automatic transliteration, which is now enabled in all templates, which use automatic transliterations. It's not added to Module:links, so the manual transliteration is not overridden. It's a good time to change Arabic verb template {{ar-verb}}. As most verbs use full diacritics and it would be much easier, if the manual transliteration is removed, all missing diacritics checked, when the template starts using the automatic transliteration. It works fine in most cases. We need to make "showI3raab" default to show case and verb conjugation endings. As was previously agreed, we don't need word stresses for Arabic words, so a fully vocalised word نَزَفَ (nazafa) should be transliterated as "nazafa", not "nazaf" (missing iʿrāb ending) or "názafa" (stress mark). (I should mention, if it's not obvious that the module is supposed to be used on a fully or partially vocalised forms, i.e. with diacritics, which are normally unwritten in a running Arabic text). You're doing a great job, Benwing, thanks! --Anatoli T. ^{(обсудить}/^вклад) 03:28, 3 September 2014 (UTC)

You're welcome.

Can you give an example of templates that use automatic transliterations? In the case of {{ar-verb}}, can you point to a verb where this translation happens? Will it happen if you remove the manual transliteration?

I'm all for making "showI3raab" the default; if no one objects I'll go ahead and do this.

Also (Notifying Lo Ximiendo): I haven't done much with {{ar-verb}} so far. I think it should be rewritten entirely so that it basically takes the same params as {{ar-conj}} and makes use of the same code. That would obviate the need for explicitly writing out the perfect and imperfect verb forms and would automatically supply the right vowels and such. This should be retrofitted into the existing params, which I think is possible. What this means is that form I verbs need only the form and past and non-past vowels specified, and augmented (non-form-I) verbs need only the form specified (the radicals are inferred from the headword; the few cases where ambiguity exists all involve weak radicals i.e. و or ي, and as it happens the call to {{ar-verb}} already specifies the radicals in these cases, e.g. in تسلى where III=و is specified, see below). The form is already present in the call to {{ar-verb}} but the past/non-past vowels aren't; however, this isn't an issue if the verb forms are manually given (which they are, currently), and we can arrange things so that there's a category containing form-I verbs whose call to {{ar-verb}} is missing the past or non-past vowels, so they'll eventually be fixed. For augmented (non-form-I) verbs, I'm thinkingwe should actually ignore the parameters specifying verb forms, because of cases like تسلى, which has a call to {{ar-verb}} declared as {{ar-verb|III=و|form=5|tr=tasallā|impf=يتسلى|impftr=yatasallā}} with missing vowel diacritics. Module:ar-verb will correctly generate the verb forms on its own: it currently handles all "regular" verbs and almost all of the very few truly irregular verbs, and if any cases come up where it doesn't work properly, just fix the module. (A more conservative approach is to check to see whether the diacritics are present and use the manually specified verb form if so.) I don't have time to work on this now, so Anatoli if you're interested in working on it, go ahead. Benwing (talk) 04:49, 3 September 2014 (UTC)

I have just updated نَزَفَ (nazafa) (and the verbal noun), which now uses automatic transliteration ("showI3raab" is currently off), so it now automatically shows "nazaf", instead of "nazafa". Note that imperfect forms only need one parameters - the form with diacritics, |impfhead=يَنْزِفُ is not necessary, neither is |impftr= (inflected forms are not transliterated in the headword. The entry got into Category:Arabic terms lacking transliteration, which should probably be removed from {{ar-verb}}. --Anatoli T. ^{(обсудить}/^вклад) 05:25, 3 September 2014 (UTC)

Re: templates using automatic transliteration: {{t}}, {{l}}, {{term}}, headword templates, etc. One problem with that is that if a term is missing both manual transliteration and diacritics, it will transliterate incorrectly, e.g. نزف is, as you can see is just "nzf". Various Arabic translations using {{t}} or {{t+}} will now have wrong transliterations. Someone may complain about this. --Anatoli T. ^{(обсудить}/^вклад) 05:32, 3 September 2014 (UTC)

Actually, the intention is clearly that the imperfect is translated in the headword. The call to {{ar-verb}} passes in the |impftr= param as {{head}} param |f1tr=, but this is (no longer?) supported. I think this intention is correct. Benwing (talk) 05:49, 3 September 2014 (UTC)

(You must have meant transliterated in the headword). It's no longer supported. I posted on the GP discussion you started. --Anatoli T. ^{(обсудить}/^вклад) 06:01, 3 September 2014 (UTC)

Yeah, sorry, I meant transliterated. Benwing (talk) 06:11, 3 September 2014 (UTC)

Swedish entries give glosses rather than translations

The entry for malm, for example, has, among other definitions:

(archaic) an alloy consisting of copper, zinc, lead and some tin (archaic) the geological period of late Jurassic (archaic) a hill or ridge consisting of sand or gravel

Unless these are specifically terms for which there is no English equivalent, these should be translations rather than glosses - for example, the first looks as if it should simply be "bronze".

I've looked at several other Swedish entries and they seem to give translations, so this may be an isolated example after all.

Grants to improve your project

Greetings! The Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. Your idea could improve Wikimedia projects with a new tool or gadget, a better process to support community-building on your wiki, research on an important issue, or something else we haven't thought of yet. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to hiring others to help you.

• Submit your proposal
• Get help: In IdeaLab or an upcoming Hangout session PEarley (WMF) (talk) 15:26, 3 September 2014 (UTC)

Four RfV topics to clear 2013.

If we can settle the four oldest RfV issues, we'll have 2013 cleared off of that board. Any takers? bd2412 T 20:01, 3 September 2014 (UTC)

returning nil in Module:ar-translit when vowel diacritics not available?

Now that we've turned on automatic transliteration for Arabic, one issue is that not all words have the vowel diacritics supplied, leading to incorrect transliterations. One possibility is to check for this, and return nil when encountering a word that isn't completely vocalized (with an exception made for vowels omitted on the last letter of a word). Some questions:

1. Will this work? What happens in general when a transliteration module returns nil?
2. Is this a good idea?
3. Is this the right place to ask a question like this (apologies to Wikitiki89)?

Benwing (talk) 05:18, 5 September 2014 (UTC)

Maybe @Wyang can help? You made the Korean transliterate hangeul 공부하다 (gongbuhada), while hanja is not transliterated: 工夫? (工夫하다 (工夫hada) should also be nil, IMO)

Nil shouldn't transliterate anything, like with language for which automatic transliteration is not enabled, e.g. Hindi, Hebrew, if there is no manual tranliteration. Most Arabic entries have manual transliterations, they shouldn't be removed, before vowel diacritics are added, that's all. --Anatoli T. ^{(обсудить}/^вклад) 05:39, 5 September 2014 (UTC)

This probably should be a WT:GP question. But to address the question itself, I was actually thinking that we should do the exact same thing. User:CodeCat would know if it does what we want it to do. I was thinking further that if any letter where a diacritic is expected does not have one, then we should return nil. For example بَني would return nil because a diacritic is expected on the ن to distinguish بَنِي from بَنَيْ, and دَم would return nil because the iʿrāb is not specified. But لَا would not return nil because no diacritic is expected on the ʾalif. --WikiTiki89 19:32, 5 September 2014 (UTC)

My thought was to allow final consonants without iʿrāb (which is frequently omitted in otherwise properly vocalized nouns), and to allow a few other cases where things are unambiguous even without diacritics -- specifically, alif or tā' marbuṭa with missing fatḥa before it. This is not intended to encourage people to write things like this but to handle existing usage like كاتِب, which is written as such in the كاتب entry and can be unambiguously transliterated as kātib. (Sorry if this is drifting into an Arabic-specific discussion again.) Benwing (talk) 20:52, 5 September 2014 (UTC)

But doing that would be a way to catch all existing cases and fix them. --WikiTiki89 21:31, 5 September 2014 (UTC)

This is true. I guess it comes down to a compromise between current usefulness and usefulness in fixing. Since I don't see any people currently offering to go fix all the (thousands of) existing cases needing fixing, I'd rather have the iʿrāb-less transliterations there. If someone wants to fix the iʿrāb, they can edit Module:ar-translit and temporarily comment out the lines that allow iʿrāb-less transliterations (there's a comment indicating where to do this). Ideally there would be a way of allowing iʿrāb-less transliterations while still marking them but I don't see how to do it.

BTW in case it's not clear I did implement returning nil on unvocalized text. Hopefully I did it correctly. So far all the places I can find that should have transliterations do. Benwing (talk) 08:07, 6 September 2014 (UTC)

If a transliteration module returns nil, it's equivalent to having no transliteration module at all. —CodeCat 19:34, 5 September 2014 (UTC)

Can we somehow tag it with a category such as Category:Arabic terms lacking transliteration? --WikiTiki89 19:45, 5 September 2014 (UTC)

How would Module:headword know that a transliteration is needed? —CodeCat 20:37, 5 September 2014 (UTC)

Any time a call to the transliteration module returns nil, it should be inserted into a category indicating this, perhaps Category:Arabic terms lacking vocalization; presumably this would be language-specific (for Arabic, maybe Hebrew as well and other languages using Arabic script) or script-specific. Module:links should also do this; it in fact already inserts categories like Category:Terms with manual transliterations different from the automated ones. Benwing (talk) 20:52, 5 September 2014 (UTC)

I think Category:Arabic terms lacking transliteration makes more sense, since it would be difficult for Module:headword to infer the reason for the transliteration failure. This would only apply to Arabic, not other Arabic-script languages, since most of them do not have vocalization systems. --WikiTiki89 21:31, 5 September 2014 (UTC)

I think we should be able to make this more general. After all, we really want transliterations for any language not written in Latin script, right? Whether it's generated or manually supplied is not even relevant, as long as it's there. So maybe we could apply this general rule: if the term is written in a script that is not Latn, Latinx or varieties, then if there is no transliteration, add a category to request one. That way we don't have to make it specific to Arabic. —CodeCat 21:50, 5 September 2014 (UTC)

Did I ever say "Let's make it specific to Arabic so that other languages can't take advantage of this useful feature."? Anyway, jokes aside, I agree, if there is no transliteration then it should be placed in a category, whether it's a headword or just a link. But, I think that if is specified, then the category should not be added, and we need some language-specific exceptions such as for Serbo-Croatian. --WikiTiki89 21:54, 5 September 2014 (UTC)

I also think this is a good idea. CodeCat, could you take a crack at this when you have a chance? I can't do it myself since Module:links is locked. Benwing (talk) 08:07, 6 September 2014 (UTC)

Bracketed ellipses and widowing

A week or so ago I fell sick and faced a time of lassitude and confinement. To counter or alleviate this I decided to undertake a detailed but repetitive Wiktionary project that had suggested itself during my normal occupation of adding quotations to senses, a project that could be done with a dull mind, and sitting up in bed.
 I had noticed that Robert Burton's The Anatomy of Melancholy was frequently and justifiably quoted in various entries, but also that the quotations varied in details and only occasionally (and sometimes wrongly) linked to the two directly relevant Wikipedia entries. So I created a template (Template:RQ:RBrtn AntmyMlncly) to use in sense headings. I've recently finished (I think), and there were over 400 quotations.
 As is my habit, I occasionally made what I saw as minor changes, such as adding full stops (periods) at the end of sense definitions, and making leading letters in those definitions upper case if needed. After I had been doing the project for a few days I became aware that one of the most frequent problems I was fixing was potential widowing. Because of a background in the printing industry going back to the early '50s and the days of moveable type, this was not a minor problem to me. I'll explain.
 A widow, as I was taught it, was several possible things. A line widow, as it was told to me, was the first or last line of a paragraph placed on a separate page from the rest of the paragraph. And this was considered unutterably evil if a word was split by hyphenation across the pages. Of course, in the days of moveable type this could very easily be fixed before the flong was flung. But there are widows at the letter level if mistakes are made in the typesetting, particularly with punctuation because punctuation usually needs to be juxtaposed to a word. These were avoided automatically by typesetters and simple ones are nowadays usually avoided by formnatting software. And line widows are irrelevant to the Wiktionary as running text is not split between separated pages; Keys such as PgUp and PgDn move text on the screen.
 However, the widowing that I became aware of was particular to quotations related to the bracketed ellipses (hereinafter simply called ellipses). It looks as if the {{...}} template was introduced to make ellipses easy to key in. This is just fine if the ellipsis is simply a gap between words, but there is a problem: if the ellipsis is at the end of a sentence or quotation then it needs to be followed by a full stop (period). Unfortunately for the full stop, {{...}} puts a simple space in the display on either side of the ellipsis.
 That it looks bad is not the major problem, which is that the full stop will be split off if it won't fit onto the end of the line, and worse still if the split happens at the end of a quotation. Ordinary users of the Wiktionary will have different line widths, so some would see it even if most wouldn't. Not quite so bad, but bad enough, is the effect of the simple space put in front of the ellipsis which can split the ellipsis from the text it follows, which has a bad effect on the aesthetics and a bit of burden for the readability.

  I have been criticised for making my modifications to avoid these problems and have had some undone. What I am asking for here is to have agreement that something should be done about the problems like the ones I have outlined. If agreement is reached, I suggest that what should be done is to create three new templates
(1) {{..,}} to leave off the trailing blank of the ellipsis,
(2) {{,..}} to replace the leading blank of the ellipsis with a non-breaking space ( ),
(3) {{,.,}} to combine the above two actions.
Note that it would be a mistake to use (1) to add a full stop to the ellipsis as the omission will also be needed for other punctuation, such as the comma.

I've tried to look for what's in the {{...}} template, but have got lost, perhaps because of my medical state, which continues. If something can be done very quickly I would be extremely grateful, as I would like to use another similar project to lighten my oncoming days. — ReidAA (talk) 10:06, 5 September 2014 (UTC)

(First of all, thanks for your work on finding the quotations.) Personally I don't at all like seeing the &.amp; &.hellip; &.nbsp; stuff floating around in an entry (I see you've even used it to format your comments here) and I think it hinders editing. Almost the only one I ever use is &.mdash; and that's because I get tired of having to open Character Map to find the literal symbol. Anyway: IMO, if we need to fix this "widow" problem at all (has anyone else been upset by it, or even noticed it?), then Wiktionary's markup is not the correct place to fix it. It sounds more like something that should be addressed by the CSS (Cascading Style Sheets) standard, surely...? Equinox ◑ 10:16, 5 September 2014 (UTC)

I must plead guilty to sometimes using &.amp; in place of an ampersand and always use &.#0133; in place of an ellipsis - on the assumption (maybe mistaken) that these characters might not show up correctly on some machines. Should I desist? — Saltmarsh^{απάντηση} 10:54, 5 September 2014 (UTC)

I would greatly appreciate any advice on how to achieve the effect of a non-breaking space using CSS. Specifically, I would like to replace many instance of &.nbsp;- with something less intimidating to potential contributors. In the application I have in mind all instances of a dash in a piece of text (a line with no line-breaks other than those imposed by the width of the frame) would warrant such treatment. DCDuring TALK 13:13, 5 September 2014 (UTC)

This discussion seems to be straying from the requests that I started this discussion with. Let me start again with a different tack.
  Someone wrote the (presumably very simple) {{...}} template that seems to have had wide acceptance, probably both by those like me who are concerned with presentation details, and those who are put off by plain HTML code, at least such as uses ampersands.  Furthermore I have been told that the Wikimedia software has trouble handling the directly coded […] ([…]) so that I should use the template, and I have been doing so when no widowing is threatened.
  If there are others like me concerned with presentation effects, and if it would be a simple task for someone with the requisite knowledge to create the three new templates I suggest, what objection is there to creating them so that concerned contributing editors like myself could improve the presentation as we go along making other contributions?  What effect would there be on editors who are not worried about widows?  My work here suggests to me that there is a hell of a lot of such tidying to be done. — ReidAA (talk) 23:07, 5 September 2014 (UTC)

I am not sure that I did this right, but it seems to work. It substitutes a nonbreaking space for what turned out to be an ordinary space. Try it: {{nb...}}. Frankly, if it works, it would seem to be preferred to the original. I can't see why it would ever be right to risk having the [...] widowed. DCDuring TALK 23:26, 5 September 2014 (UTC)

I tried it by simply putting {{nb..}} into an entry I was working on, but it gave an error. Is there something special I need to code to get to your brave attempt? And, yes, I agree about it being better than the original. I can't offhand think of any case where the change would cause problems. — ReidAA (talk) 00:05, 6 September 2014 (UTC)

@ReidAA It is {{nb...}}, not {{nb..}}. If you typed it in with three dots and got an error, leave it there and let me know the entry. DCDuring TALK 00:46, 6 September 2014 (UTC)

@DCDuring Not needed; I took it out when it didn't work.  But, I would prefer the shorter name for elegance; or how about {{nb.}}? — ReidAA (talk) 01:04, 6 September 2014 (UTC)

@ReidAA I'd like to understand in which situations it goes wrong. Maybe I could fix it. DCDuring TALK 01:12, 6 September 2014 (UTC)

This addressed your second requested item. But why not eliminate the trailing space for all cases? What harm could come of having the leading space always be a non-breaking space? DCDuring TALK 23:31, 5 September 2014 (UTC)

Unfortunately there is a lot of existing code that relies on the trailing space being added. Oh, and I agree about the leading space. — ReidAA (talk) 00:05, 6 September 2014 (UTC)

@ReidAA I removed the trailing space for {{nb...}}. The impression I get is that most uses of {{...}} have additional leading and trailing space inserted by users after the template. The wiki software renders the two spaces, one from the user the other from the template as one. I think the problematic entries that would exist if we were to substitute {{nb...}} for {{...}} would be of two kinds. 1., The kind with no space rendered after the template could be found by search for  […] followed by a letter. This wouldn't be so bad for the basic Latin script, but the search would also have to take place for other letters and symbols in other scripts. 2., The kind with an extra space before would need some kind of bot to eliminate the extra breaking space, but the extra space is not very annoying to me. Can you find the extra space on this paragraph? DCDuring TALK 00:24, 6 September 2014 (UTC)

@DCDuring I put two responses in last time; I think you might have overlooked the first.
  Indeed a lot of editors include both leading and trailing spaces with their ellipsis template invocation, but there are also a helluva lot who don't.  Hullo, hullo, I've just noticed that your template has three dots; in my trial I only used two.  When I've finished here I'll go and try again.  Wouldn't the extra preceding breaking space your refer to potentially widow the ellipsis?  Or have I misunderstood you?  Incidentally, I've just imitated your ping at the start of this response.  Is this supplementary or alternative to the watch this page button? — ReidAA (talk) 00:57, 6 September 2014 (UTC)

@DCDuring Well, it works, thanks very much indeed.  When will it be alright for me to start using it?  Do you agree with me about the shorter name(s) though? — ReidAA (talk) 01:14, 6 September 2014 (UTC)

{{ping}} is additional. It lights up the number next to your username at the top of the page. I don't remember if it works across projects.

If we replace insert the altered code into {{...}}, there would be a lot of cleanup to do.

I'd like to keep this five-keystroke name until I know we can't improve it. Your suggestions seem fine, but this might warrant more attention, perhaps at the grease pit.

{{nb...}} should be used without a user-added leading space to avoid the line-break. The user controls what happens after the {{nb...}}. It is by no means idiot-proof.

You could start using it now. It is really fairly simple, probably low risk. If something goes wrong, — stop using it, undo it, and let me know the entry where it went wrong. DCDuring TALK 01:26, 6 September 2014 (UTC)

Then I shall start using it right away.  My tests suggest to me that, since I understand it well (I think), there will be no problems.  My very small experience with RQ templates included the (somewhat obscure) creation of documentation to go with them.  Your code for nb... looks very opaque to me, but would you like me to try to create documentation for its use?  Again, thanks very much for your cooperation and work. — ReidAA

It is not really my code. All I did, starting from a copy of {{...}}, was substitute a nonbreaking space for the ordinary space at the leading position and delete the trailing space. I really couldn't have started from scratch. DCDuring TALK 04:31, 6 September 2014 (UTC)

Well done. I'll put some documentation together in a little while and let you know. — ReidAA (talk) 04:36, 6 September 2014 (UTC)

@DCDuring Template documentation added at Template:nb.../documentation. You might like to look it over and improve it. — ReidAA (talk) 07:00, 6 September 2014 (UTC)

@ReidAA I added Category:Text format templates to both {{nb...}} and {{...}} and referenced {{nb...}} in the documentation for {{...}}. There might be some now-unnecessary CSS stuff in {{nb...}}. DCDuring TALK 13:02, 6 September 2014 (UTC)

@DCDuring Thanks very much.  Great work!  And I've found it useful several times already. — ReidAA (talk) 23:20, 6 September 2014 (UTC)

Proto-Hellenic and Proto-Greek

Although we tend to think of Greek as a single language, it's actually a family of languages, and those languages have a common ancestor. According to Wikipedia, what is reconstructed as "Proto-Greek" usually includes all Hellenic dialects, including Mycenaean, but not the rather divergent Ancient Macedonian. One noticeable point of early divergence in AM is that the aspirates have voiced reflexes in some cases in AM while they are always devoiced in the rest of Hellenic. Unless Mycenaean underwent a re-voicing, this would have to indicate that their common ancestor still had voiced aspirates as they were inherited from Proto-Indo-European.

So this would mean that a hypothetical Proto-Hellenic, including Macedonian, would have to have voiced aspirates, while Proto-Hellenic-minus-Macedonian would have voiceless aspirates. The problem is how to define the Hellenic language family, and how people reconstruct it. Wikipedia notes that people may or may not include Macedonian in the reconstruction, but generally do not. Of course, if we include such reconstructions, we can't really call them "Proto-Hellenic" because they're missing one branch. So what should we call them? If we call them "Proto-Greek", then we would need to invent a new language family for the non-Macedonian branch of the Hellenic languages, make up a name for it (if we use "Greek" it would cause confusion with the language) and also a code. —CodeCat 23:28, 6 September 2014 (UTC)

Is there really that much consensus that Macedonian shares a common ancestor with Greek later than PIE? I would say we should treat Proto-Hellenic as identical to Proto-Greek and leave Macedonian out of it altogether to be on the safe side. —Aɴɢʀ (talk) 13:01, 7 September 2014 (UTC)

I think there is a fair consensus, at least judging by Wikipedia sourcing. But after having looked at it, there are some common innovations that appear to show that if it wasn't Greek, it was closely allied with it. At the very least, it was still similar enough to Greek that it took part in common sound changes, such as the loss of -y- intervocalically and the change of final -m to -n. w:Ancient Macedonian language shows various classifications that have been made over time. To me, the first and last proposals are the most plausible, and note that some sources call the combination of Greek + Macedonian "Greco-Macedonian" while others call it "Hellenic". So we have to make sure we check how each source understands the terms "Greek" and "Hellenic" before using them as references. In any case, if we do treat Proto-Hellenic as not including AM, then we also need to change the family of AM because it's currently included in Category:Hellenic languages. —CodeCat 13:12, 7 September 2014 (UTC)

I've written a basic draft for Wiktionary:About Proto-Hellenic. Can other editors review it and comment on it? —CodeCat 12:30, 8 September 2014 (UTC)

Oh look - even more legitimate etymologies vandalized by CodeCat's original research. Will this nightmare ever end? --Ivan Štambuk (talk) 18:08, 8 September 2014 (UTC)

Oh look, even more personal attacks from Ivan. Will this nightmare ever end? —CodeCat 19:59, 8 September 2014 (UTC)

CodeCat, what are your sources for reconstructions like *éhər. Also, how is it useful? All its content can be presented at ἔαρ (éar) without duplication. --Vahag (talk) 20:18, 8 September 2014 (UTC)

I agree with Angr that we should not distinguish Proto-Hellenic from Proto-Greek. Wikipedia does not seem to support such a distinction, specifically noting in w:Hellenic languages that most researchers consider them identical. This could happen either if Ancient Macedonian is considered to be a descendant of Proto-Greek or to be outside Proto-Hellenic entirely. The Wikipedia page on w:Ancient Macedonian language describes it as a dialect of Northwest Greek (i.e. a Proto-Greek descendant) but also notes that it's not well-attested. The supposed need for a distinct Proto-Hellenic hangs from a pretty thin thread, IMO -- one single sound change (which Wikipedia identifies as happening "sometimes") in a barely-attested language along with a clear lack of scholarly consensus. As a result I really think that it needlessly complicates the picture to create a Proto-Hellenic separate from Proto-Greek, which is going to have identical reconstructions to Proto-Greek except for mechanically substituting voiceless aspirates with something else. If you want to include AM forms, you should probably just list them under Proto-Greek.

As for the sound changes themselves, there's nothing a priori impossible about a revoicing of aspirates to voiced stops, i.e. there's not really any strong evidence that AM wasn't a Greek dialect. And your examples of common sound changes between AM and Greek don't rule out AM being outside of Proto-Hellenic: The loss of intervocalic -y- and change of -m to -n could easily be areal phenomena, or simply independent changes, esp. -m to -n, which occurred in many different IE branches. Benwing (talk) 21:32, 8 September 2014 (UTC)

The w:Proto-Greek page lists several sound changes that must have occurred after Grassmann's law, and the devoicing of aspirates is one of them. AM didn't appear to have aspirates (or at least they weren't written for us to see?), so it seems that this important identifying feature of Greek did not affect AM. It also implies that any pre-stage of Proto-Greek that would include voiced aspirates would also lack Grassmann's law, as well as palatalization, so it would be much closer phonologically to PIE; basically PIE minus laryngeals. —CodeCat 21:44, 8 September 2014 (UTC)

The devoicing of aspirates occurred before Grassmann's Law. And the list you present isn't necessarily chronological (BTW I wrote most of that list). But I don't see what any of this has to do with whether there should be separate Proto-Hellenic reconstructions, which I don't think makes sense. And as I said before there's no evidence that AM's voiced sounds weren't secondary or due to substrate influence or whatever. Benwing (talk) 02:27, 9 September 2014 (UTC)

Italic and transliterations

Hi,

I noticed that in the section of translations and for the headline, transliterations are not in italic, while they are in the section of etymology. It's not very important but I'm curious: is there a reason to that? Thanks by advance. — Automatik (talk) 02:00, 7 September 2014 (UTC)

That's odd- I see the opposite (удар (udar) (no italic), удар (udar) (italic)). DTLHS (talk) 02:14, 7 September 2014 (UTC)

Sorry, my mistake. I fixed it. — Automatik (talk) 04:08, 7 September 2014 (UTC)

Layout of IPA in the editing tools

Currently there doesn't seem to be a very clear method to how the IPA characters are arranged in the edit tools (below the edit window). This makes many of the characters hard to find as you basically have to look through the whole list, sometimes several times. So I'd like to propose that the characters be arranged in the standard IPA table format, like on WT:IPA but perhaps more compact. —CodeCat 13:45, 7 September 2014 (UTC)

Certainly more compact; there's no need to include the IPA characters that are also basic ASCII characters. (I believe that set consists entirely of the 26 lowercase letters of the English alphabet.) —Aɴɢʀ (talk) 15:03, 7 September 2014 (UTC)

Then there would just be gaps in the table. We might as well include them if the space goes unused otherwise. —CodeCat 15:37, 7 September 2014 (UTC)

The most helpful layout for a non-linguist editor would be per language: letters in alphabetical order, the IPA symbol immediately after each letter. E.g. for Hungarian: Aa /ɒ/ Áá /aː/ Bb /b/ Cc /t͡s/ Cscs /t͡ʃ/, etc. Since there are more than 1500 languages in this wiki, this might be a very long list in the drop-down, but this could be solved if editors could select a small number of alphabets to appear in the drop-down; the ones they are actually using, let's say between 1 and 15. This could be added to the preferences. --Panda10 (talk) 16:35, 7 September 2014 (UTC)

Surely people who are editing in a language are at least able to name the script it uses? —CodeCat 17:09, 7 September 2014 (UTC)

Automatic pronunciation templates

We now have a fair number of templates that automatically generate pronunciation information in IPA based on the spelling of the headword and/or an orthographic representation given as a template parameter. The ones I'm aware of are:

• {{es-pronunc}}
• {{grc-ipa}}
• {{grc-ipa-rows}} (an older, non-Lua version of the above)
• {{hy-IPA}}
• {{hy-pron}} (which transcludes the above)
• {{ka-IPA}}
• {{la-pronunc}}
• {{pl-IPA-auto}}
• {{ru-pron-auto}}
• {{uk-pron}} (which has to be inserted inside {{IPA}})
• {{vi-pron}}

There may be others; not all of the above are included in Category:Pronunciation templates, so maybe there are more that aren't there. (There's also {{fa-pron}}, which doesn't actually give pronunciation information, and {{liv-IPA}} which requires manual input of IPA rather than generating it automatically.) If you know of others that I haven't listed above, please add them.

The first problem is that these templates are not all gathered into a single category. Is Category:Pronunciation templates sufficient, or should there be a more specific category like Automatically generated pronunciation templates for them?

The second problem is that there is no uniformity of naming. Some are called "xy-pronunc", some are called "xy-IPA" (or "xy-ipa"), some are called "xy-pron" (particularly bad since other templates called "xy-pron" are headword line templates for pronouns), and some have "-auto" appended to the end. Ideally, there should be a uniform name for these; my preference is for "xy-pronunc", but what do others think? —Aɴɢʀ (talk) 14:55, 7 September 2014 (UTC)

I think we should name them {{xx-IPA}}. This resolves the pronoun problem and leaves room for the theoretical possibility of counterparts outputting something other than IPA. --WikiTiki89 13:44, 8 September 2014 (UTC)

Some IPA templates names differ in usage, e.g. Korean {{ko-pron}} is to display the user written IPA and {{ko-pron/auto}} is automatic. (There are also a number of templates for Chinese (Mandarin, Cantonese, Min Nan, etc.) and a Japanese template, which weren't listed above.) --Anatoli T. ^{(обсудить}/^вклад) 05:54, 9 September 2014 (UTC)

Also {{fa-pronunciation}} (takes transliteration as input; not Lua-ized) --Z 08:54, 9 September 2014 (UTC)

Workshop: Greek and Latin in an Age of Open Data

This event, at the University of Leipzig in December, may be of interest: Workshop: Greek and Latin in an Age of Open Data. It would be good to have somebody there to represent and speak about Wiktionary and Wikidata. Pigsonthewing (talk) 16:00, 7 September 2014 (UTC)

ORCID and other identifiers

People who edit Wiktionary should be able to show w:ORCID (and other forms of w:Authority Control, such as w:VIAF) on their user pages, as explained at w:WP:ORCID.

The template d:Template:Authority Control allows this. Can someone with the relevant bit please use Special:Import to import it and all its sub-templates (or set the bit, temporarily, to allow me to do so)? I'll then be happy to do the documentation and set up some examples. Pigsonthewing (talk) 16:15, 7 September 2014 (UTC)

@Pigsonthewing Assuming you meant w:Template:Authority control (d:Template:Authority Control doesn't seem to exist), I imported it to Template:authority control. However, I didn't want to import the complex modules it depended on — like (apparently) w:Module:Arguments, which is probably written according to different coding conventions than are used here, and possibly also redundant to things here — and the template was being waaay more complex than it needed to be by depending on modules, anyway, so I simplified it dramatically. If someone wants to prettify it a bit so that parameters which are not set simply don't display, rather than displaying "—", they can feel free to do that. - -sche (discuss) 02:34, 10 September 2014 (UTC)

Thank you, - -sche. I actually meant d:Template:Authority control (lower-case "c"). Your version has removed both the links to articles about the authority control type (like w:VIAF, w:ORCID, but also to the authority control databases, (like https://viaf.org/viaf/70042340 and http://orcid.org/0000-0001-5882-6823 ). For a comparison, look at my user page here, and on en.WP. Please will you look to importing the Wikidata template instead, which has the latter links, and a version of the former (which I will then update), and hides empty parameters? Pigsonthewing (talk) 21:10, 14 September 2014 (UTC)

@Pigsonthewing Ah, I see. Well, I didn't notice this before, but it seems that en.Wiktionary cannot import pages from Wikidata. (Compare how en.WP cannot import pages from en.Wiktionary.) The wikis which our Special:Import is configured to allow importation from are w, b, s, q, v, n, commons, and a long list of other-language Wiktionaries. I can think of a couple of ways around this. One is to get approval for en.Wikt to import Wikidata pages; I suppose the avenue for that would be bugzilla. Another is to copy whatever revision of the Wikidata template you want, using your edit summary to explain what you were doing and to direct users to see the Wikidata page for its history and contributors. - -sche (discuss) 22:54, 14 September 2014 (UTC)

@-sche: Thanks; in that case, I'll do the latter (I was just hoping to preserve the edit histories). Before I do, would you like to delete your imports, or shall I just overwrite them? Pigsonthewing (talk) 18:05, 15 September 2014 (UTC)

You can just overwrite them. - -sche (discuss) 18:17, 15 September 2014 (UTC)

@-sche: OK, that's done; see Template:authority control. I'm out of time now, but tomorrow I will work on the documentation, examples and styling. In the meantime, please see the instance on my user page. Pigsonthewing (talk) 21:03, 15 September 2014 (UTC)

Update

The template is now working. It can be styled horizontally (like on Wikipedia - see my user page on en.WP) or left as it is. To do the former, we'd need to copy the rules for the class hlist from en.WP's Common.css

Next, we need to think about how to encourage contributors to display their authority control IDs on their user pages; and if appropriate to register for an ORCID identifier. How can I get a line added to Wiktionary:News for editors? Pigsonthewing (talk) 15:11, 16 September 2014 (UTC)

I've solicited others' input on whether to copy en.WP's hlist rules or not.

I can add a blurb to WT:NFE. What should it say? "Template:authority control exists and allows users to specify their authority control numbers." ?

- -sche (discuss) 20:10, 16 September 2014 (UTC)

Requests for verification of pronunciation

Occasionally I come across entries where I suspect the pronunciation listed is erroneous. Where can I request verification of suspect pronunciations? We have Wiktionary:Requests for verification but that seems to be for verifying meanings only, not for verifying pronunciations. —Psychonaut (talk) 14:18, 9 September 2014 (UTC)

All I can think of is to use the {{attention}} tag, or take a specific issue to the Tea room. —Aɴɢʀ (talk) 14:48, 9 September 2014 (UTC)

We have {{rfv-pronunciation}}. —CodeCat 16:58, 9 September 2014 (UTC)

Which categorizes entries into "Category:Xyz entries needing reference", but AFAICT all such categories are red. Category:English entries needing reference is at any rate, and adding {{poscatboiler|en|entries needing reference}} creates an error. —Aɴɢʀ (talk) 13:13, 13 September 2014 (UTC)

They haven't been created yet because there's a discussion at WT:RFM about what to name them. Please join in! —CodeCat 13:18, 13 September 2014 (UTC)

The trouble with joining in that conversation is that I don't care what they're named as long as a name gets picked soon. —Aɴɢʀ (talk) 14:33, 13 September 2014 (UTC)

I think I'll just create the categories for now, and delete them once a conclusion is reached. That way things aren't left hanging in the air while people decide. —CodeCat 19:25, 15 September 2014 (UTC)

Change in renaming process

Single-user login (SUL) finalisation's goal is so that every Wikimedia editor has a single, recognized global account with one username across all projects. As you may know, after a long delay, it's now underway as an effort between bureaucrats, stewards, and Wikimedia Foundation engineers. This will also allow for development of cross-wiki tools like global notifications and watchlists. There is no set date for the completion of single-user login finalization at this time.

The process involves changing all rename processes into one global renaming process. The ability for local bureaucrats to rename users on this wiki will be turned off on Monday, 15 September 2014, as one of the first steps. Global renamers are in the process of being created to make sure projects and languages are represented by the time this occurs. I sent a note to every bureaucrat about this process three weeks ago with an invitation to participate and many have begun requesting to be a part of the group. Together with the stewards, the global renamers will be empowered to help editors work through the often difficult process of getting a global name.

In parting, visit Special:MergeAccount to unify your account if you have never done so. If your local pages about renaming still need to be updated, please do so and consider pointing people to m:SRUC for future rename requests, especially if this project does not have bureaucrats that hold global renamer permissions. If you have any questions, you can read more on the help page on Meta. You can also follow the technical progress on mediawiki.org. Contact me on Meta any time with questions as well. Thank you for your time.

-- User:Keegan (WMF) (talk) 16:22, 9 September 2014 (UTC)

Sant Bhasha

Apparently, a user that goes by the username Bhvintri (talk • contribs) says/claims that the word ਸੋਚੈ is of a language called Sant Bhasha. Should we make a code and category for such a language? --Lo Ximiendo (talk) 19:31, 10 September 2014 (UTC)

Can we wait for someone to comment before deleting the entries? DTLHS (talk) 00:56, 11 September 2014 (UTC)

I wasn't aware of this discussion, and the user kept creating more of them. I deleted them to try to limit the damage as every single one of them was badly formatted, and in any case we'd need to update them all if a code is assigned. —CodeCat 01:08, 11 September 2014 (UTC)

The Wikipedia article (w:Sant Bhasha) seems a bit confused about what this really is: is it a lingua franca, a conlang, or a grab bag of various similar lects used to communicate between members of a particular stratum of society who otherwise don't speak the same languages? Chuck Entz (talk) 02:51, 11 September 2014 (UTC)

Literally, it means "Saint language". I had not heard of it before, but I believe it is like the Slavic esperanto that any group of people who come from each of the Slavic-speaking countries (Russian, Poland, Ukraine, Serbia, Czech Republic, Slovakia, Belorusia, Bulgaria) naturally fall into in order that everyone can speak to and understand everyone else. In the time of Germany’s w:Martin Luther (early 1500s), the German theologians, philosophers, and other writers from various parts of Germany, all speaking different dialects of German, did much the same thing, which is where today’s Standard High German comes from. —Stephen ^(Talk) 03:18, 11 September 2014 (UTC)

I think calling it an "Esperanto-like language" is misleading. It doesn't seem to have been deliberately constructed by someone. I think it's much more like a lingua franca. The Wikipedia article on Sant Bhasha is very confusing, but the article on the Guru Granth Sahib says more clearly, "It is written in the Gurmukhī script, in various dialects – including Lehndi Punjabi, Braj Bhasha, Khariboli, Sanskrit and Persian – often coalesced under the generic title of Sant Bhasha." That leads me to believe that Sant Bhasha doesn't require a code of its own, because all of the words appear in some other language, i.e. ਸੋਚੈ is a word of Lehndi Punjabi, Braj Bhasha, Khariboli, Sanskrit and/or Persian, although perhaps only written in Gurmukhi when it's being used in Sant Bhasha. (Is the phonetic similarity between sant and saint/santo a coincidence?) —Aɴɢʀ (talk) 07:01, 11 September 2014 (UTC)

Hi There! I will stop making any new entry unless this matter is resolved.
Now why we need separate entry for Sant Bhasha. Here are my points in favour of it:
1.) There is a bulk of literature written in it by number of writers. I am listing few of them.
a. Guru Granth Sahib - Note it is a combined work of more than 30 authors.
b. Dasam Granth
c. Varan Bhai Gurdas
d. Panth Parkash
e. Suraj Parkash
2.) The languages from which it draws its vocabulary: Punjabi, Hindi, Marathi, Sindhi, Apabhramshas, Sanskrit or Persian, none of them use Gurmukhi Alphabet except Punjabi. Here it is not logical to put Sanskrit, Persian or Hindi language words in Gurmukhi Alphabet. The same logic why we need to put the word 'algebra' under English in Latin Alphabet, when we already have an entry for this word under Arabic in Arabic Alphabet. Why we need the words borrowed from Latin under different languages, when they are already explained under Latin ?
3.) Most important point is that we a bulk of word-forms where the root word comes from different language and its declension or conjugation is derived from different language. eg in ਸੋਚੈ 'sochai', root-word 'soch' could have been borrowed from Punjabi, whereas declension -ai is derived from Sanskrit instrumental plural -aih. So where should we put this word under Punjabi or Sanskrit?

Q-Is the phonetic similarity between sant and saint/santo a coincidence?
A-Maybe Latin sanctus and Sanskrit santa originated from same Indo-European root.Bhvintri (talk) 00:32, 12 September 2014 (UTC)

• Are there any grammars or dictionaries of it, or it's just a literary language of a fixed number of works? I think that it should be mandatory to have citations for any added words for obscure cases such as this one, so that it's easier to clean them up in the future (e.g. if it is decided to treat it as a form of some other Middle/Modern Indo-Aryan language). --Ivan Štambuk (talk) 10:02, 13 September 2014 (UTC)

This is what wikipedia says under Sacred language:

http://books.google.com/books?id=Itp2twGR6tsC Indo-Aryan Languages by Colin Masica also attests it on page 57 as:

Grammars:
'An Introduction to the Sacred Language of the Sikhs' by Christopher Shackle is a book on the grammar of this language. But unfortunately I can't find it online. http://www.amazon.com/An-introduction-sacred-language-Sikhs/dp/B0007BRI5W
In Indo-Aryan Languages (edited by Geroge Cordona and Dhanesh Jain) http://books.google.com/books?id=OtCPAgAAQBAJ on page xxi it is listed as 'Language of Adi Granth' (note: Adi Granth is another name for Sikh holy scripture Guru Granth Sahib), separate from Punjabi or Hindi. Further from page 656 to 672, Christopher Shackle has given a Declensions and Conjugations of its nouns, pronouns, adjectives and verbs and compared them with Modern Punjabi.
Dictionaries:
The most famous dictionary of this language is Mahan Kosh published in 1930 and then republished in 1981.
Mahan Kosh and other online dictionaries of this langiage can be found online at many links like this: http://www.srigranth.org/servlet/gurbani.dictionary
Bhvintri (talk) 19:39, 13 September 2014 (UTC)

Pronunciation needs to be at level 4 for Arabic

WT:ELE claims that pronunciation ought to be at level 3, above individual entries for nouns, verbs, adjectives, etc. Apparently, cases like duplicate where the pronunciation differs by part of speech are handled by listing the part of speech under the pronunciation section, above the corresponding pronunciation. But this fails entirely for Arabic, where a single page may have e.g. two nouns and three verbs on it, each with a different pronunciation (because the vowels are omitted in writing). In fact, it's rarely the case that two different part-of-speech entries will share the same pronunciation. As a result it seems clear to me that pronunciation for Arabic needs to go at level 4. But where exactly? I think the most obvious thing is to place it directly above the definition, possibly without any preceding header.

Note also that the current naming scheme for the .ogg pronunciation snippets is totally broken because it's named for the page title (without vowels), meaning that there's no way with this naming scheme to have separate pronunciations for two different subentries on the page, much less five or six. Benwing (talk) 06:28, 12 September 2014 (UTC)

This is a side-effect of the problem of etymologies in Arabic (both diachronic i.e. from Proto-Semitic, and synchronic i.e. from root x-y-z) - they usually refer to a one specific PoS using one specific derivational mechanism, but are instead usually grouped as if referring to all of them. After splitting by individual etymologies, pronunciations should come at level 4 naturally. These are left at level 3 for now until someone knowledgeable comes along. --Ivan Štambuk (talk) 15:22, 13 September 2014 (UTC)

Cleaning company spam

We're getting quite a lot of this lately (one every day or so?). It advertises various cleaning companies in the UK, in e.g. Brent and Enfield. I added a filter thing to prevent the original spam message, which can also be found on other sites with the same wording, but they seem to have changed to another one. Further filtering would be welcome, as this spammer is creating a lot of accounts — one useful thing might be that the word "clean" appears in many of the user names. Equinox ◑ 15:05, 12 September 2014 (UTC)

Chinese Character Composition

During my studies of Chinese I thought it would be useful to be able to look up characters by their components, not limitted to the traditional radicals. I saw that wiktionary already has some of this information and I used it as a starting point.

Altogether I decomposed more than 14,000 characters, traditional and simplified. My decomposition also provides locational information of the components in the characters.

See http://bioinfoc.ch:8081/languages/HanziComp for an application that uses the composition information. The Help link gives a short introduction.

The format of what I could provide is like this:

児 t:131/2s,b:r10 er2

兑 =11/3 =(t:r12a,b:11/2) s7 dui4

兒 =r10a =131/14 =(t:r134,b:r10) s8 er2 r5

兔 =164/1 =(a) s8 tu4

兕 t:69/118,b:r10 si4

兖 t:29/57,b:11/27 yan3

兗 t:29/57,b:11/2 yan3

兘 o:11/13,i:58/6 shi3

兙 o:152/1',i:r24 shi2 ke4

党 =63/32s =(t:200/105,b:11/2) s10 dang3

兛 o:152/1',i:10/3 qian1 ke4

The three fields are: Character Composition Pinyin

The composition field can also name components that are used in other characters: =rNNN traditional radical =NNN/NNN name used in Chinese Characters: A Genealogy and Dictionary (English and Mandarin Chinese Edition) [Paperback], Rick Harbaugh (Author) (http://www.zhongwen.com/)

Some of the named components are atomic =(a) Others are further decomposed, e.g. =(t:r134,b:r10) All of the named components have the number of strokes sNNN

I'm sure that my analysis still contains errors (but I checked it in multiple ways for consistency), some questionable assignments or incomplete decompositions.

Anyway, is there interest from your side to integrate this information into wiktionary in order to make it available to a broader audience? I would be able to put more work into this and give you the information in any format.

Birds in English

Hello,

In the Finnish version we have many articles on birds. However, we have yet to decide a naming policy, and I came here to ask your thoughts. I've noticed, that here birds names are in small caps, for example coal tit. In the Finnish version we have both fi:coal tit and fi:Coal Tit and this is somewhat problematic. In ornithology, caps seem to be used: http://www.worldbirdnames.org/english-names/spelling-rules/capitalization/. So, how should we write English bird names in the Finnish version? Of course, we would ideally want the interwiki links to work, so also a common naming policy could be sought after. Suggestions? --Hartz (talk) 16:18, 13 September 2014 (UTC)

It’s up to you guys, but my suggestion is to include all attested spellings. — Ungoliant ^(falai) 16:49, 13 September 2014 (UTC)

(edit conflict) Naming policies are for Wikipedia (where there's a good bit of debate on the subject). Wiktionary goes by usage: in theory, the spelling/capitalization that's used most should be the main entry, and any others attestably in use should be alternative forms. In practice, though, the one that's created first tends to be the main article, and I'm not sure if the "most used" criterion has ever been explicitly made a policy. Information about which capitalization is used in which contexts would be good information for usage notes. If we were consistent enough with our context labels, we might indicate it that way, but people tend to use "zoology" or "ornithology" for any word having to do with animals or birds rather than just for words used by ornithologists or zoologists. Chuck Entz (talk) 16:51, 13 September 2014 (UTC)

• I find there is a conflict between building a good set of substantive entries of such kind and having entries that are true to the most common orthography, which may differ by the source of whatever list or source the contributor was working from, contributor personal preferences, or even actual frequency research. Perhaps frequency of use should govern in principle, but it is a counsel of perfection that may stand in the way of good substance. Almost whatever reasonable two-part spelling a user types in will cause the search engine will find any two-part spellings in the wiki (including hyphenated forms, eg coal-tit, Coal-tit) and place them at the top of the headword-not-found page. Even a single-word spelling would be found, eg coaltit. But for regular users and contributors consistency of orthography makes it easier to know whether there is a substantive entry for a given vernacular name. The tedium of determining which is the more common form seems to me to far outweigh the benefits-in-principle, which seem quite modest relative to the benefits in practice IMO.

A possible practical solution would be to have standardized spelling for all main entries, but indicate the most common orthography among the alternative forms/spellings at the top of the entry. DCDuring TALK 20:20, 13 September 2014 (UTC)

• The English Wikipedia engaged in a lot of bickering for a long time regarding how to capitalized birds' names, e.g. "rusty blackbird" / "Rusty Blackbird". Finally, recently, a broad (site-wide?) RFC — which NB was judged by an admittedly pro-uppercase editor — determined that birds' names should be lowercase, because they are lowercase in most cases (e.g. in general books about subjects like home decor which happen to mention that a tapestry depicts a rusty blackbird; in works of fiction; in general reference works; etc — in other words, in general use) and it is only in some specialist works on the subject of ornithology that bird names are capitalized, and in those cases, the capitalization is equivalent or akin to honorific capitalization or to the old English practice of capitalizing Important Words. As far as I know, Wiktionary has long used lowercase for that same reason. (Wiktionary and Wikipedia have both always used lowercase for animals other than birds, e.g. rusty tinamou.) Compare how several armed forces uppercase their rank terms and other terms, e.g. "Private", "Sailor", "Ship", etc, but we have just "private", "sailor", "ship", etc. Whether you want to include redirects from other case-forms is up to you. Wiktionary does not use redirects for things like "Ship"; I don't know of any examples of Wiktionary using redirects for birds' names, but I can't rule out that some exist, and I express no opinion at this time on whether or not such redirects should exist. - -sche (discuss) 20:10, 13 September 2014 (UTC)

Official wordlists for specific fields

There are prescriptive lists of common names for some taxonomic groups issued by various scientific and other organizations, e.g. the w:International Ornithological Congress has a list at www.worldbirdnames.org. These obviously aren't a factor as far as CFI, but it might be worthwhile to have categories and/or reference templates to indicate that a name is designated as the preferred name in a given list. I don't think appendices are that good of an idea, since they would duplicate lists available elsewhere online. The IOC list would fit nicely in our current topical framework, since it covers multiple languages, but I believe there are some that only cover a given language in a given region.

I would appreciate any suggestions on how to represent this information, since these lists would be a good way to expand our coverage of names for living things, and some are available online in formats that could be used for mass importation of entries if anyone who knows how is so inclined. Chuck Entz (talk) 17:43, 13 September 2014 (UTC)

A good representation is to create an entry for each bird. I'm sure many already exist. This Excel spreadsheet has a lot of good information and this would be a lot of work. A bot could create the missing English entries, add the given translations, and create the FL entries. The English bird names are all capitalized in the spreadsheet, though. --Panda10 (talk) 18:46, 13 September 2014 (UTC)

We have more than 5200 Translingual bird name entries that use {{R:Gill2006}}, thereby indicating recourse to the IOC publication. These usually contain little more than the English vernacular name, not even that for many genus names. Remarkably that template does not appear in many (any?) English vernacular name entries.

Mass importing might be nice once we agree on a desirable format, which need not be very difficult. I have been working on a more demand-oriented approach for taxonomic names and corresponding vernacular names, but mass-import is good. Spreadsheets are easy to work with for reformatting, so capitalization need not be a problem if we agree on a simple policy of importing in a standard capitalization, leaving the more time-consuming business of determining more frequent capitalization, by date, usage context or whatever, for future generations of contributors with even more powerful tools and resources.

Isn't there also an international bird-watchers body that has different naming ideas? DCDuring TALK 21:39, 13 September 2014 (UTC)

Renaming rhyme pages

I have noticed rhyme pages have been renamed, such as from Rhymes:Czech:-alɪ to Rhymes:Czech/alɪ. I object and ask that they be renamed back. I cannot find the Beer parlour discussion for this. --Dan Polansky (talk) 07:25, 14 September 2014 (UTC)

Note that I am the creator of more than 1000 comprehensive Czech rhyme pages.

I object to subcategorization; I ask that all Czech rhyme pages be found in Category:Czech_rhymes, as they were before not too long. --Dan Polansky (talk) 07:28, 14 September 2014 (UTC)

• FYI: Wiktionary:Votes/2014-09/Renaming rhyme pages. --Dan Polansky (talk) 17:32, 16 September 2014 (UTC)

Wiktionary:Requests for moves, mergers and splits

I think Wiktionary:Requests for moves, mergers and splits does more harm than good. Proposals are being made there that affects more than 1000 of pages. Such proposals should IMHO be made in Beer parlour. For one-off moves of single mainspace pages, WT:Tea room should suffice. I think whenever someone makes a proposal there affecting a volume of pages, the proposal should immediately be rejected as being made via a wrong venue. In the ideal hypothetical world, the page would probably be deleted. --Dan Polansky (talk) 08:56, 14 September 2014 (UTC)

Maybe we should merge all the forums into your talk page so you won't miss anything, because, obviously, there's nothing more important than keeping you informed. Never mind that it's been the designated forum for this kind of thing for years- you missed out on something because you weren't paying attention to it, so it has to go. NOW!!! Chuck Entz (talk) 15:01, 14 September 2014 (UTC)

Wrong. I found the forum annoying when it was created back in 2010. It is now doing tangible harm. --Dan Polansky (talk) 18:28, 14 September 2014 (UTC)

Rhyme pages and subcategories or subcategorization

Dutch rhyme pages have subcategories. You can browse them from Category:Dutch rhymes and see how useful or not these are.

• I oppose creating such subcategories for Czech rhyme pages.
• I oppose that an editor not working on rhyme pages for a particular language creates rhyme subcategories for that language without having express support for doing so from editors working on rhyme pages for that language.

Subcategories for rhymes are a fairly useless form of organizing rhyme pages, IMHO. My idea of a useful organization of rhyme pages can be seen at Rhymes:Czech, which uses tables AKA matrices rather than a hierarchical tree, which is what categories present. Worse yet, subcategories do not present the hierarchical tree at a glance; rather, you have to click through them one at a time to see their content; even by clicking them one at a time, you won't see the larger picture.

--Dan Polansky (talk) 09:10, 14 September 2014 (UTC)

Please make RFE & RFP mandatory

Requests for etymology and requests for pronunciation should be common practice. Contributors should have the luxury of being able to facilely go through catalogues of terms that are without etymology or pronunciation. It facilitates navigation and accelerates labour. Concerning etymology, exceptions can be made for some noncanonical entries and some alternative forms, but that is about it. --Æ&Œ (talk) 07:16, 15 September 2014 (UTC)

Every lemma entry should have under those headers either good content or a link to an entry that has such content.

But I don't think universal use of {{rfp}} and {{rfe}} will lead to more good content under the headings. Perhaps it would be nice to make sure that all lemma L2 sections have Etymology and Pronunciation headers to reduce tedious typing for those who would add the content. IMO it is more important to find out which entries actually have motivated a specific individual request. It might be nice even to have a mechanism for votes supporting such requests on specific entries.

I would strongly favor creating lists (even just counts) of lemma L2 sections that lack pronunciation headers, etymology headers, translation headers and, more importantly, those that have the headers but lack actual content under those headers. DCDuring TALK 15:12, 15 September 2014 (UTC)

• Block this troll already. This is not a sane proposal, and the troll knows it very well. --Dan Polansky (talk) 17:17, 15 September 2014 (UTC)

The French Wiktionary always uses {{rfp}} (well the nearest equivalent). Admittedly the total number of entries that use it is in the hundreds of thousands, probably over a million. Renard Migrant (talk) 22:13, 15 September 2014 (UTC)

What exactly is the point of a request category with millions of members? DTLHS (talk) 22:17, 15 September 2014 (UTC)

Maybe we should start making a distinction between entries for which something is requested, and entries which are merely lacking something? —CodeCat 22:27, 15 September 2014 (UTC)

That's what I was trying to get at. I was thinking that lists of entries lacking pronunciation headers or lacking etymology headers would be good applications of dump-processing. I would think they would be most helpful for English one-word lemmas. DCDuring TALK 23:50, 15 September 2014 (UTC)

We have 369K members of the English lemma category, 89K mainspace entries that contain both "English" and "pronunciation" (so, probably an overestimate of entries with English Pronunciation headers) and 1K English rfps. It seems that the English lemma category includes many abbreviations, plurals, multi-word terms, and other items for which pronunciation and etymology are not necessarily worth any significant effort. DCDuring TALK 00:05, 16 September 2014 (UTC)

I found nothing strange in the request. The requests would not be manageable but it's not a reason for blocking or ridiculing. As for the request itself, I oppose it. We have a huge number of such requests already. We're lucky to have an entry for a term - with an English translation.

Etymology: I actually find Korean entries a good example - the etymologies are split roughly by Sino-Korean (40-60%), native (about 35%), loanwords from European languages (5%). Having something like "native + language name" is already informative. For Slavic, Germanic, Romance, etc. the minimum info could be "Slavic", etc.

Pronunciation: For languages such as Czech, etc. pronunciation can be automated but someone has to create a module. Languages, such as English could use a phonetic respelling to get automatic IPA, look at Persian or Chinese which use transcription to get IPA. --Anatoli T. ^{(обсудить}/^вклад) 00:19, 16 September 2014 (UTC)

Category:Terms needing transliteration by language

I've not spotted this one before but, some of these use [[:Category:<langname> needing transliteration]] and some use [[:Category:<langname> lacking transliteration]]. Even worse, some use both and split the entries over two categories. Purely because of the name of the parent category, could we align these into [[:Category:<langname> needing transliteration]]? For our purposes lacking and needing are synonymous. Renard Migrant (talk) 22:12, 15 September 2014 (UTC)

large page navigation

When I’m loading a large page, I have to wait approximately one minute for the content to load just so that I can see the languages that I’m interested in. The table of contents is irritating to navigate, particularly on pages with a huge number of bytes (e.g.: a). The table doesn’t even have nested tabs like on Wiktionnaire.

My idea would be to have some sort of option to ‘filter’ languages before the page loads, but I suspect that this would be very difficult to programme. I can’t think of a superior alternative, though. Do you lot have any better ideas, by any chance?

Am I the only one who finds it annoying to navigate high‐content pages? I’m not sure what we can do about it, though. --Æ&Œ (talk) 13:04, 16 September 2014 (UTC)

Buy a newer computer. I never have problems with large pages. --Vahag (talk) 13:25, 16 September 2014 (UTC)

I don’t have that kind of trouble at all. For me, every page loads as fast as every other page ... in about a second. First, I think you should go to PREFERENCES > Gadgets > User interface gadgets, and tick Enable Tabbed Languages. Each language will have its own page (and no more tables of contents). Second, I don’t know if the browser makes any difference, but I use the very latest Firefox browser, Firefox 32.0.1. Third, RAM memory might be an issue, and you should see if you can get another RAM memory card that will increase your computer’s memory. My computer is just a cheap old laptop that I bought second-hand several years ago. I just added some RAM and upgraded to Windows 7. I think if you do these things, your pages will load quickly. —Stephen ^(Talk) 13:57, 16 September 2014 (UTC)

Subpage editing weirdness

I went to cull some blue links from User:Brian0918/Hotlist/A2, and was unable to save the edit, instead receiving a message that said:

This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: Users touching other users' user pages and subpages

I was, however, able to move the page to my userspace, delete some of those blue links, and then move it back. I also tried editing User:Robert Ullmann/Oldest redlinks, and got the same message. Since I am an administrator, it seems rather pointless to "inform an administrator" of what I was trying to do. I have edited subpages like these up until earlier today without this issue coming up. What changed? bd2412 T 19:02, 16 September 2014 (UTC)

See Special:AbuseFilter/24. Looking at today's change log, it says: "2014-09-16: Check user_rights for "autoconfirmed" instead of user_groups for "*confirmed". That way global groups providing "autoconfirmed" are also supported whilst still supporting the local "confirmed" user group, too. ––Krinkle". Equinox ◑ 19:09, 16 September 2014 (UTC)

Fixed. Next time, post this in the WT:GP. --WikiTiki89 19:11, 16 September 2014 (UTC)

... but as long as we're in the BP: there has been discussion of changing the filter to allow users to edit others' subpages; I now support such a change. Would anyone else like to express a view on (or implement) that change? - -sche (discuss) 19:14, 16 September 2014 (UTC)

I support such a change. It's often legitimate to edit subpages of other users, like to update bot feed lists or to remove entries from lists that another user has generated from a dump. Editing the main user page of another user should be restricted to people who know what they are doing (unlike User:WritersCramp who vandalised my user page in diff). —CodeCat 19:27, 16 September 2014 (UTC)

I've been doing that for years. Removing entries from lists that another user has generated from a dump, I mean, not vandalizing CodeCat's user page. bd2412 T 20:09, 16 September 2014 (UTC)

As admin I've been editing selected dump-populated subpages, too. But I have simple questions about this:

1. Would this be a default setting that could be overridden?
2. What level of user are we talking about? Registered? Whitelisted?

Prudence would require that the pages be added to one's watchlist, no matter what the default and no matter what level of user. DCDuring TALK 21:47, 16 September 2014 (UTC)

bookworm: movies

Here’s a kind of ngram for movies & TV: movies.benschmidt.org. —Michael Z. 2014-09-16 21:16 z

Korean lemmas and categories

(Notifying TAKASUGI Shinji, Wyang, Jusjih):

We have a bit of a disagreement with User:Jusjih regarding Korean hanja. In my opinion, hanja or Chinese character forms, as not a primary writing system for modern Korean, should not have any topical categories. Cf. Japanese kyūjitai (pre-reform spellings), kana (usually hiragana and sometimes katakana) terms (when not the most common spelling), let alone romanisation entries - rōmaji and pinyin.

E.g. 중국인 (junggugin) (the current standard spelling) belongs to Category:ko:Nationalities but IMO (hanja entry) should not. I would say the same about Vietnamese Hán tự entries. Both Korean hanja and Vietnamese Hán tự definitions are, by convention, very short (one-liner) and only link to the current writing system, i.e. hangeul for Korean and Latin spelling for Vietnamese.

What do you think? Comments regarding kyūjitai, kana, Hán tự would also be appreciated. Format for rōmaji and pinyin entries are set in stone by appropriate votes. --Anatoli T. ^{(обсудить}/^вклад) 06:02, 17 September 2014 (UTC)