Wiktionary:Grease pit/2012/December

Could someone generate a list of all terms in OCS that contain the letter Я? This was discussed a while ago, and it was argued that this letter didn't exist yet as a separate letter in OCS. So all uses of it should be renamed, but I'm not knowledgeable about OCS so I don't know what the correct title would be. That's why I think some kind of cleanup list would help. Or perhaps someone could tag the entries with a category instead, like Category:Old Church Slavonic terms with Я? —CodeCat 14:11, 2 December 2012 (UTC)Reply

There seem to be only fifty-five such entries: недѣля · таяти · ясли · ято · яма · яснъ · ядьца · яръ · даяти · смияти · яко · каяти · каязнь · боязнь · нєприязнь · приязнь · прияти · ядь · приятєль · болярь · ярость · жѧтєлянинъ · крьстиянъіни · крьстиянинъ · солꙋнянъіни · солꙋнянинъ · ярьмъ · поясъ · вєлиѥядъ · ярьмьникъ · сꙋхоядьць · дѣля · дѣяти · ядра · ядъ · одѣяло · одѣяти · пиянъ · пияньствиѥ · пияньство · язва · язвина · кропля · капля · стрꙋя · вѣя · бꙋря · кꙋпля · кръмля · срьдоболя · тьля · вѣяти · пиря · шия · постєля. (You're welcome to add them to a category, if you like.) —Ruakh_TALK 16:52, 2 December 2012 (UTC)Reply

Looks like User:Ivan Štambuk added them, if you want to ask him what to do. —Μετάknowledge^{discuss/deeds} 16:59, 2 December 2012 (UTC)Reply

He hasn't been around for some time, though. Is anyone else familiar with OCS? —CodeCat 17:29, 2 December 2012 (UTC)Reply

Wikitiki89 might be. - -sche (discuss) 18:43, 2 December 2012 (UTC)Reply

I'm not that familiar with it. I can understand it (mostly because of my knowledge of Russian), but I cannot predict how things would be spelled and cannot tell you if "я" was used in these cases or what was used instead (although "ꙗ" and "ѣ" are distinct possibilities). I presume it would be difficult to find the correct forms online because of modern standardization, etc., so I would suggest maybe looking in manuscripts? --WikiTiki89 19:35, 2 December 2012 (UTC)Reply

Actually, he's edited a little bit recently. I'd say he and User:Stephen G. Brown are our best bets. —Μετάknowledge^{discuss/deeds} 20:27, 2 December 2012 (UTC)Reply

Could the argument have been simply that 'ya' should be '(big or little) yus'? - -sche (discuss) 19:40, 2 December 2012 (UTC)Reply

It would have usually been little, not big, yus', but I had the feeling that the yuses would be harder to substitute since they actually represent a different sound. I guess that would depend on where our spellings came from. --WikiTiki89 19:49, 2 December 2012 (UTC)Reply

Spelling varied depending on location and date, as several of these sounds tended to merge with one another. In fact, it was the change from /ę/ to /ja/ that caused the original letter for /ę/ to come to be used for /ja/ as well; the modern letter Я, originally written Ѧ. I'm not sure if OCS has any kind of normalised spelling that is generally used, but if there isn't, we could just agree to use Ꙗ whenever the original (non-merged) pronunciation was /ja/. I have no idea what sound Я represents in the words listed above, though. —CodeCat 19:54, 2 December 2012 (UTC)Reply

This discussion was copied from w:Talk:Old Church Slavonic#Use of Я?.

On Wiktionary we have come across a few Old Church Slavonic entries that use Я in their names. I noticed that a few words in this article also use it. But if the article about Я is correct in stating that Я is a later form of Ѧ, then presumably the use of the newer form in these entries is anachronistic. Nonetheless, it seems that other online sources also use this letter in those words. So is this common practice among Old Church Slavonic studies, or is it really an error brought on by modern writing, and was Ꙗ actually the intended letter? Or does Я actually stand for Ѧ in these words? CodeCat (talk) 17:42, 2 December 2012 (UTC)Reply

‹Я› is indeed a later form of ‹Ѧ›; more specifically, from Peter the Great's "civil script". Academic works consistently transliterate OCS because of the obvious need for a single scheme (as opposed to alternating between Glagolitic and Cyrillic) and because Glagolitic and Cyrillic can sometimes be ambiguous. I've only quickly glanced over them, but it seems as though ‹Ꙗ› should be used in each case (недѣля → недѣлꙗ). I'll replicate my comment on Wiktionary. --WavesSaid (talk) 23:18, 2 December 2012 (UTC)Reply

P.S. It seems Church Slavonic (not Old) spelling has confused things; in it, ‹Ѧ› and ‹Ꙗ› are simply positional variants of one another, and they were dropped to ‹Я› in the civil script. --WavesSaid (talk) 23:24, 2 December 2012 (UTC)Reply

Ok, so you think we can safely replace every occurrence of Я with Ꙗ in Old Church Slavonic words? —CodeCat 03:21, 7 December 2012 (UTC)Reply

I'm not the person you asked, but yes, I think so. —Angr 10:46, 7 December 2012 (UTC)Reply

Ok I've moved them all. —CodeCat 15:20, 7 December 2012 (UTC)Reply

In the vote on tabbed languages, it was suggested that instead of {{l|en|bar}}, {{l|de|Bar}} etc, we could switch to {{l/en|bar}}, {{l/de|Bar}} etc, because the latter format requires equally few keystrokes while being less stressful for our servers and bots. These subpages could be created for all languages en masse by bot. What needs to be done for that to happen? What information needs to be copied into the subpages? Can we do away with script subpages ({{en/script}}) at the same time? PS: how goes the effort to fix the page-breaking black hole that is {{list}}? - -sche (discuss) 05:39, 3 December 2012 (UTC)Reply

How much would this actually help? How often is {{l}} actually used on pages? -- Liliana • 07:24, 3 December 2012 (UTC)Reply

Support. All in all, {{l}} ends up making too many transclusions. Linking to a language section should be done as often as possible. I oppose deleting script subpages. And may I propose that we stop using any template for lists and just directly transclude manually formatted lists? — Ungoliant ^(Falai) 12:30, 3 December 2012 (UTC)Reply

Support, but oppose deleting script subpages. --WikiTiki89 12:36, 3 December 2012 (UTC)Reply

Before I can support this, I think we need to think carefully on what consequences this will have. If there are thousands of linking templates, that means an edit to any one of them will need to be duplicated a thousand times. We also need to consider which parameters currently in {{l}} need to be included in these new templates. We probably don't need most of them, but what about the transclusions of {{l}} that already use these extra parameters? Those will need to be fixed first. —CodeCat 14:37, 3 December 2012 (UTC)Reply

I'd think we really only need {{l/en}}. We're the English Wiktionary, so all terms are translated to English, meaning this will be the single most common language to link to. {{l|de}} etc. can still be used in parallel but they shouldn't get own templates. But that's just my opinion. -- Liliana • 14:45, 3 December 2012 (UTC)Reply

I think that would be a good place to start. But since linking to English is so common, I'd suggest making a shorter name for it (a redirect) so that it's even easier to use in definitions. I'd suggest {{d}} but that's already used as a redirect for {{delete}}. Maybe it can be appropriated for this new purpose, considering {{l/en}} would be used much more than {{delete}}? —CodeCat 14:51, 3 December 2012 (UTC)Reply

I agree with Liliana. By the way — note that {{l/en}} is currently a stripped-down version of {{l}} that doesn't support transliterations and glosses and whatnot, so it's not exactly a general-purpose replacement for {{l|en}}. Conversely, note that we have {{el-l}} and {{ja-l}} and {{he-onym}} that offer language-specific features to varying extents — and that are not mutually argument-compatible. —Ruakh_TALK 14:54, 3 December 2012 (UTC)Reply

Or we can choose a middle ground: not only English, but only commonly {{l}}'d languages. --WikiTiki89 14:57, 3 December 2012 (UTC)Reply

Let's start with English and see how that goes? —CodeCat 15:17, 3 December 2012 (UTC)Reply

We should probably find out if it would actually be an improvement first... --Yair rand (talk) 15:59, 3 December 2012 (UTC)Reply

What about the semantic relations content? They don’t link to English except in English sections. Look at a#Portuguese, I counted 15 wikilinks which would benefit directly from {{l/pt}}, plus those generated by templates. Most importantly, if we don’t create {{l/foo}} for every language, we won’t be able to write templates that use them (we could, but wouldn’t we need to use #ifexist:?). Even if we end up doing this, we can still keep {{l}}. We could only enforce {{l/foo}} for pages that take too long to load, for example.

As for parameters, because the goal here is making the template faster, I suggest that we have only the term, the alternative text and, for languages with more than one script, sc= (or we could have, say, {{l/sh/Cyrl}} and {{l/sh/Latn}}, and {{l/sh}} for whichever is the default. I don’t know how we deal with multi-script languages to be honest).

The biggest problem here is that if we change something we will need thousands of changes, but I think it’s probably worth the trouble. I agree with Yair rand: we should find out if it really is an improvement. — Ungoliant ^(Falai) 16:25, 3 December 2012 (UTC)Reply

*Can an analogous line of thinking be applied to {{t}} and its relatives? Wouldn't the potential benefit would be larger, especially for the English entries for highly polysemous terms, like ], which have several translation tables, some of which are huge. The numerous languages that use sc=Latn would seem to warrant a special template that eliminated the need to look up, test for, or transclude {{foo/script}}. I don't know what the next most common scripts are for similar treatment, but there might be further performance improvement opportunities.{{t-simple}} sure makes ] load faster. I'd missed its deployment due to storm-caused loss of internet here.

