Wiktionary:Grease pit/2019/July

隨便 shows only five other languages (Français, 한국어, Magyar, Malagasy, 日本語) to me. Chinese is notably missing. Over there, zh:隨便 shows two extra, ᏣᎳᎩ and Українська. Is this limited by some settings, or is the sidebar malfunctioning?--Roy17 (talk) 11:12, 1 July 2019 (UTC)

@Roy17: 隨便 is the traditional form. 随便 is its simplified form (it looks somewhat similar but the first character is different), which has all the interwiki links you're missing. The traditional form of 隨便／随便 (suíbiàn) (the first part) is not linked directly to the the Chinese Wiktionary but it has a redirect. --Anatoli T. ^{(обсудить}/^вклад) 14:04, 1 July 2019 (UTC)

@Atitarev: Thanks a lot! Now I realise it's not a redirect by the command # redirect ... though. It's some special automatic simp-trad conversion they have in place. Even though the trad form is not created yet, it would show the simp form. When I was not redirected the usual way I failed to notice I was looking at the simp form. Case closed.--Roy17 (talk) 14:14, 1 July 2019 (UTC)

And your filters prevent me from explaining.--Roy17 (talk) 14:14, 1 July 2019 (UTC)

You're welcome. Not sure what filters you mean. It's some kind of web redirect in the Chinese Wiktionary, not a page redirect. --Anatoli T. ^{(обсудить}/^вклад) 14:20, 1 July 2019 (UTC)

I created the neologism snaughle, and it's categorising under 'English 1-syllable words'. Not sure why. Leasnam (talk) 05:00, 4 July 2019 (UTC)

I added schwas in and the problem disappeared. So it looks like vocalic nuclei are the determiners for syllable categorization. I didn't try just adding a syllable boundary to see if that would work as well, or a syllabic diacritic to the /l/'s, but you could try that as well, if you prefer. Andrew Sheedy (talk) 06:14, 5 July 2019 (UTC)

@Leasnam, Andrew Sheedy: Module:syllables counts the syllables. The reason it wasn't counting the l as a second syllable was that it didn't have a diacritic indicating that it was syllabic. The module doesn't look at syllable dividers so that has no effect. — Eru·tuon 19:40, 5 July 2019 (UTC)

Thanks Andrew Sheedy and Erutuon ! Leasnam (talk) 20:10, 5 July 2019 (UTC)

@Erutuon, Leasnam: if you wish to indicate that the schwa is optional, you could indicate /ˈsnɑːf(ə)l/, which would also cause the module to count the word has having two syllables. Aslo, as far as I am aware, if a full stop is used as a syllable marker, this is noted by the module. — SGconlaw (talk) 18:27, 10 July 2019 (UTC)

@Sgconlaw: What I meant by "syllable dividers" above was full stops or periods. Module:syllables doesn't pay attention to them when counting the number of syllables. — Eru·tuon 21:38, 10 July 2019 (UTC)

@Erutuon: that's odd. As far as I'm aware, /iə/ is treated as one syllable, while /i.ə/ is treated as two, suggesting that the full stop is effective as a syllable marker. — SGconlaw (talk) 03:29, 11 July 2019 (UTC)

Oh, that's right. That's because /iə/ is treated as a diphthong (a New Zealand diphthong). But any character will serve to break it up; the syllable break isn't special here, but just happens to be the correct character to use. — Eru·tuon 14:41, 11 July 2019 (UTC)

My wording probably suggested that the module removes syllable breaks when calculating the number of syllables; it does not. But they are treated like any other character. — Eru·tuon 14:45, 11 July 2019 (UTC)

Oh, I see! — SGconlaw (talk) 15:44, 11 July 2019 (UTC)

Doesn't l̥ (l dotted below) also create an additional syllable ? e.g. /ˈsnɑːfl̥/ ? Leasnam (talk) 02:34, 11 July 2019 (UTC)

