Wiktionary:Grease pit/2016/April

From Wiktionary, the free dictionary
Jump to navigation Jump to search

Hiders

[edit]

In my computer hiders do not operate - key "show" does not exists and I can't open them. Please, correct it. Sic dixi REX NIGER 10:27, 2 April 2016 (UTC)[reply]

Do you have JavaScript disabled? -Xbony2 (talk) 11:34, 2 April 2016 (UTC)[reply]
I don't know. How can I find it? Sic dixi REX NIGER 14:13, 2 April 2016 (UTC)[reply]
Check here. -Xbony2 (talk) 14:25, 2 April 2016 (UTC)[reply]
Yes, Javascript is enabled! Sic dixi REX NIGER 14:49, 2 April 2016 (UTC)[reply]
What "hiders" are broken? Like here? -Xbony2 (talk) 16:11, 2 April 2016 (UTC)[reply]
adjoining screenshot
Yes, like there and like here. Sic dixi REX NIGER 17:11, 2 April 2016 (UTC)[reply]
Clear the cache and cookies. I would tell you how if you were not using Yandex browser :D--Dixtosa (talk) 17:22, 2 April 2016 (UTC)[reply]
Thank you, it helps. Sic dixi REX NIGER 19:55, 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. —CodeCat 12: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. DCDuring TALK 13:56, 3 April 2016 (UTC)[reply]

Borrowing template

[edit]

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 French incendie and Italian incendio and Latin incendium. [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:
Ungoliant (falai) 16:17, 2 April 2016 (UTC)[reply]
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]
Should we pick up that discussion in earnest? —CodeCat 12:59, 3 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/deeds 17:44, 2 April 2016 (UTC)[reply]

Would simply modifying {{l}} and {{m}} to generate links starting with : fix the issue? (I don't know.) - -sche (discuss) 18:05, 2 April 2016 (UTC)[reply]
It appears to work in the main namespace but not elsewhere: /ameeni, /ameeni DTLHS (talk) 18:16, 2 April 2016 (UTC)[reply]
I should've tested that. I still think it should work everywhere, though. —Μετάknowledgediscuss/deeds 18:43, 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]
I've never come across a language that does this before, but there's also /b/tard in English (and quite possible more terms that we haven't documented yet). —Μετάknowledgediscuss/deeds 19:58, 2 April 2016 (UTC)[reply]

Russian Church Slavonic

[edit]

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]

This is more of a Beer Parlour issue, since the real question is whether we want to have these. User:Ivan Štambuk probably has some opinions about it. --WikiTiki89 04:02, 3 April 2016 (UTC)[reply]
Church Slavonic has several recensions (separate sets of phonological rules). I think this would make it more complicated. --KoreanQuoter (talk) 04:58, 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]
The differences are much greater, though. Lots of words are spelled differently. —CodeCat 12:55, 3 April 2016 (UTC)[reply]

Would it be possible to split this category by Language? Or, at least, to split off the English entries? SemperBlotto (talk) 08:37, 3 April 2016 (UTC)[reply]

And limit the namespaces to main and reconstruction. {{plural of}} should not be included! Renard Migrant (talk) 12:11, 5 April 2016 (UTC)[reply]

{{lb|fro|Old Northern French}} should categorize

[edit]

In Category:Old Northern French (not Category:Old Northern French Old French). And I no longer know how to do that. Renard Migrant (talk) 12:01, 5 April 2016 (UTC)[reply]

Trouble loading MediaWiki:Common.css

[edit]

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? --WikiTiki89 19:51, 5 April 2016 (UTC)[reply]

Sometimes instead of getting stuck, the whole page turns blank. --WikiTiki89 00:03, 6 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. --WikiTiki89 15:03, 8 April 2016 (UTC)[reply]
Deleting my person JS and CSS did not fix the problem, so it must be a gadget I have enabled. --WikiTiki89 15:12, 8 April 2016 (UTC)[reply]
The culprit is the "Make wikilinks inside JavaScript, Lua and CSS comments clickable" gadget. --WikiTiki89 15:19, 8 April 2016 (UTC)[reply]
Thanks for resolving it and thanks for letting us know. DCDuring TALK 15:28, 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. --WikiTiki89 17: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.
You are welcome.--Dixtosa (talk) 18:23, 10 April 2016 (UTC)[reply]
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. --WikiTiki89 14:42, 11 April 2016 (UTC)[reply]

