Wiktionary:Grease pit/2016/July

The template {{topic cat}} is generating an error at "Category:en:Parties", and I'm not sure why. — SMUconlaw (talk) 16:12, 1 July 2016 (UTC)

There is no "parties" topic in the Module:category tree/topic cat/data tree. It should probably be added to the Culture subpage. --WikiTiki89 16:43, 1 July 2016 (UTC)

Thanks. It looks pretty technical. I'd better leave this to one of the grease monkeys here. — SMUconlaw (talk) 17:56, 1 July 2016 (UTC)

Done: diff. Feel free to change the parent categories if you see fit. --WikiTiki89 18:03, 1 July 2016 (UTC)

Thanks, that looks fine! — SMUconlaw (talk) 18:25, 1 July 2016 (UTC)

I created {{coglist}}, a template for lists of cognates. See this diff where the template is being added in an entry. See also the data module for the list of cognates itself. --Daniel Carrero (talk) 11:58, 2 July 2016 (UTC)

I think it's too cumbersome to be useful. People aren't going to want to create a new list in a module (modules scary!) just to list a few cognates in an entry. Same as with {{etyltree}}, that never really got used much either, which is why I created {{desctree}} as a simpler replacement. —CodeCat 13:50, 2 July 2016 (UTC)

Also, if it were to become widely used, the parameter would have to be more language-specific. At the moment there are only two lists, both in reconstructed Vulgar Latin, but what if someday we wanted one cognate list for the descendants of Latin dolus and another for the descendants of Old Irish dolus? —Aɴɢʀ (talk) 14:29, 2 July 2016 (UTC)

The group names can be: dolus1, dolus2; dolus/la, dolus/sga. The group names can be anything. @CodeCat, you meant {{etymtree}}? Also, as long as people are ok with the existence of {{coglist}}, they can choose using it or not. That template exists mostly because I got tired of replacing the same instances of {{etyl|xx|-}} {{m|xx|qwerty}} by {{cog|xx|qwerty}} in multiple entries, and I'd like to use it. --Daniel Carrero (talk) 14:38, 2 July 2016 (UTC)

I just don't list cognates much at all. If people want to find cognates, they can look in the entry for the ancestor. No sense in duplicating all that. —CodeCat 14:46, 2 July 2016 (UTC)

As Code said, I've often found lists of cognates to be duplicative and often misleading. —JohnC5 17:07, 2 July 2016 (UTC)

When you choose to use a particular template, you're choosing not just for yourself, but for the next person who's going to making changes to what you've entered. If you get a Lithuanian cognate wrong, some poor Lithuanian IP is going to have to figure out how to change it in the module. I also agree that cognate lists are rife with excess. Listing all the cognates in every etymology would be like including the entire inflection table in the headword line of every inflected form. It's bad enough that you can't give a Danish cognate without having Swedish, Norwegian, Faroese and Icelandic added immediately. Chuck Entz (talk) 17:35, 2 July 2016 (UTC)

I think including cognates in an etymology is a good idea but I also don't really like this approach too much. One issue here is that it feels wrong to have the cognate lists all stuck together into a big file instead of more distributed. Benwing2 (talk) 20:36, 2 July 2016 (UTC)

There are two issues:

1. Whether to have many (or all) cognates in the etymology of a given entry; or just 1, 2, 3 cognates; or no cognates in etymologies.
2. Whether to use {{coglist}} with Module:coglist/data, or: "Compare {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}, {{cog}}."

About both issues, I'm using {{coglist}} in pages where there already were already lots of cognates, cross-linked in most of the separate pages, as in the diff in my 1st message. If having a certain number of cognates in etymologies is not a desirable thing, should we delete the cognates altogether from these entries? Or maybe just trim all the long lists of cognates and keep only 1, 2 or 3 cognates in all pages? I don't think {{coglist}} would be very helpful in pages with few (maybe 1-3) cognates. (unless we make {{coglist}} show 3 cognates with a JavaScript button to display more cognates) If all the many cognates were to be kept, and cross-linked in all entries, it seemed logical to me creating a separate list for them.

I tried just converting from:

"Compare Language '']'', Language '']'', Language '']'', Language '']'', Language '']'', Language '']'', Language '']''."

to:

"Compare {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}, {{cog|lc|link}}."

but got tired of editing the same cognates over and over in all the linked pages. --Daniel Carrero (talk) 23:44, 2 July 2016 (UTC)

Maybe the solution is to use a bot to convert to {{cog|...}}? It requires some cleverness but probably can be done for most cases. Benwing2 (talk) 02:53, 3 July 2016 (UTC)

I think we should automatically remove/convert Latvian accent marks, as we do with other languages. For example, klât should automatically link to klāt. I don't know Latvian well but I think the three long-vowel tone marks are â ã à, which should all map to ā. Benwing2 (talk) 20:39, 2 July 2016 (UTC)

CodeCat (I think) and I had wondered about this before but also lacked the requisite knowledge. I'd love to know the answer. —JohnC5 20:47, 2 July 2016 (UTC)

I'd say just go ahead, and see if someone complains. —CodeCat 21:07, 2 July 2016 (UTC)

Done. Benwing2 (talk) 21:39, 2 July 2016 (UTC)

Except there's no such thing as ō in the standard orthography- only o (nor any variation on y whatsoever, for that matter). See w:Latvian orthography and WT:ALV. Chuck Entz (talk) 22:42, 2 July 2016 (UTC)

ō and ȳ removed. Chuck Entz (talk) 22:48, 2 July 2016 (UTC)

According to that Wikipedia page, ō is still used by some Latvian speakers, but not by the standard orthography. So entries with ō might theoretically exist as alternative spellings, and we need to be able to link to them. —CodeCat 23:03, 2 July 2016 (UTC)

Yes, but what we're talking about here is converting every accented o or O to ō or Ō. Links that have ō or Ō in the wikitext are still going to link to ō or Ō- we just don't want to link ÔÕÒôõò to ō or Ō. Why funnel everything to rare alt-forms? Chuck Entz (talk) 01:00, 3 July 2016 (UTC)

I understand that. But it would also mean that we're no longer able to link to these alt forms with additional accents. If you use ô instead of ō, it links to the wrong page. That's something to be aware about. —CodeCat 12:19, 3 July 2016 (UTC)

Yes, but there's no way to tell from the wikitext whether an accented o should link to an o with or without the macron. Assuming the rarer form means guessing wrong most of the time. Chuck Entz (talk) 15:01, 3 July 2016 (UTC)

Pinging Latvian native speakers @Čumbavamba, Neitrāls vārds. - -sche (discuss) 22:16, 2 July 2016 (UTC)

There was ŗ and ō in Latvian some time ago, but now aren't. Another letters, such â, â, â, doens't exist in Latvian. Letter y is in Latgalian, which is Latvian dialect. --Čumbavamba (talk) 20:49, 3 August 2016 (UTC)

This is concerning the protoform namespace, am I correct? If you did convert them -- kudos, because I remember seeing many, many red links due to tone marks being passed on as standard orthography as opposed to "scholarly notation" which they are (similar to macrons in Old Saxon, etc.) I don't think long o should be an issue though? It's not found in inherited words and recent borrowings are not likely to figure in protoform namespace and recent borrowings take level accent by default anyway. But there may be a need to remove accent marks from sonorants in so called "diftongiskie savienojumi", e.g., in kalns the tilde is supposed to go over l, but maybe because it's hard putting weird diacritics over consonants, the protoforms are not "contaminated" with red links of this type? I remember seeing only tone marks over vowels making otherwise existing links red... Neitrāls vārds (talk) 21:30, 28 August 2016 (UTC)

