Wiktionary

Wiktionary:Grease pit/2016/March

< Wiktionary:Grease pit

Template:wi edit

I created {{wi}}, an italicized {{w}}. See this diff. --Daniel Carrero (talk) 03:20, 1 March 2016 (UTC)[reply]

What's the point? Double-quote already means italics and doesn't require a second version of any given template. Equinox ◑ 10:34, 1 March 2016 (UTC)[reply]
{{m}} differs from {{l}} in more than just adding ''. {{w}} is much simpler template, so simple wrapping with '' is a better solution than having two separate templates. --WikiTiki89 15:27, 1 March 2016 (UTC)[reply]
This makes me really angry and I have put it up for deletion. Templates should be things that help human beings improve this project, not some kind of hobbyist bullshit that helps nobody, but gives one little individual a little autistic glow of pleasure. Equinox ◑ 23:09, 1 March 2016 (UTC)[reply]
Hey, can I pay you micropayments to stop fucking up Wiktionary? I'm not rich but I could really go for that. Fuck you. Equinox ◑ 23:21, 1 March 2016 (UTC)[reply]
I'm not even angry at you, but fuck you. You don't want that template, let's delete it. --Daniel Carrero (talk) 23:29, 1 March 2016 (UTC)[reply]
kk. kisses. Equinox ◑ 23:38, 1 March 2016 (UTC)[reply]
@Equinox: There is no need for such language. Daniel was not trying to do anything wrong. In fact he did us a courtesy by informing us that he created the template. Most templates are just created and no one knows about them until it's too late to do anything about them. --WikiTiki89 23:40, 1 March 2016 (UTC)[reply]
So it’s not just me, he also disrespects other people. --Romanophile ♞ (contributions) 23:55, 1 March 2016 (UTC)[reply]
He's fine most of the time, but when he loses his temper he does and says dumb things. Fortunately, that doesn't happen often. Chuck Entz (talk) 02:36, 2 March 2016 (UTC)[reply]
There are already too many templates for linking to Wikipedia. Some are redirects and some actually differ. So far I've found {{pedia}}, {{pedialite}}, {{slim-wikipedia}}, {{Wikipedia}}, and {{wikipedia}}. If you could help remove some templates rather than add more, it would make me happy. Chokladkaka (talk) 16:41, 7 April 2016 (UTC)[reply]
I think we should get rid of all the duplicates too, but it's not easy to get everyone to agree on which one to keep, so lack of consensus and unwillingness to compromise results in apathy. —CodeCat 16:44, 7 April 2016 (UTC)[reply]

Auto-add words with etymologies to WT:WE (wanted entries) by language edit

A Russian word фу́хтель (fúxtelʹ) is derived from German Fuchtel, фигля́р (figljár) is from Polish figlarz or шки́пер (škíper) is from Dutch schipper, which are all undefined at the moment. Could those red-linked words be automatically added to WT:WE? It would also help with some definitions and help improve entries in two languages. If spellings are wrong or a word doesn't exist, then etymologies in target languages could also be fixed. Alternatively or also, etymologies with red links type of categories by languages could be useful. Editors of source languages will see that there are words derived from the language they know.--Anatoli T. (обсудить/вклад) 04:14, 1 March 2016 (UTC)[reply]