The ring is the syllabicity diacritic in Proto-Indo-European, but in the IPA, the correct character is a vertical line below: /ˈsnɑːfl̩/. — Eru·tuon 14:41, 11 July 2019 (UTC)

When I look up Afrikaans aalwyn, I see a link to https://af.wiktionary.orghttps://dictious.com/en/aalwyn under “In other languages”. But when I look up Afrikaans aandag, I only see a message “Wiktionary does not yet have an entry for aandag.” There are no language links, even though the entry https://af.wiktionary.orghttps://dictious.com/en/aandag exists. Would it be possible to also make links to existing pages on other-language wiktionaries visible for pages that are missing hedre?  --Lambiam 11:40, 9 July 2019 (UTC)

This has to do with the Cognate extension. I don't know exactly how the extension works in relation to uncreated pages, but as soon as I preview an uncreated page, the interwiki links show up. Maybe the developers could add the feature of showing interwikis on uncreated pages if someone requested it on Phabricator. — Eru·tuon 16:27, 9 July 2019 (UTC)

Thanks. For now using preview is good enough for me.  --Lambiam 20:31, 9 July 2019 (UTC)

The url parameter of {{cite-web}} is used to attach an external link to the rendering of the work parameter, also when a title is present. But in most cases, the link goes to one of many pages is the work identified, one that has that title, so in such cases it would be better to attach the link to the title.

Example:

• code:

  {{cite-web|title=Aardvark|url=https://eol.org/pages/327830|work=Encyclopedia of Life|year=no year}}

• rendering:

  “Aardvark”, in Encyclopedia of Life‎, no year

I have not looked at the situation for other templates with a url parameter.  --Lambiam 20:58, 9 July 2019 (UTC)

@Lambiam: if, in a particular case, you feel that the URL is better linked to the title, use |titleurl= instead of |url=. This is explained in the documentation. — SGconlaw (talk) 18:22, 10 July 2019 (UTC)

An IP has been adding "Jurchen script" to a number of Jurchen entries that seems to be in one of the Unicode Private Use Areas. Is there any reason not to revert the lot? How do we know what characters site visitors will see, since AFAIK the glyphs displayed are entirely dependent on which version of which font is installed on a given system? Or is there some way to force use of a font that has the correct glyphs in the correct range? Chuck Entz (talk) 05:51, 10 July 2019 (UTC)

As I told in Category talk:Jurchen script, and PUA's appearance is different among users, so it should not be included at the moment. --Octahedron80 (talk) 06:21, 10 July 2019 (UTC)

Can someone who knows modules please edit template:m so that it has a parameter for a non-gloss definition? For example, {{m|he|א־ג־ר|tr=ʾ-g-r||forming words relating to ]ing and ]}} should display not “forming words relating to hoarding and storing” as it does now but forming words relating to hoarding and storing or even the same unitalicized.​—msh210℠ (talk) 14:36, 10 July 2019 (UTC)

Even though it's not optimal, you can use the |pos= parameter for that. I remember briefly discussing this with @Erutuon and @Sgconlaw on the talk page of a recent Word of the Day, but I can't remember which. Canonicalization (talk) 14:47, 10 July 2019 (UTC)

Yes, I have been using |pos=''non-gloss definition'' where required. — SGconlaw (talk) 16:08, 10 July 2019 (UTC)

I use it without italics: |pos=non-gloss definition. — Eru·tuon 16:10, 10 July 2019 (UTC)

I've been adding italics to match the formatting of {{non-gloss definition}}. — SGconlaw (talk) 18:19, 10 July 2019 (UTC)

But that template doesn't include '' in its output: {{n-g|foo}} → <span class="use-with-mention">foo</span>. —Rua (mew) 21:31, 11 July 2019 (UTC)

I’m not following. Clarify? — SGconlaw (talk) 02:10, 12 July 2019 (UTC)

