Wiktionary:Grease pit/2018/May

Limit on Babel?

I want to add scripts I learn but two {{User Mymr-1}} and {{User Khmr-1}} don't get added:

Using {{Babel|Cyrl|Latn|Hira-4|Kana-4|Arab-4|Hang-4|Hani-3|Jpan-3|IPA-3|Grek-2|Deva-2|Thai-2|!||Bopo-1|Hebr-1|Khmr=1|Mymr=1|align=left|footer=Scripts I can contribute in|header=Scripts}}

--Anatoli T. ^{(обсудить}/^вклад) 06:57, 2 May 2018 (UTC)[reply]

@Atitarev Should be a dash instead of an equal sign, Anatoli. :) Wyang (talk) 07:12, 2 May 2018 (UTC)[reply]

@Wyang: Thank you, Frank! --Anatoli T. ^{(обсудить}/^вклад) 10:01, 2 May 2018 (UTC)[reply]

All words clickable?

Please, could all the words become clickable (black colour)? And blue only if a specific #, or a particular page (Appendices etc) or external. Especially at UsageExamples... and definitions. Would be great. sarri.greek (talk) 10:55, 2 May 2018 (UTC)[reply]

@Sarri.greek: If all the words were clickable — I assume you mean, linked to their entries — it would be almost impossible to click on or drag from anywhere in the entry. Very bad design, IMHO. --Thnidu (talk) 04:17, 9 May 2018 (UTC)[reply]

On en.wikinews there is a gadget that double clicking on any word ~~shows~~ showed a popup with information from Wiktionary. It is currently broken but it is not so bad idea. See n:MediaWiki:Gadget-dictionaryLookupHover.js and n:Wikinews:Javascript#Wiktionary lookup gadget (Hover box variety). --Vriullop (talk) 08:43, 9 May 2018 (UTC)[reply]

Thank you for answering @Thnidu: and @Vriullop:! Well, I know nothing about computers... I was thinking something like this example@logeion.uchicago.edu. Every double.click on a word works fine. Magic! You know, how at definitions we make links for some words, the ones we expect the visitors would not understand. And at usage examples, I try to use words which exist in wiktionary. But the visitor has to type them himself at the search box. The problem would be, that many words are not lemmata. Yet. sarri.greek (talk) 11:14, 9 May 2018 (UTC)[reply]