Customizing CharInsert

[edit]

I tried to use the instructions on the Wikipedia page on CharInsert to create a custom menu in my common.js, but it doesn't seem to work. Is this functionality not available on Wiktionary, or did I do something wrong? — Eru·tuon 22:01, 5 April 2016 (UTC)[reply]

You might find this useful.--Giorgi Eufshi (talk) 07:32, 6 April 2016 (UTC)[reply]
@Giorgi Eufshi: Hmm, thanks for the suggestion. Just tried it, but it doesn't work. Is it current or outdated? — Eru·tuon 02:45, 7 April 2016 (UTC)[reply]

{{nap-conj}} table formatting

[edit]

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]

Fixed: diff. --WikiTiki89 01:13, 6 April 2016 (UTC)[reply]

Sorting in Module:columns

[edit]

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·tuon 02:54, 7 April 2016 (UTC)[reply]

I set it to use the sort key as defined in the languages module. Does it produce the correct sorting now? DTLHS (talk) 03:14, 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·tuon 03:26, 7 April 2016 (UTC)[reply]
OK, added that as well. DTLHS (talk) 03:30, 7 April 2016 (UTC)[reply]
Great! Looks right now. Thanks a ton! — Eru·tuon 03:33, 7 April 2016 (UTC)[reply]

Replace table markup with {{der4}}

[edit]

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.

For examples of what I have already started, see: kvinna, pojke, silver, symbol, musik

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?

Chokladkaka (talk) 02:27, 8 April 2016 (UTC)[reply]

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]

special:diff/37981044--Giorgi Eufshi (talk) 10:42, 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.

Usage example code:

{{derived terms|lang=de
| Golfkrieg
| Golfkrise
| Golfmonarchie
| Golfregion
| Golfstrom
}}

More examples at User:Chokladkaka/Sandbox.

I would like to get feedback on anything that needs to be changed, and then ask for approval to begin to use these templates.

Chokladkaka (talk) 20:19, 8 April 2016 (UTC)[reply]

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? —CodeCat 20: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). --WikiTiki89 20: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]
@Chokladkaka: On the contrary, if you look at {{col-top}} and {{col-bottom}}, you will see that they are auto-balancing and work without any kind of {{col-mid}} template. --WikiTiki89 22:28, 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. --WikiTiki89 15: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. - TheDaveRoss 20: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·tuon 22: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·tuon 22: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. —CodeCat 22:40, 8 April 2016 (UTC)[reply]
@CodeCat: Why would the list have to be one parameter? See the example code I added above and at User:Chokladkaka/Sandbox. It looks just like a list, except you start each line with “|” instead of “*”. – Chokladkaka (talk) 08:37, 9 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·tuon 02: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: I'll try that, I guess. Still, no way to do derivational trees. — Eru·tuon 07:17, 14 April 2016 (UTC)[reply]
@Erutuon: I'm not familiar with how derivational trees are formatted. Could you please give me links to a couple of examples? – Chokladkaka (talk) 07:23, 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·tuon 07: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.
Adding asterisks to {{der3}} doesn't seem to work: it just displays asterisks, and doesn't create a nested list. — Eru·tuon 00:45, 15 April 2016 (UTC)[reply]
@Erutuon: {{der3}} is the old template I want to get rid of. The new template I propose supports adding one asterisk. See User:Chokladkaka/Sandbox#Example_with_nested_items. – Chokladkaka (talk) 05:24, 15 April 2016 (UTC)[reply]
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·tuon 00: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]
I just changed the module to make the box collapsible only when there are more than 8 list items. I put some usage examples above and at User:Chokladkaka/Sandbox. – Chokladkaka (talk) 08:37, 9 April 2016 (UTC)[reply]
Support --Giorgi Eufshi (talk) 07:28, 14 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]

Well, I found the code: MediaWiki:Gadget-PatrollingEnhancements.js. I have commented out the part that adds the D button. I notice no difference; perhaps some kind of cache purge is required? Equinox 21:38, 21 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. --WikiTiki89 21: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). --WikiTiki89 21: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·tuon 19:25, 9 April 2016 (UTC)[reply]

@Yair rand: Did you break something? --WikiTiki89 14:41, 11 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]