I think she's pointing out that what you are inserting into the |pos= parameter (italicized text) is actually different from the HTML that {{n-g}} generates (<span class="use-with-mention">foo</span>), even though it usually looks the same. — Eru·tuon 21:35, 13 July 2019 (UTC)

I see, thanks. In that case, should we add a non-gloss parameter to {{m}} (and related templates) with the correct markup? — SGconlaw (talk) 06:28, 14 July 2019 (UTC)

Great, thanks.​—msh210℠ (talk) 21:32, 13 July 2019 (UTC)

On the page, the ablaut is given by the inflection table as *ḱl̥néwti ~ *ḱln̥wénti. But this is incorrect; the nasal infix is never syllabic, and it's the l that should be vocalised instead. The parameters are correctly given in the wikicode, so something is messing it up on the way out. —Rua (mew) 21:48, 12 July 2019 (UTC)

Thank you for your time. About week or two ago, I think we got very very close to including the Tongyong Pinyin Mandarin Chinese romanization system in the list of Mandarin Chinese romanizations that appear in Template:zh-pron. Here is the progress we made: . When I unsuccessfully tried to incorporate this romanization system into zh-pron , it caused a failure of the module: "Lua error in Module:cmn-pron at line 1150: wrong number of arguments to 'insert'". Yes, I do need to learn to code, but I haven't done so- I'm incapable of making any more progress in this area because I don't know how Lua works or why this error appeared. My request for including Tongyong Pinyin has been logged at Wiktionary:About_Chinese/tasks, but because the Tongyong Pinyin romanization system is intensely frowned upon by the Hanyu Pinyin-only fanatics among Mandarin Chinese users, it is difficult to convince others of the necessity of adding this romanization system to Wiktionary and my request will fall on deaf ears until such time as a rationale can be found to delete my request. To me, this is not a question of whether or not Tongyong Pinyin is helpful, harmful, good, bad, important, dangerous, economical, time-wasting etc etc. I'm merely trying to provide the readers of the dictionary with information they may need if they visit somewhere like Kaohsiung or Tamsui, where the Tongyong Pinyin system is seen on street signs and websites. Despite the relentless pestering, nagging and naysaying of the anti-Tongyong Pinyin people, the Tongyong Pinyin system is in current use in the Republic of China (Taiwan) (albeit on a limited scale and not by the central government). Tongyong Pinyin can be found in Mandarin Chinese language teaching materials currently in use. The small amount of usage that Tongyong Pinyin sees in modern Taiwan is way more than the Gwoyeu Romatzyh ever saw (as far as I'm aware), but Wiktionary includes Gwoyeu Romatzyh in zh-pron. That's a good thing. It makes this website more useful and more fun. As far as I am aware, the influential Chinese-langauge editors on Wiktionary may never be interested in helping me add Tongyong Pinyin to Wiktionary, so I may need assistance from someone who does not normally do editing of Chinese language topics. I have made similar requests about multi-syllable Wade-Giles in the past that have never come to fruition because Hanyu Pinyin is considered to the be the de-facto Chinese- who needs to see Wade-Giles anymore? (Answer: people who read books, the type of person that would use Wiktionary.) Of course, everyone knows about Hanyu Pinyin. I use it all the time. I know the official Mainland China rules of Hanyu Pinyin better than most do. But the Hanyu Pinyin-only mindset is too limiting to express the historical relationship between Mandarin Chinese and English. The more minor romanization systems are out there being used. They are used in people's names. A good editor who I admire wrote: "We don't need to contextualize Hanyu Pinyin, because it is the standard that people have come to expect. It is the de-facto "Chinese", and has clear prestige over other forms of Chinese." I can't agree with this view, and neither do the all the people in Taiwan. For instance, the default translation of Mandarin Chinese personal names into English in Taiwan is Wade-Giles (at least at the place I went to translate documents). It is true that Hanyu Pinyin is overwhelmingly important, OF COURSE! Hanyu Pinyin is much more important than Tongyong Pinyin ever was or ever could be. 當然! But that doesn't mean Tongyong Pinyin should be ignored or intentionally maligned. We need to be respectful of the people who are using this system and respectful of the history of Taiwan. Anti-Tongyong Pinyin bias is found throughout Wikipedia too: see my edits to Tongyong Pinyin where I have been trying to "de-propaganda". This request has nothing to do with the fact that Hanyu Pinyin is the official romanization for Mandarin Chinese at the United Nations, the People's Republic of China and the central government of the Republic of China (Taiwan). None of that matters. What matters is that people are using this system in real life, and Wiktionary has the capability to incorporate information about this romanization system just like it does for the Gwoyeu Romatzyh and Wade-Giles romanization systems. Tongyong Pinyin was the official transliteration system of the central government of Taiwan for about six years in the 2000's. I believe I have made a conclusive case that Tongyong Pinyin must be included on this website at some point, and I would appreciate your technical assistance in making this possible. All I'm asking for is inclusiveness, fairness and informativeness. In this wretched age of the wide-scale destruction and intentional suppression of the minor languages and cultures of our world, let Wiktionary reflect the existence of the minority. Tonyong Pinyin is reflected in the names of English langauge Wikipedia articles like List of cities in Taiwan, Cijin District, Kaohsiung and redirects like etc. Get the boot of Hanyu Pinyin-only off our necks. Hanyu Pinyin is definitely a great thing, but Tongyong Pinyin exists too. Thanks for reading my magnum opus. --Geographyinitiative (talk) 01:17, 13 July 2019 (UTC)

"he influential Chinese-langauge editors on Wiktionary may never be interested in helping me add Tongyong Pinyin to Wiktionary": that's a bit unfair because @justinrleung got the tongyong pinyin function working. It's now a simpler matter to add it to {{zh-pron}}. — Eru·tuon 01:33, 13 July 2019 (UTC)

Added Tongyong Pinyin to the hidden part of the {{zh-pron}} table using your previous edit. — Eru·tuon 01:42, 13 July 2019 (UTC)

I deeply believe that there's nothing our world needs more right now than a good dictionary, and that is why I am fighting for it. The fact that the Wiktionary page for Cijin can exist as it does at this time proves to me beyond a shadow of a doubt that little Wiktionary is primed to become the best dictionary in human history. We are being respectful and mindful of the choices of the people of that area concerning proper romanization of their district's name, more so than the USA government National Geospatial Agency's GEOnet Names Server, more so than Google Maps, and more than the non-English Wikipedias. We must understand that Hanyu Pinyin is of course vitally important, but at the same time we must realize that to ignore Tongyong Pinyin can only be called evil. I apologize for cracking skulls and being generally unruly, but the time has come for humanity to finally have a real dictionary. I, for my part, have had enough with the half-truths and lies that have smothered the promise of humanity in the cradle. You are all great people, and I'm proud to be among you (at least until I get kicked out of here!) and I'm sorry for anything I have said that offends: I'm just speaking the truth as I see it in the moment, and I will change my opinion according to the facts as I understand them. Please understand that I will make mistakes that are based on my biases and foolishness, and I hope you will not hold your punches- we must have a good dictionary in our time. --Geographyinitiative (talk) 17:52, 13 July 2019 (UTC)

Thanks, @Erutuon. @Geographyinitiative:, I can understand your passion to have everything represented, but I hope you could learn to be a little more patient. I was a little busy last week and it was my fault for kind of forgetting about it. There were still some edge cases to work out, like how we should deal with hyphens and apostrophes; that's why I haven't put it into the table for display yet. The sources I've looked at have been contradicting with regards to these issues, so if you have any input, that'd be great. — justin(r)leung _{{ (t...) | c=› }} 18:49, 13 July 2019 (UTC)

{edit conflict) I can think of lots of things our world needs more than any dictionary. It seems like you're getting too caught up in the drama of it all. You're also mistaking quantity for quality. Just as no one is going to take the time to read the walls of text you just added, no one wants to wade through tons of trivia to find the basic stuff they're looking for. It's okay to have extra details, but things need to be organized so they don't get in the way of the more important ones. It does no good to be the most extensive and thorough reference in history if no one can use it. Chuck Entz (talk) 19:00, 13 July 2019 (UTC)

When I visited the Wictionary via a proxy the sound simply did not play. When I went directly the sound did play, but the play-button and the menu-button looked completely different. Is this intentional? I think: there should not be any difference whether via a proxy or not. --Steue (talk) 04:05, 14 July 2019 (UTC)

Category:Horse gaits, Category:Horse racing and Category:Horse tack should be subcategories of Category:Horses. Categories are too complicated for me --Gibraltar Rocks (talk) 21:16, 14 July 2019 (UTC)

The problem is that our categories are divided into topics and sets, with topics containing terms about or connected with something, while sets are names for it, and we only have one really good category name. Horse racing and horse tack are horse topics, while purebred and racehorse are part of the set of horses. The problem with Category:Equestrianism is that the name doesn't cover things like whinny and horsemeat very well. It's also much harder to remember, so there's lots of stuff in Category:en:Horses that, strictly speaking, doesn't belong in a set category. Chuck Entz (talk) 22:10, 14 July 2019 (UTC)

Maybe Category:Equestrianism should be Category:Horsemanship because it’s easier to find an to understand. I don’t see why “whinny” should be in anything but “Animal sounds”, only that we could subdivide the animal sounds if there is enough entries. “Horsemeat” could go into a Category:Animal husbandry (I think Fleischzucht) as opposed to the crop-cultivation parts of agriculture (which I don’t know to name distinctly yet). There is also an economic sector keeping animals to produce fur that needs a name. “Trapping” we have already, which I was kinda surprised to see ignored and created a year ago since it is a big business in the USA. In such areas the dictionary still awaits expansion. Fay Freak (talk) 22:20, 16 July 2019 (UTC)

• I'm gonna do manual categorization for those categories, and hope someone techy will fix it. --Gibraltar Rocks (talk) 20:59, 18 July 2019 (UTC)
  • @Gibraltar Rocks Please don't. That only increases the work other editors have to do further down the line. —Rua (mew) 17:20, 20 July 2019 (UTC)
    • I did it anyway. --Gibraltar Rocks (talk) 19:22, 28 July 2019 (UTC)

@Rua and anyone else who's good at this sort of thing: At CAT:grc:Cities, Αἶνος (Aînos) is not sorting where it should be. It's at the end of the Α section instead of sorting as Αινος. The entry itself is using {{C}}, and I can't figure out what needs to be changed at Module:languages/data3/g to strip all the diacritics off the ι. Any ideas? —Mahāgaja · talk 21:17, 16 July 2019 (UTC)

@Mahagaja: Figured it out. The sort_key replacements were removing the wrong character ( ̂ U+0302 COMBINING CIRCUMFLEX ACCENT, which is not used in Greek, rather than ͂ U+0342 COMBINING GREEK PERISPOMENI). I didn't notice this when I converted them to the new format. — Eru·tuon 21:36, 16 July 2019 (UTC)

Why aren't categories like these clearing out entries that do have plurals? Just going through the first entries I've noticed that some have had plurals for several months. Ultimateria (talk) 16:31, 20 July 2019 (UTC)

@Ultimateria: The server has to regenerate the lemma entries in order to remove them from the category, and it doesn't do that immediately after the plural entry has been created. I guess regeneration of pages has been slow because of edits to much-transcluded pages, such as the language data modules and Latin inflection modules such as Module:la-verb. I ran touch.py to perform a null edit on most of the entries in the category, and it started with 642 members, but is now at 481. — Eru·tuon 17:53, 20 July 2019 (UTC)

It means you're editing too quickly. Slow down and take a holiday. They should have caught up by the time you're back. --Gibraltar Rocks (talk) 11:22, 28 July 2019 (UTC)

There seems to be something odd with Category:Ancient Greek terms spelled with Ͷ (see wanted categories) and Category:Ancient Greek terms spelled with ͷ oscillating back and forth. DTLHS (talk) 17:01, 22 July 2019 (UTC)

Similarly, for the past few weeks Egyptian entries staring with ꜣ and ꜥ have been oscillating between being categorized under capitalized and uncapitalized versions of those letters. I imagine the same problem is behind both phenomena. — Vorziblix (talk · contribs) 21:01, 22 July 2019 (UTC)

The relevant code from Module:headword is here:

-- Categorise for unusual characters
local standard = data.lang:getStandardCharacters()

if standard then
	if mw.ustring.len(title.subpageText) ~= 1 and not mw.ustring.match(title.text, "^Unsupported titles/") then
		for character in mw.ustring.gmatch(title.subpageText, "()") do
			local upper = mw.ustring.upper(character)
			if not mw.ustring.find(upper, "") then
				character = upper
			end
			table.insert(
				data.categories,
				data.lang:getCanonicalName() .. " terms spelled with " .. character
			)
		end
	end
end

For those who can't read Lua code, if a character in the subpage text is not a standard character (that is, not found in the language's standardChars pattern, which for Ancient Greek is "ͺ;΄-ώϜϝ" .. PUNCTUATION .. "ἀ-῾𐠀-𐠿"), the entry is put in a category containing the uppercase version of the character if the uppercase is also not a standard character, otherwise the lowercase version.