Ungoliant's suggestion of focusing implementation on the entries that are very slow to load and save seems like an excellent approach. They both would benefit the most and are thus likely to yield sufficiently measurable improvement. DCDuring TALK 17:40, 3 December 2012 (UTC)Reply

I'm a heavy user of {{l|lv}}, which is my standard form of linking from a Latvian entry to any other Latvian entry (form-of pages, declension/conjugation tables, synonyms/antonyms, related/derived forms, etc.). If you guys decide to change something in {{l}}, please let me know and take into account all the Latvian pages full of {{l|lv}}'s. --Pereru (talk) 10:34, 4 December 2012 (UTC)Reply

A bot could probably replace {{l|lv| with {{l/lv|. —CodeCat 14:16, 4 December 2012 (UTC)Reply

Can we test this in a page like a? How would the change in load time be measured? — Ungoliant ^(Falai) 20:34, 6 December 2012 (UTC)Reply

In this version of the main Latvian conjugation table template, I had decreased the colspan parameter in the non-cojugated forms area (lower half of the table) for the labels ("Present", "Past", "Conjunctive", etc.) from "2" to "1", while increasing it for the actual forms from "1" to "2", to get a more harmonious look. It worked, but for some reason the actual forms now became bold, just like the labels. I undid the change because of this, but I wondered if there is some way to prevent the forms from becoming bold while keeping the labels bold. Does changing colspan in this way automatically cause the boldening? Is this because of this kind of table having predefined parameters listed somewhere else? --Pereru (talk) 10:34, 4 December 2012 (UTC)Reply

It's because you added !, which indicates a "header" cell (<th>), at the start of the line. For a regular table-cell with a colspan, you'd do exactly the same thing that you did, except the line would start with | instead. —Ruakh_TALK 13:27, 4 December 2012 (UTC)Reply

Right you are. Thanks! --Pereru (talk) 08:14, 5 December 2012 (UTC)Reply

Two users have had problems with the visibility of quotations.

See Talk:cromulent and WT:ID#Removal of quotes. DCDuring TALK 14:24, 6 December 2012 (UTC)Reply

Very strange. The original hiding of the quotations is also javascript-dependent, so not having js enabled can't be the issue. Maybe it's just delaying too long for the button-adding js to run that they left the page before it activated? --Yair rand (talk) 17:02, 6 December 2012 (UTC)Reply

Two is still a small number of users possibly with the same problem. But it is unusual for users to speak up about a problem at all, let alone so close together, about seemingly identical problems. The entries involved are not "big" either.

If your hypothesis is correct, is there a way to reduce the delay? Is there a different button graphic that would load faster? DCDuring TALK 19:45, 6 December 2012 (UTC)Reply

When Mediawiki 1.21wmf5 was rolled out, I started to experience large delays before specifically Common.js ran. I filed bug 42532 about it. There seems to sometimes be a gap of as much as five seconds between when the visible page content finishes loading and gadgets run and when the site js runs. I don't know what's causing it or whether it's related to the quotations issue. Is anyone else experiencing large delays before site js runs? --Yair rand (talk) 19:53, 6 December 2012 (UTC)Reply

I just loaded ] (force of habit). It loaded a bit faster than before because of {{t-simple}} (Thanks!) but there was an additional second or two before the translation bar arrow appeared. Hope that little bit of data helps. DCDuring TALK 20:32, 6 December 2012 (UTC)Reply

Just noting what I'm seeing, I'm not sure if it's helpful... I'm seeing the quotations problem in IE8 (Firefox & Chrome are ok). The quotes have disappeared, and there's no quotations button to click on. Another thing... with IE8, it's not possible to see the translations any more: the translation tables are closed, there's no show/hide button there, and clicking the header of the translation bar doesn't open the translation table. Tables with template "rel-top" have the same issue as "trans-top". Waiting (> 10 minutes) doesn't change anything on the page. HTH. -- Curious (talk) 21:42, 6 December 2012 (UTC)Reply

Very helpful indeed. This is more exactly what two other users have experienced, but they didn't specify browser. I had heard that IE8 finally fixed the JS problems that earlier versions had. Perhaps not. DCDuring TALK 22:03, 6 December 2012 (UTC)Reply

Does the "In other projects" section of the sidebar show up? Do gadgets work? Is there an error message? --Yair rand (talk) 22:14, 6 December 2012 (UTC)Reply

I have duplicated the problem in IE9. The quotations and other "expanders" appear for me, but when I click on them, I have a lot of white space where the translations or quotations ought to be. Of course clicking on edit shows the content in all its glory. I will try to answer your questions, but you can probably duplicate it all yourself. 72.225.236.92 22:20, 6 December 2012 (UTC)Reply

Strange, IE9 works fine for me. Do the "Show quotations" and "Show translations" buttons in the sidebar work? --Yair rand (talk) 22:25, 6 December 2012 (UTC)Reply

I posted too soon. The problem I am having in IE9 is limited to translation tables and "rel" tables and has to with the tables not playing nice with the project boxes and images on the right hand side. Clicking the control can cause whitespace to appear because the table is too wide to appear next to the project boxes and images. This is a UI problem but may be unrelated to some or all of the end user reports. I did not observe any delay for "other projects". No error message. The visible controls seem to work. 72.225.236.92 22:39, 6 December 2012 (UTC)Reply

With IE8, in the side bar, sections "In other projects", "Visibility" and "Feedback" are missing. There is no error message. Gadgets: I can enable Tabbed Languages, it seems to work fine (I've never used it before in any browser, so I'm not sure if it's doing everything it's supposed to do, but it looks ok.). The gadget for adding translations (Conrad.Irwin/editor.js) doesn't work, but that's unrelated to this episode, it stopped working earlier (I'm not sure when (some time between July 2010 and October 2012), I'm not very active here). An earlier version of editor.js is imported at nl.wiktionary (nl:Gebruiker:Conrad.Irwin/editor.js), and that one works in IE8. -- Curious (talk) 23:06, 6 December 2012 (UTC)Reply

The contributions/confusions of User:72.225.236.92 were mine. DCDuring TALK 23:53, 6 December 2012 (UTC)Reply

Ruakh fixed a problem in Common.js that was apparently breaking it for users of IE8 and lower. Do the quotations work properly now? --Yair rand (talk) 16:12, 9 December 2012 (UTC)Reply

Yes, they do. In IE8, all issues (quotations, sidebar, translation table, editor.js) are fixed now. -- Curious (talk) 22:36, 13 December 2012 (UTC)Reply

While we're fixing misspelled OCS, can some also compile a list of terms using "ъі"? They should all be moved to names using the letter ꙑ instead. Ivan created them before ꙑ had been added to Unicode, so he used ъі as a kludge instead. Maybe someone could program a bot to move all the entries using ъі (can bots move pages?) as well as to fix all links containing ъі. I don't know whether the sequence ъі also has legitimate uses in languages like Ukrainian and Belarusian. —Angr 22:34, 6 December 2012 (UTC)Reply

Yes, bots can move pages. I assume you want to keep the redirects? DTLHS (talk) 00:52, 7 December 2012 (UTC)Reply

the list:(объічаи, обꙑчаи), (црькъі, црькꙑ), (пламъі, пламꙑ), (мъіто, мꙑто), (мъішь, мꙑшь), (гъібѣль, гꙑбѣль), (жрьнъі, жрьнꙑ), (локъі, локꙑ), (нєплодъі, нєплодꙑ), (цѣлъі, цѣлꙑ), (хорѫгъі, хорѫгꙑ), (смокъі, смокꙑ), (хъізъ, хꙑзъ), (пронъіръ, пронꙑръ), (мотъіла, мотꙑла), (мъішьца, мꙑшьца), (въісота, вꙑсота), (испъіть, испꙑть), (забъіть, забꙑть), (побъіть, побꙑть), (съіть, сꙑть), (нєѩсъіть, нєѩсꙑть), (къізнь, кꙑзнь), (слъішатєль, слꙑшатєль), (ръібарь, рꙑбарь), (мъітарь, мꙑтарь), (гръдъіни, гръдꙑни), (льгъіни, льгꙑни), (правъіни, правꙑни), (простъіни, простꙑни), (пѹстъіни, пѹстꙑни), (свѧтъіни, свѧтꙑни), (господъіни, господꙑни), (єгѵпьтѣнъіни, єгѵпьтѣнꙑни), (єлинъіни, єлинꙑни), (крьстиянъіни, крьстиянꙑни), (магъдалъіни, магъдалꙑни), (милостъіни, милостꙑни), (поганъіни, поганꙑни), (прѣгъіни, прѣгꙑни), (самарѣнъіни, самарѣнꙑни), (сѫсѣдъіни, сѫсѣдꙑни), (солѹнянъіни, солѹнянꙑни), (сѵрофоникиссанъіни, сѵрофоникиссанꙑни), (кънигъі, кънигꙑ), (чаръі, чарꙑ), (къізньникъ, кꙑзньникъ), (избъітъкъ, избꙑтъкъ), (иноѩзъічьникъ, иноѩзꙑчьникъ), (ѩзъічьникъ, ѩзꙑчьникъ), (хъіщьникъ, хꙑщьникъ), (въхъіщьникъ, въхꙑщьникъ), (тъісѧщьникъ, тꙑсѧщьникъ), (тъісѫщьникъ, тꙑсѫщьникъ), (промъісльникъ, промꙑсльникъ), (прибъітъкъ, прибꙑтъкъ), (хъітрьць, хꙑтрьць), (мъітоимьць, мꙑтоимьць), (ръіло, рꙑло), (любъі, любꙑ), (владъіка, владꙑка), (владъічьствиѥ, владꙑчьствиѥ), (владъічьство, владꙑчьство), (съіновьство, сꙑновьство), (пѣнъі, пѣнꙑ), (къіка, кꙑка), (осъпъі, осъпꙑ), (сѣдинъі, сѣдинꙑ), (хъізина, хꙑзина), (пѣготъі, пѣготꙑ) DTLHS (talk) 02:54, 7 December 2012 (UTC)Reply

"I don't know whether the sequence ъі also has legitimate uses in languages like Ukrainian and Belarusian." Belarusian doesn't have letter "ъ". Ukrainian and Kazakh don't have the sequence "ъі". The modern cognates for "ъі" seem to be rather consistent - Russian/Belarusian - ы, Ukrainian - и.

Where can I get the fonts for OCS. I can't see some letters on my work computer. --Anatoli ^{(обсудить}/^вклад) 03:23, 7 December 2012 (UTC)Reply

I use Dilyana, which is free to download for personal use. See Appendix:Old Cyrillic script for some other suggestions. —Angr 12:11, 7 December 2012 (UTC)Reply

I don't think Ukrainian has ъ at all either. --WikiTiki89 08:41, 7 December 2012 (UTC)Reply

Oops, yes, you're right. What was I thinking? It's an obsolete letter in Ukrainian but I'm sure not when it was used. Our Ukrainian entries shouldn't have it, anyway. Belarusian and Ukrainian use "'" instead of the Russian "ъ". In any case, "ъі" is near impossible in modern languages. --Anatoli ^{(обсудить}/^вклад) 11:34, 7 December 2012 (UTC)Reply

As long as the bot corrects the links at more or less the same time as it moves the pages, there's no reason to keep the redirects. —Angr 10:26, 7 December 2012 (UTC)Reply

My opinion here, is that we should just use ы instead of either ꙑ or ъі, because it is just an orthographic variant and is easier to type. Compare how we don't use ƿ or ᵹ for w and g in Old English. --WikiTiki89 11:47, 7 December 2012 (UTC)Reply

Easier to type depends on your keyboard. I have to copy-n-paste ы just the same as ꙑ. The difference between the OCS case and the OE case is that modern editions and dictionaries of Old English don't use ƿ or ᵹ either, but modern editions and dictionaries of OCS do use ꙑ. —Angr 12:01, 7 December 2012 (UTC)Reply

Do you mean the Unicode codepoint ꙑ? Because in printed texts (1) you can't distinguish ꙑ from ъі, and (2) ы is just a graphical variant of ꙑ, similar to the difference between ᵹ and g. No one who knows anything about Slavic languages would ever tell you that ы is a distinct letter from ꙑ. --WikiTiki89 12:46, 7 December 2012 (UTC)Reply

The OCS Wikipedia uses ꙑ: w:cu:Словѣньскъ ѩꙁꙑкъ. —Stephen ^(Talk) 12:06, 7 December 2012 (UTC)Reply

Easy to type is not a good reason to replace. Other factors are more important. Using a character palette (Firefox plug-in) solves the problem of copy-pasting frequently and not so frequently used characters that are on keyboards. Словѣньскъ ѩзꙑкъ is written using some letters, not currently used by modern languages but it doesn't mean we have to replace those letters for our convenience. --Anatoli ^{(обсудить}/^вклад) 12:27, 7 December 2012 (UTC)Reply

I would support ꙑ for "etymological" reasons. It is obviously a digraph of ъ and і originally, but ъ was chosen instead of ь because it's a back vowel. So while to modern writers there is no distinction between ꙑ and ы, this distinction was certainly significant to Old Church Slavonic writers. —CodeCat 15:26, 7 December 2012 (UTC)Reply

No, because ы is a direct descendant of ꙑ. Scribes just got too lazy to write the little hook thing. ы is completely unrelated to ь. --WikiTiki89 17:24, 7 December 2012 (UTC)Reply

I understand that. But what I meant was that I doubt an OCS scribe would have made such an "error", since the two yer-vowels were still clearly distinguished in their language. Using ы instead of ꙑ would be an anachronism, similar to using j or u in Latin. —CodeCat 16:28, 9 December 2012 (UTC)Reply

Well...

1. We do use "u" in Latin.
2. OCS scribes did make such an "error" later on once the "ъі" combination started being seen as a single letter.
3. Before it started being seen as a single letter, it wasn't a single letter; so, the "ъі" combination would make much more sense than "ꙑ".
4. The "ьі" combination never existed in any language as far as I know and so would never have been confused with "ы".

So basically I would support either sticking with "ъі" (in most languages we refrain from using ligatures, so why should OCS be different) or moving to "ы", but I would prefer not using "ꙑ". --WikiTiki89 16:51, 9 December 2012 (UTC)Reply

Somewhere up above you said "you can't distinguish ꙑ from ъі" but in fact you can: ꙑ doesn't have a dot over the і, while ъі does. Printed modern books on OCS, like Horace Lunt's textbook, use ꙑ. It's clearly not ъі because the right-hand half looks like a small capital I, not like a lowercase i. The only reason we have ъі in entries at all is that Ivan started adding them before ꙑ had been added to Unicode, and he used it as a kludge. Now that ꙑ is available, we should use it. But ы is common enough in later manuscripts (Russian Church Slavonic, etc.) that there should be a redirect from the ы form if it doesn't already exist, and an {{also}} tag if it does. —Angr 09:03, 21 December 2012 (UTC)Reply

I'm fairly sure that OCS manuscripts did not have a dot on the letter і. --WikiTiki89 17:40, 23 December 2012 (UTC)Reply

Maybe not, but we're not an OCS manuscript. We're a 21st-century website using 21st-century computer fonts that do. —Angr 17:46, 23 December 2012 (UTC)Reply

That's exactly my point. So, what would be wrong with using "ъі" or "ы"? --WikiTiki89 18:17, 23 December 2012 (UTC)Reply

I just noticed the entry ѹ. Apparently, Unicode has realised that although treated as a single letter with one sound, it is orthographically a digraph. So now оу is the recommended representation. Should we do the same with ꙑ too (i.e. keep it as the digraph ъі)? As far as I know, ъі and ꙑ are indistinguishable from each other in OCS manuscripts, even though in theory ꙑ represents "y" while ъі is identical to ъи and represents "ŭji". In practice, the sequence ŭji tended to become yji anyway (in pronunciation) but we can't tell as this was written as ъі or ъи, so the difference is actually not really significant. —CodeCat 18:58, 23 December 2012 (UTC)Reply

As I said before, I support this. --WikiTiki89 19:08, 23 December 2012 (UTC)Reply

ъі and ꙑ may be indistinguishable from each other in OCS manuscripts, but we aren't an OCS manuscript, and they aren't indistinguishable here. Nor are they indistinguishable in modern books that use modern Cyrillic typesetting for OCS. In Lunt's textbook, for example, he uses a character that looks like the one on the left in the image. Using ъі would look like the one on the right; it just looks wrong, and it is wrong. There is absolutely no reason at all to continue using this phony combination of letters just because it sort of vaguely looks like the correct letter if you don't have your glasses on. —Angr 20:07, 23 December 2012 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Can you link us to an example of modern Cyrillic typesetting for OCS? --WikiTiki89 20:16, 23 December 2012 (UTC)Reply

Here is a large picture of an old manuscript which uses "ъі" and/or "ы" in various places, such as in the rightmost word of the third line of text and the rightmost word on the fifth line of text. Here are several more large images of manuscripts. I do not detect a dotted i and any of the first several images, perhaps because that letter is not used, or perhaps because it is used but not dotted. I make no comment on what letter Wiktionary should use. - -sche (discuss) 20:35, 23 December 2012 (UTC)Reply

Here is a book where OCS is typeset in modern Cyrillic letters, including ꙑ. -sche's images are not what I mean by modern Cyrillic typesetting. —Angr 20:54, 23 December 2012 (UTC)Reply

What I am trying to say is that the i-with-dot is itself a modern convention, and didn't exist in old Cyrillic. ꙑ was, at the time, completely indistinguishable from the sequence of ъ followed by і because і had no dot. They were one and the same thing. The modern distinction is based on modern usage in Russian and Belarusian and on etymological considerations. There is actually some ambiguity even within OCS itself: the sequence <ъі> could be interpreted as either the single vowel /y/, the disyllabic sequences /ŭjĭ/ or /ŭji/, or the sequences /yjĭ/ or /yji/. What's more, the sequence <ъи> could represent all five of those too since і and и were interchangeable with each other (so yes, that includes ъи = /y/!). In a similar vein, the sequence <ьі> or <ьи> could represent either /ĭjĭ/ or /ĭji/, and <іі> or <ии> could be either /ijĭ/ or /iji/, all four of which were etymologically and probably phonologically distinct in first instance. All of this is further complicated by a late Proto-Slavic sound change which converted /ŭj/ into /yj/ and /ĭj/ into /ij/, so that the orthographical confusion also becomes a phonological confusion. So it is theoretically possible that we (as modern readers of OCS texts) don't know how to interpret the sequence <ъі> and this whether or not to normalize it as <ꙑ>, since it's possible that what we convert into <ꙑ> actually represented, say, /yjĭ/. —CodeCat 21:02, 23 December 2012 (UTC)Reply

I know that і-with-dot is a modern convention; the point is that Wiktionary is displayed in modern fonts that put dots over і's, so when we use ъі it shows up with a dot. Which looks silly, and makes Wiktionary look ignorant, especially when OCS Wikipedia itself uses ꙑ. As for using ꙑ when what's meant is /yjĭ/, well, we'll just have to be careful not to use it in those cases. —Angr 21:21, 23 December 2012 (UTC)Reply

@-sche and @Angr: None of those examples have a "і" with one dot. Do you think we need to request Unicode to created a separate character for the dotless "і" and then move all our pages to it? --WikiTiki89 21:14, 23 December 2012 (UTC)Reply

The YERU WITH BACK YER Ꙑ ꙑ was added to Unicode because it is “found alongside Ы ы in important manuscripts, such as the Dobrejšo Gospels. The ability to make the distinction between ꙑ and ы is of great importance to palaeography, and essential for a comprehensive palaeographic description of Cyrillic sources.” If we don’t change it over now, then someone will be expending 50× more energy doing this after Wiktionary has a lot more OCS in it.

I think we should move these entries. —Michael Z. 2013-02-12 04:19 z

They have now all been moved. For some there's a redirect, for others there isn't, but they all have ꙑ now rather than ъі. —Angr 06:38, 12 February 2013 (UTC)Reply

I was adding an entry under "see also", when the edit was disallowed with No header for the language and part of speech, which makes no sense, since the language header and POS header were already on the page. -- 70.24.245.172 22:29, 7 December 2012 (UTC)Reply

Seems to be working now... (same edit) -- 70.24.245.172 22:38, 7 December 2012 (UTC)Reply

Thanks. I've fixed what I believe to be the problem (it didn't count something as a POS header if it contained =, and the page you were trying to edit had only the POS header {{acronym|lang=en}}). I also unchecked the "Prevent the user from performing the action in question" box; CodeCat seems to have checked that box last month on a number of filters; I'm not sure why, and I don't think she discussed it first. —Ruakh_TALK 22:38, 7 December 2012 (UTC)Reply

See WT:BP#Special:AbuseFilter.2F9 for what's probably the closest thing to discussion of the matter. Chuck Entz (talk) 23:25, 7 December 2012 (UTC)Reply

That seems pretty far from consensus. And I don't see any notice of specific action either. Seems like a Good Faith excess of BOLDness. DCDuring TALK 00:45, 8 December 2012 (UTC)Reply

How do I get started on creating an index? My Facebook group-mate asked me if I could make one for the Dhivehi language. --Lo Ximiendo (talk) 10:03, 8 December 2012 (UTC)Reply

P.s. If you're curious about what his name is, he's Naail Naseer, and I think he lives in Chennai, India. He's the one who added the Dhivehi word for spoon, ސަމްސާ. --Lo Ximiendo (talk) 10:58, 8 December 2012 (UTC)Reply

Update: I got the index's skeleton down, here it is: Index:Dhivehi. Now for the next step: the letters themselves. (I copied {{index/Arabic}}; was going for {{index/Esperanto}} and looked at the former when it hit me that I must repeat after {{index/Arabic}}.) --Lo Ximiendo (talk) 13:20, 9 December 2012 (UTC)Reply

Ask User:Conrad.Irwin to add it to the list of indexes automatically updated by Conrad.Bot. --Yair rand (talk) 16:09, 9 December 2012 (UTC)Reply

Thanks. Is Conrad active? --Lo Ximiendo (talk) 16:12, 9 December 2012 (UTC)Reply

Can someone with an American IP please download this out-of-copyright dictionary and upload it to somewhere non-Americans can access, e.g. archive.org or some file-sharing website. --Vahag (talk) 13:30, 8 December 2012 (UTC)Reply

Does hathitrust.org have the same restrictions? Chuck Entz (talk) 14:45, 8 December 2012 (UTC)Reply

Yes. Using proxies does not help. --Vahag (talk) 14:56, 8 December 2012 (UTC)Reply

Here you go: . Geefdee (talk) 21:21, 8 December 2012 (UTC)Reply

The obvious file-sharing website would have been Wikimedia Commons, which does accept PDFs. —Angr 23:17, 8 December 2012 (UTC)Reply

Thanks! I uploaded it to archive.org --Vahag (talk) 09:21, 9 December 2012 (UTC)Reply

Good afternoon,

would it be possible to have -ubus instead of -ibus in certain dative/ablative plurals? See here (look for "acubus", "arcubus" and so on). Thank you, --Fsojic (talk) 14:13, 8 December 2012 (UTC)Reply

If no one helps with this by Friday, send me a direct reminder on my talk page, and I'll try to take care of it this weekend. --EncycloPetey (talk) 22:56, 10 December 2012 (UTC)Reply

I don't understand : where interwikis other than French (the one I have just added) come from ? --Fsojic (talk) 14:21, 8 December 2012 (UTC)Reply

Template:la-decl-1st/doc. — Ungoliant ^(Falai) 17:10, 8 December 2012 (UTC)Reply

Could this category include Category:Declension-table templates by language, Category:Adjective inflection-table templates by language, and other categories from Category:All templates ? --Fsojic (talk) 15:20, 8 December 2012 (UTC)Reply

It shouldn't. Grammar (usage in a sentence) and morphology (inflection, declension, word-ending changes) are two different things. --EncycloPetey (talk) 22:55, 10 December 2012 (UTC)Reply

now ignores any and all errors that happen. I hope that will improve its uptime. If desired, I could make it create a list of pages that would've made the bot stop. -- Liliana • 21:35, 8 December 2012 (UTC)Reply

The boxes have suddenly become much larger: http://imgur.com/xFEnS (Firefox 17.0.1). DTLHS (talk) 18:29, 10 December 2012 (UTC)Reply

I assume you had the old "Tabbed browsing of language sections" selected in WT:PREFS? That's the older version by Atelaes. I've removed it from WT:PREFS. --Yair rand (talk) 18:53, 10 December 2012 (UTC)Reply

Yes, thanks that was it. DTLHS (talk) 19:01, 10 December 2012 (UTC)Reply

In the w:arXiv, abstracts include math in w:TeX notation surrounded on either side by dollar signs. Some of these are quoted in citations:pages, dollar signs and all. Can someone please generate a list of citations: pages that include the string arXiv and ≥two dollar signs? Even better would be to include, in addition, all ns:0 pages that include the string arXiv and ≥two dollar signs in proximity to one another (arXiv on a line and the dollar signs on the same or next). I can then fix them (probably manually to avoid error).​—msh210℠ (talk) 19:19, 10 December 2012 (UTC)Reply

I didn't find any in the main namespace.

1. Citations:superbeam
2. Citations:coinvariant
3. Citations:bicrossproduct
4. Citations:anticode
5. Citations:hyperslab
6. Citations:microlocal
7. Citations:superscaling
8. Citations:supertwistor
9. Citations:hyperangular
10. Citations:bicollinear
11. Citations:bifactor
12. Citations:pseudoredundancy
13. Citations:pseudoweight
14. Citations:quasicyclic
15. Citations:isofield
16. Citations:hyperarc
17. Citations:copositivity
18. Citations:episturmian
19. Citations:transdimensional

DTLHS (talk) 20:07, 10 December 2012 (UTC)Reply

Thanks much! I'm herewith removing from your list the fourteen I just fixed. I'll get to the rest one day soon (I hope).​—msh210℠ (talk) 07:59, 11 December 2012 (UTC)Reply

And now I've done the rest. Striking this section.​—msh210℠ (talk) 15:55, 12 December 2012 (UTC)Reply

For some reason, the above template seems not to be working. At least, when I look at a Latvian suffix like (deprecated template usage) -ains, there is nothing written, nothing clickable, in the ====Derived terms==== section. What happened? (This morning, it was still working...) --Pereru (talk) 21:28, 12 December 2012 (UTC)Reply

Seems to be broken everywhere not just on -ains. --WikiTiki89 21:50, 12 December 2012 (UTC)Reply

It looks like it's the {{deriv}} template- there's the same problem in {{prefixsee}}, {{circumfixsee}}, and some Spanish conjugation templates. {{deriv}} seems to be the common factor. Chuck Entz (talk) 03:58, 13 December 2012 (UTC)Reply

There haven't been any changes to that template recently, so it must be some change to the code behind the scenes. It's also strange that there are apparently 3 separate fail states: -ity (no output) -able (Problem loading data. Please wait a moment and try again.), -tion (no error message but no entries displayed). DTLHS (talk) 04:12, 13 December 2012 (UTC)Reply

I don't get it. There's nothing obvious in {{deriv}} that could have been changed, transcluded, etc down the line. —Μετάknowledge^{discuss/deeds} 04:18, 13 December 2012 (UTC)Reply

It depends on the category tree extension. Either that or some dependency must have been modified, which would be invisible to us. I think this is a bug report for the same issue. DTLHS (talk) 04:32, 13 December 2012 (UTC)Reply

Does this mean there is nothing to do but wait and see? (I had wondered if this had anything to do with me having the "Tabbed Languages" preference on.) --Pereru (talk) 08:25, 13 December 2012 (UTC)Reply

It would seem that the problem at -tion is still there, in spite of multiple null edits. I wonder if it has anything to do with the template being used three times on one page? Chuck Entz (talk) 03:36, 15 December 2012 (UTC)Reply

Further checking shows the following entries (so far) having the template displaying the same behavior: -ar,-ric, -phobic, -phobe, phobia, and -er. -er is unique in that the English (under Etymology 3) doesn't work, but Dutch and German do. Chuck Entz (talk) 01:32, 16 December 2012 (UTC)Reply

In some entries, the line with {suffixsee} starts with an asterisk (*). It looks like those are not working. Compare:

• asterisk: -cracy, -graphy, -phobic
• no asterisk: -ify, -phagous, -tomy -- Curious (talk) 13:17, 16 December 2012 (UTC)Reply

Good catch! Perhaps we should alter the template so the asterisk is integral to it and delete the externally provided one. Unless there is a solution more consistent with existing template-usage and -formatting habits. DCDuring TALK 13:44, 16 December 2012 (UTC)Reply

(After edit conflict) Yep, that's it. I went to the first one and removed the *. It started working. I put the * back. It stopped working. I seem to remember asterisks figuring in another template-related problem not long ago. Chuck Entz (talk) 13:47, 16 December 2012 (UTC)Reply

I deleted the * in all the entries mentioned here, and they all immediately started working. Unfortunately, there are a lot more entries than can be easily checked. Chuck Entz (talk) 14:01, 16 December 2012 (UTC)Reply

Which of the Spanish conjugation templates don't work?

@Pereru: I don't use tabbed languages, but have the same problem. DCDuring TALK 14:26, 16 December 2012 (UTC)Reply

There was a wikimedia-based bug in addition to this one that has since been fixed- that was the initial subject of the thread. You can ignore those comments. Meanwhile, I look back to see about the problem with * and templates that I vaguely remembered: it was in October, and it had to do with the template {{prefixsee}}. Ruakh explained the mechanics behind the problem in detail, but "fixed" it by removing the * in the entry in question. It reminds me of the old w:Henny Youngman one-liner about the man who goes to the doctor and says: "Doctor, doctor, it hurts when I do this..." and the doctor says: "So don't do that...". We need to make it so we don't have to "discover" this again every couple of months. Chuck Entz (talk) 14:30, 16 December 2012 (UTC)Reply

Indeed. I have just been amusing myself testing {{circumfixsee}} to see whether Wikitiki's Nov 14 changes to all three non-Spanish {{deriv}}-using templates had something to do with this. Her changes didn't look like they could have done so, but I'm no good at reading templates, so testing was necessary. My test says they were NOT the problem. DCDuring TALK 14:42, 16 December 2012 (UTC)Reply

Hey, who are you calling a "her"? --WikiTiki89 19:42, 16 December 2012 (UTC)Reply

It was an assumption. No offense was intended, of course. Perhaps we need templates {{his|her}}, {{she-he}} and {{him-her}} that pseudorandomly assign a gender-specific pronoun. Or I could have used "the" instead of "her". DCDuring TALK 20:51, 16 December 2012 (UTC)Reply

Don't worry, I wasn't offended. Just felt the need to point it out. --WikiTiki89 20:59, 16 December 2012 (UTC)Reply

{{User gender}} DTLHS (talk) 21:09, 16 December 2012 (UTC)Reply

As Ruakh described it, the problem has more to do with the way the Wikimedia software works than with anything in the templates themselves. I put a big fat warning message in the documentation for the templates in question, so that at least we'll know what's going on when this comes up again in a couple more months. Chuck Entz (talk) 14:53, 16 December 2012 (UTC)Reply

I wonder whether it has to do with writing templates in a way that tags are opened in one template and closed in another, which kluge would make for a lack of robustness in the behavior of the templates. I sure that with the Coming of Lua, all such problems will be resolved. DCDuring TALK 20:51, 16 December 2012 (UTC)Reply

In any event clicking on the blue link gives a more complete listing in the form of the category pages, which do not have the quantitative limit that I believe the category expansion function has. DCDuring TALK 20:54, 16 December 2012 (UTC)Reply

Was looking in MediaWiki:Common.css to see what font we 'force' for Mongolian script (see for example Manchu#Proper noun). And it seems we don't, and I can only see boxes. Should we? Mglovesfun (talk) 19:57, 13 December 2012 (UTC)Reply

Well I guess if you don't mind the large batch of rendering errors in non-Microsoft fonts, there are choices. But unfortunately, there are people who do read this script, and for these it's either Microsoft or none at all. -- Liliana • 21:33, 13 December 2012 (UTC)Reply

Hello! The coverage of Wiktionary for Spanish irregular verbs is stupendous, but it appears the Spanish verbs ending in *r (conjugation *) at the bottom of the conjugation template of irregular verbs is broken. After expanding it, it gives the message "Problem loading data. Please wait a moment and try again." but I've been trying again over the past couple days. I realize the same information can be collected on the category page linked below of the conjugation, but this tool was quite useful and a great resource for Spanish learners. Just wanted to report it in case it had gone unnoticed. Here are some links: aunar and list excellent list Appendix:Spanish_irregular_verb_types. Thanks for checking it out.--El aprendelenguas (talk) 01:07, 14 December 2012 (UTC)Reply

See 2 sections above. This actually appears to be fixed- you may need to do a hard refresh or null edit to restore functionality. DTLHS (talk) 01:10, 14 December 2012 (UTC)Reply

Ah, didn't see that section, silly me :) Yes, it's fixed now. Thanks!--El aprendelenguas (talk) 05:24, 14 December 2012 (UTC)Reply

What's the red template error that comes up where I've used <math>? I copied the line of text from Wikipedia. Equinox ◑ 22:47, 14 December 2012 (UTC)Reply

Whoops, that's a bug. Go report on mediazilla:. -- Liliana • 22:54, 14 December 2012 (UTC) nvm, fixed now -- Liliana • 23:47, 14 December 2012 (UTC)Reply

Can someone change the second sentence from xx:Poetic to Langname poetic terms? Ultimateria (talk) 20:39, 15 December 2012 (UTC)Reply

 Done. —Ruakh_TALK 00:00, 16 December 2012 (UTC)Reply

Thank you! Ultimateria (talk) 04:09, 16 December 2012 (UTC)Reply

Is there a way to get this to work? I want a fast way to jump to the current state of FWOTDs so I can see what the next open date is and set something for it. —Μετάknowledge^{discuss/deeds} 23:16, 15 December 2012 (UTC)Reply

Not really, but I've replaced it with something that should, I believe, serve the purpose. Please take a look. —Ruakh_TALK 23:53, 15 December 2012 (UTC)Reply

Can’t it be done through recursive calls of a template? — Ungoliant ^(Falai) 00:19, 16 December 2012 (UTC)Reply

Mediawiki doesn’t allow recursion. What a pity. — Ungoliant ^(Falai) 00:30, 16 December 2012 (UTC)Reply

Not quite what I was picturing, but I'm happy with it. Thanks! —Μετάknowledge^{discuss/deeds} 00:29, 16 December 2012 (UTC)Reply

How do I get this infernal list template to get the days in correct RTL order and not mess with the sizes of various words? —Μετάknowledge^{discuss/deeds} 22:27, 16 December 2012 (UTC)Reply

OK, I fixed the order hackishly, but זונטיק is still strangely oversized in the list, probably due to being bolded. —Μετάknowledge^{discuss/deeds} 22:32, 16 December 2012 (UTC)Reply

Here's my guess: maybe never use the hypernym parameter. --Lo Ximiendo (talk) 22:42, 16 December 2012 (UTC)Reply

Why does this overly complicated template still exist? Why hasn't it been replaced by a simple expanded one that calls no templates?

Actually, why aren't all of these that are lists of the members closed sets of names replaced by an expanded version? These still seem to be real download delay generators. Repeated application of substing should make it relatively straightforward to do so. At some point the substing will reveal the ridiculous tests that are built into these.

Template uniformitarianism must end. DCDuring TALK 23:57, 16 December 2012 (UTC)Reply

It has been replaced, by User:CodeCat/list helper, which is used for all the list templates on a. You could use it for this, too, if you prefer. —CodeCat 00:24, 17 December 2012 (UTC)Reply

Is User:CodeCat/list helper used on ]? I replaced all the list-templates on that page with simple templates a couple weeks ago, and DCDuring replaced those with raw wikitext last week. - -sche (discuss) 01:36, 17 December 2012 (UTC)Reply

Well, it was, and to great effect according to the Wikimedia person who gave us the analysis (cut the load time back to half or a third or something like that). So the changes you made may not have been necessary at all... —CodeCat 03:05, 17 December 2012 (UTC)Reply

See WT:Grease pit/2012/November#Expanding the list templates. —CodeCat 03:07, 17 December 2012 (UTC)Reply

My edit was to allow Liliana to test if KassadBot could edit the page if {{list}}'s complex syntax were not invoked, not to improve load times per se (though I noted that my edit did appear to do that, too). Now that KassadBot simply ignores errors and presses on, feel free to re-instate your own simplified version of the list templates. - -sche (discuss) 03:11, 17 December 2012 (UTC)Reply

I think we can get rid of {{list}} altogether and remove one more redundant step in the process. Just look at its code and you'll see. So that would mean replacing {{list|yi|days of the week}} with {{list:days of the week/yi}} which is a bit more transparent, and slightly faster. Would it be ok if I bot-replaced all calls to {{list}} in that way? —CodeCat 03:20, 17 December 2012 (UTC)Reply

I support that. (But can someone please fix my bloody list? Or is LX's suggestion the only solution?) —Μετάknowledge^{discuss/deeds} 05:27, 17 December 2012 (UTC)Reply

(Oh, and not surprisingly, {{list:days of the week/ar}} has the same problem.) —Μετάknowledge^{discuss/deeds} 05:30, 17 December 2012 (UTC)Reply

I support that, too. - -sche (discuss) 05:48, 17 December 2012 (UTC)Reply

Can they also be listed Sunday-Saturday rather than Monday-Sunday? --WikiTiki89 06:21, 17 December 2012 (UTC)Reply

My persomal preference starts with Monday, but in this case it might make sense for the week to end with shabes. —Μετάknowledge^{discuss/deeds} 06:45, 17 December 2012 (UTC)Reply

Also, why is zuntik a hypernym? --WikiTiki89 07:01, 17 December 2012 (UTC)Reply

That's the hack I mentioned earlier. Obviously, that allows the first thing to be displayed to be די טעג פֿון דער וואָך (please check that that's the best way to say it). —Μετάknowledge^{discuss/deeds} 07:18, 17 December 2012 (UTC)Reply

Well, that's gonna have to be fixed. --WikiTiki89 07:29, 17 December 2012 (UTC)Reply

Also, FWIW, even {{list:days of the week/en}} is Sunday-Saturday. --WikiTiki89 07:29, 17 December 2012 (UTC)Reply

• If a particular language is not well served by the template, the answer is not to further complexify the template, further setting back performance and increasing our dependence on those very few who actually understand our baroque template structure. The answer is to replace the template with a custom template, preferably one that is simple and addresses the distinct needs of some languages that have a common need, eg, right-to-left script.
• Template uniformitarianism must end. DCDuring TALK 11:27, 17 December 2012 (UTC)Reply

  Actually a fix for this wouldn't slow anything down. It would just entail adding RTL or LTR marks in a few places, no extra logic. --WikiTiki89 11:59, 17 December 2012 (UTC)Reply

Why is RTL correct? IMO it's wrong. This is English Wiktionary: we list words LTR, even RTL words.​—msh210℠ (talk) 15:23, 17 December 2012 (UTC)Reply

Either way, it's buggy, as you can see here, without the little "hack", it displays the leftmost day of the week to the left of the hypernym and the rest of them to the right of the hypernym. --WikiTiki89 15:32, 17 December 2012 (UTC)Reply

I've made some changes, and I think it works, but I'm not sure if I did it the "HTML-correct" way because I don't really know how this works. I inserted a RTL mark at the beginning of each Yiddish word, and an LTR mark at the end. I also converted it to use my new list helper template, as this fix wouldn't have been possible without it! —CodeCat 15:58, 17 December 2012 (UTC)Reply

@CodeCat: First of all: thank you. It totally works now. Would you be able to perform this service for the rest of the RTL list templates (basically Hebrew, Arabic, and Yiddish)?

Also, when we use your list helper, some of the cool stuff like the list of which languages use that specific list template are not generated. I'd like it if we could keep those features. I think Yiddish is also not listed, because it's not using the template.

@Wikitiki89: Yeah, sure. I changed the week to start with Sunday. You could've done it yourself, I wouldn't have reverted you.

@DCDuring: You do realize that the only reason this whole project doesn't fall apart is this "template uniformitarianism", right? (Not to mention the fact that every time you say that you make me think of sedimentology, which is the last thing I want to think of this time of year.) —Μετάknowledge^{discuss/deeds} 16:11, 17 December 2012 (UTC)Reply

We have overdosed on it. Latin script languages don't need what other languages need. There are ways of showing Coordinate terms that don't require templates (appendices, categories) or could work with much simpler templates. Poor performance will ensure that some entries don't get edited and that users won't bother coming back. You do realize that users are the principal justification for getting funds for MWF if not themselves the source of funds. DCDuring TALK 16:23, 17 December 2012 (UTC)Reply

As I believe I have mentioned before, we get a lot of complaints from spurious to fatuous to intelligent, but I can't remember any of them ever complaining about speed. Editors certainly do, but as you rightly pointed out, the users should be the focus. In fact, it seems to me that our users tend to navigate toward pages with less bytes but longer pagetitles on more obscure subjects (i.e. the opposite of ] and ]), because that's what dictionaries are traditionally used for. Is it still such a big problem? —Μετάknowledge^{discuss/deeds} 16:42, 17 December 2012 (UTC)Reply

{{list helper}} deliberately forced an LTR order for RTL lists by having &lrm; between every item. It's not a bug, and reversing it in the individual list template is kind of ridiculous. --Yair rand (talk) 19:30, 30 December 2012 (UTC)Reply

It's not the order that's the bug. It's the fact that the first item in the list appears before (to the left of) the hypernym. --WikiTiki89 00:30, 31 December 2012 (UTC)Reply

I would like to replace this with User:CodeCat/list helper, which is faster and easier to use. But the change isn't quite trivial, so each individual list template will need to be changed individually by a human editor. I have made an example change so you can get an idea what needs to be changed: diff. The {{list doc}} template adds documentation and puts the list in a category; this used to be done by the old {{list helper}} template, but I believe it is cleaner if the documentation is kept strictly separate from the template itself. Being able to wrap it in a <noinclude> also makes the template faster. Once {{list helper}} has been orphaned, I am hoping to just move my template over it, and then bot-replace all occurrences of {{User:CodeCat/list helper (which will then be a redirect) with the proper name, and then delete it from my userspace. So... who wants to help? Here is a list of all templates that still use it. Please ask here or on my talk page if you have any questions. —CodeCat 03:02, 18 December 2012 (UTC)Reply

I don't want to help, but it would be ungrateful, to say the least, for me not to. I will be willing to work on any language I have a minimal grasp of, but not tonight. DCDuring TALK 03:16, 18 December 2012 (UTC)Reply

I don't think you really need to know the language to do this, though. If you know how to use AWB and regular expressions, I think that would make it much easier to do. Unfortunately I am on Linux so I can't use AWB, but maybe I can make a kind of "interactive" bot script that does the same thing. —CodeCat 03:19, 18 December 2012 (UTC)Reply

This currently asks users to use the non-existent {{unblock-ip}}. Can someone who knows what they should in fact use fix the page for future blockees? —Μετάknowledge^{discuss/deeds} 06:35, 18 December 2012 (UTC)Reply

Either create unblock-ip or use {{unblock}}. Mglovesfun (talk) 20:17, 18 December 2012 (UTC)Reply

Conrad Irwin's accelerated translation adding tool doesn't work any more for me (Firefox and Chrome on Linux). Is anyone experiencing the same problem? Matthias Buchmeier (talk) 18:58, 18 December 2012 (UTC)Reply

Me too (Chrome on Windows). Seems like -sche's experiencing the same thing. —Μετάknowledge^{discuss/deeds} 19:01, 18 December 2012 (UTC)Reply

I think it was -sche who broke it: —Μετάknowledge^{discuss/deeds} 19:04, 18 December 2012 (UTC)Reply

I experienced some weirdness yesterday (). — Ungoliant ^(Falai) 19:12, 18 December 2012 (UTC)Reply

It had been laggy (slow to actually add translations) yesterday before I edited it. Based on the timing, it seems my edit is what broke it, but I can't tell why. - -sche (discuss) 19:35, 18 December 2012 (UTC)Reply

I wonder if anyone could fix the following bug, please: The accelerated translation doesn't work for a language when there is {{trreq}} for another language, which sits next to it, e.g. I can't add Macedonian (mk) or Mongolian (mn) when there is {{trreq}} for Mirandese (mwl). --Anatoli ^{(обсудить}/^вклад) 23:04, 18 December 2012 (UTC)Reply

An error in User:Conrad.Irwin/editor.js is causing an irrecoverable JavaScript handling error in HTMLUnit, and possibly other browsers. This problem is line 2107, line offset 3957, see below (my emphasis):

"Latn"},nds:{alt:0,g:"mfn",hw:1,p:1,sc:"Latn"},nds-de:

Hyphens aren't allowed in keynames. The boldface text needs to be changed to 'nds-de:' (i.e. encapsulated by quotes). This is a change that happened today and broke the script in certain browsers. I'd fix it myself, but the page is protected, and I don't have the privs. Many thanks to whoever can swiftly fix this oversight.--El aprendelenguas (talk) 21:52, 18 December 2012 (UTC)Reply

Aha! Fixed, thanks! - -sche (discuss) 22:02, 18 December 2012 (UTC)Reply

Discussion moved to WT:ES#Browbeat_-_possible_etymology.

Once in a while in a Wikipedia article I want to link from an unusual word to the appropriate Wiktionary entry. Sometimes I've added an anchors to the Wiktionary entry, right at the specific sense with which the word is used in the Wikipedia article. An example on the Wikipedia side (from wikipedia:John Harvard (statue)) is here (follow the links to see the anchors I added to Wiktionary):

On the left is that most felicitously chosen of all like devices, the three open books and the veritas of Harvard.

Per someone's suggestion I'm asking if I should be getting a similar effect in some other way. EEng (talk) 00:42, 22 December 2012 (UTC)Reply

{{senseid}}? Mglovesfun (talk) 18:10, 22 December 2012 (UTC)Reply

{{senseid}} and {{anchor}} seem functionally identical; the only difference I can see is that {{senseid}} causes senses to be slightly more indented than other senses (compare "house" vs "device"), which is just slightly unschön, so I think continuing to use {{anchor}} is good. - -sche (discuss) 20:07, 22 December 2012 (UTC)Reply

{{senseid}} highlights the relevant sense in blue for supporting browsers. --Yair rand (talk) 17:11, 25 December 2012 (UTC)Reply

Oooh! I love the highlighting. This should be more visible to Wikipedia editors -- maybe an enhanced example at ? EEng (talk) 06:07, 28 December 2012 (UTC)Reply

Is there a way to find and change instances templateless lines like this, adding lang= as necessary based on the L2 header the line is in? - -sche (discuss) 20:50, 22 December 2012 (UTC)Reply

Not without a bot that is able to figure out the name of the section. I don't think regular expressions alone would be powerful enough to do it. —CodeCat 21:25, 22 December 2012 (UTC)Reply

KassadBot applies lang= parameters to {{IPA}} when it's missing them. It should be possible to adapt that code, shouldn't it? - -sche (discuss) 22:20, 22 December 2012 (UTC)Reply

I'm sure there are more than enough {{alternative form of}} needing a lang parameter to justify a later bot run for that task later on. As long as it's possible and likely to eventually happen, we could do the change as a two-step process: convert to templates now, then convert all {{alternative form of}} under a non-English header when a suitably-capable bot is made available. Of course, that would cause a temporary increase of erroneous Category:English alternative forms members (searching on "Alternative form of ,"framed":false,"label":"Reply","flags":,"classes":}'>Reply

My format.js has some code (thanks to Ruakh) that edits in language codes based on L2s.​—msh210℠ (talk) 06:39, 23 December 2012 (UTC)Reply

And so we keep going? :) Our entry ѹ itself states that the single-character encoding is deprecated in favour of the two-character sequence оу. I presume that we'll want to rename our entries and such to reflect that. However, this is kind of the same as the debate about ꙑ above. Both ꙑ and ѹ were OCS digraphs that represented single sounds, so presumably if we change ѹ to оу then we should also change ꙑ to ъі? —CodeCat 21:38, 23 December 2012 (UTC)Reply

Has Unicode deprecated ꙑ the way it's deprecated ѹ? —Angr 21:48, 23 December 2012 (UTC)Reply

I think it has done the opposite actually, which kind of confuses me, because the cases of the two letters are pretty similar. Except that no modern Slavic language uses any character or sequence that graphically resembles оу. But it was originally written that way in imitation of Greek usage, and у by itself was used to write Greek words with upsilon, so it was definitely no less digraph-y than ꙑ was. I think the reason for deprecating ѹ is that it can't correctly be written with in capitals (Оу, ОУ). The digraph ꙑ also has a capital form Ꙑ but there is no form with capital Ъ and small і, presumably because this isn't needed as that letter was never used at the beginning of a word. Still, it is a bit inconsistent... —CodeCat 21:56, 23 December 2012 (UTC)Reply

Be that as it may, as long as Unicode deprecates ѹ but encourages ꙑ, I think we should use ꙑ but change any pages using ѹ to оу. —Angr 22:10, 23 December 2012 (UTC)Reply

I don't think it specifically encourages ꙑ over ъі or ы, but it did introduce the character more recently. So presumably there was demand for it and they caved. —CodeCat 22:14, 23 December 2012 (UTC)Reply

I took your "done the opposite" to mean they specifically encouraged it, but still the absence of deprecation is good enough reason for us to continue to use it. —Angr 22:28, 23 December 2012 (UTC)Reply

Well, endorsing is closer to encouraging than it is to discouraging. :) —CodeCat 22:31, 23 December 2012 (UTC)Reply

