Wiktionary:Information desk/2020/February

From Wiktionary, the free dictionary
Jump to navigation Jump to search

red links instead of black[edit]

in the templates, is there a way to view the links to the pages that don't exist as red instead of black? it's just kinda hard to differentiate between blue and black (and especially violet and black) LICA98 (talk) 10:40, 3 February 2020 (UTC)[reply]

@LICA98: I guess you mean "redlinks" in inflection tables (for instance, all or some of the links in the inflection table in αἰτητός). You can change their color by adding the following CSS to your common.css: 
.inflection-table a.new {
	color: #ba0000;
}
This overrides the style that forces these links to have the default color of the text in the table (color: inherit;). — Eru·tuon 10:52, 3 February 2020 (UTC)[reply]
@Erutuon: so I just click "create" and paste that there? LICA98 (talk) 10:58, 3 February 2020 (UTC)[reply]
@LICA98: Yes. And then it will apply the style whenever you are logged in on this website. — Eru·tuon 11:11, 3 February 2020 (UTC)[reply]

step by step[edit]

hello there, I'm a new member here, could you tell me step by step guide for a new beginner like me?

--PutriAmalia1991 (talk) 12:52, 4 February 2020 (UTC)[reply]

I have posted our usual welcome message to your talk page: there are some useful links there. Equinox ◑ 20:48, 4 February 2020 (UTC)[reply]

Root or Affix[edit]

Hello

I took a brake from developing the pages on the Alutor language, and now that I'm back I've noticed a few pages I've created that seem inaccurate. Alutor is a polysynthetic language, and I'm not sure if root is used on Wiktionary or if I should stick to Affix. E.g the term -ынп- is a root used in adjectives, should I call it "root", "adjective" or "affix"?

Millerutt (talk) 16:19, 13 February 2020 (UTC)[reply]

What term is used by linguists when they talk about the languages? DTLHS (talk) 16:19, 13 February 2020 (UTC)[reply]
Judging by the examples -ынп- functions as a prefix, somewhat comparable to the German prefix alt-, although the latter is only used in combination with an adjective.  --Lambiam 23:24, 13 February 2020 (UTC)[reply]

Sudden changes to interface[edit]

Am I the only person going crazy because of the colour change of clicked links?! Before today, every clicked link was displayed in a purplish hue, clearly different from unclicked links. Now it's strikingly similar to an unclicked link making it hard to differentiate. Is this caused by a recent update? Checked all my preferences, but I haven't touched them in ages and I don't have a custom CSS. Also the "Compare selected revision" button is different for us who use the MonoBook skin. How do I change it back to how it was yesterday? --Robbie SWE (talk) 19:22, 13 February 2020 (UTC)[reply]

Nothing's changed for me. This must be an issue with your browser. —Mahāgaja · talk 20:52, 13 February 2020 (UTC)[reply]
That's the thing - it's not. I tried three different browsers. --Robbie SWE (talk) 21:12, 13 February 2020 (UTC)[reply]
I didn't notice a change, but visited and un-visited links do look pretty similar. The easiest way to fix it for yourself is to add to your common.css: a:visited { color: ...; }. I guess it would have to be a MediaWiki-wide change if it wasn't something in your browser, because our local CSS (MediaWiki:Common.css) hasn't been edited recently. I tried searching for "visited" in code changes on Gerrit but didn't spot anything relevant. Unfortunately not many developers visit this page regularly, but I can try posting on IRC. — Eru·tuon 22:05, 13 February 2020 (UTC)[reply]
By any chance would you be able to check an un-visited and a visited link with right click and "Inspect element" and report what the two color values in the CSS are? For me, they're #0645ad and #0b0080 respectively. — Eru·tuon 22:25, 13 February 2020 (UTC)[reply]
Some clicked links have colour #66336c, close to Palatinate purple (#72246c). I think it has something to do with the anchor element having attribute class="extiw".  --Lambiam 22:50, 13 February 2020 (UTC)[reply]
Inspect Element tells me it is #636.  --Lambiam 21:59, 14 February 2020 (UTC)[reply]

@Erutuon, I checked and I have the same colours, i.e. #0645ad (unvisisted) and #0b0080 (visisted). But it wasn't like that earlier this week – I could've sworn that all my visited links were #66336c. That colour is clearly distinct and looks familiar. Is there any way that I can go back to the latter colour? --Robbie SWE (talk) 10:16, 14 February 2020 (UTC)[reply]

