Wiktionary

Wiktionary:Grease pit/2016/September

< Wiktionary:Grease pit

Can WT:ACCEL generate entries with two forms? edit

As some of you will know, -sche recently decided to cripple our coverage of Danish adjectives by deleting the template we used for a particular form, such that we are now supposed to pretend that there exist "definite forms" and "plural forms" (unlike every other major dictionary). In the process, they disabled the creation rule for that form, meaning new entries must now be made manually. If we absolutely must introduce this artificial and pointless distinction, can we at least bring back accelerated editing?__Gamren (talk) 12:09, 1 September 2016 (UTC)[reply]

Previous discussion is at Wiktionary:Requests_for_deletion/Others#Template:definite_and_plural_of, where there is no consensus for your idiosyncratic and only recently-introduced interpretation of the forms in a handful of (<90) entries. In Danish grammar and da:Dansk grammatik, I see that the indefinite singular, definite singular, indefinite plural and definite plural all have different endings; I see no two forms which could be combined by the template you were using as "definite and singular". Perhaps you thought you were using a Template:singular definite of/Template:definite singular of coordinating with a Template:plural definite of/Template:definite plural of? that wording is what was found in entries prior to your edits, e.g. at pesten and huset. - -sche (discuss) 17:21, 1 September 2016 (UTC)[reply]
Once again, you demonstrate a staggering ignorance on the subject. Nouns are inflected with respect to definiteness and number. pesten and huset are nouns, and I have never even edited any of those entries. I am talking about adjectives, which have a form that is used for definite plural, indefinite plural and definite singular (the latter, only when used attributively). If you scroll down, you will find that adjectives have (up to) three positive forms, of which one is called the e-form or plural / definite by the Wikipedians. I also did not add that form to {{da-adj}}; it was already there, back in 2014, long before I made my first edit. And as I have noted on the page you linked to, the interpretation I advocate is used by Den Danske Ordbog, Ordbog over det Danske Sprog (which is quite old by now), Retskrivningsordbogen (which is published by a government agency) and Nudansk Ordbog. It is not in any way idiosyncratic.
However, if you refuse to listen to reason, can we, as I requested, at least make editing easy again?__Gamren (talk) 08:11, 2 September 2016 (UTC)[reply]

Morse code images not showing up in mobile view (but are showing up in mobile edit previews) edit

For example at .--. (mobile version). Can one of the devs perhaps explain this nonsense? --WikiTiki89 15:10, 1 September 2016 (UTC)[reply]