The updated standard allows for monograph and digraph letter uk to appear in the same document, as well as the three widely-used combinations of capitalization along with reproducing historical use of red ink in initials:

• оу Оу ОУ (lc, initial cap, and all-caps)
• ꙋ Ꙋ (contrast to the monograph uk U+A64B, U+A64A)
• Оу (A style used in manuscripts and print)

The combined digraph letter uk (ꙋ Ꙋ) was also a security risk. For example, a malicious website can send you to a URL that looks like it contains о+у, but actually has ѹ. Therefore OS fonts either omitted it or used the incorrect glyph.

References:

• Proposal: Proposal to encode additional Cyrillic characters in the BMP of the UCS
• Extensive discussion: On CYRILLIC LETTER OMEGA WITH TITLO and on CYRILLIC LETTER UK

We should definitely follow the Unicode recommendation on uk. —Michael Z. 2013-02-12 19:25 z

In {{ga-copular forms}} I've used {{l-self}} so that the links turn into boldface without linking when the template is transcluded on that particular word's page. It works everywhere so far except on b', where it's not bold and the link to ] is still clickable. I assume it's the apostrophe that's causing this behavior, but why, and is there any way to fix it? —Angr 22:32, 23 December 2012 (UTC)Reply

I've seen this problem before. It has something to do with the software converting some instances of ' to HTML code but not others. There is a way to fix it but I don't remember what it was. I think Ruakh knows. —CodeCat 22:41, 23 December 2012 (UTC)Reply

