Wiktionary

Wiktionary:Grease pit/2016/May

< Wiktionary:Grease pit

Disabling MediaWiki keyboard shortcuts edit

How does one disable the MediaWiki-specific keyboard shortcuts?

I'm not sure if something has changed in the past couple months, or if my typing has gotten worse, but I have found myself running afoul of MediaWiki-specific keyboard shortcuts, which have caused me to lose considerable work. I will be editing a page and typing something, and mid-typing, I've apparently accidentally hit a key combo that is specially mapped just for MediaWiki, and up pops the "Confirm Navigation: Are you sure you want to leave this page?" dialog -- only since I'm mid-word, the next letter I type is accepted as OK, and unless I've hit Preview at some point, all of my work is suddenly lost. I touch-type at a decent clip so that I might not even see more than a flicker in the UI before suddenly my browser is showing a different page altogether. Going back in the browser doesn't work.

These shortcuts are apparently defined here. Alt-N, for instance, is apparently a keyboard shortcut to go to my own Talk page. How is this remotely useful? This only works on MediaWiki sites like Wiktionary or Wikipedia. I have *never* used these, and I didn't even know they existed until I started running into this usability bug. I have no interest in *ever* using them. I want them to go away completely.

Where do I give feedback on the usability issues presented by these poorly discoverable keyboard shortcuts?

How can I disable these? ‑‑ Eiríkr Útlendi │Tala við mig 23:13, 4 May 2016 (UTC)[reply]

This is really a browser issue. Which one are you using? Equinox ◑ 23:14, 4 May 2016 (UTC)[reply]
Add $( function () {$( "[accesskey]" ).removeAttr( "accesskey" );}); to your common.js. --Yair rand (talk) 23:16, 4 May 2016 (UTC)[reply]
  • @Equinox, I'm using Chrome primarily. However, these are shortcuts specific to MediaWiki sites: they don't do anything when I'm browsing the web in general. Alt+X on Wiktionary or Wikipedia takes you to a random entry. Alt+R takes you to Special:RecentChanges. These work in Chrome, but it seems they do nothing in Firefox or IE 11.
  • I agree that accelerators should be supported. I object, quite strongly, to how this has been implemented in MediaWiki, at least with regard to Chrome. When I hold Alt and press F, I expect to see the File menu, and indeed this works as expected in Chrome. I do not expect such an accelerator combo to suddenly whisk me away to another page entirely -- especially when these combinations are not discoverable, are not advertised anywhere, and only work here. ‑‑ Eiríkr Útlendi │Tala við mig 23:41, 4 May 2016 (UTC)[reply]
  • Re "only work here": sites can define their own keys; that's the whole point. Not every site has the same features. Re conflicts with built-in browser commands: yes, that sucks; Chrome won't let you change this, though Opera used to. Equinox ◑ 00:03, 5 May 2016 (UTC)[reply]
  • I wouldn't mind so much if the accelerators were not effectively destructive -- I've lost data due to the current implementation. Accelerator keys in regular apps first open a menu, and then you hit the second combo to execute the relevant command in that menu -- the user has visibility into what is happening. For MediaWiki, I'd vastly prefer if the first keypress just activated the relevant command / link, rather than immediately executing it. For example, Alt+X should activate the Random entry menu item on the left-hand menu; the user would then press Enter to actually go to that link. Similarly, Alt+N should activate the user's own Talk link at the top, and Enter would go to the link. But with no visibility into what's going on, and no clear advertising about the shortcuts, MediaWiki's behavior becomes mysterious and frustrating. ‑‑ Eiríkr Útlendi │Tala við mig 00:18, 5 May 2016 (UTC)[reply]
  • I agree. GUIs in general have gone down the toilet lately (probably because of pandering to mobile devices): look at the near-total removal of pull-down menus from Windows 10. However, I do use Chrome, and in most cases I find that if you go Back to a previous page with a textbox, it remembers which text was in there. Personally I use the Wiktionary shortcut keys a lot, even the ones for talk pages and stuff. (My only big Chrome issue is Ctrl+W closing the entire browser; this key was designed to close a single window in multiple-document interfaces in the early days of Windows, and nobody does MDI any more, so I have no idea why Google implemented it. Easy to hit when you mean Ctrl+A to select all.) As I say, Opera did let you customise all keystrokes, which was amazing, but Opera also committed suicide a few years back and has reduced itself to a worthless featureless browser, hence my switch to Chrome. Equinox ◑ 00:22, 5 May 2016 (UTC)[reply]
  • Never used Opera. I'm curious about your Ctrl+W experience; for me, it just closes the currently active tab. I've also defaulted to using Ctrl+F4 to close tabs, in part because Alt+F4 reliably closes apps in Windows, whereas Ctrl+Q doesn't (it closes some, but not others).