I can't see any cause for the oscillation if the PHP library that ultimately handles uppercasing is functioning correctly; neither the standardChars field nor the code adding these categories nor the casemappings for these characters have changed. And I suppose something must also be happening on the PHP side to cause Egyptian entries to alternately sort under the uppercase and lowercase versions of a letter. I thought category headers were always uppercase. — Eru·tuon 22:39, 22 July 2019 (UTC)

I've encountered this error again, with Category:Latin terms spelled with ꝑ. The category name should be Category:Latin terms spelled with Ꝑ, but is not because mw.ustring.upper("ꝑ") is not returning "Ꝑ"). — Eru·tuon 15:24, 27 July 2019 (UTC)

I've posted about this in Phabricator. — Eru·tuon 15:51, 27 July 2019 (UTC)

@Vorziblix The Phabricator response indicates that the upgrade to PHP 7 is responsible- at the moment requests may be served with different PHP versions which have different Unicode behavior. Presumably it will eventually be stable. DTLHS (talk) 18:45, 15 August 2019 (UTC)

Thanks for the ping! It’s good to know what’s going on. — Vorziblix (talk · contribs) 00:35, 18 August 2019 (UTC)

It turns out that till now English Wiktionary has been unwittingly using Unicode 3.2, from 2002 before the characters in question were added to Unicode. I guess nobody's noticed before now because the more common cased characters were added in early versions of Unicode. For instance, most Greek letters (though not ͷ) were added in Unicode 1.1. The newer characters don't come up in our modules and category headers very often. — Eru·tuon 19:57, 19 August 2019 (UTC)