Indeed, the problem is that {{PAGENAME}} replaces apostrophes with &#39; (e.g., at ], {{PAGENAME}} evaluates to b&#39;), so {{l-self}} thinks that b' is not the current page-name. One solution I've used in the past, when comparing something to {{PAGENAME}}, is to wrap both comparands in {{localurl:...}}, which converts (for example) both b' and b&#39; to https://dictious.com/en/b%27 so that #ifeq: can see their essential equality. —Ruakh_TALK 23:01, 23 December 2012 (UTC)Reply

I played around with it a bit and found that using &#39; in place of the apostrophe works. Don't know if it's the ideal solution, but it gets the job done. —Angr 23:00, 23 December 2012 (UTC)Reply

How can I disable keyboard shortcuts? I looked everywhere in preferences and couldn't find such an option. I never use them, and they are very irritating when I try to type an AltGr character on the wrong keyboard layout and end up saving the page instead. --WikiTiki89 23:46, 24 December 2012 (UTC)Reply

Adding $('').attr('accesskey',null); to your JS would probably work. --Yair rand (talk) 17:10, 25 December 2012 (UTC)Reply

Ok, I'll try that. But shouldn't this be in preferences anyway? --WikiTiki89 17:20, 25 December 2012 (UTC)Reply

If they are standard Web accessibility shortcuts then you should turn them off in your browser (which might offer a site-specific disable command), rather than Wiktionary providing an option. Equinox ◑ 22:06, 26 December 2012 (UTC)Reply