@Robbie SWE: I don't remember visited links being so purple recently. To set them to that color, add a:visited { color: #66336c; } to your common.css. — Eru·tuon 10:40, 14 February 2020 (UTC)[reply]
Right, sorry to sound like a noob, but how do I create my own common.css? I know, pathetic not having one, especially as an admin, but I didn't need it until now. --Robbie SWE (talk) 10:46, 14 February 2020 (UTC)[reply]
You just click the link and edit the page like any other. — Eru·tuon 10:59, 14 February 2020 (UTC)[reply]
Ok, I'll give it a go tonight. Thank you for your help! --Robbie SWE (talk) 11:00, 14 February 2020 (UTC)[reply]
@Robbie SWE: 1.) Go to User:Robbie SWE/common.css, 2.) put this line at any point: a:visited {color:#66336c;}, 3.) should work. Let me know if it doesn't. You may need to clear your cache, etc. —Justin (koavf)❤T☮C☺M☯ 11:09, 14 February 2020 (UTC)[reply]
Thanks Koavf! --Robbie SWE (talk) 11:11, 14 February 2020 (UTC)[reply]

Just a tiny follow-up question (@Lambiam) – I followed the advice you guys gave me and created a CSS. It fixed the visited links colour, but now I'm starting to think that the unvisited links colour was also different? The current one just seems too "light" to me. Do you know anything about it and in that case, what is the appropriate CSS code if I want to change it? Tried some different codes myself, but couldn't make it work. --Robbie SWE (talk) 18:33, 16 February 2020 (UTC)[reply]

Make sure you don't make it so dark the difference with plain text becomes hard to see. I think the way to do this is to add a line a:link {color: #002060;} (or whichever colour you prefer – for me this would be too dark). Disclaimer: I haven't tried this out; I have no common.css subpage.  --Lambiam 19:06, 16 February 2020 (UTC)[reply]
Got it! Thank you for all your help! --Robbie SWE (talk) 19:10, 16 February 2020 (UTC)[reply]

Namespace Reconstruction or asterisc[edit]

I was wondering. Was there a technical reason for choosing to use a namespace for Reconrstucted terms (-nós) instead of just an asterisc *-nós? Or perhaps *xxx (Proto...)? Does the asterisc cause problems? Should we avoid it at el.witkionary (just for a few, very few terms) Thank you. sarri.greek (talk) 20:46, 14 February 2020 (UTC)[reply]

The asterisk is potentially ambiguous because we have entries that are not reconstructions that use the symbol (such as *nix). Putting everything in a separate namespace is very explicit. DTLHS (talk) 20:50, 14 February 2020 (UTC)[reply]
Thank you very much @DTLHS. We have some unattested words and did not know if asterisk was harmful. sarri.greek (talk) 21:46, 14 February 2020 (UTC)[reply]

Layout of Pali sara[edit]

Apart form the desirability of adding extra data (e.g. etymology, quotes and more senses), is this entry in a suitable state? I am worried that it may not be clear enough that the declension of etymologies 1 and 2 is different to the declension of etymology 3. How do I stably cross-reference etymologies or words within them? For example, there appear to be another two etymologies to be added - both adjectives and one also a noun. Should I just duplicate the declension table for etymologies 1 and 2, subordinating it to them? --RichardW57 (talk) 12:43, 16 February 2020 (UTC)[reply]

No, it is not. As you note, the declensions must be duplicated to be subordinated to the two etymologies. But there is a further problem: I have no idea what "Alternative interpretation" means, and a standard Wiktionary template should be used instead of plain text. If you mean an inflected form, you should specify which forms using {{inflected form of}}. —Μετάknowledgediscuss/deeds 17:17, 16 February 2020 (UTC)[reply]
It means that some people cite the stem as 'sara' (e.g. the Pali Text Society dictionary) and others as 'saras'. (The latter of course is not a possible Pali word.) The wording implies that some alternative case forms of the 4-letter stem are not consistent with the stem. Would {{form of|pi|alternative citation form|saras|t=lake}} be acceptable? --RichardW57 (talk) 17:59, 16 February 2020 (UTC)[reply]
That would be fine. Pali is of course a bit of an unusual case, but in general, we wouldn't include a citation form that shouldn't exist. —Μετάknowledgediscuss/deeds 18:22, 16 February 2020 (UTC)[reply]
Well, Sanskrit वाच् (vāc, “speech”) isn't a permissible word (as opposed to lemma) either, but I believe it gets written in native grammars. The Pali tradition seems to be more squeamish. --RichardW57 (talk) 04:22, 17 February 2020 (UTC)[reply]

Correct Cyrillic glyphs for Old East Slavic, Old Church Slavic[edit]

Is it even possible to say, which glyphs are correct or it depends on the period? I see some inconsistencies in usage here and other resources, especially for Old East Slavic. So which glyphs are correct, in particular ꙑ vs ы, є vs е. Compare Кꙑѥвъ (Kyjevŭ, “Kiev”) vs сокыра (sokyra, “axe”)? Sometimes one form is a redirect to the other. --Anatoli T. (обсудить/вклад) 11:21, 18 February 2020 (UTC)[reply]

For Old Church Slavonic there is a conventional normalization, described to a decent extent at Appendix:Old Cyrillic script, and we try to adhere to it. Old East Slavic also has a page that describes some proposed conventions (Wiktionary:About Old East Slavic), but because so little work has been done on OES here on Wiktionary, it’s far from set in stone. Personally I’m in favor of ꙑ and е, like we use for OCS. — Vorziblix (talk · contribs) 22:06, 21 February 2020 (UTC)[reply]
@Vorziblix: Thank you for your response. It seems the intentions are good but they are rarely followed and external sources are not helping to maintain it. You get alll sorts of spellings and glyphs! --Anatoli T. (обсудить/вклад) 00:24, 26 February 2020 (UTC)[reply]

Can we put missing senses of existing words at Requested Entries?[edit]

I found a sense of Russian динамо (dinamo) that isn't covered by the existing entry, and I posted it to WT:RE:ru. @Atitarev Atitarev reverted it [1], saying "the entry request page is not for missing senses". Is that true?! I have frequently added words to request pages if there was a missing sense: I felt this was fine as long as you stated the missing sense; I would also mark the word with an asterisk * to indicate that it might not be complete even if it's a blue link. Is that wrong? Where should I post? Equinox ◑ 06:57, 25 February 2020 (UTC)[reply]

I think that's the perfect place for it. "Pie" means a dessert in English and foot in Spanish: if we only had one of those definitions, then we would need the other and there has to be some way to document that. —Justin (koavf)❤T☮C☺M☯ 11:44, 25 February 2020 (UTC)[reply]
But if we already have English and Spanish entries at pie, but they're incomplete, they shouldn't be listed at WT:RE. I would add a new sense line at динамо#Russian with {{rfdef}} and then maybe an example sentence or quotation illustrating the sense you want added, so that other people know what the existing sense isn't sufficient. —Mahāgaja · talk 11:47, 25 February 2020 (UTC)[reply]
I did add an rfdef line to the entry after the above rollback, but I feel as though "unevidenced" rfdefs are very liable to be removed in passing, whereas Requested Entries has a higher barrier to stuff being removed (we even have text at the top saying "don't delete it just because you don't know the word"). Equinox ◑ 14:13, 25 February 2020 (UTC)[reply]
@Equinox: Sorry for not responding earlier. I consider requesting missing senses on any of Category:Requested entries pages incorrect, if it's the same language as the request page. You can discuss the senses at WT:RT or as you did, using {{rfdef|ru}}. I have been looking after WT:RT and some other pages.
I would have added the missing sense when reverting your edit, if I thought it exists. I am actually unfamiliar with the sense you requested, I can't confirm it exists and can't see it anywhere. So, I am disputing its existence. If it can't be confirmed, I will remove your request. If you're sure it exists, please add a topic at WT:RT and quote some examples. It seems very individual and rare and I oppose the addition at present. If the sense DOES exist, it should be added as animate. --Anatoli T. (обсудить/вклад) 00:22, 26 February 2020 (UTC)[reply]
I have no objection to a request being removed if the word doesn't exist. But I think we should allow requests for words sensu lato. That is, we should read the page as "requested senses", not "requested entries". This is because senses may be totally unrelated to entries. Suppose that someone requests the word unionized (meaning "not ionized"), and then a day later an editor creates the page for a totally different meaning (past tense of "unionize"). Will you then delete the legitimate and unfulfilled request purely because in a robotic sense "the page now exists"? That doesn't help anyone. Equinox ◑ 07:18, 1 March 2020 (UTC)[reply]
I agree with Equinox. Requested senses should only be removed from the requested entries page if they are clearly covered by an existing sense, not anytime the entry exists. Andrew Sheedy (talk) 22:01, 1 March 2020 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Information_desk/2020/February&oldid=65118334"