Hi. I noticed that when I use the der (derived) template, it doesn't always link to the correct language heading. For example, I added the following to the etymology of German Seide: Latin saeta (“horsehair; bristle; silk”), which when clicked on, takes me not to Latin saeta, but to Spanish saeta. This may be due to Spanish being at the bottom of the page. Can this be made to link to Latin ? Leasnam (talk) 01:52, 4 July 2016 (UTC)

Is this a problem specific to that template? For me, the {{der}} link works exactly like saeta#Latin or saeta, and the link it generates is correctly to saeta#Latin. The issue AFAICT is a (longstanding) bug that when there's collapsible content further up a page, and one clicks any link that points to an anchor lower down on the page, the page may load and pull the browser to the anchor while the content is uncollapsed, after which the collapsible content collapses, leaving a different part of the page visible. (Sometimes the browser subsequently corrects for the shift and re-focuses on the anchor.) - -sche (discuss) 02:47, 4 July 2016 (UTC)

For me, too, these links all work exactly the same; they correctly use the anchor "Latin", but in all cases, because of the bug -sche mentioned, the link does take me to the bottom of the page, which is the Spanish section:

• {{der|de|la|saeta||horsehair; bristle; silk}}
• '']''
• {{m|la|saeta}}

When the page is already loaded (with Spanish showing up on my screen), if I click on the address bar (https://en.wiktionary.orghttps://dictious.com/en/saeta#Latin) and press Enter, the page goes to the correct section (Latin) without loading again. (on Firefox)

If I click "Show quotations" and "Show inflection" on the left side of the screen, and then click on the link to '']'', it goes directly to the Latin section, as it should, because there's nothing to collapse. --Daniel Carrero (talk) 04:34, 4 July 2016 (UTC)

Ok. Thank you for looking into this, and for the expalanation :) Leasnam (talk) 15:15, 4 July 2016 (UTC)

Back in 2011, someone suggested making {{en-past_of}} link to the #Verb anchor, rather than the #English anchor. 3 years later, this was rejected on the basis that #Verb might not always be correct (but #English would). This does not seem accurate to me (as I explained on the linked talk page). Further discussion (and a change by an admin, once consensus is determined) would be welcome. JesseW (talk) 02:12, 5 July 2016 (UTC)

There could be a Translingual verb section. There could also be a different English verb; for example, if flied pointed to fly#Verb rather than fly#English, it would be confusing because it would be pointing to a verb that doesn't have a form "flied". If it points to fly#English, on the other hand, the reader knows that the form is there somewhere, even if it takes a little looking for. —Aɴɢʀ (talk) 12:40, 5 July 2016 (UTC)

The id= parameter, along with {{senseid}}, was introduced to allow templates to link to specific senses. It can be used here too. —CodeCat 12:47, 5 July 2016 (UTC)

That's close, but {{senseid}} only lets you point to a specific sense, while what is needed is a way to point to multiple senses (e.g. on desert, there are two senses, which deserted can refer to either.) Suggestions? (Angr -- very good point about fly.) JesseW (talk) 00:55, 6 July 2016 (UTC)

Just point to the first one? —CodeCat 01:03, 6 July 2016 (UTC)

I would do that if it was a pure anchor, but it also highlights the definition, which to me implies that the link doesn't apply to the other definitions, which is misleading. JesseW (talk) 03:34, 6 July 2016 (UTC)

Just how many Translingual verbs are there now? How would such things come about? DCDuring TALK

There are 3 currently in Category:Translingual_verbs (but only ⠆ seems to actually have a Verb section). JesseW (talk) 03:40, 6 July 2016 (UTC)

Is anyone able to create a version of w:Template:Multiple image here? Lua is beyond me. — SMUconlaw (talk) 17:55, 5 July 2016 (UTC)

I could really use such a thing for family- and higher-level taxonomic names. DCDuring TALK 21:50, 5 July 2016 (UTC)

Example images

{{multiple images}} should be set to go. KarikaSlayer (talk) 03:10, 10 July 2016 (UTC)

Thanks! Is there any reason why we don't use the same name as the English Wikipedia template, though? — SMUconlaw (talk) 13:30, 10 July 2016 (UTC)

The "s" is because I typoed. Should we have it as {{multiple image}} or {{Multiple image}}, though? KarikaSlayer (talk) 21:21, 10 July 2016 (UTC)

Since there are multiple images, why not keep the plural? It makes more sense to me. —CodeCat 21:31, 10 July 2016 (UTC)

Is there a specific reason why the tables are ordered right-to-left? Our Arabic templates don't do this, and neither does {{fa-basic}}. It's also pretty unintuitive on an English-language wiki. KarikaSlayer (talk) 00:26, 6 July 2016 (UTC)

It was just something the person who made it liked to do. I don't think anyone would mind much if you want to switch it to left to right. DTLHS (talk) 00:33, 6 July 2016 (UTC)

There must be some error in Module:families/data that causes this incorrect categorization. DTLHS (talk) 17:43, 6 July 2016 (UTC)

Nope, the error was in Mod:languages/datax. I've fixed it and all the resultant module errors. —Μετάknowledge^{discuss/deeds} 18:25, 6 July 2016 (UTC)

Thanks. Btw, for anyone who wasn't aware, WT:DATACHECK tracks such clashes. - -sche (discuss) 18:58, 7 July 2016 (UTC)

When I tried to use the "add new rhyme" tool at "Rhymes:English/æɹɪti", it gave the error message "ERROR:TypeError: (intermediate value).parentNode is undefined". "* {{rhymes|æɹɪti|lang=en}}" was successfully added to the entry page "tutelarity", though. — SMUconlaw (talk) 21:35, 6 July 2016 (UTC)

I get the error only when adding to the seven-syllable rhymes section; others are fine, oddly. Equinox ◑ 21:05, 7 July 2016 (UTC)

I'm currently trying to add mouseover transliterations for {{el-decl-noun}}, but they aren't working in the template. Hard-coded {{l|el|αγγούρι|3={{tooltip|{{xlit|el|αγγούρι}}|αγγούρι}}|tr=-}} works just fine (αγγούρι), but {{l|el|{{{1}}}|3={{tooltip|{{xlit|el|{{{1}}}}}|{{{1}}}}}|tr=-}} just displays the link (with no tooltip). KarikaSlayer (talk) 15:51, 7 July 2016 (UTC)

I think it's more accessible if the transliteration is shown as text in the table, tooltips are too hidden and I have no idea how they're supposed to be accessed on systems without a mouse pointer. It doesn't have to be cluttery, look at how Russian, or even French, display it. —CodeCat 19:48, 7 July 2016 (UTC)

Pinging @Saltmarsh. KarikaSlayer (talk) 20:52, 7 July 2016 (UTC)

It is of course more accessible - but surely anyone looking at a table is going to be familiar with the syllabary in question and can hover (if enabled) or follow the link if they are interested. Showing the transliteration detracts from the effort taken to present a clear, easily read table.   — Saltmarsh^{συζήτηση-talk} 05:00, 11 July 2016 (UTC)