Is this perhaps related to the bug User:Erutuon reported above? —CodeCat 13:38, 12 April 2016 (UTC)[reply]
And is it related to WT:Grease pit/2016/March#WT:PREFS cookies? Chuck Entz (talk) 13:51, 12 April 2016 (UTC)[reply]
I don't understand exactly what broke it, but I've reverted my recent changes to the PREFS script. Is the issue fixed now? --Yair rand (talk) 15:43, 12 April 2016 (UTC)[reply]
Nope. SemperBlotto (talk) 08:12, 13 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·tuon 08:35, 13 April 2016 (UTC)[reply]

fr-conj-auto failure on nourrir and other -rir

[edit]

Complaint in tea room: Wiktionary:Tea room#French nourrir

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]

It's even worse - all miscellaneous -rir verbs are thrown into the ouvrir group for absolutely no rhyme or reason; they all should be second-group. Hillcrest98 (talk) 18:29, 11 April 2016 (UTC)[reply]

Problems in charinsert MediaWiki extension

[edit]

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 &#xfffd;) -- the underlying cause seems to be an update in the charinsert MW extension.

The documentation still says to use &#13; to insert newlines, but this is clearly non-functional.

I tried using &#10; 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:

<charinsert><nowiki>text&#10;#&#32;other&#32;text</nowiki></charinsert>

renders as:

text

  1. other text

The <nowiki> tags should suppress the linebreak and numbering, but it's clearly not working correctly.

An alternative possibility is that something changed in how MediaWiki renders?

Questions:

  1. Who do I talk to to find out if the cause is in charinsert or in MW rendering?
  2. Where would I look for past related bugs?
  3. Where would I file a bug report for this?

TIA, ‑‑ Eiríkr Útlendi │Tala við mig 05:47, 10 April 2016 (UTC)[reply]

"Where would I file a bug report for this?" Maybe Phabricator. —suzukaze (tc) 03:40, 11 April 2016 (UTC)[reply]

Old Hindi

[edit]

Can Old Hindi be made into a full fledged mainspace language with code ohi (not taken by any other language so far)? See WT:Beer Parlour#Old Hindi for discussion. —Aryamanarora (मुझसे बात करो) 15:23, 10 April 2016 (UTC)[reply]

As discussed before, we don't assign codes that ISO could potentially assign. It'll have to be inc-ohi. —Μετάknowledgediscuss/deeds 17:23, 10 April 2016 (UTC)[reply]
Also, before it's added: what translit module should it use? —Μετάknowledgediscuss/deeds 17:27, 10 April 2016 (UTC)[reply]
MOD:sa-translit, please. Script is Deva, of course. —Aryamanarora (मुझसे बात करो) 19:29, 10 April 2016 (UTC)[reply]

Inherited terms using findetym

[edit]

@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]

The module uses the {{etyl}} template. Is a different template supposed to be used for inherited terms? If so, should it always use it? --Yair rand (talk) 20:44, 10 April 2016 (UTC)[reply]
Direct inheritances are now supposed to use {{inh}}, which categorizes as Angr mentioned. Benwing2 (talk) 00:42, 11 April 2016 (UTC)[reply]

ha-verb as inspired by lv-noun

[edit]

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]

Editable title

[edit]

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

$(function() {
	$("#firstHeading").prop("contenteditable", "true");
	$('#firstHeading').keypress(function (e) {
		var key = e.which;
		if(key == 13) {
			window.location = "https://en.wiktionary.org/w/index.php?search=" + $('#firstHeading').text() + "&title=Special%3ASearch&go=Go";
			return false;
		}
	});
});

The script makes entry's title area editable. Hit enter to search the modified title. --Dixtosa (talk) 18:38, 15 April 2016 (UTC)[reply]

You just made me so happy!!!! --WikiTiki89 18:41, 15 April 2016 (UTC)[reply]
Swell. - TheDaveRoss 18:54, 15 April 2016 (UTC)[reply]
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. --WikiTiki89 19:47, 15 April 2016 (UTC)[reply]
And it would also be nice if it could load search suggestions. --WikiTiki89 19:59, 15 April 2016 (UTC)[reply]
Then copying the title directly to the search box would make more sense for you. This is what you want
$(function() {
	$("#searchInput").val(mw.config.values.wgPageName);
});
--Dixtosa (talk) 20:14, 15 April 2016 (UTC)[reply]
Yeah I guess. But it's not as cool as editing the title. --WikiTiki89 20:36, 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]
Ooh, really nice! I do that a lot too. Thanks so much! — Eru·tuon 20:15, 15 April 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:

  1. 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.
  2. 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= }}

