Wiktionary:Grease pit/2017/November

Why spell out the name of the month in templates? edit

I note that {{rft}} has a required parameter "m" with compels the name of the month to be spelled out. Why not permit the number of the month and a three-letter abbreviation? Too hard?

I further note that this template (and other request templates?) seem to be used less since 2016 when the number of required parameters increased. That means that someone looking at the entry would not be aware of the discussion. DCDuring (talk) 12:24, 1 November 2017 (UTC)[reply]

Using numbers is potentially better for localisation too. (Heh, I doubt this template will have to support the Hijri calendar or what not, but who knows?) Equinox ◑ 19:18, 1 November 2017 (UTC)[reply]

template:back-formation edit

I'd like to get rid of the extremely annoying full stop that is currently added automatically by {{back-form}}, and of the {{{nodot}}} parameter which it entails. There are currently fewer than a thousand transclusions; would it be possible to clean them up afterwards? Or could someone add me to the AWB list and I'll try and take care of it myself? --Barytonesis (talk) 14:19, 1 November 2017 (UTC)[reply]

nodot=yes has always seemed silly to me. I would rather type a single . where I need it than have to explicitly say that I don't want one by typing an entire parameter. Equinox ◑ 14:35, 1 November 2017 (UTC)[reply]

@Equinox: exactly. --Barytonesis (talk) 15:47, 1 November 2017 (UTC)[reply]

+1 —suzukaze (t・c) 16:04, 3 November 2017 (UTC)[reply]

Go for it. I can help with cleanup. – Jberkel (talk) 19:23, 6 November 2017 (UTC)[reply]

Well, if we're gonna do this manually, we might as well remove the default text altogether (as we're currently doing for {{bor}}, per Wiktionary:Votes/2017-06/borrowing, borrowed). What do you think? --Barytonesis (talk) 20:47, 6 November 2017 (UTC)[reply]

I think they're very different cases. The default text should be kept on {{back-formation}}. But the period should be removed from {{deftempboiler}} as well and all templates made from it. —Aɴɢʀ (talk) 21:08, 6 November 2017 (UTC)[reply]

[1]... Well, I'd better get to work! --Barytonesis (talk) 09:33, 7 November 2017 (UTC)[reply]

Form-of templates wrap their contents in a span with a special class. Are we ok with the dot itself being outside the span? —Rua (mew) 17:03, 7 November 2017 (UTC)[reply]

Save Changes versus Publish Changes edit

When editing a page, the button to save your work says "Publish changes". The text immediately above this says, "By clicking the “Save Page” button...". These should be consistent by changing the latter Special Message to match the former. -Stelio (talk) 15:24, 1 November 2017 (UTC)[reply]

It was changed to "Publish changes" fairly recently. Obviously someone forgot to change the wording above it. DonnanZ (talk) 16:23, 1 November 2017 (UTC)[reply]

Done —Μετάknowledge^{discuss/deeds} 16:48, 1 November 2017 (UTC)[reply]

Super; thank you very much! :-) -Stelio (talk) 16:52, 1 November 2017 (UTC)[reply]

Interestingly, this hasn't worked (or at least, not for me). I know that "wikimedia-copyrightwarning" is the correct Special Message by applying the "uselang=qqx" trick to display the underlying field names for messages. Forcing hard refreshes in my browser doesn't change what I see. I tried purging the message page as well, but to no avail. -Stelio (talk) 10:32, 6 November 2017 (UTC)[reply]

Corollary: the reason the message change wasn't showing for me is that I had my language set to "en-GB British English" rather than "en - English". -Stelio (talk) 20:52, 18 March 2018 (UTC)[reply]

Solved. Per utramque cavernam (talk) 21:48, 19 January 2018 (UTC)[reply]

Idea for an abuse filter edit

If there is a sequence of the form {{...}} on a single line, and a user's edit inserts a line break somewhere in the central ... portion (which might be anything), that's almost always vandalism. Heuristic: this kind of vandalism tends to be rather "small" (i.e. page size doesn't change much, maybe a few chars of gibberish added). This could be expressed with a regex, if anyone can be bothered. See e.g. [2]. Equinox ◑ 20:16, 1 November 2017 (UTC)[reply]

Yes, these can go undetected. I think I have found one or two cases before by checking my watchlist. DonnanZ (talk) 00:46, 2 November 2017 (UTC)[reply]

Is this really usually vandalism? I insert line breaks into template calls all the time. Sometimes {{der3}} will have a great long list of derived terms all written together as a block, and I'll add line breaks to make the individual entries easier to read. For the edit linked to above, I'd say what's noticeable is the deletion of the closing }}, not the insertion of a line break. —Aɴɢʀ (talk) 12:50, 2 November 2017 (UTC)[reply]

Ideas for a more advanced WT:ACCEL edit

@Dixtosa At the moment, the WT:ACCEL script makes use of the preload function to specify text that should be placed in the edit window as soon as the edit page is loaded. This allows you to quickly check and save the page without having to put in all the contents. Obviously it's a very useful tool, but it has drawbacks. A major drawback is that it only works if the page doesn't exist yet. If the page already exists (the link is blue/yellow) then nothing happens, and you have to put the contents in manually. That's not really ideal. A bot can do better, since it can parse the wikitext and figure out where to insert a new language section (for example diff).

This restriction is somewhat strange, though. A bot is just parsing code with a programming language, and WT:ACCEL is implemented in JavaScript, a programming language that is also capable of parsing code. There's nothing in principle that would disallow JavaScript from modifying wikicode, if it received the old wikicode (WT:EDIT does this in order to edit the translations). Of course, when you view an entry with blue/yellow links, the wikicode of all those other pages is not on the current page. There are ways to retrieve the wikicode of a page but this takes time (it's essentially another page request), and doing this for every single blue/yellow link is obviously not going to be feasible. On the other hand, the wiki software helpfully loads the page contents when you click the edit button, so if a script were to be made to automatically modify the wikicode in the edit window, that should work just fine. Essentially, this is what the preload facility that we currently use already does, except we'd be rolling our own custom version that does more.

Currently, it is the page containing the red/green link that generates the new contents, and this new contents is then appended as a new parameter onto the existing link URL. When you click the link to create the new page, the preload facility picks up on this URL parameter, and puts the text into the edit window. In practice, this means that every time a page is loaded, the ACCEL script goes through all the links, generates the new entry code, and modifies the URL, each time for every link. If our new version of ACCEL is going to run on the edit page instead, it makes a lot more sense to generate the page contents at that point, and not on the page containing the link. The linking page will load faster then, since it's not going to be busy generating content and modifying links each time someone views the page. The information will still need to be passed on via the URL in some way, but that could be done without any JS at all in theory. —Rua (mew) 15:59, 3 November 2017 (UTC)[reply]

I've created a partial version of the new script at User:Rua/Gadget-AcceleratedFormCreation.js. It differs from the original script in the following points:

The only "processing" a link undergoes is to add the form-of class attributes onto the URL, with a new accel= parameter. Some additional attributes are added, such as part of speech and page of origin. The URL will now look like this: https://en.wiktionary.org/w/index.php?title=soddjilis&action=edit&redlink=1&editintro=User:Conrad.Irwin/creation.js/intro&accel=pos-adjective%20origin_pagename-soddjil%20target-soddjilis%20form-of%20lang-se%20attributive-form-of
This URL is picked up on the edit page, where the new page content is actually generated and added to the edit window. The new content is thus not generated on the page with the link anymore. The existing creation rules that are currently already defined are re-used, since they work for the new system without changes.
The links themselves need no modifying.

At the moment, the script doesn't actually produce any new results. It still doesn't work for links to already-existing pages. When you click on a blue link, it takes you to that page, it doesn't take you to an edit window. It would probably be undesirable to turn such view-existing-page links into edit-existing-page links. Perhaps the script can be made to interface with the OrangeLinks gadget, so that it takes you to an edit page if the link is orange, but not when it's blue. I'm not sure how that would be done, though.

Because the new entry content is created only on editing the page, and only for that one page, we can do more time-consuming or resource-intensive things than we could otherwise. An interesting idea would be to convert the creation rules into a module, and have the script invoke the module. The module would then return the new text of the page, which the script would then place in the edit window, ready to be saved. This would allow much easier editing of creation rules and the addition of new ones, because people on Wiktionary are generally better with Lua than they are with JS, and you don't need to be an admin to edit modules. —Rua (mew) 19:55, 3 November 2017 (UTC)[reply]

I am glad you are looking into improving this great tool, and I think you have some good ideas for enhancements. One obvious problem for modifying existing pages is that, in order for the link to know if the target needs to be modified, it has to actually load the entire page. For a page with dozens of such links you could be loading dozens of pages with each page load, which can slow down the user as well as create quite a lot of overhead for the WMF servers. That doesn't mean that it shouldn't be done, it just complicates the issue. Have you thought about any way to avoid or minimize the amount of data loaded? The second step of actually inserting the text isn't as bad, since the API provides section editing which will limit the size of the creation URL considerably even on a large page. - TheDaveRoss 20:01, 3 November 2017 (UTC)[reply]

@TheDaveRoss I mentioned the OrangeLinks gadget, which turns links orange (more like yellow to me) when the language section in the fragment # of the URL is not present on the page. I don't know how it's implemented or if it's very inefficient, but at the very least if we already have that gadget, we have the information we need. An possible alternative approach is to not modify the links themselves, but to add an extra little link to the right of them, which takes you to the edit page but with a new entry added to the existing wikicode already. People would probably find that ugly, though. —Rua (mew) 20:14, 3 November 2017 (UTC)[reply]

Yet another possibility might be to modify links to existing pages so that they include the acceleration information, but to take the user to view the page as they'd expect to be. The script will then run on that page, see if there is already a language section for that language, and if not, it will display a large friendly message suggesting that the user click a certain link to add the new entry. It adds an extra step to the process - you have to first view the page before you get the edit link - but at least it's a lot easier than having to manually type all the code. —Rua (mew) 20:18, 3 November 2017 (UTC)[reply]

The new script is now at least capable of inserting new language sections in existing pages, if you give it acceleration parameters on an existing page. However, because of the above issue, no such links are actually generated yet. —Rua (mew) 22:31, 3 November 2017 (UTC)[reply]

I have it working! Now, the script will pick up on accelerated orange links, and modify them into edit links. Then, on the edit page, the new section is correctly inserted among the existing sections. —Rua (mew) 00:22, 4 November 2017 (UTC)[reply]

@Rua: I made a form-sorting function in Lua here. It's quite fast, and it's pretty simple to generate the maps used for the sorting. What do you think? — Eru·tuon 22:15, 12 November 2017 (UTC)[reply]