{{fr-conj-auto}} is throwing up some odd pronunciations in the verb errer (and verbs ending with it such as serrer), saying that erre, erres, errent are pronounced /e/ instead of /ɛʁ/. This only seems to happen with verbs with this spelling, as clairer which rhymes is shown correctly. I presume this is something going on with the code that makes final -er pronounced /e/.

Relatedly, I note that all three verbs are displaying with the stem vowel /e/ rather than the correct /ɛ/ in forms such as errons/clairons, errais/clairais, erra/claira (I know there's some metaphony going on with /ɛ/ being raised to /e/ before an ending containing /e/ or /i/ but it doesn't occur before other vowels and it's allophonic anyway). 81.129.155.63 18:55, 7 July 2016 (UTC)

The missing /ʁ/ should be fixed. KarikaSlayer (talk) 20:46, 7 July 2016 (UTC)

Module:fr-verb should really have test cases to detect things like this. DTLHS (talk) 20:49, 7 July 2016 (UTC)

Recent Changes is showing the correct time, but (for example) WT:TR is showing all the time-stamps an hour earlier. It's about 04:20 now, but the message I just posted in the Tea Room is showing a time of around 03:20. Definite bug. Equinox ◑ 03:23, 8 July 2016 (UTC)

It's 8:31 UTC now, and my timestamp is showing that, so maybe it's been fixed. —Aɴɢʀ (talk) 08:31, 8 July 2016 (UTC)

My initial message in this subsection still shows 3:something for me, so nope. Equinox ◑ 08:31, 8 July 2016 (UTC)

The timestamp of your initial message is plain text now, so it's not going to change. But if the time registered in the history matches the real time, then the bug is fixed. —Aɴɢʀ (talk) 17:39, 8 July 2016 (UTC)

What did I just change with diff? I can't tell what it is, but it's blocking MewBot from adding in {{cog}}. —CodeCat 17:54, 8 July 2016 (UTC)

That's a nonbreaking space (U+00A0). DTLHS (talk) 17:58, 8 July 2016 (UTC)

String converters (like this) can be used to see what's going on. --Z 17:48, 9 July 2016 (UTC)

string.__repr__() in Python works too (yields {{etyl|fo|-}}\\xa0{{m|fo|-ligur}}) . --Njardarlogar (talk) 21:12, 9 July 2016 (UTC)

{{given name}} now supports a new parameter |xlit= for an approximate transliterated name, in addition to |eq= for an equivalent name. For the difference, consider e.g. Михаил (Mixail) with transliterated name Mikhail and equivalent name Michael. It also supports multiple transliterated and equivalent names, and multiple main forms of diminutives, along with alternate display text and manual transliterations of those main forms. Note that |xlit= isn't named |tr= because it's not used to represent transliterations in typical Wiktionary form but in "popular" (approximate) form. Benwing (talk) 17:17, 9 July 2016 (UTC)

I added support for dimtype= to specify endearing and pejorative diminutives (which exist in Russian). I tried to display the value of from= in the defn line, as someone requested, but it messes up lots of existing names like Ashley. Benwing2 (talk) 23:59, 9 July 2016 (UTC)

Seems useful. Thank you. :) - -sche (discuss) 03:55, 11 July 2016 (UTC)

How do you put a definition that refers to another word? In this case the word is йо́ркский (jórkskij), which is an adjectival version of York but also occurs as part of нью-йо́ркский (nʹju-jórkskij), the adjectival version of "New York". One definition should say {{lb|ru|attributive}} ], while another should say "See нью-йо́ркский (nʹju-jórkskij)" or something similar. I know about {{only in}} but it doesn't seem right because the term has a definition on its own, just one that's not as common as when it forms part of the larger word. Benwing2 (talk) 03:21, 11 July 2016 (UTC)

If йо́ркский only means "New Yorkian" when it's in the form нью-йо́ркский, I have seen {{only in}} used even when there are other senses present on other lines. But if йо́ркский can sometimes be a synonym of нью-йо́ркский, then using {{synonym of}} seems like the thing to do. - -sche (discuss) 03:54, 11 July 2016 (UTC)

Yes, I'm pretty use that йо́ркский only refers to New York in the form нью-йо́ркский. Benwing2 (talk) 04:01, 11 July 2016 (UTC)

I wouldn't say that йо́ркский refers to anything at all in the form нью-йо́ркский (nʹju-jórkskij). As our etymology section indicates, that form is Нью-Йорк + -ский, not нью + йоркский. The only definition of йо́ркский (jórkskij) should be "pertaining to York (e.g. England or Ontario)"; it shouldn't also say {{only in|нью-йо́ркский}}. Likewise I wouldn't expect an English entry Yorker that's defined as {{only in|New Yorker}}. —Aɴɢʀ (talk) 14:58, 11 July 2016 (UTC)

OK, maybe a better example is яга́, which occurs primarily in баба-яга but also has some meanings of its own. Benwing2 (talk) 02:59, 12 July 2016 (UTC)

Hello. Can somebody fix it? Something went bad and now many transcriptions don't look the way they should (see Template:es-IPA). All I did was to remove excessive narrowness in phonetic transcription. Mr KEBAB (talk) 11:19, 11 July 2016 (UTC)
Besides, the example: "{{es-IPA|hielo}}: /ˈjelo/, ", found here, was utterly wrong, as no diphthongs starting with /j/ can appear word-initially, only the /ɟ͡ʝV/ invalid IPA characters (V) sequence can (see Martínez Celdrán - Problems in the classification of approximants (2004)). Therefore, initial <hiV> is the same as <yV> (where V stands for "vowel"). Mr KEBAB (talk) 12:59, 11 July 2016 (UTC)

Please add test cases to Module:es-pronunc/testcases, so we can have a better idea of the expected behavior and the current problems. DTLHS (talk) 19:10, 11 July 2016 (UTC)