Ah, you mean double-clickable. "Click" by itself almost always means a single click. Yes, that seems plausible in terms of UX (user experience). (I'm neither recommending for or against it.) --Thnidu (talk) 22:17, 9 May 2018 (UTC)[reply]

It is probably undesirable to override double-click behaviour because many browsers allow double-click to select an entire word (making it easier to copy etc.); I've even seen triple-click to select the whole sentence or paragraph. Equinox ◑ 18:29, 17 May 2018 (UTC)[reply]

Browser-specific "Preferences" (left-hand column, not top of page) has such an option. It is ugly, probably broken. If someone could fix it, […] . DCDuring (talk) 09:48, 10 May 2018 (UTC)[reply]

Oh, I see: Wiktionary:Per-browser preferences, but it does not work for me. It seems to come from User:Bequw/quickLookup.js. Ping User:Bequw. --Vriullop (talk) 19:03, 10 May 2018 (UTC)[reply]

It sorta works for me in Chrome, not in Firefox. DCDuring (talk) 20:29, 10 May 2018 (UTC)[reply]

incategory for topic cats

What's the technical reason why incategory:"en:Nautical" doesn't work? — This unsigned comment was added by 208.71.184.41 (talk) at 22:22, 3 May 2018.

What do you mean by "doesn't work"? — SGconlaw (talk) 16:44, 3 May 2018 (UTC)[reply]

Because of a bug in the search software. See a previous discussion on this topic: Wiktionary:Information desk/2018/April#how do you search these topic cat?. — Eru·tuon 17:08, 3 May 2018 (UTC)[reply]

Wikitext highlighting out of beta

Wikitext syntax highlighting, also known as CodeMirror, has been moved out of Beta Features and is available in the 2017 Wikitext Editor on all wikis. Syntax highlighting helps you see problems in your wikitext before previewing or publishing text. Please try out the tool if you did not do so while it was being developed, and feedback is welcome. - Keegan (WMF) (talk)

18:55, 4 May 2018 (UTC)

Module:etymology

Hello. I create this module on Azerbaijani Wiktionary. But I want write info.cat_name with lower case. How I can do that? For example change from English terms derived from Turkic languages to English terms derived from turkic languages. Please help me. --Drabdullayev17 (talk) 20:29, 4 May 2018 (UTC)[reply]

@Drabdullayev17: I looked at the modules and I will try to explain the problem and a possible solution. But perhaps you would want me to edit the modules instead.

info.cat_name has been set to either source:getCanonicalName() or source:getCategoryName(), where source is a language object from Module:languages or a language family object from Module:families. So you will have to edit Module:languages or Module:families, or their data modules such as Module:languages/data2 and Module:families/data, to change "Turkic" to "turkic".

Perhaps language and language family names need to be in lowercase in the data modules ("turkic", not "Turkic") because Azerbaijani doesn't capitalize language names. (But Azərbaycan, the name of the country, as the name for az, and it is capitalized.) Then you can capitalize the first letter of the category name (english terms derived from turkic languages → English terms derived from turkic languages) with code like the following: category_name = mw.getContentLanguage():ucfirst(category_name). — Eru·tuon 23:08, 4 May 2018 (UTC)[reply]

@Erutuon: thanks for your answer but I can't understand clearly. Can you do for me? --Drabdullayev17 (talk) 18:18, 5 May 2018 (UTC)[reply]

@Drabdullayev17: I made a change in az:Module:etymology to capitalize the category name. I changed "Turkic" to "turkic" in az:Module:families/data, but you will have to change the rest of the language family names. This may cause problems in places where language family names need to be capitalized. — Eru·tuon 20:54, 5 May 2018 (UTC)[reply]

@Erutuon: problem not solved, so undo all changes. Can you check az:ahmoq? --Drabdullayev17 (talk) 21:10, 5 May 2018 (UTC)[reply]

@Drabdullayev17: I looked at az:ahmoq; what was wrong? — Eru·tuon 21:13, 5 May 2018 (UTC)[reply]

@Erutuon: we need change category name (Özbək dilində Ərəb mənşəli sözlər → Özbək dilində ərəb mənşəli sözlər) --Drabdullayev17 (talk) 21:20, 5 May 2018 (UTC)[reply]

@Drabdullayev17: I guess you have to edit a language data module and change "Ərəb" to "ərəb". I believe the module is az:Module:languages/data2. — Eru·tuon 21:24, 5 May 2018 (UTC)[reply]

@Erutuon: this edit will create new problems. --Drabdullayev17 (talk) 21:30, 5 May 2018 (UTC)[reply]

@Erutuon: code which you add to az:Module:etymology give me an idea. Now problem is solved. Thank you very very much. --Drabdullayev17 (talk) 21:47, 5 May 2018 (UTC)[reply]

@Drabdullayev17: Well, that might cause problems. I don't know Azerbaijani, but I am guessing that some language names in the language data modules such as az:Module:languages/data2 are always capitalized (az, Azərbaycan) and some are not (ar, ərəb). Is this correct? — Eru·tuon 22:02, 5 May 2018 (UTC)[reply]

@Erutuon: not correct. If name of language first word of sentence it is capitalized, otherwise not. This rule include Azərbaycan. --Drabdullayev17 (talk) 23:00, 5 May 2018 (UTC)[reply]

@Drabdullayev17: Are you saying that Azərbaycan can be in lowercase: azərbaycan? — Eru·tuon 23:18, 5 May 2018 (UTC)[reply]

@Erutuon: yes if you mean language. Azərbaycan has two meanings: country and language. I give you some examples : Mən azərbaycan dilində danışa bilirəm. (I can speak Azerbaijani language.) Azərbaycan dili qədim dildir. (Azerbaijani language is old language.) Azərbaycan Asiyada yerləşir. (Azerbaijan locates in Asia.) Mən Azərbaycana gedirəm (I go to Azerbaijan.) --Drabdullayev17 (talk) 23:25, 5 May 2018 (UTC)[reply]

If so, there should be an entry for lowercase azərbaycan. But this rule is not followed in the article w:az:Azərbaycan dili: Azərbaycan dili is always capitalized, while fars dili and ərəb dili are not. — Eru·tuon 23:35, 5 May 2018 (UTC)[reply]

Wikitionary.org

I have a proposal, can WMF add "wikitionary.org" as an alias domain name for "wiktionary.org" ? It is currently being typosquatted, but it used to 404. The typosquatting could cause potential readers to gain unwanted malware. -- 65.94.42.219 03:53, 5 May 2018 (UTC)[reply]

You should email the Wikimedia office with this suggestion, they are the only ones who can act on it. - TheDaveRoss 04:17, 5 May 2018 (UTC)[reply]

Well, any of us could buy the website and set it to redirect. It may be more money than I'm willing to spend, but we'd have to find out. —Μετάknowledge^{discuss/deeds} 06:37, 5 May 2018 (UTC)[reply]

Are you the person trying to sell this domain? Equinox ◑ 10:35, 5 May 2018 (UTC)[reply]

No, I bumped into it when I was trying to get here. It used to 404, so it didn't matter too much (it was just annoying), but someone should have acted back then, since it would have been simple. Perhaps the ICANN namesquatting rules can be used to usurp the domain ownership. -- 65.94.42.219 11:40, 5 May 2018 (UTC)[reply]

links between connected Arabic characters

There's probably no way around it but inserting brackets breaks the display of Arabic connected letters, compare: عَنِّي (ʕannī) (connected) with عَنِّ ي (ʕanniy) (disconnected), even without diacritics: عن ي. --Anatoli T. ^{(обсудить}/^вклад) 03:52, 8 May 2018 (UTC)[reply]

Interestingly, I'm seeing عَنِّ ي (ʕanniy) and عن ي as connected on Firefox. Same with عَنِّي. But when I bring up Google Chrome, it has them disconnected. So I guess it depends on the browser or font engine or something whether Arabic characters that are separated by HTML tags are connected. — Eru·tuon 17:13, 8 May 2018 (UTC)[reply]

Request: parameter so Template:en-adj indicates 'more' or '-er' forms are uncommon

Inspired by Wiktionary:Tea_room/2018/May#doleful, a feature request: similar to how {{en-noun}} accepts a (short sequence of) parameter(s) that makes it display "usually uncountable, plural [x]", it would be useful if {{en-adj}} accepted some parameter(s) to display something like "comparative usually more doleful, sometimes dolefuler, superlative usually most doleful, sometimes dolefulest". Alternatively, allowing individual forms to be qualified, as in {{en-verb}}, could be useful. - -sche (discuss) 16:08, 9 May 2018 (UTC)[reply]

I'd support that. We'd need to add |gloss= parameters to the template. — SGconlaw (talk) 12:20, 20 May 2018 (UTC)[reply]

Misnested tags in entries

I have been working to reduce the number of entries with misnested tags or incorrect formatting (here) from upwards of 500 down to less than 50. There are some pretty interesting abuses of wikitext in the remaining pages, and it would be great if we could get the list down to zero. To identify where on the page the invalid wikitext is present, click the "edit" link on the lint errors page (this is not a normal edit link), then scroll through the edit box to find the highlighted text.

When this wiki is switched over to RemexHtml, the new wikitext presentation engine, the display of these pages may change. This could happen quite soon, so it is in the interests of this project to clean this up.

The errors in namespaces other than "main" are probably not worth worrying about. This, that and the other (talk) 11:57, 11 May 2018 (UTC)[reply]

FYI, the change to RemexHtml has now occurred. This, that and the other (talk) 12:48, 17 May 2018 (UTC)[reply]

Shortcut for Template:slim-wikipedia

I suggest Template:slim-wp, based on {{wp}}, which would be a handy shortcut. DonnanZ (talk) 13:18, 16 May 2018 (UTC)[reply]

There's already {{swp}}, but I've added your suggestion. --Per utramque cavernam 13:20, 16 May 2018 (UTC)[reply]

Ah, I wasn't aware of that one, anyway thanks. DonnanZ (talk) 13:32, 16 May 2018 (UTC)[reply]

@Per utramque cavernam: Um, there appears to be a missing ingredient, I'm getting the same wording as appears in the template. On the other hand, {{swp}} works fine. DonnanZ (talk) 14:47, 16 May 2018 (UTC)[reply]

The redirect was pointing to the template documentation page instead of the template. I've fixed it. — SGconlaw (talk) 15:23, 16 May 2018 (UTC)[reply]

@Sgconlaw: Yep, that works fine, cheers. DonnanZ (talk) 15:41, 16 May 2018 (UTC)[reply]

Whoops. --Per utramque cavernam 13:29, 17 May 2018 (UTC)[reply]

Why?

Why is it that I slap

{{citations}}

on Citations:aporically and it's fine, but doing so on Citations:paint the mice gives an error message? Also, why don't we get a bot to put

{{citations}}

on all Citations pages without it. Should we care about such a minor thing? I certainly don't. --Genecioso (talk) 10:23, 20 May 2018 (UTC)[reply]

By the way, use {{citation}} as {{citations}} is just a redirect to the former. — SGconlaw (talk) 11:28, 20 May 2018 (UTC)[reply]

We should probably reverse that, {{citations}} makes more sense as the main template. Also, that template has become way overbuilt over time. We don't use a bot to place the template on all citations pages because the template is supposed to include a language parameter. - TheDaveRoss 12:06, 20 May 2018 (UTC)[reply]

I can do the switch if there's consensus for it. (This is a hint for other editors to comment.) — SGconlaw (talk) 12:17, 20 May 2018 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ But to respond to Genecioso's original question, I have no idea why the template behaves that way. Pinging @Daniel Carrero, Erutuon who have edited the template and probably know more about how it works. — SGconlaw (talk) 12:19, 20 May 2018 (UTC)[reply]

`{{sa-IPA}}` is producing unusual HTML

It appears that sa-IPA is producing HTML with abnormal nesting, unless the "Raw HTML output" of Special:ExpandTemplates is wrong. The <div>s are very unusual. One of them seems to be opened before an <ul> and closed inside a <li>???

Firefox is also rendering the result as <li>s without enclosing <ul>s, which looks very weird. —Suzukaze-c ◇◇ 05:22, 21 May 2018 (UTC)[reply]

Possibly related: a couple hundred module errors where Module:translit-redirect is checking the script on empty parameters, "-", and on display forms that obviously weren't meant to be transliterated as Sanskrit. Chuck Entz (talk) 12:25, 21 May 2018 (UTC)[reply]

`{{quote-book}}`

When I put just a year in the date parameter, it generates May 21 as the day. See aguacatero. Ultimateria (talk) 15:06, 21 May 2018 (UTC)[reply]

Yes, that's an artifact of PHP's date handling. Use "year" as a parameter if you only have a year. DTLHS (talk) 15:29, 21 May 2018 (UTC)[reply]

Okay, but I do think this is a widespread (if minor) issue. I see about 160 examples just by searching "May 21". Ultimateria (talk) 21:38, 21 May 2018 (UTC)[reply]

@Ultimateria OK, please check Category:Pages with module errors. I've changed the code to throw an error if the date is a number. DTLHS (talk) 21:49, 21 May 2018 (UTC)[reply]

We could also create a module which pre-processes dates before sending them to PHP. I am not volunteering. - TheDaveRoss 11:38, 23 May 2018 (UTC)[reply]

User Scripts, are there any?

In using the dictionary extensively the browser history is a little lacking for tracking progress, so to speak. I have often desired a graph with semantic features, a mind map of sorts, with chronology or not. Before I eventually attempt to write my own, I thought it best to ask for existing solutions along that line, or other input. 89.204.137.210 21:05, 21 May 2018 (UTC)[reply]

Depending on what you want to accomplish, simply adding entries to your watchlist might be sufficient (that would let you know what you have looked at, if not when). Beyond that simple list there is nothing local to Wiktionary which sounds like what you are looking for. - TheDaveRoss 11:37, 23 May 2018 (UTC)[reply]

Bot request

The consensus here is to migrate {{ga-decl-adj-1}}, {{ga-decl-adj-1a}}, and {{ga-decl-adj-2}} to {{ga-decl-adj}}. This is going to be pretty complicated, but please do the following:

1. For {{ga-decl-adj-1}}:

Split |1= into |1= and |2= according to the guidelines given at {{ga-decl-adj}} (note that bh, ch, dh, etc. do NOT lenite)
Pass |2= (minus the new |1=) to |gsm=
Ignore |slender= for the most part (see below)
Pass |gsf= (once again, minus the new |1=) to |gsf= and set the new |gsf=~e if the old |gsf= is missing
Pass |pl= (minus the new |1=) to |pl= and set the new |pl= equal to "~e" if the old |pl= is missing and |slender= is there and "~a" if it isn't
Pass |comp= to |irrcomp=
Pass |nocomp= to |comp=-

2. For {{ga-decl-adj-1a}}:

Split |1= into |1= and |2= as outlined above
Add "ch" to the old |2= and pass it to |3= unless |2=ia; then do the following:
1. Add "iach" to the new |2=
2. Replace the "iach" with "iaiche" and pass it to |gsf=
3. Set |pl=~a
Pass |nocomp= to |comp=-
Ignore |sp=

3. For {{ga-decl-adj-2}}:

Split |1= into |1= and |2= as outlined above
Combine the old |2= and |3= into |3=
Take the "ú" or "amh" from |2= (if any) and move it to |3=
Pass |nocomp= to |comp=-

I know this is really complicated, but we would greatly appreciate if someone could do this for us. Esszet (talk) 17:35, 22 May 2018 (UTC)[reply]

I am happy to make and run the bot, but without knowing any Irish whatsoever I would only be willing to do so if others are willing to check my work. - TheDaveRoss 11:33, 23 May 2018 (UTC)[reply]

@Esszet I have done a little bit of preliminary work, even though I don't understand step one. Check out User:TheDaveRoss/Irish Adjectives and let me know what I should be doing differently! - TheDaveRoss 13:09, 23 May 2018 (UTC)[reply]

@TheDaveRoss:: Adjectives starting with b, c, d, f, g, m, p, sa, sá, se, sé, si, sí, sl, sn, so, só, sr, su, sú, t should have the first letter (or first two letters when the first letter is s) passed as |1= and omitted from the other parameters. Adjectives starting with anything else should have |1= empty. So it should be {{ga-decl-adj|d|ual|gsm=uail|gsf=~e|pl=~a}}, {{ga-decl-adj|g|ar|gsm=air|gsf=~e|pl=~a}}, {{ga-decl-adj|sá|il|gsf=~e|pl=~e}}, and so on. Otherwise, it all looks good at first glance. Thanks for doing this!! —Mahāgaja (formerly Angr) · talk 13:22, 23 May 2018 (UTC)[reply]

@Mahagaja: Thanks for that, it made things much clearer to me. Can you take another look at User:TheDaveRoss/Irish Adjectives to see if everything is in order? - TheDaveRoss 13:51, 23 May 2018 (UTC)[reply]

@TheDaveRoss: The list of letters I gave above should include capitals, so it should be {{ga-decl-adj|B|údaíoch|gsf=údaíche|pl=~a}} instead of {{ga-decl-adj||Búdaíoch|gsf=Búdaíche|pl=~a}}. (For the s-clusters only the S itself will be capitalized.) Otherwise I'm not finding any errors. Is it possible for the bot to throw up an error in case it finds one of the old template on a nonlemma ("adjective form" or "mutated adjective") page? They should only be on lemma forms, and on your sample I only see lemma forms, but it's remotely possible someone put one on an inflected or mutated form by mistake. —Mahāgaja (formerly Angr) · talk 13:59, 23 May 2018 (UTC)[reply]

@Mahagaja: Great, I updated the characters to include capitals. Could you provide a couple of example pages where the template should not appear (even if it doesn't currently) and I can try and skip and flag such cases for further review. - TheDaveRoss 14:05, 23 May 2018 (UTC)[reply]

@TheDaveRoss: Some pages where declension templates shouldn't (and currently don't) appear include bheag, boige, and dubha. However, it may happen that the lemma form of one adjective is homographic with a nonlemma form of a different adjective, though I can't think of an example at the moment. —Mahāgaja (formerly Angr) · talk 14:15, 23 May 2018 (UTC)[reply]

@Mahagaja: Can you elaborate on steps 2 and 3 in the declension 2 section? By combining does that mean that 2=x and 3=y become 3=xy? And what will it look like to move ú and amh? - TheDaveRoss 14:52, 23 May 2018 (UTC)[reply]

Sure. Taking some examples from Template:ga-decl-adj-2/documentation and Template:ga-decl-adj/documentation (plus one more for good measure):

{{ga-decl-adj-2|fearú|i|l}} → {{ga-decl-adj|f|ear|úil}}
{{ga-decl-adj-2|difriú|i|l}} → {{ga-decl-adj|d|ifri|úil}}
{{ga-decl-adj-2|fearamh|ai|l}} → {{ga-decl-adj|f|ear|amhail}}
{{ga-decl-adj-2|có|i|r}} → {{ga-decl-adj|c|ó|ir}}
{{ga-decl-adj-2|deac|ai|r}} → {{ga-decl-adj|d|eac|air}}
{{ga-decl-adj-2|gaisceamh|ai|l}} → {{ga-decl-adj|g|aisce|amhail}}

Clear as mud? —Mahāgaja (formerly Angr) · talk 15:03, 23 May 2018 (UTC)[reply]

@Mahagaja: I think I get it. Check out User:TheDaveRoss/ga-decl-adj-1a and User:TheDaveRoss/ga-decl-adj-2 when you get a moment. - TheDaveRoss 15:11, 23 May 2018 (UTC)[reply]

@TheDaveRoss: {{ga-decl-adj-1a|2=iach}} can't be converted to {{ga-decl-adj|3=iach}}, so leispiach should have {{ga-decl-adj||leispiach|gsf=leispiaiche|pl=~a}} (N.B. -iaiche, not *-iache). —Mahāgaja (formerly Angr) · talk 15:24, 23 May 2018 (UTC)[reply]

Oh, and even though Esszet says to ignore |sp=, I'd prefer it if the bot didn't touch templates with |sp=old. Those shouldn't be migrated yet. (At some point we're hoping to get a module to do all this work instead of the complexity of {{ga-decl-adj}}, but neither Esszet nor I know how to write a module.) —Mahāgaja (formerly Angr) · talk 15:28, 23 May 2018 (UTC)[reply]

