Wiktionary:Grease pit/2020/May

Regen WTconcord[edit]

Back in the day, User:RJFJR/WTconcord was created, a concordance of all the undefined words used in en.wiktionary. The logic was "Since Wiktionary is a dictionary it should define all the words it uses...". It'd be interesting to see a new version of this list, perhaps we're missing lots of good stuff. contrib, Routledge, gender-specific and encyc are just a few of those on the list from 2007 that were missing an entry. --Elvinrust (talk) 01:02, 2 May 2020 (UTC)[reply]

IPs adding a newline between see-alsos and first header[edit]

e.g. here [1]. Not sure why, but anons/IPs seem to do this fairly regularly. It goes against the established style rules and seems like something we could reliably block with a Special:AbuseFilter, if anyone feels like working out the correct regex. Equinox ◑ 02:49, 2 May 2020 (UTC)[reply]

@Equinox: I created filter 115 to check for a blank line before the first heading. At the moment it's in the testing phase. The first 7 matches to the filter have the blank line in the new wikitext; further matches will have the blank line in the new wikitext but not in the old wikitext, the condition that should be blocked. I'm a little concerned that it uses the new_wikitext and old_wikitext variables, which can be large, but maybe it won't be terribly inefficient because the regex only matches at the beginning of the string. There's no way to check for this using added_lines. — Eru·tuon 06:01, 2 May 2020 (UTC)[reply]

Just a thought: if the size of the wikitext can be a problem in general, possibly we could convince them to add numeric variables that contain the wikitext lengths? Then (assuming the AND and OR operators are short-circuiting) we could always skip a non-essential abuse filter if it was going to be painfully long. Equinox ◑ 09:50, 2 May 2020 (UTC)[reply]

It's not actually the size of the wikitext so much as having to fetch it from a different part of the database. The abuse filters stop evaluating things as soon as they determine that the entry has failed, so, in general, it's best to eliminate as many entries as possible use non-expensive tests, then use the expensive tests.

In this case, you can access less-expensive variables to get things such as the edit delta and the added lines without using up as many conditions. By definition, one of these edits would consist of nothing but empty added lines and have a very small edit delta, so check for that first.

Why would you care about this at all? This would be incredibly annoying to get blocked for. -1. DTLHS (talk) 16:08, 2 May 2020 (UTC)[reply]

Abuse filters don't block. They prevent the edit. There can be an explanatory message, e.g. link to appropriate paragraph of style guide. Also note the IPs I refer to make no other edit to the article except adding the newline; it's quite common. Equinox ◑ 17:27, 2 May 2020 (UTC)[reply]

Yeah, I would definitely add a warning message. But should the filter check that the only change is the addition of the blank line? Based on the abuse filter log, a few long-time editors like User:Julia and User:Apisite sometimes put a blank line below when adding {{also}}. I'm inclined to do this now that I look at the filter matches. Blocking an edit or even just displaying a warning message seems extreme when the edit is more than just adding the blank line. — Eru·tuon 18:23, 2 May 2020 (UTC)[reply]

I wonder if there's something about the mobile interface that allows someone reading the entry to go into edit mode and add an empty line without realizing it. I would note that this is always added at the end of the first line- perhaps the IP thinks that they're scrolling down a line rather than adding one. This may be just part of the problem we've had in recent years of millions of clueless new mobile users with poor English comprehension in places like South Asia, the Middle East, Africa, and Latin America. Chuck Entz (talk) 19:09, 2 May 2020 (UTC)[reply]

Unami diacritics do not link properly.[edit]

I do not know why this is the case, but it appears that someone edited a template which strips diacritics from Unami words. Diacritics are necessary to distinguish words in Unami, and therefore I really believe that they should be able to link properly. The Unami alphabet is as follows [a,à,ch,e,è,ë,h,i,ì,k,l,m,n,o,ò,p,s, sh,t,u,ù,w,x,y], which means that the characters [à, è, ë, ì, ò, ù] need to be able to link properly. Please help!

Are the diacritics used in normal Unami writing (books, newspapers, websites) intended for native speakers? Or are they only used in pedagogical works for learners? —Mahāgaja · talk 17:15, 3 May 2020 (UTC)[reply]

Diacritics are used in normal writing. It is noteworthy however, to mention that Unami is a moribund language, and diacritics are not universal, yet they are the norm. more than one orthography is sometimes used, as there have been a few phonetic systems developed since the 1920's to ease with spelling. Currently most speakers use diacritics, but some do not, or alternate, preferring older spellings for some words, and the newer one for others. There has been some confusion on wiktionary, as some editors have added entries using technical linguistic orthography using IPA notation (which would be incomprehensible to speakers). This could potentially be why the diacritics were disabled. Hk5183 (talk) 18:25, 3 May 2020 (UTC)[reply]

@Hk5183 I disabled diacritic stripping for Unami. Benwing2 (talk) 19:03, 3 May 2020 (UTC)[reply]

Thank you! Hk5183 (talk) 19:22, 3 May 2020 (UTC)[reply]

Cmd-F is totally broken in module editing[edit]

Anyone else notice this? I'm on a Mac, and as of recently, Cmd-F no longer works for searching within the edit box of a module. Formerly, it would bring up a separate Find box within the editing area and you could search for text within the module, now you can only search for whatever happens to be on the current HTML page, which is only a small sliver of the module text. It makes it very hard to edit modules. Benwing2 (talk) 19:00, 3 May 2020 (UTC)[reply]

@Benwing2: Yes, I've encountered this in Linux in Firefox. It seems to be related to phab:T251545. It is really annoying because I normally constantly use the search and replace box while editing code. Have to page down and search manually or copy the code to an editor. Unfortunately the task doesn't seem to be receiving much attention. — Eru·tuon 19:06, 3 May 2020 (UTC)[reply]

@Benwing2: Fixed for me now, at the same time that the monospace font has returned to diffs (for those whose edit box font is monospace). — Eru·tuon 19:00, 5 May 2020 (UTC)[reply]

Genitives with colons[edit]

This might not be the best place for this issue, but today I noticed that links to some genitive forms containing colons (such as SD:s from the Swedish SD) become interwikis instead (in this case, to the Sindhi Wiktionary). How do we resolve this? Glades12 (talk) 18:46, 5 May 2020 (UTC)[reply]

Thanks for the answer. Glades12 (talk) 19:12, 5 May 2020 (UTC)[reply]

<ref> tag but no <references/> tag![edit]

Warning: You're trying to save page with a <ref> tag but no <references/> tag! This action has been automatically identified as likely in error. If you believe this edit to be correct, you may click "Save page" again to confirm it. Otherwise, please fix it and then click "Save page".

If you received this message in error, please report it at the Wiktionary:Grease pit.

I have {{reflist}}, isn't that good enough? Alexis Jazz (talk) 15:33, 6 May 2020 (UTC)[reply]

The filter you triggered doesn't check for {{reflist}}. Fixed. — Eru·tuon 18:38, 6 May 2020 (UTC)[reply]

Reflexive verbs with Ukrainian conjugation templates[edit]

Current Ukrainian verb conjugation templates. e.g. {{uk-conj-table}} don't support reflexive verbs at all. this revision is a disaster. The problem is with alternative future forms for imperfective verbs (a feature unique to Ukrainian verbs), which uses {{{infinitive}}}му, {{{infinitive}}}меш, etc. which works fine for non-reflexive verbs (the endings are added to the infinitive) but messes up for reflexive.

https://goroh.pp.ua/боятися shows correct alternative future forms (бу́ду боя́тися, etc. is the main form)

I want to be able to enter the forms manually as follows, the wrong forms are crossed out:

бу́ду боя́тися, ~~боя́тисяму~~ -> бу́ду боя́тися, боя́тимусь, боя́тимуся
бу́деш боя́тися, ~~боя́тисямеш~~ -> бу́деш боя́тися, боя́тимешся

The main future forms work fine, etc. "бу́ду боя́тися" (бу́ду + infinitive), it's the alt forms, which don't work. -му-, -меш- are inserted in the middle and in some cases there are -сь/-ся variations, similar to Russian but the rules are much less predictable.

Calling @Benwing2 for help. Pls note there are too many irregularities and alt forms are possible. --Anatoli T. ^{(обсудить}/^вклад) 02:34, 7 May 2020 (UTC)[reply]

@Benwing2: I have restored the template created by User:Dƶoxar in 2014 and it's the one I want. I am glad I found it. @Rua: It was a rush move from you to delete it :), please check the difference with other templates first. We need this template for the reasons I described above. It's the only one working at the moment. If Ukrainian verbs are ever modularised in the future, this may go but Ukrainian inflections are extremely irregular. --Anatoli T. ^{(обсудить}/^вклад) 04:54, 18 May 2020 (UTC)[reply]

@Benwing2: Are you able to apply slight improvements to {{uk-conj-reflexive}} so that it splits terms when there are commas, like other templates do? --Anatoli T. ^{(обсудить}/^вклад) 05:34, 18 May 2020 (UTC)[reply]

@Atitarev I can do that. I can probably also fix {{uk-conj-table}} so {{uk-conj-reflexive}} isn't necessary, give me a day or so. Benwing2 (talk) 05:57, 18 May 2020 (UTC)[reply]

@Benwing2: Whatever is easier for you. There are parameter name mismatches and not all parameters are displaying in the tables. I do have questions about Ukrainian verb conjugations, such as about existence of pres. actv. participles. No Ukrainian grammar references mention them e.g. диви́тися->ди́влячийся. They may be considered Russianisms(?). In any cases, we may want to drop the param, if it's not used. Pls see https://www.ukrainianlanguage.org.uk/read/unit17/page17-7.htm. In forums people suggest to replace active present particles in Ukrainian and Belarusian with descriptions, something like "the running person" = бігаюча людина -> людина, яка біжить (i.e. the person, which is running).

With adverbials, I often have to figure it by analogy with Russian and then search to confirm. This method can be used: e.g. https://slovnyk.ua/index.php?swrd=дивитися shows adverbials "дивлячись" and "дивившись". Now I search in https://goroh.pp.ua/Словозміна/дивлячись and https://goroh.pp.ua/Словозміна/дивившись and confirm the stress. The main entry itself https://goroh.pp.ua/Словозміна/дивитися doesn't show adverbials, which is annoying, that's why this extra step may be required. --Anatoli T. ^{(обсудить}/^вклад) 06:13, 18 May 2020 (UTC)[reply]

23.82 + 8.91 > 50?[edit]