Thanks, but that module should display both phonemic (between slashes //) and phonetic (between brackets ) transcriptions, or only phonetic ones. As of now, there are only phonemic transcriptions, and we don't have any problems with those - it's the phonetic transcriptions that are problematic, though JohnC5 helped me a bit with that (thanks man). Mr KEBAB (talk) 19:34, 11 July 2016 (UTC)

OK, I think. DTLHS (talk) 19:37, 11 July 2016 (UTC)

(Sorry, Firefox crashed and deleted my post, it pissed me off and I had to take a break).

Thanks for fixing it, it works as it should. Here's the list of the problems:

- First of all, we have a really weird problem of <ɟ͡ʝ> invalid IPA characters (<>) not being displayed correctly and therefore it is not detected as a single sound, so that the approximant allophone doesn't appear where it should. On the other hand, the other affricate, <t͡ʃ> invalid IPA characters (<>), is displayed without a problem!

- The post-pausal, word-initial voiced plosives /b, d, ɡ/ are incorrectly transcribed as if they were approximants *, but they should be transcribed because they're not lenited unless a word-final non-nasal (in case of /d/ also not the lateral /l/) consonant directly precedes them - see .

- /o/ in the word cónyuge is incorrectly transcribed as not nasalized *. It is nasalized, because it precedes coda /n/ - see . I think that the fact that <ɟ͡ʝ> invalid IPA characters (<>) seems not to be detected by the module is directly influencing the non-nasalized transcription, because when I briefly switched the symbol <ɟ͡ʝ> invalid IPA characters (<>) to <ɟ> invalid IPA characters (<>), the vowel was transcribed correctly...

- Word-initial prevocalic sequence <hi> is incorrectly treated as if it were a diphthong onset, but, as I said above, only /ɟ͡ʝ/ can appear word-initially. <hiV> is merely a spelling variant of <yV>, where "V" stands for "vowel". Mr KEBAB (talk) 22:24, 11 July 2016 (UTC)

All of these bugs should be fixed. KarikaSlayer (talk) 00:54, 12 July 2016 (UTC)

Thanks! Some of them are but, again, some of them aren't - see Module:es-pronunc/testcases. We also have a weird bug on pez#Pronunciation_2, where the Latin American pronunciation (/ˈpes/) is not listed at all... Mr KEBAB (talk) 00:58, 12 July 2016 (UTC)

I disagree with the statement that /j/ cannot occur word-initially in Spanish. Argentinian Spanish, at least, makes a clear distinction between word-initial hi- and word-initial y- . A minimal pair is hierba vs. yerba (as in yerba buena, yerba mate). Benwing2 (talk) 03:08, 12 July 2016 (UTC)

Also hierro vs. yerro. Benwing2 (talk) 03:09, 12 July 2016 (UTC)

The source above disagrees. Mr KEBAB (talk) 05:05, 12 July 2016 (UTC)

The source above doesn't say which dialect of Spanish it's referring to. It seems to be treating Spanish monolithically, which is careless. —Aɴɢʀ (talk) 09:16, 12 July 2016 (UTC)

That's still much better than going with someone's OR. Mr KEBAB (talk) 13:49, 12 July 2016 (UTC)

This isn't Wikipedia. There's a huge amount of information such as pronunciation that can't be sourced to Wikipedia standards for many entries. Even when there's sourcing it takes quite a bit of synthesis (another dirty word at WP) to make it work in the entries. I don't know that it's a good idea to exclude regional pronunciations because speakers haven't checked the latest phonological research before having a conversation. Chuck Entz (talk) 14:01, 12 July 2016 (UTC)

Even if Benwing2 is right, we still have no idea how widespread that distinction is. I really don't think that his word is enough in this case. Mr KEBAB (talk) 14:45, 12 July 2016 (UTC)

FWIW, the Spanish Wiktionary itself (which one would expect might know a thing or two about Spanish) says es:hierro /j-/ and es:yerro /ʝ-/, and es:hierba /j-/ and es:yerba /ʝ-/, are not homophones. Lourdes Aguilar, Vocales en grupo (2010), page 57, has some information about this, commenting that "Desde este punto de vista, las palabras hierro y yerro serían homófonas en la norma castellana, aunque no en otras variantes." - -sche (discuss) 15:02, 12 July 2016 (UTC)

That's good to hear, because it fits perfectly with our European-Latin American distinction. Does the author say anything about the /ʝ-j/ issue before other vowels? Mr KEBAB (talk) 15:22, 12 July 2016 (UTC)

This phonemic contrast seems to be based on spelling pronunciations, since hierba and yerba are etymologically identical, both coming from Latin herba. —Aɴɢʀ (talk) 15:47, 12 July 2016 (UTC)

How the contrast originated is irrelevant. The question is only whether it exists. --WikiTiki89 17:28, 12 July 2016 (UTC)

Maybe not completely identical: the difference in spelling might be an indication of regional borrowing, or of a different register. Chuck Entz (talk) 03:23, 13 July 2016 (UTC)

What is causing CAT:Pages using invalid self-closed HTML tags to show up on a bunch of pages? I'm finding it on several Irish entries (e.g. abhaill, abhainn, achar), but I can't find any HTML tags on those entries. Is it being triggered by a template? There's no template listed in the category, so if so, I don't know how to find the template causing the trouble, nor what exactly the trouble is. —Aɴɢʀ (talk) 15:22, 14 July 2016 (UTC)

<p /> used in {{ga-decl-f3}}. There may be other templates with the same problem. DTLHS (talk) 15:28, 14 July 2016 (UTC)

<p /> should be replaced with <br />. Can we do this by bot? --WikiTiki89 15:34, 14 July 2016 (UTC)

{{rfd}} uses a self-closed <span id="..." /> tag. I think this should be allowed. This is a bit ridiculous. In the Irish declension templates, <p /> is just superfluous and can be removed entirely. --WikiTiki89 15:43, 14 July 2016 (UTC)

Yeah, I'm going through them all now and removing it. For the life of me I can't remember why I ever put it in in the first place. —Aɴɢʀ (talk) 15:57, 14 July 2016 (UTC)

It might be ridiculous but if they're going to complain then it's easy enough to fix. DTLHS (talk) 15:59, 14 July 2016 (UTC)

Writing <span id="..."></span> instead of <span id="..." /> when you don't need to have any content between the tags is ridiculous. I refuse to fix these and will actively oppose the "fixed" syntax. --WikiTiki89 16:10, 14 July 2016 (UTC)

It sounds like they are planning to make this syntax break totally in the future. So you may not have a choice. DTLHS (talk) 16:18, 14 July 2016 (UTC)

That's pretty nonsensical. <span/> is by definition allowed in XML and is considered more or less equivalent to <span></span>. Are they trying to break XML compatibility? —CodeCat 16:23, 14 July 2016 (UTC)

HTML has never been fully XML-compatible. That's what XHTML was for. --WikiTiki89 16:28, 14 July 2016 (UTC)

Breaking that compatibility on purpose is worse though. I think XHTML is the way forward. —CodeCat 16:40, 14 July 2016 (UTC)

In general, most of the ways HTML breaks compatibility are beneficial. However, this particular thing is pretty ridiculous. --WikiTiki89 16:46, 14 July 2016 (UTC)

I Googled around a bit more and found that <span id="..." /> was never valid HTML and was always interpreted as just an opening <span id="..."> tag. Supposedly this causes a lot of weird problems. Maybe fixing these to <span id="..."></span> will solve some of our weird formatting mysteries. --WikiTiki89 20:18, 14 July 2016 (UTC)

Right. HTML predated XML, and it's always had various elements where the end-tag is either optional (e.g. <p>; the element ends when it has to either due to a containing element ending, or due to a start-tag for an element that can't be contained in a <p> element) or actively forbidden (e.g. <br>; the element is inherently empty). XML doesn't allow that concept, but it has a "empty tag" concept (such that e.g. <foo/> is equivalent to <foo></foo>); and experimentation showed that existing (pre-XHTML) browsers simply treated e.g. <foo /> (note the space) as if it were <foo>; so with XHTML (a reworking of HTML to be XML) came the recommendation to use XML's empty-tag syntax for elements that are inherently empty, but otherwise to avoid it. That way XHTML pages would still work correctly with pre-XHTML browsers, even though it wasn't actually valid HTML. (And MediaWiki has, for years, supported using HTMLTidy to clean up bad (X)HTML, including converting XHTML that doesn't conform to this recommendation into XHTML that does.) —Ruakh_TALK 05:38, 15 July 2016 (UTC)

I've fixed all of the Irish declension templates. There are still other pages in the category, but I feel like I've cleaned up my own mess. —Aɴɢʀ (talk) 17:02, 14 July 2016 (UTC)

Is <references /> an invalid self-closed HTML tag? —Aɴɢʀ (talk) 09:28, 15 July 2016 (UTC)