I can't really figure out what it does. Sorting cases is not usually needed. What matters is sorting singular before plural. But really, the system should be as agnostic as possible, so it should be limited to something like "this column goes before that column". The makers of the table would include HTML code in the right places to ensure this. The difficulty I'm having is how to actually make such code work. It's really a JavaScript/DOM/JQuery problem. —Rua (mew) 22:25, 12 November 2017 (UTC)[reply]

@Rua: So, if you have a case–number pair, each case has a number that indicates its rank in relation to other cases (nominative 1, genitive 2, ...). Same for numbers (singular 1, plural 2). Each morphological category has a number that indicates its rank in relation to other morphological categories (number 1, case 2). These numbers are used to create a base 36 number (string). (The base could be lower at this point, since there aren't anywhere near 36 cases, numbers, or morphological categories in the examples I chose.) The ranking of the morphological categories determines the order of the digits. For nominative singular, the number is 11, for genitive singular 12; nominative plural 21, genitive plural 22. The digit for number comes before the digit for case, so that singular always appears before plural. These numbers can then be sorted using the less-than operator. These ranks are generated from arrays listing the cases and numbers, and the morphological categories, in the order in which they should appear.

I dunno, using the HTML seems so complicated to me. I like a sorting method where the sorting is very explicit so you can tell what the result should be. — Eru·tuon 22:50, 12 November 2017 (UTC)[reply]

But what happens when a form isn't in your list, or when it's not easily sortable relative to other forms, such as a comparative form or a participle? —Rua (mew) 22:58, 12 November 2017 (UTC)[reply]

Either create ad-hoc categories for them so that they can be assigned rankings, or just have the sorting function leave them in their original positions. I guess I need to find some new examples to adapt the function to. — Eru·tuon 23:32, 12 November 2017 (UTC)[reply]

Is it really necessary to make things this complicated, though? What I'd much prefer is for the relative ranking of forms to be indicated as part of the table wikicode. That way, the script can stay agnostic about what the forms actually are, and it doesn't need editing whenever someone comes up with a new kind of form. —Rua (mew) 23:42, 12 November 2017 (UTC)[reply]

What do you mean? A new data- attribute that specifies the form's relative position? Or something else? — Eru·tuon 00:00, 13 November 2017 (UTC)[reply]

Actually a column number is what I had in mind. —Rua (mew) 00:04, 13 November 2017 (UTC)[reply]

I didn't know that was a thing. Oh, do you mean grabbing the nth cell in each row? Or is there some other way? — Eru·tuon 01:51, 13 November 2017 (UTC)[reply]

Right now, the script iterates through all accelerated links in a page, in the order that they are present in the HTML, and stores them in that order. My idea was that, if the script encounters a link for which a column number is set, then rather than directly storing the link, it stores it in an array (successively numbered table in Lua terms), indexed by the specified column number. So all entries with column 1 get put together, and all entries with column 2, and so on. Of course the entries in this array must eventually be stored like the rest, so there must be something that says at some point "ok, we're done with these columns, let's store them". One such trigger is obvious: when a link is encountered that's not in the same table. This would occur when the iteration moves on to another inflection table; of course it should be considered separately from the first. A second trigger is when the iteration encounters a link in the same table that lacks a column number. Both of these triggers "reset" the columnisation and cause everything that's currently in the column arrays to be stored. The storing itself is of course done in the order of columns: column 1 first, then column 2, etc. One final trigger is when the iteration reaches the end and there's no more links. —Rua (mew) 12:05, 13 November 2017 (UTC)[reply]

I've added column numbers to Module:se-adjectives (down the bottom), to illustrate. Reading from top to bottom, row by row, you first encounter the attributive form. It has no column number, so it's stored in sequence as usual. Then you encounter the nominative singular, which is stored in the array at index 1. Then the nominative plural, stored at index 2. This alternating pattern continues until the essive form. The essive has no column number, which triggers the emptying out of all the links currently in the column array. All entries in column 1 are stored, then all entries in column 2. Then the iteration continues in HTML order, so the essive is stored. The final order will be: attr, nom_s, acc_s, gen_s, ill_s, loc_s, com_s, nom_p, acc_p, gen_p, ill_p, loc_p, com_p, ess. —Rua (mew) 12:20, 13 November 2017 (UTC)[reply]

I've added them to Module:se-verbs as well, to illustrate a more elaborate example. Here, there's 6 columns. The first section contains columns 1 to 3, then the second section contains 4 to 6. The second section can't be labelled 1 to 3 because there is nothing in between the two sections that would trigger reset/storage. So additional column numbers are used. —Rua (mew) 12:48, 13 November 2017 (UTC)[reply]

I've updated the script with the method I proposed above, and it works. In Northern Sami adjective inflection tables, the comitative singular comes before the locative plural in the generated URL, and therefore also in the generated entry. —Rua (mew) 16:41, 13 November 2017 (UTC)[reply]

@Rua: That does sound like it will work. I was curious how it would work when the ordered list of items is oriented differently (say in Latin verb tables, horizontally, vs. Latin noun tables, vertically), but it's clear to me how those cases will work out now. The noun table will have the column number attributes and the verb table will not (at least, for the finite forms). I think "column" could end up being a misnomer, if the items with a certain column number aren't actually in columns, but I don't have any examples. I still like the idea of clearly writing out the order rather than having it hidden in the HTML, but if it works, it works. — Eru·tuon 07:36, 17 November 2017 (UTC)[reply]

Found a fatal bug with the automatic Arabic transcriptions. edit

If, in Arabic, the preposition لِ (li) is used in front of anything determined by ال (al-), the ا/ٱ of the article disappears by rule of Arabic orthography.
If, in Arabic, the determiner ال (al-) meets an alveolar, an assimilation occurs whereby the ل disappears in pronunciation but not in writing and the meeting alveolar is geminated, which is indicated in orthography by a shadda ـّ over the character representing the geminated consonant.
Now if لِ (li) is followed by ال (al-) and this by an alveolar, the templates on Wiktionary do not return a transcription.
1. For an example, see the Qurʾān 3:14 quotation in قَنْطَرَ (qanṭara). The word لِلنَّاسِ is affected. In the page I have written the second lām ل with a sukun ـْ, but this is an orthographic error, as in the case of the determiner meeting an alveolar no sukun may be placed, and also the resulting transcription is wrong *“lilnnāsi” instead of “linnāsi”. If you go there and remove the sukun by a hit on backspace, you will see in the preview that the transcription is gone.
2. I repeat the example here: لِلنَّاسِ versus لِلْنَّاسِ (lilnnāsi)
It seems to me that a fix is possible, because pursuant to the High Arabic phonotactics there is no other case that in vocalized text there is an orthographic word beginning with لِ (li), diacritic-free ل (l) and a geminated alveolar (or any other consonant).
Note that the displayings here of ـّ and ـْ are glitchy too. Palaestrator verborum (loquier) 23:07, 3 November 2017 (UTC)[reply]

@Palaestrator verborum: By "vocalized text", do you mean the Qur'an? what do you mean by High Arabic? --Backinstadiums (talk) 23:45, 3 November 2017 (UTC)[reply]

@Backinstadiums: I’d think that you have figured out this day already that there is a literary Arabic language which we conceptualize as the proper Arabic which has minute rules about allowed syllables and an unmistakeable system of orthographically representing its sounds, as is exemplified by the Qurʾān and as distinguishes it from Arabic dialects which all have different rules. Why do you only post questions instead of learning the grammar thoroughly? It should not take you more than two months, yet you only post questions since the creation of your account in November 2016 instead of making entries as you should be able to do if you can read Arabic. Palaestrator verborum (loquier) 00:15, 4 November 2017 (UTC)[reply]

@Palaestrator verborum: My grammar is still basic, since I've focused on vocabulary, yet I admit I don't like the material taken predominantly from Wehr's and Lane's. Furthermore, I have to learn how to edit properly, perhaps some JS, etc. I still do not understand what you mean by "there is no other case that in vocalized text..."--Backinstadiums (talk) 00:43, 4 November 2017 (UTC)[reply]

@Backinstadiums: It is my argument why it should be possible for the programmers here to fix it (or in @Atitarev’s words: why “this case is supposed to work”). Regarding your learning endeavors, I can only advise against such an approach. The concrete shapes of the words heavily depend on the grammar, synchronically and diachronically, and it pays out well to learn at the beginning the grammar from beginning to end as it is the shortest part of the language from which only you will understand idioms and the relations between words in the instances in which they are used. Really, I first read the whole grammar if I want to know a language and pick up not even thirty words in this act (that reading sometimes needs only two days!), then I am armed to read all kinds of texts, faster and faster. There is no such thing as immersion – you do not have the time or opportunities or necessities babies have for the language to pour in upon them. Palaestrator verborum (loquier) 01:18, 4 November 2017 (UTC)[reply]

@Palaestrator verborum: This is a digression from the topic but everyone's abilities and interests are different. I'd prefer beginners take their time learning rather than creating in bulk erroneous entries. The Arabic grammar is very difficult too and you can't get a good exposure to it without understanding some words, being able to read and in order to read an unvocalised Arabic text and without transliteration, you need to know those words and grammar, common patterns. The matter is further complicated by the fact that, simply put, nobody speaks the written language and nobody writes the spoken dialects. Complex grammar such as Russian can be learned by reading texts without using aids such as transliteration or vocalisation and listening to it. It is so much harder to get this exposure in Arabic. --Anatoli T. ^{(обсудить}/^вклад) 01:30, 4 November 2017 (UTC)[reply]

Of course one shall only create entries when one has the necessary degree of sureness about them – but obviously exactly to exclude errors in the entry creation one should know the whole grammar, while on the other hand nobody needs to know the whole vocabulary of a language; the pursuit of completing it is what drives us here to create entries: The memorial enhancement brought forth by adding entries as well as the inner altercation with the words and the language wherewith you describe. Is there an off-topic demarcator template? Should be made. Palaestrator verborum (loquier) 01:49, 4 November 2017 (UTC)[reply]

Topics just get split but the general discussion we had, had nothing to do with the purpose of the Grease pit. --Anatoli T. ^{(обсудить}/^вклад) 01:56, 4 November 2017 (UTC)[reply]

@Palaestrator verborum: There is no reason for لِلنَّاسِ to fail, since we have an identical working example: بِالتَّأْكِيد (bi-t-taʔkīd). It works well without explicitly providing hamzatu l-waṣl ٱ. You can see this and similar in Module:ar-translit/testcases. Please add another test case and any other glitches. --Anatoli T. ^{(обсудить}/^вклад) 00:29, 4 November 2017 (UTC)[reply]

Oops, I just noticed that your case doesn't have an alif. Not sure, if this case is supposed to work now. --Anatoli T. ^{(обсудить}/^вклад) 00:32, 4 November 2017 (UTC)[reply]

Hmm, my comments were simply wiped out by User:Backinstadiums. I am sure it wasn't intentional. --Anatoli T. ^{(обсудить}/^вклад) 00:49, 4 November 2017 (UTC)[reply]

I added some examples to the testcases. — Eru·tuon 01:34, 4 November 2017 (UTC)[reply]

@Erutuon: Swell, but the entry لِلَّبَنِ (li-l-labani) contained by the testcases looks imaginary to me. There is no such thing as full graphical elision of the determiner, as far as I know, so we have لِللَّبَنِ. Example found on the web: “هل تعلمي أن لللبن الرائب فوائد أخرى عديدة أكثر من مجرد تهدئة القولون أو علاج عسر الهضم”. That is “li-l-labani”, the entry here is “li-labani” without any article (else how would you know if it is determined or not?). Also that is obviously a SOP, so, well, why not delete it? Palaestrator verborum (loquier) 02:39, 4 November 2017 (UTC)[reply]

@Palaestrator verborum: Well, I thought a series of three lams was shortened to two. I could be mistaken. There would be ambiguity, but language is often ambiguous. As for the entry, @Stephen G. Brown probably had a reason for creating it. Propose deletion if you want. — Eru·tuon 02:51, 4 November 2017 (UTC)[reply]

The reasons then and now may be different. The notion that everything spelled without spaces is a word, even for languages that do use spaces between words is not always true. --Anatoli T. ^{(обсудить}/^вклад) 02:56, 4 November 2017 (UTC)[reply]

My copy of Arabic: an Essential Grammar (p. 57) says that three lams are indeed simplified to two, so لِـ (li-) + اللُّغَةُ (al-luḡatu) is لِلُّغَةِ (lilluḡati), a homograph of لِلُغَةِ (liluḡati) when written without diacritics. But apparently, from the example you give, this rule is not always followed. — Eru·tuon 03:47, 4 November 2017 (UTC)[reply]

Back to the topic, the new cases لِللَّبَنِ or لِلتَّأْكِيذ are weak. What we have is "lām + nothing + sun letter + šadda + vowel" in the middle of a word. The module expects to have a vowel point where it sees nothing. It works for definite articles at the beginning of words or after prepositions but dropping the alif makes it very ambiguous. It should continue failing, IMO and a manual transliteration needs to be provided, unless a stronger case is provided to show that only an abbreviated definite article can happen in this position and not another lām in an incompletely vocalised word. --Anatoli T. ^{(обсудить}/^вклад) 03:24, 4 November 2017 (UTC)[reply]

Yuck, Wolfdietrisch Fischer writes in § 22 of his Grammatik des klassischen Arabisch:

“In einigen feststehenden Verbindungen wird alif al-waṣl nicht geschrieben.:

a) bei der Verbindung der Partikel la- und der Präp. li- mit dem Artikel: لِلرَّجُلِ lir-raguli (statt لالرجل‎), لَلْمَجْدُ lal-maǧdu (statt لالمجد). Beginnt in solchen Fällen das folgende Nomen mit ل, wird das ل des Artikels nicht geschrieben: لِلَّيْلَةِ lil-laylati (statt لالليلة‎), لِلّٰهِ lil-lāhi ‘für Gott’ (statt لالله).”