I'm not sure what the particular key combo is, but something in MediaWiki causes a reload of the current page, in edit mode, but with the edit box reverted to the last edit -- basically reloading the page, where hitting Back just gets you to the page in reading mode. Very frustrating.
After testing, I think it might have been Alt+O, defined as Login -- if you're already logged in, it just reloads the page you're on, wiping anything in the edit window buffer in the process. I'm guessing that Alt+E Edit might do the same thing. ‑‑ Eiríkr Útlendi │Tala við mig 00:39, 5 May 2016 (UTC)[reply]
(Continuing on your talk page since I've taken this a bit off topic.) Equinox ◑ 01:00, 5 May 2016 (UTC)[reply]

asseoir edit

@kc_kennylau A bit confusing. I had to fix the past participle myself, and I don't know where the "assis" conjugations for the present tense came from, any sources/attestation for them? Hillcrest98 (talk) 23:39, 5 May 2016 (UTC)[reply]

@Hillcrest98: Fixed. I copied those from the deleted template Template:fr-conj-asseoir, in which those erroneous forms were added by Wonderfool's account User:Rising Sun. --kc_kennylau (talk) 12:13, 6 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:37, 19 January 2018 (UTC)[reply]

Bug with translations boxes edit

Hello,

I often find that, when I load a page, translations boxes are automatically closed, but no link appears to open them (even if I click on the heading, the box doesn't open). Sometimes the "show" link appears, sometimes it doesn't.

My Javascript is always enabled of course, and I use Windows 7/FF latest version (46.0.1): I guess that I'm not the only one to encounter this bug, and that the average visitor doesn't know he should reload the page to make the translations appear (he could think there isn't any translation in the page).

Does anyone have any idea how to fix this bug? — Automatik (talk) 14:22, 6 May 2016 (UTC)[reply]

When this happens to me, refreshing the page usually fixes the problem (sometimes a cache-bypassing refresh is necessary). --WikiTiki89 15:20, 6 May 2016 (UTC)[reply]
The average visitor doesn't have necessarily this reflex: maybe it could be considered not to close by default translations boxes. — Automatik (talk) 11:08, 8 May 2016 (UTC)[reply]
Does it really occur to you "often"? Glad I met you! Could you please open the console (by pressing F12) and make a screenshot of the console error next time it happens to you?--Dixtosa (talk) 12:31, 8 May 2016 (UTC)[reply]
Dixtosa: there isn't any console error when it happens, but it just happened to me right now on botany (that said, if I reload the page, it doesn't happen again). Recently, it happened from time to time, not often. But on the French Wiktionary where we do not close by default translation boxes, it never happens. — Automatik (talk) 12:17, 18 May 2016 (UTC)[reply]

Right now again, I was unable nor to see nor to edit translations in the scholasticism entry. It's really disturbing, and giving the poor quantity of Javascript gadgets I enabled, I'm probably not the only one to encounter this issue. — Automatik (talk) 02:15, 19 June 2016 (UTC)[reply]

Entries not automatically leaving category (Cat:Gothic romanizations without a main entry) edit

Lately I've been adding a lot of Gothic terms, both lemmata and non-lemma forms, but the number of pages in Category:Gothic romanizations without a main entry does not appear to be going down, it's stuck at 7,499. How can I see the real number/when does this update? Kleio (t · c) 17:19, 6 May 2016 (UTC)[reply]

You might have to make a null edit to the page with the romanization on it to refresh the category. —Aɴɢʀ (talk) 17:34, 6 May 2016 (UTC)[reply]
Lordy. That's a lot of pages to refresh. Will it not sort itself out in time/are there no shortcuts? Kleio (t · c) 17:40, 6 May 2016 (UTC)[reply]
You don't have to refresh all the pages in the category, just the ones that should be disappearing from the category, i.e. the ones you've created Gothic-script entries for. —Aɴɢʀ (talk) 17:42, 6 May 2016 (UTC)[reply]
It should sort itself out over time. --WikiTiki89 17:51, 6 May 2016 (UTC)[reply]
FWIW, the category now has 7487 entries when I look. —Aɴɢʀ (talk) 17:55, 6 May 2016 (UTC)[reply]
I've been fixing it for some of my contributions, I'm an impatient person Kleio (t · c) 18:04, 6 May 2016 (UTC)[reply]

translation-entry error for Classical Hebrew (ISO 639-3 HBO) edit

I get the following error message when attempting to add translations for Classical Hebrew (ISO 639-3 HBO): "Lua error in Module:languages/templates at line 28: The language code 'hbo' is not valid.: Lua error in Module:parameters at line 110: The parameter "<strong class" is not used by this template." NicoleSharpRFS (talk) 21:22, 7 May 2016 (UTC)[reply]

@NicoleSharpRFS Wiktionary:About_Hebrew#Dialects_and_languages DTLHS (talk) 21:31, 7 May 2016 (UTC)[reply]
@DTLHS Thanks for the info; I did not know that Wiktionary did not differentiate entries in Modern versus Classical Hebrew. Perhaps the translation box can have the error message changed to inform users of that when attempting to enter HBO translations? NicoleSharpRFS (talk) 21:51, 7 May 2016 (UTC)[reply]
One thing we can do is have check whether the language code exists as an etymology-only code and produce a more descriptive error message based on that (such as "The language code 'hbo' is an etymology-only code"). @CodeCat: What do you think? --WikiTiki89 14:42, 9 May 2016 (UTC)[reply]
That could be done, but the difficulty is that the error message isn't actually generated by the language module but by each individual module that uses it. The getByCode function just returns nil if the language isn't found. So a lot of modules would have to be changed. Also consider that for templates like {{etyl}}, the code tries different modules in turn when looking up a code; if one of them returns nil, then it tries the next, and only when none of them return anything is an error triggered. So we can't really change the nil-return behaviour. —CodeCat 16:15, 9 May 2016 (UTC)[reply]

Formatting error in Module:io-conj edit

There is a formatting error in a new module that I made with the name Module:io-conj which causes some pages to show incorrectly. Could somebody help me fix this formatting problem? I looked at the HTML and Lua code for quite some time and I don't see what I did wrong. Here is an example. Robin van der Vliet (talk) (contribs) 22:38, 7 May 2016 (UTC)[reply]

I saw "amote|}" in the final cell, a sign that the table wasn't being closed properly. I added an extra newline to the code and it seems to be okay now. —suzukaze (t・c) 22:42, 7 May 2016 (UTC)[reply]
Thank you, it looks like it works perfectly now! Robin van der Vliet (talk) (contribs) 15:12, 8 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:37, 19 January 2018 (UTC)[reply]

Category:Horse racing and Category:Horses edit

Could somebody make Category:Horse racing (and its language-based subcategories) a subcategory of Category:Horses (and its language-based subcategories)? Thanks! Purplebackpack89 23:04, 7 May 2016 (UTC)[reply]

Horses is a category for terms for horses. Terms found in horse racing aren't a subset of that. —CodeCat 23:14, 7 May 2016 (UTC)[reply]

My Wiktionary programs don't work any more edit

Example: User:Equinox/Antiblue. Using the DotNetWikiBot library. The error is: "Login failed. Check your username and password." Is this to do with the switch from HTTP to HTTPS, possibly? Any ideas on how to fix it? (Just changing the login URL to use HTTPS doesn't help. P.S. It really annoys me that nobody cares a crap about backward-compatibility any more. It used to be considered a big deal.) Equinox ◑ 14:02, 8 May 2016 (UTC)[reply]

Which version of the library are you using? 3.15 targets MW 1.27 but we are still on 1.26.x so this might be it.--Dixtosa (talk) 15:58, 8 May 2016 (UTC)[reply]
Just upgraded from 3.10 to 3.15. Now it logs in but says an XML "root element is missing". Hmm. Never seen that before. Equinox ◑ 17:53, 8 May 2016 (UTC)[reply]
Aha. Using the new version and using an HTTPS URL fixed it. Equinox ◑ 17:55, 8 May 2016 (UTC)[reply]

Subtle etymtree problems edit

I just ran into a module error at stella caused by the changing of {{l|la|stella}} to {{l|la|stēlla}} in {{etymtree/la/stella}}. This made it so the module was no longer able to find a match for "stella" (without the macron) in the tree. Changing the branch term to stēlla (with the macron) didn't work, either, because it's not a valid Latin entry name. The solution I finally arrived at was to change {{l|la|stēlla}} to {{l|la|stella|stēlla}} in {{etymtree/la/stella}}.

The problem with the way etymtree is currently set up is that perfectly innocent edits in one place can cause module errors somewhere else that the performer of those edits doesn't see- and may even may be completely unaware of.

That may not be so easy to deal with in the short term, so can we at least make it so the module compares the branch term to the the spellings actually linked to by the tree's terms (i.e., after the diacritics have been stripped, etc.)? Or, if that introduces too much overhead/complexity, at least add an explanation to the documentation so people either won't cause the problems in the first place, or so that people encountering the module errors know what to look for? Thanks! Chuck Entz (talk) 05:15, 9 May 2016 (UTC)[reply]

I've been working on a new template called {{desctree}} that replaces {{etymtree}} altogether, so it may be a solution in the long term. The new template doesn't use a centralised page for the entire descendants tree, but it re-uses the descendant list already present in the entry. Simply said, it allows you to transclude one entry's descendants as part of another entry's descendants, reducing duplication. The template isn't entirely mature yet, there are some things that need to be changed before it can be used generally. —CodeCat 16:19, 9 May 2016 (UTC)[reply]

Help with etymtree template edit

I'm new to this; I took a stab at doing an etymtree template for Latin canto (https://en.wiktionary.org/wiki/Template:etymtree/la/canto), using that of stella (https://en.wiktionary.org/wiki/Template:etymtree/la/stella). But when I insert it the same way under "Descendants" on the canto page, I get the error message "Lua error in Module:etymtree at line 84: Branch not found." If I change the 'o' at the end to a macron 'ō', I get a different error message: "Lua error in Module:etymtree at line 21: Invalid root". I'm not sure what I'm doing wrong here. The pages look identical as far as I can tell; am I missing something? Word dewd544 (talk) 00:27, 10 May 2016 (UTC)[reply]

Wow, never mind; I just realized the thread above pretty much answered my question. Word dewd544 (talk) 00:30, 10 May 2016 (UTC)[reply]
Yep. The fact that I was working with stella at all was due to a module error caused by your edits, and I started the thread above precisely because it struck me as for too easy to make the error you made (if one can really call it an error) and far too hard to figure out what went wrong afterwards. I'm glad the time I spent racking my brains to figure out why suddenly 2+2≠4 was of benefit to someone... Chuck Entz (talk) 01:41, 10 May 2016 (UTC)[reply]

Torlakian Serbo-Croatian edit

Could someone add the following for w:Torlakian to Module:labels/data/regional? 

labels["Torlakian"] = {
	display = "[[Torlakian]]",
	plain_categories = {"Torlakian Serbo-Croatian"},
}

We already have the other three major divisions (Chakavian, Kajkavian, Shtokavian), and Torlak seems to have been left out by happenstance. Thanks, Vorziblix (talk) 05:14, 10 May 2016 (UTC)[reply]

Done, except I made the display link to the Wikipedia article instead of our rather uninformative entry. —Aɴɢʀ (talk) 10:03, 10 May 2016 (UTC)[reply]
Thanks! Vorziblix (talk) 11:50, 10 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:38, 19 January 2018 (UTC)[reply]

1 alert, 8 messages, yet "You have no notifications." edit

Hi there! I seem to have both the notice indicators lit, red and blue at the top of the page but when I click those I'm told I have no messages. I wonder what's up. Weird. Palosirkka (talk) 12:07, 13 May 2016 (UTC)[reply]

Maybe they’re notifications and messages from other wikis. This feature was introduced recently. — Ungoliant (falai) 14:38, 13 May 2016 (UTC)[reply]
I noticed this too the other day. I got welcome messages from the Vietnamese and Bavarian Wikipedias from 8 months ago (I've never been to either wiki). KarikaSlayer (talk) 14:42, 13 May 2016 (UTC)[reply]
I was just notified that edits of mine to various obscure Wikipedias were reverted—three years ago. —Aɴɢʀ (talk) 14:44, 13 May 2016 (UTC)[reply]
Thanks guys! So we wait and see. They say nothing is contant except change... :) Palosirkka (talk) 17:16, 13 May 2016 (UTC)[reply]
I got some of the same kinds of message notifications today. DCDuring TALK 17:32, 13 May 2016 (UTC)[reply]
I blame annoying welcome bots. -Xbony2 (talk) 22:31, 13 May 2016 (UTC)[reply]
I had a welcome message from the Arabic site, and I've never ever been there. Needless to say it was all Greek to me... Donnanz (talk) 12:26, 18 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:38, 19 January 2018 (UTC)[reply]

Need help with Gothic declension templates edit

There's a problem with Gothic declension templates which list two options for a certain form, separated by a comma: the link in the template will then be to both options with the comma between them, instead of two separate links for the individual option.

You can see an example of this happening here, at 𐍅𐌰𐌿𐍂𐌸𐌰𐌽𐍃 (waurþans). As you see, the neut. nom. and acc. sg. strong forms have two possible options suggested by the template, which in the Gothic script are linked separately as they should, but in romanization they are treated as a single link to waurþan, waurþanata instead of two links to waurþan and waurþanata separately.

This happens in a bunch of Gothic inflection table templates which list two possible forms together and has the unfortunate consequence of making it difficult to see if a given form is attested or not, as all attested forms have been imported in romanization. If someone could fix this for the affected templates I should be very grateful, I myself am pretty much code illiterate unfortunately. — Kleio (t · c) 02:01, 14 May 2016 (UTC)[reply]

What's really needed is additional parameters to specify the second form. I don't have the time to do it now, but I'll look tomorrow. —CodeCat 02:08, 14 May 2016 (UTC)[reply]
I think the culprit might be {{xlit}} stripping the links out of the transliteration. KarikaSlayer (talk) 02:41, 14 May 2016 (UTC)[reply]
Doing this solves the problem, but ideally that shouldn't be necessary. —Aɴɢʀ (talk) 08:20, 14 May 2016 (UTC)[reply]

Edit request: Template:was wotd edit

The template does not work well with {{wikipedia}}. Adding this style padding: 4px; to the wrapper div helps. --Dixtosa (talk) 16:02, 15 May 2016 (UTC)[reply]

Where and how do you put padding: 4px;? Donnanz (talk) 12:29, 18 May 2016 (UTC)[reply]
Donnaz, replace the whole content with the one from here--Giorgi Eufshi (talk) 11:26, 19 May 2016 (UTC)[reply]
I'm not sure whether I can make head or tail of that, but thanks anyway. Donnanz (talk) 22:45, 19 May 2016 (UTC)[reply]

'term' appears as a placeholder edit

In Template:etymtree/sem-pro/maʾ-, {{l|lsd|tr=ṃāye}} results in term (ṃāye). 'Term' seems like a poor placeholder because it's a word, and it shouldn't be linked in any case. Better might be [...] which IIRC was what it previously displayed. - -sche (discuss) 23:29, 16 May 2016 (UTC)[reply]

It's because you're viewing a template page. Module:links displays "term" as a placeholder on template pages. —CodeCat 23:54, 16 May 2016 (UTC)[reply]
There are two problems: 1. This list probably shouldn't be in the template namespace. 2. Module:links/templates currently assumes that its uses in the template namespace are on the pages of the term templates themselves. Both of these problems should be fixed. --WikiTiki89 13:49, 17 May 2016 (UTC)[reply]
I fixed the second issue. I still think the first one should also be addressed. --WikiTiki89 13:58, 17 May 2016 (UTC)[reply]
Thanks for the explanation, CodeCat, and for fixing the second issue, Wikitiki. - -sche (discuss) 17:01, 17 May 2016 (UTC)[reply]

Module:vo-conj weirdness edit

There are currently 7 Volapük entries at CAT:E due to "not enough memory" errors in their conjugation tables. At first I thought this was due to the sheer size of the conjugation table combined with the tendency for Volapük to be stuffed full of "Related terms" and "See also" items by the obsessively over-thorough editor Hans-Friedrich Tamke.

Then I looked at zütävön, which has very little more than the bare bones, content-wise, yet overruns the memory limit. When I edit and preview the Conjugations section, the stats at the bottom say it uses 14.84 MB/50 MB. When I do the same for the Verb section, which includes the Conjugations section, it says 43.68 MB/50 MB.

Now, here's where it gets weird: if I comment out {{vo-conj}} and preview the Verb section, the number drops to 2.03 MB/50 MB. If I uncomment {{vo-conj}} and comment out the headword and definition lines, the number is 14.84 MB/50 MB.

It looks like the regular modules and vo-conj are interacting somehow. I did notice that the module uses very generic variable names, so there might be a variable-name or reserved-word conflict, but that's just a wild guess, since I know very little about Lua. Could someone have a look? Thanks! Chuck Entz (talk) 03:49, 17 May 2016 (UTC)[reply]

I would guess that it's the string concatenation operations, specifically the 720 iteration loop. String concatenation in Lua is not efficient. It would be better to make a table and then concatenate the table when the loop is complete. DTLHS (talk) 04:02, 17 May 2016 (UTC)[reply]
I managed to get the page down to 3-4 MB memory usage by replacing most of the concatenation with table.insert(). KarikaSlayer (talk) 04:12, 17 May 2016 (UTC)[reply]

UPA edit

I'd like to add Uralic Phonetic Alphabet proficiency templates (similar to {{User IPA-1}} etc.) Looks like we'd need a new script entry for that, though. Can someone add the suitable script module entry? ("Finno-Ugric Transcription" should probably be an alternate script name.)

Alternately though, it looks like the {{User script-1}} (etc.) templates are also doing some kind of special handling of IPA. Perhaps adjusting them would be sufficient, since we probably don't want to actually use UPA around much. --Tropylium (talk) 22:19, 17 May 2016 (UTC)[reply]

I don't think we really need a script code for it. You can add special handling to {{User script-1}}. First, though, you would need to create a template ({{UPA}} or something) that would be used for displaying UPA text, which would also require adding a CSS class for it at MediaWiki:Common.css. --WikiTiki89 14:53, 18 May 2016 (UTC)[reply]
Do we need that either, or could we stash that inside the script templates too? Again, we probably aren't going to be regularly using UPA for anything, this would be mainly a "hi, I know how to read the sources if you need stuff converted to IPA" kind of a template. --Tropylium (talk) 19:23, 18 May 2016 (UTC)[reply]
I mean, you could probably use "Latinx" for a script code, then you won't need a separate CSS class and all you would need is a template, with essentially the code {{lang|und|sc=Latnx|{{{1}}}}}. That is, if you ever actually want to use UPA anywhere. If all you want is the Babel box, then you can hard-code {{lang|und|sc=Latnx|{{{2}}}}} into {{User script-1}}. But then again, if you never intend to use UPA anywhere, why do you need it on your userpage? --WikiTiki89 19:30, 18 May 2016 (UTC)[reply]
The main scenario I'm thinking of is that we probably want IPA pronunciation for various Uralic and neighboring languages, but sources fairly commonly only use UPA.
Though there's also a secondary issue over creating entries for unwritten Uralic languages. Currently e.g. our Ter Sami entries are entered in an inconsistent mixture of UPA (ji̮ɯ̭̄n̜ɛ), IPA (kɨkt) and even mixed IPA-UPA (vɨennče) transcription. (This particular discussion should probably continue over at WT:ASJT though.) --Tropylium (talk) 19:47, 18 May 2016 (UTC)[reply]
There is no reason not to include both IPA and UPA in the pronunciation sections. There seems to be a common misconception that all pronunciations must be in IPA. So it wouldn't hurt to create an infrastructure of templates to support UPA. --WikiTiki89 19:58, 18 May 2016 (UTC)[reply]
It's not a misconception; all pronunciations do have to be in IPA. But they don't have to be only in IPA. —Aɴɢʀ (talk) 10:02, 19 May 2016 (UTC)[reply]
@Angr: Where does it say that? --WikiTiki89 14:56, 19 May 2016 (UTC)[reply]
I'm not sure if it's actually written down anyplace, but it seems to be common consensus that pronunciation sections should contain at least the IPA, and may contain other systems (e.g. enPR for English) as well. Wiktionary:Pronunciation#Ad hoc transcription sort of implies this, and Wiktionary:Entry layout#Pronunciation says "Use an established system of pronunciation transcription, such as IPA." That said, however, it looks like Tropylium above isn't talking about Pronunciation sections, he's talking about entry names. —Aɴɢʀ (talk) 15:04, 19 May 2016 (UTC)[reply]
Both of those links clearly imply that as long as it's an unambiguous and established transcription system, it doesn't have to actually be IPA. And if you read carefully, the Tropylium said the entry name issue is "a secondary issue over creating entries for unwritten Uralic languages". However, I agree that whenever possible, it's better to also include IPA. --WikiTiki89 15:10, 19 May 2016 (UTC)[reply]
That's all well and good in principle, but UPA is neither unambiguous (as a system of phonetic transcription, it comes in varying degrees of closeness, and it also suffers from lacking some distinctions made by IPA), nor established in normal lexicographical use. I would oppose using anything except, perhaps, highly broad transcription, where it actually provides some kind of benefit over IPA (e.g. ś in cases where it is not known if this is [sʲ] or [ɕ]). For example, the pronunciation for ji̮ɯ̭̄n̜ɛ should probably be given simply as IPA(key): [jɨʉ̯nʲɛ]. --Tropylium (talk) 17:05, 19 May 2016 (UTC)[reply]

Protected edit request: Template:ja-def edit

Template talk:ja-def#Code update. —suzukaze (t・c) 06:41, 19 May 2016 (UTC)[reply]

Done. Wyang (talk) 10:04, 19 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:39, 19 January 2018 (UTC)[reply]

Unexplained removal of diacritics edit

This template creates a noun table. If I enter characters with macrons into it, the words in the table link to pages without macrons. For exampe water#Middle Low German. This is desirable behaviour for me, but why does it happen? Korn [kʰũːɘ̃n] (talk) 09:52, 19 May 2016 (UTC)[reply]

Because Module:languages/data3/g automatically strips all macrons and circumflexes from links tagged as being gml. —Aɴɢʀ (talk) 10:01, 19 May 2016 (UTC)[reply]
Well, nice to see that someone had the right idea long time ahead. I'd like to request that an addition is made so that the following glyphs are also stripped: ÄÄ̂Ǟ ää̂ǟ ÖÖ̂Ȫ öö̂ȫ ÜÜ̂Ǖ üü̂ǖ. Korn [kʰũːɘ̃n] (talk) 10:25, 19 May 2016 (UTC)[reply]
  Done —Aɴɢʀ (talk) 10:42, 19 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:39, 19 January 2018 (UTC)[reply]

something is wrong with suffix categories containing accents edit

Something recently changed that broke suffix categories containing accents in the {{suffixcat}} call. Example: Category:Russian words suffixed with -атый. There's now a big ugly warning that didn't use to be there. Benwing2 (talk) 23:03, 19 May 2016 (UTC)[reply]

@CodeCat Do you know what's going on? Benwing2 (talk) 03:20, 21 May 2016 (UTC)[reply]
I don't know why it's happening, but I removed the displaytitle override from the module, so the error should be gone. —CodeCat 13:18, 21 May 2016 (UTC)[reply]
@CodeCat BTW thanks for doing this, it seems to have solved the problems. Benwing2 (talk) 02:25, 27 May 2016 (UTC)[reply]

Norman edit

There are a lot of Norman translations that are out of alphabetic order. I assume that the original problem has been fixed (I have not tested it), but there are still many Translation sections that have the Norman out of order. Often I see where another language, such as Mongolian, was entered after the Norman, and it was placed ahead of the Norman, making it out of place as well. Other examples are: voter, catamaran, bicarbonate, first person, quart, Christ, pâté, grammatical. I just wonder if there is a way to fix these automatically, such as User:AutoFormat (which I don’t think is in use anymore). —Stephen (Talk) 18:42, 21 May 2016 (UTC)[reply]

The "original problem" is simply that Norman used to be known as Jèrriais and Guernèsiais, so Norman translation lines are often still alphabetized under G or J, depending on which variety was originally listed. I have no idea if there's any way to fix this other than manually. —Aɴɢʀ (talk) 21:08, 21 May 2016 (UTC)[reply]
It can, indeed, be done by a bot: Ive seen many a bot task that involved rearranging whole lines. Chuck Entz (talk) 07:24, 22 May 2016 (UTC)[reply]
I correct the order for Norman whenever I come across it, as I have occasionally made the mistake of entering Norwegian just after it when it's in the wrong order, and then I have to move both. I hope that makes sense. Donnanz (talk) 08:58, 22 May 2016 (UTC)[reply]

‘Add country flags next to language headers’ breaks the pages. edit

http://i.imgur.com/FnThnsH.png

The left side is when the flags are off, the right is when the flags are on. --Romanophile ♞ (contributions) 08:46, 22 May 2016 (UTC)[reply]

Apart from the page being heavily customised I can see a difference, but I haven't got a clue what you're talking about. What kind of flags? Donnanz (talk) 18:58, 22 May 2016 (UTC)[reply]
There is an option in Preferences, under Gadgets, called »Add country flags next to language headers«. Before last night, this option added small images of flags next to the headers of the appropriate language sections of each entry. Since last night, it has broken the site by getting rid of the left sidebar and the toolbars at the top of each page. It’s not a consequence of his customizations; the same thing happened to me with default typography. Was there some recently changed code that could have caused this? Vorziblix (talk) 19:12, 22 May 2016 (UTC)[reply]
Try now. — Ungoliant (falai) 19:25, 22 May 2016 (UTC)[reply]
Seems to work, thank you ^_^ -Xbony2 (talk) 19:32, 22 May 2016 (UTC)[reply]
OK, found it. My opinion of the English flag is unprintable. Donnanz (talk) 20:52, 22 May 2016 (UTC)[reply]
You can add a different one to your personal css. That’s what I do; using the flag of the Commonwealth to represent English is dumb. — Ungoliant (falai) 20:56, 22 May 2016 (UTC)[reply]
As is using flags to represent languages at all! Equinox ◑ 21:35, 22 May 2016 (UTC)[reply]
That's what I thought. I'll probably end up switching the damned thing off again. Donnanz (talk) 21:46, 22 May 2016 (UTC)[reply]

Doubling diacritics edit

Something's going on with the box of clickable characters governed by MediaWiki:Edittools. In Burmese and Devanagari, clicking any of the combining characters causes the character to appear twice. (For example, if I click on ा in Devanagari, what appears is ाा.) This doesn't seem to be happening for combining characters in the other scripts, though I haven't checked everything. Also, for Khmer, clicking any of the combining characters causes all of them to appear in the edit box. Any thoughts how to fix this? —Aɴɢʀ (talk) 20:01, 22 May 2016 (UTC)[reply]

水 and 一 edit

Both of these pages currently run out of memory about halfway down the page. No idea why only these specifically, though I'd guess it's the tables using {{l}}. KarikaSlayer (talk) 21:12, 22 May 2016 (UTC)[reply]

It must be caused by {{ja-r}}: [1], [2]. @Haplology, why is this template so memory-hungry? — TAKASUGI Shinji (talk) 14:07, 24 May 2016 (UTC)[reply]
Personally I think the Chinese templates are more suspect. —suzukaze (t・c) 14:40, 24 May 2016 (UTC)[reply]
You are right. It’s {{zh-l}} that is the heaviest: [3]. The Chinese “Compounds” section uses 8.8 MB in the allotted 50 MB per page. The Chinese section uses 27.02 MB while the Japanese one uses 6.75 MB. (You can check it by viewing the HTML source of a preview.) We must modify Module:zh. — TAKASUGI Shinji (talk) 16:17, 24 May 2016 (UTC)[reply]
Looks like it's fixed now. KarikaSlayer (talk) 03:02, 25 May 2016 (UTC)[reply]
Because one of the less important templates has been hidden... it's not over yet orz —suzukaze (t・c) 03:08, 25 May 2016 (UTC)[reply]

Change in function of DISPLAYTITLE Magic Word edit

{{DISPLAYTITLE}} no longer allows changing the displayed title to anything that isn't closely equivalent to the actual title. instead, it shows:

Warning: Display title "<title that would have been displayed>" was ignored since it is not equivalent to the page's actual title.

As I understand it, we have a number of templates that depend on the previous behavior of {{DISPLAYTITLE}}, including the ones for our unsupported title entries. This change in behavior seems to be due to the introduction of the configuration setting $wgRestrictDisplayTitle, which defaults to true. Can we change this to false, or get someone to change it for us if we don't have access to it? Chuck Entz (talk) 23:14, 22 May 2016 (UTC)[reply]

Has {{DISPLAYTITLE}} ever allowed it? I don’t think so. I correctly see pages like “ . ” and “#”, but I don’t know where the template is. Similarly, Wikipedia has w:Template:Correct title, and the French Wiktionary has fr:Modèle:titre incorrect. — TAKASUGI Shinji (talk) 13:52, 24 May 2016 (UTC)[reply]
Yeah, that's never been allowed. Unsupported titles do it through JavaScript. --WikiTiki89 15:19, 24 May 2016 (UTC)[reply]
You may want to set a category in MediaWiki:Restricted-displaytitle to track any such wrong usage of DISPLAYTITLE. — Dakdada 08:48, 25 May 2016 (UTC)[reply]
  Done: CAT:DisplayTitle errors. --WikiTiki89 15:26, 25 May 2016 (UTC)[reply]
It would be nice, but by no means essential, to be able to display taxonomic names in italics (viruses, genera, subgenera, species, some subspecies) or mixed italic and ordinary type (some subspecies, sections, varieties). How could that be done? Would it consume significant programming resources or server resources? DCDuring TALK 16:24, 25 May 2016 (UTC)[reply]
Wikipedia does italics for taxonomic names. However, I would oppose that here (although I would support italicizing headwords of taxonomic names). --WikiTiki89 16:46, 25 May 2016 (UTC)[reply]
Hunh? Do you mean you support current practice for normally italicized taxonomic names on their inflection line, as well as all other uses of such names here? DCDuring TALK 21:48, 25 May 2016 (UTC)[reply]
I didn't know that it was current practice in headword lines, but yeah I support it. My point was that I oppose it for the page title (and I was clarifying that that doesn't mean I oppose it in other places). --WikiTiki89 22:01, 25 May 2016 (UTC)[reply]

Automatic welcome message at id.wikipedia edit

FYI, it seems you get an automatic welcome message on your talk page at https://id.wikipedia.org/wiki/ just by visiting the project for the first time. (My welcome message is here: https://id.wikipedia.org/wiki/Pembicaraan_Pengguna:Daniel_Carrero)

This could be annoying for some people, because they get a notification here on Wiktionary about that welcome message. --Daniel Carrero (talk) 06:48, 25 May 2016 (UTC)[reply]

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

Formatting changes with verbs that are centred aligning to the left when they are printed[edit] edit

Hi Wiktionary is brilliant. I am preparing for Polish exams and am finding my new printer does not print the page as is when I select and copy and print.

Anything that is centred is aligned to the left when printed. How can I stop this happening?

However, if i print the whole page with the conjugation not hidden the title conjugaiton appears on the first page and everything on the second and it is perfectly aligned. i just want the title conjugation on the same page as the actual conjugation - it looks neater.

I will be making a contribution to wiktionary as it has been invaluable. Thank You Anne marie

You're very welcome.
I'm not sure how much control we have over printing, this may be a Wikimedia issue, anyone know? Benwing2 (talk) 02:27, 27 May 2016 (UTC)[reply]

Prakrit edit

Could a kind admin remove pra from MOD:families/data and add it to MOD:languages/data3/p? Also, the following languages need to made etymology-only:

  • pmh
  • pka
  • psu
  • pgd

(pinging those involved in the discussion at WT:Beer parlour#Merge all Prakrits: @CodeCat, -sche, Metaknowledge) —Aryamanarora (मुझसे बात करो) 18:34, 25 May 2016 (UTC)[reply]

@Aryamanarora: I'm not sure this has reached agreement yet. I'm not saying I disagree―I'm just not sure that we have a consensus on what, if any, action should be taken. —JohnC5 19:41, 25 May 2016 (UTC)[reply]

updated since my last visit edit

The "updated since my last visit" text on history pages of pages in my watchlist is now highlighted bright green. Why? And can we disable it? --WikiTiki89 19:43, 25 May 2016 (UTC)[reply]

You can remove the highlighting by adding span.updatedmarker { background-color:transparent; } to your css, or the site css. - -sche (discuss) 01:44, 26 May 2016 (UTC)[reply]
Would people support adding that to MediaWiki:Common.css? And why did it change in the first place? --WikiTiki89 14:52, 26 May 2016 (UTC)[reply]
I think "updated since my last visit" has some sort of highlighting on most other wikis. Makes it easier to see where to start if you want to see all changes since the last time you looked at the page. I like it. —Aɴɢʀ (talk) 15:04, 26 May 2016 (UTC)[reply]
I just think it's way too bright. We could highlight with a more mellow color. --WikiTiki89 15:16, 26 May 2016 (UTC)[reply]
I agree with both of you: yes, it's handy to have highlighting, but this particular color is burning holes in my retinas. Please make it stop!!! Chuck Entz (talk) 01:58, 27 May 2016 (UTC)[reply]
I've softened it to "tea green". (I tried the predefined css color "pale green", but it was still too garish IMO.) - -sche (discuss) 08:11, 28 May 2016 (UTC)[reply]

My new entry marked as spam edit

I just created a definition for the word : Collectory and it keeps reporting it as spam. The definition is:

1. a collection of beloved items and their stories 2. the password for entry on Twicemore.co

Please let me know what I can do to avoid this from happening.

Thanks so much, Nikki

Hi Nikki. That is spam. Stop adding it, and learn how to advertise in an appropriate way without wasting other people's time. —Μετάknowledgediscuss/deeds 16:16, 26 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:41, 19 January 2018 (UTC)[reply]

Diminutive parameter for lb-noun edit

The template {{lb-noun}} ought to have a parameter for diminutive forms, like {{de-noun}} does. Also, who would like to create the module lb-headword, not just for nouns but also for other lemmata? --Lo Ximiendo (talk) 18:15, 26 May 2016 (UTC)[reply]

@Lo Ximiendo: I was considering making a module after seeing your earlier request. I would make it similarly to mod:de-headword, but I'm not very familiar with Luxembourgish and might need some guidance. —JohnC5 18:41, 26 May 2016 (UTC)[reply]
@JohnC5: You could consider consulting Kolmiel (talk • contribs); knowledge of Franconian forms of language at least. --Lo Ximiendo (talk) 18:48, 26 May 2016 (UTC)[reply]
Yes. You can get most of the guidance you need from me, I hope :) Luxemburgish should definitely have diminutives in the template. I've often thought about requsting that, too. Now, the regular form is stem + -chen, but there's much variation (umlaut and other things), so generally the forms will have to be added by hand. An important thing is that Luxembourgish diminutives, unlike the German and Dutch, generally keep their gender and don't become neuter. Plural diminutives are somewhat irregular, or at least there's not one simple rule like in the aforementioned two languages. We might consider putting the plural diminutive into the template as well. But on the other hand, plural diminutive will be found in the respective diminutive lemmas. So it may not be necessary. Kolmiel (talk) 22:52, 26 May 2016 (UTC)[reply]
@Lo Ximiendo, Kolmiel: Could you both look at User:JohnC5/lb-sandbox and mod:lb-headword and give comments on things you'd like added/removed/changed/etc? Please fiddle around with the functionality and tell me what template behaviors you prefer. Also, should verbs have more principle parts? Is there any need for |head2=, |head3=? Do verbs ever take both hunn and sinn? —JohnC5 05:26, 27 May 2016 (UTC)[reply]
The nouns look very good, I think. I forgot to say that diminutives should not be obligatory and that alternative forms should be possible, but that's the case already. Thanks. --- Verbs: 1.) Yes, they can have both auxiliaries. 2.) I think it would be good to have the third-person singular present as principle part. It's very often irregular and in this case generally enables you to figure out the 2nd person singular and 2nd person plural. --- Adjectives: 1.) We should probably get rid of the feminine because it's always the same as the basic form. I'm 99,9% sure that there's no exception whatsoever. However, we could leave it as a non-obligatory entry for some strange word that might pop up. 2.) The comparative - but not the superlative - is usually analytic (méi XY = "more XY"). So there should be some short key for this, and only the word "méi" should be clickable (if at all). 3.) The superlative is given in the predicative/adverbial form, which as in German has the prepositional element am before it. So superlatives should automatically be preceded by a non-clickable am. Kolmiel (talk) 11:07, 27 May 2016 (UTC)[reply]
@Kolmiel: Check it out now. If you think these are fine, we can start switching the current templates over, but the verbs and adjectives would certainly be broken for current entries. If we left them broken for too long, Chuck would leave a message on my page saying there are a bunch of errors. So, if you are prepared to fix all of the verbs or adjectives at one time, we can do it; though I don't know how much help I'll be. Alternatively, we can create {{lb-adj-new}} and {{lb-verb-new}}, switch the lemmata over, replace the code in {{lb-adj}} and {{lb-verb}} with then new template, then rename everything back. Whichever you think is most appropriate. —JohnC5 17:20, 27 May 2016 (UTC)[reply]
I generally don't bug people if I know they're working on the problem, though I've been known to complain when someone does the equivalent of shutting off the regional power grid so they can rewire their kitchen... Chuck Entz (talk) 21:33, 27 May 2016 (UTC)[reply]
@Chuck Entz: ;) I know. I just was floating options on the best way to do this and would also like for you to get early notice for what may of may not happen. —JohnC5 21:42, 27 May 2016 (UTC)[reply]
Thanks guys. I'll check them on Monday or Tuesday, God willing. It's three at night around here, and I don't think I'll get to it during the next two days. Kolmiel (talk) 01:04, 28 May 2016 (UTC)[reply]
I'll be away from the internet for about a week starting Sunday, so do whatever you want. I think the operation of the module is fairly straightforward, but otherwise I can help when I get back. —JohnC5 01:26, 28 May 2016 (UTC)[reply]
Looks pretty good. Just one thing doesn't seem to exist yet: the analytic "méi"-comparative with another alternative comparative. That happens a lot. (For example, al "old" has méi al and eeler, the latter of which is often used in the sense of "rather old" as in "older people".) Kolmiel (talk) 11:30, 30 May 2016 (UTC)[reply]
@Kolmiel: Ok, I'm back. how would you like this to be input? Do most irregular comparatives have analytic counterparts? I can think of several ways of implementing this behavior but don't know which if best. One would be to have all extra usage of |comp= appear along with the analytic comparative unless the analytic one were explicitly turned off (with something like |comp-irreg-only=). Or we could have something like |comp=m represent the analytic comparative, similarly to what has been done with |1=s in {{en-noun}}. What do you think? —JohnC5 17:27, 5 June 2016 (UTC)[reply]
@JohnC5: Most adjectives have only the analytic form. Just three (good, much, little) have only the irregular form. A certain number (10, 20, 30?) have both forms. -- Maybe your first idea would be then best then? Kolmiel (talk) 18:29, 5 June 2016 (UTC)[reply]
@Kolmiel: I'll work on that. Also is there a rule that predicts when the superlative takes -schten vs. -sten vs. -ten? —JohnC5 18:45, 5 June 2016 (UTC)[reply]
@Kolmiel: I've made some updates. —JohnC5 19:16, 5 June 2016 (UTC)[reply]
@JohnC5: Yes, good. Thanks again. But preferably the analytic form should be given before the irregular one since the analytic one tends to be the actual comparative (more than someone else) while the irregular one has a less literal sense (e.g. more than average). — -schten is not an ending of the regular superlative. It only occurs in bescht ("best") and meescht ("most"). Kolmiel (talk) 18:29, 5 June 2016 (UTC)[reply]
@Kolmiel: I've reversed the comparatives. As for -ten, it seems like this is added to adjectives ending in -s (grouss → groussten). Are there any other examples? Also, what is the general rule for generating the masculine and the neuter (stem + -en and stem + -t)? I'd like to get this as streamlined as possible. —JohnC5 23:47, 5 June 2016 (UTC)[reply]
@JohnC5: Sure. The superlative of "grouss" is "am gréissten" with an umlaut. Such forms and some others must definitely be added manually. Otherwise it's -sten, but -ten after -s, -x, -z. (Btw, can we do alternative superlatives? That should be possible too. [Actually all forms should allow alternatives to be safe, I think.]) The regular masculine is stem + -en. The regular neuter is stem + -t, but unchanged after -d, -t. Kolmiel (talk) 18:29, 5 June 2016 (UTC)[reply]
@Kolmiel: Yeah, I should have guessed grouss would be a bad example. I've already written the module to accept alternatives for all parameters except the headword itself (I can add alternative headwords if you think it will be useful). I noticed when reading the code for {{lb-decl-adj}} that adjectives ending in -f have a -w- alternation and those ending in -e take -ën in the masculine. I'll probably encode this, but are there any other such rules? —JohnC5 02:47, 6 June 2016 (UTC)[reply]
@JohnC5: There are other alternations, but no rules that I'm aware of. Also f/w is not a rule; it depends on the etymology. I think it shouldn't be included in the code. In what words have you seen the trema? I think it's just after -ee. Where your words with -ee? — Does "headword" mean the lemma, i.e. the basic form? In that case, no, I don't think we need alternatives for these. Kolmiel (talk) 03:18, 6 June 2016 (UTC)[reply]
@Kolmiel: Yeah, I guess the rule is for -ee. Does it always hold for -ee? If so, I'll just keep that one. Otherwise, I think it may be done. —JohnC5 03:23, 6 June 2016 (UTC)[reply]
@JohnC5: Yeah, for -ee it's right. Kolmiel (talk) 03:18, 6 June 2016 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Kolmiel: Ok, I think these are ready for usage. As I said, it's gonna cause a lot of errors. Shall we begin changing them over? I suggest doing {{lb-noun}} and {{lb-proper noun}} first. —JohnC5 03:32, 6 June 2016 (UTC)[reply]

