Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:Bug reports)
Jump to navigation Jump to search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018


Contents

December 2018

Template:alter generates incorrect format[edit]

When you include multiple terms as arguments to this template, they are shown on a single line, separated by commas. But the normal formatting of Alternative forms, like Derived and Related terms, is to have one term per list item. —Rua (mew) 16:17, 1 December 2018 (UTC)

It's intentional. {{alter}} is different from the templates used in the Derived and Related terms sections, in that it formats a list of terms followed by an optional qualifier (usually a dialect). Sometimes there are multiple terms with the same qualifier or set of qualifiers (search query: hastemplate:"alter" insource:/\{\{alter(\|[^|}]+){3,}\|\|/); for instance, two forms used in the same set of dialects. I am not sure how a one-item-per-bullet list template would handle this. Perhaps by repeating the qualifier after each one; for instance, {{alter|grc|ἀδελφεός|ἀδελφειός||epi|ion|lur}} (from ἀδελφός) would have to display as something like
A bit repetitive, and it would be complicated when there are multiple qualifiers involved. But probably there are Alternative forms sections where a one-item-per-bullet list template would be the best fit. — Eru·tuon 21:23, 1 December 2018 (UTC)
If there is only one item, why is there even a list? It feels like a misuse of HTML. I think we should revert to the standard format, unless there's an agreement that this is how we want lists to be formatted from now on. —Rua (mew) 21:44, 1 December 2018 (UTC)
Look at ἀδελφός; there are multiple alternative forms and multiple instances of {{alter}}. I just quoted one instance that had two terms with the same qualifier. What do you mean by "standard format"? How would the Alternative forms section of ἀδελφός look in this format? — Eru·tuon 21:51, 1 December 2018 (UTC)
I've always hated {{alter}}, from its non-standard || function to its name, and I think it's due for a rethinking. I would much rather each dialect be on it's own like, much like it is in descendants. --{{victar|talk}} 00:20, 2 December 2018 (UTC)
Something like the version that I added here? Make any changes you like or add additional versions. It helps to have a demonstration of what people are describing. — Eru·tuon 00:29, 2 December 2018 (UTC)
@Erutuon: Just about, but like this. --{{victar|talk}} 00:51, 2 December 2018 (UTC)
@Victar: Ah, that seems a nice layout. But for whatever reason, the odd way the parameters in {{alter}} work does not bother me. — Eru·tuon 01:07, 2 December 2018 (UTC)
What if there are no dialects, but just a list of terms? I think they should be listed with one term per item, like we do for derived terms. —Rua (mew) 12:24, 2 December 2018 (UTC)
As I hinted at above, I agree that if it's just a plain unorganized and unqualified list, {{alter}} is not a good fit and some kind of list template would be simpler and more efficient. — Eru·tuon 20:52, 2 December 2018 (UTC)
The || function is indeed strange when elsewhere one has |q=. Fay Freak (talk) 22:03, 2 December 2018 (UTC)
I wouldn’t like one term per line. It would mean more scrolling and more attention taken when perhaps the alternative forms are not sought for, just added for completion – imagine the lamest orthographic variants in German, like Kreis having Kraiß, Kreiß, Krayß, Kreyß, Krais, Krays, Kreys. But note that currently the comma is on the wrong side between multiple forms if the script is right-to-left. Fay Freak (talk) 22:03, 2 December 2018 (UTC)
@Fay Freak: Fixed the position of the comma between right-to-left terms with no annotations in {{alter}}. Somehow the left-to-right mark has to be outside rather than inside the HTML tag. — Eru·tuon 22:24, 2 December 2018 (UTC)
@Erutuon: Yes, but now the tr1 parameter displays for the third form when there are three forms, tr2 displays for the first when there two forms, etc. Fay Freak (talk) 22:37, 2 December 2018 (UTC)
@Fay Freak: Could you point me to some examples? I looked at instances of {{alter}} containing Arabic-script words with transliteration and didn't see what you're describing. — Eru·tuon 22:40, 2 December 2018 (UTC)
@Erutuon: רמא‎ (apparently because it uses multiple scripts) (currently not containing transcriptions because the transcription is according to the etymology of two, not distinct from what is on the page). Fay Freak (talk) 22:43, 2 December 2018 (UTC)
@Fay Freak: Okay, so you're referring to the output of {{alter|arc|ܪܡܐ|ࡓࡌࡀ|tr2=rāmā}}. Actually, it's working as expected. ܪܡܐ|ࡓࡌࡀ is a run of right-to-left text. In memory, ܪܡܐ is first, then there is |, then ࡓࡌࡀ. So ࡓࡌࡀ is the second word and its transliteration is |tr2=rāmā. — Eru·tuon 22:57, 2 December 2018 (UTC)
@Erutuon Ok yes, I probably got confused. Fay Freak (talk) 23:02, 2 December 2018 (UTC)
En.Wiktionary entries already have too much wasted space, IMO, so I wouldn't want alt forms to always be on separate lines, and it seems sensible for them to be on one line in the environment {{alter}} seems (from the examples) designed for, of several terms of the same dialect/type being grouped per line / per invocation of the template — and also in cases where there are a lot of alt forms, like ambaíba, seien, or ambergris. Of course, that doesn't mean this template itself has to exist, or have its current || parameters or one-line format, if people object to those, since entries with exceptionally many alt forms could be handled manually, like most already are... but we could also just leave this template be for the cases it was designed for and just use the usual manual formatting for cases where there are only a few alt forms and it's desired that they be on separate lines. - -sche (discuss) 17:00, 3 December 2018 (UTC)
We already have a set of expanding box templates for derived and related terms (as well as a BP discussion on how they should look/work going on). Why aren't we using those for alternative forms as well? That would alleviate the wasted space concerns and also make alternative forms look consistent in style with other lists. —Rua (mew) 17:37, 4 December 2018 (UTC)
@Rua This is not a good way because there are usually not more than half a dozen alternative forms, rarely 25 as in اسفناج‎; -sche (talkcontribs) has also a list of the leaders, I don’t know how much it is updated. I don’t know what you wanna do with voivode. One would get needlessly tired from clicking the alternative forms expander down to find only two more alternative forms and so. Fay Freak (talk) 22:47, 4 December 2018 (UTC)
Of course, that also applies to derived terms, so it's not really relevant for alternative forms necessarily. —Rua (mew) 10:46, 6 December 2018 (UTC)

|lang= in {{quote-web}}[edit]

I saw in ว่าที่ that some quotes say "in th" instead of "in Thai". It seems intuitive that this parameter should accept language codes. Ultimateria (talk) 21:44, 1 December 2018 (UTC)

You are referring to the |language= (not |lang=) parameter. I'm aware of this issue, but haven't got round to figuring out how to deal with it. One difficulty is that at the moment one has to enter the full language name. If the parameter is switched to accepting language codes, then all templates using the full language name will result in an error. I'm not entirely sure how this should be dealt with. Suggestions are welcome. — SGconlaw (talk) 13:16, 2 December 2018 (UTC)
What exactly is the "language" parameter supposed to be for? You should not have both "lang" and "language". Choose one, and I will deprecate the other. here is a list of quotes with the "language" parameter where the language isn't recognized. DTLHS (talk) 23:41, 2 December 2018 (UTC)
That makes sense. The parameter |language= is intended to allow editors to specify the language of a source, while |lang= merely categorizes the entry in “Category:Language terms with quotations, but the latter parameter can serve both functions. I’ll work on that. — SGconlaw (talk) 02:22, 3 December 2018 (UTC)
@DTLHS: OK, I have combined |language= and |lang= (now synonyms), and it is now mandatory that a language code rather than the full language name be used. This means that any template that is now using |language= with a full language name will be throwing an error. Are you able to fix that with a bot or otherwise? — SGconlaw (talk) 12:37, 3 December 2018 (UTC)
I made a similar change to the "cite" templates, meaning that templates like {{cite-book}} and {{cite-journal}} will also need to have their |language= parameters updated with language codes rather than full language names. (The parameter |lang= can now be used as a synonym for |language= as well.) — SGconlaw (talk) 13:18, 3 December 2018 (UTC)
@Sgconlaw I have encountered a template {{R:trk:Radloff}} that had |language=German and Russian. This insinuates that there should be |language2=, |language3=, since it is not implausible that linguistic lexica are in multiple languages (btw {{T:R:ota:Meninski}} is in Latin, Polish, Italian, French, German, but not consistently). Fay Freak (talk) 15:19, 3 December 2018 (UTC)
Ah, bother. OK, let me think about this. There is a problem, because in the "quote" templates |language2= and |lang2= are already used for a different purpose – when quoting from a reprint or republication of an original work. (The "cite" templates do not have this feature. Would it be advisable to use a parameter with a particular name differently in the two sets of templates?) Again, suggestions welcome. — SGconlaw (talk) 15:34, 3 December 2018 (UTC)
P.S. For a template like {{R:ota:Meninski}} I would suggest that |lang= not be used at all, because it would be very awkward to try and reflect in the citation all the different languages used in the work. I don't know if there is a standard language code for "multilingual" (mul?) – if so, that should be used instead. — SGconlaw (talk) 15:38, 3 December 2018 (UTC)
Yes I intended not to give such information for {{R:ota:Meninski}}. I did not think about the use for republications (these specific ones are in the documentations only mentioned in the way “Most of the parameters listed above can be applied to a new version of the book by adding "2"”) and I have no suggestions for this issue currently. Fay Freak (talk) 16:01, 3 December 2018 (UTC)
OK, it looks like someone switched |language= to require lang codes not names without bothering to run a script to fix all the references. Not good. Now we have 5000+ errors. Benwing2 (talk) 16:31, 3 December 2018 (UTC)
Yikes. Someone with admin rights, please fix. --{{victar|talk}} 16:35, 3 December 2018 (UTC)
@DTLHS said he would attend to it: see above. DTLHS, perhaps you can attend to the changes for the "quote" templates first, and then let me know when you are ready to deal with the changes for the "cite" templates. — SGconlaw (talk) 16:44, 3 December 2018 (UTC)
I can fix it in about 9 hours, you probably want to revert that for now. DTLHS (talk) 16:55, 3 December 2018 (UTC)
@Vorziblix already did so. --{{victar|talk}} 16:59, 3 December 2018 (UTC)
Yes, for the time being. Just revert my edit when the template changes are ready. — Vorziblix (talk · contribs) 17:05, 3 December 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Sgconlaw I've done a bunch of the mainspace ones- however there are a lot of edge cases. Please make a tracking category so we can take care of those instead of just breaking everything all at once :) DTLHS (talk) 04:48, 4 December 2018 (UTC)