Your link is working great to me. I'm accesing in on my notebook, so I'm not using an actual cell phone. I suppose you already fixed the problem? Or should we try accessing the page with an actual cell phone? Or is it still broken in actual cell phones? (edited for tone) --Daniel Carrero (talk) 19:56, 1 September 2016 (UTC)[reply]
I did not fix the problem. It still doesn't work for me, neither on my iPhone (in chrome, safari, and firefox), nor on my Windows computer (in chrome). --WikiTiki89 20:02, 1 September 2016 (UTC)[reply]
I don't know what would help. I would suggest cleaning the cache, (?) but since it is not working in any of the 4 mobile+navigator combinations you mentioned, my suggestion would probably be pointless. The Module code looks okay to me. --Daniel Carrero (talk) 20:09, 1 September 2016 (UTC)[reply]
Hmm... It's working now on my computer and my phone. Interestingly, it loads as invisible and then fades into view. Perhaps that fade is what wasn't working before. --WikiTiki89 11:51, 2 September 2016 (UTC)[reply]
Do other images load on your phone? Do they fade in/ behave like the Morse code does? I wonder if it matters that the same image is being loaded multiple times: try viewing [1]. Or perhaps the issue is that the images are being loaded by a template, especially one which I gather is fetching the page name in order to decide what images to load, which may be taking time (too long, so that it gets shut off?). - -sche (discuss) 04:41, 3 September 2016 (UTC)[reply]
"Loads as invisible and then fades into view" sounds like lazy loading. (also, why don't we get Tech News here) —suzukaze (t・c) 04:58, 3 September 2016 (UTC)[reply]
I wonder if it's possible to explicitly exempt certain small images from lazy loading, or at least disable the fade-in. @-sche, yes those and other images show up but also fade in. --WikiTiki89 18:05, 5 September 2016 (UTC)[reply]

Anagram format edit

Since the vote on anagram format (can anyone dig this up? Circa 2011) the format has never actually been implemented. I have initially tried to implement it for French and it's a bit too difficult for me to do. And that's just for French before starting on other languages.

I suppose ideally all the anagrams on the whole wiki need updating. I mean, why do we only do some languages and not all? But just updating the format without updating the words would be a good start. The format is 

===Anagrams===
* {{l|en|instar}}, {{l|en|sartin}}, {{l|en|strain}}

The old format was 

===Anagrams===
* [[instar#English|instar]]
* [[sartin#English|sartin]]
* [[strain#English|strain]]

Renard Migrant (talk) 20:17, 3 September 2016 (UTC)[reply]

I would prefer to use a single template: {{anagrams|en|instar|sartin|strain}}, since this section is almost never edited by humans. Of course this would require someone willing to run a bot to update all the entries. DTLHS (talk) 20:28, 3 September 2016 (UTC)[reply]
I oppose showing them all on one line. If we're going to use a list item, we should show them all in a list, as in the old format. —CodeCat 14:01, 4 September 2016 (UTC)[reply]
I would have separate lines for separate orders of letters, but keep things that are identical except for capitalization and diacritics on a single line, thus:
===Anagrams===
* {{l|en|ees}}
* {{l|en|ese}}
* {{l|en|see}}, {{l|en|See}}, {{l|en|sée}}
(I know most of the above aren't actually English words, it's just to illustrate my suggestion.) —Aɴɢʀ (talk) 20:56, 5 September 2016 (UTC)[reply]
The votes was Wiktionary:Votes/pl-2011-11/Update ELE anagram format (although language anchors were already in use then, so I don't know why I didn't include them in the example text). I've no objection to reviewing the anagram display format, although I don't think it's the most productive thing we could be doing. I'm not seeing a lot of appetite to change it. Renard Migrant (talk) 12:23, 9 September 2016 (UTC)[reply]

Special:Nuke edit

A point of usability: the selection links (All, None, Invert) on this page are dangerously close to the big Delete button. Can we add more space? Equinox ◑ 09:21, 4 September 2016 (UTC)[reply]

(How does one edit a special page, anyway?) Equinox ◑ 16:57, 17 September 2016 (UTC)[reply]
I have no idea. I imagine they are hardcoded into the software. —CodeCat 16:59, 17 September 2016 (UTC)[reply]
Apparently; at least, someone has previously had to ask the devs when they wanted the text changed (despite the comment "Looking at the i18n file for Nuke.. Those look like localised messages..."). - -sche (discuss) 17:41, 17 September 2016 (UTC)[reply]
I have no idea what is going on, but it seems like someone moved the button to the bottom of the page, which is not perfect (it's still very close to the lowermost tickbox) but better. Who did this?! Own up. I'm gonna keep the whole class in, until someone admits it. Equinox ◑ 05:44, 27 September 2016 (UTC)[reply]

Rundi error edit

  • Wiktionary:Language treatment: "Rwanda-Rundi is treated as a single language with the code rw. The ISO had coded the dialects separately, using rw for "(kinya)Rwanda" and rn for "(ki)Rundi", etc." DTLHS (talk) 14:04, 4 September 2016 (UTC)[reply]
    • Yes, I just saw that. There is a Rwanda-Rundi translation, with Wikipedia listing Rundi and Rwanda as being dialects of Rwanda-Rundi as opposed to individual national languages. However, there is no ISO language code for Rwanda-Rundi, only for the national lects. The translation module should be programmed then to display translations entered as RN under "Rwanda-Rundi," similar to how translations entered as BS (Bosnian) display under "Serbo-Croatian." Nicole Sharp (talk) 14:12, 4 September 2016 (UTC)[reply]
  • Here is another one I just noticed: "republic" is either "repubulika" (Rwandan) or "republika" (Rundi). I would advise allowing translations to be entered under both codes (RN and RW), and then having the dialectal differences in spelling listed separately as we do for Norwegian Bokmal (NB) versus Norwegian Nynorsk (NN), e.g. "Norway#Translations." Nicole Sharp (talk) 16:55, 4 September 2016 (UTC)[reply]
    The split of Norwegian into three languages (Bokmal, Nynorsk, and "Norwegian" for dialectal forms that belong to neither standard or forms that another standard) is controversial and not to be imitated. The small differences you have pointed out are hardly enough to hamper mutual intelligibility (and they rarely follow the lines denoted by the codes Ethnologue set up), which is indeed what a native speaker said when Metaknowledge consulted them before we merged the lects, following the linguistic literature which mostly treats Rwanda, Rundi, Vinza etc as dialects of one language. You may note that Serbian, Croatian, etc also have separate Wikipedias, but this is not an impediment to the merger of them, either. - -sche (discuss) 17:02, 4 September 2016 (UTC)[reply]
    • Words that are unique to only one of the Rwanda-Rundi dialects should be tagged with the {{lb}} template. Right now, {{lb|rw|Rwanda}} would put terms into "Category:Rwandan Rwanda-Rundi", which sounds ridiculous. Is there some way to edit Module:labels/data/regional to categorize into "Category:Rwanda" instead (and also have {{lb|rw|Rundi}} categorize into "Category:Rundi"), while still correctly categorizing CAT:Rwandan French and CAT:Rwandan English? But wait! Come to think of it, do we even want CAT:Rwanda to be for terms in the Rwanda variety of Rwanda-Rundi? Because Rwanda is also a country, and other categories named for countries are top-level topic categories, e.g. CAT:Thailand. So maybe we should keep CAT:Rwanda for the country and find some other name for "Rwandan Rwanda-Rundi". Suggestions? CAT:Kinyarwanda for the dialect? —Aɴɢʀ (talk) 21:09, 5 September 2016 (UTC)[reply]
      • @Angr, -sche: Yes, that needs to be dealt with. The dialects should display the name of the country in the label, but simply categorise as CAT:Kinyarwanda and CAT:Kirundi, in my opinion. (And the other lects merged into rw should be handled similarly.) —Μετάknowledgediscuss/deeds 00:14, 6 September 2016 (UTC)[reply]
        • The categories "Rwandan French" and "Kinyarwanda" are of the same type (both dialect categories, rather than e.g. one being a topic category), which complicates matters. Perhaps someone could add code that would make category names language-specific; this would also be useful for distinguishing e.g. "South Bavarian" (bar) from words hypothetically limited to "South Bavarian German" (de). Failing that, we could just use a different label "Kinyarwanda" to put terms into the Kinyarwanda category, and make "Rwandan Rwanda-Rundi" a cleanup category. - -sche (discuss) 04:42, 6 September 2016 (UTC)[reply]

A bot job request edit

Can please someone run a job to convert all transliterations to lower case for languages where transliterations should only be in lower case?

There were previous agreement on this but please comment if you object to this. Some casual editors still capitalise Persian and Hebrew transliterations.

Obviously, Cyrillic, Greek and Armenian capitalisations should match the native spelling and they use mostly automatic transliterations, anyway.

Languages, which DON'T use capital letters in their scripts but capitalised transliterations are allowed are only:

  1. Some Chinese lects - Mandarin, Min Nan, Min Dong, Hakka but not Cantonese, Wu, etc.), Japanese and Korean. No need to to do anything with these languages.

My request is mainly for these:

  1. Capital letters for Arabic, Hindi, Bengali and various Indic languages (e.g. Dravidian group) have a different phonetic value but they are mostly converted and largely rely on automatic transliterations. Arabic entries have been mostly fixed by User:Benwing/User:Benwing2
  2. Persian, Hebrew, Yiddish, Pashto still use capital letters. They all need to be turned to lower case in entries and translations, including proper nouns.

--Anatoli T. (обсудить/вклад) 07:14, 5 September 2016 (UTC)[reply]

Perhaps Gothic should be added to this list. There's the added complication that the transliterations have entries, and they're often capitalised even though the original script had no such distinction. But I believe that we shouldn't be inventing case distinctions, not just for Gothic but for any language. This includes Japanese, Chinese, as well as old European languages written before casing was a thing. —CodeCat 21:40, 5 September 2016 (UTC)[reply]
We've discussed this before. For Chinese and Japanese, the case distinctions are invented for us by the language governing bodies, and while I still don't like it, it's still more acceptable to me than inventing case distinctions ourselves. --WikiTiki89 22:50, 5 September 2016 (UTC)[reply]
Ok, if they're official, then leave it. What about the rest, though? There's no official spelling for Old English; Englisc was not written with a distinct capital letter in any manuscript. It's an anachronism based on modern English spelling. —CodeCat 22:54, 5 September 2016 (UTC)[reply]
For the rest I agree. The problem with languages like Latin, however is that the capitalization rules changed throughout the history of what we consider to be Latin. In Classical Latin, there was only one lettercase, but later on (well, much much later on) capitalization did develop. But I also guarantee that for most of our early modern languages, the attested capitalization is different from our capitalization. It's a big mess and most people seem to be against solving it. --WikiTiki89 00:21, 6 September 2016 (UTC)[reply]
  • Don't forget Georgian either. In official use, Georgian is unicase, but it is still acceptable to capitalize using Asomtavruli letters. For languages that have optional capitalization like Latin and Georgian, I would say to definitely keep the capitalized transliterations, even if the translation does not use capitalization. Nicole Sharp (talk) 03:55, 8 September 2016 (UTC)[reply]
    • No, not true. Modern Georgian does not have optional capitalization. Anyways, Asomtavruli has its own unicode range, so optional capitalization can be handled by the module.--Giorgi Eufshi (talk) 09:24, 9 September 2016 (UTC)[reply]
      • Look, it's pretty simple, transliterations should keep capitalization of the original script if it has any and not add any new capitalization (or remove any capitalization). There's no more theory to it than that. Whichever Georgian entries are entirely in the unicase Mkhedruli, as (nearly?) all of them are, should have unicase transliterations. If we are transliterating text that uses Asomtavruli as capitals, then the Asomtavruli should be transliterated as capitals. --WikiTiki89 13:46, 9 September 2016 (UTC)[reply]
The easiest (only) way this is going to happen is with lots of tracking categories: for each language and for each template that needs to be converted. DTLHS (talk) 14:06, 9 September 2016 (UTC)[reply]
Or with a bot, which is the purpose of this thread. --WikiTiki89 14:27, 9 September 2016 (UTC)[reply]
Yes, a bot that is fed with tracking categories. DTLHS (talk) 14:30, 9 September 2016 (UTC)[reply]
It doesn't need to be fed with tracking categories. It can just do a dump analysis, which is easier and faster. --WikiTiki89 14:32, 9 September 2016 (UTC)[reply]
Categories will allow us to detect the problem even after the original bot run is complete. DTLHS (talk) 15:06, 9 September 2016 (UTC)[reply]
Sure, but we don't need the categories for the original bot run. That's all I wanted to say. --WikiTiki89 15:10, 9 September 2016 (UTC)[reply]

French IPA module error edit

On brancher, Joconde and a couple dozen other pages there is the following error: "Lua error: bad argument #1 to 'lc' (string expected, got table)/, /Lua error: bad argument #1 to 'lc' (string expected, got table)" - -sche (discuss) 04:53, 7 September 2016 (UTC)[reply]

Sorry, my breakage. Fixed. Benwing2 (talk) 08:13, 7 September 2016 (UTC)[reply]
Thanks. - -sche (discuss) 18:05, 8 September 2016 (UTC)[reply]

Template:haw-IPA edit

Can anyone figure out why this is in Cat:Pages with module errors? No error is displayed and there's nothing obviously wrong with the code to my admittedly untrained eye. Chuck Entz (talk) 12:26, 7 September 2016 (UTC)[reply]

  Fixed. The module errors were hidden in the if statements (essentially {{#ifeq:[module error]|...}}) and therefore not displayed. --WikiTiki89 14:01, 7 September 2016 (UTC)[reply]

Image sizes edit

What image sizes can be used? I found "350px", are there others? DonnanZ (talk) 09:35, 8 September 2016 (UTC)[reply]

What do you mean can be used? Any size can be used. --WikiTiki89 10:11, 8 September 2016 (UTC)[reply]
I meant what sizes are recognised by the system, obviously 350px is one. DonnanZ (talk) 10:32, 8 September 2016 (UTC)[reply]
Any size is recognized by the system. --WikiTiki89 10:36, 8 September 2016 (UTC)[reply]
Right. (But for the record, the default sizes "thumb" and "upright" should be used in most cases so that users' preferences for what size they want images to display at are respected, unless there is a specific reason to deviate, such as that a non-SVG image is designed to appear at a smaller size than the usual thumbnail size.) Wikipedia has a tutorial, which notes that you can even specify a size like upright=1.35 to display something at 1.35 times the user's preferred base size. - -sche (discuss) 18:05, 8 September 2016 (UTC)[reply]
I will have to do some experimenting on this. I did scale down one image I filched from Nynorsk Wikipedia (satellittbilete) from the given 350px as I felt it was too big, but on the other hand I used 350px to scale up the image at tramshed, which I think gives a better result. DonnanZ (talk) 18:20, 8 September 2016 (UTC)[reply]
Don't forget that everyone has a different screen size, so if you adjust it to look good on your screen, it might make it worse on other people's screens. That's why it's better to stick with the default as much as possible. --WikiTiki89 18:28, 8 September 2016 (UTC)[reply]
Yeah, my screen is about 18.5", but I guess anyone can alter an image size if they aren't happy with it. DonnanZ (talk) 18:45, 8 September 2016 (UTC)[reply]
It's not only the inches but also the resolution and just the size that the browser window happens to be. People also use Wiktionary on mobile devices. I hope by your comment you're not expecting every user who is unhappy with image sizes to edit the page himself. --WikiTiki89 18:53, 8 September 2016 (UTC)[reply]

n/a edit

diff. What the Hell's actually changed here? I've copied and pasted both of them and they both go to English. Renard Migrant (talk) 20:09, 8 September 2016 (UTC)[reply]

Two characters of U+FFFC (OBJECT REPLACEMENT CHARACTER) were inserted on either side of the word "English". No idea why. --WikiTiki89 20:12, 8 September 2016 (UTC)[reply]
They were trying to get around Abuse Filter 52. I created it to deal with a very specific type of vandalism (I won't go into detail here for obvious reasons), but it catches some very interesting other types, including a misconfigured bot that seems to be hunting out insecure servers to post gibberish from. So far, only one false positive and no one's figured it out yet. Chuck Entz (talk) 02:57, 9 September 2016 (UTC)[reply]

Audio recording now working in Chrome edit

As of the latest Chrome update I have received (version 53.0.2785.101 m), the audio recording functionality is now working: the "Add audio pronunciation" appears within entries (it didn't before) and recording and playback are working. I haven't tried saving one yet because my Webcam audio is a bit noisy; I'll try it with a headset at some other point. Equinox ◑ 21:15, 9 September 2016 (UTC)[reply]

My headset won't record properly (it's very quiet, barely audible, and I've tried everything, e.g. changing USB ports, setting vol to 100% with boost, reinstalling drivers...). Should I record loads of pronunciations with my Webcam even though it's a bit hissy? No point bothering if the files will need replacing. Or can we build in a noise/hiss filter into the recording gadget (LOL I doubt it). Equinox ◑ 17:58, 11 September 2016 (UTC)[reply]
Maybe upload the quiet ones, then [ask someone to] reprocess them with another external audio editing program...? (just an idea) —suzukaze (t・c) 18:04, 11 September 2016 (UTC)[reply]
I have tools to do noise reduction myself, but then I can't use the gadget and there's the awful ten-step process of licensing, uploading, linking... So I think I won't bother for now. I'll try my headset on another PC and see if it's actually broken, though I think it's some deep obscure issue with my specific computer. Equinox ◑ 19:32, 15 September 2016 (UTC)[reply]

VL-verb module edit

I've created Module:User:KarikaSlayer/VL-verb (demo: User:KarikaSlayer/VL-verb/test) as a replacement for {{VL-conj}} and family. The module is set up to show separate tables for different Romance branches along with forms unique to that branch (instead of just Italo-Western Romance). Any thoughts/criticism? KarikaSlayer (talk) 03:30, 10 September 2016 (UTC)[reply]

Manichaean transliteration edit

@Vahagn Petrosyan: I've made a Manichaean transliteration module at Module:Mani-translit. I guess I should make a transliteration appendix too. Do you have any comments on this? I'm not sure whether I like all the specific transliteration (for instance, the transliteration of the aayin 𐫚 (ʿ̈)). —JohnC5 04:55, 10 September 2016 (UTC)[reply]

@JohnC5: Thank you for making the module. I prefer c instead of č and x instead of q̇. That is what DMMPP uses.
I have two concerns about using the native script for Manichaean. As far as I know, no font supports Manichaean, which is why we have been using the Latin transliteration. Also, if we use the module with automatic transliteration, where would the transcription go? For languages with defective writing systems, such as Manichaean or Pahlavi, both transliteration and transcription should be shown. That is how the academic literature does. Currently we cheat and give the transcription in place of transliteration, like this: Middle Persian bzyšk (bizešk). We should probably have an additional parameter for transcription, so that {{m|pal|𐫐𐫢𐫏𐫉𐫁|transcription=bizešk}} renders like 𐫐𐫢𐫏𐫉𐫁 (bzyšk /bizešk/). That would also solve the problem with Thai transliteration/transcription about which people have been fighting. --Vahag (talk) 10:42, 10 September 2016 (UTC)[reply]
That would be a very interesting idea that would also help out with things like Mycenaean Greek, Hittite, Old Persian, and numerous other abjads and syllabaries. Let me pull in @CodeCat, Wyang, Dan Polansky, Chuck Entz. —JohnC5 15:01, 10 September 2016 (UTC)[reply]

Page layout problem edit

The page stitch up displays incorrectly in IE and Edge. There is a large blank space at the top of the page to the left of the picture, and all the text content is pushed down below the picture. It is a consequence of the combination of "was wotd" with "File:" The page displays correctly in Chrome. I'm not sure whether it is a browser glitch or whether Wiktionary is generating badly-formed HTML that Chrome handles gracefully but the other browsers do not. The following fixes the problem, but it seems a bit of a hack:

<div style=float:right> {{was wotd|2016|May|27}} [[File:Fotothek df roe-neg 0000071 001 Portrait einer jungen Frau mit Nähzeug.jpg|thumb|A young woman with her sewing kit in Germany in the 1940s]] </div>

Is there any better way to work around this? 109.146.248.82 17:29, 10 September 2016 (UTC)[reply]

Here is a minimal example that looks fine in Firefox and Chrome but not in IE or Edge. It seems to be a combination of the two divs with "clear: right; float: right;" and the heading with "overflow: hidden;". I'm not sure what the solution is from our point of view - presumably there are other affected pages? Edit: indeed there are: adder, adhocracy, anneal, alabaster, acheiropoieton (continued ad infinitum...) Keith the Koala (talk) 19:04, 10 September 2016 (UTC)[reply]

Ⰼ edit

I notice that the module which supplies transliterations of OCS/Glagolitic does not transliterate Ⰼ ⰼ (Đ đ) (or, transliterates it as itself). Presumably it should transliterate it to Latin script, regardless of whether we lemmatize words on that spelling, since Ⰼ mentions words spelled with this letter. How should it be transliterated? - -sche (discuss) 18:28, 10 September 2016 (UTC)[reply]

Perhaps Đ/đ? --WikiTiki89 19:40, 10 September 2016 (UTC)[reply]
I have implemented my own suggestion. --WikiTiki89 15:39, 12 September 2016 (UTC)[reply]
@Wikitiki89 Thanks. The character is hard to search for, so I couldn't find any works that used/transliterated it at the time I posted. I've now managed to find a few books which transliterate it, including the Handbook of Old Church Slavonic of G. Nandris, as edited (translated?) by Robert Auty, and Horace Gray Lunt's Old Church Slavonic Grammar, which both transliterate Ⰼ as ǵ. Is a switch to that transliteration in order? The different Old Cyrillic Ꙉ (Đ) of the same name ("djerv") may equate to đ, per WP, but indeed the etymology of the entry Ⰼ suggests that a g-like transliteration for the Glagolitic letter may be more appropriate for it (in words it seems to have come to be represented by г/ѓ in some languages, per Lunt). - -sche (discuss) 17:33, 17 September 2016 (UTC)[reply]
The letter ѓ is only used in Macedonian, in which it represents historically the same phoneme as Serbo-Croatian đ/ђ (the latter Cyrillic character is actually derived ultimately from the Old Cyrillic character Ꙉ that you mentioned). The phoneme itself is is a reflex of Proto-Slavic *-ď- < *-dj-. --WikiTiki89 20:18, 17 September 2016 (UTC)[reply]
@-sche, Wikitiki89 In most of the attested OCS corpus, ⰼ is only used as an equivalent of г҄, that is, the variant of г found before front vowels in loanwords, e.g. ⰰⱀⰼⰵⰾⱏ (anđelŭ), анг҄елъ (angʹelŭ), ангелъ (angelŭ) are found as variants of the same word, which is why it’s usually transliterated as ǵ. However, it’s widely believed that the originally intended value of the letter was a palatalized dʲ, possibly to represent Proto-Slavic *ď in some dialects (although by this time *ď probably already diverged to žđ or even žd in the Bulgarian area); evidence in favor of this includes the very early (before 893 AD) Alphabet Prayer of Constantine of Preslav, which gives дѣть as a word starting with ⰼ. (See Veder’s The Glagolitic Alphabet as Text in Glagoljica i hrvatski glagolizam, 2004; Stjepan Damjanović’s grammar Staroslavenski jezik also agrees.) Later texts from the western Balkans also use the Cyrillic equivalent Ꙉ to represent Proto-Slavic *ď or sometimes *j, although they fall outside the OCS period. Despite this, Serbo-Croatian works conventionally transliterate ⰼ as ĝ. I’d say both đ and ǵ are perfectly justifiable, but we should, in any case, give Ꙉ (Đ) a transliteration as well, since cu also encompasses later Church Slavic. —Vorziblix (talk) 00:29, 28 November 2016 (UTC)[reply]
@Vorziblix In your view, would it be better to transliterate both Ⰼ and Ꙉ as đ, or to distinguish them by changing Ⰼ to ǵ? - -sche (discuss) 02:48, 29 November 2016 (UTC)[reply]
I’d keep them both đ. —Vorziblix (talk) 06:04, 29 November 2016 (UTC)[reply]
In the absence of objections, I’ve gone ahead and implemented that, and also added a transliteration for ⱒ (x). —Vorziblix (talk) 05:50, 30 November 2016 (UTC)[reply]

Template:R:The Bokmål Dictionary, Template:R:The Nynorsk Dictionary edit

These have a new Internet address, and searches are now being affected by the change. The new address is http://ordbok.uib.no, probably due to the recent move from Oslo University to Bergen University. DonnanZ (talk) 14:03, 12 September 2016 (UTC)[reply]

What needs to be edited is Module:Template:R:The Bokmål and Nynorsk dictionaries, though I'm not sure how. —Aɴɢʀ (talk) 14:18, 12 September 2016 (UTC)[reply]
I wish it was as easy as amending the address in Favourites on my computer... DonnanZ (talk) 20:11, 12 September 2016 (UTC)[reply]
I think I've fixed it (tested successfully with onsdag), but all entries may need the "null edit" to update their template usage. Equinox ◑ 20:16, 12 September 2016 (UTC)[reply]
The fix will propagate without null edits. Null edits and purgues just force it to happen immediately. --WikiTiki89 20:18, 12 September 2016 (UTC)[reply]
Yes, it's working for onsdag, but not for hånd and hånd-, so maybe æ, ø and å need special treatment. DonnanZ (talk) 20:27, 12 September 2016 (UTC)[reply]
It's working for me at hånd and hånd-. --WikiTiki89 20:34, 12 September 2016 (UTC)[reply]
They are now, I null-edited them both, so the system has to catch up. Thanks to Equinox. DonnanZ (talk) 20:37, 12 September 2016 (UTC)[reply]

Collapsible nested tables edit

I have an experimental template {{hu-possessive}} with nested collapsible tables based on the possessive forms table {{qu-poss-noun}}. When the table is first opened, six rows are displayed. I'd like to add more information to the six header rows besides the current "first-person singular", etc. I'd like to display the nominative row's singular and plural entries, so it would say: first-person singular | emberem | embereim. Is this technically feasible? Is there a better solution for collapsible tables, perhaps using mw-collapsible? Thanks. --Panda10 (talk) 15:30, 12 September 2016 (UTC)[reply]

That's not just feasible, but actually quite easy; the first-person singular actually appears as such in the template definition, and it's easy to edit it to add other stuff there. But that template doesn't yet support showing declensions of different words on different pages, which is certainly the most basic requirement for a declension template; so it seems premature to be worrying about niceties like you describe. —RuakhTALK 06:43, 17 September 2016 (UTC)[reply]

History merges: Are they worth it? edit

I found on Wikipedia how to merge the histories of two pages when merging two pages. I tried it a couple times today, for example when merging бєз into без. If you look at the history of the page без, you will see a bunch of edits that seemingly remove large amounts of text; those are the edits that were merged from бєз. So I'm wondering: Is it worth preserving the history of the old page despite the strange way it shows up? --WikiTiki89 21:09, 13 September 2016 (UTC)[reply]

Isn't the idea that we preserve the whole history of all contributions? I thought it was part of the wiki religion, not to be questioned on utilitarian grounds. DCDuring TALK 22:23, 13 September 2016 (UTC)[reply]
Well we already don't do that absolutely always. But still don't you think that the history merge makes the history a little confusing? --WikiTiki89 22:28, 13 September 2016 (UTC)[reply]
(e/c) The resulting merged history is hard to make sense of because of the way it's linearized; I would probably say it's not worth it for this reason. If you hadn't told me that this was the result of a history merge, I'd have a hard time figuring out what the hell was going on. It's unfortunate that the merged history can't be displayed in a more sensible way. Benwing2 (talk) 22:34, 13 September 2016 (UTC)[reply]
They are certainly worth it when required by the licenses, when they aren't required they are probably not worth it. - TheDaveRoss 23:43, 13 September 2016 (UTC)[reply]
@TheDaveRoss: When are they, and when are they not, required by licenses? --WikiTiki89 02:27, 14 September 2016 (UTC)[reply]
All content created by contributors must be attributed. This is best done via the edit history, but I've seen it done for interwikis by a listing on the talk page, and even an edit summary will suffice for something like copying from one entry to another, where it's just a matter of pointing to the location that has the edit history. Content from non-copyrighted sources doesn't require attribution as far as licensing goes, and edit histories aren't attribution in such cases anyway. I believe content that has been permanently removed wouldn't require attribution, either. Chuck Entz (talk) 03:43, 14 September 2016 (UTC)[reply]

R:World Wide Words edit

Can someone help figure out what is wrong (if anything) with {{R:World Wide Words}}? I used it on on the wagon, but it produces the link http://www.worldwidewords.org/qa%2Fqa-wag1.htm (note how the "/" is replaced by "%2F"), which generates an error and does not load the correct page http://www.worldwidewords.org/qa/qa-wag1.htm. Thanks. — SMUconlaw (talk) 18:19, 14 September 2016 (UTC)[reply]

@Smuconlaw: Fixed. Isomorphyc (talk) 17:05, 15 September 2016 (UTC)[reply]
Great, thanks! — SMUconlaw (talk) 17:15, 15 September 2016 (UTC)[reply]

NavFrame question edit

I created a new template to replace the current Hungarian possessive template in order to contain all inflected forms instead of only a few. The new table uses NavFrame and because of that it looks slightly different than the old one. Please see both tables here: {{hu-infl-pos-table-comparison}}. The name of the collapsing links are different: more/less vs show/hide. NavFrame works better for long tables in Mobile view because it keeps the table collapsed, while in the current solution tables are always open in Mobile view and are not collapsible at all. The other reason for the exact match is that Hungarian entries use two declension tables, one for regular declensions (generated by a module), the other for possessives. The two tables should look the same in collapsed mode. Is there a way to achieve that with NavFrame? Thanks. --Panda10 (talk) 19:22, 14 September 2016 (UTC)[reply]

Did you try mw:Manual:Collapsible_elements? This is a way better alternative, if only because it is in the core of Mediawiki, so it is tested and stable (=works on mobile). — Dakdada 13:28, 15 September 2016 (UTC)[reply]

Interwikis after page moves edit

Do any of the current interwiki bots remove interwiki links to the wrong page name after a page is moved? I have found instances where the interwiki bot just adds the new interwiki links below, leaving the old incorrect interwiki links there. It would be nice if the bots could do this sort of cleanup, since it is very tedious to do by hand when moving multiple pages. --WikiTiki89 19:44, 14 September 2016 (UTC)[reply]

@Ruakh, Thibaut120094, Whym, Octahedron80, Udo T. (pinging people who run interwiki bots). --WikiTiki89 22:40, 14 September 2016 (UTC)[reply]
I lately did that on other projects. When running on English Wiktionary, the result is my OctraBot got blocked few days ago. Because admin said it's okay to keep redirects (even they're moved). So I don't care this issue. I now look forward to new Wikidata approach that is going to collect Wiktionary interwiki links declared yesterday. The problem will begone with this. --Octahedron80 (talk) 00:35, 15 September 2016 (UTC)[reply]
@Octahedron80: I see in your bot's block log that TAKASUGI Shinji said "Wiktionary allows an interwiki link to a redirect". This is true. I am talking about a different issue: When I move a page here from X to Y, the page at Y now contains links to X on other wikis. For example, I moved сєдмь to седмь, but now седмь currently still has links such as [[fr:сєдмь]], which should be removed. As far as I can tell, no bot seems to be removing these, although I may be wrong. --WikiTiki89 01:05, 15 September 2016 (UTC)[reply]
That case when you move a page, you can just delete old iw's all. Some time later a bot will visit the page and re-create clean iw's for it. --Octahedron80 (talk) 01:40, 15 September 2016 (UTC)[reply]
@Octahedron80: I know I can. But like I said in my original post, when I am movig a lot of pages, it becomes very tedious. --WikiTiki89 01:44, 15 September 2016 (UTC)[reply]
Any pywikibot can do this. But it uses the same parameter as my bot got blocked (-force) so nothing we can do better than adding new iw. (-cleanup) --Octahedron80 (talk) 01:49, 15 September 2016 (UTC)[reply]
I guess you're not the type to meddle with the code. Maybe someone else will be up to the task. --WikiTiki89 01:58, 15 September 2016 (UTC)[reply]
I don't want to mess other's codes or I can't update new version. Sorry. ;( --Octahedron80 (talk) 02:08, 15 September 2016 (UTC)[reply]
Is there really no option to treat redirects as normal pages? That would solve the problem you were blocked for. --WikiTiki89 02:10, 15 September 2016 (UTC)[reply]
As I research at this point, still no. phab:T111136 --Octahedron80 (talk) 03:16, 15 September 2016 (UTC)[reply]
Well of course if you use -force and let your bot running without checking its edits, it will get blocked, lol. -force remove everything including mismatches and other things that should be dealt with manually. --Thibaut120094 (talk) 06:57, 15 September 2016 (UTC)[reply]
I've done such cleanup runs before, but it's not part of the usual behavior of Rukhabot's interwiki-updater. I'll look into adding it. (No promises, though; so if someone else wants to do it, they should go right ahead.) —RuakhTALK 04:50, 15 September 2016 (UTC)[reply]
Addendum: I've now added this functionality to Rukhabot's monthly interwiki-updater. [example edit]   Note that, at least for now, it's pretty conservative, only removing ones that seem (on the basis of a few heuristics) like they were really intended to be interwiki-links. (These heuristics should, at least, cover any cases where an interwiki-link was added by a bot but then invalidated by a page-move.) After the first monthly pass, I'll check to see if there are any pages that have bad interwiki-links that Rukhabot ignored, and re-assess the heuristics accordingly. —RuakhTALK 04:11, 18 September 2016 (UTC)[reply]
With pywikibot it is possible to remove links automatically (except "disambiguation mismatch and namespace mismatch") with -cleanup. Haven't tried it yet, I don't know if I'll add it to the normal routine but I'll give it a try. Regards. --Thibaut120094 (talk) 06:57, 15 September 2016 (UTC)[reply]
Welp, -cleanup was working well until it removes redirects, so I can't run my bot unattended to remove the links. :(
Do you guys keep the pywikibot devs updated about our specificities? Maybe I should learn Python and create my own scripts. I raised the priority of phab:T111136, I hope it will get fixed. --Thibaut120094 (talk) 07:31, 15 September 2016 (UTC)[reply]
@Wikitiki89: I think I updated all the pages you moved. Regards. --Thibaut120094 (talk) 08:47, 15 September 2016 (UTC)[reply]
@Thibaut120094: Thank you! Just note that I am not done moving pages, and people will always be moving pages, so I hope you can make that part of your bot's routine to cleanup moved pages. --WikiTiki89 11:46, 15 September 2016 (UTC)[reply]

Alphabetical sorting in categories edit

Category:1000 basic French words isn't sorting properly. Diacritics should be ignored rather than listed under separate headings. Andrew Sheedy (talk) 03:08, 15 September 2016 (UTC)[reply]

The category is outside of automated language structure controlled by modules so it is certainly not sorted. 😅 --Octahedron80 (talk) 03:51, 15 September 2016 (UTC)[reply]
Not quite true: it's sorted by the order of its encoding. The only way to fix this is to add a sort key to the category reference in the entry, as in [[Category:1000 basic French words|etre]] or [[Category:1000 basic French words|e^tre]] (you could also use DEFAULTSORT in the entry, but that affects sorting for everything on the page). Chuck Entz (talk) 04:00, 15 September 2016 (UTC)[reply]
@Chuck Entz. User:Octahedron80 must be referring to Thai (Lao, Khmer, etc.) entries. The default sort is poor or wrong. French diacritics is a small problem in comparison. That's why many Thai entries use {{DEFAULTSORT|CUSTOMSORT}}. Please see more of my ranting in Wiktionary:Votes/2015-03/Templatizing topical categories in the mainspace. --Anatoli T. (обсудить/вклад) 06:05, 15 September 2016 (UTC)[reply]
User:Wyang has created categories with sorting with Module:zh-cat for Chinese. I don't know if {{catlangcode}} does a better job for Japanese. Apparently, you still need to pass a kana reading for kanji terms. --Anatoli T. (обсудить/вклад) 06:16, 15 September 2016 (UTC)[reply]
@Atitarev By the way, I have sort keys for Thai and Lao waiting in Module:languages/data2 talk page --Octahedron80 (talk) 07:04, 15 September 2016 (UTC)[reply]
@Octahedron80 I'll add per your request but I have some doubts it'll fix topical categories. --Anatoli T. (обсудить/вклад) 07:16, 15 September 2016 (UTC)[reply]
It should do too. Leave the system clear their cache for some time. Nope it doesn't work with manual categorizing. It works only POS cats.--Octahedron80 (talk) 07:19, 15 September 2016 (UTC)[reply]
(Before E/C) @Octahedron80 เกรปฟรุต (gréep-frút) is sorted correctly in Thai nouns and lemmas categories but if you open Category:th:Fruits, เกรปฟรุต (gréep-frút) is now sorted under "เ" not the expected "ก". Even [[Category:th:Fruits|กเรปฟรุต]] doesn't seem to help. Do you think I need to give it some time? --Anatoli T. (обсудить/вклад) 07:29, 15 September 2016 (UTC)[reply]
(After E/C) Yes, something like Module:zh-cat is required for a number of languages. --Anatoli T. (обсудить/вклад) 07:31, 15 September 2016 (UTC)[reply]
Having template 'th-cat' can solve this. But it will be unable to use HotCat any more. --Octahedron80 (talk) 07:34, 15 September 2016 (UTC)[reply]
HotCat is not smart enough for this and it doesn't add in the proper language section either. --Anatoli T. (обсудить/вклад) 07:37, 15 September 2016 (UTC)[reply]
Module:th-cat would be a good idea. This and Module:zh-cat need to be invoked by the central sorting functionalities to ensure templates such as {{lb}} used with the language codes 'th' and 'zh' are properly sorted too. Wyang (talk) 07:45, 15 September 2016 (UTC)[reply]
We would not waste so much time with this if we had category-specific sorting. See the open bug: phab:T30397. I wish there was a way to put some weight on this kind a critical request. — Dakdada 13:39, 15 September 2016 (UTC)[reply]
At Thai projects, we already set to sort pages by Unicode collation algorithm (UCA) so we get rid of this problem almost completely. phab:T50097, some charts The pitfall is that CJK characters need another sorting method. [2] But we also solve this with user script. Perhaps you (users) could think about this to apply on English Wiktionary either. --Octahedron80 (talk) 14:08, 15 September 2016 (UTC)[reply]
PS. I forgot which page we discussed about UCA at Thai Wikipedia. Forgive me. --Octahedron80 (talk) 14:19, 15 September 2016 (UTC)[reply]

e-form of Danish adjectives edit

As shown here - hermafroditisk. If this is the standard form now, I'm not impressed. Does anyone understand what it means, apart from me? DonnanZ (talk) 16:30, 15 September 2016 (UTC)[reply]

I wouldn't have a clue. —CodeCat 16:34, 15 September 2016 (UTC)[reply]
I don't like it, but can you think of anything better? I've had to do something similar with Yiddish "dem-forms" (see מיט). --WikiTiki89 16:38, 15 September 2016 (UTC)[reply]
Inflection tables, of course. —CodeCat 16:44, 15 September 2016 (UTC)[reply]
It means the definite singular and plural form, and if I remember correctly the wording originally read "definite and plural", so I think someone has tampered with the template. DonnanZ (talk) 16:51, 15 September 2016 (UTC)[reply]
Yes, it's the definite for all genders/numbers and also the indefinite plural. This is why it's hard to define concisely. --WikiTiki89 17:36, 15 September 2016 (UTC)[reply]
"when definite or plural" perhaps?​—msh210℠ (talk) 17:43, 15 September 2016 (UTC)[reply]
It's really not that hard to make an inflection table to avoid all of this. Compare groot, which has a similar inflection to Danish, and stor, which is also quite close. If it works fine for those languages, it can work fine for Danish too. —CodeCat 18:20, 15 September 2016 (UTC)[reply]
No objection from me. I was merely pointing out a (I think) clearer wording for the headword line than those already mentioned, in case headword-line inflection is desired.​—msh210℠ (talk) 18:30, 15 September 2016 (UTC)[reply]
Note in particular that the Swedish and Danish inflections of stor differ on only one point: where Swedish has -a, this becomes -e in Danish. —CodeCat 18:24, 15 September 2016 (UTC)[reply]
Except that Swedish itself has an -e in the masculine singular. Anyway, there's nothing wrong with an inflection table, but it would be nice to have this in the headword line as well in some concise form. --WikiTiki89 18:31, 15 September 2016 (UTC)[reply]
Personally I'm not in favour of inflection tables. Has anyone checked the template to see if it has been altered lately? DDO doesn't help with its presentation (see reference I attached to the entry); it may be OK for Danes, but not for us. DonnanZ (talk) 18:38, 15 September 2016 (UTC)[reply]
And I'm not in favour of stuffing it all into the headword line. Inflection tables, having two dimensions to work with, can present information a lot clearer, and can also present a lot more information than a headword line. Where did we even get the idea of putting inflections in two different places? —CodeCat 18:42, 15 September 2016 (UTC)[reply]
Maybe you haven't noticed the English presentation of adjectives and verbs. DonnanZ (talk) 18:46, 15 September 2016 (UTC)[reply]
Yeah, whose idea was that? I think it was a bad idea. Anyway, I created a basic inflection table for Danish adjectives: {{da-infl-adj}}. It needs some work, in particular in recognising when to use -est for the superlative and when -st. —CodeCat 19:08, 15 September 2016 (UTC)[reply]
Don't forget some adjectives are indeclinable, others don't have comparatives and superlatives, and that -ere and -est, -st / -este, -ste endings for comparatives and superlatives don't always apply, mere and mest are also used. Maybe the addition of comparatives and superlatives should be optional, otherwise you're getting into a minefield. DonnanZ (talk) 20:35, 15 September 2016 (UTC)[reply]
Generally adjectives of one syllable have -est / -este for the superlative, and those of two syllables use -st / -ste. DonnanZ (talk) 22:02, 15 September 2016 (UTC)[reply]
For now, I'm only doing the uncomparable adjectives, I'll do the comparable ones later. I think I'll just include a parameter to specify whether the superlative has the e or not, it's easier than including a rule that only works half the time. However, I have a question: are there any adjectives that have a superlative but no comparative, or vice versa? If not, then there could just be a parameter to specify the superlative suffix, and that would automatically infer that there is a comparative as well. A word like billig would be specified as just {{da-infl-adj||st}} then. The first parameter indicates a stem change, like in e.g. grøn or forloren. —CodeCat 22:49, 15 September 2016 (UTC)[reply]
To answer your question, I think there are a few without comparatives or vice versa, but I think they are usually shown in DDO. It's always a useful reference. DonnanZ (talk) 23:02, 15 September 2016 (UTC)[reply]
I am the one who "tampered" with the template. My impression was that "definite and plural" caused a lot of confusion, and I felt that "e-form" would be conciser and more recognizable. If someone had asked me for the "plural and definite singular attributive" form of grøn, I do not think I would have known what to say. I do feel that we should have at least the most commonly-used forms on the headword line, for the convenience of users, but six forms may be too much. And yes, sometimes the expected comparative form simply isn't attestable, even when the superlative is.__Gamren (talk) 11:12, 16 September 2016 (UTC)[reply]
Well, I'm afraid you got that wrong, it's not understandable unless you're "in the know". The previous form was better despite its poor wording. DonnanZ (talk) 13:44, 16 September 2016 (UTC)[reply]
I think a concise name with a link to a description of what it means is better than confusing wording. (HINT: We should add a link to a description of what it means.) --WikiTiki89 15:10, 16 September 2016 (UTC)[reply]
I support the new adjective template, but please do not delete Template:e-form of. I personally think it was a really good idea. PseudoSkull (talk) 22:35, 16 September 2016 (UTC)[reply]
It's a terrible idea if passive users can't make head or tail of it. DonnanZ (talk) 22:51, 16 September 2016 (UTC)[reply]
It includes a link to the entry that explains exactly what it is. PseudoSkull (talk) 22:58, 16 September 2016 (UTC)[reply]
What does? The template itself doesn't make any sense. DonnanZ (talk) 23:12, 16 September 2016 (UTC)[reply]
Template:e-form of links to e-form#English, which states in its second definition; "2. (linguistics, of the Danish language) The definite singular and plural form of adjectives, which often end in -e." PseudoSkull (talk) 23:32, 16 September 2016 (UTC)[reply]
Oh my giddy aunt, how is anyone meant to work that out? DonnanZ (talk) 08:50, 17 September 2016 (UTC)[reply]
I really don't see what's so bad about it. It seems pretty simple to me; you click a link and see the definition. @User:Gamren, you might be interested in this discussion, as this is your template that you created. PseudoSkull (talk) 17:39, 17 September 2016 (UTC)[reply]
I created it, but nothing here is "mine". I wouldn't mind if someone found a better wording; just keep in mind that "definite and plural" confused even experienced editors enough to start deleting templates. Maybe the table layout that CodeCat is working on will make this clear without requiring overly-long designations?__Gamren (talk) 17:58, 17 September 2016 (UTC)[reply]
It would be better if we linked to an Appendix page with a more thorough explanation, rather than to the dictionary entry of a term so obscure we thought we made it up. --WikiTiki89 20:10, 17 September 2016 (UTC)[reply]
As much as I like the idea of grammar appendices, WP has a page on w:Danish grammar, so it might be less info-duplicating to just link to that, like we do with e.g. {{IPA}}.__Gamren (talk) 06:33, 18 September 2016 (UTC)[reply]
We don't have enough control over WP's content to force them to keep their section in the same place and specifically mention the obscure term e-form. --WikiTiki89 11:28, 18 September 2016 (UTC)[reply]
"Overly long" designations are sometimes necessary. Consider "third person singular simple present indicative form" of English verbs. That's what I call a long designation. DonnanZ (talk) 11:45, 18 September 2016 (UTC)[reply]
So why don't you change it?__Gamren (talk) 17:10, 19 September 2016 (UTC)[reply]
I'm not sure that I should if it's correct. DonnanZ (talk) 19:05, 19 September 2016 (UTC)[reply]
Well, I've changed the wording now (and updated WT:About Danish accordingly). Feel free to move it, too, but please leave a redirect.__Gamren (talk) 12:05, 21 September 2016 (UTC)[reply]

Creating per-sense links edit

This is a long-standing desire, and is implementable solely within the project via a not-nice-but-functional kluge: create UUIDs for each sense, and use # {{anchor|$UUID}}$term_sense_here. There are a range of possible methods for generating non-rfc-compliant but unique UUIDs, for example using the zero-padded page id as the leading 9+ characters. The point is it can be done, now, and without further dithering. Discussion? - Amgine/ t·e 18:14, 16 September 2016 (UTC)[reply]

What's the advantage of an unreadable computer-generated UUID over a human-generated descriptive UUID? --WikiTiki89 18:35, 16 September 2016 (UTC)[reply]
  • Uniqueness
  • Translingual
  • Machine-readable
  • Existing tools/transportability/reusability
  • Predictability
  • Automatable (although this may also be considered a drawback)
But a human-generated descriptive UUID which is actually unique without excess processing (e.g. having to parse the page to discern Language/Etym/POS/UUID structure) would work as well. - Amgine/ t·e 19:30, 16 September 2016 (UTC)[reply]
Uniqueness and machine-readable also apply to human-generated IDs. I'm not sure what you mean by existing tools/transportability/reusability. But you have me at translingual if that means we'd be able to have the same ID used on all languages' Wiktionaries for the same sense. --WikiTiki89 19:34, 16 September 2016 (UTC)[reply]
Maybe we can start with cross-language suffixes and prefixes. English -cide, Portuguese -cídio, Spanish -cidio, etc. could all use the same ID meaning "act of killing", and a separate ID for "killer". --Daniel Carrero (talk) 19:41, 16 September 2016 (UTC)[reply]
I 100% oppose using these IDs for senses of different languages. The only translingual aspect can be definitions in different languages of the same sense in the same language. --WikiTiki89 19:46, 16 September 2016 (UTC)[reply]
I agree: this issue came up in much more detail in another discussion (on Meta?), didn't it? Equinox ◑ 10:34, 17 September 2016 (UTC)[reply]
Even if the two senses are identical? For instance, an easy example, the element helium. The first sense "a colorless, inert gas..." could be used in scores of other language entries, preventing the need for a gloss/click-through/discernment process by the reader. - TheDaveRoss 11:44, 17 September 2016 (UTC)[reply]
I like this idea. Editing the single sense would change "Helium" in all languages. --Daniel Carrero (talk) 14:56, 17 September 2016 (UTC)[reply]
Human-generated descriptive IDs sound better. The only advantage of unreadable computer-generated IDs I am thinking is that they can probably be filled quickly for all entries. But they would probably be a pain to copy elsewhere and use. --Daniel Carrero (talk) 18:40, 16 September 2016 (UTC)[reply]
Where is the documentation about how this could be used? What is the relationship to {{senseid}}? Oh, I'm sorry. I'm dithering. DCDuring TALK 18:42, 16 September 2016 (UTC)[reply]
One way would be to use {{#invoke:UUID|full}} (which generates "383f6946-86ec-433a-977e-41ee7b98ec9d31") and I think there is a version making its way into core MediaWiki. If it were up to me I would build a template around each sense which creates a transcludable section that can be referenced by the UUID. Even better would be if each of those senses lived on its own entry in a sense namespace so that it makes the machine-readability much higher, and creates a real opportunity to shift senses to a relational database at some point. We can do the same thing with any other piece of data, sense is just an obvious choice since it is central to everything we do here. - TheDaveRoss 19:44, 16 September 2016 (UTC)[reply]
But we would have to have that ugliness in the wikitext... --WikiTiki89 19:46, 16 September 2016 (UTC)[reply]
Sure, but we could also leverage it to reduce the necessity of actually editing the wikitext. - TheDaveRoss 19:48, 16 September 2016 (UTC)[reply]
Anyway, regardless of how you generate the UUIDs, the biggest problem is that every time you merge or delete senses, you have to go and update all the links. Will there be an easy way to solve that problem? --WikiTiki89 18:43, 16 September 2016 (UTC)[reply]
merge senses -> allow a single sense use multiple old IDs?
delete senses -> ignore the ID forever or generate a category for entries linking to bad IDs?
--Daniel Carrero (talk) 18:47, 16 September 2016 (UTC)[reply]
And I forgot splitting senses. --WikiTiki89 18:49, 16 September 2016 (UTC)[reply]
split senses -> keep the old ID as a group ID whose children are the multiple separate IDs; if a link points to the group ID, it highlights all the multiple applicable senses... ? --Daniel Carrero (talk) 18:53, 16 September 2016 (UTC)[reply]
And how are we supposed to enforce any of that? DTLHS (talk) 19:48, 17 September 2016 (UTC)[reply]
The problem with sense IDs has never been technical. The problem is we have no way to track these kinds of dependencies. If we start giving English entries sense IDs we make them dependent on all the other languages that want to link to them. Now if I want to change an English sense do I have to know all of those languages and possibly change their links if the new sense no longer applies? Glosses don't have this problem. DTLHS (talk) 20:05, 17 September 2016 (UTC)[reply]
The sense ID has uses beyond links - that is simply the most obvious use. However, from the point of view of its use as a link, if you alter a sense, the ID should not necessarily change (I would expect it should not change, actually.) The real issue is when a sense is deleted since the the ID should be eliminated from possible recreation. (And an OCD person might figure out how to generate a 410 status code for links to deleted sense IDs at some point.) That is, the issue you raised is not actually an issue. Editing the sense ID itself, however, would be a problem and is why a contextual UUID is probably better than a human-generated UUID. - Amgine/ t·e 05:43, 18 September 2016 (UTC)[reply]
The solution to the possible problem of editing a human-generated sense ID is to retain both the old and the new IDs as anchors, as Daniel Carrero suggested above. But I can see where unusual cases might result in very large blocks of anchors in the wikitext. - Amgine/ t·e 05:50, 18 September 2016 (UTC)[reply]
We could also insist on having exactly one ID per sense, with no old IDs and no IDs standing for multiple senses, but we would have some way to mark bad IDs, (either having an actual list of bad IDs; or a huge list of good IDs, where absence on the list means an ID is bad) and the link would not go anywhere. If we have a list of "bad ID -> good ID", we could have a bot replace all links that point to bad IDs. --Daniel Carrero (talk) 05:54, 18 September 2016 (UTC)[reply]

User:Hippietrail/nearbypages.js edit

Would anyone be able to fix User:Hippietrail/nearbypages.js? I really liked it, but it hasn't worked for a long time. It's supposed to add a little horizontal bar of previous and next entries, so you can see where you are in the current language. For example, at the entry for equinox, I would see something like equinity - equinoctial - equinox - equip - equipage. Equinox ◑ 16:56, 17 September 2016 (UTC)[reply]

Looks useful! The backend url in the js is no longer valid, and I can't find it on the new tool server. – Jberkel (talk) 19:46, 17 September 2016 (UTC)[reply]
Like so many toolserver addresses, this one has been mothballed. The code is apparently still available via special request, and can be set up to run via labs, but someone will have to do the legwork to get it running again, and update the script as necessary. - Amgine/ t·e 05:55, 18 September 2016 (UTC)[reply]
Where is the code? Jberkel (talk) 12:28, 18 September 2016 (UTC)[reply]
Apparently I was wrong; the toolserver archives were only kept until 2014. So I am asking Hippietrail about xyr source. - Amgine/ t·e 16:55, 18 September 2016 (UTC)[reply]
I'm curious how this was implemented. Given that we now have categories for lemmas, that category can be used for such a list where it was not possible before. —CodeCat 17:06, 18 September 2016 (UTC)[reply]
You may recall that Hippietrail implemented many tools based on dump parsing. This was one of them, apparently. The benefit of dump parsing is the complete population - poorly structured and all. The drawback is its brittleness/high maintenance cost. - Amgine/ t·e 19:38, 18 September 2016 (UTC)[reply]
  • I've changed it a little bit to use MW API. Unfortunately MW API does not have option for reverse ordering in the API query. So it only displays the next 5 lemmas under the language header. scri. --Dixtosa (talk) 19:00, 18 September 2016 (UTC)[reply]
  Done Dixtosa's script is as good as the old one. Yeah!! Equinox ◑ 21:02, 5 October 2016 (UTC)[reply]

UlaanBaatar -> Ulaanbaatar edit

Hey everyone,
I made a spelling mistake and foolishly repeated it a hundred times by copying. I wrote "UlaanBaatar" instead of "Ulaanbaatar" in a lot of Mongolian accent templates, could someone with a bot change it to proper capitalization if it's not too much of a hassle? — This unsigned comment was added by Crom daba (talk • contribs) at 14:14, 18 September 2016.

This search should find all uses (there are supposedly 112 of them). If no one does this by bot, it shouldn't be too hard to do by hand. --WikiTiki89 13:11, 19 September 2016 (UTC)[reply]

Gadgets and page loading time edit

Originally I thought my main problem was that the HotCat gadget seemed to be load very slowly. I disabled it and that didn't help much. I disabled a number of other gadgets that I use rarely, but still note that the tab in Firefox shows that something is still loading. At the end of the loading the page seems to jump a bit. Why is this? Are we overloading our pages with scripts? Can the scripts be emended to reduce (eliminate?) this effect? DCDuring TALK 17:09, 18 September 2016 (UTC)[reply]

Is the "jump" the annoying delayed insertion of the citations tab (causing the other tabs to change places, so that my mouse clicks always miss)? Yes, we must fix that monstrosity. Equinox ◑ 18:28, 19 September 2016 (UTC)[reply]
A few things jump. Now that I think of it, the visual editor would do the same thing, until I disabled that, too. It was particularly annoying as the inserton-jump happened just as I was starting to edit. I've read that visual editor is considered a great success. I hope I can always opt out of such successes, at least so long as the implementation is in a slow-to-load-and-execute script. DCDuring TALK 18:51, 19 September 2016 (UTC)[reply]
Unfortunately, you still get that junk when editing as an IP. If that had been the case when I first found Wiktionary (which I edited anonymously for months before making a user name) I just wouldn't have come back. The horrid "Media Viewer" on Wikipedia is another case of horrific usability failure: indeed, if I type "media viewer wikipedia" into Google, the predictive search suggests "terrible". Equinox ◑ 18:56, 19 September 2016 (UTC)[reply]
For me, the QQ tab pushes the History and Edit tabs leftwards as it loads. Also, the toolbar above the editing frame (can that be removed?).__Gamren (talk) 10:41, 20 September 2016 (UTC)[reply]
Sheesh, sorry, I found it.__Gamren (talk) 10:56, 20 September 2016 (UTC)[reply]
For me the most annoying thing is when the clock gadget loads at the top right (if you have it enabled, it's pretty useful), it pushes everything to the left, putting "Log out" in the place of "Contributions", so frequently I try to go to my contributions and end up logging out (which then logs me out on all my devices). --WikiTiki89 14:40, 20 September 2016 (UTC)[reply]
add UTCLiveClockConfig = {};UTCLiveClockConfig.nextNodeId = "pt-userpage"; to you common.js if you want it to appear before your username... --Giorgi Eufshi (talk) 08:26, 21 September 2016 (UTC)[reply]
Learning the keyboard shortcuts is probably a good idea if nobody is going to fix this. Equinox ◑ 15:41, 21 September 2016 (UTC)[reply]
For the unenlightened: w:WP:Keyboard shortcuts (Thank you for giving me cause to seek this, Equinox).__Gamren (talk) 10:34, 22 September 2016 (UTC)[reply]
Thanks from one of the unenlightened. DCDuring TALK 11:06, 22 September 2016 (UTC)[reply]
On the watch list, I noticed that the main culprit for post-load shifting of page contents is the "News for editors" link. Why is that even implemented with JavaScript? Can it please be removed and placed somewhere more sensible? The links on the left seem like a much better place. —CodeCat 00:30, 24 September 2016 (UTC)[reply]
The link above the entry? You can remove that with the [dismiss] button.__Gamren (talk) 07:21, 24 September 2016 (UTC)[reply]
That's only temporary, and it doesn't stop the JS itself from loading. —CodeCat 12:18, 24 September 2016 (UTC)[reply]
There has to be some JS in order to work with cookies. BTW, how do you measure what's taking what time? --Dixtosa (talk) 16:40, 24 September 2016 (UTC)[reply]
  • How/who do we ask for help in diagnosis and cure of this problem? We apparently don't have contributors willing and able to deal with this. In the short run, we need a diagnosis of the current sluggish loading or execution of the JS. In the longer run we could use some kind of performance diagnostic tool to assess the performance-impairing portions of the JS. DCDuring TALK 13:51, 6 November 2016 (UTC)[reply]

Lua performance question edit

Since strings are not mutable in Lua, there can be all kinds of optimisations done on them. One thing I wonder in particular is whether taking a substring of an existing string causes any copying in memory, or if the same data is used with just different pointers to start and end. This is significant when the strings are large, both for performance and for memory usage, which is why I ask. —CodeCat 23:05, 22 September 2016 (UTC)[reply]

Making new string always uses more memory. When you make substring and modify it, it will not modify its original string. However, any unused or no-longer used variables will be revoked at the end of their scopes. --Octahedron80 (talk) 00:55, 23 September 2016 (UTC)[reply]
I think this file should be helpful: https://www.lua.org/gems/sample.pdf
Look for the section "About strings" in the page 8. --Daniel Carrero (talk) 01:03, 23 September 2016 (UTC)[reply]
I found that, but it didn't really answer my question. My question is this: let's say a string variable is created with the contents "abcdefgh", and I then take a substring of that, "cdef". Does this actually create a new memory area where the second string's data is stored, or is it reused from the original one? This is a trivial example of course, but it matters more when the original string and the substring are both rather large, many kilobytes in size. If the data is not copied but merely has a new reference created for the substring, then it's more efficient in both memory and in speed. What I wondered is whether Lua actually does this, or whether it takes the slow approach by copying the substring over to a new data buffer. —CodeCat 01:13, 23 September 2016 (UTC)[reply]
My guess is that the substring function doesn't copy anything. They'd be crazy not to have implemented it that way. Of course, when you concatenate, it must copy everything. I wonder if a chain of .. operators is reduced to a single operation. --WikiTiki89 01:29, 23 September 2016 (UTC)[reply]
Yes, see [3]. Benwing2 (talk) 05:03, 23 September 2016 (UTC)[reply]
BTW you are probably right that substring doesn't copy but it's not completely crazy to do so. Lua uses garbage collection, and allowing a string to point to the middle of another string makes garbage collecting strings more complicated. For example, it might require that string metadata objects contain an extra slot to point to the beginning of the string that is subsetted, so that if the main string gets garbage-collected but the substring still remains, its contents don't get garbage-collected out from under it. This would also imply that if you take a small substring of a very large string, the very large string has to sit in memory as long as the substring remains, even if it otherwise could be garbage-collected ... so taking a relatively small substring might well be implemented with a copy. Benwing2 (talk) 05:11, 23 September 2016 (UTC)[reply]
In garbage collected environments, you never keep a real pointer to anywhere other than the beginning of an array. Instead, you keep a pointer (to the beginning) and an offset (and in this case also a length). Garbage collection does pose a separate problem, that if you keep a short substring of a large string, the entire large string must remain in memory. Interning small strings (which CPython does, for example) has a side effect of alleviating this problem (because the short substring will point to an interned copy, rather than the string you took it from). I have no idea whether Lua interns small strings or does anything else to alleviate this problem. --WikiTiki89 13:26, 23 September 2016 (UTC)[reply]
But note that if you use mw.ustring.sub, it will still take linear time, so it really doesn't matter if it copies it, except for memory efficiency. --WikiTiki89 01:37, 23 September 2016 (UTC)[reply]
Create a single-purpose module or two with two functions that would act the same if the system works one way, but would act differently if it works the other, then create a template for each function and transclude them both precisely a gazillion times on one page, then "view source" to compare the stats for memory and time usage. Chuck Entz (talk) 04:02, 23 September 2016 (UTC)[reply]

Coloured emoji obscure red/blue link colour edit

A recent update to Chrome (or to Windows?) means that emoji now render in full colour, e.g. the smiley faces are yellow. This means that, viewing a page like Appendix:Unicode/Emoticons, it is impossible to see which are "red" links and which are "blue" links. Any suggestions? Equinox ◑ 12:34, 25 September 2016 (UTC)[reply]

My Google Chrome is "Version 53.0.2785.116 m", on Windows 7. The browser is up to date, according to the "About" screen. The emoticons listed at Appendix:Unicode/Emoticons are being displayed as normal blue/red linked text to me. There should be a checkbox or something to allow/disallow full-colored emoticons. --Daniel Carrero (talk) 14:27, 25 September 2016 (UTC)[reply]
Daniel: thanks, but ideally I'd like to keep the coloured emoji (they look okay!) but still see the red/blue status. I might be asking too much. Equinox ◑ 05:28, 27 September 2016 (UTC)[reply]
I have Firefox on a Mac,and I see emoji colors (why do I hear Haley Joel Osment saying that?). If the Javascript can easily detect emoji characters, I believe Common.js could be changed to put a red border around them when they're redlinked (it might require giving them a separate redlinked-emoji css class). Chuck Entz (talk) 15:29, 25 September 2016 (UTC)[reply]
From an accessibility point of view we should definitely not have to treat these characters differently, and it's pissing me off. This is a much wider issue than just Wiktionary. Did nobody realise that adding coloured characters to displayed fonts, when displayed fonts already have colour as a property, might be an issue? I am going to stab them in the knee. Equinox ◑ 05:38, 27 September 2016 (UTC)[reply]

Request for minor Hangul syllable cleanup edit

Template:ko-symbol-nav edit

{{ko-symbol-nav}} runs solely on the magic of Lua now, so I would like to request the removal of parameters from wikitext. —suzukaze (t・c) 04:47, 27 September 2016 (UTC)[reply]

Excellent job! Wyang (talk) 22:55, 27 September 2016 (UTC)[reply]

Template:ko-syllable-hangul edit

{{ko-syllable-hangul}} now automatically displays Revised Romanization only, so I would like to request the removal of numbered parameters from wikitext. —suzukaze (t・c) 05:02, 27 September 2016 (UTC)[reply]

Template:Hangul Syllables character info edit

At some point this was redirected to {{character info/new}}. Which is bad, because {{character info/new}}'s |1= overrides the codepoint to display, and {{Hangul Syllables character info}} used to use |1= for other things. It looks like it is safe to replace {{Hangul Syllables character info}} with {{character info/new}} per User:Kephir's tinkering here. —suzukaze (t・c) 05:02, 27 September 2016 (UTC)[reply]

  Done. All existing "Hangul Syllables" entries use {{character info/new}} now. --Daniel Carrero (talk) 21:30, 20 November 2016 (UTC)[reply]

Other minor question edit

{{character info/new}} seems to be able to do what {{ko-defn-hangul}} does manually (display the composition of a syllable). Could someone automate {{ko-defn-hangul}}? —suzukaze (t・c) 05:39, 27 September 2016 (UTC)[reply]

Underscore in unsupported titles? edit

Is there a way to include an underscore in an unsupported page title? I've created Unsupported titles/-_-, but I can't get the underscore to appear, even with the magic word. Smurrayinchester (talk) 08:05, 27 September 2016 (UTC)[reply]

Underscores always convert to spaces. This is the limitation of MediaWiki. You must rename to words instead. See also Unsupported_titles/Low_line --Octahedron80 (talk) 08:29, 27 September 2016 (UTC)[reply]
Naah, he only needs to get MediaWiki:Common.js updated accordingly. --Giorgi Eufshi (talk) 08:53, 27 September 2016 (UTC)[reply]
The link title is double dashes that does not make sense. Should be renamed like Unsupported titles/low line interfix. The script surely fixes display. --Octahedron80 (talk) 09:01, 27 September 2016 (UTC)[reply]
Thanks. Could someone make the change to MediaWiki:Common.js? Just need to add 'Low_line_interfix'  : '-_-', Smurrayinchester (talk) 08:34, 28 September 2016 (UTC)[reply]
Done. Benwing2 (talk) 14:34, 30 September 2016 (UTC)[reply]

Editing tools at the top of the page edit

As in when editing above the editing box, starting with B I (etc.). Is there anyway to avoid loading these? They're taking ages at the moment, like over a second. Renard Migrant (talk) 11:25, 27 September 2016 (UTC)[reply]

I wouldn't miss them either, but I can imagine they're useful for new people. —CodeCat 14:00, 27 September 2016 (UTC)[reply]
Try unchecking Preferences:Editing:"Show the edit toolbar (requires JavaScript)". DCDuring TALK 16:56, 27 September 2016 (UTC)[reply]

Who broke the transliteration on term, m, etc? edit

Right now the transliteration of Ancient Greek ἀποϕυγή is showing up as apoϕugḗ instead of apophygḗ. Adding at |tr= doesn't help, since someone decided to override manual corrections. Needs fixing, wherever the transliteration code is hidden. — LlywelynII 02:28, 29 September 2016 (UTC)[reply]

The person who used the wrong phi broke it. It should be ἀποφυγή (apophugḗ), which transliterates correctly. —Μετάknowledgediscuss/deeds 02:32, 29 September 2016 (UTC)[reply]
The wrong phi (it was the mathematical phi symbol U+03D5 instead of the Greek small letter phi U+03C6) was being used at congé. I've fixed it now. —Aɴɢʀ (talk) 12:36, 30 September 2016 (UTC)[reply]

Strange description at Category:Old Irish verbs by inflection type edit

There's a strange description with Arabic characters showing up at this category. Can this be fixed/removed? —CodeCat 15:16, 29 September 2016 (UTC)[reply]

@CodeCat: Someone added Pashto-specific descriptions to "simple verbs" and "simple intransitive verbs" in Module:category tree/poscatboiler/data/lemmas. Maybe you can figure out better than me the best way to fix this, while having this information still show up in the Pashto categories (Category:Pashto simple verbs and Category:Pashto simple intransitive verbs). --WikiTiki89 15:38, 29 September 2016 (UTC)[reply]
I think that having this category in poscatboiler isn't really appropriate. The principle of poscatboiler is that it contains categories applicable equally across all languages. Creating a category for just one language goes against that. —CodeCat 15:42, 29 September 2016 (UTC)[reply]
Ok, then we should remove it from there. We should probably have a template that can be used in categories for language-specific parts of speech that will still add in all the usual boilerplate such as the default parent categories, TOC, descriptions, oldest/newest entries, and all the rest of the stuff. --WikiTiki89 15:55, 29 September 2016 (UTC)[reply]
I have considered something like that. It would basically be an ad-hoc category that has all the data provided manually instead of being taken from the modules. But we have to account for the possibility that an ad-hoc category may one day be turned into a global one. —CodeCat 16:10, 29 September 2016 (UTC)[reply]

Lag when focusing edit window on large page edit

This has been happening for a while now and it's really annoying. Basically, if I open the edit page and there is a lot of text in the edit window (a lot being an entire monthly BP page or something like that, but not just a section), when I focus the edit window for the first time, there is a 10-second-or-so-lag during which I believe a ton of unnecessary javascript is being run, does anyone know what the culprit could be? --WikiTiki89 21:45, 29 September 2016 (UTC)[reply]

I've never had anything like 10 seconds. What are your OS, CPU speed, and browser? Equinox ◑ 22:27, 29 September 2016 (UTC)[reply]
So the lag doesn't occur when you have javascript disabled? - TheDaveRoss 22:45, 29 September 2016 (UTC)[reply]
I Windows 7 with a crazy good CPU and Windows 10 with an i7. Both with Chrome. I haven't tried disabling JS, but will do as soon as I get back to a computer. --WikiTiki89 23:01, 29 September 2016 (UTC)[reply]
Actually, just tried on my Windows 10 and there seems to be no issue. It could be a Chrome bug that got fixed and my Windows 7 hasn't been updated. I'll have to wait till tomorrow to find out. --WikiTiki89 23:14, 29 September 2016 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2016/September&oldid=71464119"