No, I mean the WikiMedia-specific ones (like Alt-S for saving an edit). --WikiTiki89 22:12, 26 December 2012 (UTC)Reply

Right, but that's standard. Like how if a page on Wiktionary uses <a> to create a link to another page on Wiktionary, it's still a standard hyperlink, and a browser will understand how to manipulate it. Similarly with these access keys; for example, in my browser (Firefox 17.0.1 on Windows 7), I can disable them by opening about:config and changing ui.key.contentAccess from 5 to 0. —Ruakh_TALK 02:23, 27 December 2012 (UTC)Reply

The template page says that {{de-adj|er|sten}} will generate PAGENAME (comparative PAGENAMEer, superlative am PAGENAMEsten), but it doesn't. Can someone add this function? Ultimateria (talk) 17:28, 30 December 2012 (UTC)Reply

LOL, Sae1962 added this but broke the template in doing so, then went and added it to the docpage, but nobody thought to fix the doc after the edit was reverted. Yair's fixed it now. —Μετάknowledge^{discuss/deeds} 17:40, 30 December 2012 (UTC)Reply

Oh, lovely. Thanks, Yair! Ultimateria (talk) 18:28, 30 December 2012 (UTC)Reply

As the page loads, I can see all tabs (Faroese, Hungarian, Icelandic, and the Maori section I just added), but once it's done loading, only the Faroese tab is visible and all the categories from the other sections have been grouped with the Faroese categories on that single tab. Is this just me, or is anyone else seeing this? I don't know what the error is... the Faroese templates? —Μετάknowledge^{discuss/deeds} 02:41, 31 December 2012 (UTC)Reply