ποικίλος currently has an out-of-memory error. Previewing the Ancient Greek section shows Lua memory usage of 23.82 MB. Previewing the Greek section shows Lua memory usage of 8.91 MB. Previewing the entire entry shows Lua memory usage of 50 MB. There is no content outside of the two sections, and the list of modules used by the whole-entry preview contains nothing that's not in either of the two single-section previews.

Obviously there's some kind of weird interaction going on here, but this is way over my head. The obvious suspect would be the Ancient Greek "Further reading" subsection, which shows Lua memory usage of 19.29 MB when previewed. If you preview the Ancient Greek section with the "Further reading" subsection commented out, it shows Lua memory usage of 10.97 MB, and if you preview the whole entry with the "Further reading" subsection commented out, it shows Lua memory usage of 26.13 MB.

Still, although User:Isomorphyc's code is notoriously indecipherable, I don't think it's pulling anything from other dimensions. Does anyone have even the slightest inkling as to what's happening here, or how to fix it?. Chuck Entz (talk) 04:29, 7 May 2020 (UTC)[reply]

I've got no additional theories beyond the fact that garbage collection is unpredictable, but I noticed that Module:R:Strong's/grc-data is pretty big and would use even more memory when it's parsed into a Lua table, so I switched Module:R:Strong's to use Module:R:Strong's/grc-data-text-format, which results in less memory usage in ποικίλος. Maybe other data modules could use text formats as well. — Eru·tuon 05:24, 7 May 2020 (UTC)[reply]

Hi User:Chuck Entz and User:Erutuon. I'm sorry I can't help much right now but I hope you're both well. Unfortunately I don't have an explanation for why the memory utilization is not additive here. If I had a way to reduce the memory utilization of a large module, the one I would choose though is: Module:R:Woodhouse/reverse index, because it is big and used a lot. Because of this, R:Woodhouse might be the entry to delete, if there were absolutely no other option. But Module:R:Woodhouse is much more predictable than Module:R:M&A in Latin, which has a one-to-many relation in the reverse lookup which sometimes touches a lot of shards and makes it the worst memory offender. This is just a case of a singe big lookup table I believe. Isomorphyc (talk) 20:36, 7 May 2020 (UTC)[reply]

Fixed per the table -> text suggestion; very nice observation, User:Erutuon, thank you. As suggested I also suspect this is a GC issue relating to Lua tables. With the old tables implementation, swapping the order of the Modern Greek adjective declension template Template:el-adj with Module:R:Woodhouse creates the arithmetic problem flagged by User:Chuck Entz, increasing the memory utilization by 14 MB, see the memory utilization in: User:Isomorphyc/Sandbox/ποικίλοςBA and User:Isomorphyc/Sandbox/ποικίλοςAB. Isomorphyc (talk) 22:28, 8 May 2020 (UTC)[reply]

Replace grave accents with acute accents for translations into Bulgarian[edit]

Per WT:BG TR, we are using acute accents. I have tried to add the following in MediaWiki:Gadget-TranslationAdder-Data.js:

from: "А̀ЀЍО̀У̀Ъ̀Ю̀Я̀а̀ѐѝо̀у̀ъ̀ю̀я̀",
from: "А́Е́И́О́У́Ъ́Ю́Я́а́е́и́о́у́ъ́ю́я́",

And

from: "\u0301",
to: "\u0300",

but to no avail How should it be done? I want e.g. "отгово̀рност" (with a grave) to be replaced with "отгово́рност" (acute). @Benwing2, Erutuon, Dixtosa. --Anatoli T. ^{(обсудить}/^вклад) 06:22, 8 May 2020 (UTC)[reply]

@Atitarev: This wasn't supported by the current data format, but adding a map makes it possible. Of the Cyrillic letters with graves, only Ѐ Ѝ ѐ ѝ are single code points; the rest are formed with a combining acute accent. But each of them must be replaced with two code points (a Cyrillic letter and a combining acute) – Е́И́е́и́ – but from and to fields are treated as a series of individual code points. So a new feature had to be added. With my edit the Translation Adder replaces the graves in the vowels above with acutes when I press "preview translation". — Eru·tuon 03:45, 9 May 2020 (UTC)[reply]

@Erutuon: Thank you but it hasn't worked for me yet (I did a hard refresh). I am using Chrome on Windows 10. --Anatoli T. ^{(обсудить}/^вклад) 03:52, 9 May 2020 (UTC)[reply]

@Atitarev: Hmm, I must've imagined it. Yeah, diacriticStrippers doesn't change the text of the translation. I've created orthographicalCorrections for this type of replacements. At the moment it just has Bulgarian, but some of the other diacriticStrippers replacements may need to be moved there. And after making lots of coding mistakes, I've confirmed it actually works. — Eru·tuon 06:47, 9 May 2020 (UTC)[reply]

@Erutuon: This is excellent, thank you! We can actually do a replacement of wrong characters for specific languages. --Anatoli T. ^{(обсудить}/^вклад) 08:28, 9 May 2020 (UTC)[reply]

@Atitarev: I've moved the diacriticStrippers replacements that looked like orthographical corrections to orthographicalCorrections. Now the palochka replacements and cedilla replacements are finally used as intended. — Eru·tuon 19:19, 9 May 2020 (UTC)[reply]

@Erutuon: Great job! You missed Uzbek, I think. They are orthographic corrections as well. What can be added in the future to the list are common lookalike wrong characters for Persian, Pashto, Urdu and Arabic (the ones you know of), Old Church Slavonic/Old East Slavonic. Some stuff is in WT:AORV (not sure everything is right!) but ꙑ -> ы is correct. --Anatoli T. ^{(обсудить}/^вклад) 22:10, 9 May 2020 (UTC)[reply]

plural gender in `{{it-noun}}`[edit]

When specifying the gender in {{it-noun}} as m-p or f-p, the template currently displays plural forms when there should be nothing in the headword line after the gender. It's different for masculine and feminine: see scopettoni and feoficee. Ultimateria (talk) 02:16, 9 May 2020 (UTC)[reply]

Dialect modules[edit]

I'm trying to move the regional Occitan categories to match the etym-only canonical names (Auvergnese Occitan > Auvergnat, etc.). But one of these edits on /subvarietes and /regional broke like every use of {{label}}, and this error message showed up: Lua error in Module:labels/data/functions at line 10: bad argument #1 to 'ipairs' (table expected, got string). I'm not sure what happened, but I think it may be because Occitan has a dialect module. If someone knows what happened please let me know. Julia ☺ ☆ 01:44, 10 May 2020 (UTC)[reply]

@Julia: Fixed. By convention Module:labels/data/subvarieties has a language field that is a string, while Module:labels/data/regional has a languages that is an array-like table of strings. They can each use either of those types of fields, but combining the two (a languages field that is a string) causes a type error. Probably there should be a clearer error message that appears on the documentation page of each of the modules. — Eru·tuon 02:52, 10 May 2020 (UTC)[reply]

ocior[edit]