According to this it is classical to drop the ل – honestly that seems weird to me according to current standards and I have to ask some native speakers about the current stringency. But for the module it means that that case has to be handled, as Classical Arabic is also Arabic in Wiktionary – the current evidence points to both cases being in need of handling. Note the transcriptions given by Fischer. Palaestrator verborum (loquier) 03:48, 4 November 2017 (UTC)[reply]

The search for للله takes significantly more to scroll down than the search for لله. Note لله and the discussion page, Anatoli. / I did not see btw a need for a text direction fix. The bidi implementations are awful, they apparently even differ across browsers. / Whatever, I am becoming silly and need to sleep. Palaestrator verborum (loquier) 03:59, 4 November 2017 (UTC)[reply]

@Palaestrator verborum: I'm not sure why you said "yuck". I am not arguing and I wasn't arguing the correctness of the case as a reading rule (for humans) but for the module, we need to make sure there are no other cases, where unpointed lām is not part of an abbreviated ال to avoid mistransliterations. --Anatoli T. ^{(обсудить}/^вклад) 10:05, 4 November 2017 (UTC)[reply]

@Atitarev: I’m sorry for your feeling offended. I have not referred to anything you said but said yuck about the whole topic and this uncertainty (the indentitation level was supposed to relate to my own message just before it). As it seems that if that rule of § 22a applies, there is no way for the module to recognize the article. So it will always be a bit wrong only by not adding a hyphen. But understanding now what you have said, I think if diacritic-less lām is not part of an abbreviated ال (al-), it is just incomplete transcription and the editor is liable for providing such a transcription; whereas it is of highest importance that the module does not fail with nil if a completely and correctly vocalized Arabic text is provided (it is too regrettable if it fails for just this). And yet also we do not know cases “where unpointed lām is not part of an abbreviated ال (al-)”.

@Heydari, do you know any such cases? And if we are on it, how do you esteem spellings like “لِللَّبَنِ”. A matter of taste? Wrong, but pleasant? Horrifying? Justly prefered these days? Palaestrator verborum (loquier) 14:00, 4 November 2017 (UTC)[reply]

@Palaestrator verborum: No problem, keep up the good work in Arabic! --Anatoli T. ^{(обсудить}/^вклад) 23:12, 4 November 2017 (UTC)[reply]

@Palaestrator verborum Does prefixing لِـ change the nature of the velarized /ɫ/ of لله? Otherwise the pronunciation should show ɫ --Backinstadiums (talk) 10:54, 4 November 2017 (UTC)[reply]

@Backinstadiums Good question, but I am the wrong man asked, I hardly ever hear Arabic speech. Palaestrator verborum (loquier) 14:00, 4 November 2017 (UTC)[reply]