I use the regular interface (no TL), and I can only see the Faroese section; the other sections are hidden inside the conjugation table. Did someone forget to close a tag in the template code? See . - -sche (discuss) 02:47, 31 December 2012 (UTC)Reply

 Fixed. —Ruakh_TALK 03:07, 31 December 2012 (UTC)Reply

Thank you! —Μετάknowledge^{discuss/deeds} 03:34, 31 December 2012 (UTC)Reply

I found here a bug where there are 2 identical "also" sections at the top of the page. If anyone knows of a quick way to find any more of them and clean them up, it would be nice. --Wikt Twitterer (talk) 15:32, 31 December 2012 (UTC)Reply

It's a behavioral "bug". If one clicks on the first L2 section edit, then one is not aware of the existence of anything above the L2 and may add {{also}}. If one checks one's work by using the preview function, the duplication is not evident. As sometimes saving takes time, one's attention could already be elsewhere when the screen shows the duplication. It would take a dump run to find the instances I think. See WT:TODO. DCDuring TALK 16:16, 31 December 2012 (UTC)Reply

See Wiktionary:Todo/Also appearing twice. —Ruakh_TALK 16:33, 31 December 2012 (UTC)Reply

There's also an Autoformat "bug". If {{also}} is added in an L2 section, AF puts it at the top of the entry without regard to what is there and without marking the duplication. That seems to account for a large number of the Romance language entries on the surprisingly large list. I have no idea if it is worth fixing or whether it is easier to periodically (annually?, whenever the spirit moves?) rerun the Perl script on a dump. DCDuring TALK 18:19, 31 December 2012 (UTC)Reply