@Kolmiel, Chuck Entz: I've changed {{lb-noun}} and {{lb-adj}} over. CAT:E has ~200 broken adjectives. I've fixed a bunch already but am unsure which have irregular comparatives and superlatives. Kolmiel, if you could check all the adjectives with irregular forms (whether they have errors or not), then we can continue fixing the template errors (this usually involves deleting all the parameters and using the auto-generated forms). Sorry to dump this work on you. —JohnC5 05:32, 6 June 2016 (UTC)[reply]
@JohnC5: I've checked the category. Those in it now should all regularly work with the template. The others I've changed manually. The template works very well, but because of the complicated spelling rules and the irregular superlatives I'd like to check those which you already did. Is there a list? (I spotted and corrected mistakes in kuerz and I think one other word. So there might be a few more.) And there's one thing we've forgotten: predicative-only adjectives (for which masculine and neuter don't exist and don't apply). Can we still add that? Otherwise we'd have to use {head|lb|adjective} for these. They are not very many.
PS: So far I've come across 6 adjectives with two comparatives. So they may be fewer than I'd thought, just 10 or 15 probably. And it was good that we left the feminine as a non-obligatory form. I had to use it once on futti. (I didn't think it existed, but okay, we're good.) Kolmiel (talk) 17:03, 6 June 2016 (UTC)[reply]
@Kolmiel: I'd say check my recent history. They should all be in there. I can add |pred-only= which will remove all gendered forms. I also noticed the spelling that [aiou] followed by a single consonant or nothing represent a long vowel that must be must be separately marked if a word ends in multiple consonants (kal → kaalt & kaalsten). I could probably add functionality to generate the odd neuters and superlatives if you think it is useful. —JohnC5 17:12, 6 June 2016 (UTC)[reply]
@JohnC5: Yes, amazing how you figured out this rule, which many Luxembourgish people can't remember even when they're taught it :) I thought about it too. The rule affects the neuter and superlative of adjectives with a, i, o, u not preceded by another vowel and followed by a word-final single consonant. And it affects the superlative only of adjectives with a word-final a, i, o, u not preceded by another vowel. -- I thought this would be very difficult to encode, but if you can do it and want to it, it would be quite useful I think. Kolmiel (talk) 17:24, 6 June 2016 (UTC)[reply]
@Kolmiel: I've made the changes for predicate-only adjectives and for lengthening. Could you check out fit to see if its superlative is correct? Also, could you give me an example of a predicate-only adjective? And should it be predicate(-)only, predicative(-)only? —JohnC5 20:23, 6 June 2016 (UTC)[reply]
PS: May I suggest just running through everything in cat:Luxembourgish adjectives to make sure they have the correct irregular forms? Some of them may have had no parameters specified previously, which would cause them not to have errors, but would still be generating regular, potentially incorrect forms. —JohnC5 20:46, 6 June 2016 (UTC)[reply]
@JohnC5: Great! Seems to work fine. Yeah, fit has "am fitsten", but it needn't bother us. If it were an originally Luxembourgish word it would have to be spelt "fitt". I fixed it. -- I can't think of a predicate-only adjective right now. Sorry. But I'm sure they exist. I s'pose "predicate-only" is fine. (In the end it doesn't matter, but this has two letters less.) Okay, yeah. I'll go through the list, but it's gonna be a couple of days before I can. Kolmiel (talk) 17:24, 6 June 2016 (UTC)[reply]
@Kolmiel: Any news here? We still need to do the verbs. —JohnC5 18:04, 13 June 2016 (UTC)[reply]
@JohnC5: No news so far. I haven't forgotten about checking the adjectives, but I haven't had the time. Maybe tonight or so. -- Yes. The verbs. Luxembourgish verbs generally have only a present conjugation and a past participle. Just over 20 verbs have a preterite and/or a subjunctive (= conditional tense). The principle parts would be past participle and perfect auxiliary + (as I proposed) the 3rd person singular present, which is irregular in ca. 70 verbs. The preterite and subjunctive would be non-obligatory items that we add when applicable. Kolmiel (talk) 13:56, 14 June 2016 (UTC)[reply]
PS: I've checked the adjectives from A to E now. Will do the rest some time soon, I hope. -- And I have a predicate-only adjective for you now: eleng. I wasn't able to use the right code though. Add it for me please and I'll see. Kolmiel (talk) 22:20, 14 June 2016 (UTC)[reply]
@Kolmiel: I'd already added it (|pred-only=). I really need to write some documentation. I've also added |subj= and |pred= to the lb-verb code; though that hasn't been added to the mainspace. You can still test it out at User:JohnC5/lb-sandbox. —JohnC5 00:35, 15 June 2016 (UTC)[reply]
@JohnC5: I'm done with the adjectives now. What should I do next? :) Kolmiel (talk) 17:01, 28 June 2016 (UTC)[reply]
@Kolmiel: —JohnC5 22:54, 28 June 2016 (UTC)[reply]
Great, and thanks for all your work! Next is the verbs, which is going to be interesting. If I change the {{lb-verb}} over to the code in mod:lb-headword, all of the lb verbs are going to be wrong or create errors. We can do it if you'd like, but we'll have to change them over fairly quickly, with which I won't be much help. The new template has two required params:
  • |1=: the 3rd singular present (further with |3s pres2=, ...),
  • |2=: the past participle (further with |pp2=, ...)
And several optional params:
  • |3=: auxiliary ("hunn", "sinn", "both") with "hunn" as default
  • |pret=: irregular preterite form (further with |pret2=, ...)
  • |sunj=: irregular subjunctives (further with |subj2=, ...)
I can change it over if you want to start fixing them, or I can create {{lb-verb-new}}, you move them from the old template to the new (with added information), then I go through and move lb-verb-new > lb-verb. What do you think? —JohnC5 22:53, 28 June 2016 (UTC)[reply]
@JohnC5: Yeah, it should be the latter. I'll work on it, but I won't be very quick, I think. -- Now I suppose we want to optimize the verb template like we did the adjective one: 1.) Verbs are given as infinitives, whence we get the (regular) stem by subtracting -en. The 3rd singular present takes -t and has the same spelling rules as the neuter adjective, with just one difference: Verbs with a stem in -d aren't left unchanged, but rather replace -d with -t (waarden > waart). 2.) The past participle is usually the same as the 3rd singular but with a prefix ge- (> gewaart). Sometimes ge- is missing, however. Maybe a shortcut for this. 3.) Finally, there are separable verbs. The Afrikaans verb template has a thing for this (cf. opskryf). For a Lux. verb "ofwaarden" it would mean that I enter a parametre sep=of or the like, and it would give me the forms "waart of" and "ofgewaart". (I.e. the separated syllable comes after the 3rd singular and the prefix ge- becomes an infix). Kolmiel (talk) 00:31, 30 June 2016 (UTC)[reply]
PS: A) The infinitive ending can also be -ën, so that should be deletable too. (Forms in -n(n) without -e occur only in a handful of verbs, all of which are irregular anyway, so this doesn't need to be considered.) B) Verbs with a stem in -dd make that -tt (bidden > bitt). C) Verbs with a stem in -w make that -ft (schreiwen > schreift). C) When the stem begins with e- or i- the prefix ge- becomes gë-. Kolmiel (talk) 00:46, 30 June 2016 (UTC)[reply]
@Kolmiel: I've made the appropriate changes. You may find the new template at {{lb-verb-new}}. So, you're going to change all the verbs over to this one, then I'll switch the code at {{lb-verb}} and use AWB to change the entries back to original template? —JohnC5 03:00, 30 June 2016 (UTC)[reply]
@JohnC5: The template seems to work very well. Thanks once more. There's just one more thing I'd forgotten: A couple of separable prefixes lose an "n" before some consonants. Please see whether you can do the following: a function where we type e.g. sep=a(n) and the system separates "an" if that's there and just "a" otherwise, and automatically puts "an" in the 3rd person, but "a" in the participle. So that with sep=a(n) andecken has "deckt an, agedeckt", and abeezen has "beezt an, agebeezt". Kolmiel (talk) 23:27, 5 July 2016 (UTC)[reply]
Oh wait: in the past participle it would have to leave out the "n" when the prefix "ge-" is there, but otherwise use the form of the infinitive. That is, automatic past participle = no "n", and manually added past participle starting with "ge-, gë-" also = no "n", but manually added past participle without "ge-, gë-" = judging by the form of the infinitive. I hope this is not too complicated... Kolmiel (talk) 23:34, 5 July 2016 (UTC)[reply]
@Kolmiel: I had already added this rule to omit all n's in prefix of a past participle that doesn't begin with any of [dhntz]. Is that sufficient? —JohnC5 23:40, 5 July 2016 (UTC)[reply]
@JohnC5: Oh! I thought I'd checked it. Seemingly not properly. Great job! -- I'm sure it'll work. There are two potential problems with it: Verb prefixes that don't lose "n", of which I'm not aware, but which I can't rule out entirely because the n-losing-rule is grammatical, not purely phonological. And the letter "z", which would trigger n-less forms when pronounced /z/ rather than /ts/ in French or English words. But please leave it, both are so marginal and quite probably non-existant that it really wouldn't be worth the effort before I actually come across one such verb. Kolmiel (talk) 00:09, 6 July 2016 (UTC)[reply]
@Kolmiel: Great! keep me posted if you find any errors! —JohnC5 00:13, 6 July 2016 (UTC)[reply]
@JohnC5: Sorry, I just did ;) The "n" must also be there before all vowels (a, ä, e, é, ë, i, o, u, and the rare ö, ü). Thanks in advance. Kolmiel (talk) 00:18, 6 July 2016 (UTC)[reply]
@Kolmiel: That should fix it. Got an example for testing? —JohnC5 00:25, 6 July 2016 (UTC)[reply]
@JohnC5: I've created unerkennen. It works there :) Kolmiel (talk) 02:57, 6 July 2016 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I've migrated everything over to the new template then move it all back to {{lb-verb}}. I have also created {{lb-proper noun}} which has very similar syntax to {{lb-noun}}. I'll try to remember to write some documentation for these, but I'm too tired at the moment. Is there anything else that you need from me? —JohnC5 04:27, 11 July 2016 (UTC) @Kolmiel. —JohnC5 04:28, 11 July 2016 (UTC)[reply]