Thanks! SageGreenRider (talk) 11:37, 16 April 2016 (UTC)[reply]

The Quiet Quentin gadget can do something kindof similar to #2. —suzukaze (tc) 11:39, 16 April 2016 (UTC)[reply]
Thanks! That's helpful. Is there a way to make it output structured data in the {{quote-book}} template rather than a single, flatten text string?

It froze. --Romanophile (contributions) 15:10, 19 April 2016 (UTC)[reply]

Was just about to say the same thing. --WikiTiki89 15:10, 19 April 2016 (UTC)[reply]
Jolly. Notice how largo a isn’t anywhere to be seen. --Romanophile (contributions) 15:11, 19 April 2016 (UTC)[reply]
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). --WikiTiki89 15: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=. —CodeCat 16: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]

{{lb|li|Maastrichtian}}

[edit]

For some reason (page caching?), this isn't linking to Maastrichtian like it should be, even though the relevant code is in Module:labels/data/subvarieties. KarikaSlayer (talk) 19:05, 19 April 2016 (UTC)[reply]

Module:labels/data/subvarieties is not called upon by anything. I've moved the Maastrichtian label and protected that page against further additions. - -sche (discuss) 19:22, 19 April 2016 (UTC)[reply]

Unicode character \u200e

[edit]

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? - TheDaveRoss 15:28, 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]
We encountered some other problems caused by stray left-to-right and right-to-left marks last year, and I proposed removing them all (or most of them) by bot or AWB. They also cause display problems. Here are old lists of pages containing them: Wiktionary:Todo/Pages containing LTR marks, Wiktionary:Todo/Pages containing RTL marks. They can safely be removed from most contexts, as Chuck says. PS another character which randomly, inappropriately shows up and should be checked for and removed (especially from page titles!) is the soft hyphen. - -sche (discuss) 04:42, 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. --WikiTiki89 15:51, 21 April 2016 (UTC)[reply]

Unsupported titles in MediaWiki:Common.js

[edit]

Instead of maintaining the map at MediaWiki:Common.js, why not create a simple template placed at the top of each unsupported title entry that will tell the JS what to replace the title with. --WikiTiki89 21:27, 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]
(1) Why? (2) Good point. (3) But it requires editing MediaWiki:Common.js every time a new unsupported title is created, while MediaWiki:Common.js should really be modified as rarely as possible. Can we at least move the list to something like MediaWiki:UnsupportedTitles.js? That would solve half of my problem with it. --WikiTiki89 19:22, 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 page here.

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

Lua frame arguments

[edit]

Something seems to be broken.

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.

What am I missing? —ObsequiousNewt (εἴρηκα|πεποίηκα) 18:31, 25 April 2016 (UTC)[reply]