It looks like the letters are finally being uppercased consistently and the PHP 7 tag has been removed, resulting in module errors in the categories with lowercase letters, so I marked them for deletion. (This testcase is outputting nothing; it will print the letters if they aren't being uppercased.) Hopefully I'm not jumping the gun. — Eru·tuon 00:02, 8 September 2019 (UTC)

@Erutuon It is not stable yet- Category:German terms spelled with ꝛ. DTLHS (talk) 16:13, 10 September 2019 (UTC)

O please! (from el.wiktionary, where all Lua editors are gone), can somebody help?
How can i make this

args = "<br />& " .. stem] .. Lf( args)

that is args = "<br />& " .. stem] .. Lf(args)

to be linked like this:

args = "<br />& " .. LINKTHISstem] .. Lf( args)UNLINK

I have tried .. "[[" .. but of course it does not work...
Is there a place for Lua-support? Perhaps request help at https://meta.wikimedia.org/ ? But i did not find a lua-support-desk there sarri.greek (talk) 09:32, 24 July 2019 (UTC)

@Sarri.greek: I think English Wikipedia has quite a few active Lua editors, so Wikipedia:Lua is a good place to post. However, in this case, args = "<br />& ] .. Lf( args) .. "]]" does what you want, if I'm understanding correctly. — Eru·tuon 16:28, 24 July 2019 (UTC)