@Mahagaja: On leispiach the current template is {{ga-decl-adj-1a|leisp|ia}}, which appears to follow Esszet's 2.2. In such cases the new form should be {{ga-decl-adj||ROOTiach|gsf=ROOTiache|pl=~a}}? Should I skip only cases where "sp=old" or any instance which has "sp" at all? - TheDaveRoss 15:35, 23 May 2018 (UTC)[reply]

Yeah, I don't know why he said that. {{ga-decl-adj}} doesn't recognize the parameter |3=iach at all. The form should be {{ga-decl-adj||ROOTiach|gsf=ROOTiaiche|pl=~a}} (don't forget the extra i before the ch!). Please skip only cases where "sp=old"; cases with "sp=new" or "sp=both" can be processed and the "sp=" part ignored. —Mahāgaja (formerly Angr) · talk 15:45, 23 May 2018 (UTC)[reply]

I said to pass “ROOTiaiche” to |gsf=, not “iach” to |3=. I didn’t say anything about |3= there at all. Esszet (talk) 16:05, 23 May 2018 (UTC)[reply]

@Mahagaja, Esszet I updated the 1a variant further to reflect the changes you mentioned, please let me know if you see anything wrong on User:TheDaveRoss/ga-decl-adj-1a. - TheDaveRoss 16:45, 23 May 2018 (UTC)[reply]

Looks good to me. Esszet (talk) 11:40, 24 May 2018 (UTC)[reply]

Great, thanks. If everything looks good I'll start updating them. I'm not going to use the bot flag, since I won't be able to catch errors easily I would like others to be able to see the changes I am making. - TheDaveRoss 12:05, 24 May 2018 (UTC)[reply]

@Mahagaja, Esszet The content of the page changed with the template update, so I stopped. Take a look at the declension sections of this diff. - TheDaveRoss 12:13, 24 May 2018 (UTC)[reply]

What, do you mean that, for example, the nominative feminine singular changed from boireannach to bhoireannach? It’s supposed to do that, that’s one of the reasons we’re doing this. Esszet (talk) 13:38, 24 May 2018 (UTC)[reply]

Ok, good, I wasn't aware that there were errors in the existing template. I'll start it going again. - TheDaveRoss 15:25, 24 May 2018 (UTC)[reply]

It's not really an error in the old template; it's a matter of interpretation. Basically, (1) the nominative feminine singular form of an adjective is the same as the nominative masculine singular, e.g. boireannach; (2) an adjective in the nominative feminine singular undergoes lenition (which changes b- to bh- among other things) after a noun; and (3) attributive adjectives (virtually) always follow the noun, so: The nominative feminine singular of boireannach always appears as bhoireannach in running text. The old template shows the unmutated form and simply assumes the reader knows enough about Irish grammar to know when to apply lenition; the new template shows the mutated form directly. —Mahāgaja (formerly Angr) · talk 20:27, 24 May 2018 (UTC)[reply]

That seems like something worth mentioning on Wiktionary:About Irish, especially if the unmutated form is theoretically possible(?). - -sche (discuss) 01:46, 25 May 2018 (UTC)[reply]

Thanks for clarifying, I just want to be cautious since I don't know Irish. - TheDaveRoss 11:49, 25 May 2018 (UTC)[reply]

These templates are completely removed from NS:0. I labeled some edits "CHECK" in case they were non-lemma. - TheDaveRoss 16:45, 25 May 2018 (UTC)[reply]

I don't know what NS:0 is, but I'll take that to mean the request has been carried out. Thank you very much, Dave, you've been a really big help here. Esszet (talk) 22:10, 25 May 2018 (UTC)[reply]

NS:0, aka Mainspace, is the main namespace of the dictionary: those pages without namespace prefixes such as Wiktionary: or User: or Appendix: or Reconstruction: Chuck Entz (talk) 00:13, 26 May 2018 (UTC)[reply]

Ah, OK, now I understand. Esszet (talk) 02:04, 27 May 2018 (UTC)[reply]

Module Errors in Invocations Passed as Parameters to Parser Functions

@Wikitiki89. At the moment, נ־ש־א is in CAT:E, but there's nothing on the page itself that explains why. That's because the template {{HE root see}} is passing {{#invoke:he-utilities|plain_root|{{#if:{{{1|<noinclude>x</noinclude>}}}|{{{1<noinclude>|כתב</noinclude>}}}|{{SUBPAGENAME}}}}}}}} to {{derivsee}}, which in turn passes it to the parser function #categorytree. Parser functions, generally, are designed to fail gracefully and invisibly if given bad input, so all the big fat screaming red lua-error displays are swallowed silently and nothing is displayed.

This is very bad interface design because contributors using {{HE root see}} have to know about templates and about parser-function behavior to find out why there's a blank space where the template display should be- if they even notice. I had to copypaste the invocation syntax with the parameter substituted in into the edit window and preview it to see the error display (the module didn't like the middle letter in the root).

Even people who know Lua and the rudiments of template coding might have problems figuring this out. Fortunately, I've run into this kind of thing before, so I knew to look through the templates listed until I found one that fed a parameter into a parser function.

We need to develop some way to make sure this doesn't happen. Ideally, all input for parser functions should be checked, and errors displayed rather than passing the input to the parser function. Sure, it adds to the complexity of the code, and it requires extra memory and often extra expensive-function calls, but we need to make it easier for our contributors to do things right.

Perhaps we need to make sure that all modules used in such ways have a validity-check function and/or something like the err function at Module:languages, or maybe we need to include intermediate code in the template that checks the parser-function inputs for error messages and decides whether to display the text as errors or feed it to the parser functions.

As an aside, it would also be nice to include better error handling in the translation adder so it doesn't add masses of error text to the entry when someone uses a bad language code.

Thanks! Chuck Entz (talk) 00:08, 26 May 2018 (UTC)[reply]

Bug: The "Expand" button in `{{zh-pron}}` is pushed down by Wikipedia link and images

Examples: 中文, 月季

Adding "overflow: hidden" to div.zhpron fixes this, but I don't know if it's the appropriate solution. — This unsigned comment was added by 2001:da8:204:1088:a0f9:7563:cf87:8edb (talk).

@2001:da8:204:1088:a0f9:7563:cf87:8edb Thanks!!! I have added it. Others: if this is not the right way to fix it or if there are better ways available, please revert / amend. Wyang (talk) 08:17, 28 May 2018 (UTC)[reply]

Change in behavior of various templates in handling of "tr" values -- formatting no longer respected

The behavior of various templates including {{compound}} and {{m}} has changed some time in the past few weeks, such that formatting in tr strings has become problematic.

In the past, the tr values were output surrounded in  tags, such that {{m|[LANG]|[TERM]|tr=[STRING]}} would produce the equivalent of [[[TERM]#[LANG]|[TERM]]] ([STRING]). In cases where additional transliterations were required, one could add a closing  tag after the first transliteration and a  tag before the second one. This worked fine for years, such as at 藍: {{m|ja|青|tr=ao, formerly awo||[[blue]]}} reliably produced 青 (ao, formerly awo, “blue”) -- where the ", formerly" is contrastively not in italics, while "ao" and "awo" are both italicized.

(NB: Alternative approaches, such as using the pos parameter for such additional information, do not work -- the pos values are always placed after the tr values and after the term gloss.)

However, with the recent changes, the above tag-based approach fails: inspecting the markup shows that the closing tag is stripped, resulting in too many opening  and unwanted italicization of the rest of the paragraph. Attempting to use '' wikitext instead of  fails: the rendered markup shows that the first '', which is expected to turn off italics, is instead an opening italics , while the second '' closes it as , which ultimately does nothing in an already-italics context. Experimentation shows that certain inline closing tags (, , ) are stripped, no matter how many were added, but some (such as ) are kept -- suggesting that the underlying module is doing some kind of selective cleanup.

For the {{compound}} template, one related change appears to be this one by Benwing to Module:compound in late April. However, that itself was in response to changes in other modules, and I have not been able to find any similar changes to {{m}} or Module:links.

This change in behavior is a problematic deviation from past norms, and it is causing a bit of a mess on various JA entries that were formatted in accordance with the past behavior. I'd greatly appreciate it if someone could 1) explain where the change occurred, 2) explain the reasoning behind this selective stripping of markup from tr strings, and 3) either back out these changes to tr behavior, or explain how to again achieve output like 青 (ao, formerly awo, “blue”).

TIA, ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:17, 29 May 2018 (UTC)[reply]

I suspect that this is related to recent changes to the Mediawiki HTML parser and not something that we can directly control. DTLHS (talk) 16:22, 29 May 2018 (UTC)[reply]

That seems likely. I suppose the solution is to add a parameter for this. "ftranslit"? "fxlit"? - -sche (discuss) 05:29, 30 May 2018 (UTC)[reply]

Why would the MW HTML parser strip some tags but not others?
Why would reverting the above-linked change to Module:compound cause {{compound}} to not strip things quite so aggressively?

At least some of this looks like something going on in our modules. However, the module code is sufficiently spaghettified that I can't track through the execution path well enough to figure out what's going on.

As an alternative to adding yet another parameter, how hard would it be to check the tr argument string for wikicode and handle it accordingly?

The tr string is output in  tags, which render in italics according to our CSS. The current behavior takes a tr input string like ''this'' sample and outputs it as like this sample. However, since the context of the string (as enacted by the  style) is already italics, the  tags don't do what we'd expect -- the anticipated behavior for the ''this'' would be non-italics. More ideally, the tr output when using ''italic wikicode'' would be something more like like this sample.

Would such output be feasible?

Ideas, as we try to figure out how to deal with an unstable foundation for our infrastructure. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:58, 30 May 2018 (UTC)[reply]

@Benwing -- do you have any insight you could relate concerning your change to Module:compound? ‑‑ Eiríkr Útlendi │^{Tala við mig} 04:25, 1 June 2018 (UTC)[reply]

@Eirikr The change you reference was only to restore an earlier behavior, and it should have only affected the situation where langN= was specified in {{affix}} or similar templates. I did notice a change a month or two ago where the translation stopped being in italics in certain places (maybe in headwords?), but I figured that was an intentional change, and it may be unrelated to the problem you're seeing. There have been a lot of code changes by User:Erutuon affecting these modules, and some by User:JohnC5; it's possible they may have changed this behavior, but I'm not sure. You're right that the code is quite complex. Benwing2 (talk) 14:19, 1 June 2018 (UTC)[reply]

I might have been the one to change things so that transliteration is no longer enclosed in a  tag when Module:script utilities is tagging transliteration with the "term" markup. The term markup is used by {{m}} for instance, as well as many etymology templates such as {{der}}. I did this because transliteration parameters sometimes include kana, which shouldn't be italicized. There is a note to this effect in Module:script utilities/data.

I don't like the idea of including non-transliteration stuff in a transliteration parameter; it messes with the integrity of the HTML. Both transliterations should be formatted with class="tr mention-tr" and with lang="language code-Latn", and the non-transliteration text should not be. But it is clear that the non-transliteration stuff is sometimes needed. I don't know what the solution should be. More parameters, some markup to indicate which part of the transliteration parameter is actually transliteration and should be tagged, separate templates for whatever languages need this annotation in the transliteration parameter? — Eru·tuon 22:27, 1 June 2018 (UTC)[reply]

Make Template:head accept 'adj' as an alias for 'adjective'

Can someone do that? Because, as here, people (including me when I'm not thinking about it) recurringly use it as the POS parameter, because because it's much shorter to type and it works in e.g. {{m|en|valid|pos=adj}} and is used in naming many headword-line templates. - -sche (discuss) 07:57, 30 May 2018 (UTC)[reply]

And 'adv' for 'adverb', as here. (Alternatively, we'll have to keep doing periodic checks for entries which use these abbreviations in {{head}}.) - -sche (discuss) 08:04, 30 May 2018 (UTC)[reply]

Why stop with those? 'n', 'v', 'conj'/'j', 'pron', 'prep', 'det', 'prop'/'propn' could all prevent/delay carpal tunnel syndrome. DCDuring (talk) 19:50, 30 May 2018 (UTC)[reply]

POS categorisation Template:affix vs. Template:suffix

I've just noticed the {{suffix}} template has a useful feature that {{affix}} doesn't have. I want to split CAT:French words suffixed with -ment in CAT:French adverbs suffixed with -ment + CAT:French nouns suffixed with -ment. At abondamment, writing {{suffix|abondant|-ment|lang=fr|pos=adverbs}} produces automatic categorisation to the right subcat, while {{af|fr|abondant|-ment|pos2=adverbs}} doesn't. Would it be possible to give that behaviour to {{affix}} as well? --Per utramque cavernam 20:39, 30 May 2018 (UTC)[reply]

Works for me, or has someone fixed this since the question was posted? —Mahāgaja (formerly Angr) · talk 12:03, 1 June 2018 (UTC)[reply]