Wiktionary

Wiktionary:Grease pit/2018/December

< Wiktionary:Grease pit

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@Erutuon: Just about, but like this. --{{victar|talk}} 00:51, 2 December 2018 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
The || function is indeed strange when elsewhere one has |q=. Fay Freak (talk) 22:03, 2 December 2018 (UTC)[reply]
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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@Erutuon Ok yes, I probably got confused. Fay Freak (talk) 23:02, 2 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
@Rua This is not a good way because there are usually not more than half a dozen alternative forms, rarely 25 as in اسفناج; -sche (talk • contribs) 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)[reply]
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)[reply]

|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)[reply]

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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Yikes. Someone with admin rights, please fix. --{{victar|talk}} 16:35, 3 December 2018 (UTC)[reply]
@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)[reply]
I can fix it in about 9 hours, you probably want to revert that for now. DTLHS (talk) 16:55, 3 December 2018 (UTC)[reply]
@Vorziblix already did so. --{{victar|talk}} 16:59, 3 December 2018 (UTC)[reply]
Yes, for the time being. Just revert my edit when the template changes are ready. — Vorziblix (talk · contribs) 17:05, 3 December 2018 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @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)[reply]

OK, which entries do you want placed in the category? All entries using |language=? — SGconlaw (talk) 04:51, 4 December 2018 (UTC)[reply]
Yes, that will work. DTLHS (talk) 04:51, 4 December 2018 (UTC)[reply]
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)[reply]

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)[reply]

@DTLHS: your view? — SGconlaw (talk) 03:00, 5 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
That makes sense to me. DTLHS (talk) 22:04, 7 December 2018 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Would someone like to summarize for me what is being suggested here? — SGconlaw (talk) 06:08, 8 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@DTLHS: are the changes that I suggested on 8 December (see above) OK with you? — SGconlaw (talk) 03:04, 13 December 2018 (UTC)[reply]
Yes, that sounds reasonable. DTLHS (talk) 03:08, 13 December 2018 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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)[reply]

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)[reply]
I notice |worklang= is not defaulting to |lang=. Is this intentional? --RichardW57 (talk) 16:21, 14 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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)[reply]

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

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

In what way? It looks fine to me. — SGconlaw (talk) 13:11, 2 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Maybe just ask an administrator there what would be the best thing to do. — SGconlaw (talk) 15:33, 2 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Adblocker? Sometimes this happens to me with “Facebook". —Suzukaze-c◇◇ 19:14, 2 December 2018 (UTC)[reply]
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)[reply]
Great. And I learned something from the OT part of the discussion. DCDuring (talk) 13:27, 4 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
I couldn't select it either using Firefox, but could using Chrome. DCDuring (talk) 13:25, 4 December 2018 (UTC)[reply]
Strange indeed, as I’m using Firefox. — SGconlaw (talk) 13:26, 4 December 2018 (UTC)[reply]
and I'm using Chrome. SemperBlotto (talk) 13:29, 4 December 2018 (UTC)[reply]
I updated Firefox and could select it. DCDuring (talk) 13:38, 4 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
Suzukaze-c has created an entry for it. — SGconlaw (talk) 03:07, 5 December 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
OK, thanks for clarifying. — SGconlaw (talk) 09:15, 9 December 2018 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]
If you type [[seasnail]] {{qualifier|XYZ}} it will sort properly. — SGconlaw (talk) 22:35, 15 December 2018 (UTC)[reply]
@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)[reply]
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)[reply]
Oh yeah ... — SGconlaw (talk) 01:57, 17 December 2018 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

If it's lexicalised, then that means it's not longer the past participle. —Rua (mew) 22:36, 21 December 2018 (UTC)[reply]
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)[reply]

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)[reply]

prius is not given as a descendant, prior is. —Rua (mew) 22:37, 21 December 2018 (UTC)[reply]
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)[reply]

反犬旁兒 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)[reply]

@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)[reply]

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)[reply]

@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

@Chuck Entz: Fixed. I don't think it'll cause any problems. — Eru·tuon 04:57, 23 December 2018 (UTC)[reply]
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)[reply]
{{l|mul|:*}} worked before. —Rua (mew) 21:44, 23 December 2018 (UTC)[reply]

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)[reply]
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)[reply]

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)[reply]

I see no bad display at [[bilivan]]. I use FF 64.0. DCDuring (talk) 19:00, 23 December 2018 (UTC)[reply]
try Reconstruction:Proto-Germanic/bilībaną ShakespeareFan00 (talk) 19:03, 23 December 2018 (UTC)[reply]
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)[reply]
Strange because for me it's saying there's a UL or LI tag too many. ShakespeareFan00 (talk) 21:26, 23 December 2018 (UTC)[reply]
Try different browsers. Or it may be something in your preferences, eg, CSS or JS. DCDuring (talk) 21:39, 23 December 2018 (UTC)[reply]

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)[reply]

  Done. — Eru·tuon 23:02, 23 December 2018 (UTC)[reply]

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)[reply]

@Chuck Entz: Would you be at all interested in maintaining an edit filter like this, perhaps starting with my draft above? — Eru·tuon 03:06, 4 March 2019 (UTC)[reply]

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)[reply]

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)[reply]

Template: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)[reply]

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://yue.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)[reply]

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)[reply]
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)[reply]

  Done. —RuakhTALK 05:06, 9 January 2019 (UTC)[reply]

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)[reply]

Ping anyone.Jonteemil (talk) 22:44, 7 January 2019 (UTC)[reply]
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)[reply]
Done for both {{alter}} and {{also}}. — Eru·tuon 01:57, 8 January 2019 (UTC)[reply]
@Erutuon: maybe Module:nyms needs to be updated similarly. — SGconlaw (talk) 02:00, 8 January 2019 (UTC)[reply]
Did that too. — Eru·tuon 02:48, 8 January 2019 (UTC)[reply]
Great! Thanks. — SGconlaw (talk) 02:58, 8 January 2019 (UTC)[reply]

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

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)[reply]

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)[reply]
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)[reply]
@Erutuon: Perhaps? I’m using Safari on my iPhone.Jonteemil (talk) 20:52, 29 December 2018 (UTC)[reply]

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

It’s the same problem in desktop and mobile view.Jonteemil (talk) 16:26, 11 January 2019 (UTC)[reply]
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)[reply]
@Erutuon: desktop, mobile. Jonteemil (talk) 19:59, 14 January 2019 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
@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)[reply]

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)[reply]

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)[reply]

{{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)[reply]

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)[reply]

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)[reply]

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)[reply]
It may be time to graduate to tasks that require some lexicographic knowledge or judgment. DCDuring (talk) 20:50, 31 December 2018 (UTC)[reply]
Any suggestions? --Pious Eterino (talk) 16:55, 1 January 2019 (UTC)[reply]
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)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2018/December&oldid=78595088"