In my computer hiders do not operate - key "show" does not exists and I can't open them. Please, correct it. Sic dixi REX NIGER10:27, 2 April 2016 (UTC)[reply]
This issue happens to me sometimes, but reloading the page fixes it. One cause is if the javascript which hides the content loads, but then something happens to go wrong before the javascript which generates the "show" button loads. If javascript is not enabled at all, the content is not hidden in the first place. - -sche(discuss)18:10, 2 April 2016 (UTC)[reply]
I tried to investigate it, but the Javascript here is so convoluted that I had no idea where the error might be coming from. It doesn't help that there is no reliable way to generate the error either. —CodeCat12:58, 3 April 2016 (UTC)[reply]
In Chrome Developers Tools there is a timeline feature that the Mediawiki JS pages offer as useful for JS. This MW page has more. Actually using this stuff is way beyond my paygrade. DCDuringTALK13:56, 3 April 2016 (UTC)[reply]
Is there any way to make the {{|bor}} not show up as the capitalized word "Borrowing", as in French [Term?]? [Note, June 2018: no longer displays this text --Benwing2] Sometimes this makes it inconvenient when doing the etymology. Like if you have it later in the sentence as opposed to the beginning, or if you put a qualifier such as "probably" or "likely" before. It would be more flexible if it just worked the same way as the {{|inh}} and {{|der}} ones, and you manually typed out borrowed or borrowing or whatever.
Another related problem is, what about words that were borrowed simultaneously from multiple languages? Like Romanian, when undertaking its "re-Latinization" efforts in the 19th century, started borrowing mass quantities of words from French. It also, in many cases, borrowed from both French or Italian, or a mix of them (cf. banchet, for example). The official etymological dictionaries of Romanian in many cases list a word as having been taken/derived from French, Italian, and literary Latin, and in some cases German too. I suppose this is when it was uncertain which particular language it was primarily taken from. Even though French is the most often listed, they are often adapted to a more Romanian "style", and this can be closer to looking like Italian (although a few words are taken almost unchanged in pronunciation from French). Older variants of some words may have been taken from different languages, like Greek, as well. Anyway, my point is that it doesn't look good in the etymology section, for example in incendiu, to have Frenchincendie and Italianincendio and Latinincendium. [Note, June 2018: no longer displays "Borrowed from" --Benwing2] Word dewd544 (talk) 16:00, 2 April 2016 (UTC)[reply]
Use the arguments nocap=1 and notext=1. For example:
Probably a {{bor|ro|fr|banquet|nocap=1}} and {{bor|ro|it|banchetto|notext=1}}.
There's been some discussion of removing the wording from the templates (so that they only generate the language name, like {{etyl}} does), making them more flexible. - -sche(discuss)18:07, 2 April 2016 (UTC)[reply]
Being able to auto-generate "Borrowing" seems somewhat handy, but it does not seem handy enough to outweigh the hassle with nocap and notext arguments, at least in terms of accessibility for new editors. --Tropylium (talk) 16:15, 22 April 2016 (UTC)[reply]
Linking to entries that start with the character /[edit]
To avoid linking to a subpage, it is necessary to write [[:/ameeni]] to link to entries like /ameeni that begin with the character /. The same is true for linking templates like {{m}} and {{l}}, but I don't see why that should be the case. Now that we have entries in the standard orthography of the Iraqw language, which uses </> for /ʕ/, it would be very helpful for them to be more straightforward to link to. Could somebody please improve those templates to facilitate linking? Thanks! —Μετάknowledgediscuss/deeds17:44, 2 April 2016 (UTC)[reply]
I really wish writing system designers wouldn't use punctuation marks as letters. The ideal solution to this problem is for Unicode to create a separate code point for a MODIFIER LETTER SLASH and for us to use that instead, but that's probably too much to hope for, and even if it happened, we'd still have to do something to accommodate Iraqw in the meantime. —Aɴɢʀ (talk) 19:55, 2 April 2016 (UTC)[reply]
Can someone create an etymology-only language for Russian Church Slavonic? I'm pretty sure it should be treated as a dialect of Old Church Slavonic (code cu). Not sure what code to use, maybe cu-ru? (Although most such codes seem to have 3 letters after the hyphen.) While we're at it, we might want similar entries for other Church Slavonic dialects; Wikipedia mentions three: Old Moscow, Croatian and Czech, but all of them in rather limited usage. Benwing2 (talk) 03:53, 3 April 2016 (UTC)[reply]
I'm not sure why it would be more complicated. There are only about 4 recensions, and each of them is clearly distinct from Old Church Slavonic; they are similar to Medieval Latin vs. Classical Latin. Benwing2 (talk) 06:36, 3 April 2016 (UTC)[reply]
For a while now, I've had trouble loading MediaWiki:Common.css (i.e. the page itself, not its CSS on other pages). It seems that there is some JS that runs in an infinite loop when I load the page (but I'm not 100% sure). Does anyone else have this problem, or better yet, know how to fix it? --WikiTiki8919:51, 5 April 2016 (UTC)[reply]
It loads perfectly fine when I'm not logged in, so it must be a bug either in my personal JS or in a gadget I have enabled. --WikiTiki8915:03, 8 April 2016 (UTC)[reply]
I didn't resolve it, all I did was identify the gadget in which the error is occurring. I disabled it for myself and hope that someone who is better at JavaScript will take a look at it. --WikiTiki8917:11, 8 April 2016 (UTC)[reply]
I have investigated the case. It was partly due to OrangeLinks and partly "Make wikilinks ...." gadget. The latter made wiki style links in anchors' hrefs like this <a href="https://en.wiktionary.org/wiki/w:someWikipediaPage">[[w:someWikipediaPage]]</a>). But OrangeLinks gadget assumed href's contained 'normal' links (i.e. "https://en.wikipedia...."). That's reasonable because when parsed [[w:someWikipage]] is rendered as a 'normal' link. I corrected OrangeLinks so that now it skips external links. The corrected version is at its talk page.
Thanks! The strange thing is, though, that when I was trying to identify which gadget was causing the problem, I tried disabling orange links, but that alone didn't help. --WikiTiki8914:42, 11 April 2016 (UTC)[reply]
No matter what I do, I can't get the text in the 3rd person imperfect subjunctive and imperative cells to center like the rest of the table. No idea why it's doing that in just those two spots. KarikaSlayer (talk) 00:53, 6 April 2016 (UTC)[reply]
Template:rel3 and Template:der3 don't seem to correctly sort Greek words. If you look at the lists in the Derived and Related forms of πείθω(peíthō), ἄπειστος(ápeistos) and ἀνᾰπείθω(anapeíthō) should be at the top of their respective lists, but they're somewhere in the middle of the first column. The rest of the words are in seemingly random positions, even though the words are alphabetized in the source code. I don't know much about module coding, but I guess Module:columns is implementing some bizarre kind of sorting, which undoes the sorting of the parameters input into the template. Adding |sort=0 fixes it, but could the module be fixed so that sorting actually alphabetizes? — Eru·tuon02:54, 7 April 2016 (UTC)[reply]
Wow! Quick response. For the most part, yes. It's having trouble with letters with breves ᾰ(a), though, which are ordinarily removed when creating links. πᾰρᾰπείθω(parapeíthō) is alphabetized after προπείθω(propeíthō), when it should be before πειθαναλογία(peithanalogía), as if it were written παραπείθω(parapeíthō) (which would be the entry name if there were an entry). Perhaps the words could be put through the entry-name determining apparatus, to remove breves and macrons, before they are sorted? — Eru·tuon03:26, 7 April 2016 (UTC)[reply]
There are 211 Swedish entries with table markup in the sections “Derived terms”, “Related terms” and “Synonyms”. I propose replacing it with {{der4}}, {{rel4}} and {{syn4}}. It could be another option with fewer ({{der2}}, {{der3}}) or more ({{der5}} columns. I just guess the four column template is a good choice. Editors should never have to choose the number of columns anyway. The template should do it automatically based on user preference and number of list items.
I also propose changing “Related terms” to “Derived terms” when appropriate, since a lot of Swedish entries have derived terms incorrectly labeled as related terms.
I have put all code on a single line since the template fails when adding newlines between arguments, unless wrapping arguments in another template. I do not think it really matters, so I will keep making it a single line unless there is a good reason not to.
I have a bot that can change all entries. Any comments before I proceed? Do I need to register a bot account for this?
This Russian adjective is in a category "plural only adjectives". I think this needs to be "Russian plural only adjectives" or something similar. SemperBlotto (talk) 10:28, 8 April 2016 (UTC)[reply]
Proposal of templates automatically choosing the number of columns[edit]
Templates for listing derived terms and related terms are now a mess, because the number of columns to display has to be specified manually when using them. I propose to introduce the following two templates that automatically select an appropriate presentation instead of requiring it to be specifying manually when using them. The current implementation automatically selects a number of columns to display based on the number of items in the list. If we ever want to change the presentation or the algorithm for selecting the number of columns, we can simply modify Module:term list, and we will not have to change thousands of pages using the templates.
Support, though the language parameter should be parameter 1, not lang=. But why do we even need two templates? Is a column of derived terms any different from a column of related terms? Also, we should do the same with translations, but fixed at 2 columns. So that we no longer need to manually balance them? —CodeCat20:22, 8 April 2016 (UTC)[reply]
I just went with lang because that is how the currently used templates work. It could easily be changed to 1. The reason we have two templates is that they have a different text in the headline to click to expand/collapse the box. I see no real point in that though. The headline could just say Show/Hide and nothing else. Chokladkaka (talk) 20:42, 8 April 2016 (UTC)[reply]
The column count should really depend on the screen size, rather than the number of words. That maybe can be done with CSS, which would be preferable to being done by a module. Anyway, I will oppose any term list template that takes the terms as parameters rather than just surrounding the terms. Thus, I think the {{col-top}} and {{col-bottom}} templates should be used (or a collapsible version of them). --WikiTiki8920:27, 8 April 2016 (UTC)[reply]
That is why I emphasize that the implementation can be changed at any time. I made it count the items simply because that is the easiest thing I could come up with for now. None of this is possible with templates that surround the terms. If we have a top and bottom template, then the editor must select the number of columns manually and use the top2, top3 or top4 template, and must count the items and insert mid2, mid3 and mid4 templates at precisely the right positions. Chokladkaka (talk) 20:42, 8 April 2016 (UTC)[reply]
@Wikitiki89: I just noticed that. {{col-top}} and {{col-bottom}} are auto-balancing, because they use CSS columns instead of HTML columns, but they do not automatically select how many columns to display, and whether to display columns at all. Chokladkaka (talk) 08:01, 9 April 2016 (UTC)[reply]
If there aren't enough words in the list to require columns, then there doesn't need to be a template at all. The number of columns cannot be decided by a module anyway, and if we decide to use CSS or JS for that, they would work fine with template pairs like this. --WikiTiki8915:44, 11 April 2016 (UTC)[reply]
What value does this add? It will complicate editing and consume resources, the "value" that we can change how many columns are displayed is not particularly important to me. I (obviously) am a huge proponent of derived and related sections being contained within templates, I am not sure this treatment is the best method. If there were similar gadgets applied to this as are applied to the translation sections I might be OK with it. - TheDaveRoss20:29, 8 April 2016 (UTC)[reply]
1. It removes the need for editors to count the list items and select between rel2, rel3, rel4 and rel5. 2. It allows changing the implementation to take screen size into consideration. Chokladkaka (talk) 20:42, 8 April 2016 (UTC)[reply]
Support and comment: I like the idea of consolidating {{der3}} and {{rel3}} and their compatriots. Like @CodeCat, I also don't see any need for two separate templates for Derived and Related terms, unless they are differentiated in some way.
However, perhaps the number of columns should also be based on the length of the words and the size of the user's screen (or more specifically the size of the bodyContent area). If there are a lot of words, but some of them are very long, then there should be fewer columns to accommodate this. And if the user is on a smartphone, or happens to be using less of their screen, it would be nice if there were fewer or no columns. If the module decides to use four or five columns, but the words are long, or the content area is narrow, then the text box will display with a scroll bar, which is sub-optimal. However, I'm not much of a programmer, and don't know how easy or costly it would be to implement these features.
Another thing to be fixed: {{der3}} displays the Greek word in italics in the header. Instead it (or its successor) should display it the way {{m}} would display the term. — Eru·tuon22:16, 8 April 2016 (UTC)[reply]
Hmm, another idea: perhaps the template could also decide whether to create a collapsible box at all, based on the number of entries. Then a Derived forms section with just a few entries would display without a box, but if there are more than a certain number of entries, the box will appear. That would also remove the necessity of deciding whether to put Derived or Related terms in a bulleted list or to use a column template: you just always use the template.
However, using a bulleted list has a benefit: you can provide glosses and genders or create a tree showing derivation. — Eru·tuon22:22, 8 April 2016 (UTC)[reply]
For this last reason I think the people above are right, the template should accept the entire list as one parameter, rather than each one separately. As for deciding the number of columns, that should really be done client-side, because server-side Lua modules can't determine how wide text will be. —CodeCat22:40, 8 April 2016 (UTC)[reply]
To repeat what @CodeCat and I said above, the reason is so that you can present a tree of derived forms or classify them in some way, and perhaps provide translations for each term. You can't do that when each word is a parameter. I just did this at φαίνω. — Eru·tuon02:06, 13 April 2016 (UTC)[reply]
@Erutuon: Use {{l}} if you need a translation, whether it is inside a parameter or not. Making a parameter of list items just improves processing and does not hinder. – Chokladkaka (talk) 07:09, 14 April 2016 (UTC)[reply]
@Chokladkaka: Well, here's the portion from φαίνω(phaínō) that I was referring to. To be honest, I might be the first person to use derivational trees in Derived terms sections, and not sure if it's an acceptable practice (though I think it makes the list easier to understand). But basically, terms are bulleted and terms that derive from another term are indented one more than that term. — Eru·tuon07:34, 14 April 2016 (UTC)[reply]
@Erutuon: I like the idea of using derivational trees. I think more entries could use them if there were just a standard way to do it. I think the proper way to do it is to use nested templates (instead of nested lists). That way we can specify in a machine readable way how the branches of the tree are related to the trunk of the tree. It would require some discussion though to come up with the format. – Chokladkaka (talk) 07:53, 14 April 2016 (UTC)[reply]
@Erutuon: I change my mind about nested templates. I think it would be better to make it more human readable by simply having one template, giving it all related terms as separate arguments, and prefixing entries with * just like when making a list, to indicate that they belong to a deeper level of the tree. A top level term would then start with | and nested entries would start with |*, |** and so on. It's like an ordinary list, and the difference is just that the first * is replaced by |. – Chokladkaka (talk) 09:42, 14 April 2016 (UTC)[reply]
@Erutuon: Now I'm unsure about having trees in related terms. I just made a tree of hyponyms for Gebäck(“pastry”). It's quite daunting to see. Maybe it would be better to remove all indirect hyponyms and just have a flat list of direct hyponyms. – Chokladkaka (talk) 13:56, 14 April 2016 (UTC)[reply]
@Chokladkaka: Yeah, the list there is pretty hard to read. I think the hyponyms could be limited to a couple levels of derivation, or alternatively only the most common ones could be listed. That's what I did at φαίνω(phaínō) with the derivatives of the combining form -φανής(-phanḗs), most of which are pretty uncommon.
Aha, there we go. That's better, though could you make a way to create a bullet point with plain text, no link (so that the textwith prepositional prefixes and suffixed can be used to categorize the list items)? — Eru·tuon00:55, 16 April 2016 (UTC)[reply]
I agree that the template should also decide automatically whether to create a collapsible box at all. The purpose of the template is precisely to eliminate decisions and guesswork by the editor of each page and introduce the possibility to consider the preference of the user viewing the page. Right now I avoid editing lists of related terms, because I do not know when to make a list, when to use a template instead and which template to use. Chokladkaka (talk) 08:01, 9 April 2016 (UTC)[reply]
Re: Red "D" delete button no longer works in recent changes[edit]
This issue was pointed out almost a year ago, and is still the case: [1]. Can we just hide the red "D" at this point? I don't know where to find the code, or I could probably manage it myself. Equinox◑06:40, 9 April 2016 (UTC)[reply]
Strange, I no longer see the D button, but I still see the deletion reason box at the bottom right, even though I commented out that part after you. --WikiTiki8921:51, 21 April 2016 (UTC)[reply]
And I don't see it anymore. Maybe it just takes a while to kick in (although I don't know why that should be the case). --WikiTiki8921:54, 21 April 2016 (UTC)[reply]
I turned off per-browser preferences a while ago because some of the gadgets were buggy, but they keep turning back on, and I keep on having to go back to the page again to turn them off. I'm always using the same browser (Chrome) on the same computer. Is there a way to keep them from turning on? It's really annoying. — Eru·tuon19:25, 9 April 2016 (UTC)[reply]
I untick the box that says "Replace text in deletion log comment" and it lasts for about a minute then reverts to the way it was - annoying. Can anything be done? SemperBlotto (talk) 08:00, 12 April 2016 (UTC)[reply]
It's acting stranger now. The preferences are working (and turned off) when I'm on my watchlist, but not working (and on) when I'm editing this page. — Eru·tuon08:35, 13 April 2016 (UTC)[reply]
fr-conj-auto failure on nourrir and other -rir[edit]
Apparently fr-conj-auto puts nourrir in the labiodental + -rir group instead of the second group -ir verbs (where it's supposed to go) for some extremely odd reason. Mglovesfunbot put in fr-conj-auto recently... Hillcrest98 (talk) 02:29, 10 April 2016 (UTC)[reply]
I finally got around to looking further into some of the edittools annoyances. In the process, I tracked down the likely cause of the problem I ran into some months ago, where &13; newlines in <charinsert> sections suddenly became � (Unicode character �) -- the underlying cause seems to be an update in the charinsert MW extension.
The documentation still says to use to insert newlines, but this is clearly non-functional.
I tried using instead, but charinsert doesn't seem to support this fully -- it will insert, but <nowiki> does not suppress autoindentation and numbering or bullets when using # and * in charinsert strings. For example:
@Yair rand, CodeCat and anyone else with the technical know-how: is it possible to edit {{findetym}} or the modules it invokes so that it will categorize into "inherited from" categories rather than (or in addition to) "derived from" categories? —Aɴɢʀ (talk) 20:02, 10 April 2016 (UTC)[reply]
In my sandbox, I based {{ha-verb}} loosely on {{lv-noun}}. (Hausa verbs are categorized by grades; the asterisk is for irregular grade verbs and rare grade verbs.) If anyone would like to give me some assistance, that's good. --Lo Ximiendo (talk) 23:27, 12 April 2016 (UTC)[reply]
I don't know about you but I often find myself copying the title of a page to the search bar changing a little thing (a typo often times) and searching again. So, just in case you face the same issue often and want to ease your life add this to your common.js
One thing though: You should have it fetch the actual title of the page when you first click on it, because in some cases it's not the same as what is displayed. I found two different examples of this so far: At Special:Watchlist, the displayed title is just "Watchlist". When editing a page or viewing a diff, extra text is added to the title. --WikiTiki8919:47, 15 April 2016 (UTC)[reply]
@Wikitiki89, autocompletion is now possible. The code got a little bigger and more prone to change so it is probably best to import script User:Dixtosa/editAndGo.js. --Dixtosa (talk) 21:23, 5 November 2016 (UTC)[reply]
WebRef bookmarklet and RefTag citation tools?[edit]
Hello! I'm wondering if there is a Wiktionary version of two tools that are useful for contributing citations to citation tabs.
The Wikipedia-formatted versions are:
WebRef bookmarklet https://en.wikipedia.org/wiki/User:V111P/js/WebRef - you install the code snippet as a bookmark in your browser, surf to the webpage you want to cite, highlight the quote you want to cite, and click the bookmarklet. It pops up a textedit panel that has the wikicode for the citation. I'm looking for something similar where the wikicode is in the style of a Wikitionary Citations:for_some_word page.
Google books tool http://reftag.appspot.com/ - you take the Google book URL of the book you want to cite and it builds the citation wikitext for you in the form of quote book template. Example:
Given a Google books URL like:
http://books.google.com/books?id=ZagUswEACAAJ
...the tool would give:
*{{quote-book
|year=2016
|author=Dan Lyons
|title=Disrupted: My Misadventure in the Start-Up Bubble
|url=http://books.google.com/books?id=ZagUswEACAAJ
|isbn=9780316306089
|page=
|publisher=Hachette Books
|passage=
}}
Basically any edit after the database was unlocked and before 15:10 UTC isn't showing up there (the database was locked at 14:01 I presume and unlocked sometime between 14:47 and 14:51). --WikiTiki8915:18, 19 April 2016 (UTC)[reply]
Indicating two third-person singular simple present forms using "en-verb"[edit]
The word sgraffito has two possible third-person singular simple present forms: sgraffitoes and sgraffitos. Is it possible to indicate this using {{en-verb}}? There's nothing in the documentation about this. — SMUconlaw (talk) 15:58, 19 April 2016 (UTC)[reply]
The documentation is pretty badly out of date, but it's in part because a change was cut short by other editors half way through and it was just left hanging. To specify a second present form, use pres_3sg2=. —CodeCat16:21, 19 April 2016 (UTC)[reply]
Thanks. Hope the documentation can be updated soon! Because the template uses Lua (which I have no clue about), there's no way to figure out what the parameters are by looking at the wikitext source. — SMUconlaw (talk) 16:54, 19 April 2016 (UTC)[reply]
I have been finding this character randomly included in dates and quotations on various pages. Does anyone know where it is coming from? Does it serve any useful purpose on this wiki or can I just replace them all? - TheDaveRoss15:28, 20 April 2016 (UTC)[reply]
That is the character, as far as I know. An example is gouda, |date=Apr 8, 2009| becomes \u007c\u0064\u0061\u0074\u0065\u003d\u200e\u0041\u0070\u0072 \u0038\u002c \u0032\u0030\u0030\u0039\u007c when converted to unicode codepoints. I combined the date and year parameters and that extraneous character causes a parser error. - TheDaveRoss15:35, 20 April 2016 (UTC)[reply]
Looking at the page histories, do the additions have anything in common? (For example, could they be the citations listed automatically by User:Walled gardener and then manually added to entries by users?) Equinox◑16:52, 20 April 2016 (UTC)[reply]
I would say that it's totally unnecessary in any text that doesn't include both a right-to-left script such as Arabic/Persian/Urdu or Hebrew/Aramaic and a left-to-right script. If the text contains both types of scripts, it's only needed where both are present next to each other. It has no reason whatsoever to be in entry names, as far as I can tell (perhaps if there were an entry name with mixed scripts, but I don't think we've ever done that), and there's no need for it in the context you mentioned
If there were mixed scripts in a document, I can see how word-processing software might add this character to everything, just to be on the safe side: for most uses, it does no harm, since it's invisible, but it could prevent all kinds of text-order weirdness if left-to-right and right-to-left scripts happen to end up on the same line. If text were copypasted from such a document, this character would be included. Chuck Entz (talk) 01:21, 21 April 2016 (UTC)[reply]
This character is included in the timestamps on history pages (by the framework itself, I think, for whatever reason). When these timestamps are copy-and-pasted, it goes along with them. --WikiTiki8915:51, 21 April 2016 (UTC)[reply]
Because (1) it is nice to have all unsupported titles and real titles together at one place; and (2) with this way we can also replace titles on the history pages; and (3) it works? --Dixtosa (talk) 19:10, 25 April 2016 (UTC)[reply]
Wikimedia Individual Engagement grant: A graphical and interactive etymology dictionary based on Wiktionary[edit]
I have submitted an IEG proposal and need your feedback. This is the link to the grant proposal, and this is the demo of the visualization. The aim of the project is to visualize the etymological tree of words using data from Wiktionary and an interactive tool. If you think the project is interesting and feasible, and or if you feel you would like to volunteer, please post at the end of the new grant pagehere.
The interactive web page uses d3.js - a JavaScript library for manipulating documents based on data - where you search a word and then you visualize the etymological tree of the word (ancestors, cognates, on the same tree). Right now I have only developed a demo for 10 words (the graphical interface needs some polishing still) and I am developing a java code based on dbnary to extract etymological relationships from Wiktionary.
More precisely, for interested users only, the output of the java extractor is an rdf file (a sample is available here) that I will query to identify etymological trees. Once I have extracted etymological trees, I plan on writing a JSON file of the tree that I will feed to the javascript code that uses d3.js to create an interactive web page. I am discussing with the Multimedia team what is the best way to integrate this into Wikimedia and they suggested two alternatives: either making this a parser extension (i.e. you type <etygraph> and then a bunch of JSON data, and then </etygraph>, which creates the graph) or a parallel namespace which will simplify the data storage part.
A screenshot of the etymological tree of the English word 'butter' as produced by 'etytree'
Please contribute to the grant proposal with a comment if you think it is interesting. -- Epantaleo
The first line is a module which sets an additional frame argument 'form', then reads the frame arguments out into a string.
The second line is another module which manually creates a table 'args', setting the same values to the same keys.
In both cases args['form'] works correctly, but only in the second case does the pairs() function seem to recognize that the value 'form' has been set.
(Edit conflict) If you're looking specifically to process template arguments, you may find Module:parameters useful. In the general case (which is what that module does internally), you create a new empty table, and then go over the args with pairs, copying each value over to the new table. —CodeCat19:54, 25 April 2016 (UTC)[reply]
Problems with mobile site when rendering tables with show/hide functionality[edit]
Specific tables, those that implement the show/hide features from the ===View Switching=== section of MediaWiki:Gadget-legacy.js, do not render correctly when viewed in the mobile version of the Wiktionary website (https://en.m.wiktionary.org/). I had previously assumed it was a problem with my phone's browser, but I have since confirmed that it actually seems to be in the mobile site itself.
View, for example, the conjugation table at verdedigen. This exhibits some nice collapsing behavior -- when the page is first loaded, the table shows just the minimum of useful information. When the user clicks more ▼, the summary header disappears, to be replaced with the full conjugation paradigm. The user can click less ▲ to toggle back to the minimal table format.
Meanwhile, the mobile version of this same page at https://en.m.wiktionary.org/wiki/verdedigen shows the entire behind-the-scenes table content, with the minimal table header displayed as the first three rows of table content, after which we have the full conjugation paradigm. This is a bit confusing, as the first three rows duplicate information found elsewhere in the table, with the infinitive appearing twice just in the header. We also have no more ▼ or less ▲ to click on, suggesting that JavaScript either hasn't loaded for some reason, or is disabled outright.
Screenshots
Mobile site viewed in iOS phone browser
Mobile site viewed in Chrome on Win 7
I don't understand enough of how our site infrastructure works to be effective in resolving this problem. I'd greatly appreciate it if someone savvier could have a go at a fix. ‑‑ Eiríkr Útlendi │Tala við mig21:04, 28 April 2016 (UTC)[reply]
The bizarre thing is that the "minimum" table rows have the vsShow CSS class, and in MediaWiki:Common.js this is set to be hidden by default. So a browser with no JS support should never show the minimum table rows, only those belonging to the full table. —CodeCat21:09, 28 April 2016 (UTC)[reply]
Mobile devices do have JS support. The difference is the MediaWiki framework serves up different CSS and JS for the mobile site. The problem is most of our custom CSS and JS is not included in that, because none of us bother to take it into account. --WikiTiki8921:20, 28 April 2016 (UTC)[reply]
@Eirikr: I tested the Module:hu-nominals changes in three browsers (Firefox, Chrome, and Safari) on a desktop computer. The first issue is that the main declension table width no longer matches the possessive table which is immediately below the main declension table. The second, bigger issue is that because of the fixed width, long words are simply chopped off and there is no way to horizontally scroll to see the end of the right side in the second column. Take a look at one of the longer words such as bányaszerencsétlenség. It's interesting that the horizontal scroll bar disappeared from both tables. I'm not sure how to resolve this, but I'd be curious to know why you picked Hungarian, it's not listed in your Babel box. :) --Panda10 (talk) 17:55, 9 May 2016 (UTC)[reply]
Ah, yes, I'm reminded why I didn't suggest that before -- with min-width, the table stretches across the whole page. I inferred from the previous hard-coded width values that this was possibly undesirable. I don't have any specific problem with it, but folks should have a look and comment / edit as deemed appropriate.
I just noticed that the Hungarian tables are using the old system, the one with wrapping divs. That system isn't capable of taking the width of the contents of the table into account, so you're stuck with either a fixed width or a percentage. I'll work on converting it to the new system now. —CodeCat23:42, 9 May 2016 (UTC)[reply]
Cheers! One note -- would it be possible to add a couple pixels of padding to the left and right of the listed terms? Things look a bit squished in the two tables at bányaszerencsétlenség, for instance, squished enough to be a bit hard to read on the most-crowded rows. ‑‑ Eiríkr Útlendi │Tala við mig00:07, 10 May 2016 (UTC)[reply]
That's normal. If you can read Hungarian words line "bányaszerencsétlenség", you shouldn't have any problem with the padding. —CodeCat00:09, 10 May 2016 (UTC)[reply]
There's shouldn't, and there's don't, and those two don't always align. If you're saying you won't make the change yourself, I may have a go later: the current layout presents a sub-optimal usability experience. ‑‑ Eiríkr Útlendi │Tala við mig00:29, 10 May 2016 (UTC)[reply]
It was a bit of a joke. I was saying that if you can read the jumble of letters that is Hungarian, then surely you have no problem with a bit of padding. :p —CodeCat01:23, 10 May 2016 (UTC)[reply]
@CodeCat: Actually, the content in the tables is the same width. When I open both tables, they jump to the same size (not an exact size, but very close). --Panda10 (talk) 18:50, 10 May 2016 (UTC)[reply]
Expanding the tables changes the content, though, doesn't it? Browsers determine the width based on what's visible, so when the forms are hidden, they no longer "count" towards the width. What's left is the single table cell at the top of the table. —CodeCat19:04, 10 May 2016 (UTC)[reply]
Could min-width be used to good effect here? It's a minor aesthetic issue, but having both tables the same width when closed and when open would present a cleaner interface. ‑‑ Eiríkr Útlendi │Tala við mig19:12, 10 May 2016 (UTC)[reply]
It could, yes. It's what I had in mind originally. However, a more practical solution might be to just integrate both tables into one? —CodeCat19:15, 10 May 2016 (UTC)[reply]
@CodeCat: When I look at Leonardo, the content of the single table cell at the top is much shorter than the table width, but I've just double checked and I think {{hu-decl-table}} is still having the old structure. Maybe that's caused my confusion. Is this something that would need updating, as well? About combining the two tables: It's a possibility, but it would be a huge table, might be too confusing for a student of the language. --Panda10 (talk) 19:23, 10 May 2016 (UTC)[reply]
I noticed you re-added the "of PAGENAME" bit to the table. I think it's kind of redundant, that's why I removed it. —CodeCat21:56, 10 May 2016 (UTC)[reply]
Unfortunately, setting min-width will not make the two tables the same width again. I am thinking now that the only solution is to change both tables to full length. The increased real estate will also allow to add the case names in Hungarian after the English. I've seen this done at other languages. As for the possessive tables, I've found an interesting structure in Quechua, see patacha. This table within table would eliminate the need to add declension tables to each possessive sublemmas. --Panda10 (talk) 14:00, 11 May 2016 (UTC)[reply]
Autoexpand various elements and templates on page load[edit]
Is there a way for me to auto-expand (or prevent the collapse of) more of the various collapsed elements? I'm particularly interested in the "Quotations" and "Derived terms" elements, e.g. -pathy has 3 "quotations" elements and a "derived terms" section. I'd like to read these parts without having to click anything.
I tried experimenting in my common.js, and managed to get the {{suffixsee}} "Derived terms" section to open automatically, but I cannot figure out how to work it for the Quotations elements... Can anyone help? Thanks! Quiddity (talk) 04:18, 29 April 2016 (UTC)[reply]
At [2] you see a function that fetches a page from the wiki (Reconstruction:Proto-Germanic/fuhsaz in this case) and searches for a string. It then displays 20 characters from the point where the string is found. This works ok, it finds the Descendants header correctly and shows the characters. But while it has no problem finding the header with the equals signs after the name, I'm not able to search for the equals signs before the name. The search string =Descendants turns up nothing, even though it's quite obviously on the page. Does anyone know what's going on? Am I missing something obvious? —CodeCat00:02, 30 April 2016 (UTC)[reply]
This is oddly similar to a problem I was dealing with, where it turns out that the <poem> tag replace the content with some kind of unique id (and this happens before being passed to a template). For example, {{code||<poem>foo</poem>}} produces '"`UNIQ--poem-00000014-QINU`"'. --WikiTiki8919:45, 10 May 2016 (UTC)[reply]
I created this template as a simpler alternative to {{etymtree}}. It fetches the contents of another page and transcludes the descendants onto the current page. It works well, see *tréyes for an example. However, the software doesn't seem to like recursive transclusion of the same template. So when one of the transcluded descendants uses this template itself, an error shows up. This appears in the Italic section, since the Proto-Italic page *trēs uses {{desctree}} to transclude all the Latin descendants. Is there a way around this? —CodeCat16:37, 30 April 2016 (UTC)[reply]
Fixed: diff. --WikiTiki89 01:13, 6 April 2016 (UTC)
Support --Giorgi Eufshi (talk) 07:28, 14 April 2016 (UTC)
Done —Μετάknowledgediscuss/deeds 19:49, 10 April 2016 (UTC)