Answering my own question: no, but <noinclude /> is. —Aɴɢʀ (talk) 09:42, 15 July 2016 (UTC)

I've cleared out the category all except for MediaWiki:ExtractFirst.xsl, mostly because I don't understand what it is for, what XSL even is, and why the page is wiki-rendered rather than rendered as source code like JS and CSS pages. --WikiTiki89 18:28, 15 July 2016 (UTC)

XSL is an XML-based transformation language. So it shouldn't be considered Wikicode; it's XML, and self-closing tags are perfectly valid for it. —CodeCat 18:37, 15 July 2016 (UTC)

FWIW, the purpose of the page is explained on the talk page. - -sche (discuss) 18:50, 15 July 2016 (UTC)

I noticed today that the languages list is compacted instead of leaving all (or allowing us to always show some languages). How to stop that option? I see no option to stop it. In Wikipedia we can enable of disable this option from the Beta features. --Mahmudmasri (talk) 19:47, 14 July 2016 (UTC)

It's in Preferences, under the Appearance tab. Keith the Koala (talk) 19:52, 14 July 2016 (UTC)

would it be possible, without being too "expensive", to have WT:LOL or some other page (WT:STATS?) display a real-time count of how many language codes there are? This information would be of interest to people (such as me) examining how many languages there are and how many have entries. - -sche (discuss) 18:55, 15 July 2016 (UTC)

 Done (diff, diff). Feel free to change the wording. Also, let me know if you want separate counts for natural vs. reconstructed vs. constructed languages. Or if you also want a count of etymology languages, scripts, or language families. --WikiTiki89 19:16, 15 July 2016 (UTC)

Thank you! Counts of natural vs. reconstructed vs. constructed languages would be useful. However, there is a distinction between "constructed languages", some of which have no type= set (but which all have family = "art"), and "appendix-only constructed languages" (type = "appendix-constructed"). Counts of both would be interesting. Of the two, I'd be more interested in knowing the number of family = "art" languages vs actually-natural (≠ "art") languages, but it's easy enough for me to generate a count of family = "art" languages when I need one, so I can do without a real-time/automatic count if one would be too difficult to add. At this time, I don't see a need to count scripts or families. Our script codes overlap enough (Latn, Latinx) that a count of codes wouldn't have much relation to the number of distinct scripts we include. - -sche (discuss) 20:02, 15 July 2016 (UTC)

Why does risk appear in Category:Ancient Greek terms needing native script? Even if this can be explained and justified in someone's mind, it seems likely to waste someone's time, as it has mine. DCDuring TALK 22:07, 16 July 2016 (UTC)

Because of {{der|en|gkm|tr=riziko|t=sustenance obtained by a soldier through his own initiative, fortune}}. In this case, we treat gkm as an etymology-only variety of Ancient Greek, and the module adds these request categories whenever someone uses a linking template without the actual term to be linked. The alternatives would be to either throw a module error, which would be rather disconcerting for someone who doesn't know Ancient Greek and just has transliterations, or to ignore it and hope someone thinks to add an attention template. Chuck Entz (talk) 23:07, 16 July 2016 (UTC)

Nobody forced you to make this thread. In what way did it waste your time. DTLHS (talk) 23:10, 16 July 2016 (UTC)

Trying to track down the source of the problem so I could correct it. I won't make the mistake of trying to track down such problems again. DCDuring TALK 23:52, 16 July 2016 (UTC)

For some reason, I can't get Language family, ancestors, or script into the parameters. Could someone please help me out here? I think it may have something to do with internal coding rather than templates? Philmonte101 (talk) 21:15, 20 July 2016 (UTC)

That's because it was already all included in the data modules- no action required. Chuck Entz (talk) 03:31, 21 July 2016 (UTC)

"User pages of accounts that do not contribute to the dictionary proper may be deleted after about a week." Isn't that supposed to be properly? Philmonte101 (talk) 03:34, 21 July 2016 (UTC)

No, see sense 2.3 of proper. DTLHS (talk) 03:41, 21 July 2016 (UTC)

User:DTLHS This sense seems rare and doesn't make sense to me. Could we please change it to properly? I think it would be more clear to most readers if we did. Philmonte101 (talk) 02:16, 7 August 2016 (UTC)

That doesn't mean the same thing. I like it as it is, personally. Equinox ◑ 02:46, 7 August 2016 (UTC)

I'm only saying this because, though the definition is real, I've never in my life seen or heard proper used this way. Could it perhaps be a British-only thing, or rare, or something that is very formal and usually written? Philmonte101 (talk) 03:20, 7 August 2016 (UTC)

Also, it's sort of a dangling modifier. You can't tell if it's referring to the user pages not contributing to the dictionary or if it's the "accounts". I guess that's partially what confused me about this as well. Philmonte101 (talk) 03:23, 7 August 2016 (UTC)

