Hello, you have come here looking for the meaning of the word Wiktionary:Grease pit/2016/March. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Grease pit/2016/March, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Grease pit/2016/March in singular and plural. Everything you need to know about the word Wiktionary:Grease pit/2016/March you have here. The definition of the word Wiktionary:Grease pit/2016/March will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Grease pit/2016/March, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
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)
{{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. --WikiTiki8915:27, 1 March 2016 (UTC)
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)
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)
@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. --WikiTiki8923:40, 1 March 2016 (UTC)
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)
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. —CodeCat16:44, 7 April 2016 (UTC)
Auto-add words with etymologies to WT:WE (wanted entries) by language
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)
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)
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)
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)
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. - TheDaveRoss12:28, 1 March 2016 (UTC)
Yes, this should be done by either a bot or by parsing dumps (which most people would equate with a bot anyway). --WikiTiki8915:29, 1 March 2016 (UTC)
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)
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. - TheDaveRoss17:10, 1 March 2016 (UTC)
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)
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)
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)
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)
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)
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)
IMO definitely use the order: 1, 2, 3, ..., 8, 9, 10, 11, 12, ... 99, 100, 101, ..., 911.
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. --WikiTiki8919:55, 1 March 2016 (UTC)
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.
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)
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. --WikiTiki8920:26, 1 March 2016 (UTC)
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)
Consolidating minor edits into a single major edit in an entry
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)
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)
@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)
I didn't mean merge the edits altogether, but just group them into an edit group that can be expanded to view individual edits. --WikiTiki8922:34, 2 March 2016 (UTC)
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)
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. --WikiTiki8915:41, 3 March 2016 (UTC)
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)
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)
This is why I support an opt-in strategy for "interesting" characters, rather than an opt-out for "uninteresting" characters. --WikiTiki8915:15, 2 March 2016 (UTC)
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)
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)
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. --WikiTiki8922:23, 2 March 2016 (UTC)
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)
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)
Also, the template assists in moving the pages over, so it should certainly be kept still. I wonder what you had in mind, -sche? —CodeCat23:12, 3 March 2016 (UTC)
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)
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)
Template:glink or similar to create a link to a glossary entry
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 ]. What do people think? This would hopefully encourage linking to the glossary rather than just inserting a raw link, e.g. ]. 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)
List of language codes that can be used with "etyl" and "m"
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)
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)
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)
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. DCDuringTALK16:37, 4 March 2016 (UTC)
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)
When {{affix}} was created, it didn't have this capability. It was added only later. So that explains the bad name. —CodeCat17:05, 4 March 2016 (UTC)
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)
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. - TheDaveRoss17:21, 4 March 2016 (UTC)
I completely agree with you. The constant harping about keystrokes, as if they are the final goal of Wiktionary, is really annoying. —CodeCat17:24, 4 March 2016 (UTC)
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)
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)
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)
@@CodeCat, TheDaveRoss Users are so annoying. Either save keystrokes or lose the contributors we have and then either find other human contributors who appreciate the readability, etc, or find non-human sources of content. Let me know how that works out. DCDuringTALK19:35, 4 March 2016 (UTC)
I want it to be as easy as possible to edit, but I don't think cryptic wikitext is actually better for anyone. - TheDaveRoss19:45, 4 March 2016 (UTC)
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)
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)
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. --WikiTiki8920:09, 4 March 2016 (UTC)
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. - TheDaveRoss20:15, 4 March 2016 (UTC)
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. --WikiTiki8920:19, 4 March 2016 (UTC)
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)
@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? DCDuringTALK00:19, 5 March 2016 (UTC)
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)
@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.
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)
Which red links are actually being targeted here? I noticed that "Norwegian Bokmål redlinks" popped up the other day, and then it disappeared. And it's worth noting that "red links" hidden in inflection tables are usually black-linked when no entry exists, not red-linked. Donnanz (talk) 10:59, 5 March 2016 (UTC)
Why does that have to be done in "real time" (ignoring the substantial latency delays) rather than by periodically (~monthly, quarterly, annually?) extracting lists from the XML dumps? Each language's page(s) could, for example, be one or more subpages of the "About" pages for the language. Even if one wanted to track new additions, that could be readily accomplished from the dumps.
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)
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. DCDuringTALK02:46, 6 March 2016 (UTC)
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)
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). DCDuringTALK14:17, 6 March 2016 (UTC)
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)
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. DCDuringTALK15:39, 7 March 2016 (UTC)
"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)
One can hold the cursor over a black link and determine whether the linked page is empty or not from the hover box message. DCDuringTALK17:16, 7 March 2016 (UTC)
@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)
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)
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)
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)
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)
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)
@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. —JohnC517:29, 8 March 2016 (UTC)
I agree. I want to make the warning red. Someone just made such a mistake in , which leads to wrong transliteration so I guess it's common. --146.111.30.19319:55, 10 March 2016 (UTC)
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. --WikiTiki8920:00, 10 March 2016 (UTC)
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.19320:03, 10 March 2016 (UTC)
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.19320:32, 10 March 2016 (UTC)
We do it for English because it is an accepted practice. For Khakas, we should use the accepted practice for transliteration. --WikiTiki8920:46, 10 March 2016 (UTC)
@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.19320:53, 10 March 2016 (UTC)
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. —JohnC520:51, 10 March 2016 (UTC)
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.19321:03, 10 March 2016 (UTC)
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. —JohnC520:59, 10 March 2016 (UTC)
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.19321:03, 10 March 2016 (UTC)
@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. --WikiTiki8921:15, 10 March 2016 (UTC)
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.19321:20, 10 March 2016 (UTC)
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? —CodeCat21:27, 10 March 2016 (UTC)
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.19321:31, 10 March 2016 (UTC)
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.19321:43, 10 March 2016 (UTC)
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.19321:48, 10 March 2016 (UTC)
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. —CodeCat21:51, 10 March 2016 (UTC)
And in Ukrainian, ч /tʃ/ is transliterated as č, can you please tell me why the exactly same ч /tʃ/ here should be transliterated as ç here? --146.111.30.19321:57, 10 March 2016 (UTC)
Because that's the custom for Turkic languages. In any case, I consider the matter closed with my proposal. —CodeCat21:58, 10 March 2016 (UTC)
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.19322:01, 10 March 2016 (UTC)
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.19322:05, 10 March 2016 (UTC)
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.19322:15, 10 March 2016 (UTC)
@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.19321:27, 10 March 2016 (UTC)
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. --WikiTiki8921:59, 10 March 2016 (UTC)
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.19322:03, 10 March 2016 (UTC)
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.19322:08, 10 March 2016 (UTC)
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)
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.21600:14, 12 March 2016 (UTC)
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.21600:56, 12 March 2016 (UTC)
@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, is homophoneme with , i.e. /i/=/ɪ/. So it seems as if should be transliterated as i, which is not the case. The definite Khakassian vowel shift is /e/->, 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 to an native Uyghur speaker, most likely (might depend on dialect) s/he will think it to be a consonant 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.21601:39, 12 March 2016 (UTC)
@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.6600:29, 15 March 2016 (UTC)
It seems Starostin followed a strong phonetical transcription, except for phonemical letter j, which can be either or , but never for Kazak - sound (treated as two letters). --146.111.30.19317:43, 24 March 2016 (UTC)
@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.19319:19, 5 May 2016 (UTC)
And that's also one of the reason why I proposed using "ë" to transliterate и (thus ä, ë, ı becomes the Fuyu Girgis schwa ĭ while і is always i). --146.111.30.19319:23, 5 May 2016 (UTC)
Previewing Tables
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)
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)
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. - TheDaveRoss11:04, 14 March 2016 (UTC)
Links on rhyme pages
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)
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)
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? DCDuringTALK21:52, 13 March 2016 (UTC)
@Kc kennylau: I have to agree, these are really hard to look at and unattractive. I don't remember you asking the Latin editor community about this change (but maybe I missed it). Can you please remove the colours? —Μετάknowledgediscuss/deeds23:05, 13 March 2016 (UTC)
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. - TheDaveRoss11:02, 14 March 2016 (UTC)
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. DCDuringTALK00:06, 15 March 2016 (UTC)
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)
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)
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)
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)
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)
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. —CodeCat17:43, 22 March 2016 (UTC)
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)
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)
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. —CodeCat23:18, 15 March 2016 (UTC)
They are working for me on all three at the moment, I have had issues with intermittent javascript loading recently. - TheDaveRoss20:29, 16 March 2016 (UTC)
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. --WikiTiki8920:34, 16 March 2016 (UTC)
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. --WikiTiki8920:34, 16 March 2016 (UTC)
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:
Semi-automatic transliterations override manual in {{t}}, {{t+}}, {{l}}, {{m}}
{{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.
Undefined monosyllabic terms are automatically transliterated but there are occasional incorrect transliterations.
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?
The more terms are defined using the new methods, the more accurate the transliterations get. Usage examples with {{th-x}} rely on existing terms.
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)
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)
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)
Template:WOTD – suppressing audio
{{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)
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)
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)
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)
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)
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)
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)
I consider a redlink to indicate a page that we want to have created. Whether it's likely isn't relevant. —CodeCat23:01, 22 March 2016 (UTC)
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)
The cookies used by WT:PREFS have been being set without path: '/', causing them to be inaccessible from pages not prefixed with simple "https://dictious.com/en/". 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.
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. - TheDaveRoss18:57, 24 March 2016 (UTC)
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. --WikiTiki8919:02, 24 March 2016 (UTC)
@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)
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)
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. --WikiTiki8917:57, 31 March 2016 (UTC)
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·tuon01:14, 23 March 2016 (UTC)
Hmm, cool. Someone already thought of it. I'll try using that. I suppose the categorization can be added later. — Eru·tuon03:41, 23 March 2016 (UTC)
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)
Badly aligned labels
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)
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·tuon05:57, 24 March 2016 (UTC)
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)
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. --WikiTiki8918:39, 24 March 2016 (UTC)
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 ~~~~. - TheDaveRoss16:40, 29 March 2016 (UTC)
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. 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). DCDuringTALK12:24, 26 March 2016 (UTC)
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. DCDuringTALK00:17, 28 March 2016 (UTC)
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)
@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. DCDuringTALK12:03, 28 March 2016 (UTC)
Ancient Greek dialect labels
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·tuon20:19, 27 March 2016 (UTC)
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"?
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·tuon00:32, 28 March 2016 (UTC)
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)
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. --WikiTiki8915:26, 28 March 2016 (UTC)
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)
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. --WikiTiki8914:24, 6 April 2016 (UTC)
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.
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)
TTS dictionaries from Wiktionary IPA representations
(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.
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.
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)
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)
It's Linux based, and HIGHLY experimental, for the data -
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.
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.
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. --WikiTiki8921:42, 29 March 2016 (UTC)
Even if you don't anything about this, I would like someone to at least check to see it happens for them too. --WikiTiki8912:03, 30 March 2016 (UTC)
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)
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)
p.s. If anyone else can do so, please move the wrongly titled Latin page "cirucmductio" to "circumductio".
Thanks. I still can't move pages (Internet Explorer, Google Chrome or Microsoft Edge). Could you also move "octaëdron" to "octaedron" please (it will also need editing to remove breves). Cheers. SemperBlotto (talk) 14:38, 31 March 2016 (UTC)
It works for me (Chrome, Windows 10) if I log on as SemperBlottoBot, but not as SemperBlotto. The "to" field appears and winks out immediately. SemperBlotto (talk) 15:54, 31 March 2016 (UTC)
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. - TheDaveRoss15:59, 31 March 2016 (UTC)
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)
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. - TheDaveRoss16:56, 31 March 2016 (UTC)
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)
Template:mention and automatic transcription of Arabic
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)
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)
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. - TheDaveRoss15:05, 31 March 2016 (UTC)
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. - TheDaveRoss15:21, 31 March 2016 (UTC)
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)
Protected page edited by supposedly non-autoconfirmed user
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? --WikiTiki8915:53, 31 March 2016 (UTC)
Their user-rights page shows autoconfirmed to me, they were autoconfirmed due to the age of the account I think. - TheDaveRoss15:57, 31 March 2016 (UTC)
Done --WikiTiki89 20:20, 10 March 2016 (UTC)