If you are doing a lot of linking, it might be more readable to define a function local function create_link(word) return "]" end and do args = "<br />& " .. create_link(stem] .. Lf( args)). — Eru·tuon 16:31, 24 July 2019 (UTC)

Dear @Erutuon, thanks -it does not work, I cannot link things which start with args. But never mind. I' ll try your second advice-. You always help me!. Your previous help with the module for affixes is a great success! THANKS. sarri.greek (talk) 16:36, 24 July 2019 (UTC)

What is the error message? I can't tell where you are using this code. — Eru·tuon 16:38, 24 July 2019 (UTC)

Oh, I found el:Module:el-nouns-decl. — Eru·tuon 16:48, 24 July 2019 (UTC)

@Erutuon, I love you! OK: I will study now, what you have done, and try to apply. sarri.greek (talk) 16:59, 24 July 2019 (UTC)

A brand-new account tampered with {{character info/new}}, which means that there are currently thousands of single-character entries cluttering up the category. I would appreciate it if someone with a bot could do null edits on all the single-character entries in CAT:E so that we can see the real module errors. They've been clearing up a few hundred at a time here and there, but it would be nice to give it a bit of a push. Thanks! Chuck Entz (talk) 02:06, 26 July 2019 (UTC)

I'll run touch.py on the category (doesn't require a bot account). — Eru·tuon 02:14, 26 July 2019 (UTC)