Hi! This was an actual Wikimedia student/intern project that came to naught, IIRC, but we have plenty of people here who can code pretty well, and (while I haven't kept up, and am gradually becoming Old Uncle COBOL) I believe that it's now fairly easy to do audiovisual stuff in HTML5. So what about it? We must have some hacking talent who can simplify the current horrible process of creating, uploading, licensing (!!) and entry-embedding our beautiful voices. See also . xx, Equinox ◑ 18:36, 22 July 2016 (UTC)

Is your only complaint about User:Yair rand/AddAudio.js that it only works in Firefox? DTLHS (talk) 18:53, 22 July 2016 (UTC)

How does one use that? — SMUconlaw (talk) 19:03, 22 July 2016 (UTC)

Add importScript( 'User:Yair rand/AddAudio.js' ); to your common.js. By the way I was able to get it work in Chrome by enabling experimental web platform features in chrome://flags/. DTLHS (talk) 19:05, 22 July 2016 (UTC)

Thanks, will try it out! — SMUconlaw (talk) 19:48, 22 July 2016 (UTC)

Sorry that was the wrong link: try User:Smuconlaw/common.js. DTLHS (talk) 19:50, 22 July 2016 (UTC)

Ha, ha, too late. But I figured it out, and have tagged Talk:Smuconlaw/common.js for speedy deletion. — SMUconlaw (talk) 19:52, 22 July 2016 (UTC)

Not actually aware of that! (I use Chrome. I don't really want to install another browser, but I might do, for this purpose.) For the purpose of me installing Firefox purely to record shit for Wiktionary: 1. Does it work well and reliably? (Can regular Wiktionary users vouch for it?) 2. How do you actually use it? The page says it lacks documentation. Pretend I'm your grandmother. 3. Are we okay for the legal aspect, since Wikipedians regularly delete audiovisual media that lack the tiniest permission detail? (4. Brownie points only. I thought HTML5 was a standard and we didn't have BLINK and IF-IE6 any more. Why do I need to install a whole other browser just to record my voice?) Equinox ◑ 19:16, 22 July 2016 (UTC)

Like I said I'm pretty sure you can get it to work with Chrome now. DTLHS (talk) 19:23, 22 July 2016 (UTC)

@Equinox: Grandmother-level instructions on how to use it:

1. To enable the script, go to Special:MyPage/common.js, click the "Edit" link (or "Create"), paste importScript( 'User:Yair rand/AddAudio.js' ); into the text box, and press "Save page".
2. To add audio to an entry, navigate to the entry, and press the "⚫" button next to the "Add audio pronunciation" text. (It should be in the Pronunciation section, or where a pronunciation section would go if there was one.) If this is your first time using the tool, you may need to select a microphone from a list given in a box that pops up. Say the word into the microphone, and then press "⚫" again to stop recording. You can press "►" to listen to the recording to make sure it sounds right, and if it doesn't, you can press "⚫" to try recording it again. For certain languages, you can select a region/dialect code for the audio by clicking on one of the codes to the right of the "►" button. Press "✔" and then click the "Save page" button at the top-left corner of the screen to add the audio to the page and upload the file to Commons. Make sure to wait until the cursor stops showing the "loading" icon before navigating away, so as not to cut off the upload in the middle.

(Okay, maybe not quite grandmother level, but hopefully good enough?)

Re the legal aspect, I kind of just assumed that anyone using the script already knows/consents that content added is licensed under CC-BY-SA 3.0 and GFDL. The script makes the files uploaded have that added as their license by default. --Yair rand (talk) 18:58, 24 July 2016 (UTC)

I added it to the common.js but nothing has changed and entries have no new section. Equinox ◑ 03:35, 25 July 2016 (UTC)

It is very small: http://i.imgur.com/Owr6mBk.png (and make sure you're using Firefox / did a hard refresh etc) DTLHS (talk) 03:41, 25 July 2016 (UTC)

@Yair rand: I tested it in Firefox and works really well. :) I have the following questions:

1. Will this work if the sound file already exist and a new version with improved quality needs to be uploaded?
2. How can we control the volume of the recording? It is slightly lower than manual recordings. Compare ablakot (assisted recording) and ablak (manual recording using Audacity).
3. The only way to cancel a recording is to close the tab or move to a different webpage, correct?
4. After recording was completed, I had to make some minor formatting changes. Are these by design?
   1. moved the audio line from below the Pronunciation header to under the IPA line
   2. capitalized the file name (The file name that is uploaded to Commons correctly starts with a capital letter, but the file name in the audio line is not capitalized.)
   3. added the word Audio after the file name (e.g. {audio|Hu-ablakot.ogg|Audio|lang=hu})

Thanks. --Panda10 (talk) 18:33, 26 July 2016 (UTC)

@Panda10:

1. If the sound file already exists, the script gives a "Audio file already exists." error. Should it overwrite it instead? Or upload a new one with a different file name? (With _2 or -2 appended, perhaps?)
2. There's no way to do that from the script itself, but there's usually a way to directly change the microphone volume settings from one's computer directly.
3. I'm not completely sure what you mean. You can start a recording over by pressing the record button again. If you've already pressed "✔", you can press "Undo" at the top-left to undo it.
4. Neither WT:EL nor Template:audio give very clear guidelines on how these are supposed to be formatted, so I just looked at a (perhaps non-representative) sampling of entries and copied what I saw there. The position of the audio template seems kind of inconsistent, so I just set it to always put it at the top of the Pronunciation section. If you could give clear rules for where more specifically it's supposed to be placed, I could edit the script to place the template there instead. (Note that some entries have IPA templates on the same lines as an audio template of the same dialect, and some sections have text right before the IPA template.) Many entries don't have the file name capitalized, so I followed that. Should I change it to always capitalize? And so that it adds the word "Audio" by default? (Currently, it only adds "Audio" when an accent/dialect is specified.) Both of these would be easy changes to make.

--Yair rand (talk) 02:14, 27 July 2016 (UTC)

@Yair rand:

1. Manual uploading a new version of an existing file is a different process than uploading a new file. Users have to go to the specific audio file in Commons and click the "Upload a new version of this file" link. The old version is never deleted from Commons, at least I've never seen it. All versions exist on the same page, visible in a table (e.g. ). The name of the new file has to be the same as the old one for at least two reasons: A) Other FL wikis run bots to check for new recordings, if the file name does not match the entry name, they might not work. External applications, such as glosbe.com, are also pulling audio from Commons. We want to have the same recording everywhere. B) The audio files are categorized in Commons, the number of the files in the categories would not show the actual number of the files. (It's interesting that the browser's cache has to be refreshed to connect to the new version.) So overwriting the file or uploading a different file name are not a direction we should take. I think it's ok if you don't add this functionality to the tool. It's still a tremendous help.
2. Volume: I will check this on my computer.
3. Canceling recording: There is a third case: let's say I recorded and re-recorded a couple of times, but I have not pressed "✔" yet, but for some reason the session has to be canceled. I think I just simply move to a different web page and that cancels the recording session.
4. If there are no guidelines, it probably requires voting. There was a discussion earlier here . As for the position and for the Audio label, don't make any changes to the tool, I will do the formatting. But I am curious what the reason is for the different file names: correctly capitalized in Commons but lower case here.
5. This is a new question. Can this tool be misused? Is it available to every registered user? What if someone uploads an incorrect audio? I think people at Commons do check the uploaded material, but I'm not 100% sure and even if it is discovered that it was uploaded by mistake (or on purpose by ill will) it is a lengthy process to request a deletion.

--Panda10 (talk) 13:08, 27 July 2016 (UTC)

It is available to every registered user. If someone adds incorrect audio as simple vandalism, it could probably be {{speedydelete}}ed on Commons and rolled back on the corresponding Wiktionary entry. I think it's unlikely that anyone will be using the tool for vandalism, but if it's a concern, I suppose we could add an AbuseFilter tag to audio additions to make patrolling easier. --Yair rand (talk) 22:04, 2 August 2016 (UTC)

I tried installing the tool and using it, but got this error message: "Error: NotSupportedError: Operation is not supported". I'm using Firefox 47.0.1. — SMUconlaw (talk) 19:57, 22 July 2016 (UTC)

Using Chrome I can record, but there seems to be a problem uploading: vulnerability @Yair rand DTLHS (talk) 20:06, 22 July 2016 (UTC)

I got the whole process to work on Firefox- I'm guessing there's some cross origin request issue with Chrome that prevents it from uploading. DTLHS (talk) 20:16, 22 July 2016 (UTC)

Presumably this represents either a vuln in Firefox or a bug in Chrome. Our tiny voices will be ignored for 3 years but is there anything we can report? Equinox ◑ 20:20, 22 July 2016 (UTC)

I think it's a security feature in Chrome- there are ways to disable it, but we should wait and see what Yair rand says. DTLHS (talk) 20:23, 22 July 2016 (UTC)

@Smuconlaw: The Firefox issue should be fixed now, I think. @DTLHS: Chrome currently doesn't support directly recording to .ogg, afaict, so Commons is returning a filetype-mime-mismatch. --Yair rand (talk) 18:31, 24 July 2016 (UTC)

Thank you, that's unfortunate. DTLHS (talk) 18:38, 24 July 2016 (UTC)

Yes, it's working in Firefox now! Just tried it out. Thanks. — SMUconlaw (talk) 20:02, 25 July 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Yair rand, I am having problems creating "File:En-uk-aspartame.ogg". The gadget keeps reporting that the upload has failed. I had accidentally recorded the pronunciation wrongly, so I asked an administrator to delete the file which has been done. However, the gadget doesn't seem to allow a new file to be uploaded. — SMUconlaw (talk) 13:51, 28 July 2016 (UTC)

@Smuconlaw: This is just a wild guess. Try to clear the cache in your browser. I know this is different but when I manually upload a new version of a sound file, the browser will keep playing the old version until I clear the cache. --Panda10 (talk) 21:55, 28 July 2016 (UTC)

Nope, I cleared the cache and deleted cookies, but the gadget refuses to upload the file, reporting an "Upload failed" error. — SMUconlaw (talk) 14:27, 1 August 2016 (UTC)

I'd like to use the audios as part of a new WT:FUN competition. Not so sure on the ins and outs of the game, though. Something like X Factor??? --Turnedlessef (talk) 19:07, 24 July 2016 (UTC)

How possible is it for this to gain further browser support? If this worked in Safari, I'd probably use it all the time :) -Xbony2 (talk) 15:41, 31 July 2016 (UTC)

Unlike Chrome, which is supports MediaRecorder but doesn't support the audio/ogg mime type, Safari doesn't support MediaRecorder at all. So, we'd need a complete polyfill for MediaRecorder which works on Safari. I have yet to see one that works. (Preferably, it would use the same syntax as MediaRecorder itself.) --Yair rand (talk) 22:04, 2 August 2016 (UTC)

(1) the glossN in parameter {{calque}} does not seem to be working (see Μάγχη). (2) Were existing examples of its predecessor tN updated at the time of the change? (see 水素) — Saltmarsh^{συζήτηση-talk} 06:21, 25 July 2016 (UTC)

tN= and glossN= should be equivalent synonyms. Do they both not work? —CodeCat 15:37, 25 July 2016 (UTC)

Neither of them work — Saltmarsh^{συζήτηση-talk} 04:31, 26 July 2016 (UTC)

Ah, I found the problem, it's fixed now. Note, though, that the numbered parameters of {{calque}} are deprecated, and it's preferable to just use {{compound}} or another appropriate template instead. —CodeCat 12:23, 26 July 2016 (UTC)

I wouldn't say Μάγχη (Mánchi) is a calque at all. It's a sort of a transliteration of Manche. —Aɴɢʀ (talk) 13:16, 26 July 2016 (UTC)

Oops! and thank you — Saltmarsh^{συζήτηση-talk} 06:26, 27 July 2016 (UTC)

This template creates a url as follows:

This works fine for single words, but if there's a space in the term, wikisyntax interpretation turns that into a link to:

• http://www.websters1913.com/words/ + <everything in pagename or 1st parameter before the space> with <everything in pagename or 1st parameter before the space> + <space> + <pagename or 1st parameter> as the displayed text.

In other words, {{R:Webster 1913|plume grass}} displays: grass plume grass (followed by other text).

The link doesn't seem to be a problem, because the site apparently has multi-word terms on the same page with the main word, but it sure looks peculiar. Chuck Entz (talk) 14:06, 26 July 2016 (UTC)

AFAICT the site we are now using for Webster 1913 only links to single words. The second word does not seem to make any difference, at least with a space as separator. On other sites I have had to use other characters, such as "+", "-", and "_" to obtain a link to an MWE.

I found an MWE that the site actually has: "White horse". I cannot get to it using our template, which takes me to the entry for "White". The site seems a good deal more amateurish than the University of Chicago site we had been able to use. I hope there is another Webster 1913 site that we can use. Free Dictionary is better, but doesn't yield only Webster 1913 references. DCDuring TALK 18:35, 26 July 2016 (UTC)

That's because we should be replacing spaces with "%20" in the URL. --WikiTiki89 18:43, 26 July 2016 (UTC)

Did you try that? DCDuring TALK 20:25, 26 July 2016 (UTC)

Yes. I just don't know whether there is an easy way to do that automatically from a template, or whether we have to resort to lua. --WikiTiki89 20:28, 26 July 2016 (UTC)

DTLHS (talk) 20:30, 26 July 2016 (UTC)

Are you saying that we have to replace "plume grass" with "plume%20grass"? That doesn't seem to work: see User:DCDuring/Template:W13. Neither the display nor the page link work. DCDuring TALK 20:45, 26 July 2016 (UTC)

Hold on. The link to their entry for "White horse" works, with %20 hard-coded into {{{1}}}. The remaining technical problem is that the display shows %20.

The non-technical problem is one with the website that does not redirect from plume grass to their entry at Plume, where plume grass is a run-in. DCDuring TALK 20:52, 26 July 2016 (UTC)

Would Lua save us? DCDuring TALK 20:54, 26 July 2016 (UTC)

Relax, you only have to change the template, not the input to the template. Of course the redirect thing cannot be fixed, however. --WikiTiki89 21:13, 26 July 2016 (UTC)

Fixed --WikiTiki89 21:27, 26 July 2016 (UTC)

Thanks. Of course now the accidental correct link from "plume grass" to the entry "Plume" has been replaced by a link to non-existent "Plume grass". It will be necessary to insert correct one-word links for MWEs and have the display as at present . DCDuring TALK 21:51, 26 July 2016 (UTC)

I didn't figure out how to keep all current template usage unchanged and allow a single-word entry with a run-in to be the target for what we have as a multi-word entry. If optional parameter 2 for the target entry is used then parameter 1 must specify the display, even if the display is the same as PAGENAME or parameter 2. I look forward to seeing a better solution. DCDuring TALK 23:54, 26 July 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I tweaked the template. Is it working as intended now?

• {{R:Webster 1913|white horse}} → “white horse”, in Webster’s Revised Unabridged Dictionary, Springfield, Mass.: G. & C. Merriam, 1913, →OCLC.
• {{R:Webster 1913|plume grass|plume}} → “plume grass”, in Webster’s Revised Unabridged Dictionary, Springfield, Mass.: G. & C. Merriam, 1913, →OCLC.

— SMUconlaw (talk) 19:21, 30 July 2016 (UTC)

I checked many of the entries with spaces or hyphens and good results seem to occur with minimal extra typing (less than in my clumsy version). Thanks.

For some entries replacing {{R:Webster 1913}} with {{R:OneLook}} gives better results, at least if some modern dictionaries have the term. DCDuring TALK 20:05, 30 July 2016 (UTC)

I also note that some uses of {{R:Webster 1913}} are of the form (hypothetically at ]) {{R:Webster 1913|plume}} → “plume”, in Webster’s Revised Unabridged Dictionary, Springfield, Mass.: G. & C. Merriam, 1913, →OCLC.. I think this makes it less likely that newer users would persist in paging down to the run-in for plume grass. DCDuring TALK 20:11, 30 July 2016 (UTC)

I suppose those occurrences will have to be manually replaced. — SMUconlaw (talk) 20:19, 30 July 2016 (UTC)

There aren't very many. I wonder whether the template display should say something like "See plume grass at plume in Webster ...." DCDuring TALK 02:12, 31 July 2016 (UTC)

That's a good idea. I've updated the template – see the new documentation page (is it clear enough?). — SMUconlaw (talk) 18:15, 31 July 2016 (UTC)

Thanks. I wish could do better than guess at what might work best for normal users. The documentation looks good for the use cases we have so far. DCDuring TALK 19:36, 31 July 2016 (UTC)

Dear Sir/Madam,

I would like to know what word could be used for plural of support to be meant backing(s), is it wrong to say supports for plural of backing, if yes why?.

What word could be used for say "financial supports" at all? I mean to have many support from different sources not only one.

Best regards...Vaziri

While this isn't the best venue for this type of question (the Tea Room is where questions about terms generally go), I will try and help here. The sense of support which you are using is uncountable, so you never pluralize it. Instead, if you want to indicate that there is support coming from multiple sources you would form your sentence "...getting financial support from Jim and Jane..." or "...financially supported by Mary and Mark...". - TheDaveRoss 16:47, 27 July 2016 (UTC)

Would it be possible to split CAT:etyl cleanup according to the language section where {{etyl}} is being used? In other words, could all instances of {{etyl|...|en}} categorize into CAT:etyl cleanup/en, and so forth? I feel more confident deciding whether to replace {{etyl}}+{{m}} with {{der}} or with {{inh}} in some languages than in others. —Aɴɢʀ (talk) 14:32, 27 July 2016 (UTC)

That would lead to a lot of categories being created, so I think it would be best to limit it to some languages at once, the ones we're actually interested in categorising. Which languages are you interested in? —CodeCat 14:37, 27 July 2016 (UTC)

All Celtic languages (including non-modern ones) as well as Burmese and Lower Sorbian. —Aɴɢʀ (talk) 15:43, 27 July 2016 (UTC)

Done. —CodeCat 15:50, 27 July 2016 (UTC)

Thanks! —Aɴɢʀ (talk) 16:01, 27 July 2016 (UTC)

I've noticed for a while that the notifications on the top bar are switched; I'm getting talk page notifications under "Alerts" and thank notifications under "Notices". Also, I don't think pings are getting through to the notifications. — justin(r)leung _{{ (t...) | c=› }} 15:20, 28 July 2016 (UTC)

This is all dev stuff. They're messin around and using us as guinea pigs because Wiktionary is not important like Wikipedia is. --WikiTiki89 15:31, 28 July 2016 (UTC)

I think that arrangement makes sense tho. Alerts (talk page, mention, revert) are more important while notices (thanks, linking) are less so. --Giorgi Eufshi (talk) 16:01, 28 July 2016 (UTC)

It's just confusing that it keeps changing. --WikiTiki89 16:11, 28 July 2016 (UTC)

I'd like to remove the rollback link from my watchlist in preferences. My iPhone's Safari seems to have some problems. I click on wrong links most of the time and it's nothing to do with "thick fingers" The correct link is seen as highlighted when I click on it.--Anatoli T. ^{(обсудить}/^вклад) 00:50, 30 July 2016 (UTC)

CSS .page-Special_Watchlist .mw-rollback-link { display: none; } should work. —suzukaze (t・c) 20:23, 30 July 2016 (UTC)

@suzukaze-c Thanks but sorry, could you please clarify what I need to do? --Anatoli T. ^{(обсудить}/^вклад) 01:48, 31 July 2016 (UTC)

Copy and paste it to Special:MyPage/common.css. —suzukaze (t・c) 01:49, 31 July 2016 (UTC)

@suzukaze-c Thank you! --Anatoli T. ^{(обсудить}/^вклад) 10:19, 31 July 2016 (UTC)

No problem! —suzukaze (t・c) 10:20, 31 July 2016 (UTC)

@Kc kennylau, Hillcrest98, Esszet Could one of you add these features? (1) An argument allowing for a respelled stem to be given to indicate the proper pronunciation of the stem. This should ideally support multiple such stems to properly handle déjeuner and déjeusner (see tea room comments), e.g. |pronstem=déjeun,déjeûn. I implemented similar kind of stuff in Module:fro-verb, Module:ru-verb, Module:ru-noun; you might get some hints here. If multiple such stems is too hard, at least support one; if this is still too hard, support disabling the pronunciation entirely. (2) Correct pronunciation of i in -ions, -iez. This should be pronounced as not after two or more consonants. Thanks! Benwing2 (talk) 17:51, 30 July 2016 (UTC)

@Benwing2: Thanks for your attention. On which verb do you see the second problem? Thanks. --kc_kennylau (talk) 23:52, 30 July 2016 (UTC)

@Benwing2: The first issue has been solved. --kc_kennylau (talk) 23:58, 30 July 2016 (UTC)

@Benwing2, kc_kennylau: I just checked déjeusner and although the code has been added the problem still persists. 2WR1 (talk) 00:03, 31 July 2016 (UTC)

@Kc kennylau Check out montrer for example. Also, in approprier, is the pronunciation /a.pʁɔ.pʁi.je/ with consistent /ij/ correct? I would have expected prier /pʁi.e/ to be different from hypothetical priller /pʁi.je/. Benwing2 (talk) 07:14, 31 July 2016 (UTC)

@Benwing2: For montrer, I have fixed it. For approprier and prier, cf. fr:Annexe:Conjugaison en français/approprier. Also, cf. fr:Annexe:Conjugaison en français/briller which shows that prier and *priller do not have all the forms identical in terms of pronunciation. --kc_kennylau (talk) 10:56, 1 August 2016 (UTC)

@Kc kennylau Thank you! Another issue: Check out the difference in pronunciation of the future and conditional in approprier vs. the French equivalent. Benwing2 (talk) 12:16, 1 August 2016 (UTC)

@Benwing2: Fixed. --kc_kennylau (talk) 12:57, 1 August 2016 (UTC)

@Kc kennylau Awesome! Benwing2 (talk) 13:06, 1 August 2016 (UTC)

Before we had the Reconstruction namespace and reconstructions were in the Appendix namespace, there were often hard redirects from alternative forms to main forms. For example, Appendix:Proto-Indo-European/nepot- redirected to Appendix:Proto-Indo-European/népōts. But when we shifted to the new namespace, only the main entries were shifted, while redirects were left in the Appendix namespace, but had their targets changed to the Reconstruction namespace, so that Appendix:Proto-Indo-European/nepot- redirected to Reconstruction:Proto-Indo-European/népōts. The problem is that links like {{l|ine-pro|*nepot-}} now point to Reconstruction:Proto-Indo-European/nepot-, which (up until a few minutes ago, when I fixed it) was a redlink. So we had bluelink redirects in Appendix namespace with nothing linking to them, and links pointing to nonexistent pages in Reconstruction namespace. Can someone with a bot please go through all redirects of the form ] and move them, without leaving a redirect, to ]? Thanks! —Aɴɢʀ (talk) 09:17, 31 July 2016 (UTC)

There are also a whole bunch of old redirects from pages with spaces instead of slashes in the title (e.g. Appendix:Proto-Semitic *kalb-) that can be outright deleted. --WikiTiki89 14:22, 1 August 2016 (UTC)

Yeah, but those aren't so urgent because there aren't pages pointing to red links because of them. —Aɴɢʀ (talk) 19:35, 15 August 2016 (UTC)

The latest FWOD amanaty needed some improvement in its Arabic etymology. I replaced the misspelled red-linked Arabic etymon with a blue link to the correct word أمانة. The transliteration amānah needs to accompany the Arabic script. In other uses of the etyl template, the automatic transliteration works, but not in this one, even though I've coded it by carefully imitating how the template is used in cases where it does work. There's no difference that I can see, yet mine doesn't work. Johanna-Hypatia (talk) 00:56, 1 August 2016 (UTC)

Arabic needs the full vocalisation to be transliterated. Now, I can't find the Russian word mentioned there - аманат or аманати. If "аманати" is supposed to be the plural of аманат, then it's incorrect. --Anatoli T. ^{(обсудить}/^вклад) 01:02, 1 August 2016 (UTC)

Thank you both so much. Johanna-Hypatia (talk) 23:31, 4 August 2016 (UTC)