Wiktionary:Grease pit/2019/September

Hi, on the search page I get the possibility to choose language and then a suitable new-template to create a page with a skeleton.

This does not work at all for Swedish or Danish, presumably because the templates are missing. Is that correct?--So9q (talk) 03:45, 2 September 2019 (UTC)

I found these https://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Swedish_entry_templates and a hint there telling me to change my language in the preferences to see the templates.

This is unsatisfactory for these reasons:

1. I can only see templates for one language even though I'm trilingual.
2. I prefer the English layout and would prefer a solution that does not force me to change.
3. They don't show up in the search like when I have English in the preferences.

I would like to improve this situation but I don't know where to start.--So9q (talk) 03:59, 2 September 2019 (UTC)

@So9q: The messages that you are seeing above the search results are located at MediaWiki:Noexactmatch and MediaWiki:Searchmenu-new. (There's also MediaWiki:Searchmenu-exists.) Wiktionary:Swedish entry templates seems to be out of date. (MediaWiki:Nogomatch/sv and MediaWiki:Noexactmatch/sv aren't used anymore.) Now it looks like the messages displayed for each language in Special:Preferences are controlled by subpages of MediaWiki:Noexactmatch and MediaWiki:Searchmenu-new. For instance, the Swedish text can be changed by creating MediaWiki:Noexactmatch/sv and MediaWiki:Searchmenu-new/sv. These pages can only be edited by sysops and interface admins, so I can help if you draft pages in your userspace. — Eru·tuon 06:38, 2 September 2019 (UTC)

@erutuon: Perfect! Thanks.--So9q (talk) 10:02, 2 September 2019 (UTC)

I noticed that the selector in the box on both MediaWiki:Searchmenu-new and MediaWiki:Noexactmatch is useless as it does not change the page to show the relevant templates for the language choosen. Is that a JS-bug?--So9q (talk) 10:43, 2 September 2019 (UTC)

Just noticed this on MediaWiki_talk:Noexactmatch: This system message is not currently used. The current one is Mediawiki:Searchmenu-new.. Is that true?

I'm done translating both. Se User:So9q/MediaWiki:Searchmenu-new/sv, User:So9q/MediaWiki:Noexactmatch/sv--So9q (talk) 11:06, 2 September 2019 (UTC)

@So9q: I thought I saw MediaWiki:Noexactmatch on the search page, but can't reproduce it so the talk page must be right. I copied your page to MediaWiki:Searchmenu-new/sv.

I can't even see a selector next to "Select a different language", if that's what you're referring to. It looks like it must have used JavaScript at some point in the past. — Eru·tuon 16:27, 2 September 2019 (UTC)

Hi guys,

can anybody fix the Bashkir declension template? It's misbehaving (or, properly, refusing to work) in һүҙ.

Thanx, Borovi4ok (talk) 08:26, 2 September 2019 (UTC)

Hello. I would like to request for help with the following entries: KevinUp (talk) 13:30, 2 September 2019 (UTC)