Looks good. Thanks! Chuck Entz (talk) 03:16, 26 July 2019 (UTC)

As an example, after using the special codes for Greek dialects in etymology sections, like because Latin clāthrī is from Doric Greek, one creates the categories “LANGUAGENAME terms derived from Doric Greek”, “Terms derived from Doric Greek”, and then, so the category is not orphaned, creates Category:Doric Greek with {{dialectboiler|grc|Western Greece}} or the like, and so with the other dialects, to categorize into Category:Regional Ancient Greek, on the model of anything in Category:Regionalisms, like Category:Egyptian Arabic ends up in Category:Regional Arabic, Category:Istanbul Armenian ends up in Category:Regional Armenian, for example. Now I just have noticed the opposition to Category:Ancient Greek dialects which contains categories for all Ancient Greek dialects already that contain Ancient Greek lemmas containing regionalisms, as well as Greek of specific times (Byzantine Greek, Koine Greek etc.), these categories being sorted in Category:Ancient Greek language. I think I do not err if I aver that the current state of the categories is too byzantine and it would make sense not to have this duplication but Category:Doric Greek and Category:Doric Ancient Greek should be united, and probably under Category:Regionalisms for the dialects, while the chronolects should get their own categories: so we don’t have “Classical Latin”, “Medieval Latin”, “New Latin”, “Post-classical Latin”, ”Renaissance Latin” right in Category:Latin language. And I see potential for a “sociolects” category as we have Category:Vulgar Latin and the like. That’s the observation I wanted to share. What you do with this insight or how the category names should be cleaned up is up to you. I ping particularly @Erutuon as he holds stakes in the Greek dialects system. Fay Freak (talk) 13:56, 26 July 2019 (UTC)

Yes, the categories should be "x Greek" instead of "x Ancient Greek", which is clunky and unnatural. In most cases the clunky categories are added by labels in Module:labels/data/subvarieties, so moving all the entries is easy.