OK, which entries do you want placed in the category? All entries using |language=? — SGconlaw (talk) 04:51, 4 December 2018 (UTC)
Yes, that will work. DTLHS (talk) 04:51, 4 December 2018 (UTC)
All right, I have added "Category:Quotation templates using the language parameter" to {{quote-book}}, {{quote-journal}} and {{quote-web}}, the three most heavily used templates. Let me know if you want the category added to the rest as well. — SGconlaw (talk) 06:41, 4 December 2018 (UTC)

I'm noticing a problem with these changes. The quotation under Azcapotzalco now says "Arte de la lengua mexicana con la declaracion de los aduerbios della (in Classical Nahuatl)", but that book isn't in Classical Nahuatl, it's in Spanish (as the title suggests). But if I change |lang= to es, it categorizes the entry under Category:Spanish terms with quotations. The template doesn't allow for a quotation to come from a work in a different language from that of the entry. --Lvovmauro (talk) 01:30, 5 December 2018 (UTC)

@DTLHS: your view? — SGconlaw (talk) 03:00, 5 December 2018 (UTC)
So, we need to be very clear what the lang / language parameter means in these templates. Does it mean this is in a Spanish entry, or does it mean the language of the quote is Spanish? It makes more sense to me for it to be the latter. I think the category "Spanish terms with quotations" is badly named. It refers to outside context, but theoretically we could quote a term from one language in the entry of another (as above). "Quotations of Spanish texts", perhaps. DTLHS (talk) 03:13, 5 December 2018 (UTC)
I agree. Personally, I think the intention should be to indicate the language of the quotation, not the work generally. (I'm not sure about whether the categories should be renamed. That seems to require a separate discussion.) — SGconlaw (talk) 03:35, 5 December 2018 (UTC)
That's my interpretation, and I too am suffering from the loss of the distinction between 'language' as the language of the book and 'lang' as the language of the quotation. I've been working on Pali in non-Roman scripts (there are interesting spelling issues) and the languages of the best citable sources I have are Lao and Sinhalese. I presume the purpose of the category is to support forming long-term maintenance categories along the lines of "xxx terms lacking quotations". The language of the book has some use as a warning to the checker and might be relevant to pruning quotations. --RichardW57 (talk) 17:37, 7 December 2018 (UTC)
Please, suggest some alternative names for new parameters to make such a distinction then. "lang" and "language" are unacceptably similar and it's untenable to maintain a distinction between them. DTLHS (talk) 19:53, 7 December 2018 (UTC)
It's not obvious to me, except from the history, whether lang/language would identify the language of the source document (typically a book) or the quoted passage. So, I would use 'lang' to specify the default for both concepts, and let it be overridden by a parameter for the source document and by another parameter for the quote language. Then some reasonable names for the language of the source document as a whole are:
source_lang, document_lang, doc_lang, book_lanᩮ
Some reasonable names for the quote language are:
quote_lang, passage_lang, lemma_lang
The commonest use case would be for both to default to the value of the parameter 'lang'. --RichardW57 (talk) 20:41, 7 December 2018 (UTC)
That makes sense to me. DTLHS (talk) 22:04, 7 December 2018 (UTC)

(Fixed indentation --RichardW57 (talk) 20:46, 7 December 2018 (UTC))

Given that lang= refers to the language of the current entry in all our other templates, it should have this meaning as well for this particular case. If the quote is in another language, I wonder why that quote appears in the entry in the first place. Why would a quote in French illustrate usage of English? The language of the entire work seems completely irrelevant to indicate, because the quote is all that matters. —Rua (mew) 21:23, 7 December 2018 (UTC)
Could one not have used {{inflection of|ignoro|īgnōrō|pres|ind|act|1|p|lang=la}} to explain the English word ignoramus? --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
For Nahuatl, a mention of a word in an otherwise-Spanish or partly-Spanish sentence is apparently enough for the word to meet CFI, and in practice such sentences are quoted under the relevant sense of the word, like quotations. For other languages where we have only a few entries, I've usually cited the book and quoted the sentence in ===Further reading=== (or formerly ===References===), and perhaps that would be a better practice for Nahuatl, I don't know. - -sche (discuss) 22:34, 7 December 2018 (UTC)
The language of the work is information relating to the ease of verification. As we suffer from vandals, it is entirely conceivable that some quotes are manufactured. There is also the risk of quotes being incorrectly 'corrected'. Additionally, a work may quote chunks in another language. If one didn't understand English, one could very easily assume the Brahmi script text in Mason's Pali grammar was actually Pali.
I don't know if this is happening, but I could imagine a quote in French being used to illustrate a point in the development of English, e.g. the replacement of 'hit eam ic' by 'it is me'. However, I will agree that it is wrong to use '#*' for quotes in another language - defining 'in another language' as in the Nahuatl practice given by -sche. The sequence '#*' that should be all this is needed to convey the presence of a quote. Presumably it is too complicated to extract the information by parsing the generated pages. --RichardW57 (talk) 23:07, 7 December 2018 (UTC)
Language codes are very good for categorization, because we don't want to have dozens of one-entry categories based on slight variations in the language name. They're rather awkward, otherwise, because there are myriad distinctions of time, region and social context that language codes don't cover very well.
I think the language of the work is useful information for the reader, but not necessarily for categorization.I would think there would be lots of cases where someone quoted a passage from a lost work in another language, or someone gave examples of speech in another language collected in the course of their fieldwork. A monolingual English speaker, for instance, may not be able to use a work where the passage in question is quoted in the midst of a lengthy discussion by a German author. Possible parameter names: |worklang= or |authorlang=. It might also be good to have parameters that parallel parameters for volumes, parts of series, chapters, etc. An international journal or festschrift might have articles in numerous languages, and sometimes different authors write different chapters of a book, each in their own language.
A separate issue to think about is categorization of quotes by subvariety: I can see why someone might want to find quotes of a dialect even in entries where the dialect doesn't merit a context label in any of the definition lines. Chuck Entz (talk) 23:52, 7 December 2018 (UTC)
I don't like |authorlang=. It might be taken for the native language of the author! For example, I have taken Pali quotations from a book written in English by a Burmese author, who sometimes uses conventions that only make sense to me from a Burmese context. The source was chosen because it was valid for quotations. --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
Would someone like to summarize for me what is being suggested here? — SGconlaw (talk) 06:08, 8 December 2018 (UTC)
Summary: The old (e.g. Autumn 2018) functionality of the distinction between |lang= language of the quote and |language= language of the source being cited should be restored. As these two parameter names are too easily confused, the language of the source should have a new, clearer parameter name. If this parameter is not specified explicitly, it should default to the language of the quotation, which is the commonest use case. --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
Remark: Wikipedians may be confused, as they use 'lang' or 'language' for the language of the source; the language of a quotation should be obvious from the context. --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
Pinging @DTLHS for your views since it was your suggestion that |language= and |lang= should be combined. As RichardW57 suggests, I think it would be a good idea for these two parameters to continue being synonyms of each other, and for them to be used to indicate the language of the quotation. However, I could create a new parameter for indicating the language of the work (perhaps |worklang=, as suggested by Chuck Entz). The template could display |worklang= if has been specified; if not, it will then display the language indicated by |language= or |lang=. — SGconlaw (talk) 13:14, 8 December 2018 (UTC)
@RichardW57 Even Wikipedia needs to tag text written in foreign languages though, just like we do. How do they handle that if there is no parameter to indicate it? —Rua (mew) 13:58, 8 December 2018 (UTC)
For tagging text within the page, there is {{lang}}, which takes language code and text as parameters. Their {{cite book}} etc take |language=, which accepts both IANA codes and English names of languages. I think the citation templates may assume that the untransliterated title of the source is in the language of the source. Note though that this is primarily used for font selection. Wikipedia citation has three forms of a title - original, transliteration and translation. --RichardW57 (talk) 14:42, 8 December 2018 (UTC)
Note: (1) Our {{cite}} and {{quote}} templates currently do not tag text as belonging to any language. (2) As regards the |language= and |lang= parameters, the intention is to ultimately make them work the same way in these two families of templates – once we are agreed on how they should work. There is no reason for the parameters to work one way in the {{quote}} templates and another way in the {{cite}} templates. — SGconlaw (talk) 15:02, 8 December 2018 (UTC)
The issue is rather with Wiktionary and Wikipedia having different semantics. However, retiring |language= will force Wikipedians to look at the documentation. --RichardW57 (talk) 16:04, 8 December 2018 (UTC)
What is the intention on moving forward? Should unprivileged editors be creating temporary work-arounds for the broken general templates? --RichardW57 (talk) 21:57, 12 December 2018 (UTC)
I’m waiting for @DTLHS to comment since he originally requested for the changes to the templates. — SGconlaw (talk) 01:54, 13 December 2018 (UTC)
My comment is the templates need more parameters with specific names to indicate exactly what the language refers to. DTLHS (talk) 02:32, 13 December 2018 (UTC)
@DTLHS: are the changes that I suggested on 8 December (see above) OK with you? — SGconlaw (talk) 03:04, 13 December 2018 (UTC)
Yes, that sounds reasonable. DTLHS (talk) 03:08, 13 December 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── OK, @DTLHS, RichardW57, the following quotation templates now accept the parameter |worklang=, which is intended for specifying the language of a work, as distinct from the language of the quotation (to be specified using |lang= or |language=):

(It didn't seem necessary to add the parameter to the rest of the quotation templates; let me know if you think otherwise.)

The parameter |worklang= accepts either a language code or freeform text (e.g., either |worklang=ja or |worklang=Elvish). DTLHS, how is the replacement of the |language= parameter coming along? Let me know when you would like me to start on converting the {{cite}} templates. — SGconlaw (talk) 07:46, 14 December 2018 (UTC)

The remainder of entries in Category:Quotation templates using the language parameter are unusual cases such as multiple languages and need to be handled somehow. DTLHS (talk) 16:18, 14 December 2018 (UTC)
I notice |worklang= is not defaulting to |lang=. Is this intentional? --RichardW57 (talk) 16:21, 14 December 2018 (UTC)
As I could understand the given information |worklang= is what |language= has been in cite templates, for displaying a language, while |lang= works now for categorization like when I use a citation templates as quotation template with a switch. Fay Freak (talk) 17:19, 14 December 2018 (UTC)
There is a claim above that | implies |. While that claim has been refuted, it is often true that the correct values are identical. So, having specified |lang=, when should one specify |worklang=? When the language of the work is different to the language of the quote, or when the work is not in English? Or do we expect the reader to work out form the title whether the work is in the language of the quote or in English, and only note third alternatives. Note that the current display should never say that the work is in English.
A conceivable example is a Latin quote from Vox Latina, which is written in English, despite its Latin title. --RichardW57 (talk) 17:56, 14 December 2018 (UTC)
A better example would be a Thai quote from the apparently Thai magazine called Cleo - the title only appears in the Roman script! --RichardW57 (talk) 18:27, 14 December 2018 (UTC)
It occurred to me that making the template default to |lang= if |worklang= is omitted would mean there would be many cases where "in English" would be displayed, which would be redundant. I suppose I could make the template check if |lang=en, and if so not display the language of the work. Would it make sense to treat English in this way, differently from other languages? — SGconlaw (talk) 18:41, 14 December 2018 (UTC)
Ah, I mistakenly thought English was the default language, as in Wikipedia, and would not be displayed. As one can force 'in English' to appear, it would make sense to adapt the part of the old description that said, "The language that the book is written in. If the book is written in English, it is not necessary to specify this fact", to add to the description of |worklang= the policy remark, "If the book is written in the language of the quote, it is not necessary to specify this fact". My prime concern was to achieve stability as soon as possible. As we can explicitly state that a book is in English, the current code does not need further change.
As an aside, is there any guidance on determining the language of a book? For instance, I have an Old Testament (Biblia Hebraica Stuttgartensia) with an introduction in Latin and repeated in other European languages, sidenotes in Aramaic and footnotes in Latin. (The list of Aramaic abbreviations is a card explaining them in German.) The sacred text is mostly in Hebrew, with a few bits in Aramaic. What language is the book in? --RichardW57 (talk) 19:34, 14 December 2018 (UTC)
There are several module errors in CAT:E because something like "Greek and Latin" has been put in the |language= parameter. I assume the correct thing to do is |worklang=Greek and Latin, if the work really is in both languages. For instance, it seems incorrect to indicate an English–Turkish dictionary, with English text describing Turkish words, as "English and Turkish" (see this edit). — Eru·tuon 20:25, 14 December 2018 (UTC)
It looks like there's a hidden module error still being generated for some reason by the new parameter. Presumably the template should not try to parse it as a language code. DTLHS (talk) 20:35, 14 December 2018 (UTC)
(edit conflict) The invisible module errors in pages such as Citations:chiausus and Citations:chiaux were because of {{#iferror:{{#invoke:languages/templates|getByCode|{{{worklang}}}|getCanonicalName}}...}} bit in Template:quote-meta/source. The module error category is not removed by {{#iferror:}} (see this Phabricator item). I've switched to the errorless getCanonicalName function in Module:languages/templates when processing the |worklang= parameter. It would be even nicer not to have to call getCanonicalName twice in the template (save server resources). — Eru·tuon 20:58, 14 December 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I have modified {{quote-meta/source}} so that if |worklang= is omitted, it now uses |language= or |lang= as a backstop if one of those parameters is specified and does not have the value "en". @Erutuon, if you can think of a tidier way to achieve that effect, feel free to update the template. (Note that |worklang2= lower down in the template would also need to be updated.) [Nope, that part didn't work properly, and so no longer uses |lang= as a backstop.] — SGconlaw (talk) 18:02, 16 December 2018 (UTC)

The word 'twitter' does not display properly on the page 呢喃[edit]

--Geographyinitiative (talk) 13:07, 2 December 2018 (UTC)

In what way? It looks fine to me. — SGconlaw (talk) 13:11, 2 December 2018 (UTC)
Is there a convenient way for us to get a screenshot? I've resorted to personal e-mails. Uploading to Commons is also possible, but seems inappropriate for this purpose, unless there is a way to ensure the removal of the file after a certain interval. DCDuring (talk) 13:19, 2 December 2018 (UTC)
Can screenshots be uploaded locally to the English Wiktionary rather than to the Commons? They could be put into a category created for maintenance purposes, and then tagged for deletion once they have served their purpose. — SGconlaw (talk) 13:26, 2 December 2018 (UTC)
"Upload file" provides for uploading to Commons. We can't automagically limit use of upload to a subset of desired images. At some point, we decided not to risk getting into copyright policing and instead use Comomons infrastructure. Perhaps we could establish a category there for such images. Would we get as many as 100 screenshots per year? DCDuring (talk) 14:20, 2 December 2018 (UTC)
See this Commons category (well down in a category tree) for a model of what might work for us. DCDuring (talk) 14:26, 2 December 2018 (UTC)
There is a fair amount of overhead relating to licensing which makes me appreciate user email for this purpose. DCDuring (talk) 14:47, 2 December 2018 (UTC)
Ah, I see. Yes, I have been involved with the Commons before, and it certainly does require a lot of attention to keep copyright violations at bay. — SGconlaw (talk) 14:50, 2 December 2018 (UTC)
We could add a Wiktionary category, make mistakes, get beaten about the head and shoulders, accept corrections, and end up with something usable. DCDuring (talk) 14:58, 2 December 2018 (UTC)
Maybe just ask an administrator there what would be the best thing to do. — SGconlaw (talk) 15:33, 2 December 2018 (UTC)
In a case like this where a file is only needed for a short time for site-related bug-fixing, admins have the ability to temporarily upload a file locally using Special:Upload, and then delete it once the purpose is served. - -sche (discuss) 19:11, 2 December 2018 (UTC)
Special:Upload looks good. That means that the user with the problem, eg, @Geographyinitiative:, would need to email the screenshot to an admin, eg, me. DCDuring (talk) 20:38, 2 December 2018 (UTC)
Do you know that Wikimedia isn't literally the only site on the internet that you can upload an image to? DTLHS (talk) 23:03, 2 December 2018 (UTC)
I try to avoid proprietary and insecure social media sites. Do you have a specific recommendation of a site for anonymous posting (and deletion) of images? DCDuring (talk) 02:23, 3 December 2018 (UTC)
I've used Imgur before for a few things (as, I see, has suzukaze). You can make a username (as anonymous as you want), upload images and delete them later. - -sche (discuss) 17:11, 3 December 2018 (UTC)
Thanks. I guess the important thing is to tag the image (screenshot) so it can be found. "Wiktionary" or "enWikt" would be good for starters. DCDuring (talk) 17:58, 3 December 2018 (UTC)
No need to. The person who uploads the image posts the url here, and anyone who wants to can view it there (until it's deleted there, of course). Chuck Entz (talk) 03:10, 4 December 2018 (UTC)
Adblocker? Sometimes this happens to me with “Facebook". —Suzukaze-c 19:14, 2 December 2018 (UTC)
I tested Suzukaze-c's idea and it seems to be correct. When I turned off AdBlock and reloaded the 呢喃 page just now, I could see the word 'twitter'. When I turned AdBlock back on and reloaded the page, I was no longer able to see the word 'twitter'. --Geographyinitiative (talk) 12:14, 4 December 2018 (UTC)
Great. And I learned something from the OT part of the discussion. DCDuring (talk) 13:27, 4 December 2018 (UTC)
As Suzukaze mentions, this kind of thing has happened to other people before, for the same reason (adblockers being overzealous) - should we add this to the FAQ? (Does anyone read the FAQ?) - -sche (discuss) 04:22, 8 December 2018 (UTC)
If the issue has come up before, I think it is worth adding to the FAQ. People are not likely to find the FAQ on their own, but it is something that editors who post on these discussion pages can be directed to if the issue surfaces again. — SGconlaw (talk) 06:01, 8 December 2018 (UTC)
True. (I'd like to add to my earlier comment that I'm not chastising OP for not reading it, and had not read it myself until this thread made me wonder if we had one. But yes, maybe adding this question there will ensure more of us retain institutional memory of the answer.) - -sche (discuss) 07:30, 8 December 2018 (UTC)

strange entry[edit]

I'm trying to delete the thing added by 175.33.160.128 (talk) but can't select it. Any ideas? SemperBlotto (talk) 08:07, 4 December 2018 (UTC)

I had no trouble deleting it (̰ – U+0330 COMBINING TILDE BELOW). However, as quite a number of other entries link to it, it seems to make sense to create a proper entry for it. — SGconlaw (talk) 08:31, 4 December 2018 (UTC)
I couldn't select it either using Firefox, but could using Chrome. DCDuring (talk) 13:25, 4 December 2018 (UTC)
Strange indeed, as I’m using Firefox. — SGconlaw (talk) 13:26, 4 December 2018 (UTC)
and I'm using Chrome. SemperBlotto (talk) 13:29, 4 December 2018 (UTC)
I updated Firefox and could select it. DCDuring (talk) 13:38, 4 December 2018 (UTC)
I also cannot select click on that thing in Chrome. (Possibly related: I'm using plugins called "Chromium Wheel Smooth Scroller", which makes scrolling less jerky, and "Select Like a Boss", which allows you to start selections from mid-hyperlink etc. instead of that triggering the link.) Equinox 15:18, 4 December 2018 (UTC)
Regarding whether we should have an entry for it, I think no. If exists at all, it should be a redirect to a non-combining equivalent. Combining diacritics alone should not have entries because of the problems they cause with formatting. Space + combining diacritic, or placeholder character + combining diacritic, could be ok if they don't cause any problems. —Rua (mew) 17:40, 4 December 2018 (UTC)
Suzukaze-c has created an entry for it. — SGconlaw (talk) 03:07, 5 December 2018 (UTC)
My understanding of Wiktionary:Votes/2011-06/Redirecting combining characters is that this should just be a redirect, yes. - -sche (discuss) 07:20, 8 December 2018 (UTC)
If there is a previous decision on the issue, we should follow it. To what entry should the Unicode character in question be redirected to? — SGconlaw (talk) 15:06, 8 December 2018 (UTC)
Actually, the vote only talks about combining characters for which there is a non-combining character. I don't think there's a non-combining tilde below, so the vote doesn't apply to the combining tilde below. But the entry name would be easier to click on if it were situated at ◌̰ with the diacritic seated on a dotted circle. We can't seat the diacritic on a space character, because spacing characters are stripped at the beginning and end of an entry name: a link containing ̰ (SPACE, COMBINING TILDE BELOW) links to the same entry as ̰ (COMBINING TILDE BELOW).
Well, that previous example demonstrates that there can be a spacing character in the links, making them easier to click (at least in my browser). In theory Module:links could add a space character entity reference before any initial combining character (or before a single combining character), but that would require transcluding Module:Unicode data on many more pages and would probably lead to module errors on high-memory pages, and it wouldn't fix the links in category pages such as Redirected combining characters, which could be fixed independently with JavaScript. — Eru·tuon 19:48, 8 December 2018 (UTC)
OK, thanks for clarifying. — SGconlaw (talk) 09:15, 9 December 2018 (UTC)
I think that CSS letter-spacing could help, but I'm not sure how the appropriate links would be targeted. —Suzukaze-c 23:35, 8 December 2018 (UTC)

Bot editting[edit]

Hey all. Shit like this is among my most memorably boring work that I do here. It's so boring that I kinda wanna smash my computer into a wall. But it's kinda cool because the quotes get categorised into Category:Requests for date by source, and that means we can do one of the most immensely fun things - finding and dating the work from which a quote (generally from Webster 1913) was taken. To save my potentially injurying myself and having to buy a new computer, does anyone want to use a bot to make similar edits? If I remember correctly, I recently got into an argument with someone, probably DCDuring, about these templates - I probably lost the argument... --Love Young (talk) 12:33, 7 December 2018 (UTC)

Wiktionary:Bots/Tasks is a good place to make such requests. Seems like it might be pretty trivial to make a bot to handle that type of edit, depending on how uniform the existing usage of {{rfdate}} is. - TheDaveRoss 13:04, 7 December 2018 (UTC)
The question is (or should be): Why do something that is counterproductive?
{{rfdate|and other bibliographic particulars, eg, title of work, page, url, full name of author}} asks for all the information missing for complete citations. {{rfdate}} without {{{1}}} asks for only a date. In my experience the result was often the dates of the author, not the date of the work (which may have been a translation, in which case the date range did not even include the date of the work). Of course, in other instances the contributor added the date, but none of the other missing information, such as the title of the work. {{rfquotek}} is an improvement over bare {{rfdate}}, but fails to inform contributors that more than a date is needed.
It would be useful to get a bot to replace bare {{rfdate}} with {{rfdate|and other bibliographic particulars, eg, title of work, page, url, full name of author}}, but there would still be some point in manually reviewing each entry to add to the listed missing items other appropriate items (eg. act, scene, line, for plays) and to delete those items already present. DCDuring (talk) 17:52, 7 December 2018 (UTC)

Template:IPA letters[edit]

Is there a way to get this useful template to generate both /zɛd/ and /zi/, tagged appropriately? Or at least to allow generating one or the other via a parameter, so it could then be used twice on entries like LZW to generate both pronunciations? (Other differences, e.g. in the pronunciation of o or parenthetical /(ɹ)/s, seem less significant but could also be addressed, especially if we go the route of adding a dialect parameter.) If not I suppose we can monitor for use on pages with z and add the other pronunciation as needed. - -sche (discuss) 22:16, 7 December 2018 (UTC)

BTW, some BrE speakers have the /h/ sound on the beginning of the name of the letter H. Equinox 21:23, 8 December 2018 (UTC)
I've created a first draft of a Lua version at Module:IPA letters. It shouldn't be too hard now to make it generate pronunciations for both Received Pronunciation and General American. — Eru·tuon 23:38, 8 December 2018 (UTC)

sort_key for Central Tarahumara[edit]

Could someone add the following to the entry for Central Tarahumara (tar) at Module:languages/data3/t?

	sort_key = {
		from = {"á", "é", "í", "ó", "ú", "ꞌ"},
		to   = {"a", "e", "i", "o", "u"}},

--Lvovmauro (talk) 09:57, 9 December 2018 (UTC)

Added. DTLHS (talk) 02:55, 11 December 2018 (UTC)

Dealing with qualifiers when using der3 etc.[edit]

I have had some interesting fun and games including qualifiers when using the {{der3}} family. It is probably better to avoid using qualifiers at all, but when reformatting sea#Derived terms I felt I had to include them for sea snail and seasnail. The basic problem is that qualifiers when used with {{der3}} and {{der4}} result in incorrect sorting; the entries including qualifiers were placed out of order at the head of the list. I got around the problem by using {{der4-u}} without automatic sorting, but still had to use {{l|en|[term]}} with the qualifiers instead of [[ ]]. So the problem is not insurmountable, but is there a solution regarding the automatic sorting? DonnanZ (talk) 15:11, 15 December 2018 (UTC)

@Donnanz: Ah, what's happening is that Module:columns doesn't link the term in {{der3}} (or another column template) if it contains <span. It sorts terms before linking them. So the parameters that are linked with {{l}} will start with <span and the others will start with an alphabetic character (which is capitalized internally during sorting), and < (code point U+003C) sorts before basic Latin capital letters (U+0041-U+005A).
One solution would be to have Module:columns look for matched parentheses at the end of the parameter and format them as a qualifier. (hat would correctly format |seasnail (fish) as the equivalent of {{l|en|seasnail}} {{q|fish}}. |sea snail (snail), seasnail (fish) could be formatted nicely if the module also checked for commas. That is similar to how the module that generates the tables for Appendix:English doublets works. I don't know what the Lua memory cost of this would be though. — Eru·tuon 20:27, 15 December 2018 (UTC)
If you type [[seasnail]] {{qualifier|XYZ}} it will sort properly. — SGconlaw (talk) 22:35, 15 December 2018 (UTC)
@Sgconlaw: But then the qualifier is supplied to the language-tagging-and-linking function along with the term or terms, roughly like {{l|seasnail {{qualifier|XYZ}}}}. That is messy and will sometimes cause problems: if the language is not English, the qualifier will be tagged with the wrong language, and if the terms aren't in the Latin script, the qualifier will either mess up script recognition or it will have the wrong script class applied to it (in which case it may be displayed in the wrong fonts). In general only the terms themselves should be supplied to the language-tagging-and-linking function. Unfortunately, any parameters with a qualifier are not language-linked, so this is not a good solution. My crossed-out remarks will apply if the module learns to tell the difference between a qualifier and a language link. — Eru·tuon 23:00, 15 December 2018 (UTC)
I had already tried Sgconlaw's suggestion, but tried it again anyway. Yes, it sorts properly with {{der4}} but using [[ ]] instead of {{l}} doesn't take you to directly to the entry, but to the top of the page. I can't recall having that problem in Norwegian (where lang=nb or lang=nn would be included with {{der3-u}} anyway, {{der3}} isn't used because of sorting problems with æ, ø, and å). DonnanZ (talk) 23:17, 15 December 2018 (UTC)
Oh yeah ... — SGconlaw (talk) 01:57, 17 December 2018 (UTC)
Ohh, that's right. Because the qualifier contains a span tag, the module assumes it is already language-linked (via {{l}}) and does not pass it through the language-linking function. (So my remarks above weren't correct.) — Eru·tuon 00:09, 16 December 2018 (UTC)
Actually I do have this problem in Norwegian, I tried it with jern, where I could have done away with the qualifier but left it there for now. DonnanZ (talk) 00:34, 16 December 2018 (UTC)

Reconstruction:Proto-Germanic/aiganą[edit]

The past participle of Proto-Germanic *aiganą is automatically given as *aihtaz, but it is really *aiganaz, which has been lexicalised and has got its own entry. Can this be corrected? --Florian Blaschke (talk) 03:24, 18 December 2018 (UTC)

If it's lexicalised, then that means it's not longer the past participle. —Rua (mew) 22:36, 21 December 2018 (UTC)
Not necessarily. In Old English, for example, the past participle is still (ġe-)āgen.
The reconstruction *aihtaz was generated automatically by the template that generated the inflectional table. Is there any evidence for it in the daughter languages? I don't know any. It seems to be a spurious form. --Florian Blaschke (talk) 02:26, 23 December 2018 (UTC)

Reconstruction:Proto-Italic/priōs[edit]

The nominative-accusative-vocative singular of the neuter is given as *priōs in the inflectional table. Latin prius suggests that this reconstruction is incorrect and it should really be *prios with a short o. Can this be corrected? --Florian Blaschke (talk) 03:29, 18 December 2018 (UTC)

prius is not given as a descendant, prior is. —Rua (mew) 22:37, 21 December 2018 (UTC)
prius is an inflected form of prior. Sihler's New Comparative Grammar of Greek and Latin seems to agree that the neuter nom/acc should have a short vowel. --Lvovmauro (talk) 01:31, 22 December 2018 (UTC)

反犬旁兒 nodot=1[edit]

On the new 反犬旁兒 page, the gloss on the 反犬旁 in the 'zh-forms' box reads: "nodot=1, dog radical". "nodot=1" should not appear there. This gloss is created by pulling on the definition at 反犬旁, a definition which happens to use 'zh-character component'. My conclusion is that 'zh-forms' can't handle the 'zh-character component'. How should the issue be addressed and the "nodot=1" removed (excluding the obvious "1=dog radical" fix) ? --Geographyinitiative (talk) 07:03, 21 December 2018 (UTC)

@Geographyinitiative The page is modified now with an edit unrelated to this issue; this issue is nevertheless disappeared (but unsolved). Dokurrat (talk) 13:12, 21 December 2018 (UTC) (modified)

zh-der and zh-syn-saurus[edit]

Template:zh-der and Template:zh-syn-saurus are not working. Any idea what's happening now? Dokurrat (talk) 13:01, 21 December 2018 (UTC) (modified)

@Erutuon Do you know if it has anything to do with your recent edit to MOD:zh? — justin(r)leung (t...) | c=› } 17:11, 21 December 2018 (UTC)
@Erutuon Yes, turns out that was the problem. I've reverted that edit, but we still need a better solution that would fix the potential problem of having links with colons. — justin(r)leung (t...) | c=› } 17:48, 21 December 2018 (UTC)
@Justinrleung: Thank you for fixing my error. I should have looked at more examples of the template. I made another change that fixes the colon problem and didn't cause terms to disappear. — Eru·tuon 20:36, 21 December 2018 (UTC)
@Erutuon: Thanks for fixing the problem! There was a module error before @Shāntián Tàiláng removed {{vern}} and {{taxlink}}, which were causing the error. I've put those back and it works great :D — justin(r)leung (t...) | c=› } 05:42, 22 December 2018 (UTC)

Capitalise[edit]

Is there a shortcut or template to write something instead of [[competition|Competition]]? I'm thinking of a template like Template:capit, where you type {{capit|competition}} and it shows up capitalised but with a link to the lowercase version. --Pious Eterino (talk) 18:13, 22 December 2018 (UTC)

If there is to be such a template, it would be more useful if it were called {{c}} (sadly already taken), {{u}}, or {{uc}}: the shorter the name, the fewer the keystrokes, the more the keystroke-saving applications. DCDuring (talk) 20:05, 22 December 2018 (UTC)
Funny you should ask. There is {{1}} which is intended to be substituted, and I only learned it existed because it has been nominated for deletion or at least renaming at “Wiktionary:Requests for deletion/Others#Template:1”. — SGconlaw (talk) 23:32, 22 December 2018 (UTC)
I agree such a template would be useful. Could we call it Template:capitalize with a redirect from T:cap (contrast T:caps), perhaps? - -sche (discuss) 00:17, 23 December 2018 (UTC)
Personally I have an aversion to capitalising where not necessary. I am a good customer of nocap=1. DonnanZ (talk) 19:12, 23 December 2018 (UTC)

Linking to * as a term[edit]

I just deleted Reconstruction:Translingual/, which was apparently due to our linking templates mistaking * for an empty reconstruction entry (see Special:WhatLinksHere/Reconstruction:Translingual/). Can we make them stop doing that without totally disrupting things? Chuck Entz (talk) 04:23, 23 December 2018 (UTC)

@Chuck Entz: Fixed. I don't think it'll cause any problems. — Eru·tuon 04:57, 23 December 2018 (UTC)
Not that I was worried, but it was, after all, a unique edge case- not worth any risk of chaos, however slight ... Thanks! Chuck Entz (talk) 05:12, 23 December 2018 (UTC)
{{l|mul|:*}} worked before. —Rua (mew) 21:44, 23 December 2018 (UTC)

Template:request box should be re-written to make it safe to use in list items, because the parser apparently terminates the list content surrounding it incorrectly.[edit]

I was trying to figure out why the use of {{request box}} inside a list causes "Stripped" tags to occur, and had come to the conclusion that the template needs to be rebuilt entirely.

Two different attempts to solve this are compared here - Template:rfap/sandbox, {{rfap}} being one of the template which was one of the templates, which caused the Linter extension to complain about "Stripped DIV" tags when the template concerned was embedded inside a list, due to the parsers apparent inablity to correctly read the DIV context when the template was placed inside a list item (see https://phabricator.wikimedia.org/T212509 amongst others)

I've tried to implement a (CSS) grid based approach in Template:request box/sandbox2 which does NOT yet behave identically to the original template.

Someone else implemented a DIV based (non grid based approach) in Template:request box/sandbox which does NOT yet behave identically to the original.

I was told in the phabricator ticket, that using TABLE's for layout was not appropriate, which is reasonable. However not all browsers support CSS Grid yet, and so I'm not happy about about using that approach long-term, if it's not going to work. Perhaps some of the more experienced template editors here will be able to use the sandbox templates to come up with a version of {{request box}} that doesn't get broken by the parser's apparent inability to handle mutli-line DIV's embedded inside lists in what would be a logical and consistent manner? Or alternatively figure out what the ACTUAL parser bug is so that it can be more effectively communicated to the Mediawiki development team, so it gets repaired properly, instead of normal contributors like myself being told to come up with ineffective work-arounds.?

CSS grid layout to replace one single row seems like overkill. What's missing in the DIV-based approach? – Jberkel 13:39, 23 December 2018 (UTC)
The image bounces to the top when the page width is reduced, That doesn't happen in the table based version. ShakespeareFan00 (talk) 18:06, 23 December 2018 (UTC)

Something is broken..[edit]

Can someone explain why a template is generating suprious HTML tags for one use case?

See Template_talk:descendants_tree#Something_is_broken.. ShakespeareFan00 (talk) 18:07, 23 December 2018 (UTC)

I see no bad display at [[bilivan]]. I use FF 64.0. DCDuring (talk) 19:00, 23 December 2018 (UTC)
try Reconstruction:Proto-Germanic/bilībaną ShakespeareFan00 (talk) 19:03, 23 December 2018 (UTC)
I see no bad display (unless the "?" doesn't belong in the inflection table.), certainly nothing in the descendants tree. DCDuring (talk) 19:11, 23 December 2018 (UTC)
Strange because for me it's saying there's a UL or LI tag too many. ShakespeareFan00 (talk) 21:26, 23 December 2018 (UTC)
Try different browsers. Or it may be something in your preferences, eg, CSS or JS. DCDuring (talk) 21:39, 23 December 2018 (UTC)

Template:rfc-sense and Template:rfd-sense[edit]

Have corrected versions in the respective sandbox, but it needs someone able to edit protected tempaltes to swap in the new versions ShakespeareFan00 (talk) 22:28, 23 December 2018 (UTC)

Yes check.svg Done. — Eru·tuon 23:02, 23 December 2018 (UTC)

Abuse filter idea: null feedback[edit]

Wiktionary:Feedback gets an awful lot of empty feedback (nothing beyond a page title header and the invisible "fill in your feedback here" comment code). It would be good to have an abuse filter blocking these frequent empty posts, which uselessly bloat the edit history. Equinox 03:31, 25 December 2018 (UTC)

Minor UI annoyance when typing a deletion reason[edit]

When you go to delete a page, the "other/additional reason" box is pre-populated with "content was: ____" (the current page contents). The text cursor is at the beginning, so you should be able to prepend an extra note: e.g. "empty category - content was...". But (at least in the latest Chrome) the cursor suddenly hops to the end of the text after a couple of seconds. So I am typing "empty" but I end up with "emp - content was - ty|" (if you see what I mean). A sort of race condition. Any fix? Equinox 07:16, 26 December 2018 (UTC)

Wikinews[edit]

Quite some time ago Wikinews used to pop up when a new item had been added. It doesn't do it (for me) any more, was this an unavoidable change? Could it return to its old habit? — Saltmarsh. 11:20, 28 December 2018 (UTC)

{{th-pron}}[edit]

Template invocation :

{{th-pron|อะ-เม-ริ-กา-เหฺนือ}}

Outupt:

<table cellpadding=10 style="border-spacing: 2px; border: 1px solid darkgray; text-align:center">
<tr><td bgcolor="fafeff" colspan="2" style="border-bottom:1px solid lightgray;border-right:1px solid lightgray;font-weight:bold">''[[w:Thai alphabet|Phonemic]]''</td><div class="th-reading"><td style="border-right:0px"><span lang="th" class="Thai ">อะ-เม-ริ-กา-เหฺนือ</span><br><small>ɒ a – <span title="Vowel sign appearing in front of the initial consonant." style="border:1px dotted gray;border-radius:50%;cursor:help">e</span> m – r i – k ā – <span title="Vowel sign appearing in front of the initial consonant." style="border:1px dotted gray;border-radius:50%;cursor:help">e</span> h ̥ n ụ̄ ɒ</small></td></tr></div></div>
<tr><td bgcolor="fafeff" rowspan="2" style="border-bottom:1px solid lightgray;border-right:1px solid lightgray;font-weight:bold">''[[Wiktionary:Thai romanization|Romanization]]''</td><td bgcolor="fafeff" colspan="1" style="border-bottom:1px solid lightgray;border-right:1px solid lightgray;font-weight:bold">''[[Wiktionary:Thai romanization|Paiboon]]''</td><td style="border-right:0px"><span class="tr">à-mee-rí-gaa-nʉ̌ʉa</span></td></tr><td bgcolor="fafeff" colspan="1" style="border-bottom:1px solid lightgray;border-right:1px solid lightgray;font-weight:bold">''[[Wiktionary:Thai romanization|Royal Institute]]''</td><td style="border-right:0px"><span class="tr">a-me-ri-ka-nuea</span></td></tr>
<tr><td bgcolor="fafeff" colspan="2" style="border-bottom:0px;border-right:1px solid lightgray;font-weight:bold">(''[[w:Standard Thai|standard]]'') [[Wiktionary:International Phonetic Alphabet|IPA]]<sup>([[Appendix:Thai pronunciation|key]])</sup></td><td style="border-right:0px"><span class="IPA">/ʔa˨˩.meː˧.ri˦˥.kaː˧.nɯa̯˩˩˦/</span></td></tr>
</table>

This is malformed, as there is a DIV generated OUTSIDE of a TD (which is bad structuring per HTML5) On a related note an attempt is made to close the DIV tag twice, also bad structuring. Can someone please have a look at the underlying module's assumptions and remove whatever is generating the incorrect HTML? ShakespeareFan00 (talk) 12:38, 28 December 2018 (UTC)

Wikimedia language code for Cantonese: zh-yue, or yue?[edit]

The Cantonese Wiktionary launched last month, as https://yue.wiktionary.org/ (with HTTP 301 redirects from https://zh-yue.wiktionary.org/). This creates some inconsistencies, because in some ways the code is now yue, but in other ways it's still zh-yue:

  1. A wikilink like yue:foo or zh-yue:foo still links to https://zh-yue.wiktionary.org/wiki/foo (which then redirects to https://yue.wiktionary.org/wiki/foo).
  2. The Cantonese Wikipedia is still https://zh-yue.wikipedia.org/ (with HTTP 301 redirects from https://zh.wikipedia.org/).
  3. {{t+|yue|foo}} produces foo (zh-yue) instead of foo (yue).

We can't do anything about #1 or #2, but #3 is under our control: Module:languages/data3/y specifies that yue has wikimedia_codes = {"zh-yue"}, but we can remove that if we want.

So:

  • Does anyone have any more context about the Cantonese language-code situation? Can we expect that #1 and/or #2 will change over time?
  • Does anyone know what-all effects it will have if we change Module:languages/data3/y to no longer specify that zh-yue is the Wikimedia language code for Cantonese?
  • Should we do that?

RuakhTALK
20:11, 28 December 2018 (UTC)

The Cantonese Wikipedia community has been asking for a move from zh-yue to yue for a long time, with no progress in sight. The details are somewhere on Phabricator. —Suzukaze-c 05:18, 29 December 2018 (UTC)
OK, thanks for the info! So, I think the best path for us is for Module:languages/data3/y to map the Wiktionary code yue to the Wikimedia codes yue and zh-yue (instead of just zh-yue as now). That will tell {{t+}} to say 'yue' instead of 'zh-yue', while still indicating that 'zh-yue' is a Wikimedia code that exists for the same language.
Does anyone object to my doing that?
RuakhTALK 18:30, 30 December 2018 (UTC)

Yes check.svg Done.RuakhTALK 05:06, 9 January 2019 (UTC)

Comma/semicolon[edit]

In T:alter and T:also (probably some more as well) the comma between two terms should be changed to a semicolon if the term before contains a comma so that it is easier to read. See the alternative forms at same old same old for example, which had to be done manually. It was not possible with ”See also”.Jonteemil (talk) 20:26, 28 December 2018 (UTC)

Ping anyone.Jonteemil (talk) 22:44, 7 January 2019 (UTC)
I think I would put a semicolon between all the terms if any of them contains a comma. — Eru·tuon 22:51, 7 January 2019 (UTC)
Done for both {{alter}} and {{also}}. — Eru·tuon 01:57, 8 January 2019 (UTC)
@Erutuon: maybe Module:nyms needs to be updated similarly. — SGconlaw (talk) 02:00, 8 January 2019 (UTC)
Did that too. — Eru·tuon 02:48, 8 January 2019 (UTC)
Great! Thanks. — SGconlaw (talk) 02:58, 8 January 2019 (UTC)

Perfect! Thanks!Jonteemil (talk) 09:54, 8 January 2019 (UTC)

T:head[edit]

What happened with t:head at , the transliteration overlaps the word itself. Please fix.Jonteemil (talk) 05:35, 29 December 2018 (UTC)

After further looking it seems like most of the words in Category:Khmer letters aren’t working too good with neither T:head nor T:km-letter. Also using head= and head2= for the second form doesn’t seem to work either.Jonteemil (talk) 05:54, 29 December 2018 (UTC)
I'm not seeing any overlap of characters or anything undesirable. It could be a browser-specific thing. My browser is Firefox; what's yours? — Eru·tuon 05:58, 29 December 2018 (UTC)
@Erutuon: Perhaps? I’m using Safari on my iPhone.Jonteemil (talk) 20:52, 29 December 2018 (UTC)

Is it possible the fix the Safari version?Jonteemil (talk) 16:24, 11 January 2019 (UTC)

It’s the same problem in desktop and mobile view.Jonteemil (talk) 16:26, 11 January 2019 (UTC)
At the moment I don't know what is causing the problem, partly because I cannot see it myself. If you could post a screenshot, that might help. — Eru·tuon 20:55, 11 January 2019 (UTC)
@Erutuon: desktop, mobile. Jonteemil (talk) 19:59, 14 January 2019 (UTC)
Huh. In addition to the overlapping characters, the code points KHMER SIGN COENG, KHMER LETTER LO (the second thing in the headword) are being rendered incorrectly in your browser. For you they are displaying as a plus sign and letter, but for me as a combining diacritic below a dotted circle (as they should, according to this blog post). The same issue has been reported here. Maybe the font in which the Khmer characters are displayed is not very good, or maybe it is an issue with the font-rendering engine. — Eru·tuon 22:04, 14 January 2019 (UTC)

Unfortunately I haven’t got a clue. Is it en.wikt. that can fix this or is this a more general inter-wikimedia thing that has to get fixed on a ”mother website” for all Wikimedia projects?Jonteemil (talk) 23:53, 14 January 2019 (UTC)

If it's a browser or font-rendering issue, it's not a Wikimedia or MediaWiki thing at all because MediaWiki and Wikimedia do not have control over how browsers or font-rendering engines treat Khmer characters. If it's a font issue, it could be fixed if MediaWiki:Common.css is assigning a font to the class .Khmr that does not render this combination of characters correctly. (On the other hand, maybe your device does not have one of the fonts in the font-family property for .Khmr installed, or does not have a good Khmer font.) But I am speculating. To determine if the problem somehow relates to MediaWiki or Wiktionary, you could try inserting the HTML for the headword into another website and see if it displays differently. — Eru·tuon 00:17, 15 January 2019 (UTC)
@Erutuon: I’m not entirely sure what you mean but I guess it’s just Apple that has to stop neglecting Khmer speaking people. Thanks for your help in the matter anyway!Jonteemil (talk) 22:00, 16 January 2019 (UTC)

Table of Contents won't stay shut[edit]

The table of contents used to shut & stay shut. Now, it keeps reopening itself. What can I do to keep it shut? Anjuna (talk) 15:23, 30 December 2018 (UTC)

This seems to be an issue that keeps popping up. I want the quotations to stay open, but on occasion they keep closing even though I have clicked on "show quotations" in the menu. I'm guessing it's a problem with a cookie. — SGconlaw (talk) 16:39, 30 December 2018 (UTC)

{{R:Cantalausa}} producing extra line[edit]

I'm not sure what I did to give this template an extra line at the end (see ensalada for example). Can someone remove it please? Ultimateria (talk) 15:45, 30 December 2018 (UTC)

You added a line break before the "noinclude" tag, which I've removed. (Also, you might want to think about applying {{cite-book}} for a consistent layout.) — SGconlaw (talk) 16:38, 30 December 2018 (UTC)

Good deeds for nerds[edit]

When editing hangi (and others) it struck me that any (English? noun) entry with an "uncountable" sense line but no uncountability in the en-noun template must be an error. So, there's something someone could do. Equinox 00:31, 31 December 2018 (UTC)

Not for this nerd. My good deed was to add |lang=en to the 500+ entries in Category:Language code missing/deftempboiler. That category is now empty, and just before the year ended. --Pious Eterino (talk) 20:06, 31 December 2018 (UTC)
It may be time to graduate to tasks that require some lexicographic knowledge or judgment. DCDuring (talk) 20:50, 31 December 2018 (UTC)
Any suggestions? --Pious Eterino (talk) 16:55, 1 January 2019 (UTC)
Besides what Equinox suggested, see WT:RFV#boning. There are many such bits of awkward wording, missing synonyms, too many synonyms instead of real definitions, non-substitutable definitions, etc. Most rewarding in my experience is to find them on one's own and fix them, particularly if there aren't too many (eg, fewer than 100, YMMV). Search using regular expressions in Cirrus search can be a "fun" way of getting a good, targeted list. Also using the Regex editor gadget can speed such edits. DCDuring (talk) 17:53, 1 January 2019 (UTC)

January 2019

Stripping of diacritics in word links[edit]

The page Reconstruction:Proto-Germanic/þeubaz contains a list of descendants of the Proto-Germanic noun *þeubaz, meaning "thief", and in that list, the following code appears:

** Old Danish: {{l|gmq-oda|thiūf}}

This outputs the line:

As is seen, the link is red, although the page thiuf actually exists. Shouldn't the linking template automatically strip the macron and similar diacritics? Certainly that's the common practice with other languages. I'm aware that one could use {{l|gmq-oda|thiūf|thiuf}} as a workaround, but I see no reason why the template should not strip the macron. —Pinnerup (talk) 15:58, 1 January 2019 (UTC)

That would be controlled under gmq-oda in Module:languages/datax. As you can see there are no entry name rules. If you understand the orthography of Old Danish and want that behavior it could be added. DTLHS (talk) 16:00, 1 January 2019 (UTC)
I've added the entry name replacements for Old Swedish, which remove macrons, to Old Danish. Let me know if that is incorrect or if something more is needed. — Eru·tuon 20:56, 1 January 2019 (UTC)
Looks good. Thank you! —Pinnerup (talk) 03:47, 3 January 2019 (UTC)
@Erutuon I'm not sure if tying the data of two languages together like that is a good idea in the long term. A person wishing to edit the Old Danish diacritics in the future will not be aware that they are also used for Old Swedish. —Rua (mew) 14:31, 3 January 2019 (UTC)
@Rua: I'm guessing there won't be a problem in this case, but I've added a note. — Eru·tuon 20:20, 3 January 2019 (UTC)

Sorting Old Irish verbs into cats based on future, preterite, and subjunctive paradigms[edit]

So I attempted to modify Module:sga-verbs to categorize based on preterite class, subjunctive class, and future class, but I believe I botched it and now the categories won't show the pages that are categorized in them. mellohi! (僕の乖離) 22:01, 5 January 2019 (UTC)

Could you point to some pages that should have these categories but don't? — Eru·tuon 22:03, 5 January 2019 (UTC)
@Erutuon: I have created Category:Old Irish é future verbs, Category:Old Irish f future verbs, and Category:Old Irish s preterite verbs so far. mellohi! (僕の乖離) 23:12, 5 January 2019 (UTC)
@Mellohi!: Okay, but please give me some entries that should be in those categories so I can test the module and figure out what's wrong. I'm not familiar with Old Irish. — Eru·tuon 23:18, 5 January 2019 (UTC)
@Erutuon: dogní, etarscara, lingid, canaid, adsuidi, actually pretty much any Old Irish verb, e.g. the many in Category:Old Irish simple verbs. Go to those entries, click on the future/preterite/subjunctive verb categories, and right now they contain zero pages. mellohi! (僕の乖離) 00:03, 6 January 2019 (UTC)
@Mellohi!: As far as I can tell, your changes are working. You need to look at the list of categories in the entries, not at the category pages. When I look at dogní, it has a bunch of categories like Category:Old Irish é future verbs on it. The category pages will eventually update. Category updates take a while. If you do a null edit on one of these entries (I just did one on dogní), it will show up on the category pages. — Eru·tuon 00:12, 6 January 2019 (UTC)
Ah, I initially thought that slow-updating cats were the reason when filing this question, and indeed it is. Thanks for confirming. mellohi! (僕の乖離) 00:23, 6 January 2019 (UTC)

They've broken the Delete page again[edit]

Now, if you have the input focus on the Reason text box, and press Enter, instead of the natural behaviour of submitting the form (by activating the Delete button), it instead — bizarrely — drops down the Reason list box to show the list of reasons! I have never before seen a UI where you could drop down a list using the keyboard when the list wasn't focused! And as usual this needless change violates my operating system's UI laws; they should always, always use standard GUI components unless absolutely necessary. Equinox 01:49, 10 January 2019 (UTC)

B-b-but my hipster JS enhancements :^(
Perhaps you could file a bug on Phabricator. —Suzukaze-c 04:46, 10 January 2019 (UTC)
Yes check.svg Done [1] Hardly know why I bother though. Bet they will either sit on it for a year or slap a WONTFIX and yell at me. Equinox 15:32, 11 January 2019 (UTC)
Well, they fixed it very fast and nobody snarked about my (IMO somewhat justifiable) nasty tone. So, double thumbs up. Equinox 22:18, 21 January 2019 (UTC)

Font size in template:l[edit]

In the last few hours some change has taken place that has led items enclosed in {{l|mul}} to display in a larger font than if they were enclosed in {{l|en}}. Why? DCDuring (talk) 04:00, 10 January 2019 (UTC)

An example is [[amaranth]] on which what should (IMO) appear as Amaranthus blitum appears as Amaranthus blitum when presented as {{l|mul|Amaranthus blitum}}. On my screen using FF 64.0.2 the font size seems nearly 50% larger in the second instance on this page. DCDuring (talk) 04:36, 10 January 2019 (UTC)
I have the same version of Firefox, but don't see a difference. I also couldn't spot any recent changes in the module, template, or MediaWiki namespaces that could cause this. — Eru·tuon 04:48, 10 January 2019 (UTC)
In Chrome you can right click and inspect the link and see all the styles applied to it, and toggle them to see which one is causing the font size difference. DTLHS (talk) 04:50, 10 January 2019 (UTC)
The problem includes various other languages.
BUT: It doesn't happen in Chrome.
It doesn't happen if I eliminate FF's zoom (It doesn't happen with Chrome's zoom. I need zoom to read the screen without glasses.)
I hadn't changed zoom for many months. The problem seems specific to the link function only in certain languages. It doesn't happen on Translation tables. Is there a page that has a words linked via {{m}} or {{l}} in lots of different languages? That would be ideal for determining the scope of the problem, however limited the circumstances that trigger it. I know that some languages and/or scripts need to have large font sizes for legibility. I can't see why there should be differences in font size for Translingual and English unless there is something happening in CJKV that led to a non-script-specific change in font size. I presume that CSS could be involved. DCDuring (talk) 13:03, 10 January 2019 (UTC)

Translation adder script stopped working[edit]

The translation adder box just disappeared (on both Firefox and Edge). Matthias Buchmeier (talk) 12:38, 10 January 2019 (UTC)

Sorry for the trouble, fixed. — Eru·tuon 12:55, 10 January 2019 (UTC)

New language/family request[edit]

I'd like to request that language codes be added for Proto-Otomi, Proto-Otomian, and Proto-Oto-Pamean, as well as family codes for Otomi and Oto-Pamean. There is already a family code for Otomian (oto) but no corresponding protolanguage. --Lvovmauro (talk) 09:19, 11 January 2019 (UTC)

@-sche Can you suggest codes for these? DTLHS (talk) 17:44, 11 January 2019 (UTC)
Proto-Otomian would use the family code plus -pro, thus oto-pro. For the Oto-Pamean family, the code would start with the code for Oto-Manguean (the next level up that has a code), so something like omq-otp, so then Proto-Oto-Pamean would be omq-otp-pro. I think we generally have family codes any time we have proto-language codes, so we'd create a family code for the Otomi languages starting with the nearest (next-highest) family to it that has a code, so something like oto-otm, based on which the code for Proto-Otomi would then be oto-otm-pro. (You don't have to categorize all the Otomi languages into the new "Otomi" family if you'd rather leave them in Otomian, I guess, but this way etymologies can say "from an Otomi language", and the systematic correspondance between family codes and proto-language codes is maintained.) I'll add these codes. (If you would particularly prefer some other abbreviation for the second part of any of these codes, lemme know.) - -sche (discuss) 18:14, 11 January 2019 (UTC)
The ancestors for each (proto)language need to be added too, otherwise Template:inh gives an error (e.g. hme). --Lvovmauro (talk) 07:58, 12 January 2019 (UTC)

Template:zh-der results do not match description[edit]

On the template page, the example is given:

垃圾:lājī, lèsè:rubbish

but even this example doesn't actually work on either the or pages (at least in preview). It treats the English translation as a Chinese romanization (italicizes it).

--Geographyinitiative (talk) 10:05, 11 January 2019 (UTC)

"etymology-only" script codes[edit]

@Erutuon, Octahedron80, -sche, I've talked about this before, but I'm wondering about the feasibility of having "etymology-only" script codes for historical and language specific nomenclature, like we do for language codes. For instance, Avst-paz or paz-Avst for Pazend, which can be used in cases like {{desc|sc=Avst-paz|sclb=1}} and {{sc|Avst-paz}}. It's been noted before that some of the codes in Module:scripts/data shouldn't have proper language codes of their own, like mzn-Arab. --{{victar|talk}} 21:00, 14 January 2019 (UTC)

Alternatively, in the cases of language specific script names, that could be defined with the language code itself. I'm also thinking about cases like {{der|fa|pal|sc=Avst|sclb=1}} => Pazend Middle Persian, instead of creating a language code like pal-paz. --{{victar|talk}} 21:36, 14 January 2019 (UTC)

I think to create "pal-Avst" is enough. (pal = Middle Persian) The language code-script code notation is already used for script variations. It can be used anywhere not limited to etymology. And we can also set a specific (Pazend) font for it. While "Avst" should be generic Avestan script. --Octahedron80 (talk) 01:31, 15 January 2019 (UTC)
@Octahedron80: I would be fine with that, but I was told that that isn't recommended (also note that I linked Module:scripts/data above already). @Erutuon, -sche? --{{victar|talk}} 02:36, 15 January 2019 (UTC)
@Wikitiki89, Erutuon, -sche, have you changed your opinion on this? How should I proceed? --{{victar|talk}} 19:46, 18 January 2019 (UTC)
@Victar: I'm thinking it's best not to add script codes to Module:scripts/data unless they will be used in language-and-script tagging. But what to do is not clear to me, because I'm not aware of all the places where these special script codes or script labels would be used. It would be helpful if you made a page listing the places in entries where you see a need for these special script labels and what templates they would be used in and possible template syntax: etymology section, descendants section, etc.; {{desc}}, {{der}}, etc. Our system of labels is quite baroque and complicated and I am not sure where these script labels would fit in, or if they would at all. — Eru·tuon 22:17, 18 January 2019 (UTC)
@Erutuon: What are your objections? --{{victar|talk}} 23:34, 18 January 2019 (UTC)
@Victar: To what? — Eru·tuon 23:34, 18 January 2019 (UTC)
@Erutuon: What are your objections to adding pal-Avst to Module:scripts/data. --{{victar|talk}} 23:36, 18 January 2019 (UTC)
@Victar: If it's just for a label, then it's different from most of the scripts already there and I guess it would need different data items; for instance, if it's not used in language-and-script tagging it would not need a list of characters because it would never be used in language data modules or returned by script recognition functions, but it would need label-related information. But I dunno; as I said, I need more information. — Eru·tuon 23:55, 18 January 2019 (UTC)
@Erutuon: Is it really "different from most of the scripts already there"? What makes it different from ku-Arab? --{{victar|talk}} 00:02, 19 January 2019 (UTC)
Oops, I didn't notice you said paz-Avest. That's different in that it isn't a combination of a valid language code and script code. paz is the language code for Pankararú, Avest isn't a script code but could be replaced with Avst. It also would be different from ku-Arab if it weren't used in language-and-script tagging (ku-Arab is used). — Eru·tuon 00:13, 19 January 2019 (UTC)
That was a mistype, which I corrected. I'm referring to what Octahedron80 suggested (and my original suggestion), using pal-Avest. How would that be different from ku-Arab? --{{victar|talk}} 00:18, 19 January 2019 (UTC)
Okay though that should be pal-Avst. If pal-Avst would not be used in language-and-script tagging, then it would be different from ku-Arab, which is. — Eru·tuon 00:35, 19 January 2019 (UTC)
@Erutuon: do you have an example of ku-Arab being used in "language-and-script tagging"? --{{victar|talk}} 00:38, 19 January 2019 (UTC)
@Victar: Search : insource:"ku-Arab" or : insource:"ku" insource:/ku\|[؀-ۿݐ-ݿࢠ-ࣿﭐ-﷽ﹰ-ﻼ]+/ to find more than a thousand examples. — Eru·tuon 00:43, 19 January 2019 (UTC)
Is that all you mean? Sure, I could give you dozens of examples of places where I could be doing {{der|fa|pal|𐬞𐬭𐬌𐬭|sc=pal-Avst|tr=prir|ts=parīr}} or {{m|pal|𐬥𐬋𐬭𐬋𐬰|sc=pal-Avst|tr=nōrōz}}, like here. --{{victar|talk}} 06:37, 19 January 2019 (UTC)
Sorry, a script code is used for tagging (i.e., inserted into a class attribute in the HTML) if it is in a language's data table and is returned by the script detection function (findBestScript) or if it is manually supplied to a template or a module function that tags. "Etymology-only script code" suggested to me it wouldn't be used in tagging, just as, when an etymology-only language code is used in a template or module function, tagging uses the code for the first non-etymology-only language in the chain of parent codes. For instance, {{cog|grc-dor|μᾱχᾰνᾱ́}} tags the word with grc (Ancient Greek) instead of grc-dor (Doric Greek). Analogically pal-Avst could be replaced with its parent Avst in tagging. But I guess that is not what you meant and I should have asked for clarification. — Eru·tuon 23:01, 19 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Erutuon: Maybe I'm missing something, but I'm just not seeing a good argument of why a pal-Avst script code shouldn't exist. Another important distinction of Avestan script between Middle Persian and Avestan, beside font and ligatures differences, is that MP sometimes wrote the script in the style of an abjad as seen in my {{m|pal|𐬞𐬭𐬌𐬭|sc=pal-Avst|tr=prir|ts=parīr}} example. That makes a huge difference if someone is fulfilling Avestan script requests. --{{victar|talk}} 06:25, 21 January 2019 (UTC)

@Victar: Yes, that's what I meant to imply: whatever I said that assumed pal-Avst wouldn't be used in tagging doesn't apply. I'm not enthusiastic about adding yet another language-code-prefixed script code used for one language; it would be nice to get rid of as many of those codes as possible. A difference in CSS properties does not require a separate script code, but "Pazend" as script label can be most easily achieved that way. (I finally added the CSS properties that you requested on the other thread.) Other solutions would be a map from language code to script label in Module:scripts/data, or a map from script code to label in the language data tables, or a separate table somewhere. Those methods would require modifying module architecture, but adding pal-Avst doesn't. — Eru·tuon 21:29, 21 January 2019 (UTC)
  • On the other thread about Pazend, it was proposed that the CSS selectors in MediaWiki:Common.css that use language-code-prefixed script classes could be replaced with a selector that combines a parent script class and language attribute (for example, .fa-Arab with .Arab:lang(fa)). I like this idea, but it means that selectors would be longer. I did a survey of the languages that use each of these script codes. Several of the language-code-prefixed script classes are used by multiple languages. fa-Arab is used by quite a few languages, so the selector .fa-Arab wherever it's used would have to be replaced with a very long list of selectors. So the proposal would greatly inflate some of the selectors in MediaWiki:Common.css (for instance, .fa-Arab.Arab:lang(fa), .Arab:lang(avd), .Arab:lang(awa), ...). Maybe it would be fine to remove some of the language-code-prefixed script classes though, the ones used by fewer languages. I mention this because it is relevant to the question of whether to have or add more language-code-prefixed script codes, or whether to get rid of them. — Eru·tuon 00:02, 20 January 2019 (UTC)

Category talk[edit]

Please see Category talk:German proper noun forms.Jonteemil (talk) 21:57, 16 January 2019 (UTC)

Capitalization in {{causative of}} template[edit]

The template {{causative of}} can be used in etymology sections to mark a verb as a causative of another verb, thus furnishing the page with the proper categories for causative verbs (e.g. Category:Proto-Germanic causative verbs). However, the template seems to always result in the text:

 causative of lemma

… even at the beginning of a sentence, where a capital "C" would be required. Is there any way to work around this, say by suppressing the leading text or perhaps coding it to capitalize the first "c" when used at the beginning of a line? Or is there some other method that should be used to mark verbs as causatives of other verbs? —Pinnerup (talk) 12:09, 17 January 2019 (UTC)

This template is meant for use in definitions, which is why it has italic text. Definitions aren't usually capitalised. —Rua (mew) 12:54, 22 January 2019 (UTC)
Many templates have named parameters like i, noi; cap, nocap; dot, nodot. It would be possible, even desirable, to universalize this. The default settings should reflect the most common current usage.
In the case of definitions of non-English words, prevailing practice is not to capitalize the first word of the definition, nor to end with a period ("dot"), contrary to the prevailing practice in English (and taxonomic) definitions. As it also provides a non-gloss definition, its text is italicized. Thus {{causative of}}, by default would have i, nocap, and nodot as defaults in my parameter scenario. DCDuring (talk) 13:29, 22 January 2019 (UTC)
I suppose categorization is also a concern. nocat and cat would be another pair of parameters. In a definition we probably want categorization, we almost certainly don't want {{causative of}} to categorize if it is used in etymology sections. The default would be cat.
The alternative of having pairs of templates with consistent naming, one for use in definitions, another for use in other places seems to me less desirable. DCDuring (talk) 13:37, 22 January 2019 (UTC)

"Pronounciation"[edit]

It seems like there are up to 2,524 entries with the following header: ===Pronounciation=== which is a misspelling of ===Pronunciation=== (Search here). KevinUp (talk) 19:22, 18 January 2019 (UTC)

Looks like a job for a bot. --{{victar|talk}} 19:44, 18 January 2019 (UTC)
@Suzukaze-c Maybe you can help with this? There's also ===Reference=== instead of ===References=== (1474 entries, search here)). KevinUp (talk) 06:53, 20 January 2019 (UTC)
Thanks to User:350bot, this job is now Yes check.svg Done. KevinUp (talk) 18:51, 21 January 2019 (UTC)

Category:German redlinks/l[edit]

I wish there's a hidden category like Category:Portuguese redlinks/l, but for German entries. --Lo Ximiendo (talk) 22:31, 18 January 2019 (UTC)

Why isn't there one? I don't see any special provision for Portuguese entries in the code. – Jberkel 12:54, 19 January 2019 (UTC)
See {{redlink category}}. The problem with adding a language to this is that it adds system overhead to every linking template (which includes translations), and there are many entries right on the edge of running out of execution time or memory. Chuck Entz (talk) 19:25, 19 January 2019 (UTC)
Oh, I understand now, I hope. --Lo Ximiendo (talk) 03:13, 20 January 2019 (UTC)

Vector hieroglyphs[edit]

I asked about SVG support for hieroglyphs in MediaWiki and there's now a ticket: phab:T214232. I'm not really familiar with our requirements so just wanted to post this here in case it needs more input, or if you have any recommendations for fonts to use. @Vorziblix, AearthriseJberkel 11:28, 19 January 2019 (UTC)

@Jberkel: SVG images would be nice. Would they be much slower to load than the current ones?
In the ticket there’s a mention of making ‘a map between our 2004 images and the hieroglyphs that were added to unicode in 2009’ to see what the overlap and discrepancies are. As it turns out, a year ago I made such a map; it’s available at User:Vorziblix/Mismatches between WikiHiero, Hieroglyphica, and Unicode and quite complete in its documentation of mismatches. (Any glyph that doesn’t appear there exists in both sets of glyphs and has the same Gardiner code in each). I hope it can be useful.
As far as fonts go, the Abydos font (which is ‘Free for any use’) is, IMHO, by far the best free font available for hieroglyphs at present. It covers not only the glyphs currently in Unicode but the much larger Hieroglyphica sign-list. Like WikiHiero, it has some mismatches with Unicode; the full correspondence is documented here: Module:Unicode_data/images/013. The Windows font Segoe UI Historic is definitely unusable, as it censors out several hieroglyphs by replacing them with rectangles.
It’s worth noting that the Unicode situation vis-a-vis hieroglyphs will be rapidly changing over the next few years; control characters that allow proper stacking of glyphs will be encoded on 5 March of this year, and there are several proposals floating around for expansions of the Unicode glyph repertoire in the near future as well. — Vorziblix (talk · contribs) 22:49, 19 January 2019 (UTC)
Thanks for the detailed response! I just quoted it verbatim on the ticket, hope that's ok. On disk the SVGs are significantly larger than the PNG files, but they can be optimized and compressed, so I don't think it will be much slower. I had a look the Abydos font, unfortunately it does not seem to be license-compatible. – Jberkel 00:13, 20 January 2019 (UTC)

Automatically expand all Quotations sections and Derived terms sections[edit]

Yes check.svg Done Hi. Briefly: How can we make the auto-collapsed "quotations" templates and "Derived terms" templates all automatically expand on page-load?

Notes and example links: In my User:Quiddity/common.js I've got 2 parts.

  1. The first part will sometimes successfully auto-expand the "Derived terms" (and similar) templates on page-load, e.g. it works at -logy#Derived terms, but not at time#Hyponyms and the related sections below that. (because of different templates being used in each case)
  2. The second parts contain my unsuccessful attempts (re-using code found elsewhere) to get the "Quotations" templates to auto-expand, e.g. at time#Noun or at ology.

Is there a better (more reliable) way to do the first, and is there any way to do the second?

Sidenotes: I tried searching archives, but couldn't see anything. And disabling JS entirely is not an option ;-) Thanks! Quiddity (talk) 22:43, 19 January 2019 (UTC)

@Quiddity: To always display quotations you can just use "Show quotations" on the left sidebar, under "Visibility". This will be stored in a cookie and persist through reloads. – Jberkel 23:27, 19 January 2019 (UTC)
Huzzah! Thank you.
I was sure there had been a gadget to do this, hence was really confused when it wasn't listed there. Of course it's in the mediawiki:sidebar !
(I tend to use multiple browsers/computer/accounts for testing things, so I use userscripts to make things consistent across them all. Your pointer helped me find the appropriate cookie name/value, and it works :). Thanks again. Quiddity (talk) 01:10, 20 January 2019 (UTC)

Latin conjugation template lists wrong forms in ōdī[edit]

Hiya. Latin has three defective verbs that are quite similar in many regards and all use perfect forms, having deposed their entire present system, namely meminī, ōdī and coepī. The entry for ōdī seems to use a template designed for meminī and not entirely applicable to other verbs, for it lists mementō and mementōte as imperative forms. Clearly, these are not imperative forms of ōdī (which has no imperative forms), but I've not been able to see how to suppress them. The template seems not to have any relevant documentation. —Pinnerup (talk) 16:59, 20 January 2019 (UTC)

nocat=y no longer works in {{affix}}[edit]

The template creates red-link categories even when the nocat=y paramter is added. There was a recent change in Module:compound/templates, could that cause this issue? Panda10 (talk) 16:08, 22 January 2019 (UTC)

Yes. User:Victar updated that page without updating the method signature of export.show_compound in Module:compound. DTLHS (talk) 16:13, 22 January 2019 (UTC)
Sorry about that, @DTLHS. I was adding a |g= parameter per this discussion. --{{victar|talk}} 17:23, 22 January 2019 (UTC)
It's ok, I'm just hoping the existing categories will eventually get back to their original state. For example, in Category:Hungarian words suffixed with -a, no words should be there, only the subcategory. Saving each entry without changes would help, but there are thousands of them. Panda10 (talk) 18:43, 22 January 2019 (UTC)
@Panda10, all categories will automatically update once the server cache clears. --{{victar|talk}} 03:58, 23 January 2019 (UTC)

Is it possible to trim images?[edit]

I added an image to ballerina, but I would like to trim the right-hand side; normally Commons do it. Is it possible on here? DonnanZ (talk) 00:17, 23 January 2019 (UTC)

Wikipedia has w:Template:Annotated image which appears to do this. We could probably copy / import it. We would need some more global CSS classes. DTLHS (talk) 02:01, 23 January 2019 (UTC)
That looks like a useful tool. I hope it doesn't slow image rendering too much. Can it be substed? DCDuring (talk) 03:08, 23 January 2019 (UTC)
It could be, but you would just get a bunch of raw HTML in the output. DTLHS (talk) 03:11, 23 January 2019 (UTC)
Commons also has a “CropTool“ (or something); it's in-browser and creates a new cropped upload. It might make reuse easier, if any one else also wants a cropped version. —Suzukaze-c 03:21, 23 January 2019 (UTC)