(Previous discussion at User talk:Tooironic#Romanization)

Convert the ==Chinese== header to ==Mandarin== for these 7000 Mandarin entries:

Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

 Done. @KevinUp I forgot to write code to reorder the sections alphabetically, but I haven't seen any instances where more than one language occurs on any of these pages (all of which appear to be Romanization pages). If you see any, let me know and I'll write the script to fix them. Benwing2 (talk) 20:16, 15 September 2019 (UTC)

Convert the ====Compounds==== header to ====Derived terms==== for these 480 Japanese entries that are not single character kanji:

Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

 Done. @KevinUp I also rearranged the resulting Derived terms section after Synonyms and Antonyms as needed, for consistency with WT:ELE. Benwing2 (talk) 21:23, 15 September 2019 (UTC)

(Previous discussion at https://en.wiktionary.orghttps://dictious.com/en/User_talk:Poketalker#Template_%7B%7Bbor%7Cja%7Cltc%7D%7D)

Convert {{bor|ja|ltc to {{der|ja|ltc for these 170 Japanese kanji entries:

Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

This is simple enough that it doesn't require a bot, just AutoWikiBrowser or JavaScript Wiki Browser, so I'm doing it. — Eru·tuon 23:29, 7 September 2019 (UTC)

 Done. Thanks for correcting the entries. KevinUp (talk) 00:17, 9 September 2019 (UTC)

Remove the following bad links in 160 Chinese entries:

* http://www.trade.gov.bt/administration/mktbriefs/10.pdf
* http://www.koreantk.com/en/m_sta/med_stat_search.jsp?searchGbn=statis
* http://www1.dict.li

Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

 Done. @KevinUp Benwing2 (talk)

Adjust header level of ====Anagrams==== from L4 to L3 (136 entries).

@Benwing2 Hi. Would it be possible for you to assist with these tasks (Items 1,2,4,5)? KevinUp (talk) 15:21, 15 September 2019 (UTC)

@KevinUp Yup, I'll look into them. Benwing2 (talk) 16:12, 15 September 2019 (UTC)

 Done. @KevinUp I semi-manually moved the Anagrams section to the end as required by WT:ELE. Benwing2 (talk) 21:51, 15 September 2019 (UTC)

Incorrect use of {{etyl}} for cognates (65 entries).

Another one. KevinUp (talk) 16:18, 15 September 2019 (UTC)

Hi, I coded again today and came up with a script to filter the translations appearing when translations are shown. This is much cleaner than the default "Select target translations" that does not work with the TranslationsAdder and is IMO hard to read.

A week ago I created the automatic input filler for the TranslationsAdder and it works very well.

These two scripts rapidly speed up the time to translate between similar languages like the nordic languages nb, sv, da but might be useful for oters too. Give them a spin and tell me what you think.--So9q (talk) 07:20, 6 September 2019 (UTC)

Discussion moved from WT:Information desk.

Maybe better suited here - New editors’ contribs suddenly stopped working. Why and how can it be fixed? --Robbie SWE (talk) 09:17, 6 September 2019 (UTC)

When editing, I now have colours and different sized text. Where did this come from? I haven't decided if I like it yet, so where can we turn it off? --Mélange a trois (talk) 21:12, 6 September 2019 (UTC)

I guess you mean the syntax highlighting. I'm surprised you're just remarking on it now, because it was added a while back. There's a thing that looks like a marker on the top toolbar that you can click to turn it off (see mw:Extension:CodeMirror). — Eru·tuon 04:10, 8 September 2019 (UTC)

I've tried a spot of googling about, but I can't find anything terribly informative about collation for Japanese.

Specifically, there are two wrinkles to Japanese sorting that I'm trying to address.

• Hiragana is the canonical script for sorting. However, even for all-hiragana entries, the sorting algorithm doesn't seem to know how to handle kana with diacritics, the 濁点 (dakuten) or voicing mark 〃 as in が (ga) versus unvoiced か (ka), or the 半濁点 (handakuten) or half-voicing mark ゜ used to indicate a /p/ sound for kana in the "H" row, as in ぴ (pi), versus unmarked ひ (hi). Any kana + dakuten should come after the plain kana, and handakuten should come after any dakuten.

Our cludge has been to manually include sortkeys and add apostrophes at the end of the sortkey to force the proper sorting -- but this is a cludge. This shouldn't be needed at all.

• The set of katakana describes exactly the same phonemes as hiragana. This is vaguely akin to UPPER CASE and lower case in the Latin alphabet, in that there are two sets of glyphs for each letter. In Latin-alphabet collations, AAM comes before aam, and both come before aamchur, which comes before AAMFT, etc., as seen now at Category:English lemmas. In more-functional Japanese dictionaries, a string spelled in hiragana comes before the same string spelled in katakana. In our MediaWiki-based system, all hiragana entries incorrectly come before any katakana entries.

Our cludge has been to manually include sortkeys in katakana entries. This also shouldn't be needed at all.

Does anyone here happen to know:

• Where is the Japanese collation is configured? Is there a page we can access, or is it some config file buried in the server setup where we'd need MediaWiki's help?
• If we need MediaWiki help, where would we post an inquiry?

TIA, ‑‑ Eiríkr Útlendi │^{Tala við mig} 23:12, 6 September 2019 (UTC)

No categories use Japanese collation; according to mw:Help:Sorting and mw:Manual:$wgCategoryCollation I guess all categories are sorted using a single collation, for the most part based on code point values, with uppercasing of sortkeys. It might be "uca-default", though I don't know where to go to find that out. So all pages with hiragana sortkeys are sorted before before all pages with katakana sortkeys, あ..ん..ア..ン, because the Hiragana block has smaller code points than Katakana block. (That is, a katakana sortkey sorts after the corresponding hiragana sortkey, but also after all other hiragana sortkeys.)

To change this, the MediaWiki developers would have to come up with a way to change collation for individual categories (Phabricator task). Then Japanese categories could use a Japanese collation, while other languages' categories could use their own collation system if it exists. This has been discussed before (for instance, Wiktionary:Grease pit/2017/August § Language-specific alphabetisation). — Eru·tuon 00:01, 7 September 2019 (UTC)

I would find it helpful to have subcategories that further distinguish categories like Category:Latin_masculine_nouns_in_the_first_declension according to whether the entries are for proper nouns or common nouns. I created the category pages, then realized that they wouldn't be filled with anything unless Module:la-headword is edited to assign the new categories to pages. All of the necessary information is already in the system, so the edits should be fairly simple: I think changing Line 332, and maybe a few other lines would be enough. Can anyone help with this?--Urszag (talk) 08:08, 8 September 2019 (UTC)

(Notifying Fay Freak, Brutal Russian, JohnC5, Benwing2): This is definitely doable. However, before doing this we should get rid of categories like CAT:Latin common nouns in the third declension, which refers not to non-proper nouns but to nouns of "common" gender. Either we put such nouns in both CAT:Latin masculine nouns in the third declension and CAT:Latin feminine nouns in the third declension, or we can put them in

Also, if we subdivide noun categories into common nouns and proper nouns, should we also keep the combined "nouns" category (so that a common noun goes into e.g. both CAT:Latin masculine nouns in the third declension and CAT:Latin masculine common nouns in the third declension), or eliminate it? If we eliminate it, should we name the common noun categories "common nouns" or just "nouns"? Benwing2 (talk) 22:33, 15 September 2019 (UTC)

I have eliminated the "common" (epicene) gender in favor of just specifying |g=m|g2=f. The |g=c spec was underused, in any case. If we want categories like CAT:Latin epicene nouns in the third declension, they can be implemented by checking for nouns where both masculine and feminine gender is specified. Benwing2 (talk) 02:31, 16 September 2019 (UTC)

I think there is no such thing as an “epicene gender”. We can distinguish grammatical gender and natural gender. The latter is not a property of the noun per se but of the referent of a noun, and therefore is only meaningful if that referent is a natural person or other animal, or something else to which personhood is ascribed (a god, a living statue, ...). When a Latin noun refers to a gender-bearing referent, the most common situation is that the grammatical and natural genders agree. For example, filius eius scriptor est vs. filia eius scriptrix est. In this case, there are two forms of the noun, revealing the gender. For other nouns the masculine and feminine forms coincide: Lucius heres suus est vs. Lucia heres sua est. Then the use of “m or f ” is appropriate. Theoretically, we could have two separate entries hērēs m and hērēs f, but that would be unnecessarily duplicative and confusing. Such a dual-gender noun is not epicene. As far as I know there is no agreed techical term for them (in the context of Latin grammar). Finally, there are nouns that have one fixed grammatical gender, regardless of the natural gender of the referent. It is always persona sua, also when the referent is a man. Such nouns are called “epicene”, but they have an invariant grammatical gender, either masculine or feminine. An example of a masculine epicene is passer: passer meus trēs ōva pāruit. Being epicene is a property of the Latin noun, not of the gender.  --Lambiam 09:50, 16 September 2019 (UTC)

It would not be inappropriate to have a Category:Latin epicene nouns, which are found in all declensions. I think their epicene nature should be mentioned with the entry, perhaps as a usage note. If we want a category for nouns like heres, we could use Category:Latin dual-gender nouns in the third declension.  --Lambiam 10:02, 16 September 2019 (UTC)

I think it would be good to keep the combined "nouns" category. Being able to see a combined list of common and proper nouns of a certain gender that inflect a certain way can be useful in some circumstances. (In particular, I believe that some gender/declension combos have so few nouns that all of them can easily be taken in without separating proper nouns.) Unfortunately, as Lambiam said, "epicene" often means something different, so it's not a great term to use (I think may be used differently by different sources). I don't know of an exact synonym for the term "common gender", but I think it's not too ambiguous when the word "gender" is retained: a wording like "common gender nouns" is hopefully not easily confusable with "common nouns".--Urszag (talk) 13:21, 18 September 2019 (UTC)

Hi. @Erutuon helped me create lists for da, nb, sv where there is a translation of a noun missing a gender. I estimate after correcting 50 or so manually that 98% of the danish ones need common gender (c) and I am looking how to best automate this.

My current plan is to insert (c) into the danish translations if there is a nb or sv translation AND no (n) appear in either of them.

Is AWB useful for doing this? I installed it and would like to be added to the list of users. Thanks in advance.--So9q (talk) 10:07, 8 September 2019 (UTC)

I'm not sure if AWB could reliably filter pages in the way you describe, but it could probably do the replacements. — Eru·tuon 17:31, 8 September 2019 (UTC)

I don't think running a bot task with only an accuracy of less than 100% is a good idea. --{{victar|talk}} 03:26, 9 September 2019 (UTC)

AWB isn't quite a bot. You have to click a button to save the edit, and it shows you a diff. — Eru·tuon 05:12, 9 September 2019 (UTC)

Yeah, that is my intentional use of it.--So9q (talk) 06:00, 14 September 2019 (UTC)

You'll have to check the edits; the Swedish and Bokmål words don't always look like they are cognate with the Danish. See the list here. — Eru·tuon 05:12, 9 September 2019 (UTC)

Of course I will check the edits. :)

Regarding the list: I'm only talking about editing the gender and no genders appear in that list. I know they are not cognate on the lexeme level (maybe 50-75%) but the gender correlation is very strong (as I estimated above 95%).--So9q (talk) 06:00, 14 September 2019 (UTC)

The New Entry Creator hasn't been working properly for a month or so, ever since another change was made (when language headers suddenly appeared larger when editing). It has the default setting of English noun, no other language or part of speech can be selected. It has to be overwritten manually for anything other than an English noun. DonnanZ (talk) 12:02, 10 September 2019 (UTC)

@Donnanz: I can't reproduce this in my browser (Firefox, Linux). For me, it shows English noun by default, but I can click on the other parts of speech, and can choose a language code by typing it into the box, in which case preprogrammed PoS options show up as expected. I haven't used it much so I'm not sure if that's how it's supposed to work. (Sometimes there's an error message "missing ( before condition" in the JavaScript console when I click a PoS, which ought to be fixed, but I haven't found the source; it might be in the JavaScript that the gadget dynamically inserts into the HTML.) Is that how it's supposed to work?

There haven't been any changes to User:Yair rand/newentrywiz.js that could explain this, so the cause must be somewhere else. (I haven't noticed a change in the size of headers.) Maybe your browser changed its behavior, or some other JavaScript code changed and started interfering with the NEC. — Eru·tuon 18:37, 10 September 2019 (UTC)

@Erutuon: I use Windows 10 with Chrome these days. With NEC I can type in the language and click on a PoS, but nothing happens below like it should, no changes are made. If you can't find what's wrong I will have to accept the fact. Level 2 headers increased in size at the same time NEC went wrong, but that can only be noticed when creating or editing an entry (if I change level 2 to level 3/4/5 it goes to normal size). DonnanZ (talk) 19:01, 10 September 2019 (UTC)

@Donnanz: Okay, I went onto the latest version of Chrome on Windows 10 and it still works. Maybe it's an interaction with something else that you have installed, like a gadget or script, then. — Eru·tuon 19:44, 10 September 2019 (UTC)

@Erutuon: I don't think so, my set-up is pretty standard, in fact there are scripts like Avestan I can't read, my browser doesn't recognise them, but I'm not bothered by that. I have the ability to change keyboards, a click-on feature available on Windows. I can't think of anything else. DonnanZ (talk) 20:12, 10 September 2019 (UTC)

@Donnanz: I was thinking more of Wiktionary gadgets and scripts written in JavaScript. But it looks like you don't have any .js files in your userspace so if anything is interfering, it could only be in the Gadgets tab of Special:Preferences or in WT:PREF. I guess it would be a good idea to see if the NEC is producing any error messages. Could you do the following? Start up the NEC, open the JavaScript console in the browser by pressing the F12 key and clicking on "console", type in a language code and click a PoS in the NEC (or whatever you would normally do), and post any messages that appear at the bottom of the console as a result. — Eru·tuon 20:57, 10 September 2019 (UTC)

@Erutuon: OK, I got a message when I clicked on Adjective: Uncaught SyntaxError: Unexpected index.php?title=søppelsekk&action=edit&editintro=User:Yair_rand/usenec:1. Does that help? Nothing came up when I first inserted nb (language). Actually for this entry it's a noun, not an adjective, I just pressed it accidentally. DonnanZ (talk) 21:47, 10 September 2019 (UTC)

That sounds like the same error that I was seeing, but the NEC was still working. Ohh! Maybe by the big header thing you mean the wikitext syntax highlighting in the edit box (mw:Extension:CodeMirror). I had it off. When it's on, it kept the NEC from changing the contents of the edit box. (It's toggled with the marker button in the top edit toolbar.) I edited the NEC script to use a different method, and now the NEC works for me even with syntax highlighting enabled. Does it work for you now? — Eru·tuon 23:00, 10 September 2019 (UTC)

@Erutuon: I haven't done any more entries using it yet, but I tried NEC on crashbangwallop as a fake Norwegian adjective. It seems to be working now, you could test that one yourself. I'm still getting large level 2 headers when I click on edit, anyway thanks a lot for the hard work. DonnanZ (talk) 10:56, 11 September 2019 (UTC)

@Donnanz: If it's the syntax highlighting (mw:Extension:CodeMirror) that's making the headers large, you can click the marker icon in the edit toolbar to change them back to normal. — Eru·tuon 18:29, 11 September 2019 (UTC)

@Erutuon: That's much better, no longer disconcerting. Cheers. DonnanZ (talk) 19:30, 11 September 2019 (UTC)

I have added several Unami entries, and have noticed that entries with diacritics do not link properly. Translations on other pages do not link with the words (with diacritics) even though they are spelled identically, but to the same spelling with no accents. Can someone familiar with templates help remediate the issue. Hk5183 (talk) 03:37, 11 September 2019 (UTC)

@Hk5183: The language data for Unami in Module:languages/data3/u provides entry name replacements so that linking templates will link to forms without diacritics. This seems to fit certain entries (alente, which shows alënte in the headword line), but not others. It can be changed, but whichever convention is chosen, all entry names should follow it so that links will work. — Eru·tuon 03:53, 11 September 2019 (UTC)

This is tagged as squash (sport), which I think is pretty lame, squash is fine. There's no way anyone reading the definition would be confused between the sport and the vegetable or juice. --Mélange a trois (talk) 10:20, 13 September 2019 (UTC)

Belongs in Tea Room. DCDuring (talk) 13:08, 13 September 2019 (UTC)

As exemplified here in BP the mobile frontend currently only collapses translation and similar "boxes". This means that entities like "rock" are very very long because the derived terms are many and are shown in full in one column. Additionally this also hides the quotations by default which also shortens the amount of scrolling and increase the readability of the page substantially.

Today I found out how to enable all the visibility toggles on mobile thanks to @Erutuon. I suggest replace the content of MediaWiki:Mobile.js with this:

// Make all collapsing work on mobile (e.g. der3 and rel3)
mw.loader.load(  );
importScript( 'MediaWiki:Gadget-VisibilityToggles.js' ); // Backlink: ]
importScript( 'MediaWiki:Gadget-defaultVisibilityToggles.js' ); // Backlink: ]

The reason for "replace" is that the old code in Mobile.js is a duplicate of our visibility toggles and I prefer to reuse code from the desktop site if possible.

The above configuration is tested on GNU Icecat v60.5.1 from F-Droid. To test this yourself insert the above in your minerva.js and visit the mobile frontend.

I do not believe we need to vote on this change as you already voted on the collapsing of lists in 2018 for the desktop site and this just brings the result into effect on the mobile frontend also.--So9q (talk) 05:47, 14 September 2019 (UTC)

As I understand it, that method of loading the gadgets is less efficient because it sends individual requests to the server for each script. It's better to load the gadget and its dependencies more efficiently with ResourceLoader by adding targets=desktop,mobile to the options for defaultVisibilityToggles in MediaWiki:Gadgets-definition. I'll try this, and I hope people who actually use the mobile site will post here if they encounter bugs. — Eru·tuon 16:24, 14 September 2019 (UTC)

Okay, collapsing finally works on mobile after I fixed a syntax error. — Eru·tuon 17:26, 14 September 2019 (UTC)

Congratulations! Jippie! I can confirm it works on my mobile :D. One thing is different from the desktop frontend and that is the color of the JS-links (show more), it is black not blue as it should be. Is some CSS missing perhaps?--So9q (talk) 18:12, 14 September 2019 (UTC)

It's because of a style rule that you can find in the Inspector window. It seems to be connected to the Minerva skin (Vector seems to have a different rule for the same selector):

a:not() {
	color: #222222;
	cursor: pointer;
}

It looks like it's meant to make a tags without a URL look like they aren't clickable. I suppose it could be overruled by adding a class to toggles in MediaWiki:Gadget-defaultVisibilityToggles.js (somewhat laborious) and adding a style rule that targets that class. — Eru·tuon 01:57, 16 September 2019 (UTC)

@Benwing2, Erutuon: all collapsible elements in entries such as quotations and translation tables seem to have failed, probably due to some recent edit. See, for example, coryphée. Any idea what has happened? — SGconlaw (talk) 17:02, 14 September 2019 (UTC)

@Sgconlaw I don't see this under Chrome on Mac OS 10.9. Benwing2 (talk) 17:05, 14 September 2019 (UTC)

My fault. Fixed with this edit. (See this discussion for what I was trying to do.) — Eru·tuon 17:06, 14 September 2019 (UTC)

I had the same problem. I'm glad it's fixed. DonnanZ (talk) 17:11, 14 September 2019 (UTC)

Thanks! I was about to mention that I am using Firefox 69.0. The problem was also reported by @FixingThePage at "Wiktionary:Feedback", and he provided the screenshot on the right. I was also experiencing this issue of the "show" button in translation tables being replaced by "". — SGconlaw (talk) 17:12, 14 September 2019 (UTC)

Hmm, next time I'd better check for syntax errors in the gadgets definition first. I was caught up in the idea that there was something in the JavaScript that prevented collapsibility from working on the mobile site so it took me far too long to fix this. — Eru·tuon 17:28, 14 September 2019 (UTC)

Actually, that one is a separate issue- you'll notice that it was posted before Erutuon did anything. If you go to Appendix:Polish pronouns you'll see that the problem is still unresolved.

This is something that came up once before: using certain characters in a header causes all collapsible elements within the section to have the same problem as caused by Erutuon's edit. Before it was (IIRC) an equal sign ("="), but in this case it seems to be both a colon (":") and accented letters (with "Singular subject: mój", "Singular subject- mój", "Singular subject- mój" and "Singular subject: moj" it fails, but with "Singular subject- moj" it works). I was still tinkering with the variations in preview when everything started failing due to Erutuon's edit. @Erutuon, is there any way to change the gadget so it can handle any of these variations in the header? I'm not sure whether it's a problem with the HTML generated by the system, a problem of the gadget making incorrect assumptions about what kind of HTML context it should be in, or some interaction between the two. Chuck Entz (talk) 18:25, 14 September 2019 (UTC)

Also, I believe the problem isn't a matter of the "show" button in translation tables being replaced by "", but the "" in translation tables not being replaced by the "show" button, though that's a minor and irrelevant technicality. Chuck Entz (talk) 18:35, 14 September 2019 (UTC)

Yep, that's right. I've known about this problem in general terms for a while, but have just figured out the details. The NavFrame code in MediaWiki:Gadget-defaultVisibilityToggles.js uses the header as the name of a toggle category (returned by getToggleCategory) and supplies it to MediaWiki:Gadget-VisibilityToggles.js. There, ToggleCategory.prototype.newSidebarToggle tries to use it (this.name) as part of a CSS id selector in jQuery. But ids must be valid CSS identifiers (reference), and CSS identifiers can only contain certain characters: in the ASCII range, a-z, A-Z, 0-9, hyphen, underscore (reference).

So I'm thinking the header should be rejected as a toggle category when it's not convertible to a valid CSS identifier. Because this is English Wiktionary and toggle categories are usually English, it can probably be restricted to an CSS identifier containing characters in the ASCII range. If necessary, the qualifications can be extended later. — Eru·tuon 19:48, 14 September 2019 (UTC)

Funny, the problem with the translation table at coryphée cleared up after Erutuon's fix. — SGconlaw (talk) 19:53, 14 September 2019 (UTC)

Maybe I wasn't clear: "that one" referred to the problem reported at Feedback, which is separate from the one that prompted you to make your initial report. Your problem was cleared up, but the other one is still unresolved. The confusion is understandable, since the two coming to light at the same is a rather unusual coincidence. Chuck Entz (talk) 20:15, 14 September 2019 (UTC)

I've fixed the other problem (unresponsive buttons with on them) too though. — Eru·tuon 20:25, 14 September 2019 (UTC)

Thank you! It's not good to have such a subtle and indirect bug out there. I had to spend a lot of time commenting different things out and fiddling with headers in preview to figure it out the first time, and the second time it still took me a while to figure out the limits of the problem, even with what I remembered from the first time. Chuck Entz (talk) 21:21, 14 September 2019 (UTC)

Can someone please add w:Martial? I tried to but got stuck. He's among the best-known Latin poets and he is often quoted on Wiktionary. —Biolongvistul (talk) 12:29, 15 September 2019 (UTC)

@Biolongvistul: I have added the Wikipedia link and years active to the module, but none of his works (I am ignorant of them personally). —Aryaman^{A (मुझसे बात करें • योगदान)} 20:15, 15 September 2019 (UTC)

On the desktop we automatically show the English section if none is specified. I would like the same behavior on mobile. Does anyone know how to code this easily?--So9q (talk) 06:04, 16 September 2019 (UTC)

Currently this is not enabled according to my tests. I think we should enable it. WDYT?--So9q (talk) 06:38, 16 September 2019 (UTC)

On my tablet (Samsung Galaxy with ten-inch screen) I do get redirected to the mobile version (en.m.wiktionary.org) by default. Sometimes I find it somewhat annoying when websites default to a cut-down mobile view on a device that seems to have a screen big enough to accommodate the full view. Having said that, I don't know that there is a great deal missing from the Wiktionary mobile view. I don't know whether the server can always reliably determine the device or screen size. Mihia (talk) 17:02, 19 September 2019 (UTC)

Oh, great. Then it probably is enabled by default and I just got unlucky/had an old browser/tablet.--So9q (talk) 19:01, 19 September 2019 (UTC)

The mobile frontend is coded to hide all sections/all but the first one by default AFAICS. There is an expand all setting in the settings. On WP mobile frontend only the top section is expanded, others are collapsed. I think we should fix this on our site to only expand English by default or the language appearing in the URL (#language) if any. Any ideas how to archieve this?--So9q (talk) 06:47, 16 September 2019 (UTC)

Hi, does anyone know if it is supposed to work? Here it does not. I would like to help make it working, but dunno where to start.--So9q (talk) 15:40, 16 September 2019 (UTC)

There's no acceleration because {{sv-noun-irreg-n}} in that entry uses {{sv-decl-noun}}, which doesn't have any acceleration stuff in it. — Eru·tuon 18:06, 16 September 2019 (UTC)

Thanks, I just asked Gamren if he would to look into it like he did for Danish.--So9q (talk) 20:58, 16 September 2019 (UTC)

Hi, I'm about to create a bot.

I found Tbot and User:Tbot/code/createflw that creates foreign language entries today after having looked into why norwegian has twice the number of lemmas (~12000) as danish in here.

Is anyone familiar with this code? The author is dead what I understood so I thought to ask here.--So9q (talk) 08:33, 19 September 2019 (UTC)

See WT:BOTS. You should also not use code that is completely outdated, as RU's is. —Μετάknowledge^{discuss/deeds} 15:15, 19 September 2019 (UTC)

Yes, I would also prefer something more recent. Do you know any that can roughly do what this does?--So9q (talk) 18:59, 19 September 2019 (UTC)

I hope you noticed that permission is needed to operate a bot, generally I am wary of them as they can damage entries. If you want Danish to catch up on Norwegian, Danish editors will need to be more diligent. I have done Danish entries in the past, but I don't like the systems used and have stopped. DonnanZ (talk) 18:15, 19 September 2019 (UTC)

Yes, I am aware. What systems do you mean? Templates?--So9q (talk) 18:59, 19 September 2019 (UTC)

Yes, templates. In many noun and verb entries a two tier system is used, e.g. Danish bil and Danish ringe. I'm not in favour of hidden tables for inflections, but if Danish editors insist on including genitive forms of nouns I guess they are needed - fortunately they aren't recorded in Norwegian and I don't see any need for them. It is impossible to tell whether inflections have entries without clicking on them, unentered inflections don't show as red links. A lot of adjectives were changed for the worse by User:Rua, e.g. Danish økonomisk (økonomiske has no entry), fortunately Danish automatisk was left untouched - this one looks much better, but no entry done for automatiske. In fact there are many missing inflection entries which may or may not be the same in Norwegian. DonnanZ (talk) 20:47, 19 September 2019 (UTC)

The noun heading at many reads:

many (plural manies)

I wish to make it read:

many (plural (rare) manies)

Is there any way to do this within the "en-noun" template? Mihia (talk) 16:39, 19 September 2019 (UTC)

Much to my surprise: {{en-noun|(rare) manies}} gives you what you are asking for, except that rare is bold. DCDuring (talk) 20:16, 19 September 2019 (UTC)

Aha, thank you. When I was looking at a similar case of labelling the inflection "developt" within the "en-verb" template of "develop", I discovered there was a parameter "past2_qual" that did the trick. I wonder whether someone who understands templates and has the time and inclination might be able implement something similar at "en-noun" in order to enable qualification of plurals in a more obviously supported way, and also prevent the text from being displayed in bold. Mihia (talk) 22:16, 19 September 2019 (UTC)

That would be better than the kluge. DCDuring (talk) 02:38, 20 September 2019 (UTC)

Agree that that would be a welcome addition to {{en-noun}}. In the meantime, what I have done before is to put the rare plural last and to add {{qualifier|rare}} after {{en-noun}}. — SGconlaw (talk) 03:23, 20 September 2019 (UTC)

But that would make it seem that it is the noun PoS lemma that is rare rather than just the plural form. DCDuring (talk) 14:25, 20 September 2019 (UTC)

Yes, that’s not an ideal solution by any means. — SGconlaw (talk) 15:07, 20 September 2019 (UTC)

I'd like to request the addition of a family code for the Mixtec languages (as a branch of Mixtecan) and a corresponding Proto-Mixtec language code. --Lvovmauro (talk) 07:16, 20 September 2019 (UTC)

Hi, I just wrote a new script to edit translation lines in place. Unfortunately Editor.js gives me the following error when I run the script in my sandbox:

jQuery.Deferred exception: Cannot read property 'appendChild' of undefined TypeError: Cannot read property 'appendChild' of undefined
    at new window.AdderWrapper (<anonymous>:34:129)
    at Array.<anonymous> (https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=User:So9q/EditTranslations.js&action=raw&ctype=text/javascript:61:4)
    at <anonymous>:26:626
    at mightThrow (https://en.wiktionary.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%…7Coojs-ui.styles.icons-editing-advanced&skin=monobook&version=1ccwo:48:916)
    at process (https://en.wiktionary.org/w/load.php?lang=en&modules=jquery%2Coojs-ui-core%…7Coojs-ui.styles.icons-editing-advanced&skin=monobook&version=1ccwo:49:589) undefined

I would be very grateful if somebody with knowledge of Editor.js could take a look.--So9q (talk) 10:50, 20 September 2019 (UTC)

@Mahagaja, Hintha, Wyang, Octahedron80: Hi. We're missing the initial ဿ (ssa.), causing a Lua error at သောမနဿ (sau:ma.na.ssa.) in Module:my-pron. Ref: Wiktionary:Burmese transliteration. --Anatoli T. ^{(обсудить}/^вклад) 11:27, 20 September 2019 (UTC)

@Atitarev: I've added a paragraph at Wiktionary:Burmese transliteration#ဿ, but I'm not good enough at module editing to fix Module:my-pron. —Mahāgaja · talk 11:45, 20 September 2019 (UTC)

@Mahagaja: Thanks. I tried adding this line: = { "ʔθ", "ss", "ss", "tth", "ʔth" } but it won't work with preceding vowels (my edit summary "Won" was accidental). --Anatoli T. ^{(обсудить}/^вклад) 12:05, 20 September 2019 (UTC)

@Atitarev: There was already a line that said: = { nil, "ss", "ss", nil, nil }, so maybe the problem was that there were two competing lines for ဿ? —Mahāgaja · talk 12:22, 20 September 2019 (UTC)

@Mahagaja: I'm not good with module editing either. Perhaps the exact rules should be defined - all translits + preceding vowels, so that someone with Lua knowledge could fix it, without any knowledge of the Burmese script. --Anatoli T. ^{(обсудить}/^вклад) 12:33, 20 September 2019 (UTC)

@Atitarev, Mahagaja: I fixed the edit: just have to replace the previous definition of ဿ. Is the transcription correct now? — Eru·tuon 20:41, 20 September 2019 (UTC)

@Erutuon, Mahagaja: Thanks but no. It doesn't produce the right tone for the preceding syllable. In Wiktionary:Burmese_transliteration#Syllable_rhymes, it should give the same result as the rhyme ကတ် (kat) (က (ka.) + တ (ta.) + ်): /-aʔ/ -at, -at‘, -at, -aʔ, as in the this revision by Mahāgaja. Symbol ဿ (ssa.) imitates Pali's geminate "-ss" where the first "s" belongs to the previous syllable is pronounced as a glottal stop /ʔ/ in Burmese, the second "s" is pronounced "θ" in Burmese. In Module:my-pron, please look at the final_table, the first "s" should work as the final = { "aʔ", "at", "at‘", "at", "aʔ" }, and the 2nd "s" works as a normal initial သ (sa.) (pronounced /θ/ + vowel). The problem with your edit is that the preceding inherent vowel becomes a creaky tone followed by a glottal stop /na̰ʔ/ (it doesn't happen) but should be a checked tone /naʔ/. Basically, this symbol is special and should work across two syllables. --Anatoli T. ^{(обсудить}/^вклад) 07:14, 21 September 2019 (UTC)

@Atitarev, Mahagaja: Thanks, that explanation helps. Are there any other letters that behave this way (containing a syllable coda consonant as well as an onset consonant)? I wonder if it would work for the module to internally respell ဿ as a combination with an equivalent pronunciation (I guess တ်သ?), before generating the IPA. (It looks like this respelling cannot happen before the transliterations or transcriptions are generated.) — Eru·tuon 17:19, 22 September 2019 (UTC)

Implemented respelling here and it at least makes the testcase come out right. — Eru·tuon 17:55, 22 September 2019 (UTC)

@Erutuon: I think this is the only single letter that behaves this way. All the other cross-syllable consonant clusters would be written with two letters (like သ်သ or သ္သ) and I assume the module can already accommodate those. (The letter ည originated as a double ဉ, but it doesn't behave as two consonants in contemporary Burmese.) —Mahāgaja · talk 17:57, 22 September 2019 (UTC)

Hi, Erutuon helped me create this 7000 lemma list of lemmas that have no,nb or da translations but missing a Swedish.

Some of the lemmas have an article in the sv.wiktionary where there is a translation also. E.g. abash, sv:abash. In this case there is only one # in the Swedish article and only one of the 2 translation sections in abash have nb,no and da translation.

I'm imagining that this could be semi- (when there are more than 2 #'s in the swedish article or multiple translation sections in the english one with nb,no and da) or fully automated (in cases like the above) by a bot script.

Afterwards I would of course patrol the edits to see that it makes sense. Does this sound reasonable? Would someone like to help me write such a script?--So9q (talk) 13:07, 21 September 2019 (UTC)

Please see here, if you are interested: . Equinox ◑ 22:12, 25 September 2019 (UTC)

Is there something like titleapp= in German inflection templates? I'd like to add gender labels to the decl tables in Weisel#German. Thanks in advance, --Akletos (talk) 10:35, 28 September 2019 (UTC)

Done. —Rua (mew) 11:29, 28 September 2019 (UTC)

I'm surprised that it's that simple. Thanks a lot. --Akletos (talk) 12:53, 28 September 2019 (UTC)

Hi, yesterday I tried hard porting the TranslationAdder to jquery. I found out that the Editor.js is not accepting JS objects. I accepts text like this:

return error("Please choose a foreign language. (fr, es, aaa)");

and newNodes like this:

return error(newNode('span',
							"Translations normally don't have capital letters. If you're certain it does, you can ",
							newNode('span', {
								style: "color: blue; text-decoration: underline; cursor: pointer;",
								click: function () {
									forceCase = true;
									inputForm.onsubmit();
									prefs.set('case-knowledge', 'guru');
								}
							}, "continue by clicking here.")));

But currently it does not support JS html objects:

						return error(
                            $('<span>').text(
							"Translations normally don't have capital letters. If you're certain it does, you can ")
							.append($('<a>')
									.text("continue by clicking here.")
									.click(function () {
											forceCase = true;
											inputForm.onsubmit();
											prefs.set('case-knowledge', 'guru');})));

The relevant function that handles this is this function inside a for loop:

function(msg) {
						status.appendChild(
							$('<span>').css("color", "red")
							.append($('<img>').attr('src', 'http://upload.wikimedia.org/wikipedia/commons/4/4e/MW-Icon-AlertMark.png'))
							.append(msg)
							.append($('<br>')));
						adder.elements.style.border = "solid #CC0000 2px";
						return false
					}

Does anyone know how to improve this situation?--So9q (talk) 07:38, 29 September 2019 (UTC)

I started a discussion in the Tea Room about this, I wonder if there are any solutions available. DonnanZ (talk) 10:33, 30 September 2019 (UTC)

A new infinite/impersonal category of inflection needs to be added to the template. The designation is gerund and it can be placed right below the existing converb. It is formed by

• addition of -aq to 3rd person indefinite future for verbs with back vowels with a stem-final consonant
• addition of -yaq to 3rd person indefinite future for verbs with back vowels with a stem-final vowel
• addition of -ək to 3rd person indefinite future for verbs with front vowels with a stem-final consonant
• addition of -yək to 3rd person indefinite future for verbs with front vowels with a stem-final vowels

Examples:

• Positive: olmaq → olaraq; negative: olmamaq -> olmayaraq;
• Positive: oxumaq → oxuyaraq; negative: oxumamaq -> oxumayaraq;
• Positive: gəlmək → gələrək; negative: gəlməmək -> gəlməyərək;
• Positive: yerimək → yeriyərək; negative: yeriməmək -> yeriməyərək

Allahverdi Verdizade (talk) 11:43, 30 September 2019 (UTC)

Recently bots have changed lang=en to simply the language code in the first parameter on a number of templates. For some instances of {{seemoreCites}} – presumably those that did not have the lexeme as a parameter – that means that the template now links to Citations:en#English instead of e.g. Citations:haemony#English or Citations:het#English. Cnilep (talk) 01:37, 1 October 2019 (UTC)

@Cnilep Thanks for noticing this, it should be fixed now. Benwing2 (talk) 15:47, 1 October 2019 (UTC)