@Backinstadiums: Yes. You can see an example of that in Module:ar-pronunciation/testcases. [edit: To be clear, I think it happens after the vowel /i/, long or short, so there are many more possible examples. At least, that's what the module assumes.] — Eru·tuon 19:11, 4 November 2017 (UTC)[reply]

@Erutuon, Palaestrator verborum: According to this forum, it's right --Backinstadiums (talk) 21:03, 4 November 2017 (UTC)[reply]

Confirming. I replied to you in Talk:لله. --Anatoli T. ^{(обсудить}/^вклад) 23:12, 4 November 2017 (UTC)[reply]

Wiktionary:Quotations edit

Hello. How I can use Quotations function in other wiki projects? Which extensions, templates or gadgets required? --Drabdullayev17 (talk) 09:00, 4 November 2017 (UTC)[reply]

@Drabdullayev17: Are you referring to the JavaScript code that allows quotations to be shown and hidden? I did a search and it seems to be located in MediaWiki:Common.js (search for "Hidden Quotes" and "Visibility toggling"), but other people such as @Dixtosa or @Rua might know more about it. — Eru·tuon 21:30, 4 November 2017 (UTC)[reply]

Thanks @Erutuon:, I did it but it didn't solve my problem. --Drabdullayev17 (talk) 06:16, 5 November 2017 (UTC)[reply]

@Drabdullayev17: I was simply showing you the code. I can't promise this will work, but you could try copying it to the User:Drabdullayev17/common.js file on the wiki where you want to use it. — Eru·tuon 09:58, 5 November 2017 (UTC)[reply]

template:fr-noun and other headline templates edit

It's not terribly important, but would it be possible to add automatic parsing of words like attentat-suicide, trait d'union and à l'instar de? Currently, one has to use the parameter {{{head}}} and write manually "[[attentat]]-[[suicide]], [[trait]] [[d']][[union]] and [[à]] [[l']][[instar]] [[de]]". --Barytonesis (talk) 10:59, 4 November 2017 (UTC)[reply]

I'd rather not, because automatic parsing like that isn't language-specific as far as I know, which means there would have to be a break at a hyphen and apostrophe in all languages. And I don't want English won't parsed as [[won']][[t]] or Irish t-athair as [[t-]][[athair]]. —Aɴɢʀ (talk) 13:43, 5 November 2017 (UTC)[reply]

@Angr: Would it be technically feasible to make it apply only to French? --Barytonesis (talk) 10:49, 6 November 2017 (UTC)[reply]

I don't know. —Aɴɢʀ (talk) 11:13, 6 November 2017 (UTC)[reply]

languages offered for a certain entry edit

I am concerned about the languages offered for a certain entry in the English version of wiktionary. That is, for https://en.wiktionary.org/wiki/a, there're 99 languages with the term "a" in their lexicon, all of them explained in the English language (for example, for french, https://en.wiktionary.org/wiki/a#Etymology_3_12 the third etymology reads "third-person singular present indicative of avoir".

Yet, you could choose the French interface to see the same info., https://fr.wiktionary.org/wiki/a#Forme_de_verbe.

Now , I want to limit the languages which show the term that's been searched, not those of the interface offered on the lelft of the page. --Backinstadiums (talk) 12:48, 6 November 2017 (UTC)[reply]

Arabic translit fails on fully vocalised texts edit

I can't figure out why it fails here:

هٰذَا ٱلرُّوبُوت اَلَّذِي يَتَكَلَّمُ ٱلْعَرَبِيَّة

hāḏā r-rūbūt allaḏī yatakallamu l-ʕarabiyya

This is a robot, which can speak Arabic

but not here هٰذَا ٱلرُّوبُوت اَلَّذِي يَتَكَلَّمُ ٱلْعَرَبِيَّة (hāḏā r-rūbūt allaḏī yatakallamu l-ʕarabiyya)? It requires a manual transliteration, since "robot" is pronounced in a non-standard anglicised way "rōbōt", not "rūbūt" but something's going wrong with one of the modules. It works with {{m}} but not with {{ux}}. @Erutuon, Palaestrator verborum. --Anatoli T. ^{(обсудить}/^вклад) 12:53, 6 November 2017 (UTC)[reply]

@Atitarev: It's because of a right-to-left mark at the end of parameter 2 in {{ux}} above that is not present in {{m}}. I can see it because I have the wikitext syntax highlighting beta feature enabled. That makes the has_diacritics function think that the text isn't properly vocalized. Perhaps the module should ignore right-to-left and left-to-right marks so that bizarre stuff like this doesn't happen. — Eru·tuon 19:32, 6 November 2017 (UTC)[reply]

Okay, now Module:ar-translit ignores these marks when determining if text can be transliterated, but tracks them in ar-translit/lrm or rlm. — Eru·tuon 19:58, 6 November 2017 (UTC)[reply]

@Erutuon: Thank you for fixing this! Now, there's a new problem. It seems that using {{ux}}, it thinks that there is a final sukūn, although I haven't even entered a full stop to avoid this, so the final word with an unpointed tāʾ marbūṭa is transliterated as "ʿarabiyyat" but should be "ʿarabiyya". --Anatoli T. ^{(обсудить}/^вклад) 13:02, 7 November 2017 (UTC)[reply]

@Atitarev: Okay, that's fixed too. It was because of the final right-to-left mark (again), which made the module think the tāʾ marbūṭa wasn't final. — Eru·tuon 18:51, 7 November 2017 (UTC)[reply]

@Erutuon: Thanks for the efforts! Do you think you can make it work with the punctuation as well?

هٰذَا ٱلرُّوبُوت اَلَّذِي يَتَكَلَّمُ ٱلْعَرَبِيَّة.

hāḏā r-rūbūt allaḏī yatakallamu l-ʕarabiyya.

This is a robot, which can speak Arabic.

--Anatoli T. ^{(обсудить}/^вклад) 05:18, 8 November 2017 (UTC)[reply]

@Atitarev: Done! Hopefully it's okay to do it with all punctuation; I can't think of any counterexamples at the moment. — Eru·tuon 05:28, 8 November 2017 (UTC)[reply]

Struck this out as solved. --Per utramque cavernam (talk) 13:36, 4 January 2018 (UTC)[reply]

Links in category lists edit

Is it somehow possible to make the links in category lists go to the correct language? (without too much effort). Very annoying to have to click through to the right entry sometimes. – Jberkel (talk) 19:26, 6 November 2017 (UTC)[reply]

Yes, this is already implemented for most categories. What category are you referring to? DTLHS (talk) 19:26, 6 November 2017 (UTC)[reply]

What do I have to do to enable it? For example, I recently created Category:Italian nouns with multiple plurals. – Jberkel (talk) 10:06, 7 November 2017 (UTC)[reply]

Does {{catfix}} do what you want? I put it on the category you mentioned. —Aɴɢʀ (talk) 10:34, 7 November 2017 (UTC)[reply]

Yes, thank you! – Jberkel (talk) 11:03, 7 November 2017 (UTC)[reply]

Struck this out as solved. --Per utramque cavernam (talk) 13:37, 4 January 2018 (UTC)[reply]

Abuse filter 73 help edit

Trying to forbid references as a level two header in the main namespace. article_namespace == 0 & new_wikitext rlike "\n==\s*References\s*==\s*\n" seems not to work at all- what should the regex be? DTLHS (talk) 21:40, 6 November 2017 (UTC)[reply]

Looks like it is working to me, perhaps you tweaked it since you asked. You might want to add the inverse for old_wikitext if you don't want to flag entries which already have References as an L2. - TheDaveRoss 15:23, 7 November 2017 (UTC)[reply]

@DTLHS you may wish to consider added_lines_pst as that is the most accurate for new additions, otherwise you are testing the entire rendering of the updated page. If doing that I would suggest that you ignore the new lines and focus on the target text so a regex something like ={2}\s{,3}references{,3}={2} (note this is untested), it also shortens the length of your wildcard searches, and either make it [rR] or irlike just in case they don't follow your case pattern. — billinghurst sDrewth 02:57, 8 November 2017 (UTC)[reply]

Template alerts for `{{bor}}` edit

The {{inherited}} template helpfully generates an alarm if an editor tries to enter a source language that is not an ancestor of the target language. I wonder if we could do something similar with {{borrowed}}? I believe most users agree that {{bor}} is only supposed to be used for the last derivation in a chain, so e.g. Hungarian láma is not supposed to be marked as a borrowing either from Quechua (the animal) or Tibetan (the title). We in fact do not expect to see any direct borrowings between Hungarian and Quechua, or Hungarian and Tibetan. There are going to be at least hundreds of other pairings like this, where language A very well might have words derived from language B, but they're all going to be mediated by some other language.

For a rough first approximation, would it be possible to:

divide languages as having one or more specific regions;
generate errors for borrowings between non-adjacent regions. (We should clearly not limit things to just one region, since their boundaries are going to be fluid.)

A region in this sense is not merely the native region of a language, but the region where it has speakers at all. "Global" languages like English could be assigned to every or almost every region, so they would almost never trigger errors. (Maybe for regions like "ancient Middle East", but I doubt anyone is going to go in good faith marking e.g. Akkadian words as borrowings from English anyway.)

By "generating an error" I do not necessarily mean an explicit template error — a maintenance category "nonsensical borrowings" or "suspicious borrowings" might be sufficient. --Tropylium (talk) 12:03, 7 November 2017 (UTC)[reply]

This sounds like an enormous amount of effort to set up and maintain compared to quite a modest benefit. I wouldn't even say it's a mistake to say that Hungarian láma is borrowed from Quechua and Tibetan: it is borrowed from those languages, just not directly. —Aɴɢʀ (talk) 13:53, 7 November 2017 (UTC)[reply]

I agree that we should only use borrowing for the final step in an etymology, but enforcing that is not going to happen until we can put an entire etymology into one template invocation. DTLHS (talk) 02:48, 8 November 2017 (UTC)[reply]

@DTLHS Your dumps can help, though. —Rua (mew) 12:08, 9 November 2017 (UTC)[reply]

If you are doubtful, just alter them to {{der}}. Like all the proto stuff in many entries, they are often not directly inherited or borrowed and some editors get carried away with the use of {{inh}}. DonnanZ (talk) 12:42, 10 November 2017 (UTC)[reply]

In page anchors? edit

What is the process for linking to a specific part of a definition on a page. As sub-headings are not unique, about the only place to which I can link uniquely is the language sub-heading, and for a page with multiple meanings/uses, I would like to be more specific in my linking. Thanks. — billinghurst sDrewth 02:46, 8 November 2017 (UTC)[reply]

@billinghurst: Use the |id= parameter in linking templates. This links to an HTML id created by {{senseid}}. For instance, {{m|en|-er|id=agent}} → -er. Also works in {{affix}} and related templates, only the parameter needs a number to specify which component the id applies to: {{affix|en|teach|-er|id2=agent}} → teach +‎ -er. — Eru·tuon 04:06, 8 November 2017 (UTC)[reply]

@Erutuon I am only an occasional editor of Wikt:, and definitely don't know the ins and outs, so there is a little (big?) gap in what you are explaining and where my knowledge lies. Nothing at category:Linking templates or category:Internal link templates assists. Are these innate to current labels, or do they need to be explicitly added when one wants to make them an anchor? I had wanted to link to one of the definitions within may#English and I don't see those templates overtly used. Thanks. — billinghurst sDrewth 04:47, 8 November 2017 (UTC)[reply]

@billinghurst: If {{senseid|language code|id code}} is not in the definition line that you want to link to, you must add it. Once the senseid template is there, it can be linked to by putting the id code into the linking template. For the {{l}} template, that looks like {{l|language code|page name|id=id code}}. For instance, in the -er entry, one of the definition lines is # {{senseid|en|agent}} {{lb|en|added to verbs}} A [[person]] or [[thing]] that ... ., and the template code {{l|en|-er|id=agent}} creates a link to that definition line. Does that help? — Eru·tuon 05:07, 8 November 2017 (UTC)[reply]

Yes, thanks. It would be useful to put it into some guidance page here for other intrepid wikimedians who wander by. — billinghurst sDrewth 07:12, 8 November 2017 (UTC)[reply]

What about anchors to subsections? For example, how would I link to Etymology 2 of Irish bán? {{l|ga|bán|id=Etymology 2}} doesn't work, and I don't suppose it would be kosher to write ==={{senseid|ga|grassland}}Etymology 2===. Sometimes I want to link to the whole Etymology section and not just a single sense line. —Aɴɢʀ (talk) 12:42, 8 November 2017 (UTC)[reply]

Well, [[bán#Etymology 2]] links to the first Etymology 2 header on the page, which happens to be the Hungarian one at the moment. [[bán#Etymology 2 2]] (I recently discovered this) links to the second Etymology 2 header. Currently that's the Irish one. Either of those links will end up going to a different section if another Etymology 2 header is added above them. There's no way for the linking template to figure out which Etymology 2 header is in which language section, except by getting the page content and doing a search, which would be costly. Maybe you could use {{senseid}} in the etymology section (which I don't particularly like the idea of, but maybe it should be allowed), or {{anchor}} (in which case you have to do something like {{l|ga|bán#anchor name|bán}}). — Eru·tuon 05:23, 9 November 2017 (UTC)[reply]

No wait, {{l|ga|bán#anchor name|bán}} doesn't work; it links to [[bán#anchor name#Irish]]. Hmph. — Eru·tuon 05:24, 9 November 2017 (UTC)[reply]

So, [[bán#Etymology 2 2]] works as a bare link, but there's no way to get {{l|ga|...}} to link to it, because {{l|ga|...}} will always add #Irish to the URL? That's frustrating. —Aɴɢʀ (talk) 11:30, 9 November 2017 (UTC)[reply]

@Angr: I'll take a look at the module and see if that can be fixed. # can only be used for anchors in wikilinks, and the module shouldn't add another anchor after an existing one. — Eru·tuon 17:22, 9 November 2017 (UTC)[reply]

Okay, it's fixed. — Eru·tuon 17:54, 9 November 2017 (UTC)[reply]

What does it do now instead? —Rua (mew) 19:08, 9 November 2017 (UTC)[reply]

Now, {{l|ga|bán#Etymology 2 2|bán}} links to [[bán#Etymology 2 2]], as I think a naive user would expect it to. (So it has the same result as {{l|ga|[[bán#Etymology 2 2|bán]]}}.) — Eru·tuon 19:17, 9 November 2017 (UTC)[reply]

But what if that section isn't actually in the English section? —Rua (mew) 19:27, 9 November 2017 (UTC)[reply]

Oops, it isn't. (Wrong language code. Changed it from en to ga.) Well, that would be unfortunate. The module probably can't check it, because it would be extravagant in processing time and memory to load and search the page for every link that has a manually inserted fragment. Similarly, the module can't check whether a sense id is present in the language section. The fragment could be removed if it isn't a sense id or language name, but that would be confusing for users and it would add to processing time and memory, as the module would have to check if the putative language name in the anchor was valid. (It would sometimes have to check twice: for {{l|en|-er#English-agent|er}}, whether English-agent was a language code, and then whether English was a language code.) Checking the validity of fragments and sense ids might be easier for a bot. — Eru·tuon 19:42, 9 November 2017 (UTC)[reply]

The problem actually runs deeper than that. When someone links to an English section, we know which specific section they intended to link to. With "Etymology 2", there's no such guarantee, since it just picks the first section with that name. It could be in the wrong language section, or it could be in the right language section but not actually be the Etymology section that the linker intended to link to (because someone rearranged the entry). This is why I generally remove anchors from links. They are really unreliable and there's no guarantee that the section they link to is the intended one. Only senseids can solve this problem, since they assign a specific identifier that will never change regardless of how much the entry is changed. —Rua (mew) 19:51, 9 November 2017 (UTC)[reply]

I agree that generic anchors are unreliable, but there's still the possibility that someone will change or remove a sense id, making the links that use it fail to work anymore. (I've changed ids before, though I do make sure to update the links that use them.) So it would be good if they were being checked regularly. — Eru·tuon 00:53, 13 November 2017 (UTC)[reply]

@billinghurst: I would be willing to write something on how to use sense ids. I just don't know where to put it exactly. — Eru·tuon 05:26, 9 November 2017 (UTC)[reply]

The documentation for {{l}} would be a good place. There's also some at {{senseid}} itself. —Rua (mew) 12:07, 9 November 2017 (UTC)[reply]

☛ Let me throw this out there -- we've spoken from time to time about more radical restructurings. One that would seem to make a great deal of sense (even if it would be a huge PITA to migrate existing content), would be to move language content to language-specific subpages. So [[bán]] would show all words in all languages that have this graphical representation, while the content specific to Irish would live at [[bán/ga]], and the content specific to Hungarian would live at [[bán/hu]], etc. That would make it possible to link to specific headers in specific languages. This is also quite similar to how the Grease Pit itself is now organized (among other discussion pages), where the main page at [[Wiktionary:Grease_pit]] shows the combined content, while the actual threads live on sub-pages like [[Wiktionary:Grease pit/2017/November]].

Alternatively, we could rework how HTML id values are generated, so rather than id="Etymology_2_2", which, for our purposes, is pretty close to bloody useless, we would instead get useful id values, like id="ga-Etymology_2" or something similar.

Hopefully fodder for productive discussion. ‑‑ Eiríkr Útlendi │^{Tala við mig} 03:59, 12 November 2017 (UTC)[reply]

@Eirikr: I imagine that adding ids like id="ga-Etymology_2" could be done with JavaScript. But to do it without JavaScript would require templates. — Eru·tuon 08:23, 17 November 2017 (UTC)[reply]

@Erutuon: That's an interesting approach. My initial thought was to see if there's anything in the server setup related to anchor auto-generation that we could reconfigure. id="Etymology_2_2" is clearly not in a format that we're intentionally generating. I'm curious if there's any way of getting the server-side setup to do the work for us, without requiring any change to the wikicode on each page. If not, then JavaScript or templates would presumably be the way to go. ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:18, 17 November 2017 (UTC)[reply]

@Eirikr: It would be neater if it were implemented server-side. There would be less mess in the wikitext. It would probably require help from MediaWiki folks, who might or might not want to implement this. To put language codes into ids in headers, the server would have to be updated with the latest language codes and canonical names from our language data modules so that it could convert canonical names in headers to codes. Or it would have to just put the canonical name or whatever else is found in the previous level-2 header in the id (that is, id="Irish-Etymology_2", or id="Irish_Gaelic-Etymology_2" if someone decided to use an alternative name of the language). I don't know that much about how the server software works, though. I would mention, many other wiktionaries use templates in headers, and French Wiktionary seems to use the templates to insert custom ids into headers. — Eru·tuon 10:45, 18 November 2017 (UTC)[reply]

Straw poll -- would you be open to the idea of using templates in page headers as a means of improving in-page-anchor functionality? edit

As mentioned by Erutuon above, the French Wiktionary apparently makes extensive use of templates in page headers as one means of improving in-page-anchor functionality.

Would you (whoever is reading this) be open to the idea of doing something similar here?

Support ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:23, 20 November 2017 (UTC)[reply]
Oppose. It doesn't actually solve the problem, like I mentioned in my earlier post. There is no guarantee that the section named "Etymology 2", even if it's in the right language, is the section that the linker intended to link to. There is nothing about it that reveals which etymology section it is. {{senseid}}, specifically because they contain actual meaningful text most of the time, do not suffer from this problem. If we started naming etymology sections rather than numbering them (at least for anchoring purposes), it would be better. However, it would make a lot more sense to link to the part-of-speech section rather than the etymology; when do you actually want to link specifically to an etymology? —Rua (mew) 19:31, 20 November 2017 (UTC)[reply]
@Rua -- Templates in headings could provide more useful and semantically stable link IDs than just numbers, such as the naming possibility you mention. Numbering alone is possibly one of the worst approaches, as pages grow and change and numberings become unstable. Re: linking to POS sections, perhaps I should have been more explicit -- I'm thinking about all headings, not just etymology headings. ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:46, 20 November 2017 (UTC)[reply]

Useful graphic on loading sequence edit

This graphic looked like it might be helpful at some stage in diagnosing and minimizing the occasionally recurring problems we have with the show-hide JS. DCDuring (talk) 13:18, 8 November 2017 (UTC)[reply]

Automation of 'See also' links? edit

I've stumbled across a few pages that are lacking {{also}} links at the top of the page recently, e.g. OWO/owo and Szilágyi/Szilagyi.

Was there ever a bot that created these links automatically? Is it possible to write a module which would automatically keep the see-also links up to date? Pengo (talk) 12:41, 9 November 2017 (UTC)[reply]

There was a bot, but it wasn't very reliable, and it hasn't run in a long time. —Aɴɢʀ (talk) 14:28, 9 November 2017 (UTC)[reply]

I have had to add a number of words including the letter "ø" to {{also}} links, they seem to be missed for some reason. DonnanZ (talk) 14:38, 9 November 2017 (UTC)[reply]

Hi @Pengo, Donnanz, Angr: I'm the operator of the robot in question. My experience was that linking 80% of the pages correctly took about a day of work; getting to 90-95% took a week; the last 5-10% probably needs another week; and continual unsupervised updates perhaps another week still. It has been a while, but I hope to be able to work on this again the middle term. (Much of the remaining work aligns with my other Wiktionary interests, as well.) I have added 'ø'/o to the next update iteration: Unicode does not consider the slash to be a diacritic, so the equivalence has to be made exceptionally. I'll poll around for further needs when I start again, but I'm still watching my talk page, and GP/BP to the extent I can. Isomorphyc (talk) 20:36, 30 November 2017 (UTC)[reply]

Edit: It is not possible to do this with a Lua module because Scribunto cannot query the list of existing pages. One could maintain a list of pages in a series of data modules. This would have to be kept updated by a robot, but the tradeoffs in doing this do not really excite me, as it would probably require creating 100 thousand separate data modules. Isomorphyc (talk) 20:47, 30 November 2017 (UTC)[reply]

Perhaps the wrong approach. Should be moderately simple to do using an external tool (based on parsing the data dump) rather than internal wiki modules. Equinox ◑ 20:50, 30 November 2017 (UTC)[reply]

@Equinox: Currently I derive an equivalence table from the XML/API data, keep it updated from the streaming API feed, and push the updates out through OrphicBot. What's complicated is the social aspect of what constitutes an equivalence around the edges, in various scripts, and how to make it extensible, secure and maintainable. Also, how to standardise the also-appendices for large equivalence classes, and what to do with the tens of thousands of pages which are malformed Wikitext. It will likely take two weeks of community buy-in to to make an acceptable interface on Wikimedia ToolServer. I indeed have no interest in doing this with Lua and data modules. Isomorphyc (talk) 21:37, 30 November 2017 (UTC)[reply]

@Isomorphic: I do find the {{also}} links quite handy, most recently with Icelandic "ð", I haven't installed an Icelandic keyboard anyway. Unicode may not consider "ø" as a diacritic, but many a time when a Swedish word with "ö" has (almost) exactly the same spelling as a Norwegian word with "ø", I have had to create an {{also}} red link first before I can make an entry for the Norwegian word. The same applies with words with exactly the same spelling, one with a capital letter and one without. DonnanZ (talk) 21:23, 30 November 2017 (UTC)[reply]

This might be a good candidate for migrating too Tools, since there is access to mirrors (for easy searching of existing articles), databases (for storing normalized strings), RC feed (for constant update), and multi-user access (for teamwork). I think that Isomorphyc has done an admiral job in keeping these things going as is, though, normalization is a terrible pain. - TheDaveRoss 12:32, 1 December 2017 (UTC)[reply]

"References is forbidden as a level 2 header" in inappropriate namespace edit

My bot just tried to edit Wiktionary:Etymology and got booted out by this edit filter. Of course, the filter should only apply to namespaces that contain entries, mainspace and Reconstruction. Can the filter be fixed to that effect? Moreover, the filter shouldn't be triggered for edits that others made. My bot didn't add the References section, so the filter shouldn't be flagging unrelated edits as bad. —Rua (mew) 23:10, 10 November 2017 (UTC)[reply]

It's abuse filter 73- I couldn't get it to work right and I've disabled it for now. DTLHS (talk) 01:20, 12 November 2017 (UTC)[reply]

@DTLHS I assume it isn't as simple as adding an & article_namespace = 0 to the existing filter? - TheDaveRoss 12:36, 1 December 2017 (UTC)[reply]

Maybe. There was also the issue of spaces within and at the end of the header. Regardless, there aren't that many people trying to add references as level 2 headers, and the problem can easily be detected and fixed, so maybe this filter isn't necessary. DTLHS (talk) 01:37, 2 December 2017 (UTC)[reply]

Prevent deletion of the main page edit

This is evidently something that can be done, so I presume we should. This suggested it to me. @Angr, since you're an admin at en.wiki, can you confirm that the main page can't be deleted there? —Μετάknowledge^{discuss/deeds} 01:17, 12 November 2017 (UTC)[reply]

I don't know. I've never tried. —Aɴɢʀ (talk) 15:16, 12 November 2017 (UTC)[reply]

Before you try it, make sure to read Wikipedia:Don't delete the main page. ;-) -Stelio (talk) 21:19, 12 November 2017 (UTC)[reply]

@Angr, what I meant was, can you access the page to delete it? —Μετάknowledge^{discuss/deeds} 21:39, 12 November 2017 (UTC)[reply]

I can confirm that the "Delete" and "Move" options that every other main-namespace article has do not appear on the Main Page at English Wikipedia. —Aɴɢʀ (talk) 21:46, 12 November 2017 (UTC)[reply]

What if you go to delete some random page, but then change the URL so that the target page is "Main page"? —Rua (mew) 19:14, 13 November 2017 (UTC)[reply]

@Metaknowledge, Rua: You get a Permission error saying, "You do not have permission to delete this page, for the following reason: You cannot delete or move the main page." —Aɴɢʀ (talk) 10:08, 17 November 2017 (UTC)[reply]

At this task it has been remarked that the main page was not deleted since 2012. The question is open -- "It hasn't been deleted since August 2012... What are we trying to solve here?" (by Reedy).

If hiding the 'delete' and 'move' tabs suffices, perhaps this can be done by CSS, the body has a class name of "page-Wiktionary_Main_Page" there. I.e. "

body.page-Wiktionary_Main_Page #ca-delete {  display: none !important; }

" could work, placed in MediaWiki:common.css. The same could be done for #ca-move, the move tab. --Gryllida 08:24, 2 March 2018 (UTC)[reply]

There are at least three easy ways to delete the page which this doesn't solve, it only solves "inadvertent" deletions, which has not been the problem. I do, in part, agree with Reedy, it is a pretty minor problem. - TheDaveRoss 14:10, 2 March 2018 (UTC)[reply]

Min Nan POJ entries ended up in HSK categories edit

Something puts Min Nan POJ entries into Mandarin HSK entries, e.g. an-chēng#Chinese. @Wyang, Justinrleung. --Anatoli T. ^{(обсудить}/^вклад) 02:46, 12 November 2017 (UTC)[reply]

That thing has been annihilated. Wyang (talk) 02:52, 12 November 2017 (UTC)[reply]

Great, thanks! --Anatoli T. ^{(обсудить}/^вклад) 02:54, 12 November 2017 (UTC)[reply]

Struck this out as solved. --Per utramque cavernam (talk) 13:37, 4 January 2018 (UTC)[reply]

Request for kana as ruby on kana-containing base text for uses of `{{furigana}}`, `{{ja-r}}` & `{{ja-usex}}` edit

Some authors use ruby on base text that contains kana, for example [ベーゼ](キッス) or [魔法使い](ぼく), which {{furigana}} & {{ja-usex}} can't handle yet. It's trickier to automatically render romaji for {{ja-r}} & {{ja-usex}} in these cases, but they also have parameters for manually doing that, so they should offer more options.

By the way, what wrong this: バカじゃないの。全(ぜん)裸(ら)美(び)女(じょ)密(みっ)室(しつ)露(ろ)天(てん)風(ぶ)呂(ろ)連(れん)続(ぞく)殺(さつ)人(じん)事(じ)件(けん)？わざわざ断(ことわ)らなくても、服(ふく)着(き)たまま風(ふ)呂(ろ)には入(はい)る美(び)女(じょ)なんていないわよ。だいたい、露(ろ)天(てん)風(ぶ)呂(ろ)が密(みっ)室(しつ)になった段(だん)階(かい)で大(だい)事(じ)件(けん)だわ。

Baka ja nai no. Zenra bijo misshitsu rotenburo renzoku satsujin jiken? Wazawaza kotowaranakute mo, fuku kita mama furo ni wa hairu bijo nante inai wa yo. Daitai, rotenburo ga misshitsu ni natta dankai de daijiken da wa.

Now that’s just absurd. A series of murder cases of beautiful naked women inside locked-room outdoor baths? I mean, it’s not like there’s such thing as beautiful women taking a bath with clothes on. And an outdoor bath can’t be in a locked room to begin with.

.I tried breaking it down into small parts (バカじゃないの。全(ぜん)裸(ら)美(び)女(じょ)密(みっ)室(しつ)露(ろ)天(てん)風(ぶ)呂(ろ)連(れん)続(ぞく)殺(さつ)人(じん)事(じ)件(けん)？わざわざ断(ことわ)らなくても、服(ふく)着(き)たまま風(ふ)呂(ろ)には入(はい)る美(び)女(じょ)なんていないわよ。

Baka ja nai no. Zenra bijo misshitsu rotenburo renzoku satsujin jiken? Wazawaza kotowaranakute mo, fuku kita mama furo ni wa hairu bijo nante inai wa yo.

Now that’s just absurd. A series of murder cases of beautiful naked women inside locked-room outdoor baths? I mean, it’s not like there’s such thing as beautiful women taking a bath with clothes on. And an outdoor bath can’t be in a locked room to begin with.

だいたい、露(ろ)天(てん)風(ぶ)呂(ろ)が密(みっ)室(しつ)になった段(だん)階(かい)で大(だい)事(じ)件(けん)だわ。

Daitai, rotenburo ga misshitsu ni natta dankai de daijiken da wa.

(please add an English translation of this example)

) and found nothing wrong with the matching of kana. ばかFumiko￥^talk 06:09, 12 November 2017 (UTC)[reply]

I made a small change to the function and it appears to fix this problem. I believe the problem is due to repeated characters or sequences of characters, in this case triple apostrophes used for bolding. However, there are likely to be other effects of this edit... — Eru·tuon 06:57, 12 November 2017 (UTC)[reply]

Now there's something wrong with ラーの翼(よく)神(しん)竜(りゅう)

Rā no Yokushinryū

Ra the Winged God Dragon

. Can you check it again? ばかFumiko￥^talk 10:58, 12 November 2017 (UTC)[reply]

Okay, that is now fixed. — Eru·tuon 18:57, 12 November 2017 (UTC)[reply]

Struck this out as solved. --Per utramque cavernam (talk) 13:38, 4 January 2018 (UTC)[reply]

ISO codes in tab languages edit

The languages in the tabs (PREFERENCES > GADGETS – Enable tabbed languages) take a lot of space, so I'd like to change them for their ISO codes. --Backinstadiums (talk) 17:58, 12 November 2017 (UTC)[reply]

Oppose showing language codes in any user-facing place, and especially in such an important place as L2 language headers (which the tabs replace). —Rua (mew) 18:02, 12 November 2017 (UTC)[reply]

@Rua: I'd like it as an option in the user's preferences, just as the tabs are optional --Backinstadiums (talk) 18:11, 12 November 2017 (UTC)[reply]

I'd be opposed even to letting people opt in to this setup. Even experienced users will sooner or later be baffled and frustrated by the fact that the language codes aren't listed in alphabetical order, since we alphabetize by full name, not by code. —Aɴɢʀ (talk) 13:20, 13 November 2017 (UTC)[reply]

@Angr: Customizable order of languages should be optional as well --Backinstadiums (talk) 19:12, 13 November 2017 (UTC)[reply]

`{{autocat}}` edit

Is there a way to make the wizard that appears on Creating Category:... pages paste {{autocat}} directly into the editing box upon clicking it (if possible also saving the page and maybe giving me a back massage), I've wasted countless man-seconds on typing this in. Crom daba (talk) 16:29, 13 November 2017 (UTC)[reply]

If you're willing to wait a bit, you don't have to create those categories at all. DTLHS runs a bot script that creates them. —Μετάknowledge^{discuss/deeds} 19:23, 13 November 2017 (UTC)[reply]

I'm not, red links provoke me. Crom daba (talk) 19:28, 13 November 2017 (UTC)[reply]

P.S. This is off topics, but does anyone know what's wrong with this (I've just added Proto-Yukaghir, but poscatboiler can't see it apparently).

Proto-Yukaghir is "qfa-yuk-pro" not "xgn-mgr", and, you need to also edit Module:languages/canonical names if you add a new language in order for {{auto cat}} to function. DTLHS (talk) 19:39, 13 November 2017 (UTC)[reply]

Module:IPA sorting wrong edit

For Northern Sami, a sort key is set to sort á immediately after a. But in Category:Northern Sami terms with IPA pronunciation, á is sorted at the very end. Can this be fixed? —Rua (mew) 21:02, 14 November 2017 (UTC)[reply]

Done. — Eru·tuon 21:44, 14 November 2017 (UTC)[reply]

@Erutuon: Thanks! Can you also arrange it so that {{IPA}} accepts |sort= for manual sorting? —Aɴɢʀ (talk) 21:49, 14 November 2017 (UTC)[reply]

@Angr: I guess that feature should be available. Done! — Eru·tuon 22:08, 14 November 2017 (UTC)[reply]

Struck this out as solved. --Per utramque cavernam (talk) 13:39, 4 January 2018 (UTC)[reply]

Behaviour of `{{topic cat}}` at "Category:en:New York City" edit

I've just noticed that at "Category:en:New York City", {{topic cat}} is generating the following statement: "English terms related to new York City" (with new instead of New). There are some instructions at {{topic cat}} on using the special keyword "default with capital" to alter the default behaviour of the template, but I can't figure out how to do it. Could someone help? — SGconlaw (talk) 10:21, 17 November 2017 (UTC)[reply]

It seems to read OK now, so someone must have quietly changed the module. DonnanZ (talk) 17:06, 19 November 2017 (UTC)[reply]

Oh, great! — SGconlaw (talk) 21:08, 25 November 2017 (UTC)[reply]

Woops! I fixed it in this edit, but forgot to post here about it. I also modified the explanation at Template:topic cat/documentation to hopefully make it more understandable. — Eru·tuon 21:59, 25 November 2017 (UTC)[reply]

Thanks! I didn't realize that the phrase "default with capital" had to be put in double quotation marks. That seems rather counterintuitive as this rule doesn't apply to other templates. — SGconlaw (talk) 03:59, 26 November 2017 (UTC)[reply]

Two collapsing displays under the same definition? edit

I am having troubling picturing a user interface suitable for infrequent users that would allow for a collapsing display under a definition of a synonyms line and a collapsing display of citations. Are we forced to have a single collapsing display that included both? DCDuring (talk) 13:49, 17 November 2017 (UTC)[reply]

Output of template:label edit

Hello, in the page bump into, we can see for the first two definitions: (literally intransitive) and (literally transitive), without any comma between the two labels. Is there any reason to that? — Automatik (talk) 01:48, 19 November 2017 (UTC)[reply]

"Literally, intransitive" would be as ambiguous as "literally intransitive". Perhaps for that reason {{lb|en|intransitive|literally}} produces (intransitive, literally). I think that literally should not appear together with any other label because it can be read ambiguously with many other label words. DCDuring (talk) 11:16, 19 November 2017 (UTC)[reply]

I had just noticed this issue on another entry. I agree it's often problematic. "literally obsolete" etc are wrong, too. What are the use-cases where the lack of a comma is desired? Notice also that in the previously-mentioned cases, it's problematic for "literal" and "literally" to display "literally" rather than "literal"; we don't say e.g. "obsoletely". - -sche (discuss) 01:58, 4 December 2017 (UTC)[reply]

Perhaps punctuation can be added to the order change to clarify the lack of relationship between "literal(ly)" and other label terms. A semicolon, possibly emboldened, might help, at least for careful readers. Switching from literally to literal would help a lot. Any word used in our labels that can be read as an adverb might be subject to the same misreading that literally can cause. DCDuring (talk) 13:33, 4 December 2017 (UTC)[reply]

Doesn't it seem literally, ridiculous to begin a definition (of cool#Verb) with 'figuratively, intransitive': "(figuratively, intransitive) To become less intense, e.g. less amicable or passionate." We and most of our users all know that it means, but should this be our style? Although Wiktionary definitely could use a little humor, this doesn't seem the right kind: it potentially distracts from getting the information a user seeks. DCDuring (talk) 18:47, 6 December 2017 (UTC)[reply]

what if I wanted to edit

As someone with a "C-like" background (can struggle through C and C++; regularly use C#, JS, PHP; am low-level enough to have an idea about assembler), what is a good entry point to all this Lua fun that we have here? Equinox ◑ 04:26, 19 November 2017 (UTC)[reply]

Does this help? DTLHS (talk) 04:30, 19 November 2017 (UTC)[reply]

Excellent, thank you. For future idiots, where should I have found the link? Equinox ◑ 04:43, 19 November 2017 (UTC)[reply]

I have no idea. DTLHS (talk) 04:48, 19 November 2017 (UTC)[reply]

It's linked in the edit notice for module pages, with the link text "Scribunto": MediaWiki:Editnotice-828. — Eru·tuon 04:49, 19 November 2017 (UTC)[reply]

It might be a good idea to link this kind of thing from this (WT:GP) page. If I knew Lua (which I don't! yet) I would like the techy page to have a clear pointer to "this is how we do Lua around here". Anyway, thanks! Equinox ◑ 04:52, 19 November 2017 (UTC)[reply]

I hadn't thought about it before, but I guess I agree. It should probably link to WT:LUA, which can serve as a hub. It has the link given above as well as others. — Eru·tuon 08:15, 19 November 2017 (UTC)[reply]

Solved. Per utramque cavernam (talk) 21:50, 19 January 2018 (UTC)[reply]

Improving links to pages with many languages edit

I hope I am not asking for too much, but is it possible for links to be improved to pages such as ti, which has entries in no less than 47 languages, so you land on exactly the right language. For example, the link from tiande to Norwegian Nynorsk ti. DonnanZ (talk) 12:57, 20 November 2017 (UTC)[reply]

It already does bring you to the right section, because the link is using {{l}}. Why don't you try again? —Μετάknowledge^{discuss/deeds} 15:35, 20 November 2017 (UTC)[reply]

Behaviour is erratic, sometimes in the right place, sometimes ends up two or three languages below. Could it be a browser problem? DonnanZ (talk) 15:52, 20 November 2017 (UTC)[reply]

The link to [[ti#Norwegian Nynorsk]] worked perfectly for me this time in Chrome 62.0.3202.94 (64-bit), Firefox 56.0.2 (64-bit), and Edge 40.15063.674.0. DCDuring (talk) 16:12, 20 November 2017 (UTC)[reply]

FWIW, I've noticed similar behavior on up-to-date Chrome, where the view of the page shifts as the JavaScript loads and different portions of the page expand or contract. @DonnanZ, when you click through a language-specific link using {{l}} or {{m}}, do you see this behavior too? ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:15, 20 November 2017 (UTC)[reply]

I think I will have to put it down to my browser. I'm still using IE (with Windows 10 which may be an anachronism), as I can't be bothered moving my links stored in Favourites to another browser. Sometimes I notice it lands on Nynorsk for a split second, then jumps downwards. With pages with just two or three languages there's usually no problem. DonnanZ (talk) 19:28, 20 November 2017 (UTC)[reply]

I've had that problem with Chrome (and it can't really be helped), but with Firefox now I can go to the address bar and click enter, and it'll zoom me to the correct section. (On Chrome, that reloads the page.) — Eru·tuon 21:40, 20 November 2017 (UTC)[reply]

For the JavaScripters: What would happen if a script runs very last and manually resets the anchoring to the correct position? —Rua (mew) 19:39, 20 November 2017 (UTC)[reply]

`{{trans-top}}` edit

Translation tables on my browser (Chrome. see: reorganize) have developed a horizontal scroll bar - is this a temporary glitch, or what? — Salt marsh. 16:35, 20 November 2017 (UTC)[reply]

No such scroll bar on my Chrome. SemperBlotto (talk) 16:41, 20 November 2017 (UTC)[reply]

@SemperBlotto: Thanks - "Preferences/Enable targeted translations" makes it come and go. It also appears with all the "pull-down" inflection tables which I have looked at. — Salt marsh. 18:58, 20 November 2017 (UTC)[reply]

Solved. Per utramque cavernam (talk) 21:50, 19 January 2018 (UTC)[reply]

Text appearing oddly big at nála edit

The link to the lemma in Northern Sami nála is looking really big for some reason. Does anyone know why? —Rua (mew) 21:58, 20 November 2017 (UTC)[reply]

According to my Firefox "inspect" window, it's because of the style rule Tibt .use-with-mention .mention, .form-of-definition-link .mention { font-size: 160%; } in MediaWiki:Common.css. I don't know why that's being applied here, because I doubt there are really any <Tibt> tags anywhere, but changing Tibt to .Tibt should fix the problem. — Eru·tuon 22:16, 20 November 2017 (UTC)[reply]

Oh, duh, the second selector .form-of-definition-link .mention is what's applying. That should be prefixed by .Tibt too. — Eru·tuon 22:17, 20 November 2017 (UTC)[reply]

I came across this with {{alternative form of}}. DonnanZ (talk) 22:23, 20 November 2017 (UTC)[reply]

Same problem appearing at English elders, where etymon elder is excessively embiggened in the call to {{plural of}}. ‑‑ Eiríkr Útlendi │^{Tala við mig} 23:01, 20 November 2017 (UTC)[reply]

Still happening, see undervassbåt. DonnanZ (talk) 23:07, 20 November 2017 (UTC)[reply]

@Wyang: I think this edit caused the problem. The selectors should perhaps be changed to .Tibt .use-with-mention .mention, .Tibt .form-of-definition-link .mention to get the rule to do what you intend. — Eru·tuon 23:09, 20 November 2017 (UTC)[reply]

Thanks! Wyang (talk) 23:17, 20 November 2017 (UTC)[reply]

I reverted the problematic change until it's fixed. —Rua (mew) 23:09, 20 November 2017 (UTC)[reply]

More easily fixed than reverted. 😂 Wyang (talk) 23:17, 20 November 2017 (UTC)[reply]

Solved. Per utramque cavernam (talk) 21:51, 19 January 2018 (UTC)[reply]

Esperanto headword edit

I am going to convert all these using templates to {{eo-head}}:

eo-noun, eo-verb, eo-adj
head|eo|noun form, head|eo|verb form, head|eo|adjective form

since Esperanto rules are fixed and they can be autodetected in Module:eo-headword. --Octahedron80 (talk) 00:18, 21 November 2017 (UTC)[reply]

sc=CGK edit

It is found in MediaWiki:Common.css and Module:scripts/data as an alias for Korean (I think?), but it is actually used (i.e. can it be removed)? (I removed two manual uses here and here. Unless my search query for Special:Search is bad, those were the only manual uses in the dictionary.) —suzukaze (t・c) 07:20, 21 November 2017 (UTC)[reply]

Well, it's not used by any languages (i.e., not found in any language data modules) according to Module:data consistency check. — Eru·tuon 07:46, 21 November 2017 (UTC)[reply]

Sorry for the late reply. CGK is/was needed because most contemporary Korean fonts cannot deal with ancient Korean characters which are composed of characters from the Hangul Jamo Unicode block, so they appear completely broken. When I open the two mentioned pages now, they display fine, but I think that's only because my browser uses the Windows 10 version of Malgun Gothic. I don't think we can expect people to be using Windows 10, and the Windows 7 version still gets it wrong (as far as I know), so this should probably stay as a compatibility measure unless there's some way to detect the operating system used with CSS/JS (probably not?) -- Pedrianaplant (talk) 19:55, 18 December 2017 (UTC)[reply]

But if it's not actually used anywhere..? —Rua (mew) 20:35, 18 December 2017 (UTC)[reply]

It was used in two articles until the tag was removed. It should be restored. -- Pedrianaplant (talk) 08:46, 20 December 2017 (UTC)[reply]

What about assigning CGK to Cia-Cia in general, rather than using it manually in a few pages? Then at least it would be clear that it is being used. — Eru·tuon 08:54, 20 December 2017 (UTC)[reply]

(edit conflict) Currently, MediaWiki:Common.css defines the same fonts for Kore, Hang, and CGK; Malgun Gothic is near the top of the font stack. It then redefines the fonts for CGK (/* Old Korean */) a few lines lower, and none of the fonts listed seem to come with Windows; Malgun Gothic is not in the list, and if I understand correctly, Windows machines would fallback to using Batang (serif), which indeed does not support old Korean hangeul. —suzukaze (t・c) 08:58, 20 December 2017 (UTC)[reply]

egg edit

Lua error: not enough memory. --Barytonesis (talk) 13:05, 21 November 2017 (UTC)[reply]

@Barytonesis: Current solution is to move the largest Translations section to a /translations subpage. — Eru·tuon 22:00, 21 November 2017 (UTC)[reply]

We really need to fix the underlying issue. From past discussions, it seems it would be helpful to (en masse) subst: the transliterations into the wikitext, instead of auto-generating them. - -sche (discuss) 01:54, 4 December 2017 (UTC)[reply]

@-sche: I was going to make a script that can do that, but never got around to it. The reason was partly that I don't want to actually use the script until there is a method for updating transliterations, which will be necessary when the output of a transliteration module changes or a language has been assigned a transliteration module for the first time. To avoid the complicated question of whether updating of transliterations is needed, it would be best to have updating done by bot on a regular schedule (say, once a month, or on request). The bot could substitute a template that would generate the transcription parameter (|tr=) if a transliteration was successfully generated. I think there were additional complications that I don't recall at the moment. — Eru·tuon 09:22, 14 December 2017 (UTC)[reply]

Updates needed to "A Wonderfool Archiver" edit

Hello, could someone please update "A Wonderfool Archiver" so that it works with the new subpages "Wiktionary:Requests for deletion/English" and "Wiktionary:Requests for deletion/Non-English"? Much obliged. — SGconlaw (talk) 21:07, 25 November 2017 (UTC) {{look}} @Erutuon, can you help? — SGconlaw (talk) 10:46, 3 December 2017 (UTC)[reply]

@Sgconlaw: I don't fully understand the script, but it might help to change the line

} else if ((wgPageName === "Wiktionary:Requests_for_deletion") || /^Wiktionary:Requests_for_deletion\/Archives\//.test(wgPageName)) {

to /^Wiktionary:Requests_for_deletion/.test(wgPageName)) {. Actually, apparently I proposed something like this before? — Eru·tuon 19:32, 3 December 2017 (UTC)[reply]

Done. Thanks, that worked! — SGconlaw (talk) 02:18, 4 December 2017 (UTC)[reply]

Parallel universes in regard to reference formatting edit

About the formating of references especially in so far as they are templatized I have lost quite some words on a page.

I have started to like using {{cite-book}} in reference templates like in {{R:ar:Fraenkel}} but now I have found out that there has been widespread usage of {{R:Reference-meta}}. @Vahagn Petrosyan, you probably do not know about this one – it has been created by @Sgconlaw in 2017; as for example templates, {{R:SOED}} and {{R:Dehkhoda}} use this template. Template talk:R:Reference-meta points out that Sgconlaw and @JohnC5 have been paying regard to {{cite-book}}. However it is unclear to me where the difference is, or why one is better than the other. What I see is that there are differences in how reference templates look depending on which template they use, for instance {{R:Dehkhoda}} puts the quoted dictionary entry right at the beginning of the reference while {{R:ar:Wehr-4}} puts it after the author name and the year.

There hasn’t been any discussion on the grease pit or the beer parlour if I don’t search wrong, but the new meta template seems to be a reaction to this post. I feel a bit insecure now in the endeavor of formatting new reference templates or templatizing untemplatized reference templates.

It seems to me that according to conservative principles {{cite-book}} should be used. But as there is {{R:Reference-meta}} in the world, discussion cannot be avoided, thus I raise attention here. Why does {{R:Reference-meta}} exist? Palaestrator verborum (loquier) 01:02, 26 November 2017 (UTC)[reply]

I created {{R:Reference-meta}} because an editor objected strongly to the year of publication appearing in parentheses after the author's name, which is what {{cite-book}} does (following w:cite book). I have no objection if we standardize on one form. — SGconlaw (talk) 03:52, 26 November 2017 (UTC)[reply]

Actually I do not have that much for standardization, though others have: Every style partakes in pulchritude, and standardization is rough. The most desired thing is that references look the same in the same page. In the wild one has to expect different standards too but not on the same page. And methinks that it is better solved by parameters controlling the layout of a reference; else different reference templates are incompatible or we have to have twain of them. Like, Dehkhoda and Lane on the same page look inconsistent.

One can think of parameters for inside each template’s arguments, but can there be made a wrapper around references that unifies styles? Like I write:

{{refwrapper|year=1|forename=2|surname=3|entry=4|title=5|
{{R:Dehkhoda}}
{{R:fa:Steingass}}
{{R:ar:Wehr}}
{{R:ar:Lane}}
{{R:ar:Steingass}}
}}

We would also name the most common styles:

{{refwrapper|order=germanstyle|
{{R:Dehkhoda}}
{{R:fa:Steingass}}
{{R:ar:Wehr}}
{{R:ar:Lane}}
{{R:ar:Steingass}}
}}

Would be nang. Would be also somewhat difficult to code, but there is a template chaos to fix anyhow. Palaestrator verborum (loquier) 07:09, 26 November 2017 (UTC)[reply]

With respect, I'm not sure what that would achieve. Until there is consensus about how citations should look, trying to enforce one format over another would be futile. Perhaps you could consider starting a vote on the issue so we can determine if there is a preference for a particular citation style. — SGconlaw (talk) 14:53, 26 November 2017 (UTC)[reply]

"Edit category data" in pages with Template:langcatboiler edit

The actual category data for these pages resides in the subtemplates of Module:languages, but there's a link titled "Edit category data" to edit Module:category tree/langcatboiler, which is not a data module. Is there any reason we should facilitate access for literally anyone on the planet with internet access to make changes affecting all of our language-category pages, given that the link provides no access to category data? Chuck Entz (talk) 02:15, 26 November 2017 (UTC)[reply]

It's helpful to have the link to the category boilerplate module or the data module for the catboiler module on the category page because otherwise, in some cases, it is hard to figure out which module to go to to make changes. (The links were helpful a while back when I was working on catboiler modules.) The edit link is added by Module:category tree, so it would have to be disabled there. Perhaps it could be disabled for any category title ending with "language", but an easier way to prevent foolery would be to template-protect Module:category tree/langcatboiler, and whatever other catboiler modules are deemed likely to be vandalized. I don't think the danger is great, because there hasn't been any mischief done to langcatboiler so far, but it could happen. Another idea would be to make some invisible HTML containing the module name, which could then be transformed by JavaScript into an edit link for the few who need it. (Incidentally, there is a separate link to the language data module in the table of "Information about language name".) — Eru·tuon 02:40, 26 November 2017 (UTC)[reply]

“facilitate access for literally anyone on the planet with internet access to make changes affecting all of our language-category pages” – of course not. You have stated the answer to your question. It’s just something people creating templates and modules do not like to think about, thus they do not protect it when they are administrator and have created such a thingy.

For example, I have no clue why {{ar-noun}} and Module:ar-headword have no protection whilst being used in thousands of pages and increasing – {{sh-noun}} is protected, luckily. I give this as one example, because the other Arabic templates and Modules are also vastly unprotected. Palaestrator verborum (loquier) 02:43, 26 November 2017 (UTC)[reply]

Is the new PDF quality of pages going to be better? edit

In my research project I extract text from PDF version of Wiktionary entries to carry out some NLP treatment. At beginning of October I started already working with some pages I downloaded, which have a reasonable quality. I noticed recently that the text of the new version generated by the new tool described here has much lower quality: the order of several text segments is changed and a lot of extra backlines are generated as well.

Is the quality of the PDFs getting anyway better after the ongoing work on the new PDF generator is over? — This unsigned comment was added by MedKhem (talk • contribs).

@MedKhem: Unfortunately I do not know anything about the PDF generation facility. Perhaps someone else can answer this question. However, I do spend a bit of time extracting text from Wiktionary. What is your use case for using PDFs rather than the Wikitext from the XML files or the API? I can only think of disadvantages to this method. Since this is your first post, also: welcome to Wiktionary (although, since you do NLP on it, you are likely a bit of a native already). Please do sign your comments with the quadruple-tilde syntax in future. Isomorphyc (talk) 02:11, 29 November 2017 (UTC)[reply]

ACCEL seems to be broken edit

Clicking green links from overnet does not put any text in the resulting page. Equinox ◑ 22:17, 28 November 2017 (UTC)[reply]

Fixed. —Rua (mew) 22:22, 28 November 2017 (UTC)[reply]

Struck this out as solved. --Per utramque cavernam (talk) 13:39, 4 January 2018 (UTC)[reply]

Category:English lemmas oddity edit

The "newest additions" (top right of category page) is showing entries like unsententiously that haven't been edited for many years. Equinox ◑ 02:06, 29 November 2017 (UTC)[reply]

I hypothesize that sometimes changes to the underlying templates or modules can cause the newest additions table to be updated, even if the entries haven't actually been edited. DTLHS (talk) 02:17, 29 November 2017 (UTC)[reply]

An API query shows the same list with the timestamp of when the page was included. Starting the query at the time the message was posted it shows unsententiously at "2017-11-29T01:31:38Z" as well as unsententious, uninspirable, ungaugeable, none of them edited recently. Probably they were refreshed by template or module editions. --Vriullop (talk) 09:00, 30 November 2017 (UTC)[reply]

Confirmed. On mw:Extension:DynamicPageList (Wikimedia) says "It should be noted, that lastedit really sorts by the last time the page was touched. In some cases this is not equivalent to the last edit (for example, this includes permission changes, creation or deletion of linked pages, and alteration of contained templates)." Although it explains "lastedit" parameter, it happens also with "categoryadd" parameter used here. --Vriullop (talk) 12:24, 30 November 2017 (UTC)[reply]

BC–AD script edit

The script that handles {{B.C.E.}} and {{C.E.}}, User:Bequw/bc-ad.js, is kind of brittle. While I was trying to make the date labels in {{grc-IPA}} switchable, I created faulty HTML structure and the script crashed. I created a new version at User:Erutuon/scripts/datingSystem.js. It doesn't crash if the HTML structure is wrong, and it also supports an unlinked date label that can be used in links (CE). Could an admin copy my script into User:Bequw/bc-ad.js? Though really it should be a gadget. — Eru·tuon 22:04, 29 November 2017 (UTC)[reply]

OK,

Done. How does one make it a gadget? Or can the script be stored in a more central location rather than as a user subpage? — SGconlaw (talk) 07:29, 30 November 2017 (UTC)[reply]

I don't really know. It probably has to be moved to a pagename starting with MediaWiki:Gadget-, but that's not all. mw:Extension:Gadgets is the official page explaining it. — Eru·tuon 08:57, 30 November 2017 (UTC)[reply]

Oooh, looks complex. OK, will have a look. — SGconlaw (talk) 13:54, 3 December 2017 (UTC)[reply]

@Erutuon, I've created "MediaWiki:Gadget-DatingSystem.js". See if it works. — SGconlaw (talk) 02:24, 4 December 2017 (UTC)[reply]

@Sgconlaw: w:Wikipedia:Gadget#Installation. Creating just the JS page isn't sufficient. —suzukaze (t・c) 02:44, 4 December 2017 (UTC)[reply]

Ah, OK. Will look at that page. "mw:Extension:Gadgets" wasn't very clear. — SGconlaw (talk) 02:51, 4 December 2017 (UTC)[reply]

I'm afraid I'm going to need help. I'm not sure how to:

Create the script home and/or help page, and state the browser requirements (@Erutuon, you may need to do this).
Update "MediaWiki:Gadgets-definition".

Is that all that needs to be done? — SGconlaw (talk) 03:05, 4 December 2017 (UTC)[reply]

@Sgconlaw: Well, I think the script should work in all browsers, and there doesn't need to be a help page, so that item doesn't apply. The script uses ResourceLoader, so presumably that has to be added in brackets in Gadgets-definition. I don't know if that's all that's required. It would be nice if an admin who has installed gadgets would chime in. — Eru·tuon 04:00, 4 December 2017 (UTC)[reply]

@Dixtosa, Gamren, can you help? — SGconlaw (talk) 04:10, 4 December 2017 (UTC)[reply]

Do we have a consensus that the script is worth being a gadget? Dixtosa (talk) 15:12, 4 December 2017 (UTC)[reply]
- I vote yes since {{B.C.E.}} and {{C.E.}} use the script. — SGconlaw (talk) 02:10, 5 December 2017 (UTC)[reply]