ocior is a Latin comparative which apparently has no attested positive form (the currently-linked ocis doesn't exist, as far as I can tell). The positive form in the headword template needs to be replaced with a link to the attested superlative form, ocissimus. I'm not aware of any other Latin comparative with no positive form, so it's not clear how the headword template is to be set up here. This, that and the other (talk) 04:40, 10 May 2020 (UTC)[reply]

@This, that and the other, This, that and the other: Perhaps confer prior. 恨国党非蠢即坏 (talk) 13:08, 15 May 2020 (UTC)[reply]

Importing geographical terminology databases[edit]

@Metaknowledge Hello all! In the month of March 2020, I went on an editing spree in which I manually added a large number of variant names for geographical terms to Wiktionary: [2]. I plan to continue to do this indefinitely. However, I was thinking that I could save myself the trouble if we could go ahead and just come up with some kind of program that would automatically add geographical terms to Wiktionary. The program I am proposing would function in a manner similar to the way that Template:zh-new/der is linked in with ROC Taiwan's Revised National Language Dictionary (Chongbian Guoyu Cidian) and automatically generates lists of derived terms. We might pull terms from GEOnet. I have used GEOnet for China-related geographical terms and although it is definitely weak in some aspects, I think it could be put to our uses here and set the foundation to turn the dictionary into the ultimate freely editable database of geographical terminology. There's probably a good reason this hasn't been done yet, but in case there isn't I wanted to go ahead and put forth my thoughts. For instance, one program might work by automatically attaching non-Roman alphabet language names of location names into the translation box, directly from GEOnet. I don't have the technical know-how to do this, only the imagination to describe a general concept. --Geographyinitiative (talk) 09:42, 10 May 2020 (UTC)[reply]

It's CC-BY, so I believe compatible with our license. But the main reason this hasn't been done yet is that it would be a mammoth undertaking, and our more technically capable contributors generally have other interests than geographic names. —Μετάknowledge^{discuss/deeds} 17:22, 10 May 2020 (UTC)[reply]

Double linking a single entry in declension templates[edit]

I'd like a declension table cell to contain a single entry in this form: sivatag(j)a which is a short notation for two possible possessive variants: sivataga and sivatagja. The lemma is sivatag. The user should be able to click on (j) to get to sivatagja or to click on the rest of the word to get to sivataga. The template name is {{hu-infl-pos-table-test}}. Is this feasible? Any ideas would be really appreciated. Panda10 (talk) 21:12, 10 May 2020 (UTC)[reply]

@Panda10: I don't know how to do it, because I don't know how to to write modules, but I know that the Ancient Greek inflection modules have this functionality, so it is possible. See for example, φέρω (phérō), where the top row of the first table shows φέρουσῐ(ν) (phérousi(n)). —Mahāgaja · talk 04:53, 11 May 2020 (UTC)[reply]

@Panda10: Maybe User:Benwing2 can give you some advice. The comparative forms of the Russian adjective тёплый (tjóplyj) are linked to (по)тепле́е or (по)тепле́й (move your mouse over to see what is linked), etc. depending on what you click on. The problem with your example is that you have a term around the link inside. "j" should be linked to sivatagja#Hungarian but I am not sure about the term around it. --Anatoli T. ^{(обсудить}/^вклад) 06:10, 11 May 2020 (UTC)[reply]

@Panda10: You'd have to create three separate links, one for sivatag, one for (j) and one for a. Benwing2 (talk) 06:26, 11 May 2020 (UTC)[reply]

@Benwing2, Panda10: Thanks. The complete link would look like this then: [[sivataga#Hungarian|sivatag]]([[sivatagja#Hungarian|j]])[[sivataga#Hungarian|a]] and the result like this: sivatag(j)a. --Anatoli T. ^{(обсудить}/^вклад) 06:37, 11 May 2020 (UTC)[reply]

@Mahagaja, Atitarev, Benwing2: Thank you all for your help. It's good to know that it is feasible and other languages also use this format. After I submitted the question it occurred to me that there is one problem with this solution. The search engine will not find sivataga and sivatagja if they are still red links. Is that acceptable for the Greek and Russian entries? Normally, if the inflected form is a red link, the search engine will find the lemma entry. But no one will search for sivatag(j)a. Panda10 (talk) 16:28, 11 May 2020 (UTC)[reply]

@Panda10: That's the reason why I switched away from using parentheses in {{grc-decl}} and {{grc-adecl}}. (If I ever rewrite {{grc-conj}}, I'll make the same change there.) For instance, the Attic declension table in ἔπος (épos) shows "ἔπεσῐ / ἔπεσῐν" instead of "ἔπεσῐ(ν)". The parenthesized form is used in Module:grc-decl/decl/staticdata/paradigms and Module:grc-decl/decl/data, but it is translated into the fully expanded form by Module:grc-decl/table (inside local function link) when the forms are linked. — Eru·tuon 20:11, 11 May 2020 (UTC)[reply]

@Erutuon: Thanks for letting me know. We wanted to save some space since the table is already huge and rather intimidating for users, but we will have to reconsider it because of the search issue. Panda10 (talk) 20:26, 11 May 2020 (UTC)[reply]

@Panda10: Yes, there is that problem with red links as you describe. You see, rather than displaying all four possible comparative forms at тёплый (tjóplyj), it's shortened to two with brackets.

I looked at sivatag. I think the alternative forms are better separated by commas: sivatagai, sivatagjai rather than a simple carriage return. --Anatoli T. ^{(обсудить}/^вклад) 22:48, 11 May 2020 (UTC)[reply]

I, too, thank you all for your generous help. I changed these experimental templates to prepare displaying both forms in full, separated by a slash (or a comma). Could you help me find the bug why sivatagját is not currently displayed after sivatagát? It seems like the variable "3sg_sg_suff_alt" (= "sivatagjá") doesn't get its value in {{hu-infl-pos-table-test}}, although it depends on the value of "j" in {{hu-pos-otok-test}} (i.e., the j-alternation is present here), and I don't know why it doesn't get its value, why the condition is not evaluated as true (if this is the problem at all). Adam78 (talk) 23:08, 11 May 2020 (UTC) PS, the table with the parameters supplied: [reply]

Possessive forms of Grease pit/2020/May
	1st person singular	2nd person singular	3rd person singular	1st person plural	2nd person plural	3rd person plural
single possession
nominative	sivatagom	sivatagod	sivataga sivatagja	sivatagunk	sivatagotok	sivataguk sivatagjuk
accusative	sivatagomat	sivatagodat	sivatagá sivatagját	sivatagunkat	sivatagotokat	sivataguk sivatagjukat
dative	sivatagomnak	sivatagodnak	sivatagá sivatagjának	sivatagunknak	sivatagotoknak	sivataguk sivatagjuknak
instrumental	sivatagommal	sivatagoddal	sivatagá sivatagjával	sivatagunkkal	sivatagotokkal	sivataguk sivatagjukkal
causal-final	sivatagomért	sivatagodért	sivatagá sivatagjáért	sivatagunkért	sivatagotokért	sivataguk sivatagjukért
translative	sivatagommá	sivatagoddá	sivatagá sivatagjává	sivatagunkká	sivatagotokká	sivataguk sivatagjukká
terminative	sivatagomig	sivatagodig	sivatagá sivatagjáig	sivatagunkig	sivatagotokig	sivataguk sivatagjukig
essive-formal	sivatagomként	sivatagodként	sivataga sivatagjaként	sivatagunkként	sivatagotokként	sivataguk sivatagjukként
essive-modal	sivatagomul	sivatagodul	sivatagá sivatagjául	sivatagunkul	sivatagotokul	sivataguk sivatagjukul
inessive	sivatagomban	sivatagodban	sivatagá sivatagjában	sivatagunkban	sivatagotokban	sivataguk sivatagjukban
superessive	sivatagomon	sivatagodon	sivatagá sivatagján	sivatagunkon	sivatagotokon	sivataguk sivatagjukon
adessive	sivatagomnál	sivatagodnál	sivatagá sivatagjánál	sivatagunknál	sivatagotoknál	sivataguk sivatagjuknál
illative	sivatagomba	sivatagodba	sivatagá sivatagjába	sivatagunkba	sivatagotokba	sivataguk sivatagjukba
sublative	sivatagomra	sivatagodra	sivatagá sivatagjára	sivatagunkra	sivatagotokra	sivataguk sivatagjukra
allative	sivatagomhoz	sivatagodhoz	sivatagá sivatagjához	sivatagunkhoz	sivatagotokhoz	sivataguk sivatagjukhoz
elative	sivatagomból	sivatagodból	sivatagá sivatagjából	sivatagunkból	sivatagotokból	sivataguk sivatagjukból
delative	sivatagomról	sivatagodról	sivatagá sivatagjáról	sivatagunkról	sivatagotokról	sivataguk sivatagjukról
ablative	sivatagomtól	sivatagodtól	sivatagá sivatagjától	sivatagunktól	sivatagotoktól	sivataguk sivatagjuktól
multiple possessions
nominative	sivatagaim sivatagjaim	sivatagaid sivatagjaid	sivatagai sivatagjai	sivatagaink sivatagjaink	sivatagaitok sivatagjaitok	sivatagaik sivatagjaik
accusative	sivatagaim sivatagjaimat	sivatagaid sivatagjaidat	sivatagai sivatagjait	sivatagaink sivatagjainkat	sivatagaitok sivatagjaitokat	sivatagaik sivatagjaikat
dative	sivatagaim sivatagjaimnak	sivatagaid sivatagjaidnak	sivatagai sivatagjainak	sivatagaink sivatagjainknak	sivatagaitok sivatagjaitoknak	sivatagaik sivatagjaiknak
instrumental	sivatagaim sivatagjaimmal	sivatagaid sivatagjaiddal	sivatagai sivatagjaival	sivatagaink sivatagjainkkal	sivatagaitok sivatagjaitokkal	sivatagaik sivatagjaikkal
causal-final	sivatagaim sivatagjaimért	sivatagaid sivatagjaidért	sivatagai sivatagjaiért	sivatagaink sivatagjainkért	sivatagaitok sivatagjaitokért	sivatagaik sivatagjaikért
translative	sivatagaim sivatagjaimmá	sivatagaid sivatagjaiddá	sivatagai sivatagjaivá	sivatagaink sivatagjainkká	sivatagaitok sivatagjaitokká	sivatagaik sivatagjaikká
terminative	sivatagaim sivatagjaimig	sivatagaid sivatagjaidig	sivatagai sivatagjaiig	sivatagaink sivatagjainkig	sivatagaitok sivatagjaitokig	sivatagaik sivatagjaikig
essive-formal	sivatagaim sivatagjaimként	sivatagaid sivatagjaidként	sivatagai sivatagjaiként	sivatagaink sivatagjainkként	sivatagaitok sivatagjaitokként	sivatagaik sivatagjaikként
essive-modal	sivatagaim sivatagjaimul	sivatagaid sivatagjaidul	sivatagai sivatagjaiul	sivatagaink sivatagjainkul	sivatagaitok sivatagjaitokul	sivatagaik sivatagjaikul
inessive	sivatagaim sivatagjaimban	sivatagaid sivatagjaidban	sivatagai sivatagjaiban	sivatagaink sivatagjainkban	sivatagaitok sivatagjaitokban	sivatagaik sivatagjaikban
superessive	sivatagaim sivatagjaimon	sivatagaid sivatagjaidon	sivatagai sivatagjain	sivatagaink sivatagjainkon	sivatagaitok sivatagjaitokon	sivatagaik sivatagjaikon
adessive	sivatagaim sivatagjaimnál	sivatagaid sivatagjaidnál	sivatagai sivatagjainál	sivatagaink sivatagjainknál	sivatagaitok sivatagjaitoknál	sivatagaik sivatagjaiknál
illative	sivatagaim sivatagjaimba	sivatagaid sivatagjaidba	sivatagai sivatagjaiba	sivatagaink sivatagjainkba	sivatagaitok sivatagjaitokba	sivatagaik sivatagjaikba
sublative	sivatagaim sivatagjaimra	sivatagaid sivatagjaidra	sivatagai sivatagjaira	sivatagaink sivatagjainkra	sivatagaitok sivatagjaitokra	sivatagaik sivatagjaikra
allative	sivatagaim sivatagjaimhoz	sivatagaid sivatagjaidhoz	sivatagai sivatagjaihoz	sivatagaink sivatagjainkhoz	sivatagaitok sivatagjaitokhoz	sivatagaik sivatagjaikhoz
elative	sivatagaim sivatagjaimból	sivatagaid sivatagjaidból	sivatagai sivatagjaiból	sivatagaink sivatagjainkból	sivatagaitok sivatagjaitokból	sivatagaik sivatagjaikból
delative	sivatagaim sivatagjaimról	sivatagaid sivatagjaidról	sivatagai sivatagjairól	sivatagaink sivatagjainkról	sivatagaitok sivatagjaitokról	sivatagaik sivatagjaikról
ablative	sivatagaim sivatagjaimtól	sivatagaid sivatagjaidtól	sivatagai sivatagjaitól	sivatagaink sivatagjainktól	sivatagaitok sivatagjaitoktól	sivatagaik sivatagjaiktól

@Adam78: |{{#if:{{{j|}}}|3sg_sg_suff_alt={{{1}}}{{{2|}}}já}} in {{Template:hu-pos-otok-test}} doesn't work as a way to optionally supply the parameter 3sg_sg_suff_alt. It just expands to an empty string because it is supplying the parameter |3sg_sg_suff_alt= to the "if" parser function, which simply ignores it. As far as I know there isn't any way to optionally supply a parameter. You have to supply one of two values depending on the condition. If you do |3sg_sg_suff_alt={{#if:{{{j|}}}|{{{1}}}{{{2|}}}já}}, {{{3sg_sg_suff_alt|}}} will be the empty string in {{hu-infl-pos-table-test}} when the alternative suffix should not be applied. — Eru·tuon 23:21, 11 May 2020 (UTC)[reply]

I made the change and the template might be working now. — Eru·tuon 23:29, 11 May 2020 (UTC)[reply]

Thank you very much. I continued the expansion and I'm more and more inclined to think that this kind of contraction: sivatag(j)ait would be a hundred times better. Currently it's pretty intimidating indeed. Adam78 (talk) 00:45, 12 May 2020 (UTC)[reply]

One way to make the possessive table smaller is to only show the nominative singular of each person–number possessive form in the noun lemma, and give each nominative–singular possessive form its own entry containing an inflection table of the rest of its case–number forms, as is done for Finnish nouns. For instance, see koira, which has a possessive table linking to the nominative singular possessive forms koirani, koirasi, koiransa, koiramme, koiranne, which in turn have their own inflection tables, similar to those of koira (with case rows and number columns) but of course without possessive tables below them. This would make the tables smaller so that showing the alternative forms with j would not inflate the table as much, but the tradeoff is more tables to keep track of. — Eru·tuon 05:42, 12 May 2020 (UTC)[reply]

@Erutuon: Actually, this is our current method. See sivataga. The reason both @Adam78 and I think a large table would be useful is that search would find red links even if the form entries do not exist. And many still don't exist. It takes time to enter them. I have another question. Could we create nested tables? Similar to the table labeled "Possessive forms of term - with NavFrame" in {{hu-infl-pos-table-comparison}} except using the current {{hu-infl-pos-table}} table script and not NavFrame. I've read somewhere that NavFrame is obsolete. The nested tables have to remain closed in Mobile view by default. Do you think it's feasible? Panda10 (talk) 16:56, 13 May 2020 (UTC)[reply]

@Panda10: Sorry, should have paid attention to the entries. Yeah, I see what you mean about the search engine issue.

You can use vsSwitcher if you would like nested tables. For example, see the tables for many or all of the Sami languages (created by User:Rua), such as Northern Sami áhkalakkis. They have a top-level table that, when expanded, shows the case–number forms and the header for table for the possessive forms, which can be clicked on to show the nominative singular possessive forms.

vsSwitcher allows any number of nested expandable tables. There isn't documentation for it as far as I know, so I'll give a basic explanation. It uses classes to mark the elements involved in collapsing and expanding. The top level of the expandable element is marked with the class vsSwitcher, the show–hide button with vsToggleElement, and the elements that are visible only in the "shown" state and the "hidden" state with vsShow and vsHide respectively. vsSwitcher elements can be nested, in which case the vsToggle element only affects elements that are in the same nearest parent vsSwitcher element. So the top-level toggle in the Sami table opens the case–number table and shows the toggle for the possessive table, which in turn can be clicked to open the possessive table.

vsSwitcher would allow you to have a nested table for the nominative singular possessive forms, or even to have a second level of nested tables for the case–number forms of each of the possessive forms, if you can come up with a good way to arrange them. — Eru·tuon 21:51, 13 May 2020 (UTC)[reply]

@Erutuon: Thank you for this information. I will look into it and see if this would work for us. Panda10 (talk) 23:08, 13 May 2020 (UTC)[reply]

@Erutuon: I created a test table {{hu-infl-pos-table-nested-test}} with hardcoded data and only a few cases to be able to focus on the nested function. The table is closed by default. Clicking more opens the table and shows the nominative forms for both single and multiple possessions. Clicking more on the single possession header opens all case forms for single possessions and the header of multiple possessions. Clicking the toggle switch on multiple possessions works as it should. However, clicking more (which should really be less) on the single possession closes the table and I can't open it unless I refresh the page. I can't figure it out. Would you take a look at it? I have two more questions: 1) Can a nested table be part of a condition? E.g. show this table only if j=y, otherwise hide it completely. 2) Shouldn't every vsSwitcher table have a closing |} at the end? Panda10 (talk) 18:29, 15 May 2020 (UTC)[reply]

@Panda10: Every table, whether vsSwitcher or not, should end with |}, yes. I'm guessing the problem is that you have multiple vsToggles that are inside the same vsSwitcher element. Each vsToggle needs to be inside its own unique vsSwitcher element. — Eru·tuon 18:39, 15 May 2020 (UTC)[reply]

To put a table inside {{#if:}} or {{#ifeq:}}, you have to put the table in a separate template and use that template in the if statement, or replace the pipes and brackets in the syntax of the table with templates so that it doesn't parse as template syntax. That is, all {| with {{(!}}, all | or || of table rows or cells with {{!}} or {{!!}} respectively, all |} with {{!)}}. Using a separate template is easier than this I think. — Eru·tuon 18:44, 15 May 2020 (UTC)[reply]

Now I'm slowly starting to acquiesce in the idea of having two tables under each other, not only because the other way might not work at all or would be too complicated to implement or lengthy to look at but also partly because it's done this way with other types of variations (like levet vs. lét from lé) and partly because sometimes there is some difference at least in style between the two forms (as many people today will say karrierje instead of karriere but I find the former strange; others might likewise shrink from using other forms). So maybe such templates with a parameter j=y should recursively call itself twice, once without j and again with it, if it's a viable alternative. @Panda10 and others, what do you think? Adam78 (talk) 19:14, 13 May 2020 (UTC)[reply]

@Adam78: A second table would be fine for the -j forms if nothing else works. But it might be worth looking into the nested table idea and applying it to the same table you created. By default, the table would be closed just like now. When the user opens it, for each large section there would be a second level of closed tables: single possession, multiple possessions and the same two for the -j forms. For each, the nominative row could be visible, the rest hidden until opened with another click. I have one concern about your current test table, though. I wonder if it is a better practice to separate look and feel from function, so the layout table would contain only wikicode for the layout (colors, columns, etc.), the rest of the template would call this layout template and provide the values. Panda10 (talk) 16:36, 14 May 2020 (UTC)[reply]

Does acceleration need unique parameter names?[edit]

If I want to add acceleration to a new template, does each cell need a unique parameter in the code? The template is {{hu-infl-pos-table-test}}. Thanks in advance. Panda10 (talk) 21:16, 10 May 2020 (UTC)[reply]

@Panda10: Which parameter do you mean when you say "unique parameter"? |accel-form= in {{l}} or {{l-self}} perhaps? — Eru·tuon 22:29, 10 May 2020 (UTC)[reply]

As with Erutuon I'm not sure what parameter you're referring to. Each cell should have a different set of inflection codes in the acceleration info but some cells may have the same inflected form as others (i.e. there may be syncretism). Benwing2 (talk) 06:29, 11 May 2020 (UTC)[reply]

@Erutuon, Benwing2 Here is an example. The lines for 1st-person singular nominative and accusative both use the same 1sg_sg which represents the lemma. The accusative line adds the accusative suffix to that. So the parameter (am I using the correct term here?) is not unique. 1sg_sg is used throughout the script several times and the different case suffixes are added to that.

Nominative: {{#if:{{{1sg_sg|}}}|{{l-self|hu|{{{1sg_sg}}}}}|—}}|#default=—}}

Accusative: {{#if:{{{1sg_sg|}}}|{{l-self|hu|{{{1sg_sg}}}{{{v}}}t}}|—}}|#default=—}}

Will the the acceleration code below work?

{{l-self|hu|accel-form=nom{{!}}s|{{{1sg_sg}}}}}|—}}|#default=—}}

{{l-self|hu|accel-form=acc{{!}}s|{{{1sg_sg}}}}}|—}}|#default=—}}

Shouldn't we create unique names such as 1sg_sg_nom and 1sg_sg_acc?

Thanks. Panda10 (talk) 16:17, 11 May 2020 (UTC)[reply]

I think |accel-form=nom{{!}}s and |accel-form=acc{{!}}s alone are not enough information to generate the form-of entries, but User:Surjection, who has worked on a table of Finnish possessive forms in Module:fi-nominals, may be better able to offer advice. — Eru·tuon 20:20, 11 May 2020 (UTC)[reply]

I don't really have any experience using accel directly in templates, as I've always relied on Module:links. However, if two different forms (potential entries) have the same accel form, that form will be suggested for both separately, and if a single form (potential entry) has multiple distinct accel forms, those all will be suggested for the created entry. — sur jec tion ⟨??⟩ 20:39, 11 May 2020 (UTC)[reply]

Merging entries[edit]

I had a couple technical questions about merging entries. 1. Can two entries that have been merged be unmerged? 2. Is merger a separate role that can be granted, or is that only an admin tool? --{{victar|talk}} 02:34, 12 May 2020 (UTC)[reply]

@Victar: Merging page histories requires the mergehistory right, which is limited to admins here and on Wikipedia. Yeah, to my surprise, there's "unmerge" button in the merge log and it brings up the same merge interface, just with the page titles reversed. When the original merged-from page doesn't exist, it complains, so I'm not sure the exact mechanics of unmerging; it might not be possible in all circumstances. — Eru·tuon 05:16, 12 May 2020 (UTC)[reply]

@Erutuon: So as far as you known, mergehistory rights cannot bestowed on a user that isn't an admin, correct? --{{victar|talk}} 06:22, 12 May 2020 (UTC)[reply]

@Victar: Yeah, that's what I was getting at. Rights are bestowed by group membership and only the admin group has the right, so no non-admins can have the right in the current setup. — Eru·tuon 06:33, 12 May 2020 (UTC)[reply]

@Erutuon: Gotcha. Boo. --{{victar|talk}} 06:59, 12 May 2020 (UTC)[reply]

@Erutuon: So, would that be technically possible to create a mergehistory role? Is that a phabricator job? --{{victar|talk}} 22:06, 12 May 2020 (UTC)[reply]

@Victar: Yep, if you could round up enough people to clamor for it and then post on Phabricator, the MediaWiki folks could create a "history merger" group that included that right. — Eru·tuon 22:38, 12 May 2020 (UTC)[reply]

Cuneiform CLDR lookup is broken, likely many other pages[edit]

Steps to reproduce:

Go to (e.g.) Appendix:Unicode/Cuneiform.
Click on the outgoing link to look up any character, e.g. 𒀩 (cuneiform sign alan), which should be located at https://unicode.org/cldr/utility/character.jsp?a=12029
Get a 404 error.

I have been trying to figure out where these are now located but I'm some amount of sleepy and stupid. Can anyone else figure out where the new URIs are for all of these entries and how to fix them? Pretty shocking that a standards body would have URIs that go dead like this but here we are. :/ —Justin (koavf)❤T☮C☺M☯ 09:08, 12 May 2020 (UTC)[reply]

@Koavf: It seems that the character properties lookup is broken for all Unicode characters, and has been since at least May 2019 per this Wayback Machine archive. According to the page for the Unicode Character Properties utility the tool was a demo. As to why it broke, I have no clue. Looking at the "How to Use" link you provided and doing my own search, there don't seem to be any online replacements at this point. —The Editor's Apprentice (talk) 22:47, 4 June 2020 (UTC)[reply]

@The Editor's Apprentice: Thanks for following up. I'll write Unicode. —Justin (koavf)❤T☮C☺M☯ 00:36, 5 June 2020 (UTC)[reply]

I heard back from them and the short answer is that they are not set up to have character-by-character retrieval like this and recommended against us trying to access their site in this manner. They have no ETA for a service like this coming back if ever. If our goal is to have some kind of long-term, durable citation, we can just cite the Unicode standard itself (i.e. without a hyperlink to an individual character's page). —Justin (koavf)❤T☮C☺M☯ 06:44, 5 June 2020 (UTC)[reply]

@Koavf: That's a pretty quick turn around time. It is unfortunate that there doesn't seem to be any plans for a similar service in the future. As far as I can tell, specific Unicode standard PDFs don't contain any information about characters that the appendix pages don't already contain besides example glyphs. I agree with you that if the goal is to provide a citation proving that a characterhas certain properties then it would make sense to just add a link in the introduction to the specific Unicode standard PDF, for example https://unicode.org/charts/PDF/U12000.pdf for Cuneiform. I think doing so would be moderately useful, but would not significantly fill in the gap of information lost because of the discontinuation of the Unicode Character Properties utility. I think it would be most helpful to users if such was done in addition to providing links to a third party service which provides information on individual characters such as fileformat.info, charactercodes.net, shapecatcher.com, or charbase.com. Such links would help mitigate the loss due to the discontinuation of the Unicode Character Properties utility. I'm curious as to what your thoughts are about my idea and if you are aware of any other sites which provide detailed information about individual Unicode characters. —The Editor's Apprentice (talk) 17:34, 5 June 2020 (UTC)[reply]

@The Editor's Apprentice: I have written Unicode a couple of times and they always respond quickly and thoroughly in my experience. I am not familiar with any of those particular sites, so I can't speak to them but I do agree that having some character-by-character info is valuable until we have that info here. Unicode representatives clarified that the actual content of the standards are freely licensed but they have to themselves license hundreds of fonts in their PDFs so we couldn't reproduce them as-is here. —Justin (koavf)❤T☮C☺M☯ 18:43, 5 June 2020 (UTC)[reply]

@Koavf: Good to hear. I also became aware that the fonts are licensed from other sources while reading about them, its an interesting situation. In my opinion, of the sites that I listed charactercodes.net is probably the best because it seems to be able to serve example glyphs for the most number of Unicode characters. After it, I would say fileformat.info is the second best because it contains the most details. What are your thoughts on the importance of providing example glyphs versus detailed character information? Thanks again. —The Editor's Apprentice (talk) 06:53, 6 June 2020 (UTC)[reply]

@The Editor's Apprentice: At the risk of being pedantic (I have no clue what you know about typography), I think it is most valuable to discuss what the character is and means followed by how it looks, as dictionaries are about semantics, not style. But style is still pretty important. And I think that if someone were discussing <a> and didn't mention single-storey and two-storey variants, that would be a pretty big lacuna. The nice thing about the Internet is that we can have multiple links, so there's no reason why have to choose. Additionally and as an aside, I very much think that we should include an entry for every Unicode character (as well as non-Unicode ones like Maya script but that is a tall challenge). —Justin (koavf)❤T☮C☺M☯ 06:57, 6 June 2020 (UTC)[reply]

@Koavf: No risk of being with pedantic with me, it's practically my middle name :^). I'm familiar enough with typography to understand the distinction you're drawing. In terms of providing multiple links, even though I have a personal favourite website, I do think doing so is generally a good idea, though not something I was initially thinking about, thanks for bringing it up. The easiest way for doing so that comes to mind for me is to create a new column in the Unicode character appendix tables which contains the links. One thing that I am curious about is if you think the links provided should be of any website which contains information on Unicode characters individually, or if it should exclude websites which only contain very brief information, like charbase.com. In response to your aside, I definitely concur. Basically by definition every Unicode character is idiomatic and is attested.
Finally, I have some questions about the set up of the Unicode character appendix tables in general. First, I don't understand the point of the "Image" column which seems to just list the characters' code points in base ten, something that is already done in the "Code point" column. Second, wouldn't it make sense to actually display the character itself in its own column so that even if an image isn't provided, a user can still navigate based on appearances if they have the right fonts? Third, wouldn't it make sense to provide a link to characters' pages on Wiktionary, even if they don't exist, to provide for easier navigation? Thanks again. —The Editor's Apprentice (talk) 23:47, 7 June 2020 (UTC)[reply]

@The Editor's Apprentice: Kind of shocking that I am only now noticing this but you are correct that images are not appearing in the "image" column but in the "character" one and what does appear in "image" should be converted into either character entities or the raw character itself. Additionally, providing links to actual entries would be very helpful. As it stands, these appendices are a mess. —Justin (koavf)❤T☮C☺M☯ 00:44, 8 June 2020 (UTC)[reply]

@Koavf: They are a bit of a mess. I think the two of use concur on what types of changes should be made. With that I'm now thinking about implementation. Specifically, can we simply go forward and make the changes, as they seem fairly agreeable, or is it necessary to go through some sort of process to establish community consensus? —The Editor's Apprentice (talk) 17:17, 9 June 2020 (UTC)[reply]

@The Editor's Apprentice: I don't think it's controversial enough to require feedback and we're posting here publicly where anyone can comment, etc. Do you need help or can you do this yourself? —Justin (koavf)❤T☮C☺M☯ 18:51, 9 June 2020 (UTC)[reply]

I've fixed the tables so that the image column actually displays the image. — Eru·tuon 20:43, 9 June 2020 (UTC)[reply]

That's an amazingly simple fix, but makes sense given that the code worked in the past. I played around with the code a lot and I created a version that I believe works. It is currently located at Module:character list/sandbox and just needs to be merged into the main module with some one with the permissions to do so. Pinging Justin. —The Editor's Apprentice (talk) 21:52, 9 June 2020 (UTC)[reply]

Great. @Erutuon: since you jumped in for a quick fix just now, would you like to sign off on this before I copy and past it over? —Justin (koavf)❤T☮C☺M☯ 22:22, 9 June 2020 (UTC)[reply]

I previewed the sandbox version, and honestly, I don't think any of the three websites (fileformat.info, charactercodes.net, shapecatcher.com) provides quite enough information on the code points (though I'm somewhat fond of fileformat.info) to replace the discontinued tool, and think it would be best to avoid the repetitivity of repeating the names of the websites over and over in the "External documentation" column if possible. None of the three shows the full list of properties, as did the discontinued tool. codepoints.net probably does though; see the page on U+12002 for instance. One important disadvantage (for rarer code points) is that it doesn't include an image. graphemica.com seems to also provide a pretty complete list of properties, but they're cryptically abbreviated, which is not helpful. (Like charactercodes.net, graphemica.com has an incorrect algorithm to generate one of the escape sequences: for instance, \u12000 should be \U00012000.) Overall I like codepoints.net, but it would be good to also link to a site that has images. — Eru·tuon 23:08, 9 June 2020 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I was totally unaware that there were any other similar websites, hence why I suggested linking to sites such as fileformat.info even though they did not contain anything close to complete information. Thanks for pointing them out. Looking at the codepoints.net page for <A> in comparison to the corresponding archived official Unicode page there are some properties that codepoints.net misses, including some that graphemica.com has, but it seems that most useful properties are listed. Additionally, comparing codepoints.net to any of the websites I previously mentioned reveals that it contains substantially more information. I agree that repeating the names of websites over and over is something worth avoiding. I think that codepoints.net provides the best replacement for the lost service because of its detail and legibility as well as because it provides further links to other websites. The website which appears to have the greatest collection of images is charactercodes.net. With all of that, I think the remaining question is how to implement the links. My current thinking is that the character's code point could contain the link to the site which contains the property information (codepoints.net), as was previously done for the official tool, and that the charactercodes.net page for the block (e.g. [3]) could be linked in the introduction to the appendix page. —The Editor's Apprentice (talk) 17:53, 10 June 2020 (UTC)[reply]

@Erutuon, Koavf: I'm following up on our previous discussion since it seems to have stalled quite close to the end. I'm curious what y'all's thoughts about my proposal which is, admittedly, buried at the end of my previous post. The only modification that I'm making to my proposal is that scriptsoure.org (e.g.[4]) be used instead of codepoints.net as a source for images since it seems to actually be the codepoints.net is sourcing its images and from scriptsource.org and that scriptsource.org has higher quality images. Thanks to you both for your help and input throughout. —The Editor's Apprentice (talk) 21:37, 6 July 2020 (UTC)[reply]

I think your suggestion about what to link and when that you provided above is sensible. I like it. —Justin (koavf)❤T☮C☺M☯ 21:40, 6 July 2020 (UTC)[reply]

Could you clarify where codepoints.net is displaying images from scriptsource.org? I don't see an image on the page for U+12029 for instance, only the character itself. — Eru·tuon 22:08, 6 July 2020 (UTC)[reply]

Yeah, I meant to refer charactercodes.net instead but accidentally swapped out the website names. I find it easily confusing because of how semantically similar the domains all are. —The Editor's Apprentice (talk) 22:18, 6 July 2020 (UTC)[reply]

@Erutuon: I've made some more changes to Module:character list/sandbox to match my proposal and to accommodate the current version of Module:character list. If my explanation is sufficient and the code looks good to you, I think it is ready to become official.
PS: The the names of control characters, for example at Appendix:Unicode/Basic Latin, are currently handled seems less than ideal. Various other information, specifically the text "<control-####>; control character name:", precedes the actual character's name. I was able to figure out how remove the text "control character name:", but not the rest. Any suggestions on doing so? —The Editor's Apprentice (talk) 03:36, 7 July 2020 (UTC)[reply]

Actually, the "control character name" is one of the name aliases, not an official name. That's why it's preceded by "control character name", which apparently is not very clear. The control characters U+0000-U+001F and U+007F-U+009F don't have names, only labels (<control-XXXX>, described in chapter 4 of the Unicode Standard) and aliases. Perhaps the labels should be marked, like the aliases, to indicate that they aren't official names. Currently the table marks control character aliases but not the labels. — Eru·tuon 05:02, 7 July 2020 (UTC)[reply]

@Erutuon: Interesting. That is a much more complicated setup than I would have expected, but matches pretty well what I was seeing when I was looking at the code for the module. One thing that is unclear to me is what the advantage to users is of providing the labels. The reason it is unclear is because they are just a concatenation of the category information and the code point, both of which are included elsewhere in the table. Overall, I don't see the benefit of reiterating the information. For the aliases, I think it would make sense to change the way they are marked to something that specifically names them as aliases, e.g. "alias name". —The Editor's Apprentice (talk) 19:03, 7 July 2020 (UTC)[reply]

Some file names' casing is different. Why?[edit]

For example, on the "Dog" page, there are

<a href="/wiki/File:En-uk-a_dog.ogg" title="File:En-uk-a dog.ogg">
<a href="/wiki/File:en-us-dog.ogg" title="File:en-us-dog.ogg">

If I click each of the links, actual file names are:

This is problematic for me because I wanted to get the actual file using the virtual file name (I mean the thing that comes after "/wiki/File:"), and different casings generate different MD5 hashes (ee33536c3a430c19a4631c1e5bd9cf93 for "en..." and 061574a4fd4fbe9d61efa8acb00f2002 for "En..."). Sin Jeong-hun (talk) 16:51, 12 May 2020 (UTC)[reply]

This is a initial letter case-sensitive wiki, but the files are hosted on an initial letter case-insensitive wiki. I imagine that it hasn't mattered for any purposes before, and I don't know what your hashes are for. —Μετάknowledge^{discuss/deeds} 16:39, 12 May 2020 (UTC)[reply]

Well, according to a StackOverflow answer, the actual file URL can be generated by the MD5 hash. If you look the URL closely, it has "...commons/0/06/En-us...." the "0" is the first letter of the MD5 and 06 is the first two letters of the MD5 (061574a4fd4fbe9d61efa8acb00f2002). The same applies to "...commons/4/47/En-uk...". "En-uk-a_dog.ogg" has the MD5 hash of "479d395d96fa5cde381861182e2c97c7". But anyway, it seems that the rule in that StackOverflow answer is not always correct anyway. Some audio file's actual URL does not follow that format. Sin Jeong-hun (talk) 16:51, 12 May 2020 (UTC)[reply]

A lot of "Lua error: not enough memory" at the bottom of the "si" page[edit]

After "Romansch" (https://en.wiktionary.org/wiki/si#Romansch), it is all "Lua error: not enough memory". Sin Jeong-hun (talk) 18:38, 12 May 2020 (UTC)[reply]

Yes, many people are aware of this and other pages that have had module errors for a while, and we haven't come up with a solution. — Eru·tuon 18:42, 12 May 2020 (UTC)[reply]

Add language links[edit]

I wanted to link Category:da:Materials to relevant categories on Russian and Swedish Wiktionary, as I have done hundreds of times before. But today the link to Wikidata is missing from the bottom of the left margin. It's also missing on Swedish and Russian Wiktionary, but still visible on English and Swedish Wikipedia. Please put it back soon. --LA2 (talk) 16:39, 14 May 2020 (UTC)[reply]

w:WP:ITSTHURSDAY. Reported at phab:T252800. --Vriullop (talk) 17:32, 14 May 2020 (UTC)[reply]

Apparently, there is now a solution and it will be applied sometime May 27 or 28. -- LA2 (talk) 13:20, 19 May 2020 (UTC)[reply]

@Vriullop: For the record, Wiktionary gets deployments on Wednesdays, not Thursdays. --Yair rand (talk) 23:44, 26 May 2020 (UTC)[reply]

That's right, but it is usually on Wednesday UTC afternoon and Europeans report broken things on Thursday UTC morning when (most) Californians are sleeping :-). Note that this is a bug only for Vector, as a workaround you can add links as usual changing to another skin. --Vriullop (talk) 06:25, 27 May 2020 (UTC)[reply]

Edittags[edit]

I'm curious about the page Special:EditTags, which appears on every page history. It seems odd to me that this is open to everyday users, but, when I tried removing some of the tags of my edits that I thought might not be really deserving of tags (e.g. WT:NORM), it wouldnt let me do it. Is this an experimental feature that will be rolled out to all users soon, or is it going to be just for those with advanced permissions? Oddly I couldnt find any help pages anywhere either. I dont know if this button has been there for months or even years without my noticing it, or if it just appeared today. Thanks, —Soap— 15:55, 17 May 2020 (UTC)[reply]

@Soap: Not all tags can be removed from or added to revisions. The WT:NORM tag can't be. I don't know how this is determined. You should just ignore the WT:NORM tag because it says something about the entire wikitext in the page and not your edit in particular. — Eru·tuon 18:23, 17 May 2020 (UTC)[reply]

There have been previous discussions about the "WT:NORM" tag and whether it should be abolished. Apparently it mostly refers to picky whitespace infringements. For "ordinary" editors the tag is largely useless, not least because there is apparently no way to discover what is wrong, but apparently it is of limited use to some people. Mihia (talk) 20:43, 21 May 2020 (UTC)[reply]

Chinese templates triggering filters[edit]

1. When I create a new simplified Chinese entry using {{zh-see}} I get a warning that I don't have both an L2 and L3 header and I have to submit a second time to confirm. The message points me to the grease pit to report false alarms so here I am. The convention I infer from existing pages is you don't need an L3 on a simplified Chinese page if the simplified form applies to all senses. (Randomly chosen example of current practice: 鼠疮.)

2. I created some Chinese pages manually and was told I should be using {{subst:zh-new}} which adds some information automatically. I tried to go back and change existing pages replacing my hand coded wiki text with the template. Preview worked fine, but I couldn't publish the change because I had deleted all the L3 headers. Can the check for deleting headers be moved to after the substitution step? Vox Sciurorum (talk) 13:26, 18 May 2020 (UTC)[reply]

@Vox Sciurorum: I've made the level-3 header deletion filter use new_pst and exempted entries with {{ja-see}} and {{zh-see}} from the requirement to have both a level-2 header and a level-3 header. — Eru·tuon 18:29, 18 May 2020 (UTC)[reply]

Thanks. Is the source code for these filters visible to ordinary users? Vox Sciurorum (talk) 21:20, 18 May 2020 (UTC)[reply]

@Vox Sciurorum: Yeah, they're not top-secret enough to be hidden: filters 2 and 1. — Eru·tuon 21:29, 18 May 2020 (UTC)[reply]

@Erutuon: Thanks for that change. IP's and non-admin users complained about this problem in the past. The exceptions should be give to soft-redirects like this. --Anatoli T. ^{(обсудить}/^вклад) 01:20, 19 May 2020 (UTC)[reply]

The underlying problem is that the CJKV-language entry structure is technically in violation of all kinds of site-wide standards. We have to think about how to reconcile WT:EL with local community practice without destroying either.

By the way: were you aware that one of the Chinese modules enforces proper nesting of headers on the entire page that transcludes it? If you add a header to the Japanese or Vietnamese section that's at the wrong level, it throws a module error demanding that you fix it. I'm not sure how it would react to {{ja-see}}, though I would imagine that the combination of a full Chinese section with a soft-redirect Japanese section would be extremely rare. Chuck Entz (talk) 03:51, 19 May 2020 (UTC)[reply]

On further investigation, apparently Module:zh-forms only does this for numbered Etymology and Pronunciation headers, so it would never have a problem with soft-redirect Japanese sections. I wonder, though, if all of this rummaging around in the page's source is part of the memory problems we've been having with single-character entries. Chuck Entz (talk) 04:35, 19 May 2020 (UTC)[reply]

Citations misaligned[edit]

All the citations are misaligned. The current ones show up as 19th century, the 1500s show up as 14th century, etc. Surely it must be due to a new edit to a template because i would expect this to have been noticed quickly. —Soap— 16:37, 21 May 2020 (UTC)[reply]

@Soap: Where is this happening? — Eru·tuon 19:14, 21 May 2020 (UTC)[reply]

All Citations pages that I can find so far that have the century template {{timeline}}, although Ive only been looking at English words. e.g. Citations:cool has all the years positioned two centuries further left than they should be, as if there is a template coding error somewhere where a person put -1 instead of +1. It's also doing it on pages like masticate which are not Citations pages. Basically everything that I can find from Special:WhatLinksHere/Template:timeline shows the error. The template has been recently edited and I suspect the error is in there plain as day, but I cant quite piece it out. —Soap— 19:56, 21 May 2020 (UTC)[reply]

Actually I think I just fixed it after realizing there was a missing line in one area and an extra line in the other. But feel free to check over my work to make sure it's the best way to do it. —Soap— 19:59, 21 May 2020 (UTC)[reply]

Behaviour on loading long pages[edit]

Recently (let's say in the last couple of months), I notice that some Wiktionary pages seem to take multiple attempts to load and display properly. When I first open such a page, it appears at first to load normally, at normal speed. Then, a few seconds later, all the formatting disappears (e.g. I see browser default fonts throughout). Then the correct formatting reappears after another few seconds. Sometimes this cycle then repeats. One page where this happens fairly consistently is Wiktionary:Word_of_the_day/Nominations. I have also noticed it on some long page histories, after I have chosen the "500" option. I have not noticed it on any short pages, nor on the majority of normal articles. Of course I understand that for any large web page the browser takes time to download the page, interpret and apply the styles, flow the page etc., but this is new, distinctive and unusual behaviour specific to Wiktionary, or certain pages thereof, that I have not seen here before, and do not see, and have not seen, at other websites. Does anyone else experience this? Has something changed with the way Wiktionary serves the pages that could have caused this behaviour? Mihia (talk) 19:40, 21 May 2020 (UTC)[reply]

I haven’t noticed this when using the web version, but when I access the website on a mobile device, more often than not I have to reload pages to get them to display correctly. It’s very annoying. — SGconlaw (talk) 06:40, 24 May 2020 (UTC)[reply]

Month, year dates confuse quote-journal template[edit]

{{quote-journal|date=August, 2013}} yields "2020 August 23". Vox Sciurorum (talk) 23:57, 23 May 2020 (UTC)[reply]

Looks like the underlying PHP function doesn't like the comma, so it skips the year, and since it doesn't have a year or a day of the month, it uses the current ones, 2020 and (now) 24. — Eru·tuon 05:31, 24 May 2020 (UTC)[reply]

I went through all the "quote-" templates and fixed the ones that matched this pattern (month comma year). I've added an error for this particular pattern because it's rare. But there are many more without a comma or with numerical year and month, which behave in the same way: for instance, {{quote-journal|date=August 2013}} and {{quote-journal|date=2013-08}}. Either these should all be fixed by bot and then an error message should be displayed, or Module:time should just treat these dates correctly. The latter is less disruptive for editors who use these date formats. — Eru·tuon 06:04, 24 May 2020 (UTC)[reply]

Module:time/testcases shows all the date formats used in the quote templates and the resulting output from the date-formatting function in Module:time. Some of the common date formats are not interpreted correctly, including these year-month formats. — Eru·tuon 01:06, 25 May 2020 (UTC)[reply]

I suggest the test inputs "17.03.19" and "05-2-27" generate an error because those styles are potentially ambiguous. Vox Sciurorum (talk) 18:46, 28 May 2020 (UTC)[reply]

@Vox Sciurorum: I agree. That's what I meant by putting question marks as the expected value for those two. — Eru·tuon 05:16, 29 May 2020 (UTC)[reply]

Unsupported titles/Colon three[edit]

This page contains the emoticon ":3". I attempted to create this unsupported title page, and I can't figure out why the title is showing up on my browser as "Colon_three", whereas it should show up as ":3". On other unsupported title pages, the title at the top shows up correctly. PseudoSkull (talk) 02:41, 24 May 2020 (UTC)[reply]

You might have to add it to Module:unsupported titles/data. —Μετάknowledge^{discuss/deeds} 02:56, 24 May 2020 (UTC)[reply]

It also needs to be added to MediaWiki:UnsupportedTitles.js to fix the display on the page, and Module:links/data to let linking templates link to it. (This is confusing; there should be just one page to edit.) Done. — Eru·tuon 06:08, 24 May 2020 (UTC)[reply]

Yes, or at least each page should include a notice of which other pages also need to be updated! Could the module look at and pull whatever it needs (in terms of: what to replace, and what to replace it with) from the .js page, or vice versa? And the link module pull what it needs from the unsupported titles module, or vice versa? Or would this use up too much memory... - -sche (discuss) 03:31, 8 June 2020 (UTC)[reply]

Missing passage= gives weird error[edit]

Leaving out passage= in a quotation gives a misleading error message. I guess the argument lands in the numbered slot reserved for a year.

{{quote-journal|en|date=December 31, 1969|This is some text which I forgot to mark with passage}}

Lua error in Module:quote at line 170: Only one of date= or year= should be specified

If the error had said "This is some text" is not a valid year I would have figured it out sooner. Vox Sciurorum (talk) 16:43, 24 May 2020 (UTC)[reply]

@Vox Sciurorum: You have answered your own question. The quotation text is in the numbered slot reserved for a year. Fay Freak (talk) 17:00, 24 May 2020 (UTC)[reply]

We don't attempt to validate years because there can be all sorts of things other than simply 4 digits, such as a year range, or some other approximation. DTLHS (talk) 17:02, 24 May 2020 (UTC)[reply]

But can we make the error message more informative? —Mahāgaja · talk 21:20, 24 May 2020 (UTC)[reply]

How about "was " + [parameter] + " meant to be the year?" followed by the current error message? Chuck Entz (talk) 23:02, 24 May 2020 (UTC)[reply]

At the moment the numbered parameters are just lumped in with the named ones, so the module doesn't know when the year is in a numbered parameter and when it's in |year=. But definitely the error message is worth improving here. — Eru·tuon 23:06, 24 May 2020 (UTC)[reply]

Collaborating with other Wiktionaries' pronunciation data[edit]

...is something we should definitely be doing. Please write a programme to do it. --Undurbjáni (talk) 23:02, 24 May 2020 (UTC)[reply]

Even if this is technically possible, I frankly don't trust other Wiktionaries to get pronunciation data right. —Mahāgaja · talk 05:05, 25 May 2020 (UTC)[reply]

I'd trust fr.wiktionary to get French pronunciations right most of the time. --Undurbjáni (talk) 09:00, 25 May 2020 (UTC)[reply]

Thanks for the suggestion. Search for squeakynox at the party. This can be used to mine pronunciation data from Wiktionary: https://github.com/kylebgorman/wikipron WelcomeSnack (talk) 18:52, 25 May 2020 (UTC)[reply]

Some CSS for Vector has been simplified[edit]

{{int:Hello}}!

I'd like to make a double-check about a change that was announced in Tech/News/2020/21.

Over-qualified CSS selectors have been changed. div#p-personal, div#p-navigation, div#p-interaction, div#p-tb, div#p-lang, div#p-namespaces or div#p-variants are now all removed of the div qualifier, as in for example it is #p-personal, #p-navigation …. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them. This only impacts the Vector skin.

On this wiki, this impacted or still impacts the following pages:

How to proceed now? Just visit all these pages and remove div# before these CSS selectors if it hasn't been removed so far.

Thank you! SGrabarczuk (WMF) (talk) 13:03, 25 May 2020 (UTC)[reply]

Discrepancy between template lists of policies and actual set of policies[edit]

Hello, it seems that Template:policy-list, which is used in Template:policy-DP, Template:policy-TT, and Template:policy-ED, has become outdated and was only most recently updated in 2016! Upon comparing it to Template:policy, which appears to be more accurate, I noticed multiple discrepancies. Additionally, upon further investigation, I found three pages (Wiktionary:Wikidata policy, Wiktionary:Matched-pair entries, and Wiktionary:About sign languages) which were labeled with Template:policy or the similar Template:policy-VOTE, but which were not listed in Template:policy. This situation seems very confusing and contradictory to me, so I think that Template:policy-list and Template:policy should be updated to fix the discrepancies. Unfortunately, as seems to be a running trend for myself recently, I am unable to enact such a fix myself because I lack the necessary permissions, specifically I am not a template editor nor an administrator. Because of that, I've created this post to make the following requests, first that Template:policy-list be modified to include all of the pages currently listed as part of Template:policy as well as the three aforementioned pages that are currently excluded from Template:policy. Second, that Template:policy be modified so that instead of containing its own copy of the list of English Wiktionary's policies it transcludes Template:policy-list. This would allow for the existence of a centralised list of policies and mean that it would not be necessary to update both Template:policy-list and Template:policy every time a change to the set of policies occurs. Thanks. —The Editor's Apprentice (talk) 18:04, 26 May 2020 (UTC)[reply]

Hsi-ning[edit]

Hello all- I would like the review of the community on what's going on with the Hsi-ning page (see also Talk:Hsi-ning). I don't want to be prevented any longer, not one moment, from providing the English speaking community of our world with an open source dictionary / encylopedia that includes the geographical terms used to describe China in all our books and maps from the 20th century. --Geographyinitiative (talk) 08:33, 28 May 2020 (UTC)[reply]

Alternative spellings shouldn't even have etymologies. The etymology goes in the main entry. --Lvovmauro (talk) 02:49, 5 June 2020 (UTC)[reply]

@Lvovmauro: He is keen to add etymologies to the alt spelling, which is different from the modern spelling.

@Geographyinitiative: If you already stopped misusing the transliteration for Mandarin with non-standard transliterations in |tr=, I can unblock the page a bit later, however, you are not in the position to demand anything, since you know very well why the page was blocked in the first place! --Anatoli T. ^{(обсудить}/^вклад) 03:13, 5 June 2020 (UTC)[reply]

I reject this blatant mischaracterization of the nature of my edits. --Geographyinitiative (talk) 03:17, 5 June 2020 (UTC)[reply]

Mischaracterization? I am being kind. You have a little history of misuses of standards and conventions. Talk:吃飽 is just one example. Some of your improvements are a result of fear of being blocked, not the understanding. Your ideas might be of interest on social networks, not in a dictionary work, which requires adherence to standards and cooperation. --Anatoli T. ^{(обсудить}/^вклад) 03:34, 5 June 2020 (UTC)[reply]

What are you doing? This is a for-fun non-profit dictionary website. Enjoy it. --Geographyinitiative (talk) 05:40, 5 June 2020 (UTC)[reply]

@Lvovmauro: Information about the etymology of the actual term should indeed go in the lemma entry. However, spellings themselves have their own derivations. Where else would such information go other than an etymology section? There have been a few Japanese alternative spelling entries where I have added information to the ===Etymology=== section of the alt spelling entry to explain the derivation of the alternative spelling itself. Such information would be out of place in the lemma entry. ‑‑ Eiríkr Útlendi │^{Tala við mig} 06:26, 5 June 2020 (UTC)[reply]
@Anatoli, I reserve the right to be wrong :), but I think we should give Geographyinitiative the benefit of the doubt in this case (the Hsi-ning entry, anyway). FWIW, I agree with the point made earlier that "Chinese Mandarin" is a weird label compared to the more-common "Mandarin Chinese". (For that matter, what about just saying "Mandarin", as the regular format output from {{bor|en|cmn|...}}?)

Rather than view me as a rule breaker that must be stopped for the sake of order, see me from the perspective of being a revolutionary that has brought you coverage of areas no one else dared to attempt to cover. This is the website you guys have created- a twisted world where words used in English language documents throughout the 20th century but that are no longer politically correct according to internet misapprehensions of CCP policy can be persistently ignored- yikes! It's not me that's sick guys. Geographyinitiative (talk) 17:28, 5 June 2020 (UTC)[reply]

I see you as someone so clueless that you mistake trivial details of formatting for epic social and political issues. Do you also congratulate yourself on the revolutionary way you eat your lunch? Chuck Entz (talk) 19:01, 5 June 2020 (UTC)[reply]

What you portray here as trivial spelling differences is actually a major impediment to reading comprehension for people that only speak English. Once you understand that native English speakers can't necessarily make the link between Hanyu Pinyin and corresponding Wade Giles forms etc romanizations without help, then you will see the value of this work my friend. Geographyinitiative (talk) 20:35, 5 June 2020 (UTC)[reply]

To the hyperliterate people that write dictionaries, it's easy to see that Matsu and Mazu may be related terms. Other people may not know! Geographyinitiative (talk) 20:53, 5 June 2020 (UTC)[reply]

(Also, anyone that actively eats healthy is really bucking the system. I'm not that much of a revolutionary!) Geographyinitiative (talk) 21:12, 5 June 2020 (UTC)[reply]

I realized that adding Wade-Giles derived forms would be shocking to this community because academia teaches us to look down on any romanization that is not Hanyu Pinyin as antiquated or useless. I was the user who got the ball rolling on Tongyong Pinyin. All those arguments against these romanizations may be 100000 percent right, but what is not right is to pretend that these words are not a component of the English language in some contexts, as I have clearly demonstrated. Now, people can use Wiktionary to look up some of the main geographical terms derived from Chinese characters and romanized with Wade Giles that they may see while reading journals, books and atlases that use these terms. It is a despised and unloved part of English, but it is a part of English. Geographyinitiative (talk) 04:05, 6 June 2020 (UTC)[reply]

There you go with the grandiosity again. What you did was like putting sugar in a salt shaker: it's not that either is better or worse than the other, but people shouldn't be getting one in a context where they're expecting to get the other. Chuck Entz (talk) 07:01, 6 June 2020 (UTC)[reply]

If I want to be another narcissist in this thread, I will make a revolution and will do what nobody has done before, I will transliterate into a neglected Cyrillisation of Chinese words. Moreover, I will add IPA, so people know exactly what they have missing out on! There you go:

Cyrillic 南京 (Наньцзин)
IPA 南京 (nän³⁵ t͡ɕiŋ⁵⁵)

Can I add Arabic or Hindi? Don't you dare to criticise me for misusing |tr=, I am making a revolution here! (sigh). --Anatoli T. ^{(обсудить}/^вклад) 08:03, 6 June 2020 (UTC)[reply]

If I may be allowed to attempt to respond you with my own analogy- what I did is more like the rule of etiquette where you always pass the salt and pepper together. Yes, you can add Arabic and Hindi, if that's part of the etymology for an Arabic or Hindi romanization of a Chinese character term- the Wikipedia and Wiktionary projects ARE a revolution for the enlightenment of humanity. Geographyinitiative (talk) 08:07, 6 June 2020 (UTC) (modified)[reply]

Your word salad is tiring. You were told a million times. Everything is important, nothing is discriminated against but everything must be used appropriately, not mixed when something else is expected or required. You simply CAN'T use Min Nan POJ in a group of Mandarin words with no labelling, or Wade-Giles or whatever is related to word, even if it's important, if user expecting a romanisation they're familiar with because this is how transliteration works, what is appropriate. You add IPA only in the pronunciation section, with the right templates, which have link to a pronunciation key. You do add Hindi and Arabic but not AS the transliteration of English words. You continue to do it, puffing your cheeks and pretend this is a revolution. It's not a revolution, it's a mess, salt mixed with sugar. Even exaggerated examples don't tell you how bad it is what you're doing. I have nothing more to say, go and stuff your user page with your verbal diarrhoea. In my opinion, you should stay away from editing in the main space. You don't have what it takes. --Anatoli T. ^{(обсудить}/^вклад) 08:50, 6 June 2020 (UTC)[reply]

The fact that I have slightly different opinions from you doesn't mean either you or I are "wrong". There's some level of subjectivity here. You helped me create a good template for explaining Wade-Giles derived terms to modern readers, and I thank you for that and other work you have done. Please don't hate me- let's be allies in the overall struggle to make a useful dictionary resource for mankind. Geographyinitiative (talk) 09:16, 6 June 2020 (UTC)[reply]

It's nothing personal. I don't know you in the real life but you need to learn to do things the right way but you start getting defensive. I do make mistakes, everyone does, but they are unintentional.

Let me give you some examples. If you're familiar with programming or maths, programming languages and mathematical functions take certain parameters, they often need to be of a certain type. If you don't follow simple rules, you either get an error (like square root of "apple")) or an unexpected result (a string instead of a number). Linguistics is not a very precise science, there are too many exceptions and the way people express the same ideas may not follow any logic or be very inconsistent. If we, dictionary editors, make things worse by deliberately not following the expected parameters, then we are not good editors. All you had to say, was "yeah, that doesn't seem quite right". Do you think you know why some templates, such as {{IPA}} throw errors sometimes? It's because editors may use wrong characters. |tr= won't throw an error if you use unexpected characters, such as Cyrillic or Arabic or Devanagari but nobody does it because we only transliterate on the English Wiktionary into symbols with appropriate scripts and sets of letters expected for a particular language. Now, why do you think it would be a bad idea to use a Korean transliteration 東京 (Dokyo) on a Japanese word with no labelling? The answer is obvious and you know it, I am sure. A user without any Japanese or Korean knowledge may think that "Dokyo" is a standard Japanese Hepburn transliteration. The expected and the right way would be to use the expected transliteration for the appropriate language, right? That is, Japanese 東京 (Tōkyō) should get "Tōkyō" and Korean 도쿄 (Dokyo) should get "Dokyo". Why then you mix pinyin and POJ, pinyin and Wade-Giles? Why don't you see this as a problem?

Am I wasting time? Please tell me if it makes sense to you. I don't hate anyone. Just please do the right thing. --Anatoli T. ^{(обсудить}/^вклад) 09:56, 6 June 2020 (UTC)[reply]

Another analogy: most people see a line with a "Wet Paint" sign and stay back. You, on the other hand, proclaim grandly that the sign is an ideologically-based ruse to keep people behind the line. You walk across it and track wet paint all over. You then interpret complaints about the paint as shock at the very idea of transgressing boundaries, and confirmation that you're on the right track.

There are two errors here: making a mess, and insulting those who object by asserting nonexistent ulterior motives. The first is why you're getting rolled back and blocked. The second is why people like Anatoly get especially angry at you (as if the mess wasn't reason enough). Chuck Entz (talk) 17:20, 6 June 2020 (UTC)[reply]

If there are problems with specific edits I have made, bring them up at that time or bring them up now. Last week, I made a lot of great edits. When is this discussion going to move from the realm of constructive criticism to into the realm of targeted abuse? Not a good atmosphere for creating an honest dictionary of English my friends. I add a few politically incorrect romanizations, and I get this? I can not respond to so much wild abuse at once guys. Geographyinitiative (talk) 23:31, 6 June 2020 (UTC)[reply]

I can't respond to this coversation any longer unless a specific edit is brought up and discussed for its merits. I am a little bit of a rabble rouser because I made the community see that it was missing a part of English that is looked down on. I talk about “revolution” for exactly this reason: I knew it would be hard to accept the fact that these words are part of English for some. But now all that is over- I have added the citations and sources. I have negotitated, compromised and accomodated. Let us learn to make common cause for a dictionary of all words used in English and not just those which we want to know about. Wiktionary is a great tool for helping people understand words. I am so proud to have participated. Geographyinitiative (talk) 23:58, 6 June 2020 (UTC)[reply]

Except that none of what you said is true: you're not a rabble rouser, the community doesn't view origin of English words from Wade-Giles as any different from origin of English words from Hanyu Pinyin, so you didn't make the community see anything new. It's not at all hard to accept that this is part of English because it was already obvious that it is and no one has any ideological objection to Wade-Giles. Your evidence didn't change anything because no one thought any different to start with. You keep describing barriers that aren't there, and ideological opposition that doesn't exist. The only objections have to do with what's practical and what will work, and with the total disconnect between the grand ideological battle that you keep talking about and anything even slightly resembling reality. Please stop making assertions about our ideology without providing evidence. Chuck Entz (talk) 06:33, 7 June 2020 (UTC)[reply]

I would argue that I, the lowest of the low, should not be the one adding these entries. As said above, it is true that I am probably not good enough to add material on the mainspace. So why would it be me, why did the website wait til me, to call for adding Tongyong Pinyin? Why would it be me that makes the Wade Giles entries? If what you said is really, actually true, shouldn't a vastly more competent and intelligent user have made these entries back in 2008 or so? Well anyway, I am glad that this is a safe space for all sourcable, citable words. What a great resource this is. Geographyinitiative (talk) 06:59, 7 June 2020 (UTC) '(modified)"[reply]

Wiktionary:Grease pit/2020/May

Contents

Regen WTconcord[edit]

IPs adding a newline between see-alsos and first header[edit]

Unami diacritics do not link properly.[edit]

Cmd-F is totally broken in module editing[edit]

Genitives with colons[edit]

<ref> tag but no <references/> tag![edit]

Reflexive verbs with Ukrainian conjugation templates[edit]

23.82 + 8.91 > 50?[edit]

Replace grave accents with acute accents for translations into Bulgarian[edit]

plural gender in `{{it-noun}}`[edit]

Dialect modules[edit]

ocior[edit]

Importing geographical terminology databases[edit]

Double linking a single entry in declension templates[edit]

Does acceleration need unique parameter names?[edit]

Merging entries[edit]

Cuneiform CLDR lookup is broken, likely many other pages[edit]

Some file names' casing is different. Why?[edit]

A lot of "Lua error: not enough memory" at the bottom of the "si" page[edit]

Add language links[edit]

Edittags[edit]

Chinese templates triggering filters[edit]

Citations misaligned[edit]

Behaviour on loading long pages[edit]

Month, year dates confuse quote-journal template[edit]

Unsupported titles/Colon three[edit]

Missing passage= gives weird error[edit]

Collaborating with other Wiktionaries' pronunciation data[edit]

Some CSS for Vector has been simplified[edit]

Discrepancy between template lists of policies and actual set of policies[edit]

Hsi-ning[edit]

Navigation menu

Wiktionary:Grease pit/2020/May

Regen WTconcord[edit]

IPs adding a newline between see-alsos and first header[edit]

Unami diacritics do not link properly.[edit]

Cmd-F is totally broken in module editing[edit]

Genitives with colons[edit]

<ref> tag but no <references/> tag![edit]

Reflexive verbs with Ukrainian conjugation templates[edit]

23.82 + 8.91 > 50?[edit]

Replace grave accents with acute accents for translations into Bulgarian[edit]

plural gender in {{it-noun}}[edit]

Dialect modules[edit]

ocior[edit]

Importing geographical terminology databases[edit]

Double linking a single entry in declension templates[edit]

Does acceleration need unique parameter names?[edit]

Merging entries[edit]

Cuneiform CLDR lookup is broken, likely many other pages[edit]

Some file names' casing is different. Why?[edit]

A lot of "Lua error: not enough memory" at the bottom of the "si" page[edit]

Add language links[edit]

Edittags[edit]

Chinese templates triggering filters[edit]

Citations misaligned[edit]

Behaviour on loading long pages[edit]

Month, year dates confuse quote-journal template[edit]

Unsupported titles/Colon three[edit]

Missing passage= gives weird error[edit]

Collaborating with other Wiktionaries' pronunciation data[edit]

Some CSS for Vector has been simplified[edit]

Discrepancy between template lists of policies and actual set of policies[edit]

Hsi-ning[edit]

Navigation menu

Search

plural gender in `{{it-noun}}`[edit]