The args table has a metatable set on it, so it's not a regular table of values the way you're used to. —CodeCat 18:38, 25 April 2016 (UTC)[reply]
If you need to modify the args table, as I have had to do numerous times, I recommend just making a copy of it. --WikiTiki89 18:52, 25 April 2016 (UTC)[reply]
How is that done? —ObsequiousNewt (εἴρηκα|πεποίηκα) 19:50, 25 April 2016 (UTC)[reply]
Iterate over it and copy the results into a new table. DTLHS (talk) 19:54, 25 April 2016 (UTC)[reply]
(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. —CodeCat 19:54, 25 April 2016 (UTC)[reply]
(e/c)
local args = {}
for key, value in pairs(frame:getParent().args) do
    args[key] = value
end
You can even take the opportunity to filter out blank arguments:
local args = {}
for key, value in pairs(frame:getParent().args) do
    if value ~= "" then
        args[key] = value
    end
end
--WikiTiki89 19:55, 25 April 2016 (UTC)[reply]
But, as I have just demonstrated, using pairs() doesn't work Ah, I see—it will work for the values that have already been set. Thanks. —ObsequiousNewt (εἴρηκα|πεποίηκα) 20:00, 25 April 2016 (UTC)[reply]

Wiktionary:Beer parlour and onlyinclude

[edit]

It looks like somehow my use of "onlyinclude" tags in Wiktionary:Beer parlour/2016/April#Cascading protection of the main page, despite being wrapped in "nowiki" tags, is preventing the April 2016 BP page from being transcluded properly onto the main WT:BP page. Anyone know how to fix this? --WikiTiki89 20:23, 27 April 2016 (UTC)[reply]

Did this do the trick? If not, I'm out of ideas. —Aɴɢʀ (talk) 20:53, 27 April 2016 (UTC)[reply]
Yes it worked (can't you see for yourself?). But I'm still curious what the problem was in the first place. --WikiTiki89 21:09, 27 April 2016 (UTC)[reply]
My guess is that onlyinclude tags get interpreted before nowiki tags do? —CodeCat 21:19, 27 April 2016 (UTC)[reply]
Yeah it seems so. Is it a bug? I think I had intended to write "includeonly" anyway. --WikiTiki89 21:21, 27 April 2016 (UTC)[reply]
Looks like it's working as intended (as counterintuitive as it sounds). KarikaSlayer (talk) 13:14, 28 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.

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ð mig 21: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. —CodeCat 21: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. --WikiTiki89 21:20, 28 April 2016 (UTC)[reply]
  • This bug is still an issue.
One quick-and-dirty fix would be to tweak the hard-coded CSS specified in Module:hu-nominals, from width: 40%; to max-width: 400px;. Would anyone object to this? ‑‑ Eiríkr Útlendi │Tala við mig 21:47, 5 May 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]
I see. Good luck to your studies, hope you'll enjoy it. --Panda10 (talk) 14:43, 10 May 2016 (UTC)[reply]
Using max-width is generally a bad idea. I've always used min-width. —CodeCat 18:07, 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'll also see if I can figure out where to find the guts of the possessive table, and I'll make a similar change there. ‑‑ Eiríkr Útlendi │Tala við mig 22:21, 9 May 2016 (UTC)[reply]
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. —CodeCat 23:42, 9 May 2016 (UTC)[reply]
Done. —CodeCat 23:56, 9 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. —CodeCat 00:09, 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 —CodeCat 01:23, 10 May 2016 (UTC)[reply]
@CodeCat: Thanks for making the changes. Is there a reason the possessive table appears half as long as the other when the two are closed? --Panda10 (talk) 14:43, 10 May 2016 (UTC)[reply]
It's because the content in the tables isn't the same width. —CodeCat 18:12, 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. —CodeCat 19:04, 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? —CodeCat 19: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've updated that table now too. —CodeCat 19:33, 10 May 2016 (UTC)[reply]
Thanks! --Panda10 (talk) 21:10, 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. —CodeCat 21:56, 10 May 2016 (UTC)[reply]
Yes. I am trying to make the header longer to make the possessive table a little wider. --Panda10 (talk) 23:15, 10 May 2016 (UTC)[reply]
You can set a min-width on the table to make it wide without adding content to the header. —CodeCat 00:39, 11 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]
I don't understand what the issue is. It works fine for me. —CodeCat 14:15, 11 May 2016 (UTC)[reply]
Yes, it does. Thanks for adding it. --Panda10 (talk) 14:22, 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]

There's a "Visibility" section in the sidebar that should do what you want. DTLHS (talk) 04:29, 29 April 2016 (UTC)[reply]
Aha! Perfect, thank you. Quiddity (talk) 19:04, 30 April 2016 (UTC)[reply]

As pointed out on WT:TR, Module:fr-verb which is causing a lot of problems does not deal with this correctly. It imposes the wrong conjugated form disez for the imperative and since Module:fr-verb/documentation contains no information about how the module works (that's, right none) I am unable to fix the problem. Renard Migrant (talk) 12:53, 29 April 2016 (UTC)[reply]

Strange behaviour of mw.ustring.find

[edit]

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? —CodeCat 00:02, 30 April 2016 (UTC)[reply]

expandTemplate changes the code - 'Descendants===' is preceded by '"`UNIQ--h-6--QINU`"'? in content. Wyang (talk) 00:15, 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`"'. --WikiTiki89 19:45, 10 May 2016 (UTC)[reply]

Template:desctree template loop

[edit]

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? —CodeCat 16:37, 30 April 2016 (UTC)[reply]

I managed to work around it, by replacing the template with a module invocation. —CodeCat 19:18, 30 April 2016 (UTC)[reply]