Not all of them are lemmas, unfortunately. For instance, in Category:Epic Ancient Greek (which should be Category:Epic Greek) ἄνεμος (ánemos) is a lemma, while ἀνέμοιο (anémoio) is an inflected form. The dialectal categories would be more useful if they were divided into lemmas and non-lemma forms, but that's not a simple task.

"Regionalism" is an inaccurate label for the some of the Ancient Greek dialects; for instance, Epic Greek was a literary mishmash of several dialects used by people in various regions and Koine Greek was pan-regional. It's most accurate for lects that weren't used in literature written outside of their native land, like Boeotian. But all of the dialectal categories could maybe still be temporarily placed in Category:Regional Ancient Greek if there isn't another name for a category for non-regional lects yet. — Eru·tuon 18:37, 26 July 2019 (UTC)

I think the core problem is that we're stuck on geographic variation, when any distance, whether temporal, spatial or social, causes variation. We need to categorize based on variation itself, with geographical varieties as one subtype, along with historical and social varieties. Maybe the parent category should be "XX Language varieties". As for subdividing, it get's complicated: RP and AAVE are both regional and social in nature, and there are definite social perceptions attached to many regional varieties. Historical varieties are often linked to social changes, and to geographical factors. The Wessex dialect tended to dominate Old English, but Modern English is more Midlands-based, as one example. Chuck Entz (talk) 01:43, 27 July 2019 (UTC)

Can a user merge two accounts, and combine the edits, and keep only one of the logins? Or, if not, how would they delete/destroy one account, and leave only their second account for logging in? Please see User_talk:Scottmacstravic who IMO might be a bit confused about his account status but really just needs and wants one. Equinox ◑ 17:04, 27 July 2019 (UTC)

Not entirely sure of the answers to your questions, but see "meta:Changing username" and "meta:Steward requests/Username changes#Requests involving merges, usurps or other complications". Locally, I think a Wiktionary administrator could just block the account that Scott no longer wishes to use, but a request will have to be made at Meta if the blocking is to apply across all Wikimedia projects. — SGconlaw (talk) 17:28, 27 July 2019 (UTC)

Can we allow ===Logogram=== as a valid heading in WT:ELE? --Gibraltar Rocks (talk) 11:20, 28 July 2019 (UTC)

@Gibraltar Rocks: What were you thinking of using it for? For some (e.g. & at and) they already exist in the synonyms section, which seems fine to me. - TheDaveRoss 12:30, 29 July 2019 (UTC)

Hi GPers. When using this page to make this page, I get the error message "Lua error in Module:quote at line 170: Only one of date= or year= should be specified". As is well-documented, I don't do templates, categories, or modules anymore as they got overcomplicated. I reckon this error message comes up because of Template:quote-journal, perhaps that template assumes that an entry must have a year, what do I know? As I didn't know how to fix it, I asked someone else to do so and have carried on making entries even though they have module errors. --Gibraltar Rocks (talk) 19:12, 28 July 2019 (UTC)

@Gibraltar Rocks: {{quote-journal}} just wants the parameter |date=, without |year=. |date= lets you put in the year, month, and day of the month, |year= takes the year. If both parameters are provided, {{quote-journal}} emits an error message because it doesn't need both. I think no further action is needed because User:DTLHS has removed the |year= parameter from the preload template that you used in suborganismo, so using the template doesn't trigger the error message anymore. — Eru·tuon 19:53, 28 July 2019 (UTC)

Yes, good. I love DTLHS --Gibraltar Rocks (talk) 23:05, 28 July 2019 (UTC)

I am looking for someone who can help me to construct/make Template:ms-pron for Malay pronunciation. I planned make similar to Template:zh-pron style. But, it more simple and slightly different. NB: i don't know everything about programming. Rex Aurorum (talk) 11:20, 29 July 2019 (UTC)