@CodeCat, Luxemburgish lemmas will be easier to manage using mod:lb-headword. --Lo Ximiendo (talk) 17:51, 30 May 2016 (UTC)[reply]

Support for etym-only languages in {{affix}}? edit

It's awesome that {{affix}} supports derivations from other languages; this happens all the time in Russian, for example, where foreign adjectives routinely get -ный (-nyj) added to them to form a Russian adjective. But this template doesn't yet support etym-only languages; can this be added (maybe by @CodeCat)? See эквивале́нтный (ekvivaléntnyj) for an example using Late Latin. Benwing2 (talk) 02:25, 27 May 2016 (UTC)[reply]

This would be easy to add, and I'm glad you like this feature, but it was added before we had templates/categories distinguishing inherited, borrowed and miscellaneously derived terms. The template doesn't currently distinguish these. I'm thinking, though, that the only cases where this feature would be used would be in borrowings. If it were used with an inherited term, then surely there would be no need for the language parameter, and I'm not sure when a miscellaneous derivation would be appropriate either. So would it be ok to automatically use the borrowing category? —CodeCat 12:31, 27 May 2016 (UTC)[reply]
I'm fine with this. I did use an inherited language in one case, see взрачный. This is probably a misuse of the {{affix}} template, though; presumably the word itself was constructed in Old East Slavic (or earlier) even if not attested. Benwing2 (talk) 05:39, 28 May 2016 (UTC)[reply]
In fact the source I took the etymology from, ruwikt, says this:
Др.-русск. образование от зракъ «вид, облик», заимствованное из ст.-слав.; восходит к праслав. *zьrěti и праиндоевр. ǵerh₂-.
which seems to indicate exactly what I just said. Benwing2 (talk) 05:40, 28 May 2016 (UTC)[reply]
It would be strange for a nonexisting word to be used in word formation, so I think this is a misuse. While the general intent is clear, it's not really accurate. Either the word survived into modern Russian and was used for the derivation before it fell out of use, or the derivation took place in Old East Slavic. Dating attestations would be the key. —CodeCat 16:13, 28 May 2016 (UTC)[reply]
I've added support for etymology-only languages. I also changed the categorisation to use "borrowed". —CodeCat 16:58, 30 May 2016 (UTC)[reply]
Thank you! Benwing2 (talk) 19:14, 30 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:41, 19 January 2018 (UTC)[reply]