There are also some instances of {{also}} appearing lower down on the page (translation tables for example)- I assume this is also something that should be fixed? DTLHS (talk) 20:34, 31 December 2012 (UTC)Reply

If Autoformat moves them up to the top of the entry, then the content may no longer appear where the user intended it. Some users seem to use {{also}} as "See also". For instance, I saw two uses referencing the usage notes of a homophonous entry. Perhaps all of the {{also}}s appearing at the top of an entry or an L2 section could be moved to the very top of the page and renamed to {{topalso}}. The others could be marked for manual cleanup.

OTOH, this might not be worth the trouble. Perhaps just marking the mislocated {{also}}s would be better. DCDuring TALK 22:25, 31 December 2012 (UTC)Reply

I'd like to add a parameter for gender to Template:ast-pp, so inflected forms of it, e.g. lliberaes show the gender. --Wikt Twitterer (talk) 16:31, 31 December 2012 (UTC)Reply

Shouldn't it have a full inflection line, showing the plural forms as well like adjectives do? —CodeCat 16:33, 31 December 2012 (UTC)Reply

It ought to, yes. I suck at templates though so someone else can fiddle with that. It'll need parameters for feminine singular, neuter singular, masculine plural, feminine plural (not neuter plural) --Wikt Twitterer (talk) 16:59, 31 December 2012 (UTC)Reply