You mean, listing, say, all Russian words that are redlinks in the etymology section of all entries in Wiktionary:Wanted entries/ru?
Maybe someone could list them all by parsing the latest dump somehow.
I'm pretty sure we can't just expect the page to be automatically updated by the software, because it would have to constantly check all pages to stay up-to-date.
One possible compromise would be creating a new category Category:Russian redlinks with all uses of {{m|ru}} (and maybe {{l|ru}} too) that are red links. (it still would be very expensive if we are using "ifexist" in all pages, I'm not sure if Lua has a good replacement for that) --Daniel Carrero (talk) 04:25, 1 March 2016 (UTC)[reply]
I just want to discuss. I can imagine, the categories will be swamped with red-links. It's always much easier to reference a word than create (even a simple) entry for it. --Anatoli T. (обсудить/вклад) 05:08, 1 March 2016 (UTC)[reply]
Just to test, I edited {{m}} and {{l}} to populate exactly 1 category: Category:Russian redlinks. If people like it, we can create the same category for other languages.
Suggestion: if you wanted an actual list of Russian redlinks, (rather than a list of the entries where the Russian redlinks can be found) I wonder if someone could use that category to generate the list. --Daniel Carrero (talk) 05:43, 1 March 2016 (UTC)[reply]
Sorry, I don't understand this category. It doesn't make sense. I was thinking of schipper to be added to Category:Dutch redlinks (because it's a Dutch word), figlarz to be added to Category:Polish redlinks (because it's a Polish word), etc. --Anatoli T. (обсудить/вклад) 05:51, 1 March 2016 (UTC)[reply]
If schipper is a redlink (an uncreated page), it does not exist so it can't be added to Category:Dutch redlinks.
My idea is like this: all entries that have a Russian redlink are added to Category:Russian redlinks. For example, kulimász (a Hungarian word) is in the category because it has a red link to Russian коломазь. If you create коломазь, then kulimász will be removed from the category. This is a way to find all Russian redlinks. --Daniel Carrero (talk) 07:20, 1 March 2016 (UTC)[reply]
I'm open to other ideas, BTW. Maybe the category should be called Category:Entries with Russian redlinks. --Daniel Carrero (talk) 07:23, 1 March 2016 (UTC)[reply]
I see. If e.g. a Veps entry tageta has a red link to a Russian word отдаля́ться (otdaljátʹsja). (CodeCat even created a category for this: Category:R:vep:UVVV with red link). If I make this entry (отдаляться), it may help understand the meaning of the Veps word, because the source dictionary is Russian, not English. Will tageta appear in that category? --Anatoli T. (обсудить/вклад) 07:51, 1 March 2016 (UTC)[reply]
Yes, Category:R:vep:UVVV with red link serves exactly the same purpose as Category:Russian redlinks. (the only difference is that the former category only looks for redlinks in {{R:vep:UVVV}}) I took the liberty of editing the template to move all entries from the former to the latter category. It should take some time before the system catches up. In the end, Category:R:vep:UVVV with red link should be empty and can be deleted. (unless someone disagrees, of course) --Daniel Carrero (talk) 08:21, 1 March 2016 (UTC)[reply]
Some entries in your category have only blue-linked Russian words, e.g. Gerogian აფთიაქი (aptiaki). Are you checking for ALL red-linked words there? --Anatoli T. (обсудить/вклад) 07:56, 1 March 2016 (UTC)[reply]
My mistake, but I already fixed it. The entry აფთიაქი has a blue link to аптека and thus should not be in Category:Russian redlinks. The problem is that at first the template was erroneously looking for an entry named апте́ка with an accent, which is a true redlink. When the system catches up, these entries with Russian blue links should disappear from Category:Russian redlinks. --Daniel Carrero (talk) 08:21, 1 March 2016 (UTC)[reply]
Thank you very much, Daniel. I think it's going to be very useful.--Anatoli T. (обсудить/вклад) 12:16, 1 March 2016 (UTC)[reply]
That's nice to know. :) --Daniel Carrero (talk) 16:51, 1 March 2016 (UTC)[reply]
This should be done by a bot, not by template. These templates are already too resource intensive, and adding further conditional statements which have to do database lookups is not going to help. - TheDaveRoss 12:28, 1 March 2016 (UTC)[reply]
Yes, this should be done by either a bot or by parsing dumps (which most people would equate with a bot anyway). --WikiTiki89 15:29, 1 March 2016 (UTC)[reply]
As I said above, I definitely know that checking the existence of a page is an expensive function (I'm using the Lua equivalent of {{#ifexist}}). But I really wanted to test this if it would work, so this is one reason why I created only a few categories (Category:Russian redlinks, Category:English redlinks, Category:Portuguese redlinks), I wanted to see if it would be okay and if anyone would object.
Actually, I found 1 problem: water was displaying the "The time allocated for running scripts has expired." error, so I fixed it with a kludge: I edited the affected templates ({{t}}, {{t+}}, {{l}} and {{m}}) to make them not search for redlinks in the entry water specifically. The kludge worked. Also, the entry a is fine without needing to be an special exception like that. Can we measure the impact of Module:redlink category in our entries? I don't know how people came up with the numbers at Wiktionary:Grease pit/2016/February#a: The time allocated for running scripts has expired.
If the impact of these new categories is really too much, I don't mind doing like @Wikitiki89 and @TheDaveRoss said: doing this by bot or by parsing dumps, rather than using categories. Although my idea of categorization has a minor advantage: assuming the impact on the entries is not that much, I already did most of the work for the categorization idea (coming up with the code that searches for redlinks) so it's easier to just use it than create the bot or parse the dumps. Also, the categories update automatically once people add new redlinks or create the entries for the redlinks. --Daniel Carrero (talk) 16:51, 1 March 2016 (UTC)[reply]
The numbers there are from the page source, they are near the bottom. They can be misleading, because they are single-pass tests rather than good benchmarks, they can vary greatly depending on the load and the caching. I am concerned about kluges, and I am not sure why these pages need to be real-time. If people are looking for lists of pages to work on they can easily see which of the remaining pages are actually red links. Bots/parses are updated at worst monthly, which seems like a fine timeline to me. - TheDaveRoss 17:10, 1 March 2016 (UTC)[reply]
Any improvements is welcome but Daniel has already provided tangible help and made a useful category. Apart from performance, a split by page language would be good too. Also, my original request was about blue-linked foreign words on the Russian pages. Making editors aware of red-linked words like Fuchtel, schipper, figlarz is perhaps of interest to editors of the appropriate languages.--Anatoli T. (обсудить/вклад) 21:07, 1 March 2016 (UTC)[reply]
I created categories for 99 languages in Category:Redlinks by language. Once others appear in Special:WantedCategories, I'll create them too. Again, let me know if the ifexist causes any problems. I was a bit worried at first because I thought it might cause any module errors or cause pages to load more slowly (in that case I would delete the new categories) but I didn't notice anything wrong happening in entries other than water (which I added as an exception, as I said above). --Daniel Carrero (talk) 18:59, 3 March 2016 (UTC)[reply]
The ifexist is causing a lot of errors at CAT:E; you should probably take it out. Benwing2 (talk) 22:50, 3 March 2016 (UTC)[reply]
True, there were almost 200 pages with some kind of error. I disabled the ifexist in all pages for now. I'm going to see if I can make it work without errors. --Daniel Carrero (talk) 02:14, 4 March 2016 (UTC)[reply]
Someone made a quickly-corrected error in the module several days ago which maxed out the edit queue, so there are still pages developing module errors from that edit. They would eventually go away when the instances of the correction edit emerge from the queue- except I'm constantly doing null edits to speed them along.
There are actually only three real "expensive function" errors now, and those are the result of CodeCat's temporary patch to allow both Appendix and Reconstruction to exist and be linked to by Module:links. Reverting the patch is unthinkable until we finish the move, so we're stuck with them for the time being (they're in appendices that have huge numbers of links to reconstructed forms).
Without having looked at the entries with module errors before you undid your edit, I can't be sure if there were additional errors caused specifically by your modification, but I would have thought they would have shown up by the last time I checked the category last night. Still, I don't think we should be doing any more ifexists than absolutely necessary, and right now is an especially bad time to push the limits. Chuck Entz (talk) 04:10, 4 March 2016 (UTC)[reply]
I see. At the very least I won't try to reenable the ifexists while we still have reconstruction pages in the appendix namespace, because of the patch you mentioned. --Daniel Carrero (talk) 04:23, 4 March 2016 (UTC)[reply]
Shouldn't these pages be called Category:Entries with redlinked English terms or something similar? They aren't categories of English redlinks, since that would be impossible. DTLHS (talk) 04:25, 4 March 2016 (UTC)[reply]
An entry like eyelash is going to have dozens of redlinks categories, (see the translations) so I'd settle for the shortest name possible. Also, think this way: these entries have English redlinks, hence they are categorized in Category:English redlinks. Like train is categorized in Category:English nouns, not Category:Entries with English noun senses. The entry train is not a noun, it contains a noun (and a verb). At least, I came up with that justification and I hope it makes sense. --Daniel Carrero (talk) 04:29, 4 March 2016 (UTC)[reply]

How should numbers be sorted on Wiktionary? edit

Per phabricator:T8948, it will eventually be possible to sort numerical page titles naturally (in numerical order) rather than lexigraphically (in strictly alphabetical order). We would like to know which type of sorting would be preferred on English Wiktionary. Should 911 come before or after 99 (assuming they were both in the same category)? Ryan Kaldari (WMF) (talk) 16:58, 1 March 2016 (UTC)[reply]

IMO definitely use the order: 1, 2, 3, ..., 8, 9, 10, 11, 12, ... 99, 100, 101, ..., 911.
The category Category:Portuguese words by number of syllables has subcategories properly sorted. --Daniel Carrero (talk) 17:02, 1 March 2016 (UTC)[reply]
(Note that this only works because the subcategories have custom sorting keys, thanks to {{poscatboiler}} – the actual logic is somewhere deep in Module:category tree, with the category names and corresponding sortkeys listed at Module:category tree/poscatboiler/data/words by number of syllables. Matma Rex (talk) 19:34, 1 March 2016 (UTC))[reply]
What about mixed numeric and alphabetic entry titles. How should those be sorted? Another complication is that really the sorting order logically depends on what the numbers mean in the entry title. 911 is a phone number and not actually the number "nine-hundred eleven", so really, it should come before 99. In order to maintain consistency, I would say our only choice is to stick with the order: 1, 10, 100, 101, 11, 12, 2, 3, 8, 9, 911, 99. --WikiTiki89 19:55, 1 March 2016 (UTC)[reply]
I disagree about 911 and think it should be between 910 and 912. It even has a Translingual number sense "the number nine hundred and eleven". At the very least, this should be the standard (I meant default) sorting. We can still use sortkeys for 911 to change that if we want.
Category:E numbers should be able to be sorted automatically too, this way: E101, E101a, E400, E620, E1000, E1001.
File names in Microsoft Windows are able to do that. If you sort files by name, this is the order they end up in. Incidentally, "A02" comes before "A2" in Windows, so we'd have: A1, A02, A2, A3, A4. --Daniel Carrero (talk) 20:08, 1 March 2016 (UTC)[reply]
Don't forget that the translingual section would not be sorted together with the English section. We could sort 911 one way in the phone number sense, and another way in the translingual sense. --WikiTiki89 20:26, 1 March 2016 (UTC)[reply]
@Wikitiki89 You can test out the numerical sorting at https://ssl.icu-project.org/icu-bin/collation.html. Just be sure to turn "numeric" on in the settings. Ryan Kaldari (WMF) (talk) 23:38, 4 March 2016 (UTC)[reply]
I agree with Daniel that the default sorting should be 1, 2, 3, ... 99, 100, ... 910, 911, 912. And 06 (if we don't apply any special sorting to it) should be before 6, I suppose? - -sche (discuss) 20:54, 1 March 2016 (UTC)[reply]

Consolidating minor edits into a single major edit in an entry edit

Tracked in Phabricator
Task T9904

User:Wikitiki89 proposed this in User_talk:KoreanQuoter#Long_series_of_edits this discussion. He said something like this:

Maybe the developers will someday release a grouping feature that would allow edits by the same user to be grouped in histories.

For example, I did a lot of minor edits in рука over the past several days. I think we can merge all the minor edits together into one. I don't know whether if this is a feasible idea, but I want to discuss about this. --KoreanQuoter (talk) 05:45, 2 March 2016 (UTC)[reply]

I have done the same thing to one entry once and feeling sorry for page-watchers I found a solution - I became more thoughtful. --Giorgi Eufshi (talk) 06:24, 2 March 2016 (UTC)[reply]
Does anyone know any devs we can ping to see if this is desirable or feasible? --WikiTiki89 15:16, 2 March 2016 (UTC)[reply]
@Ryan Kaldari (WMF) (who commented on this page a few sections up) is listed as the WMF's Engineering Manager; perhaps he can help or knows who to contact. It doesn't strike me as a high priority. If the edits were to the same snippet of the page (e.g. you changed foo bar baz to foo baz baz and then to foo foo baz), it could theoretically prevent someone who looked at the page while it said foo baz baz from being able to properly cite that version of the page, which is admittedly an edge case. - -sche (discuss) 22:31, 2 March 2016 (UTC)[reply]
I didn't mean merge the edits altogether, but just group them into an edit group that can be expanded to view individual edits. --WikiTiki89 22:34, 2 March 2016 (UTC)[reply]
Now this is even a better idea. --KoreanQuoter (talk) 02:14, 3 March 2016 (UTC)[reply]
I suppose it could be done in JavaScript as a gadget, very similar to the way multiple edits to a given page are collapsed in Recent Changes (at least the way I see them with the patrolling enhancements enabled). Chuck Entz (talk) 02:39, 3 March 2016 (UTC)[reply]
That wouldn't completely work, because it would only be able to do that after having loaded a given number of edits. So, if one user has been editing the same page a lot, you will only see one edit group per page. If it's done server-side, that won't be an issue. --WikiTiki89 15:41, 3 March 2016 (UTC)[reply]
There's an existing request for this: phabricator:T9904. I've linked to this discussion from there. Ryan Kaldari (WMF) (talk) 00:24, 5 March 2016 (UTC)[reply]

Word of the day edit

Discussion moved from WT:FB.

It's not the 12th of February. Donnanz (talk) 09:12, 2 March 2016 (UTC)[reply]

It's showing the word that is set at Wiktionary:Word of the day/March 2, but labelling it "February 12" (even if I clear my cache, and no matter if I'm logged in or logged out, and no matter what browser I use); how odd. - -sche (discuss) 09:43, 2 March 2016 (UTC)[reply]
I think I've fixed it (by editing "Wiktionary:Word of the day/March 2"). SemperBlotto (talk) 09:53, 2 March 2016 (UTC)[reply]
A tiny error like that! That's better, cheers. Donnanz (talk) 10:06, 2 March 2016 (UTC)[reply]
Whoops! — SMUconlaw (talk) 11:01, 2 March 2016 (UTC)[reply]
Thanks! - -sche (discuss) 22:17, 2 March 2016 (UTC)[reply]

Updating Index:Proto-Germanic edit

Somebody ought to update Index:Proto-Germanic to the new namespace of reconstruction. --Lo Ximiendo (talk) 11:53, 2 March 2016 (UTC)[reply]

Not just that one. All those ancient proto-language indices use really bad linking methods and are in desperate need of overhauling or deletion. —Aɴɢʀ (talk) 12:48, 2 March 2016 (UTC)[reply]

Category:French terms spelled with , edit

Could some edit {{head}} to remove this uninteresting and generally false category (a comma is not part of the spelling of any of the words in this category. As far as I know English doesn't use commas in spellings either). Renard Migrant (talk) 14:35, 2 March 2016 (UTC)[reply]

This is why I support an opt-in strategy for "interesting" characters, rather than an opt-out for "uninteresting" characters. --WikiTiki89 15:15, 2 March 2016 (UTC)[reply]
It's harder to notice and thus bail in new(-to-us) interesting characters if the categories are only generated once the characters are noticed in entries and bailed in to some central list of interesting characters. I suppose we could periodically search the list of all titles in the wiki used by each language and see which were interesting (does French occasionally use alpha, the way English does? is that interesting?), but that seems like a lot of work. OTOH, we might benefit from occasionally doing that regardless (checking what characters are used in entry titles) — maybe not on a per-language basis, but checking e.g. all languages whose only script in Latn, to see if any of them have entries with Chinese or Cyrillic characters — to catch instances of miscategorization. - -sche (discuss) 18:49, 2 March 2016 (UTC)[reply]
To expand upon this: the list of characters which are interesting is large and open-ended, whereas the list of characters which are uninteresting is small and closed. Is a French word spelled with alpha? I'm interested. With any Cyrillic or Chinese character? Wow, interesting! Hence, I think it'd be easier to list the uninteresting characters and "opt them out", rather than trying to "opt in" all interesting characters. - -sche (discuss) 22:17, 2 March 2016 (UTC)[reply]
Well opting in can include character ranges, so we don't have to list every Chinese character individually. But I disagree that the list of uninteresting characters is small and closed. There are a great deal of uninteresting punctuation marks and other such things in Unicode. Another thing to consider is is it really interesting if an English word is spelled with an alpha? Maybe if it were used in the middle of a word, it would be interesting, but if it is used simply as an alpha, like α-ray, then I don't find that very interesting. I would even say that something has to occur commonly enough for it to really be interesting. Otherwise, it's just some random obscure symbol no one cares about and would end up alone in the category anyway. --WikiTiki89 22:23, 2 March 2016 (UTC)[reply]
Spaces, commas, semicolons, colons, periods, apostrophes, quotation marks, maybe exclamation marks (or perhaps those are interesting), parentheses, maybe slashes (or again maybe those are interesting)... it's a closed class, and small compared to the class of characters I'd find interesting. I wouldn't mind having e.g. a single Category:French terms spelled with Greek letters rather than separate categories for each letter, though. - -sche (discuss) 22:54, 3 March 2016 (UTC)[reply]

Template:reconstructed edit

Now that reconstructions have their own namespace, and everything in that namespace is a reconstruction, it seems we could do away with this template and have its text displayed on all reconstructions automatically (probably using a Mediawiki page). - -sche (discuss) 22:42, 3 March 2016 (UTC)[reply]

I agree. But not everything has been moved over yet. --WikiTiki89 22:44, 3 March 2016 (UTC)[reply]
Also, the template assists in moving the pages over, so it should certainly be kept still. I wonder what you had in mind, -sche? —CodeCat 23:12, 3 March 2016 (UTC)[reply]
If it's useful in the short term, keep it in the short term, but in the long term there's no reason to type it into the wikitext of every page. A bot could remove it from all pages in the Reconstruction namespace, and its text could instead be displayed automatically on all pages in the namespace, probably via a Mediawiki page. - -sche (discuss) 01:05, 4 March 2016 (UTC)[reply]
Yes, ok, but how are you going to display the text automatically? —CodeCat 01:17, 4 March 2016 (UTC)[reply]
@CodeCat: I was hoping the same way that we have Modules automatically transclude the documentation page. How do we do that? --WikiTiki89 20:39, 4 March 2016 (UTC)[reply]
It's part of the Scribunto extension: [1]. So we can't use it for other namespaces. —CodeCat 20:49, 4 March 2016 (UTC)[reply]
We have a Mediawiki page to display the "news for editors" link on all pages, and MediaWiki:Editnotice-10 displays certain text in the edit windows of all templates. It should be possible to use a similar page to display a notice only on the Reconstruction namespace. - -sche (discuss) 22:45, 4 March 2016 (UTC)[reply]
Actually, I decided that I don’t want a new namespace anymore. Can you put them all back? --Romanophile ♞ (contributions) 01:10, 4 March 2016 (UTC)[reply]
@Romanophile: I sincerely hope you are joking. —JohnC5 02:02, 4 March 2016 (UTC)[reply]
@JohnC5: sic est; joco aliquando. --Romanophile ♞ (contributions) 02:12, 4 March 2016 (UTC)[reply]

Template:glink or similar to create a link to a glossary entry edit

I'm thinking of creating a template that links to a glossary entry, so I could say e.g. {{glink|iotation}} and it expands to [[Appendix:Glossary#iotation|iotation]]. What do people think? This would hopefully encourage linking to the glossary rather than just inserting a raw link, e.g. [[iotation]]. The name should be short enough so that it will actually be used instead of just writing a raw link. Perhaps it should be even shorter, e.g. {{gl|iotation}}, although that might preempt other uses of {{gl}}, e.g. as a shortcut for {{gloss}}. Another possibility is {{gln}} or maybe {{gli}}; {{gln}} has the advantage that ln is already a common Unix command that creates a link. Benwing2 (talk) 04:29, 4 March 2016 (UTC)[reply]

List of language codes that can be used with "etyl" and "m" edit

Can a complete list of the language codes that {{etyl}} and {{m}} accept be set out on the documentation pages of those templates? I can't seem to find such lists anywhere, plus it's rather vexing that some codes accepted by {{etyl}} are not accepted by {{m}}. — SMUconlaw (talk) 11:38, 4 March 2016 (UTC)[reply]

WT:List of languages and WT:List of languages/special list all languages accepted by those two templates (as well as by {{l}}, {{inh}}, and {{der}}). The ones under WT:List of languages/special#Etymology-only languages can be used by {{etyl}}, {{inh}}, and {{der}} but not by {{m}} and {{l}}. —Aɴɢʀ (talk) 12:51, 4 March 2016 (UTC)[reply]
Thanks. So which language codes can be used with {{m}}? — SMUconlaw (talk) 15:12, 4 March 2016 (UTC)[reply]
All the ones at WT:LOL and WT:LOLS can be used by all templates that take a language code, including {{m}}. --WikiTiki89 15:30, 4 March 2016 (UTC)[reply]
Ah, I see. Thanks. — SMUconlaw (talk) 15:38, 4 March 2016 (UTC)[reply]
No, the etymology-only languages can't be used by {{m}} and {{l}}, as I said above. If you write {{m|xno|blah}} (xno being an etymology-only language), you get a module error. —Aɴɢʀ (talk) 16:25, 4 March 2016 (UTC)[reply]
Oh, whoops. I didn't realize that the etymology-only codes were also at WT:LOLS. --WikiTiki89 16:52, 4 March 2016 (UTC)[reply]
I think they probably should be on their own page, just to avoid confusion. —CodeCat 17:04, 4 March 2016 (UTC)[reply]

Template:compound edit

Is there no abbreviation of this template that would save a wee bit of typing? I would suggest comp or cpd. Donnanz (talk) 13:08, 4 March 2016 (UTC)[reply]

You can use {{affix}}, which is fewer letters and, more importantly, doesn't need lang= written out. Compare:
{{compound|dog|house|lang=en}}
{{affix|en|dog|house}}
That saves you 8 keystrokes. —Aɴɢʀ (talk) 14:48, 4 March 2016 (UTC)[reply]
You can do {{compound|en|dog|house}} too, which I'm doing now. But {{cpd|en|dog|house}} would be even shorter than using "affix". Anyway, I'll try it. I often type "compound" wrongly (I did it just now!), and have to correct it. Donnanz (talk) 15:03, 4 March 2016 (UTC)[reply]
The name {{affix}} used in place of {{compound}} for dog + house is a misnomer as neither element is a bound morpheme. So anyone relying on an entry using this to model their entry would be confused if not misled about the relationship between our templates and conventional linguistic terminology. DCDuring TALK 16:37, 4 March 2016 (UTC)[reply]
Affix does work; I just tried it with medeier, and it registers as a compound entry. But you're quite right, it is a misnomer, and I would still prefer {{temp|cpd}}. Donnanz (talk) 16:44, 4 March 2016 (UTC)[reply]
When {{affix}} was created, it didn't have this capability. It was added only later. So that explains the bad name. —CodeCat 17:05, 4 March 2016 (UTC)[reply]
I think {{affix}} was originally introduced so words with a prefix or a suffix (or both) could be dissected, where {{confix}} doesn't work. Donnanz (talk) 17:12, 4 March 2016 (UTC)[reply]
How is whoever made the addition to the template going to explain that to every confused user? The user-confusion argument is sometimes risen to the highest priority, but sometimes it is whipped and thrown away. Not cool. --Dixtosa (talk) 18:22, 4 March 2016 (UTC)[reply]
A brief open letter to all people who are concerned about saving 8 keystrokes: Get AutoHotKey. It is free (all the kinds) software which allows you to create all kinds of scripts and macros. For instance, you can create a script which will detect when you type "{cpd|" and replace it with "{{compound|". You can restrict the scripts to only function when editing a Wiktionary page in Chrome (or whatever). You can also create hotkeys, for instance if you frequently speedy delete with the deletion reason "Nonsense/Gibberish" and not have to use the mouse at all. Seriously, check it out. - TheDaveRoss 17:21, 4 March 2016 (UTC)[reply]
I completely agree with you. The constant harping about keystrokes, as if they are the final goal of Wiktionary, is really annoying. —CodeCat 17:24, 4 March 2016 (UTC)[reply]
In terms of my bot replacements, replacing {{cx}} with {{context}} doesn't make it harder for anyone to type {{cx}}. No-one's ever explained this to me, the whole point of having a bot do it is so human users don't have to. Renard Migrant (talk) 17:38, 4 March 2016 (UTC)[reply]
It's not so much about keystrokes, it's about readability. --WikiTiki89 18:01, 4 March 2016 (UTC)[reply]
Not to mention convenience. Not all of us want to use hot keys either. So why were {{m}} (replacing {{term}}) and {{l}} (instead of {{link}}) introduced? For convenience surely. And I've just discovered {{lb}}. Donnanz (talk) 18:28, 4 March 2016 (UTC)[reply]
Because {{m}} is prone to be used a lot in a single section (like in Etymology) and that's where shorter means more readable (just imagine long chains of {{mention}}'s). compound is expected to used once on the other hand. As for, {{lb}} I think it 3 letters shouldn't matter on a single line. Dunno why it is preferred. --Dixtosa (talk) 18:36, 4 March 2016 (UTC)[reply]
I think all users know {{etyl}} by now, so it that a real problem? Donnanz (talk) 19:53, 4 March 2016 (UTC)[reply]
Users don't know any templates. Editors do. Did DCDuring forget about our real audience here? —CodeCat 19:57, 4 March 2016 (UTC)[reply]
An important distinction. Users are the ones who get hit by module errors that are aimed at editors. Are you sure you haven't done the same? Chuck Entz (talk) 20:24, 4 March 2016 (UTC)[reply]
I meant registered users who are editors. Anyone who creates or edits an entry would know, not passive users. Donnanz (talk) 20:06, 4 March 2016 (UTC)[reply]
A user who is editing is an editor. An editor needs to learn the templates. A user who doesn't edit is only a reader and shouldn't care about templates. --WikiTiki89 20:09, 4 March 2016 (UTC)[reply]
The harder it is to learn the templates, the fewer people who will make the transition from user to editor. We have never had a month in which more than 100 people made more than 100 edits each, we should be trying to make it easier to contribute. - TheDaveRoss 20:15, 4 March 2016 (UTC)[reply]
And what makes you think that this is the reason? The templates you've mentioned so far are easy to learn. It's conjugation templates and things like that that are difficult, and that is because of the complexity of the subject and not necessarily because of poor template design. --WikiTiki89 20:19, 4 March 2016 (UTC)[reply]
A new template can be created, and the old one retained for those who aren't up to speed, something I'm often guilty of. Donnanz (talk) 20:21, 4 March 2016 (UTC)[reply]
@CodeCat The real audience is those who don't seem to notice that we need a massive injection of new contributors to improve entry quality, especially for, but not limited to, English entries, the core product we're selling. IMO all changes should be viewed from that perspective. Technical changes that don't address the core issue are just rearranging deck chairs.
Could anyone list the technical changes over the last three that ease the processes of reviewing existing entries to find defective definitions and correct them and to find missing definitions and add them? DCDuring TALK 00:19, 5 March 2016 (UTC)[reply]

Redlinks categories edit

Yesterday, I was happily working my way through Category:Italian redlinks, adding missing terms, and making various types of correction. I finished the "A"s. Today, the category is empty. The same seems to be the case for all similar categories. There is one exception:- Category:Russian redlinks still includes many Veps words. Any ideas? SemperBlotto (talk) 06:11, 5 March 2016 (UTC)[reply]

@SemperBlotto: I can explain. I populated Category:Italian redlinks, but the code that checked for redlinks caused an error of "too many expensive functions" in almost 200 entries, so I emptied the redlink categories. If there's any nonempty redlink category, it's because the system didn't catch up to these categories yet.
I intend to try and populate the redlinks categories again later, if I can possibly do it without causing any errors. I should definitely wait after all the reconstructed terms appendices are moved to the Reconstruction: namespace, because we're currently also using an expensive function to check for reconstructed terms in the Appendix: namespace.
Related discussion: #Auto-add words with etymologies to WT:WE (wanted entries) by language. --Daniel Carrero (talk) 07:06, 5 March 2016 (UTC)[reply]
Yes please. It was really useful. SemperBlotto (talk) 07:58, 5 March 2016 (UTC)[reply]
p.s. Those Veps ones don't go away even after a null edit.
Ok, thanks for saying it was useful. I forgot about Category:Russian redlinks. This category is still being populated by the reference template {{R:vep:UVVV}}. But, admittedly, that's redundant. The template links to Russian words using {{l}} so the Russian redlinks would get categorized anyway. --Daniel Carrero (talk) 08:52, 5 March 2016 (UTC)[reply]
I really don't see why we would want our own processes to be resource hogs on a regular basis. DCDuring TALK 12:31, 5 March 2016 (UTC)[reply]
If someone creates the full list of redlinks in all languages from the XML dump, then I suppose we won't need the categories.
I'm curious: is it verifiable that the ifexist is a resource hog? (especially when used repeatedly to check for redlinks in all pages) I know it's marked as an "expensive function", but using it didn't make the site slower to me or something like that. Does it flood the job queue or something?
Also, I'm thinking of a compromise. We can enable the redlink categories again, (after the Reconstruction: pages are done being moved to the new namespace) and if the site gets slower or something, we can disable the categories, but not before making a separate list of all members of these categories. It would be the same as creating a XML dump, but hopefully simpler/easier. --Daniel Carrero (talk) 02:03, 6 March 2016 (UTC)[reply]
Please recall what you are trying to do is a larger and more complex version of what is offered at Special:WantedPages, which is only run periodically. Why do you think MW only runs it periodically? Just to make life harder for us? Do you think it just might be because it's a hog?
I don't give a rat's ass about a "compromise". I'd like to know what substantial advantage there is to having this real-time category instead of periodic updates from the dumps. If there is one, then we can allow you, under adult supervision, to treat Wiktionary as a sandbox. Otherwise, you are once more going off in the direction of just amusing yourself, to put it politely. DCDuring TALK 02:46, 6 March 2016 (UTC)[reply]
Some people liked the idea and I'm ready to take it down if needed. (I took it down once) As I said before, it does not have to be real-time (in my opinion), it's just that I took the time to create the code that populates categories and I'm not really willing to try parsing dumps (I have 0 experience doing that, and this task in particular sounds difficult), but I welcome anyone to try and create the lists from dumps if they want. Again, if we had dumps we wouldn't need categories. To be clear: I'm totally for creating dumps, as long as someone else does it. You mentioned Special:WantedPages, but it is kind of a mess; the redlink categories are organized by languages. Also, you're being dismissive in the last 2 sentences. ("to put it politely") Does anyone else basically thinks I'm being an idiot for presenting this idea after something related was requested in #Auto-add words with etymologies to WT:WE (wanted entries) by language? Geez, even if I'm experimenting something new, give me credit for asking for feedback and discussing the new ideas. --Daniel Carrero (talk) 03:29, 6 March 2016 (UTC)[reply]
Don't get me started. Special:WantedPages is cluttered with the detritus of many an extravagant use of "ifexist", of monster lists from user pages, and of redlinks created in support of category pages, which last you may know something about. If it were not so cluttered, I wouldn't have needed the {{taxlink}} infrastructure.
I'd hate to think that your choice of approaches to solving problems was as limited by the range of tools you know as mine is.
I thought for sure that a person of your talents would know how to and would enjoy downloading and processing the dump in the virtually infinite ways possible. It is so easy that even an old fart like me can do it (with help). All it takes is a few minutes time for downloading, an unzipping tool, a language like Perl or Python that supports and extends regular expressions, and the ability to use these. What is remarkable to me is that a useful list can be produced in less than a minute on one's own PC. Personally I find that the most useful. motivating lists are fairly selective "short" ones (hundreds of items rather than tens of thousands). DCDuring TALK 14:17, 6 March 2016 (UTC)[reply]
Could you also cast your energy to eradicate these categories too?--Dixtosa (talk) 14:44, 6 March 2016 (UTC)[reply]
Well, Category:German verbs with red links in their conjugation tables seems to have lots of false positives - the verbs do not have red links in their conjugation tables. SemperBlotto (talk) 15:01, 6 March 2016 (UTC)[reply]
It only takes one. On such tables it is easy to miss a single black-displayed form on such tables. DCDuring TALK 15:09, 6 March 2016 (UTC)[reply]
Can the colour within tables be changed to red? It would make unentered inflections more obvious; I come across this problem elsewhere. Donnanz (talk) 15:05, 7 March 2016 (UTC)[reply]
I think that red was changed to black because was deemed distracting or too likely to lead to bad entries. I'm guessing it would be possible to have a preference that restored those redlinks by default for a user. But I assume adding lemmas are still a priority in most languages and additional definitions and quality improvement are in other languages. DCDuring TALK 15:39, 7 March 2016 (UTC)[reply]
"Too likely to lead to bad entries" if in red? I think it is more likely the entries for inflections will be completely ignored if there is no distinction in colours between inflection "done" and inflection "not done". Mind you it may suit some editors if the unentered inflections are not highlighted, who knows? Donnanz (talk) 16:27, 7 March 2016 (UTC)[reply]
One can hold the cursor over a black link and determine whether the linked page is empty or not from the hover box message. DCDuring TALK 17:16, 7 March 2016 (UTC)[reply]
Category:Burmese redlinks appears to be empty, but [[half]] has it listed at the bottom. Categories aren't much use if they don't actually show you the words that belong to them. —Aɴɢʀ (talk) 19:43, 7 March 2016 (UTC)[reply]
It isn't empty anymore, but [[half]] still isn't in it. Weird. —Aɴɢʀ (talk) 19:56, 7 March 2016 (UTC)[reply]
@Angr: When you saw any category like Category:Burmese redlinks with terms appearing or disappearing, it was because I was testing Module:redlink category and Template:redlink category to see if it was possible to populate all redlinks categories at once. I was unable to populate the redlinks categories for all languages because the code was generating too many module errors, but apparently I was able to populate the categories for a few languages without generating any errors. --Daniel Carrero (talk) 15:11, 9 March 2016 (UTC)[reply]
We have to stop doing this. It is creating too many module errors and should simply be done by bot. --WikiTiki89 20:00, 7 March 2016 (UTC)[reply]
I was unable to populate the redlinks categories for all languages because the code was generating too many module errors, but apparently I was able to populate the categories for a few languages without generating any errors. Also, I don't mind if someone does this by bot or whatever. --Daniel Carrero (talk) 15:11, 9 March 2016 (UTC)[reply]
It wasn't just that; some categories were showing pages that didn't have any relevant redlinks in them at all. They just seemed very unreliable and I'm not sorry they've been deleted. What we need a bot (or rather, lots of bots) to do is to actually keep the Index: namespace up to date with blue, red, and orange links for all languages (or at least all that there are people interested in editing). —Aɴɢʀ (talk) 15:20, 9 March 2016 (UTC)[reply]
As I said in User talk:Daniel Carrero#Redlinks categories, at some point I made a mistake that caused entries without redlinks to be wrongly categorized in the redlinks categories, but that was quickly fixed. --Daniel Carrero (talk) 15:43, 9 March 2016 (UTC)[reply]

Latvian should map diacritics? edit

Cf. Latvian raĩdît. I don't know Latvian well at all but I think this entry should map to raidīt. Benwing2 (talk) 13:27, 7 March 2016 (UTC)[reply]

neger edit

I'm requesting to unblock the entry neger (cf. "You do not have permission to edit this page, for the following reason: (no reason given)"). Looking at the version history, there is the comment "persistent vandalism in the form of undiscussed drive-by tampering with usage notes, labels, etc" but that's obviously incorrect. -Random187056 (talk) 13:58, 8 March 2016 (UTC)[reply]

I'm disinclined to unblock it. It's only semiprotected, meaning once you're autoconfirmed you'll be able to edit it. As I understand it, if you make several good edits over the course of the next three days or so, you'll be autoconfirmed automatically. (That's redundant, but oh well.) —Aɴɢʀ (talk) 15:24, 8 March 2016 (UTC)[reply]
As Smurray commented the last time you brought this (or Neger) up, what a hill to die on. - -sche (discuss) 22:08, 8 March 2016 (UTC)[reply]
That's another word and irrelevant for this one. The block reason here obviously is incorrect and thus the entry shouldn't blocked at all. -Random187056 (talk) 01:04, 9 March 2016 (UTC)[reply]

Navbox and navbox edit

Can someone combine {{navbox}} and {{Navbox}}? I'm not sure why we have both of them. — SMUconlaw (talk) 15:47, 8 March 2016 (UTC)[reply]

Latin headword line templates not linking correctly edit

{{la-noun}} and {{la-adj-1&2}} aren't correctly linking to reconstructed pages. Examples:

This only happens with nouns and adjectives (as far as I know). It works just fine with verbs like *toccō. I've gone over Module:la-headword a few times, but I can't find anything that could cause this. KarikaSlayer (talk) 17:07, 8 March 2016 (UTC)[reply]

Fixed. —CodeCat 17:16, 8 March 2016 (UTC)[reply]
@CodeCat could you also cleanup mod:de-headword according to the new logic? I doesn't have the reconstructed business, but it does still prevent categories from being inserted except in the mainspace. You seemed to have removed that behavior from mod:la-headword. —JohnC5 17:29, 8 March 2016 (UTC)[reply]
Done. For some reason, the module overrides the standard namespace filtering of Module:headword. I've removed that now. —CodeCat 17:35, 8 March 2016 (UTC)[reply]

Edit protected Module:languages/data3/t edit

Hi! Could you add transliteration module entry for Altai (alt+atv) AND Shor (cjs) at Module:languages/data3/t please? Thank you! --146.111.30.193 19:36, 10 March 2016 (UTC)[reply]

I think Module:alt-translit and Module:atv-translit should be combined into one module, since they are exactly the same. Also, can you show some testcases? --WikiTiki89 19:40, 10 March 2016 (UTC)[reply]
Also, the messages "WARNING: misuse of Latin ö in original text!" should be made into categories instead. --WikiTiki89 19:42, 10 March 2016 (UTC)[reply]
Transliteration modules shouldn't return categories as part of the text. —CodeCat 19:45, 10 March 2016 (UTC)[reply]
But why not? It's better than an outright textual error message in any case. --WikiTiki89 19:46, 10 March 2016 (UTC)[reply]
I agree. I want to make the warning red. Someone just made such a mistake in [2], which leads to wrong transliteration so I guess it's common. --146.111.30.193 19:55, 10 March 2016 (UTC)[reply]
In Wikimedia Incubator, almost every umlaut o and u, and Cyrillic j is misreplaced. --146.111.30.193 20:03, 10 March 2016 (UTC)[reply]
But is it possible to combine them? There's no single ISO code for Altai. --146.111.30.193 19:56, 10 March 2016 (UTC)[reply]
Modules don't have to be named by the ISO code, that's just a convention. You can call it Module:Altai-translit. Making the warning red will help prevent new instances of it, but to find all the old ones, a category would be easier. --WikiTiki89 20:00, 10 March 2016 (UTC)[reply]
Thank you! Could you please merge them? I don't have the right to move pages. --146.111.30.193 20:03, 10 March 2016 (UTC)[reply]
  Done --WikiTiki89 20:20, 10 March 2016 (UTC)[reply]
@Wikitiki89:Changed to category references. Can you please add an entry in Module:languages/data3/t? --146.111.30.193 20:35, 10 March 2016 (UTC)[reply]
  • Also, could anyone unprotect Module:kjh-translit? The vandalism was done half years ago and I don't think s/he's still here. It's important to switch the two i in Khakas language because Khakas is like Modern English, suffered from an extensive vowel shift where i and ee are switched. --146.111.30.193 20:03, 10 March 2016 (UTC)[reply]
    Are you sure that phonological peculiarity needs to be reflected in the transliteration? --WikiTiki89 20:20, 10 March 2016 (UTC)[reply]
    When it's systematic, yes. Imagine if İnglísh ís wrítten thís way accordíng to the current schime... Also imagine when you are comparing several languages for a certain Reconstruction/... article and you will have to keep several trivial phonological rules in mind... isn't that annoying? Why not let the machine do every tedious job and use our human mind to think about more advanced comparisons? Of course, again, this can only be done when the phonological rule is systematic. --146.111.30.193 20:32, 10 March 2016 (UTC)[reply]
    That's not what transliterations are for. --WikiTiki89 20:41, 10 March 2016 (UTC)[reply]
    But that is exactly what people do for English. Double standard should not be applied to Khakas. --146.111.30.193 20:43, 10 March 2016 (UTC)[reply]
    We do it for English because it is an accepted practice. For Khakas, we should use the accepted practice for transliteration. --WikiTiki89 20:46, 10 March 2016 (UTC)[reply]
    @Wikitiki89: Unfortunately, there's no accepted practice for the transliteration of Khakas. The Russian dialect of Khakas follows several ISO9 like transliterations and the Manchurian dialect of Khakas follows several other transliterations. The transliteration we have write now is based on Anatolian which is neither used by Khakas people in Russia nor by Khakas people in Manchuria. The assignment of í and i is simply ad hoc. And this is exactly one of the reason why I don't do the same thing to Volga Tatar. --146.111.30.193 20:53, 10 March 2016 (UTC)[reply]
    People transliterate the word “English” with a character with a phonetic value of /i/? Such a system is untenable given the wide variation in English spelling. We should not do something of that nature. —JohnC5 20:51, 10 March 2016 (UTC)[reply]
    I agree. And that's exactly the reason why we shouldn't transliterate Khakas with a i-character for the phonetic value of /i/. The way English people read Middle English is exactly the way Khakas people read Yenisian Old Turkic (Древнекыргызский язык, a.k.a. енисейско-кыргызский язык). The transliteration system of both should approximately match, just like the way how the spelling of Modern English and Middle English approximately match. --146.111.30.193 21:03, 10 March 2016 (UTC)[reply]
    You misapprehend my meaning. We should not allow phonological changes to affect transliteration. That's why we distinguish pronunciation from transliteration in the first place. —JohnC5 20:59, 10 March 2016 (UTC)[reply]
    Exactly. Then how can we allow the phonological change from Old Yenisian Turkic /e/ to Modern Khakas /i/ to affect its spelling from ä/e to i? My proposed transliteration - translit it with "ë", would match it with Yenisian Kyrgyz transliteration approximately. --146.111.30.193 21:03, 10 March 2016 (UTC)[reply]
    @JohnC5: To clarify what the anon is saying: Khakas went through a phonetic shift, but their modern spelling system is phonetic. The anon wants our transliteration to be etymological rather than phonetic. This would be completely absurd. --WikiTiki89 21:15, 10 March 2016 (UTC)[reply]
    Transliteration should reflect the characters written. —CodeCat 21:17, 10 March 2016 (UTC)[reply]
    What do you mean by reflecting the characters written? Why does the i, í system more reflecting the characters и, і than ë, i does? I don't see how it better reflects them by assigning и to i while і to í. --146.111.30.193 21:20, 10 March 2016 (UTC)[reply]
    I didn't say that. I just mean that the characters that are written should be reflected in the transliteration. So if the term contains the same letter twice, but it is pronounced differently in those two occasions, it should be transliterated as the same Latin letter twice regardless. Which Latin letters to choose for transliterating which Khakas letters is a separate issue. Which phonemes do и and і normally represent? —CodeCat 21:27, 10 March 2016 (UTC)[reply]
    Get it. You meant that the transliteration should be approximately one-to-one, with the exception of both щ and шч can be transliterated into same characters set. I agree with you. But the one I proposed meets your requirement. @CodeCat: (added after your comment) In Khakas, и,і,э are three different characters, and under whatever transliteration, mine or the original, they are still three different characters (not four, not two). However, I'd like to point out a small flaw: under whatever Cyrillic transliteration of Turkic languages, "е" in different position are transcribed differently (except for that of Sakha language). --146.111.30.193 21:31, 10 March 2016 (UTC)[reply]
    Does ë represent the phoneme /e/ or similar? Can you please answer? —CodeCat 21:32, 10 March 2016 (UTC)[reply]
    Under my proposal, in whatever position, ë represents the phoneme /i/, i.e. as 'ee' in English word 'beep'. --146.111.30.193 21:39, 10 March 2016 (UTC)[reply]
    That makes no sense. /i/ should be transliterated as i. —CodeCat 21:40, 10 March 2016 (UTC)[reply]
    So can you please tell me why /i/ should be transliterated as i while /ɪ/ shouldn't be? If transliterate /i/ to something other than i makes no sense, how can translating /ɪ/ to something other than i make any sense? --146.111.30.193 21:43, 10 March 2016 (UTC) --146.111.30.193 21:43, 10 March 2016 (UTC)[reply]
    Because i is the same as the IPA phonetic symbol /i/. —CodeCat 21:45, 10 March 2016 (UTC)[reply]
    Are you just telling me that when transliterate a Khakas article with smallcaps, transliterating /ɪ/ to something other than i doesn't make any sense? And the reason why that makes no sense is simply because i is same as IPA symbol /ɪ/. --146.111.30.193 21:48, 10 March 2016 (UTC)[reply]
    No. In any case, it appears that the pronunciation of и and і is exactly the same as in Ukrainian: и is /ɪ/ while і is /i/. This is my guess, anyway, based on your lack of an answer to my question above. So I propose that we transliterate them the same as in Ukrainian too: и > y, і > i. —CodeCat 21:51, 10 March 2016 (UTC)[reply]
    Because that's the custom for Turkic languages. In any case, I consider the matter closed with my proposal. —CodeCat 21:58, 10 March 2016 (UTC)[reply]
    • Wait. You didn't get it. In Ukrainian и is /ɪ/ while і is /i/, here і is /ɪ/ while и is /i/. --146.111.30.193 21:59, 10 March 2016 (UTC)[reply]
      And you're again applying double standard: apply Turkish standard (which you called "Turkic standard") to consonants but Slavic standard to vowels. --146.111.30.193 22:01, 10 March 2016 (UTC)[reply]
      Why didn't you say so before, then? And how is /ɪ/ normally transliterated in Turkic languages? —CodeCat 22:02, 10 March 2016 (UTC)[reply]
      • It's simply normally transliterated as i. See Uyghur Latin alphabet. I didn't notice your subtle mistake as I was not familiar with Ukrainian orthography (it's pretty weird to me). --146.111.30.193 22:05, 10 March 2016 (UTC)[reply]
      • Believe me. I am not really fond of obscure characters. Whenever there is a better choice I am very happy to use it. I have compared a lot of Turkic words and checked a book "Khan-Mirgen" written in Cyrillic. If the vowel shift is not systematic I wouldn't apply it. Everything I proposed are very close to academic transliteration of Old Turkic which is distinct from the Anatolian Turkish tradition, which is exactly the reason y'all felt weird. And that's where Ä, Č, Š come from. --146.111.30.193 22:15, 10 March 2016 (UTC)[reply]
    @Wikitiki89 I'd say: Khakas went through a phonetic shift, and their have a number of modern transliteration system. The one used by Wiktionary is not anyone of those established systems, and is phonetic. I therefore request instead of using a unestablished ad hoc transliteration, why not apply an etymological one? Does this sound absurd? --146.111.30.193 21:27, 10 March 2016 (UTC)[reply]
    Yes, that sounds absurd. --WikiTiki89 21:33, 10 March 2016 (UTC)[reply]
    @JohnC5: Do you also think that sounds absurd? What do you think of the system used in Starostin's dictionary then? --129.236.208.216 00:23, 12 March 2016 (UTC)[reply]
Why don't we just use the old Khakas Latin alphabet for transliterations? We should do the same for Altai, since I think this anon used the same absurd scheme there. --WikiTiki89 21:59, 10 March 2016 (UTC)[reply]
Did you mean the Uniform Turkic Alphabet by Soviet Union which is not the Uniform Turkic Alphabet introduced in Wikipedia? Then we are going to use a lot of Ь, Ƣ, Ə and Ꞑ. --146.111.30.193 22:03, 10 March 2016 (UTC)[reply]
I meant the one given at w:Khakas language#Orthography. And so what if we use those characters? --WikiTiki89 22:06, 10 March 2016 (UTC)[reply]
That one is Uniform Turkic Alphabet. ЬƢƏꞐ. Well, I agree, that the Uniform Turkic Alphabet was established, nontheless not a lot of people know it. If you are going to applying UTA to all Turkic language including Kazakh and Kyrgyz, I agree to substitute my proposal with UTA. However if such change is only made to Khakas I don't quite agree, as it brings some confusion when comparing Kyrgyz with Khakas. --146.111.30.193 22:08, 10 March 2016 (UTC)[reply]

I propose to use the Khakas transliteration system adopted in Template:R:tut-pro:SDM, namely и = i, і = ĭ. Thus, Khakas изір- (izìr-, “to get drunk”) would be izĭr-. See here. Or we can adopt the system shown in the second column here. In any case, I don't like anon's proposal to reconstruct phonology in the transliteration. --Vahag (talk) 08:32, 11 March 2016 (UTC)[reply]

@Vahagn Petrosyan: Sounds like either of those would be good. What about Altai? --WikiTiki89 15:55, 11 March 2016 (UTC)[reply]
It too can use either the system of the Etymological Dictionary of the Altaic Languages or KNAB's system in column 2. --Vahag (talk) 16:51, 11 March 2016 (UTC)[reply]
Thank you, @Vahagn Petrosyan:! You light up the correct direction of our discussion. I agree with applying the transliteration in Template:R:tut-pro:SDM to every Turkic language. However, Template:R:tut-pro:SDM doesn't use "ĭ" at all, nor does it use any system similar to the website you provided. In fact, Template:R:tut-pro:SDM's system is somewhat similar to the system I proposed. Below is what I found in that dictionary:
  • Khak. ajn-ɨt-
  • Khak. aɣaja, aɣajaŋ
  • Khak. āɣɨrin
  • Khak. aɣnɨχ
  • Khak. ūra-
  • Khak. apsax, apčax
  • Khak. paǯa
As can be seen Starostin's dictionary also follows conventional Altaic transliterations basically, although ɣ is used instead of γ, ǯ is used instead of ǰ, etc. Although my proposal is even closer to conventional Altaic transliterations using ä, ǰ, č, etc., Template:R:tut-pro:SDM looks scientific enough to me. --129.236.208.216 00:14, 12 March 2016 (UTC)[reply]
  • Applying KNAB romanization, however, is not quite a good idea. The KNAB romanization is mainly for geographic transcription, as can be seen in the KNAB romanization of Uyghur (whose loose form/transcription is often used in geographic name transcription while strict form/transliteration is more often quoted by KNAB), KNAB standards are used almost exclusively for geographic reasons. Unless KNAB become the standard for Wiktionary for every language, I do not suggest to use it. --129.236.208.216 00:56, 12 March 2016 (UTC)[reply]
  • @Vahagn Petrosyan: Also needed to be mentioned is I've never tried to reconstruct phonology in transliteration. In whatever Turkic language /ɪ/ should be transliterated as the major i sound in the destination alphabet (in our case, Roman). The problem is in many Turkic languages, such as in Uyghur, [i] is homophoneme with [ɪ], i.e. /i/=/ɪ/. So it seems as if [i] should be transliterated as i, which is not the case. The definite Khakassian vowel shift is /e/->[i], which results in the failure of the relation /i/=/ɪ/. So /ɪ/->i should be kept while /i/ should be assigned with some other letter in our transliteration.
  • The original writer of the current transliteration is an Anatolian native speaker, whose homeland is far away from the heartland of Turkic world, and might not have a very deep understanding of Turkic phonology. If you pronounce a [i] to an native Uyghur speaker, most likely (might depend on dialect) s/he will think it to be a consonant [j] and correct your pronunciation. If you'd love to, you can ping the original writter to ask whether he agrees to transliterate /ɪ/ as i while /i/ as something else.
  • What I requested, to use an English-like (rather than the current İnglísh-like) transliteration, is totally natural in both Khakas and English, and has nothing to do with phonologial reconstruction. Can you say our current English alphabet is a phonological reconstruction? --129.236.208.216 01:39, 12 March 2016 (UTC)[reply]
The Etymological Dictionary of the Altaic Languages (EDAL) does use "ĭ". The website I linked to is the EDAL. --Vahag (talk) 13:31, 12 March 2016 (UTC)[reply]
Yeah it seems you are right. EDAL does use "ĭ". I have worked out the Wiktionary:Khakas transliteration following EDAL and am requesting @Wikitiki89: to implement it into Module:kjh-translit. --216.165.95.66 00:05, 15 March 2016 (UTC)[reply]
@Wikitiki89: Allow me some more days to work out a more precise transliteration representing EDAL. Some part of that dictionary is vague (representing a different dialect from standard Khakassian), and I am checking it with Soviet-published Khan Mirgen to check what's the correct relation. --216.165.95.66 00:29, 15 March 2016 (UTC)[reply]
Sure, just let me know when you're done. --WikiTiki89 14:47, 15 March 2016 (UTC)[reply]
  • It seems Starostin followed a strong phonetical transcription, except for phonemical letter j, which can be either [j] or [d͡ʒ], but never for Kazak [ʒ]-[j] sound (treated as two letters). --146.111.30.193 17:43, 24 March 2016 (UTC)[reply]
@Wikitiki89: The transcription table following EDAL (for Xɨzɨl dialect) has basically been done: Wiktionary talk:Khakas transliteration (also Module talk:kjh-translit) but I still need some time to finish that of Fuyu Girgis dialect. It is somewhat disappointing that in Hu-Imart transliteration the letter ĭ was used to represent the phoneme for schwa (е and и) and back i (ы) while in Starostin's system ĭ is і. --146.111.30.193 19:19, 5 May 2016 (UTC)[reply]
And that's also one of the reason why I proposed using "ë" to transliterate и (thus [3] ä, ë, ı becomes the Fuyu Girgis schwa ĭ while і is always i). --146.111.30.193 19:23, 5 May 2016 (UTC)[reply]

Previewing Tables edit

I often edit translation tables, and find it somewhat annoying that I cannot expand any sort of table when previewing an edit, which sometimes means I inadvertently save edits with broken templates, and have to make multiple edits before I finally figure out how to fix it.

Now, I was editing an article while logged out of my account, and I realized that I was able to expand the tables while previewing the edit. I logged in, and was no longer able to do so. Why is this? Why is it no longer possible to expand tables when I'm logged in? Is it just my browsers (Firefox and Opera)? Andrew Sheedy (talk) 07:05, 12 March 2016 (UTC)[reply]

I have no such problem (Firefox, on a Mac). I suspect it's a gadget, preference, or something in your common.js- those are the main account-specific customizations. It might not even be something directly associated with the boxes: If I remember correctly, the templates add a specific css class, which triggers javascript that first creates the boxes, then adds the control that lets you expand or collapse the box. I believe that something that causes an error which stops the js execution before it adds the control would prevent the boxes from being expandable. Chuck Entz (talk) 07:52, 12 March 2016 (UTC)[reply]
Hmm...I took a look at my preferences and gadgets, but I can't see anything that would be causing the problem. Andrew Sheedy (talk) 20:35, 13 March 2016 (UTC)[reply]
Is it every time for you while editing? I have a problem where the javascript which allows table expansion fails to load every once in a while, usually when I am opening a link in a new tab. - TheDaveRoss 11:04, 14 March 2016 (UTC)[reply]

Links on rhyme pages edit

In my more recent rhyme entries for Icelandic (such as Rhymes:Icelandic/œr̥tʏr) I have formatted the links with the {{l}} template. However, the add rhyme tool uses plain links and will not order the addition correctly among the lines using the template. I think we should update the tool to use {{l}}, as it is already standard elsewhere, and of course very useful. – Krun (talk) 12:28, 13 March 2016 (UTC)[reply]

I totally agree but I have no idea how to implement it. Renard Migrant (talk) 15:53, 15 March 2016 (UTC)[reply]
The code is here: User:Yair rand/rhymesedit.js. Anyone who enjoys editing JavaScript, feel free to make the necessary changes. --WikiTiki89 15:59, 15 March 2016 (UTC)[reply]
Almost rewrote it. I added a dependency but at least it became a little more readable.
This was the result of adding a,A,z and Z.
Here's the updated script --Dixtosa (talk) 19:17, 15 March 2016 (UTC)[reply]
Your script uses a deprecated template, {{langrev}}. In fact I'm surprised we still have it. —CodeCat 19:33, 15 March 2016 (UTC)[reply]
We still have it because we don't know what scripts still use it. --WikiTiki89 19:43, 15 March 2016 (UTC)[reply]

garish Latin inflection tables edit

Latin inflection tables (see albus) have become garish, with dark colours that make it hard to see the text of some of the forms (perhaps especially for colourblind people). We have historically avoided vivid or deep colours in inflection tables (see e.g. Template talk:eo-conj for some evidence of this norm). Let's tone the Latin tables down. - -sche (discuss) 20:09, 13 March 2016 (UTC)[reply]

Indeed. That thing is hideous, no offensive to whoever created it. Andrew Sheedy (talk) 20:15, 13 March 2016 (UTC)[reply]
Do we really agree with the premise of having all inflections with the same ending share the same background color? If we do, we are more or less forced to a accept a patchwork look. The first 6-8 different endings can probably be distinguished with only hue differences (all pale and therefore less garish), but after that light and dark or high and low saturation would probably be required and garishness is more likely. If there is any kind of standardization across templates (within the same language or language family), the designer of the template would not have the ability to choose the colors in such a way as to improve the esthetics. Lastly, how does this work for the color blind? DCDuring TALK 21:52, 13 March 2016 (UTC)[reply]
How about we take it one step further, and develop a style guide for inflection tables? If we create css classes for each of the many inflections and establish default styling for all of them, then each table can share a look and feel, while being customizable at the individual user level if they so choose. It would be somewhat convenient if every future tense was the same style, regardless of language, etc. - TheDaveRoss 11:02, 14 March 2016 (UTC)[reply]

What is the acceptable colour range? --kc_kennylau (talk) 23:08, 14 March 2016 (UTC)[reply]

The whole range of hues, but limited to the rather pale. There might be four available among the colors Appendix:Colors calls "white". What's the available palette? I suspect that a table of colors for various numbers of distinct inflected forms would work. DCDuring TALK 00:06, 15 March 2016 (UTC)[reply]
I just noticed this today, it's very distracting. Is that deliberate? Because the way it's done, I assume it is, just I don't know why. Renard Migrant (talk) 15:52, 15 March 2016 (UTC)[reply]
I think the consensus here is fairly clear, so can the colours be removed? I don't see what the point of colour-coding the declension table like that is. The shades of bright green around the edge are bad enough by themselves; we don't need any more colour in those tables. This, that and the other (talk) 06:36, 19 March 2016 (UTC)[reply]
The point is clear enough to me: the idea was to color-code the tables so that identical forms have the same background color (e.g. alba has the same background color in the nominative singular feminine, nominative plural neuter, and accusative plural neuter). A nice idea, but it doesn't work in practice: it's just distracting and not helpful at all. —Aɴɢʀ (talk) 11:17, 19 March 2016 (UTC)[reply]
What about this? (although some of the RGB values generated by my code are hilariously bad, it doesn't look too bad IMO) —suzukaze (t・c) 06:48, 20 March 2016 (UTC)[reply]
Speaking for myself, I don't want differently colored cells in inflection tables at all. —Aɴɢʀ (talk) 15:26, 20 March 2016 (UTC)[reply]
When I first introduced the possibility, I was careful to say "subtle", and it was in the context of rearranging the rows, so I thought it would be simply a matter of color-coding rows with an almost-white shade of either gray or some color compatible with the colors already in the table- not a bubblegum kaleidoscope like this. Chuck Entz (talk) 15:38, 20 March 2016 (UTC)[reply]
Can the template be restored please? The colours are now gone, but the words are centered. They were left-aligned before and I want to keep it that way. —CodeCat 17:43, 22 March 2016 (UTC)[reply]

T:reference-journal edit

Small bug: in anarỹỹ and several other entries, there should be a comma and a space between the year and the author's name, but there isn't — they're run together as "1973David". @Smuconlaw, who may know how to fix it. Apparently old uses of T:reference-journal were redirected directly to T:quote-journal/source; however, switching anarỹỹ to use T:quote-journal (rather than T:quote-journal/source) doesn't resolve the issue. - -sche (discuss) 05:41, 14 March 2016 (UTC)[reply]

I have made a request for uses of the deprecated templates to be replaced with the updated templates, and @Benwing2 is working on them. In this case, the correct template is {{cite-journal}} since the citation is in a "References" section. I've replaced it. The problem was probably caused by an editor putting both |year= and |nodate= in the template, which is an unexpected combination. — SMUconlaw (talk) 07:16, 14 March 2016 (UTC)[reply]
@Smuconlaw I'll get to this tomorrow ... need to go to sleep now. Benwing2 (talk) 08:55, 14 March 2016 (UTC)[reply]
Sweet dreams! ;-) — SMUconlaw (talk) 11:11, 14 March 2016 (UTC)[reply]

Category:Requests for autoformat edit

Is there a bot tackling these at the moment? Renard Migrant (talk) 15:51, 15 March 2016 (UTC)[reply]

Categories of words descending from PIE lemmas edit

I wish to categorize all descendants of, for example, a lemma like *kʷis. But we only have root descendants category templates and that does not do well with lemmas. I guess I'll have to manually create categories for them then. Hillcrest98 (talk) 22:59, 15 March 2016 (UTC)[reply]

I suppose *kʷ- in itself might be considered a root, albeit an irregularly-shaped one. It certainly fits the definition of a root in that it has a basic meaning and is used for word formation. —CodeCat 23:18, 15 March 2016 (UTC)[reply]
For basic PIE words, I've created {{PIE word}}. However, now you can categorize descendents of *kʷis using *kʷ-, which @CodeCat just created. — Eru·tuon 01:06, 23 March 2016 (UTC)[reply]

Template:derivsee edit

Why does expanding the list work here, but not here or here? Does this have anything to do with how recently the category was created? --WikiTiki89 20:24, 16 March 2016 (UTC)[reply]

They are working for me on all three at the moment, I have had issues with intermittent javascript loading recently. - TheDaveRoss 20:29, 16 March 2016 (UTC)[reply]
Hmm... I checked the JavaScript console in my browser and there were no errors. And I even did the cache bypass and all that several times. --WikiTiki89 20:34, 16 March 2016 (UTC)[reply]
Related, {{suffixsee}} on Reconstruction:Proto-Germanic/-hw is not working, despite the category containing multiple entries. —JohnC5 20:31, 16 March 2016 (UTC)[reply]
That's strange, but a slightly different symptom, since in the above cases, the expansion doesn't work at all, while in your case, the expansion works but incorrectly shows that the category is empty. --WikiTiki89 20:34, 16 March 2016 (UTC)[reply]
Fixed. —CodeCat 20:35, 16 March 2016 (UTC)[reply]
To clarify, CodeCat only fixed the Reconstruction:Proto-Germanic/-hw issue, but not the one that I started this discussion for. --WikiTiki89 20:36, 16 March 2016 (UTC)[reply]
I figured it out, it had to do with a hack I had in my own User:Wikitiki89/common.js. --WikiTiki89 20:39, 16 March 2016 (UTC)[reply]

Semi-automatic Thai transliteration edit

The new module Module:th-pron and Module:th-translit transliterate Thai terms with mostly phonetic respellings (Thai pronunciation rules are very complicated, full of exceptions and irregular pronunciations).

Anyway, when a term is defined with {{th-pron}}, it can be transliterated automatically and correctly (there is a small number of homonyms with different pronunciations, though). It relies on Module:links. I think these features should be documented and editors be aware of the special case, only for Thai.

Some points:

  1. Semi-automatic transliterations override manual in {{t}}, {{t+}}, {{l}}, {{m}}
  2. {{th-l}} is designed for Thai, it also take phonetic respellings (p=) as a parameter (currently being fixed? but was working). It needs to work, so that incorrect automatic transliteration could be overridden with phonetic respellings.
  3. Undefined monosyllabic terms are automatically transliterated but there are occasional incorrect transliterations.
  4. It's not 100% perfect yet, some phonetic respelling rules need to be reviewed, especially the use of vowel shortener when there are other diacritics or letter "ห" is silent and used to convert consonants to high class. Should only "หฺ" with anusvara be used in such cases?
  5. The more terms are defined using the new methods, the more accurate the transliterations get. Usage examples with {{th-x}} rely on existing terms.

Calling editors involved or who may be interested: @Wyang, Iudexvivorum, Octahedron80, หมวดซาโต้, Alifshinobi, kc kennylau, Hippietrail, Lo Ximiendo, YURi. --Anatoli T. (обсудить/вклад) 23:02, 17 March 2016 (UTC)[reply]

dog in the manger edit

Can anyone see where the huge blank space at the top of this entry is coming from? This, that and the other (talk) 01:21, 19 March 2016 (UTC)[reply]

It doesn't show up with RHS ToC option selected. DCDuring TALK 01:29, 19 March 2016 (UTC)[reply]
I just see space to the right of the ToC when I opt out of RHS ToC. I use FF 45.0. and am about to update. DCDuring TALK 01:33, 19 March 2016 (UTC)[reply]
Same with FF 45.0.1 DCDuring TALK 01:34, 19 March 2016 (UTC)[reply]
I don't see it. I seem to remember reports in the past about {{was wotd}} and {{wikipedia}} (or the template it redirects to) not playing well with each other, but I thought that was resolved. Chuck Entz (talk) 02:30, 19 March 2016 (UTC)[reply]
Sorry, I should have thought about checking different browsers. The space is seen in IE and Edge, but not in Firefox and Chrome. Microsoft's rendering engines are nowhere near as buggy as they were years ago, so I'm quite surprised to see this lingering discrepancy. This, that and the other (talk) 03:33, 19 March 2016 (UTC)[reply]
I do not think they are buggy so much as some browsers and IE have different understanding (specification) of html and css.
Wrapping left floated templates in a single div with floatright styling fixes these kind of rendering problems. Is there any way to automatically have those templates wrapped? --Dixtosa (talk) 17:56, 19 March 2016 (UTC)[reply]

Template:WOTD – suppressing audio edit

{{WOTD}} automatically links to an audio file of the pronunciation of a word if one exists. However, this isn't always appropriate: see, for example, Wiktionary:Word of the day/April 3 (mother, which should be pronounced as moth-er). Could someone please update the template so that it is possible to suppress the appearance of the audio file, perhaps with |audio=off? — SMUconlaw (talk) 17:24, 19 March 2016 (UTC)[reply]

As I commented at Talk:mother#Etymology_4 (concerning the section which is now etymology 5), "mother" exists on the web as a variant of the durably-attested "moth-er", but I don't think "mother" itself meets CFI. Hence, it shouldn't be used as a word of the day. It would still be good to resolve the issue you raise, since it might come up again. - -sche (discuss) 19:19, 19 March 2016 (UTC)[reply]
This was proposed by another editor. Sure, I can change it. Will do so later. In any case, I hope an editor more familiar with {{WOTD}} can look into tweaking it as suggested above. — SMUconlaw (talk) 20:24, 19 March 2016 (UTC)[reply]

Two changes to Template:la-decl-2nd-er edit

I would like to request two changes to this template. First, it should not display the text "nominative singular in -er", because on some pages where it is used, such as vir, this is incorrect. Second, I think it should link the word in the footnote—for example, at vir, the footnote should be "May also be vire." I don't know how to make these changes, so I'd appreciate it if someone else could make them. —Mr. Granger (talk • contribs) 17:40, 20 March 2016 (UTC)[reply]

Pinging @JohnC5, Esszet, Kc kennylau, CodeCat, who have recently edited this template or the module it uses—does one of you know how to make these changes? —Mr. Granger (talk • contribs) 02:10, 22 March 2016 (UTC)[reply]
Those changes would be easy enough to make, but: 1) how many second declension nouns are there that end in -ir (or something like it) as opposed to -er? 2) I don't think most of the alternate vocative singular forms have pages of their own, so making them linked would probably just create a lot of red links – unless someone wants to get a bot or something to create pages for them. Esszet (talk) 14:03, 22 March 2016 (UTC)[reply]
Judging by the pages that transclude the template, most that follow this pattern do end in -er. There are several that end in -ir, though, including septemvir and levir. But displaying incorrect information in any entry is unacceptable, so even if it were just vir, something would need to change.
There's nothing wrong with redlinks—they encourage page creation. Certainly these alternative vocative forms should have entries created at some point, and I think declension tables should link to all of the forms they list. —Mr. Granger (talk • contribs) 15:28, 22 March 2016 (UTC)[reply]
I fixed the issue with "-er" and words that don't actually end in -er, but as far as I know, red links are supposed to be avoided unless the non-existent pages that they link to are especially likely to be created. Correct me if I'm wrong, but I think that your second proposed change thus should not be made. Esszet (talk) 23:00, 22 March 2016 (UTC)[reply]
I consider a redlink to indicate a page that we want to have created. Whether it's likely isn't relevant. —CodeCat 23:01, 22 March 2016 (UTC)[reply]
Exactly. Entries for the alternate vocative forms should ultimately be created, so we should include the links in the declension tables. How likely it is is not relevant—especially since including the redlink makes the linked entry more likely to be created. —Mr. Granger (talk • contribs) 00:03, 23 March 2016 (UTC)[reply]
I figured out how to make the change myself. —Mr. Granger (talk • contribs) 00:16, 23 March 2016 (UTC)[reply]

Module edit request edit

Can an admin please add the following sort key for Romanian to Module:languages/data2? 

sort_key = {
	from = {"ă" , "â"  , "î" , "ș" , "ț" },
	to   = {"a~", "a~~", "i~", "s~", "t~"}},

Thank you. Redboywild (talk) 19:38, 20 March 2016 (UTC)[reply]

Added. DTLHS (talk) 20:26, 20 March 2016 (UTC)[reply]
Thanks! Redboywild (talk) 11:19, 21 March 2016 (UTC)[reply]

WT:PREFS cookies edit

The cookies used by WT:PREFS have been being set without path: '/', causing them to be inaccessible from pages not prefixed with simple "/wiki/". As a result, prefs don't run on many pages. Just switching wiktSetPrefCookie to use the correct path now doesn't work, because the more local cookies are still around, and take priority when being accessed, but newly set cookies wouldn't override them, and would instead just be duplicated. So, switching directly to that would just make the cookies un-modifiable.

Any ideas for solutions to this? --Yair rand (talk) 10:00, 21 March 2016 (UTC)[reply]

I am not expert, but I think that we could just reset the values of the existing cookies to blank them and add an expiry time. - TheDaveRoss 18:57, 24 March 2016 (UTC)[reply]
We can inform users of WT:PREFS to clear their cookies...? Also, this didn't used to be the case, everything used to work on /w/ pages until maybe about a year ago. --WikiTiki89 19:02, 24 March 2016 (UTC)[reply]
@Wikitiki89: wiktSetPrefCookie's path=/ was inadvertently removed in January 2014. I'm not sure everyone would know how to clear their cookies, unfortunately. --Yair rand (talk) 10:40, 28 March 2016 (UTC)[reply]
Won't wiki-specific expire in 30 days if custom.js does not touch them?--Giorgi Eufshi (talk) 11:15, 28 March 2016 (UTC)[reply]
I'm sure that most people who actually use the WT:PREFS would be able to figure out how to clear their cookies. --WikiTiki89 15:24, 28 March 2016 (UTC)[reply]
  • How about this: The JS could be changed so that the cookies are backed up, deleted, and then automatically recreated with the proper path, and then an additional cookie is set so that it only gets done once per user. This needs to be repeated for every cookie that used wiktSetPrefCookie. The extra code could then be removed after all the old broken cookies are certain to have either expired or been fixed. Are there any problems with this? --Yair rand (talk) 17:45, 31 March 2016 (UTC)[reply]
    Sounds good, as long as it doesn't crash between deleting and recreating. And as long as it doesn't slow down page loads after the "additional cookie" is set. And as long as the deleted cookies are donated to a food drive. --WikiTiki89 17:57, 31 March 2016 (UTC)[reply]
    Done. --Yair rand (talk) 15:37, 3 April 2016 (UTC)[reply]
    Great! I'm already benefiting. --WikiTiki89 15:20, 4 April 2016 (UTC)[reply]

What's up with concession? edit

I get simply "NULL" on an otherwise blank page. Other pages like tea, Verabschiedung and even concessions and concede work fine. Even fr:concession works. de:concession also works, although I see an error in the dev console ("NULL is not defined"). What's going on? Wyverald (talk) 06:23, 22 March 2016 (UTC)[reply]

Ive found the shortest one ვ xD--Giorgi Eufshi (talk) 06:32, 22 March 2016 (UTC)[reply]
If you add "?action=purge" to the end of the url you should get the page working again. DTLHS (talk) 06:32, 22 March 2016 (UTC)[reply]
See phab:T130575. --Yair rand (talk) 06:39, 22 March 2016 (UTC)[reply]

template de-conj-strong edit

How du i add the form du bissest to beißen#Conjugation as an alternative to and in fact the more common form of du bisst? --Espoo (talk) 13:07, 22 March 2016 (UTC)[reply]

And how du i add the imperatives to wissen? --Espoo (talk) 23:14, 30 March 2016 (UTC)[reply]

Verbal arguments edit

Lots of verbs in Ancient Greek, Old Norse, and Icelandic (and other languages) take oblique cases as "subjects" or non-accusative cases as "objects": for instance, þykja, δοκέω (dokéō) take dative of "subject" in at least some of their senses. At the moment, I mention these things using {{label|grc|with dative}}, but there should be a better way, so that words can be put in categories according to what type of arguments they take (for instance, Category:Ancient Greek words with dative objects). Also could code such things as participle or infinitive arguments with verbs of perceiving or saying. Maybe it could be called {{argument}}. The problem is, I don't know how to code something this complex. There are a lot of variations on verbal arguments. It could probably also include things such as the cases that prepositions and adjectives take. Might require a Module. — Eru·tuon 01:14, 23 March 2016 (UTC)[reply]

We have {{+obj}} already, but it doesn't categorise. —CodeCat 02:07, 23 March 2016 (UTC)[reply]
Hmm, cool. Someone already thought of it. I'll try using that. I suppose the categorization can be added later. — Eru·tuon 03:41, 23 March 2016 (UTC)[reply]
Categorization isn't that useful when you have words that can take three or more cases, depending on the meaning. The really interesting contrasts are within the entry, but categories only deal with the entry as a whole. Chuck Entz (talk) 04:54, 23 March 2016 (UTC)[reply]

Badly aligned labels edit

At head, the labels for the picture are all way off. (I'm using Firefox, if that makes a difference.) I didn't try to fix it because I'm not sure if it's just a me problem or if it looks like that for everyone. Andrew Sheedy (talk) 05:30, 24 March 2016 (UTC)[reply]

For me (in Chrome), "nose", "eye", and "mouth" are pretty well-positioned, but the rest are flying off (so I didn't notice them at first). — Eru·tuon 05:57, 24 March 2016 (UTC)[reply]
this edit was the culprit. I think I fixed it. --Giorgi Eufshi (talk) 06:42, 24 March 2016 (UTC)[reply]

Bug in {{affix}} edit

@CodeCat Embedding a link in {{affix}} usually works, but not when done this way:

{{affix|ru|по-|[[блестеть|блеск-]]|-ивать}}

This works OK on this Grease Pit page, producing:

по- (po-) +‎ блеск- (blesk-) +‎ -ивать (-ivatʹ)

But it inserts extra garbage when used on the page поблёскивать (pobljóskivatʹ). Can you check out what's going on?

Thanks!

Benwing2 (talk) 12:05, 24 March 2016 (UTC)[reply]

{{affix|ru|по-|блестеть|alt2=блеск-|-ивать}}
по- (po-) +‎ блеск- (blesk-) +‎ -ивать (-ivatʹ)--Giorgi Eufshi (talk) 12:48, 24 March 2016 (UTC)[reply]
Thanks. I do think it should support the other notation, though. It already does if you write e.g. {{affix|ru|[[блестеть|блеск-]]|-ивать}} so it's probably an easy bug fix. Benwing2 (talk) 18:07, 24 March 2016 (UTC)[reply]
Is [[блестеть|блеск-]] a suffix? —CodeCat 18:16, 24 March 2016 (UTC)[reply]
I hope you mean prefix. But it's not, it's a stem. But if it were a prefix, then the template should still work. --WikiTiki89 18:39, 24 March 2016 (UTC)[reply]

Special:AbuseFilter/11 edit

Hi there,

Can someone please fix this filter so it doesn't trigger a warning when adding [[fr:{{SUBST:PAGENAME}}]] (see Special:AbuseLog/251856).

It would save me a lot of time when I add interwiki links here.

Thank you. Thibaut120094 (talk) 16:24, 24 March 2016 (UTC)[reply]

It looks like that feature is already in the filter, but only if "subst" is lower-case, as in: [[fr:{{subst:PAGENAME}}]]. --WikiTiki89 17:09, 24 March 2016 (UTC)[reply]
I adjusted it to be case insensitive. - TheDaveRoss 17:22, 24 March 2016 (UTC)[reply]
Thanks! Thibaut120094 (talk) 18:53, 24 March 2016 (UTC)[reply]

eldergrad edit

I recently posted a publication citation where the term was used and it came back at once as spam. Please read the citation and advise what I did wrong?

Dentav

@Dentav The filter which stopped your edit is intended to stop people from spamming external links. It is not particularly sophisticated. You should be able to ignore the warning it gives you and post the citation with this type of filter. Thanks for your contribution, and sorry it was stopped. Also you can sign your posts with ~~~~. - TheDaveRoss 16:40, 29 March 2016 (UTC)[reply]

Thanks, I have since learned that "eldergrad" will need multiple citations (at least 3) across the USA in ordered to considered to be included. A national "eldergrad" learning institution is discussing the use of this term as being descriptive of their students in about 40 states....so when and IF that happens I can up date the citations. Dentav

Template:compound doesn't categorize prefixes edit

Template:compound doesn't categorize prefixes. Probably also suffixes. As such it is often used inappropriately. A solution would be to revert it to a version that doesn't allow the arbitrary inclusion of morphemes without creating an obvious, but not catastrophic-looking display problem. A better solution would be appropriate categorization for prefixes, suffixes and interfixes (forgoing the categorization for other morphemes). DCDuring TALK 12:24, 26 March 2016 (UTC)[reply]

This is pretty much how it has always worked. —CodeCat 20:50, 27 March 2016 (UTC)[reply]
I suppose I'm just finding abundant instances of usage contrary to what the documentation recommends when prefixes or suffixes are morphemes for the term in question. DCDuring TALK 00:17, 28 March 2016 (UTC)[reply]
So you'd like it to detect affixes based on starting or ending hyphens and categorize appropriately? DTLHS (talk) 00:22, 28 March 2016 (UTC)[reply]
@DTLHS I think it could be done from the searchbox using 'hastemplate:"compound"' and 'insource:' with a regex. Doing it that way instead of by dump-processing may be superior for on-going maintenance. However, my regex skills need work. (Also, I hope the JS flavor of regexes is sufficient.) I tried a couple of regexes but some of my later expressions found entries I thought my earlier ones should have.
A dump-based list would be helpful for a one-time cleanup. I wouldn't want to work outside English and Translingual. I found a large number of uses of {{compound}} that have infixes like -o-, for which {{compound}} does little harm. DCDuring TALK 12:03, 28 March 2016 (UTC)[reply]

Ancient Greek dialect labels edit

I've been using {{label}}, {{term-label}}, and the |from= parameter in {{alt form of}} for labeling dialects in Ancient Greek entries. At first, these templates would automatically link and categorize words in dialect-specific categories, but now that is no longer working. I think this is because I moved the labels to Module:labels/data/subvarieties. Apparently the subvarieties labels are not recognized by {{label}}, {{term-label}}, and {{alt form of}}. Could this be fixed? Labels are such a convenient way to label and categorize words in dialectal categories. (I asked this question in Module talk:labels, but nobody responded.) — Eru·tuon 20:19, 27 March 2016 (UTC)[reply]

The documentation of Module:labels says that labels are stored in Module:labels/data and its submodule Module:labels/data/regional. Move the labels to one of the recognized places (most of the "subvarieties" labels are in "regional", those that aren't regional go in Module:labels/data) and they will categorize. - -sche (discuss) 21:23, 27 March 2016 (UTC)[reply]
Unfortunately, I don't have the permissions to edit Module:labels/data/regional at the moment. Edit-protected by cascading from Wiktionary:Main page. You're an admin; could you revert my edit in which I removed the labels from "regional"?
How are the "subvarieties" labels used, if not in {{label}}? — Eru·tuon 21:38, 27 March 2016 (UTC)[reply]

@CodeCat Could you revert my edit to reinstate the labels? — Eru·tuon 05:22, 2 April 2016 (UTC)[reply]

Searching for Ancient Greek forms edit

It's really frustrating that the search bar can't find Ancient Greek forms with different accent marks. This is particularly a problem since we list Ancient Greek inflected forms with macrons and breves. So, if someone is searching for ἱερέα (hieréa, accusative singular), a form that will occur in Ancient Greek texts online, they won't find the lemma form ἱερεύς (hiereús, “priest”, nominative singular), because the accusative singular is listed in the inflection table as ἱερέᾱ (hieréā), with a macron on the final vowel.

Similarly, if they search for ιερευς (iereus), without any diacritics, a bunch of Modern Greek forms will pop up in the search bar, but if they select "containing ιερευς" at the bottom, no entries will show up (just someone's list of Strong's Greek words).

This is different from the Latin alphabet: if you search "etre" and select "containing etre", the correct entry être shows up as the second option (under etre). That's what should happen with Greek.

I vaguely remember people discussing this, maybe on the Ancient Greek talk page, but nothing has been about it, so I thought I'd complain in a more public place. Is there a way to fix this problem, so people can find Ancient Greek forms listed in entries, or headwords, even if they have typed the wrong diacritics (or even the right diacritics, just without macrons and breves)? — Eru·tuon 00:32, 28 March 2016 (UTC)[reply]

The only solution I can think of probably won't be very popular: to strip all diacritics from both Modern and Ancient Greek. Then both Modern ιερέας (ieréas) and Ancient ἱερέᾱς (hieréās) would be at ιερεας (with hard redirects from the forms with diacritics) and would show their diacritics only in their headword lines as well as when mentioned in {{l}}, {{m}}, {{t}}, etc. But I suspect this proposal will meet with general disapproval, which is why I've never actually proposed it. —Aɴɢʀ (talk) 07:04, 28 March 2016 (UTC)[reply]
Or maybe create a disambiguation page without the diacritics? — SMUconlaw (talk) 10:34, 28 March 2016 (UTC)[reply]
That could work, though Wiktionary doesn't have a history of making disambiguation pages. —Aɴɢʀ (talk) 11:23, 28 March 2016 (UTC)[reply]
This has already been discussed in the past with regard to other languages. There has been a bug in Phabricator about it and it has not progressed. The devs do not seem to care. And there is nothing we can do about it without the devs. --WikiTiki89 15:26, 28 March 2016 (UTC)[reply]
I've been thinking more about this, and actually we do have disambiguation pages here, but in Appendix: namespace, namely the "Variations of..." pages. What do other people think of creating pages like Appendix:Variations of "ιερεας", which could then link to both ιερέας and ἱερέας; and in particular also having [[ιερεας]] as a hard redirect to Appendix:Variations of "ιερεας"? That would allow us to find all Greek words regardless of diacritics (since the search box would find the redirect [[ιερεας]]) without creating the unattested form [[ιερεας]] in main namespace. In cases like βάπτισμα where there is only one form with diacritics, the hard redirect [[βαπτισμα]] could go straight to βάπτισμα rather than to a disambiguating appendix. —Aɴɢʀ (talk) 10:24, 6 April 2016 (UTC)[reply]
Seems like a good compromise, if the back-end can't be fixed by the developers within a reasonable time. — SMUconlaw (talk) 10:31, 6 April 2016 (UTC)[reply]
Honestly, I've never been a fan of those disambiguation pages, as they tend to list a lot of things that aren't really related. However, this is would be a bit of a different use for them, so I don't know how I feel. --WikiTiki89 14:24, 6 April 2016 (UTC)[reply]

{{lo-verb}} lacks a "head" parameter edit

Many heading templates have a "head" parameter. One use of the parameter is to include wikilinks to each part of the current entry's headword. This is particularly useful in monosyllabic isolating languages whose scripts don't use spaces between either words or syllables.

Would somebody fluent in template coding like to add support? — hippietrail (talk) 04:06, 28 March 2016 (UTC)[reply]

The head parameter is the first parameter: {{lo-verb|[[ສະບາຍ]][[ດີ]]|sabaai-dii}} DTLHS (talk) 04:08, 28 March 2016 (UTC)[reply]
Oh! So many variants! Maybe the template needs a doc page then. — hippietrail (talk) 04:40, 28 March 2016 (UTC)[reply]

New notation: {{lo-xxxx|head=xxxx|tr=xxxx}} same way as other languages' headword. However, you do not need to input them all. For noun,verb,adj,adv, they have other uses of parameter 1. --Octahedron80 (talk) 04:02, 17 July 2016 (UTC)[reply]

TTS dictionaries from Wiktionary IPA representations edit

(At Grease pit because it's essentialy a technicaly related request)

I found that a "free software" program called E-Speak A TTS and synthetic speech generator was being re-worked.

https://github.com/espeak-ng/espeak-ng

The number of languages it supports it's supports is quite high.

Is there any interest in Wiktionary contributors, also helping to improve the dictionaries E-SpeakNG has for translating words from text to speech?

I'd also like to ask if there's anyone on Wikitionary that has familiarity with Australian vocal dialects as Australian English doesn't seem to be represented in Espeak-NG yet, and adding a new "voice" requires some specfic technical knowledge concerning the characteristics.

ShakespeareFan00 (talk) 17:51, 28 March 2016 (UTC)[reply]

Are you doing Portuguese? I could help with that. — Ungoliant (falai) 17:57, 28 March 2016 (UTC)[reply]
have a look at the GIT repository I linked if you want to help improve the translations, ESpeak doesn't use IPA directly, but it used something that could be translated fairly easily I think. The current developer is quite appproachable and would probably welcome the input of native speakers in improving aspects of a particular language. Oh and did you mean European Portugese or Brazilian? ShakespeareFan00 (talk) 18:57, 28 March 2016 (UTC)[reply]
Brazilian. I can’t find a list of languages anywhere. I’ll try to install it and contact the developer if I find there’s something I can help with. — Ungoliant (falai) 19:49, 28 March 2016 (UTC)[reply]
It's Linux based, and HIGHLY experimental, for the data -

For the dictionary consult, https://github.com/espeak-ng/espeak-ng/blob/master/dictsource/pt_list and https://github.com/espeak-ng/espeak-ng/blob/master/dictsource/pl_rules

The former is a list of specifcaly encoded words, the later is some general rules for particular syallable and groups to save defining very similar words individually, Not sure how compounding works in Portugese so.

Basicly this is probably where you would need to add or amend stuff.

The phoneme data is at :- https://github.com/espeak-ng/espeak-ng/blob/master/phsource/phonemes https://github.com/espeak-ng/espeak-ng/blob/master/phsource/ph_pt_brazil is the phoneme not-quite-lo level details of the phonemes. You may need this to work out what's supported as a specfic phoneme sound to encode in the dictionary.

With documentation here - https://github.com/espeak-ng/espeak-ng/blob/master/docs/add_language.md

For the "voice" details try here under the relevant ISO 639-5 code (for the "suggested" language family) namely - https://github.com/espeak-ng/espeak-ng/blob/master/espeak-data/voices/roa/pt-BR


Basicly you build up a set of phoneme data and dictionary rules and then compile certain data files to make a compiled databsse. The exact details of how to make Formanant files aren't documented, as they use an external espeakedit program that's not supplied with the NG version.

ShakespeareFan00 (talk) 22:12, 28 March 2016 (UTC)[reply]

Hebrew vowel displaying strangely at צרים edit

 
A screenshot of the bug.

As you can see in the image at right, the vowel under the first (rightmost) letter of the word is displayed incorrectly in the adjective section, but correctly in the noun section. Is this happening for anyone else? What could be causing it? The Unicode strings are identical in the HTML for the page. --WikiTiki89 21:42, 29 March 2016 (UTC)[reply]

Even if you don't anything about this, I would like someone to at least check to see it happens for them too. --WikiTiki89 12:03, 30 March 2016 (UTC)[reply]
I have it displayed with a different font that has the niqqud larger and centered on the whole letter even on the resh where it looks odd to have the dot under nothing. I suspect that, even if it isn't specific to the font rendering on your system, it won't show on most fonts. Chuck Entz (talk) 14:09, 30 March 2016 (UTC)[reply]
Oh, I found the cupirt: there was for some reason a left-to-right tag in {{he-adj-form}}. --WikiTiki89 14:26, 30 March 2016 (UTC)[reply]

Special:AbuseFilter/15 blocks images in first line edit

Is such prevention expected? Nemo 09:49, 30 March 2016 (UTC)[reply]

Yes, the image should go inside the language section. --WikiTiki89 12:01, 30 March 2016 (UTC)[reply]

Problem with moving pages edit

I am no longer able to move wrongly-titled pages. The form appears, but the space to type the new title is missing. Any ideas? SemperBlotto (talk) 05:15, 31 March 2016 (UTC)[reply]

  • Would guess it might have something to do with a CSS or JS issue, try changing your skin in preferences to see if that fixes it, if not try commenting out your common.js and common.css files. - TheDaveRoss 15:59, 31 March 2016 (UTC)[reply]
    Changed skin from MonoBook to Vector. Deleted monobook.js. Logged off and on again. No change in inability to move. Restored status quo. SemperBlotto (talk) 16:11, 31 March 2016 (UTC)[reply]
    If you look at the page source do you see the markup for the move form? Starts with <div class='movepage-wrapper oo-ui-layout oo-ui-panelLayout oo-ui-panelLayout-padded oo-ui-panelLayout-framed'>. I tried switching to MonoBook and I am still able to move things. - TheDaveRoss 16:56, 31 March 2016 (UTC)[reply]
    That code is certainly there:- <div class='movepage-wrapper oo-ui-layout oo-ui-panelLayout oo-ui-panelLayout-padded oo-ui-panelLayout-framed'><form id='movepage' method='post' action='/w/index.php?title=Special:MovePage&action=submit' class='oo-ui-layout oo-ui-formLayout'><div id='mw-movepage-table' class='oo-ui-layout oo-ui-labelElement oo-ui-fieldsetLayout'><span class='oo-ui-iconElement-icon'></span><span class='oo-ui-labelElement-label'>Move page</span><div><div class='oo-ui-layout oo-ui-labelElement oo-ui-fieldLayout oo-ui-fieldLayout-align-top'><div class='oo-ui-fieldLayout-body'><span class='oo-ui-labelElement-label'>New title:</span><div class='oo-ui-fieldLayout-field'><div id='wpNewTitle' aria-disabled='false' class='oo-ui-widget oo-ui-widget-enabled mw-widget-complexTitleInputWidget' data-ooui='{"_":"mw.widgets.ComplexTitleInputWidget","namespace":{"id":"wpNewTitleNs","name":"wpNewTitleNs","value":0,"exclude":[-2,-1,2600]},"title":{"id":"wpNewTitleMain","name":"wpNewTitleMain","value":"rucaparib","suggestions":false}}'><div id='wpNewTitleNs' aria-disabled='false' class='oo-ui-widget oo-ui-widget-enabled oo-ui-inputWidget oo-ui-dropdownInputWidget mw-widget-namespaceInputWidget'><select tabindex='0' aria-disabled='false' name='wpNewTitleNs' class='oo-ui-inputWidget-input'><option value='0' selected='selected'>(Main)</option><option value='1'>Talk</option><option value='2'>User</option><option value='3'>User talk</option><option value='4'>Wiktionary</option><option value='5'>Wiktionary talk</option><option value='6'>File</option><option value='7'>File talk</option><option value='8'>MediaWiki</option><option value='9'>MediaWiki talk</option><option value='10'>Template</option><option value='11'>Template talk</option><option value='12'>Help</option><option value='13'>Help talk</option><option value='14'>Category</option><option value='15'>Category talk</option><option value='90'>Thread</option><option value='91'>Thread talk</option><option value='92'>Summary</option><option value='93'>Summary talk</option><option value='100'>Appendix</option><option value='101'>Appendix talk</option><option value='102'>Concordance</option><option value='103'>Concordance talk</option><option value='104'>Index</option><option value='105'>Index talk</option><option value='106'>Rhymes</option><option value='107'>Rhymes talk</option><option value='108'>Transwiki</option><option value='109'>Transwiki talk</option><option value='110'>Wikisaurus</option><option value='111'>Wikisaurus talk</option><option value='114'>Citations</option><option value='115'>Citations talk</option><option value='116'>Sign gloss</option><option value='117'>Sign gloss talk</option><option value='118'>Reconstruction</option><option value='119'>Reconstruction talk</option><option value='828'>Module</option><option value='829'>Module talk</option><option value='2300'>Gadget</option><option value='2301'>Gadget talk</option><option value='2302'>Gadget definition</option><option value='2303'>Gadget definition talk</option></select></div> SemperBlotto (talk) 19:56, 31 March 2016 (UTC)[reply]
  • The culprit is the MediaWiki:Gadget-MoveNoNSCombo.js gadget, I think. ("When moving pages, use the namespace-qualified title in the title box, and remove the separate namespace list" in Special:Preferences#mw-prefsection-gadgets.) Special:MovePage apparently had its format changed a while back, and the script hasn't been adapted to it. --Yair rand (talk) 20:05, 31 March 2016 (UTC)[reply]
    Yes! That fixes it. I haven't actually moved anything, but I get the input box now. Thanx. (Now, about that bot not working) SemperBlotto (talk) 05:51, 1 April 2016 (UTC)[reply]

Template:mention and automatic transcription of Arabic edit

I've noticed that while {{m}} generates an automatic transcription of an Arabic word at "mandil", it does not do so at "sais" (I had to use the |tr= parameter and add the transcription manually). Is this because vowel notation was not provided at "sais"? I'm guessing, as I'm unfamiliar with Arabic. — SMUconlaw (talk) 12:26, 31 March 2016 (UTC)[reply]

Yes, without the vowels, the transcription module cannot know how to transcribe the word. --WikiTiki89 13:19, 31 March 2016 (UTC)[reply]
OK, thanks. — SMUconlaw (talk) 15:21, 31 March 2016 (UTC)[reply]

Password problem with bot edit

I'm not having a good day.

Now, when I run my bot, it asks for a password. I supply the correct one and get:-

Logging in to wiktionary:en as SemperBlottoBot via API. Login failed. Wrong password or CAPTCHA answer? API login failed, retrying using standard webpage. Logging in to wiktionary:en as SemperBlottoBot Login failed. Wrong password or CAPTCHA answer? Password for user SemperBlottoBot on wiktionary:en: Warning: Password input may be echoed.

I know it's the correct password because it gets printed on the screen, and I can log in to Wiktionary as a human being using it. Any ideas? SemperBlotto (talk) 15:01, 31 March 2016 (UTC)[reply]

What framework are you using? They have made lots of changes to the API recently, including changing how cookies must be handled and which tokens are used for which actions. If you are on an older version of a framework it may need to be updated. - TheDaveRoss 15:05, 31 March 2016 (UTC)[reply]
Not sure what you mean by framework. It's Python 2.7.1, and I added the Wikipedia extension years ago. Hmm. SemperBlotto (talk) 15:14, 31 March 2016 (UTC)[reply]
The "Wikipedia extension" is the framework. It (probably) needs to be updated. --WikiTiki89 15:20, 31 March 2016 (UTC)[reply]
If it is still trying to log in via the old method I would guess that is the issue. If the extension is Pywikibot they have lots of updates; here is a note on their mailing list about switching to OAuth. If it is something else you may have some tinkering to do. - TheDaveRoss 15:21, 31 March 2016 (UTC)[reply]
As if by magic - now working again. Somebody must have done something. Anyway - today will be a better day. Cheers. SemperBlotto (talk) 07:00, 1 April 2016 (UTC)[reply]
I experienced this problem (and now I experience that it is no longer a problem) while trying to log in with AutoWikiBrowser. I suspect the changes to the API (mentioned above) may have been the issue. Glad they seem to be fixed. - -sche (discuss) 19:05, 7 April 2016 (UTC)[reply]

Protected page edited by supposedly non-autoconfirmed user edit

I protected Module:Altai-translit from edits by non-autoconfirmed users, but it was subsequently edited by a supposedly non-autoconfirmed user. So either how is that possible? Or why is this user autoconfirmed? --WikiTiki89 15:53, 31 March 2016 (UTC)[reply]

Their user-rights page shows autoconfirmed to me, they were autoconfirmed due to the age of the account I think. - TheDaveRoss 15:57, 31 March 2016 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2016/March&oldid=65118005"