Different parsing in template? edit

In this template, the combined character ü̂ gets interpreted as uA, i.e. if you click sü̂, you get directed to suA. Can that be fixed? Korn [kʰũːɘ̃n] (talk) 14:05, 29 May 2016 (UTC) This seems to be true for all templates. Korn [kʰũːɘ̃n] (talk) 14:19, 29 May 2016 (UTC)[reply]

Use {{l|gml|su|sü̂}}. — Ungoliant (falai) 14:30, 29 May 2016 (UTC)[reply]
That's not possible everywhere, because the verb template is made out of switches. Korn [kʰũːɘ̃n] (talk) 16:03, 29 May 2016 (UTC)[reply]
This is because the entry_name parameter in the language data for gml has combining characters in the regexes, which actually need to be treated differently. I will fix this when I get a chance unless someone beats me to it. --WikiTiki89 16:39, 29 May 2016 (UTC)[reply]
I would much appreciate that, thank you. Korn [kʰũːɘ̃n] (talk) 19:10, 29 May 2016 (UTC)[reply]
  Done --WikiTiki89 01:13, 30 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:41, 19 January 2018 (UTC)[reply]

sc= still needed? edit

Many templates accept a sc= parameter, a leftover from the days before automatic script detection. I'm wondering if this parameter is still needed? Are there still cases where overriding the script manually is necessary? —CodeCat 22:41, 29 May 2016 (UTC)[reply]