Why not clone something like {{it-pp}}? SemperBlotto (talk) 17:02, 31 December 2012 (UTC)Reply

Do we still have cleanup bots, like Autoformat? Bots that would do menial tasks like putting this in the correctly alphabetised place? If so, which bots? Doesn't Gloves's bot do things like that? --Wikt Twitterer (talk) 16:57, 31 December 2012 (UTC)Reply

Oh God no, not my bot. KassadBot (talk • contribs) does, I've long been saying we need more than one autoformat bot. There was some talk of TheDaveRoss's bot doing it, in fact he volunteered, but then didn't do it. Mglovesfun (talk) 16:59, 31 December 2012 (UTC)Reply

Possibly because some characters are romanised to apostrophes, and the software interprets the apostrophes as forming part of our bold and italic syntax, when I go to this template, it shows (transliterations: Revised ', McCune–Reischauer ', Yale '). When I look at an entry like ], it shows (transliterations: Revised eo, McCune–Reischauer ', Yale e). - -sche (discuss) 18:40, 31 December 2012 (UTC)Reply

The problem was missing romanizations, more than romanizations that start or end with apostrophes. To fix it, I've changed the ''…'' stuff to <i>…</i>, but I think we should also use liberal application of {{#if:…|…}} so that we don't even list romanizations we don't have. —Ruakh_TALK 19:27, 31 December 2012 (UTC)Reply