I don't know of any cases although theoretically I suppose it could happen with mixed scripts. Benwing2 (talk) 00:43, 30 May 2016 (UTC)[reply]
Min Nan can be written in Latn (Peh-oe-ji) or Hani. —suzukaze (t・c) 01:31, 30 May 2016 (UTC)[reply]
But would script detection not be able to work that out? —CodeCat 01:32, 30 May 2016 (UTC)[reply]
I suppose script detection could figure it out.
This reminds me, sometime script detection seems to fail if there is enough template code (I suppose it's being detected as Latn); I remember having to use sc=Jpan at some point in the last few weeks, such as at 4649. —suzukaze (t・c) 01:37, 30 May 2016 (UTC)[reply]
Would you give us several examples when it is detected as Latn when there is enough template code? I think it's easy to fix. --Z 09:37, 30 May 2016 (UTC)[reply]
There's also 圏点. I can't think of any more off the top of my head. —suzukaze (t・c) 23:03, 30 May 2016 (UTC)[reply]
I note that Serbo-Croatian Cyrillic in some templates seems to display in a different font for me depending on the presence or absence of the sc=Cyrl parameter; I don’t know whether this is the intended behaviour. Same with Old Church Slavonic and sc=Cyrs. Old Novgorodian entirely fails to display Glagolitic without sc=Glag in Template:l, instead giving »Lua error in Module:Cyrs-Glag-translit at line 129: This module can only transliterate Old Cyrillic (Cyrs) and Glagolitic (Glag).« Vorziblix (talk) 02:57, 30 May 2016 (UTC)[reply]
Old Novgorodian doesn't have Glagolitic as one of its scripts, so it won't be detected. —CodeCat 13:05, 30 May 2016 (UTC)[reply]
Should it be added? We have a number of Old Novgorodian entries attested in Glagolitic (generally from Савва Михайлович, "22 Древнерусских глаголических надписи-граффити XI–XII веков из Новгорода"), but overall, most of the Novgorodian corpus is exclusively Cyrillic. We could just standardize on Cyrillic given the preponderance of Cyrillic sources and the effort needed to maintain duplicate entries. Or we could add Glag to Module:languages/datax if we want to strictly stay with the attestations. Vorziblix (talk) 19:38, 31 May 2016 (UTC)[reply]
Yes, every language should have a code added for every attested script, even if it's only used in quotations and there are not actual entries in the script. --WikiTiki89 19:41, 31 May 2016 (UTC)[reply]
Also, can you give an example where the sc=Cyrl makes a difference? —CodeCat 17:02, 30 May 2016 (UTC)[reply]
Any Serbo-Croatian inflection table does it; the version without sc=Cyrl displays using my browser-default serif font, while the version with sc=Cyrl displays with a particular sans-serif font that’s presumably set by Wiktionary (not any of my default fonts). Here’s one of each:
Declension of Grease pit/2016/May
singular plural
nominative ратлук ратлуци
genitive ратлука ратлука
dative ратлуку ратлуцима
accusative ратлук ратлуке
vocative ратлуче ратлуци
locative ратлуку ратлуцима
instrumental ратлуком ратлуцима
Declension of Grease pit/2016/May
singular plural
nominative ратлук ратлуци
genitive ратлука ратлука
dative ратлуку ратлуцима
accusative ратлук ратлуке
vocative ратлуче ратлуци
locative ратлуку ратлуцима
instrumental ратлуком ратлуцима
And here’s a screenshot of how it looks for me: [4]. It’s not particularly significant, though; either one is perfectly fine. Vorziblix (talk) 19:20, 31 May 2016 (UTC)[reply]
That template still uses really poorly written template code. It essentially doesn't wrap the text in any templates if the sc is Latn, and wraps it in {{lang|sh|sc=Cyrl}} if the sc is Cyrl. It should be fixed. --WikiTiki89 19:33, 31 May 2016 (UTC)[reply]
I've fixed it up now. The sc= parameter of that template is no longer used at all. —CodeCat 19:53, 31 May 2016 (UTC)[reply]
But there are still more SH templates that need to be fixed. And it's not simple either, because many of the forms have parenthesized parts that cannot just be linked haphazardly, for example adjectives often have things like новог(а). --WikiTiki89 19:57, 31 May 2016 (UTC)[reply]
What I would say is that even if there were no cases where this parameter is necessary, it should still be kept. You never know when you'll want to intentionally use the wrong script code for testing or for whatever reason. --WikiTiki89 19:33, 31 May 2016 (UTC)[reply]
But if you wanted to test something you could just manually wrap it in the appropriate class. DTLHS (talk) 19:56, 31 May 2016 (UTC)[reply]
The only thing I can think of is that certain languages (Frankish, Proto-Norse, Gothic) are attested in one script and reconstructed in a different one. —Aɴɢʀ (talk) 15:52, 14 June 2016 (UTC)[reply]

template:el-noun edit

In Κυπριώτης it gives as transliteration "• (Kypriótis)". Should't it give Kypriótes (e) or am I wrong (only for old grc)? Sobreira (talk) 13:01, 30 May 2016 (UTC)[reply]

It's i in modern Greek. —CodeCat 13:04, 30 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:42, 19 January 2018 (UTC)[reply]

inh and VL. edit

Just noticed this. When using inh and VL., there are no longer any categories generated for Vulgar Latin at the bottom of a page, for example, with aguja. I don't know if I missed something in a policy discussion about this, but what happened? Was this changed because generally if a term comes from Vulgar Latin, it's assumed it's inherited? But it doesn't even show up as a derived from category. Are we just doing away with it altogether? Word dewd544 (talk) 22:51, 30 May 2016 (UTC)[reply]

It was a bug in Module:etymology, fixed now. —CodeCat 00:30, 31 May 2016 (UTC)[reply]
Oh, okay. Thanks! Word dewd544 (talk) 01:19, 31 May 2016 (UTC)[reply]
Solved. Per utramque cavernam (talk) 21:42, 19 January 2018 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2016/May&oldid=75380437"