Wiktionary:Grease pit/2018/September

I don't know if this is a correct place to report a bug, but I'd like to ask of it.--Yoshiciv (talk) 05:26, 3 September 2018 (UTC)[reply]

• Sounds like a hardware problem to me. SemperBlotto (talk) 05:29, 3 September 2018 (UTC)[reply]
  • It could also be a difference between the regular and mobile css, or even the color scheme a particular language uses. As an example, at https://en.wiktionary.org/wiki/βάθος, the Ancient Greek declension table has darker lines than the background, but the Greek one has white on white. Going to https://en.m.wiktionary.org/wiki/βάθος will show the same declension tables using the mobile version. I don't see any difference between them on my laptop, but I don't have a smartphone to test it with Chuck Entz (talk) 06:07, 3 September 2018 (UTC)[reply]
    • I'm not seeing the difference either. Could @Yoshiciv say which tables have the problem? Since there's only a little bit of mobile CSS and none that applies to inflection tables, maybe there's some default CSS for tables in Safari on the iPod Touch that is causing this. I've added a style rule to fix this in the declension tables generated by Module:grc-decl (if they are among the ones with the problem), which are transcluding a CSS stylesheet using TemplateStyles. — Eru·tuon 07:05, 3 September 2018 (UTC)[reply]
      • It seems that Modern Greek table and Lithuanian table don't have this problem. And Latin, Classical Greek, Russian, and Spanish have.--Yoshiciv (talk) 04:09, 6 September 2018 (UTC)[reply]

Perhaps related is the fact that the {{audio}} template does not display properly on my iPhone 8, which means that audio files cannot be played. However, it works fine on an iPad. — SGconlaw (talk) 07:18, 3 September 2018 (UTC)[reply]

I still can't get the "Add audio pronunciation" tool to work properly. After plugging in a microphone and doing a recording, everything seems to work. However, it then turns out that no sound file is created, despite the tool indicating that it has been saved. Any idea how to fix this? — SGconlaw (talk) 12:20, 3 September 2018 (UTC)[reply]

Please replace it with User:Rua/creationrules.js. —Rua (mew) 15:24, 3 September 2018 (UTC)[reply]

Done Dixtosa (talk) 16:21, 3 September 2018 (UTC)[reply]

Along with the flag was the note... "A brief description of the abuse rule which your action matched is: probably vandalism. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit.", so here I am, but I'm not sure how to proceed.

It was titled "Spanish, not English as the global language!" and I discussed the seeming illogicality of my native language being the global language, with no words of a "vandalistic" nature included.

So, what to do? If my piece is to be judged for "vandalism" (never thought I'd string those words together), then surely it needs to be seen before banned. But if I place the whole piece here now, will it too be flagged as "probably vandalism" and so never get a hearing/viewing?

Please let me know.

sigh — This unsigned comment was added by TheGarpster (talk • contribs) at 23:19, 3 September 2018 (UTC).[reply]

You can go ahead and post, as long as it wasn't actually blocked. We just have some "abuse filters" that 99% of the time filter out spam or vandalism and 1% of the time catch something incorrectly, like yours. Please try proceeding through the warning screen. Equinox ◑ 23:22, 3 September 2018 (UTC)[reply]

Looking at the edit in the "abuse filter" log, I think I know what triggered the warning, but I suppose I shouldn't say lest it tip vandals off. The edit in question wasn't malicious, but wasn't something Wiktionary can do anything about, either (as the user says above, it was just a long post about how English and also French are illogical). - -sche (discuss) 23:32, 3 September 2018 (UTC)[reply]

I'm not sure I can spot what you spotted, but putting English and Spanish in the same header might be an issue, because we have a lot of hilarious jokers who turn up and change ==English== to ==Spanish==. OP, if you are actually blocked from posting, use the Wiktionary e-mail feature to send me your screed, and I will put it up, eventually. Equinox ◑ 00:56, 4 September 2018 (UTC)[reply]

1. When working with alternative forms (common in Old and Middle English/French/etc), the alt forms are pushed to the end of the tree, and there is a Lua error when I try to do |[[x]], [[y]], [[z]]| in the second parameter.
2. Interference from {{desc-top}}? wyn#Middle English isn't showing the descendants at wine#English. Ultimateria (talk) 23:56, 4 September 2018 (UTC)[reply]

@Ultimateria, you shouldn't ever be doing {{desctree|en}} as no languages descend from English. For alternative forms, you need to use {{alter}} on the page your linking to. --Victar (talk) 01:02, 5 September 2018 (UTC)[reply]

The template is commonly used for borrowings as well; they're still descendants (not to mention English-based creoles). naranja#Spanish is a good example. As for the alternative forms, I'm referring to links under the Descendants header. I know it's not exactly important to link to any form besides the lemma, but I'd still like to link to all the forms that descended from a word. Ultimateria (talk) 03:04, 5 September 2018 (UTC)[reply]

I understand that there are borrowing, but all the same, no one should be doing {{desctree|en}}. We don't want all the English borrowing in Germanic descendants lists. If you really want to show that there are borrowing, you could use {{see desc}}, which is generally what we do when the borrowing jumps language family, ex. Frankish *hnapp.

You need to give an example than of your alternatives problem. --Victar (talk) 03:26, 5 September 2018 (UTC)[reply]

@Victar See win#Old English. Also, I can't find an example, but languages like Occitan with several non-centralized spellings based on region. Ultimateria (talk) 19:12, 6 September 2018 (UTC)[reply]

@Ultimateria, if you have a look at {{desctree|ang|wīn}}, you can see it's calling up the alternative form from {{alter|ang|ƿin}}. You can do the same using {{desc|alts=1}}. --Victar (talk) 20:21, 6 September 2018 (UTC)[reply]

It's strange that the descendants tree for Middle English wyn isn't showing the descendants from Modern English wine. I'll look into that. [Edit: Fixed. And yes, it was due to {{desc-top}}.] — Eru·tuon 04:04, 5 September 2018 (UTC)[reply]

That's because I replaced it with {{see desc}}. {{desctree|en}} shouldn't have been used in the first place in this case. --Victar (talk) 04:53, 5 September 2018 (UTC)[reply]

No, I noticed that, and tested {{desctree|en|wine}} on a sandbox page. — Eru·tuon 05:01, 5 September 2018 (UTC)[reply]

Thank you, Erutuon. Ultimateria (talk) 19:12, 6 September 2018 (UTC)[reply]

The insertion of Arabic diacritics in MediaWiki:Edittools doesn't work for me, unlike various other diacritics and symbols. Can someone please look into it? The sections are called "Vowels" and "Other".--Anatoli T. ^{(обсудить}/^вклад) 00:15, 5 September 2018 (UTC)[reply]

Bump. Any takers at all? --Anatoli T. ^{(обсудить}/^вклад) 06:52, 20 September 2018 (UTC)[reply]

@Atitarev: Works fine for me. Chrome v70.0.3538.110 (Official Build) (64-bit) on Windows 10. --{{victar|talk}} 20:33, 3 December 2018 (UTC)[reply]

Insertion of Arabic diacritics works for me, but the place to click is to the left of the diacritic because they are after a space character. It would be better to seat the diacritics on ـ (U+0640, ARABIC TATWEEL) so that we can click directly on them. — Eru·tuon 21:45, 3 December 2018 (UTC)[reply]

Okay, done, but the diacritics are still hard to click in the the font my browser is using for the Arab class. The font has a very narrow glyph for the tatweel. Example: ـَ. Other possibilities: two tatweels: ــَ; three: ـــَ; dotted circle: ◌َ (in my font the diacritic is not actually above the dotted circle). — Eru·tuon 22:13, 3 December 2018 (UTC)[reply]

@Erutuon, Victar: Thank you both. I did test it now and I can insert Arabic diacritics using Edit tools. Using تَطْوِيل (taṭwīl) was a great idea. Some other scripts may need a similar improvement. I have been using SC Unipad for adding/extracting diacritics. --Anatoli T. ^{(обсудить}/^вклад) 00:53, 4 December 2018 (UTC)[reply]

I've converted a few inflection templates ({{grc-decl}}, {{grc-adecl}}, {{ar-conj}}) to use a stylesheet transcluded by mw:TemplateStyles. In some cases it makes sense to put the stylesheet in the Module namespace, because the same module serves as the backend for more than one template. For instance, Module:grc-decl is invoked by {{grc-decl}} and {{grc-adecl}}.

TemplateStyles requires the Sanitized CSS content model, and at the moment that's the default content model for Template pages with titles ending in .css. I can move a CSS page from the Template namespace to the Module namespace to get the Sanitized CSS model (as I did with Module:ckb-conj/style.css), but it would be nice to be able to create it there directly. (At the moment that seems to be impossible because the server will not save CSS in a page that has Scribunto as the content model.)

Could an admin make Sanitized CSS the default for CSS pages in the Module namespace as well? I think that wouldn't cause problems; I can't recall encountering any module titles ending in .css before the one I just created. According to mw:Extension:TemplateStyles § Configuration, it can be done by modifying the $wgTemplateStylesNamespaces variable in PHP. — Eru·tuon 03:03, 6 September 2018 (UTC)[reply]

Admins are not able to change PHP variables. DTLHS (talk) 04:16, 6 September 2018 (UTC)[reply]

Oh well. I notice there is a Phabricator task about making this change on Wikipedia, so apparently someone higher-up has to make it happen. — Eru·tuon 04:31, 6 September 2018 (UTC)[reply]

Languages like Classical and Modern Greek, Lithuanian, and Japanese. That would be greatly appreciated. I'm sorry that I can't make them on my own.--Yoshiciv (talk) 09:10, 6 September 2018 (UTC)[reply]

• Do you mean that the inflected forms should be displayed in a table (relatively easy to do), or that the inflected forms should actually be created by a bot (more work involved)? SemperBlotto (talk) 09:14, 6 September 2018 (UTC)[reply]

It should be "automotive" (adjective), not "automotives" (multiple car stores). Seen at e.g. transmissioned. Sorry, forgotten how to get to the template list. Equinox ◑ 14:19, 6 September 2018 (UTC)[reply]

It's a label anyway. Yes, someone changed it to that, it's annoying me too (please revert). DonnanZ (talk) 10:37, 8 September 2018 (UTC)[reply]

I tried to fix it at Module:labels/data/topical, but it hasn't filtered through yet. DonnanZ (talk) 11:17, 8 September 2018 (UTC)[reply]

It's reading "automotive" now. DonnanZ (talk) 19:42, 8 September 2018 (UTC)[reply]

I created this to replace the JavaScript-based creation rules in User:Conrad.Irwin/creationrules.js. Because it's a module, anyone is able to edit it, rather than only interface admins. Moreover, because bots can call modules, they can use the output of this module to generate new entries. The corresponding JavaScript code is at User:Rua/Gadget-AcceleratedFormCreation.js. However, before the new script can be put in, I need some help with translating the existing rules from JavaScript to Lua modules. I already did one, Module:accel/se. If anyone with the necessary coding skills can help with the rest of the language-specific rules in User:Conrad.Irwin/creationrules.js, that would be great. —Rua (mew) 20:07, 6 September 2018 (UTC)[reply]

I think that's a great idea. I will help. — Eru·tuon 22:22, 6 September 2018 (UTC)[reply]

My first thought was "why are you circumventing the new permissions" but then I realised that these rules have got nothing to do with the interface, which is what they are trying to protect. Are there other such scripts we should... emancipate? Equinox ◑ 23:18, 6 September 2018 (UTC)[reply]

I've thought about the way that the module returns data to the script. Right now it returns the entries table directly, in JSON form, and leaves actually putting it together to the JS side. But there's no particular reason why this couldn't be done within Module:accel as well. The problem I have is how to get the JS to recognise error conditions. Right now it has to parse JSON, so anything that isn't valid JSON, like a module error, gets caught automatically. But if the module is going to return wikitext, that method no longer works. Any ideas? —Rua (mew) 23:35, 6 September 2018 (UTC)[reply]

Maybe the module could return an object with a field for entry text and fields for error information. — Eru·tuon 00:00, 7 September 2018 (UTC)[reply]

I have now done that. There can't be fields for errors, because errors break the regular return path of the module so that they can't be formatted as JSON. So instead, the entire entries string is just JSONified (wrapped in quotes and escaped, basically), and an error is unlikely to fit this format. —Rua (mew) 10:52, 7 September 2018 (UTC)[reply]

That should work. I think errors aren't ever valid JSON. I think my idea would work too if we had another function pcall generate in Module:accel and then encode a JSON object containing either the entry text or the error message. It would at least be more elegant to clearly tell JavaScript that there's an error. — Eru·tuon 05:54, 8 September 2018 (UTC)[reply]

@Erutuon I think that's all of them now? —Rua (mew) 11:02, 7 September 2018 (UTC)[reply]

@Dixtosa, Yair rand, could you replace MediaWiki:Gadget-AcceleratedFormCreation.js with User:Rua/Gadget-AcceleratedFormCreation.js and then delete User:Conrad.Irwin/creationrules.js (it's now in Module:accel)? —Rua (mew) 12:35, 7 September 2018 (UTC)[reply]

I'd prefer that User:Conrad.Irwin/creationrules.js be kept for historical purposes, but it should have a notice saying that it's no longer actually used. — Eru·tuon 21:42, 7 September 2018 (UTC)[reply]

@Chuck Entz, because they're active right now. —Rua (mew) 20:38, 7 September 2018 (UTC)[reply]

Anyone who can do this? —Rua (mew) 17:27, 8 September 2018 (UTC)[reply]

done DTLHS (talk) 17:49, 8 September 2018 (UTC)[reply]

I am going through the process of creating entries for ancient greek conjugated verb forms. This is a difficult process, so I am wondering if anyone knows how a language is added to WT:ACCEL. I would be happy to help in any way that I can. Thanks — This unsigned comment was added by RexPrincipum (talk • contribs).

@RexPrincipum: I guess the steps are as follows

1. Decide which order to put the inflectional categories in. For instance, does mood come before voice or the other way around (first person present active indicative or first person present indicative active)? Our non-lemma entries are inconsistent in this.
2. Make Module:grc-decl, Module:grc-conj, and Module:grc-headword put the necessary information into the HTML source code of the inflection tables and headword lines.
3. Write Module:accel/grc.

I started a module for an inflected forms template specifically for Ancient Greek (Module:grc-form of) but haven't finished it. It would add some nice features to {{inflection of}}, but isn't strictly necessary for Ancient Greek's integration into WT:ACCEL. — Eru·tuon 05:16, 8 September 2018 (UTC)[reply]

What features are there that {{inflection of}} can't currently do? I'd rather use a generic template. —Rua (mew) 11:45, 8 September 2018 (UTC)[reply]

See my answer at Module talk:grc-form of, and there's more information at Module:grc-form of/documentation. — Eru·tuon 18:52, 8 September 2018 (UTC)[reply]

@Erutuon: My problem is that I don't know how to code at all, so I wouldn't know how to do any of that. RexPrincipum (talk) 16:07, 8 September 2018 (UTC)[reply]

I made Module:accel/grc but I can't make any sense of how the Ancient Greek inflection modules work, so I'll leave that part to Erutuon. —Rua (mew) 18:08, 8 September 2018 (UTC)[reply]

I've added acceleration to {{grc-decl}} and {{grc-adecl}}. I'm not as familiar with {{grc-conj}}, so that will probably take longer. — Eru·tuon 23:28, 9 September 2018 (UTC)[reply]

@Erutuon: is the format they are currently in the only way?, or can they be formatted as "{inflection of|xxx||nom|and|acc|and|voc|n|s|lang=grc}" instead of like "{inflection of|xxx||n|nom|s|;|n|acc|s|;|n|voc|s|lang=grc}" because the current way looks and reads quite awkward — This unsigned comment was added by RexPrincipum (talk • contribs) at 23:38, 9 September 2018 (UTC).[reply]

@RexPrincipum: I prefer the semicolons myself, but that part isn't handled by Module:accel/grc, so Rua will have to answer. — Eru·tuon 23:56, 9 September 2018 (UTC)[reply]

You might also be talking about the order of inflectional categories. I prefer the "gender, case, number" order order, so I went with it. Ideally all entries should have the same order, but it's a hodgepodge, I think. It would be good to have a wider discussion to find out the preferences of the rest of the Ancient Greek editors, and maybe to do a survey of Ancient Greek textbooks, grammars, and other works to see what order they use. — Eru·tuon 00:06, 10 September 2018 (UTC)[reply]

Yeah we should probably make a standard for the ordering of categories, is there a poll function on here or would a strawpoll/google survey be preferable? But also we should agree on semicolons vs 'and', but I agree that semicolons would work better for this. RexPrincipum (talk) 00:09, 10 September 2018 (UTC)[reply]

I started a discussion at Wiktionary talk:About Ancient Greek § Setting a standard order of inflectional categories and pinged many of the editors who have posted there or who I know work on Ancient Greek. I think a vote might be too restrictive for this particular question. — Eru·tuon 19:31, 10 September 2018 (UTC)[reply]

Actually, there's one remaining problem with Ancient Greek acceleration. The three numbers will not be sorted properly; for instance, see this revision, where "neuter nominative plural" is before "masculine accusative singular". I have to add data-accel-col attributes to make the singular sort before the dual, and the dual before the plural, and probably something has to be done for genders too. I'm not fond of this solution; I feel it would be clearer to put the various form codes in a table and sort them with a function. Maybe I can figure out how to implement that. — Eru·tuon 23:41, 10 September 2018 (UTC)[reply]

Okay, got data-accel-col to work. I guess there's no point coming up with a more complicated method unless the forms need to be combined in some more complex way, like labeling a form "masculine and neuter nominative and accusative and vocative dual". — Eru·tuon 04:27, 11 September 2018 (UTC)[reply]

@Erutuon: I think that is great!! :), but think it should be sorted first by whatever catagory we end up deciding comes first, so if we decide on 'Gender Case Number' it should be sorted by gender first so all the male entries go first, then female then neuter. but if we decide on 'Case Gender Number', it should be ordered as all the nominative then accusatives then so on. I say this because now it sorts by case first even though gender comes first. Also honestly I prefer the __'and' ___ way. RexPrincipum (talk) 14:49, 11 September 2018 (UTC)[reply]

Category:All topics does not make sense with Category:List of topics, does it? Category:en:All topics contains Category:en:List of topics and is contained in it. Somebody needs to sweep through it as it seems to me. Fay Freak (talk) 13:16, 8 September 2018 (UTC)[reply]

I think the intended difference is that the former is nested (to get to e.g. "milk" you have to first go to "body", then "body parts", then "bodily fluids"), whereas the latter is like an index, so you can search alphabetically to see if there's a certain category. I don't know if this is useful, bbut it doesn't seem harmful. - -sche (discuss) 17:59, 8 September 2018 (UTC)[reply]

I see, the whole topical category structure is ordered by two principles: One of linear listing and one of hierarchy. But then there is Category:All sets. It, Category:en:All sets, contains bizarrely category Category:en:Names, Category:en:Periodic occurrences which could be in Category:en:Time. “Celestial bodies” is already in ”Space”, “Lifeforms” in “Nature”. Other “sets” are only in “List of sets”, Category:en:List of sets. Is the distinction between a list of sets and a list of topics that the former contains finite sets (e.g. month names) and the latter infinite sets (e.g. torture practices) of terms? And is there a principle according to which the growth of either shall be mitigated? So should Category:en:Buildings and structures be in Category:en:List of topics or is it enough that Category:en:Architecture is in Category:en:List of topics because Category:en:Buildings and structures is in Category:en:Architecture? Because one could say that “Buildings and structures” in a strict sense aren’t a topic but “Architecture”.

(I hope for our not reaching that point where grown complexity has gone beyond human understanding.) Fay Freak (talk) 18:41, 8 September 2018 (UTC)[reply]

The distinction is not well maintained by everyone in practice, but my understanding is that the set categories like Category:en:Stars are sets/lists of terms for stars, like Zeta Geminorum and (apparently) white dwarf, whereas topic categories have words related to the topic, e.g. Category:en:Astronomy for words used in astronomy (not for sets of terms for astronomy). But look at e.g. Category:en:Constellations, a list of constellations categorized as a topic (sub)category. There have been proposals to cleanly distinguish them via different naming systems, like "CAT:en:Set:Stars" and "CAT:en:Topic:Astronomy". - -sche (discuss) 19:16, 8 September 2018 (UTC)[reply]

What's going wrong here? Other Esperanto entries such as damna metalroko use the same template in the same way with no problem. —Granger (talk · contribs) 13:38, 8 September 2018 (UTC)[reply]

The only difference I spot is that ablativo absoluta has the -o word before the -a word whereas damna metalroko does it the other way round: and when I copy and paste the page's contents to ablativa absoluto and preview, it looks fine. Maybe it can't (yet) handle the suffixes being in the order -o -a?? - -sche (discuss) 17:56, 8 September 2018 (UTC)[reply]

The function getPos(word) thinks "ablativo absoluta" is an adjective. DTLHS (talk) 18:19, 8 September 2018 (UTC)[reply]

Fixed. The error was because the module didn't correctly guess the part of speech. The solution is to supply it in the |pos= parameter. The error message isn't helpful. — Eru·tuon 19:10, 8 September 2018 (UTC)[reply]

Your fix causes a lot more errors. DTLHS (talk) 19:57, 8 September 2018 (UTC)[reply]

@Erutuon, not only this, but the module should be able to predict part of speech. If there are two words, and one ends in a and the other in o, it must be a noun. —Μετάknowledge^{discuss/deeds} 22:43, 8 September 2018 (UTC)[reply]

Okay, it might be fixed now. I have to be less confident this time. Weird problem with a Lua pattern. It works in Lua 5.3, but not in 5.1, which we're using. Huh. — Eru·tuon 23:25, 8 September 2018 (UTC)[reply]

@Erutuon: If I remove |pos=noun from ablativo absoluta, it still gives me a Lua error. —Μετάknowledge^{discuss/deeds} 23:28, 8 September 2018 (UTC)[reply]

Is this a normally constructed Esperanto word that can be analyzed from its endings, or is this some exception? DTLHS (talk) 23:30, 8 September 2018 (UTC)[reply]

See my comment before last in this thread. —Μετάknowledge^{discuss/deeds} 23:30, 8 September 2018 (UTC)[reply]

@Metaknowledge: (edit conflict) I haven't revamped the part-of-speech detection system yet; I was just fixing my earlier mistake. — Eru·tuon 23:31, 8 September 2018 (UTC)[reply]

Okay, now Module:eo-headword recognizes a term containing both a word ending in -o and a word ending in -a as a noun. I'm not confident this rule will work in all cases, but it at least solves ablativo absoluta. If there are any cases of incorrectly detected part of speech, please add them to Module:eo-headword/testcases or post about them on Module talk:eo-headword. — Eru·tuon 19:37, 9 September 2018 (UTC)[reply]

As a restriction, only if the two words are adjacent. "xxxo estas xxxa" is clearly not a noun. —Rua (mew) 19:39, 9 September 2018 (UTC)[reply]

And I guess if they are the only words: mia nomo estas (though that uses {{eo-phrase}}). — Eru·tuon 20:03, 9 September 2018 (UTC)[reply]

I'm assuming we want to keep that template separate, although I suppose {{eo-phrase}} could be folded into {{eo-head}} if you really want to. —Μετάknowledge^{discuss/deeds} 20:30, 9 September 2018 (UTC)[reply]

Well, merging {{eo-phrase}} into {{eo-head}} would make things harder. If {{eo-phrase}} is kept separate and will always be used for phrases, perhaps the POS detection function used by {{eo-head}} can assume that nothing that should be categorized as a phrase (such as something containing a noun, adjective, and verb) will be supplied to it and anything containing a noun and adjective is a noun. — Eru·tuon 20:39, 9 September 2018 (UTC)[reply]

I am seeing errors in the {{ang-noun}} reading: Lua error in Module:headword/templates at line 102: bad argument #1 to 'gsub' (string expected, got nil) Leasnam (talk) 19:12, 8 September 2018 (UTC)[reply]

There's one I corrected at renscur (I removed the plural form arg in the header), but there is an example at me Leasnam (talk) 19:13, 8 September 2018 (UTC)[reply]

Fixed. @Rua should probably have previewed her edit on a page with a bunch of headword templates. — Eru·tuon 19:29, 8 September 2018 (UTC)[reply]

Ah sorry, that was a stupid oversight on my part. —Rua (mew) 19:33, 8 September 2018 (UTC)[reply]

Hi, I have been working on this little gadget which helps users who does not understand how an entry layout should be, and I finished it today. I am suggesting to open this feature to all users. You can always test it by adding this to your "common.js" file:

mw.loader.load('/w/index.php?title=User:HastaLaVi2/EntryAdder.js&action=raw&ctype=text/javascript');

It pops up when you try to create an article, above the wikicode section, under the "newarticle" table, and also when you search something it appears on the search page as well. ~ Z (m) 22:44, 8 September 2018 (UTC) By the way, the pages I have worked with are: User:HastaLaVi2/EntryAdder.js, User:HastaLaVi2/EntryAdder.js/Data.js. ~ Z (m) 22:49, 8 September 2018 (UTC)[reply]

I have been bugged for a long time about this, and finally took some time exploring on a regular PC. When you open a page for a Chinese character such as 常 on a mobile device, you will find every single collapsible infobox open/expanded. Getting to the definitions takes a **lot** of scrolling.

Looking at the same page on PC browser, one sees these infoboxes closed up and with open buttons to the right. Opening infoboxes gets you the voluminous display _always_ seen on mobiles. Having now seen the open buttons, I scrolled to the right and I *do* see some of them on the mobile device. However, they *don't* work - the infoboxes can't be closed.

I've now tried Chrome, Firefox and even Samsung's browser on my S8. All always have completely expanded infoboxes.

Is the CSS class "mw-collapsed" what is not working? Shenme (talk) 05:37, 9 September 2018 (UTC)[reply]

Hmm, to see what I'm talking about, compare the normal browser display of 常 with the version using https://en.m.wiktionary.org/wiki/常. Nearly every expandable section is permanently expanded. 23 screens full vs. 14 screens in length.

How long has this been broken? Where else do I need to post this query? Shenme (talk) 04:32, 11 September 2018 (UTC)[reply]

I don't know what JavaScript file handles the collapsibility of the boxes in 常, but the mobile version doesn't load the JavaScript in MediaWiki:Common.js, and MediaWiki:Mobile.js has only a little in it. Maybe the code that would make the boxes collapsible is in MediaWiki:Common.js. But I would've thought that the class mw-collapsible would be handled in a cross-project JavaScript file, because of the mw prefix. Other places to post would be somewhere on English Wikipedia, where there are more JavaScript coders, and on Phabricator if they can't help. — Eru·tuon 04:41, 11 September 2018 (UTC)[reply]

AFAIK the code that toggles the show/hide / expand/collapse functionality of our tables is something en.Wiktionarians cobbled together (en.Wikipedia may even have better ways of doing it...), like also the code that shows/hides quotations; look in the "Visibility toggling" section of MediaWiki:Common.js. I recall that there were, at least historically, reasons it wasn't moved to the mobile .js, although I don't recall if the reasons were technical (that it wouldn't work for some or all mobile devices, or they would have difficulty using the toggles, or if something would often happen to break the javascript after it loaded and collapsed the tables, thus preventing them from opening), or just related to the desire to keep the Mobile.js small because it is loaded for all mobile users. I know that, following an earlier Grease Pit request, I tried to add the ViewSwitcher / vsSwitcher code to the Mobile.js (see that page's edit history) but had to undo my edit because it didn't work. I suppose Shenme could copy the "Visibility toggling" code (how much other code, e.g. in the "NavBars" section, needs to go with it to make it work?) to User:Shenme/mobile.js and let us know if it works. (Users other than interface admins can still edit their own .js, right?) Longer-term, we could look into other ways of expanding/collapsing tables, and see if any are better. - -sche (discuss) 06:31, 11 September 2018 (UTC)[reply]

"desire to keep the Mobile.js small because it is loaded for all mobile users"—can we keep things small for desktop users too? ;) —Suzukaze-c◇◇ 06:43, 11 September 2018 (UTC)[reply]

Thank you for the hints. I'll go off looking at things: docs and browser dev tools. It does seem that

https://en.wiktionary.org/wiki/%E5%B8%B8?useformat=mobile

replicates the same behavior seen using "en.m.wiktionary.org". Perhaps that ought to be pointed at for testers here?

And while I understand the desire not to jam a large Common.js down every mobile throat, perhaps it then was not wise to jam all that extra, essentially optional (e.g. Dialectal data), text to mobiles, and uncontrollably displayed. Perhaps the better thing would be for page generation to know (is that possible?) that the destination is mobile and simply not generate that meant-to-be-optional display data. *That* also would be considerate to mobile users. I'll look around, investigate, and try to ask this more intelligently later/elsewhere.

And BTW, I wouldn't be so interested in the glitches if I weren't so enthused by the pan-lang nature of en-wikt. It is lovely to cross-reference all within the same Wiktionary, and I've pointed people to that feature. Shenme (talk) 14:09, 11 September 2018 (UTC)[reply]

I was trying to blank my talk page because I accidentally used the "help" template, however, Wiktionary wouldn't allow me to because it automatically detected it as vandalism. What shall I do? Torrent01 (talk) 11:06, 9 September 2018 (UTC)[reply]

• I've deleted it for you. SemperBlotto (talk) 11:08, 9 September 2018 (UTC)[reply]

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributed about two-three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have an idea for a task and could you imagine mentoring that task? For example, do you have something on mind that needs documentation, research, some gadget or template issues on your "To do" list but you never had the time, and can imagine enjoying mentoring such a task to help a new contributor? If yes, please check out mw:Google Code-in/2018 and become a mentor! Thanks in advance! --AKlapper (WMF) (talk) 13:51, 9 September 2018 (UTC)[reply]

When I go to the Afrikaans section on boor, and click the green accelerated link to bore, then the textbox initially jumps to the newly-added Afrikaans section, then right back to the start. If I disable the gadget and use User:Rua/Gadget-AcceleratedFormCreation.js instead, then the textbox jumps to the Afrikaans section and stays there (this is the desired behaviour). My own userspace script and the global WT:ACCEL are identical, so why does one work and not the other? It makes it hard to test. —Rua (mew) 13:59, 9 September 2018 (UTC)[reply]

I have to turn off the syntax highlighting for any scrolling to happen, and I can't see the scrolling because it takes a while for the view to switch to the textbox, but it's the same for me: the Afrikaans section only shows up when I'm using your version of the script. Huh. — Eru·tuon 03:56, 10 September 2018 (UTC)[reply]

I often use Mediawiki:Edittools when editing Sami entries, but I find it missing when using the translation adder, making me unable to easily insert certain characters. Is there a way to use the two together? —Rua (mew) 12:13, 10 September 2018 (UTC)[reply]

It would be useful to have a list of all entries that have a translation into a given language. If we do it with categories, the list of categories in each English page will be huge. We can hide them, but then other hidden categories (for those who have chosen to display them) will disappear among them. Alternatively we can use tracking templates, but then the list of transcluded templates will be huge, and the list of wanted templates will also be huge, at least for a while until we get around to creating them all. None of these ideas seems particularly workable, but I can't think of anything else. Any ideas? —Rua (mew) 12:27, 10 September 2018 (UTC)[reply]

There's also the matter of template include size. I don't think we're near the limit yet, but it doesn't hurt to consider it. In general, anything on the page itself is going to tax one resource or another. Think about what the redlink categories did before we restricted them- and that was just a few languages. Chuck Entz (talk) 13:44, 10 September 2018 (UTC)[reply]

Can't you just search for {{t|xx}}? Alternatively download the database dump. DTLHS (talk) 16:07, 10 September 2018 (UTC)[reply]

Can a bot do searches? —Rua (mew) 17:41, 10 September 2018 (UTC)[reply]

There is a search API, [1]. DTLHS (talk) 17:49, 10 September 2018 (UTC)[reply]

I'm not quite sure how these work in Module:labels/data/topical. I set up "colour" for Category:Colors, but I wanted to add "color" (reading "color") for those who prefer that spelling using aliases, but failed. Do I need to set up a separate entry? DonnanZ (talk) 07:47, 11 September 2018 (UTC)[reply]

 Done. You almost got it. — SGconlaw (talk) 07:54, 11 September 2018 (UTC)[reply]

OK, it's a little inflexible. It doesn't allow you have "color" reading "color". Thanks. DonnanZ (talk) 08:02, 11 September 2018 (UTC)[reply]

I think the idea is that you are declaring color to be an alias for the main term colour which you have defined in the "labels" statement. If you wish to be able to display "(color)" instead of "(colour)", then I think the only way is to set up a separate entry. (However, maybe someone more familiar with Lua knows another way to do it.) Is it desirable, though, for some entries to display color and others colour? — SGconlaw (talk) 08:17, 11 September 2018 (UTC)[reply]

Hmm, I get your point; I was trying to cater for the preferences and sensitivities of both American English and British English users, which is probably a perennial problem. DonnanZ (talk) 08:29, 11 September 2018 (UTC)[reply]

I wonder if there is any method in Lua to test if the input is "color", in which case "color" should be displayed? This can easily be done in wikitext markup, so I would imagine that Lua can't be less powerful. (I suppose another way would be some sort of gadget or option in "Preferences" that would allow registered users to choose whether they prefer American or British spelling conventions, but it seems unlikely that this will happen anytime soon.) — SGconlaw (talk) 08:38, 11 September 2018 (UTC)[reply]

A temporary fix would be for individual editors to modify their common.css, like what has been done for {{,}}. I'm afraid I have no idea how to set this up, or how it would work in conjunction with Module:labels/data/topical (if this is at all possible). — SGconlaw (talk) 08:45, 11 September 2018 (UTC)[reply]

I haven't looked through the module to see how many cases there are where spelling variations are considered necessary, probably not many. The simplest solution, as I see it, is a separate entry (but I'm holding fire on that in the meantime). DonnanZ (talk) 09:08, 11 September 2018 (UTC)[reply]

The issue of whether it is desirable to have some entries reading "color" and others "colour" still needs to be resolved. Do we have a policy relating to what variety of language to use in entries, or is it just "don't ask, don't tell"? — SGconlaw (talk) 10:45, 11 September 2018 (UTC)[reply]

Maybe that isn't a problem? This dictionary doesn't conform to either American English or British English, although there is a predominance of AmE. Editors can use either freely (if they can't I'm sure the riot act would be read). DonnanZ (talk) 11:36, 11 September 2018 (UTC)[reply]

Yeah. I'm not particularly keen to wade into that minefield if it isn't a problem at the moment ... — SGconlaw (talk) 12:38, 11 September 2018 (UTC)[reply]

My understanding is that we try to keep content in the variety that it started with: I revert edits that change "colour" to "color" and vice versa. That said, I don't remember ever changing new material I'm adding to match the rest of the page. For one thing, I'm not sure I know all the spelling rules for British English- it's not just automatically switching "-or" to "-our" and "-er" to "-re".Chuck Entz (talk) 13:56, 11 September 2018 (UTC)[reply]

Nope, you can't do that: e.g. tremor is never tremour (OK, it's obsolete), and both meter (instrument) and metre (length) are used in BrE. DonnanZ (talk) 14:47, 11 September 2018 (UTC)[reply]

At my thwikt, I always uses aliases to translate topics/labels into Thai and it doesn't break the code. If you want to see, please visit thwikt. However, you must choose one word for main topic/label. --Octahedron80 (talk) 08:34, 11 September 2018 (UTC)[reply]

I think what DonnanZ was trying to achieve was that if an editor types color instead of colour, then "color" is displayed. In other words, the label changes depending on the input. Unless someone more knowledgeable about Lua knows a solution, I think a separate entry for color would be required. — SGconlaw (talk) 08:49, 11 September 2018 (UTC)[reply]

I found Template/Module LangSwitch at Commons. Does this help? It displays language varieties as user's setting. Right now, there are en (AE), en-CA (Canada), and en-GB (BE). I think it can be used some way with topics/labels (it can't be used directly in data module). NVM Thai here we don't need it. --Octahedron80 (talk) 08:52, 11 September 2018 (UTC)[reply]

Hmmm, yes, that's interesting. Maybe someone familiar with Lua can help to assess if commons:Module:LangSwitch could help us here. — SGconlaw (talk) 12:38, 11 September 2018 (UTC)[reply]

As I understand it, this would require css classes that label text as fodder for localization, and js to actually do it. We don't want to make a P. G. Wodehouse quote read like Ernest Hemingway or have two color entries by having it convert indiscriminately. Chuck Entz (talk) 13:56, 11 September 2018 (UTC)[reply]

• hue ? DCDuring (talk) 10:02, 11 September 2018 (UTC)[reply]
  • Not as clear as "color" or "colour", IMHO. — SGconlaw (talk) 12:38, 11 September 2018 (UTC)[reply]

• In the end, as the simplest solution, I added "color" to Module:labels/data/topical, removed the alias and tested it. There's some weird labels in there like "rock paper scissors" (who wanted that?). I asked for a label for "language" once and was vetoed on that, but I still think there should be one. DonnanZ (talk) 11:04, 12 September 2018 (UTC)[reply]
  • Re language: wouldn't that be covered by "linguistics"? — SGconlaw (talk) 11:41, 12 September 2018 (UTC)[reply]

There are labels for "linguistics" and "linguistic morphology" and categories for both; Category:Languages also exists for individual languages. As linguistics is the the study of language, not an actual language, I think they should be labelled separately. DonnanZ (talk) 11:56, 12 September 2018 (UTC)[reply]

Maybe a label should read "languages" so there is no confusion with linguistics. DonnanZ (talk) 12:04, 12 September 2018 (UTC)[reply]

Mmmm, what sort of entries would a "language" tag be placed on? — SGconlaw (talk) 12:15, 12 September 2018 (UTC)[reply]

Any entry for a language, norsk for instance, which has two senses. You could have "language" as an alias of "languages", if that is the appropriate label. DonnanZ (talk) 12:30, 12 September 2018 (UTC)[reply]

I don't think that is the correct use of labels. Clearly an entry for the name of a language should be placed in, say, "Category:en:Languages" using a "Category" statement at the end of the entry. However, it's not really the function of labels to categorize entries. Rather, they are indicating the contexts in which entries are used. These could be the nature of the entry (such as "obsolete" or "slang"), geographical, or topical (such as "computing", "linguistics" or "sports"). — SGconlaw (talk) 15:00, 12 September 2018 (UTC)[reply]

Right. This has been discussed before. - -sche (discuss) 21:30, 12 September 2018 (UTC)[reply]

I can't win 'em all. I don't feel like arguing the toss. DonnanZ (talk) 10:46, 13 September 2018 (UTC)[reply]

If it's not too much trouble, please fix it.--Yoshiciv (talk) 14:23, 11 September 2018 (UTC)[reply]

I am adding entries for Pali in one of its non-Roman scripts, Tai Tham to be precise. As the Tai Tham spelling cannot always be predicted from the Roman script spelling, I believe I need to provide quotations to back up the spelling. The quotations will need to be retyped, transcribed to the Roman script, and translated, all error-prone activities. My first question is therefore:

Q1. How do I automatically transliterate Pali from the Tai Tham to Roman script? Note that the restriction to Pali makes it an easier task than automatically transliterating from Northern Thai to Roman, the latter activity is either impossible to do completely accurately or can only be done with obscure results - compare Thai, where the Romanisation requires manual respelling of the Thai word.

Q2. I intend to use each passage I use for about seven different words. I am finding this target hard to reach because Wiktionary's Pali vocabulary is currently rather small. I am initially taking multiple passages from a single book. I want to make it easy to ensure that corrections to a quotation are propagated to all the places it is used. How may I do this?

My original idea was to have one template for each quotation, which would store the page number, passage, transliteration and translation. This would invoke another template that would format the items and combine them with the reference for the book. @AryanamanA has deleted the per-quotation templates as an abuse of templates. The common template has been improved by others and survives; it now uses {{quote-book}}. The problem with just using the common template is that each quotation would be stored in the text of each page using that quotation. Of course, the common template works fine when I can only use a passage for a single word.

My revised idea is still to have one template for each quotation, but to mark the quotation up so that each invocation can specify a different word for emboldening. Apart from this markup, the data in each per quotation template would remain obvious so that it would be easy to edit. The mandatory template documentation would use a template to store boiler plate editing instructions. The per-quotation templates would then invoke the same Lua module to produce the reference. This module would probably invoke the surviving common template; I aspire to make the module 'general purpose', though there are all the rigidities of passing arguments that are functions. I propose using a Lua module because of the text manipulation required to highlight the selected word.

Q3. Can someone advise me of a better practicable way of propagating revisions?

Q4. Or, tell me that my plan has already been implemented, and where I can find the apparatus to do it with my data.

— This unsigned comment was added by RichardW57 (talk • contribs) at 21:30, 11 September 2018 (UTC).[reply]

How do I automatically transliterate Pali from the Tai Tham to Roman script?. You (or someone) will need to implement Module:pi-translit for the Tai Tham script. This can then be used by our language infrastructure. @DerekWinters created that page, maybe they can help. DTLHS (talk) 21:42, 11 September 2018 (UTC)[reply]

Can someone advise me of a better practicable way of propagating revisions? Your goal should be to minimize the number of individual templates you are creating- at most one for each work, definitely not one for each quotation. You could store the actual text in a data module. DTLHS (talk) 21:50, 11 September 2018 (UTC)[reply]

I'm surprised that's better for performance - or do parsed data modules now get cached across pages? In Wikimedia incubator a text data module is quite horrible for editing. In one editor mode there is a busy script which was overheating my computer (hardware problem), and the other mode is unusable without a monospaced font. Still, I suppose those problems will go away eventually. - RichardW57 (talk) 00:54, 12 September 2018 (UTC)[reply]

How would one generate bold for the headword in the quote, which presumably differs for each instance. It doesn't seem impossible at all, but is the game worth the candle?

Also, wouldn't some words need much more context than others? Eg, in English, adjectives need relatively little, I think, but words like pronouns, that are involved with deixis, or words like conjunctions that link different kinds of clauses need more. DCDuring (talk) 23:14, 11 September 2018 (UTC)[reply]

The emboldening is bothering. The trick I have in mind is to mark the text up so that the text for word 8 is delimited by something like -8{..}. (The numbering would be arbitrary.) I could then exploit the nesting capabilities of Lua pattern recognition where appropriate - transparent compounds could be validly used for all three words if the compound merits a dictionary entry. The template would call out Word 8 by passing '8' as a template. I could allow fancier tags, but I'm not sure it would be worth the effort. - RichardW57 (talk) 00:54, 12 September 2018 (UTC)[reply]

As to variable context, I don't think it's a problem:

• Some words might get unnecessarily long context, but that doesn't really hurt.
• I'm not planning to demonstrate the existence of Pali words, at least not yet; I am planning to demonstrate their spelling(s) in the Tai Tham script. I think there may be some subtle rules in the choice of round AA v. tall AA, and I am confident that some words will show both forms. I'm also turning up interesting patterns in the spelling of -bb-. - RichardW57 (talk) 00:54, 12 September 2018 (UTC)[reply]

Like AryanamanA, I'm also uncomfortable with the idea of creating separate templates for individual passages of text. Quotation templates are supposed to usable for multiple quotations, and it seems to me quite unnecessary to have a template so specific that it can ever only be used, say, seven times. I would say just use the general quotation template {{RQ:pi:Sai Kam Mong}} and plug in the quotation each time. With copy and paste I can't see how this is very difficult. — SGconlaw (talk) 06:33, 12 September 2018 (UTC)[reply]

@Sgconlaw: Copy and paste is a very good way of propagating error. Also, the translations may not be the best - I have to worry about copyright. With a database, corrections and improvements get propagated to all the instances of the quotation. Also judgements as to what the text is may change. For example, I read 'do devena' where the text should say 'deva devena'. I'm now wondering whether I have misinterpreted a photocopying/printing blemish, and the text actually does say 'deva devena'. What I see depends on exactly where I hold the magnifying glass. If there was no error in the text as written, I need to correct the quotation. Because of AryanamanA's efforts, I will have to track down the various users of the quote and change each of them, instead of changing a single master. - RichardW57 (talk) 08:07, 12 September 2018 (UTC)[reply]

You might save a bit of time, but frankly I doubt it would be much. You can just search for a phrase using the search box at the top right corner of the screen to pull up all entries that have that phrase. — SGconlaw (talk) 08:41, 12 September 2018 (UTC)[reply]

RichardW has reasonable concerns. Although we don't currently have such a framework, a trial run wouldn't hurt IMO. —Suzukaze-c◇◇ 08:09, 12 September 2018 (UTC)[reply]

Maybe at some stage this information would be stored on Wikidata. — SGconlaw (talk) 08:41, 12 September 2018 (UTC)[reply]

I think it may be a good idea to have some quotations housed in a central location so they can be edited in multiple entries simultaneously, but there still can be one template per work, if it has a parameter to select a quotation and a parameter to determine which word to embolden. In addition, if the quotations were housed in a data module and selected with Lua, then I can imagine ways to embolden, say the first and third words, or words with the stem dev, without adding any bracketing to the quotation (as discussed at User talk:RichardW57 § Pali references/quotations). — Eru·tuon 18:51, 12 September 2018 (UTC)[reply]

The trial module, Module:RQ:pi:Sai Kam Mong, is now encoded, including documentation and testcases.

@Erutuon, do your ideas need word boundaries to be marked? One of the tricky bits is ensuring compatible mark-up between text and translation. Transliteration will normally work on marked up text. - RichardW57 (talk) 01:50, 13 September 2018 (UTC)[reply]

Well, words or highlightable parts of words can be defined as things separated by spaces or hyphens. It's pretty simple to highlight words by number with a gsub that's operating on sequences of non-word-separator characters and that has a count variable incremented inside it. I'll write a first draft in the module. — Eru·tuon 02:05, 13 September 2018 (UTC)[reply]

The 'devadevena' I mentioned earlier had a space in the middle, but 'deva' is not an indeclinable. And what about a zero width space? (Strictly, though, that's a line-break control and not a word separator.) - RichardW57 (talk) 07:16, 13 September 2018 (UTC)[reply]

What about the zero-width space? Whether it can be added as a word separator in the function? — Eru·tuon 07:56, 13 September 2018 (UTC)[reply]

I'm uneasy about it, because it isn't recorded on palm leaf. It's a matter of interpretation, and aesthetics when typing or displaying the quote within a narrow window. The same goes for spaces in manual transliteration. In general, using anything like a string index is going to be very vulnerable to corrections. Remember that I said that NA and NAA can be hard to tell apart. The first is one character, and the second is two.

I've just had to think hard about the handling of the line-break in the middle of the place name "Sāvatthī" in script. I decided that the most honest representation was "­" so that it was visible to an editor. A future editor might replace it by an actual soft hyphen. - RichardW57 (talk) 19:44, 13 September 2018 (UTC)[reply]

I still don't see what you're getting at. My function doesn't use string indices and it considers the zero-width space as a word character because it isn't in the set of non-word characters (which only includes the basic space character, no other spacing or control characters). The HTML character reference ­ will cause problems in the function right now, though. — Eru·tuon 20:36, 13 September 2018 (UTC)[reply]

@Erutuon: The relevant text with the soft hyphen is data[241]["ekam"] in Module:RQ:pi:Sai_Kam_Mong/passages. The text marked up in transliteration as "{4-sāva­tthīyaṃ} {6-viharati} {7-{8-jeta}{9-vane}} {10-anāthapiṇḍikassa}" has at most one white space character in the original - the line break I have encoded as soft hyphen. (Active soft hyphens are invisible in the Tai Tham script; I don't know if any renderers know that.) In the 'quote' version, there is only mark-up between these four words, as can currently be seen in ᩅᩥᩉᩁᨲᩥ for the Tai Tham form of viharati. I believe that limited line length is the only reason that the word "ārāme" on the next line is separated; I have hesitatingly separated it by a space in the quote. Perhaps that separator should be a ZWSP. (Can we do multi-line quotes? Do I stick colons in the text?). Now, how would you highlight just one of those four words, or would you also highlight the translation of all four of them? I'm considering extracting both Jeta and vana from Jetavana, which you might consider a challenge for mark-up. - RichardW57m (talk) 12:08, 14 September 2018 (UTC)[reply]

Actually, I've already partly worked out how to do multiline quotes. One just uses <br/>. However, that doesn't look right for starting a quote in mod-line when a line break is part of the text. The line structure may be relevant to the strangeness of the spelling of the genitive singular ending in 'anāthapiṇḍikassa'. - RichardW57m (talk) 14:11, 14 September 2018 (UTC)[reply]

Yes, I've used a <br> tag to add a line break in quotations of Ancient Greek poetry and dialogues; for instance, ἔγωγε (égōge) and -φι (-phi). (The tag needn't have the slash, which is removed by the parser from the resulting HTML: <br/> → <br>.) That is the best solution. (Or line breaks can be respelled as /.) I recall there were cases where a quotation starts in the middle of the line (found one: ἀτασθαλία); I didn't do anything special for them.

Generally you highlight (embolden) the word that the entry is about, its transliteration (if any), and its translation. Or are you asking something else? — Eru·tuon 20:17, 14 September 2018 (UTC)[reply]

@Erutuon: What would you highlight in the quotation for the virahati entry ᩅᩥᩉᩁᨲᩥ? I've just highlighted 'ᩅᩥᩉᩁᨲᩥ', 'virahati' and 'was staying', but ᩅᩥᩉᩁᨲᩥ is, by your definition, if line breaks including <br> are non-word characters, part of the longer word which unintelligently transliterates as 'tthīyaṃviharatijetavaneanāthapiṇḍikassa'. If you don't treat <br> as implying a word boundary, you get the whole sentence 'sāvatthīyaṃviharatijetavaneanāthapiṇḍikassaārāme' as a single word. Restoring the line breaks in the quote database doesn't significantly affect the entries using my mark-up. I fear that entries using your scheme would be badly affected by such a change. I suspect the genitive singular ending '-ssa' is spelt oddly to help with the justification of the line - a vertical conjunct is used instead of the normal horizontal one seen earlier in the text. The text is justified flush right. - RichardW57 (talk) 09:25, 15 September 2018 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I can add a rule that will make <br> be treated as a non-word character. To deal with the lack of spaces between words, I would suggest separating words with a character that is not used elsewhere in the quotations and can be removed by the highlighting function (so that it is not displayed in entries). Maybe a hyphen would work, but I'm not familiar with the writing system so I don't know if it's ever used there. Actually, the hyphen is used in the transliteration, so it's not a good solution. — Eru·tuon 18:48, 15 September 2018 (UTC)[reply]

You do realise that you're now visibly marking up the text! Compare the daunting mark-up on data[241]["atha"] in Module:RQ:pi:Sai Kam Mong/passages with the clean text when the quotation appears in ᨴᩮᩅᨲᩣ (devatā). The highlighting function would naturally replace the word-separation symbol by zero-width space. While we're at it, I suppose we could have a mark for the boundaries in compound words (tatpurushas and the like) - though you're heading for something like the mark-up system I'm using. Yours has less mark-up, but I fear is consequently less robust. - RichardW57 (talk) 22:24, 15 September 2018 (UTC)[reply]

Yes, I hadn't realized (or noticed) that the words weren't all separated by spaces. In my method the quotation is less cluttered at least, but yes, it would require more work if word or word-part divisions in a quote were changed; then any emboldened word or word-part after that point in the quote would have to have its numbering changed in the template.

Another idea is to let editors input the words or word-parts that they want to highlight, and the module would search for and embolden them (and emit an error if they were not found). That might be easier and more robust than either solution, as long as the emboldened words in the quotation never change. You would just have to preview the quotation and copy the word that you wanted highlighted into a parameter in the template. No counting or deciphering brackets required. I might need to work through some issues with HTML character references and invisible characters, though. — Eru·tuon 23:03, 15 September 2018 (UTC)[reply]

This later idea is the one I first had. Unfortunately, all sorts of things are going to go wrong with highlighting short words. Numbered brackets KISS, and they're working. Also, my use case is different to yours. If you look at the passages I have marked up already, you will see that I have considered using every bit of the quote. Now, as the corpus grew this would get less intense - there's a limit to how many times I can use 'Jetuvana'. Another difference is that I am not yet proving the existence of a word, let alone its meaning: I am confirming its spelling. 7 consonants have two different subscripts, there are two different vowels for /ā/, and two different consonants for Pali <p>. On top of that, we have abecedaries that deny the existence of <ch>, "zjh" (or whatever you want to call LOW SA) in place of "jjh" in some recent teaching books (admittedly not for Pali), and creeping Sanskritisation - a Pali name for Rangoon is Trikumbhanagaraṃ. I think I'm seeing degemination of "ññ" - but then the letter for "ñ" corresponds to the Burmese letter for "ññ". - RichardW57 (talk) 03:07, 16 September 2018 (UTC)[reply]

@RichardW57: Okay, it does finally sound like neither of my ideas will work any better than the one you settled on. Interesting. They might work well for a language with more settled word separation, though, if that ever comes up. — Eru·tuon 15:35, 17 September 2018 (UTC)[reply]

I'd like to recommend the below CSS change to force derived terms to display in single column on mobile, which is otherwise too small to display multiple columns properly. This should probably be expanded to elsewhere, but this where I primarily experience this.

@media only screen and (max-device-width: 480px) {
	.derivedterms { column-count: 1 !important; -moz-column-count: 1 !important; -webkit-column-count: 1 !important; }
}

--Victar (talk) 21:38, 11 September 2018 (UTC)[reply]

Does it need to go in MediaWiki:Mobile.css? DTLHS (talk) 21:48, 11 September 2018 (UTC)[reply]

@DTLHS, I don't have any previous experience in modifying the global Wikt CSS, but that looks about right to me. --Victar (talk) 21:52, 11 September 2018 (UTC)[reply]

Added, please test. DTLHS (talk) 22:13, 11 September 2018 (UTC)[reply]

@DTLHS, works great, though I think you can remove the @media envelope since it's already in a mobile specific CSS. --Victar 22:37, 11 September 2018 (UTC)[reply]

Perfect. --Victar (talk) 22:47, 11 September 2018 (UTC)[reply]

Does this need to be in global CSS? If the class is only used by the one template, we could just add it to that template via TemplateStyles. This would also have the benefit of running for small screens outside other than mobile (assuming we keep the @media). --Yair rand (talk) 07:20, 13 September 2018 (UTC)[reply]

That's a good question, @Yair rand. I wouldn't know. I do know that this should probably be expanded to other multi-column formatted modules. --Victar (talk) 20:29, 20 September 2018 (UTC)[reply]

What is the intended point of edits like this? To me, this looks like a nuisance edit -- the result is mostly the same as doing nothing, with the added annoyance that various things in the displayed wikisource are now bolded, italicized, and color-coded for non-obvious reasons. It appears that the MediaWiki syntax highlighter extension actually doesn't support MoinMoin wikicode, leading me to believe that the syntax highlighter is falling back on some default mode (perhaps C++?). Even if the highlighter did support MoinMoin, MoinMoin wikicode differs from our wikicode in some substantial ways.

Is the linked diff edit a good one? Or should I be reverting this on sight? ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:26, 12 September 2018 (UTC)[reply]

In the particular diff you link to, the italicization and colors are indeed undesirable and I would undo the change. - -sche (discuss) 16:59, 12 September 2018 (UTC)[reply]

"Pygments does not yet provide a "wikitext" or "mediawiki" lexer (phab:T29828). Use "html", "xml", or "moin" instead."? —Suzukaze-c◇◇ 17:47, 12 September 2018 (UTC)[reply]

Yes, except 1) MoinMoin syntax isn't MediaWiki syntax, and 2) the highlighting, coloring, bolding, and other formatting isn't particularly helpful nor desirable when all we're trying to do is display wikicode as straight unparsed monospace text. By cluttering up the visual display, I would argue that this is not just a change without value, but rather a change with negative value.

Also, the edits by Cedar101 (talk • contribs) at WT:AJA here include a couple cases of replacing <pre> with <source lang="text"> -- which I also fail to see as anything other than nuisance, as it is both longer code and provides zero value.

Separately, I note on the user's talk page on Wikipedia that there are a number of threads and comments about nuisance formatting edits. This does not fill me with confidence about the user's current behavior here. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:32, 12 September 2018 (UTC)[reply]

Mediawiki syntax is originated from MoinMoin. So, some parts of them resembles each other. In WT:AJA, <source> highlights the markups of section headings, wikilinks and lists(ordered and unordered), but cannot highlight template markups.

Unlike <code><nowiki>...</nowiki></code> and <pre> that have some limitations, <source lang="text"> renders perfect 'as-is' pre-formatted text. -- Cedar101 (talk) 02:14, 13 September 2018 (UTC)[reply]

I am not aware of any limitations to the previous approach that are fixed by using <source...>. For that matter, under the hood, the parser uses <pre> tags for all of these anyway -- the color coding and other formatting is applied using <span> tags with inline CSS, within the <pre> tags.

Opening the version before your edits and the version after your edits and comparing them side-by-side, other than a newline and single extra whitespaces at the start of certain lines that you explicitly added, the only differences are the color-coding, bolding, and italics -- none of which are desirable in this context, and which could actually confuse editors, especially beginners.

Do other editors see any compelling positives here that I'm missing? If not, I move that we revert this change. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:00, 13 September 2018 (UTC)[reply]

2018 September 14, “mw:Extension:SyntaxHighlight#Advanced”, in MediaWiki:

Unlike the <pre> and <code> tags, HTML character entities such as   need not (and should not) have the & character escaped as &.
Like the <pre> tag but unlike the <code> tag, tags within the range (other than its own closing tag) need not have the < symbol escaped as <, nor does wikitext need to be escaped with a <nowiki> tag.

According to w:MOS:MARKUP (in w:WP:MOS), w:MOS:COLOR and w:MOS:DEVIATIONS (in w:MOS:ACCESS), manual uses of inline CSS style attribute considered harmful. -- Cedar101 (talk) 01:43, 14 September 2018 (UTC)[reply]

Regarding your first point, that strikes me as (at best) a minor convenience point for inexperienced editors learning how wikicode gets rendered. Anything already correctly rendered by <pre> tags would need conversion then to display correctly in <source lang="text"> -- somewhat reducing the justification you give for using that.

Regarding your second point, it may have escaped your notice, but 1) Wiktionary is not Wikipedia, and 2) nowhere in this thread do I advocate using inline CSS. ‑‑ Eiríkr Útlendi │^{Tala við mig} 04:04, 14 September 2018 (UTC)[reply]

Rather, Wiki/HTML markup escaping using <nowiki> and HTML entities is difficult to inexperienced editors and cumbersome to experienced users, too. For example, See <nowiki> uses and HTML entity uses. -- Cedar101 (talk) 08:44, 14 September 2018 (UTC)[reply]

2013 September 9, “Unnecessary <nowiki>s in <source>”, in Help:Glosses‎^[2]:

 <nowiki>
 ====Synonyms====
 * {{sense|</nowiki>''gloss1''<nowiki>}} [[branch]], [[twig]]
 * {{sense|</nowiki>''gloss2''<nowiki>}} [[record]]
 </nowiki>

Your change to <source lang="moin"> renders this differently than intended.

How it used to appear as rendered on the page, and frankly how it should appear:

 ====Synonyms====
 * {{sense|gloss1}} [[branch]], [[twig]]
 * {{sense|gloss2}} [[record]] 

How it appears after your change:

 ====Synonyms====
 * {{sense|''gloss1''}} [[branch]], [[twig]]
 * {{sense|''gloss2''}} [[record]]

This is incorrect, and erroneously informs the user to add '' around glosses.

Regardless of how "nice" it might be to "clean up" the wikicode, if the end result is incorrect, such "cleanup" should be reverted.

There has been no substantive argument in favor of <source lang="moin">, and several examples and a couple opinions in opposition. I will start reverting this change. ‑‑ Eiríkr Útlendi │^{Tala við mig} 16:30, 14 September 2018 (UTC)[reply]

The indices are not very good, usually don't exist, are not being upkept, and have long since been supplanted by the lemma categories. I suggest that we no longer link to it with {{langcatboiler}} (see the right-hand sidebar on Category:English language, for example). —Μετάknowledge^{discuss/deeds} 23:44, 13 September 2018 (UTC)[reply]

e.g. here: [3]. Equinox ◑ 06:05, 14 September 2018 (UTC)[reply]

Ahh, I can see the issue (in the part of code after the comment "Does the page already exist?"). The regex is sticky. It is first used on the text to be added, and matches the English header. That sets the lastIndex property to the index directly after the match, which means the regex will next match starting at that position in whatever string it is used on. Then when it is used on the existing text of the entry, it doesn't find the French header because it is not starting matching at position 0 where the French header begins, and therefore drops the English section at the end. So, from playing around in my browser's console, I think the solution is to set langsection_regex.lastIndex back to 0 before using it in the while loop. — Eru·tuon 06:29, 14 September 2018 (UTC)[reply]

I understand. It used to work fine so I think someone has broken it. Equinox ◑ 06:32, 14 September 2018 (UTC)[reply]

Before the recent changes, the regex just wasn't used to find the language name in the new text. It was a simple oversight. — Eru·tuon 07:31, 14 September 2018 (UTC)[reply]

e.g. here: [4]. Equinox ◑ 12:25, 15 September 2018 (UTC)[reply]

Fixed by removing that line in MediaWiki:Noarticletext. —Μετάknowledge^{discuss/deeds} 16:18, 15 September 2018 (UTC)[reply]

The inflections need a small correction. 2nd person imperative forms should be changed in positive and in negative. For the positive, they are formed by imperative stem + (y)Vn, where V is the harmonizing vowel and (y) – the epithetic consonant after stems ending in a vowel.

The following positive forms are the correct ones: olmaq – olun, qorxutmaq – qorxudun, oxumaq – oxuyun, görmək – görün, böyütmək – böyüdün, üşümək – üşüyün, almaq – alın, sarsıtmaq – sarsıdın, anlamaq – anlayın, vermək – verin, etmək – edin, demək – deyin, çatmaq – çatın.

For the negative, they are formed by imperative stem + m(V), where V is a (for back vowels) or ə (for front vowels) + yVn, where V is the harmonizing vowel.

The following negative forms are the correct ones: olmaq – olmayın, qorxutmaq – qorxutmayın, oxumaq – oxumayın, görmək – görməyin, böyütmək – böyütməyin, üşümək – üşüməyin, almaq – almayın, sarsıtmaq – sarsıtmayın, anlamaq – anlamayın, vermək – verməyin, etmək – etməyin, demək – deməyin, çatmaq – çatmayın. Many thanks in advance. Allahverdi Verdizade (talk) 09:33, 17 September 2018 (UTC)[reply]

E.g. at canción de cuna. It just pastes the entire IPA transcription together without regard for spaces between words. — Mnemosientje (t · c) 17:44, 17 September 2018 (UTC)[reply]

Hi, I just launched a phabricator ticket on Provide a Wikibase instance where we can import Wikitionaries materials and that can be queried from Wiktionaries". Feel free to comment there, please be bold with spreading the word in other wiktionnaries where you might contribute so we can get as much as we can of relevant comments from the large Wikitionary family. Cheers, Psychoslave 14:14, 18 September 2018 (UTC)[reply]

This proposal may not be cristal clear. The idea is to develop a script to transform Wiktionaries data - or dumps - into a Wikibase format under CC BY-SA, allowing to query on texts such as definitions, examples, written etymologies and notes. Those text will never be in Wikidata's Lexicographical data project because there are creative. This is the more valuable content in Wiktionaries and the idea is not to change the way we edit or format the data. Just to have a new way to offer the data, to help the reuse and query in a new interface, using the powerful Wikibase extension. What do you think about this idea, is it sound awesome? Noé 16:52, 20 September 2018 (UTC)[reply]

CKoerner (WMF) (talk) 15:34, 18 September 2018 (UTC)[reply]

When I look at my "Contributions" page, https://en.wiktionary.org/wiki/Special:Contributions/Mihia, I see a tab labelled "CollabPad". Out of curiosity, does anyone know what that is and what it does? When I click on it, I see this:

Permission error

You do not have permission to do that, for the following reason:

You are not allowed to execute the action you have requested.

This really gave me a laugh. I just love how the "reason" provides all that extra useful information! Mihia (talk) 20:58, 19 September 2018 (UTC)[reply]

[5] DTLHS (talk) 21:00, 19 September 2018 (UTC)[reply]

Aha, thanks. I wondered why I had not noticed it before. Anyway, it seems to have disappeared now. Mihia (talk) 21:49, 19 September 2018 (UTC)[reply]

Is this the right place for requests for new features? What this site desperately needs is a system for alerting you to new posts in a discussion page thread that you have participated in. The way it works right now is hopeless. Unless someone specifically "pings" you, you have no idea when you have a reply or a related comment to look at, short of repeatedly checking each thread manually. When, like me, you contribute to dozens and dozens of threads, this is completely impractical. Mihia (talk) 21:50, 19 September 2018 (UTC)[reply]

Some of us read the diffs: you open the revision history for the forum, then click on the diff for the oldest one that's highlighted as updated since you last visited (if you open it to the current revision, all the highlighting goes away). You then click "Go to next edit" until you've gotten to the current revision. You may need to go to your preferences to uncheck "Do not show page content below diffs" in the "Appearance" tab. After a while you get used to reading the wikitext in the diff rather than the actual formatted content. An added plus is you always know who's posting and in what order even if people forget to sign your posts. The main drawback is clicking through edits that are just archiving, and then there are people like @Leasnam, who's been known to take literally dozens of revisions to get what he's saying exactly the way he wants. Also, you can't really choose which threads to read unless you use the revision slider or constantly go back to the revision history. Since I read everything in all of the forums anyway, that doesn't bother me. Chuck Entz (talk) 02:25, 20 September 2018 (UTC)[reply]

How about the watchlist? —Suzukaze-c◇◇ 02:32, 20 September 2018 (UTC)[reply]

I use the watchlist to see which forums have new diffs to read. What I said above is based on the assumption that the forum in question is one with new content that you've decided you want to read. Chuck Entz (talk) 03:23, 20 September 2018 (UTC)[reply]

OK, thanks for the suggestion, but I really only want to see activity on the threads that I have participated in. I don't want to page through every single edit on a whole forum. Mihia (talk) 17:54, 20 September 2018 (UTC)[reply]

I think the threaded discussion extensions to MediaWiki can do what you are requesting, however they come with a host of other problems. Liquid Threads is one that is installed here. As far as I am aware messages and notifications cannot be sent via the API, so any solution would have to be done on the server side. The place to request those features is Phabricator. - TheDaveRoss 18:38, 20 September 2018 (UTC)[reply]

When I generate a noun, the plural form shows up as green. But when I click on the green link I just get an empty edit window that I have to fill in myself. Has something changed? SemperBlotto (talk) 05:34, 20 September 2018 (UTC)[reply]

• And the same happens for verb forms. SemperBlotto (talk) 05:45, 20 September 2018 (UTC)[reply]

(edit conflict) @SemperBlotto: Oh yes, there is an error in the JavaScript console (as opposed to Module:accel) that probably affects all accelerated links: TypeError: "mw.Api is not a constructor".

Nothing in the script has been changed recently, so probably something in the site's JavaScript has changed. To other JavaScript people, mw.Api is a constructor when I use it in the browser console (on the same page where the error above has occurred), so I guess it is not being loaded in time for the script to use it. Maybe it can be loaded somehow with mw.loader.using? — Eru·tuon 05:53, 20 September 2018 (UTC)[reply]

I tried that but it's still broken. DTLHS (talk) 06:00, 20 September 2018 (UTC)[reply]

Happily now at least it's a different error. generateEntries now needs to somehow return what api.get returns. Complicated since there are two layers of Promises now. — Eru·tuon 06:43, 20 September 2018 (UTC)[reply]

Working version in User:Erutuon/scripts/accel.js. — Eru·tuon 06:53, 20 September 2018 (UTC)[reply]

OK. Could you copy that to the live version (wherever that is) please? SemperBlotto (talk) 08:16, 20 September 2018 (UTC)[reply]

Thanks, still doesn't work. DTLHS (talk) 16:11, 20 September 2018 (UTC)[reply]

It's working fine when I try creating forms of a random Ancient Greek noun. Where's it not working for you? — Eru·tuon 19:06, 20 September 2018 (UTC)[reply]

Never mind, it must have been cached. DTLHS (talk) 19:08, 20 September 2018 (UTC)[reply]

I don't know if this text is generated by a "System message" (or even if the Grease Pit is exactly the right place to bring this up), but I'd like to bring up something that I noticed after I clicked on a red link, Verdinglichung:

Remember that Wiktionary is case sensitive. You probably want to edit the lowercase version of your word: verdinglichung. If you are entering a word that is always capitalized, like "German" or "Marxist", please proceed.

Now, the word "Verdinglichung" is German. For just a fraction of a second, I thought that the example was actually saying something about what to do with German words. (Nouns are capitalized in German even if they aren't proper nouns.) I also didn't know how English Wiktionary handles foreign capitalization procedures until just now (based on Hund and hund, we follow native rules).

So I could see someone being even more confused about entries for German words than I was. I would propose using a different example in the System message (?) besides "German". Ardric47 (talk) 05:06, 21 September 2018 (UTC)[reply]

That's a fair point. I've had a similar thought (and thought that maybe we should add an example/mention of a German noun). I think it should be changed to something that's not a language name. Maybe "African" or "Balkan"? - -sche (discuss) 05:59, 21 September 2018 (UTC)[reply]

The message in question is MediaWiki:Newarticletext. - TheDaveRoss 12:22, 21 September 2018 (UTC)[reply]

 Done Changed it to "Antarctica". Equinox ◑ 13:45, 21 September 2018 (UTC)[reply]

entry https://en.wiktionary.org/wiki/// exist, but link doesn't work, neither as [[//]] ([[//]]) nor as [Term?] ({{l|mul|//}}). After that's fixed, entry --#Synonyms needs to be cleaned-up. -07:38, 22 September 2018 (UTC)

It can be linked with a leading colon: [[://]]. However, Module:links ({{l|mul|//}}) ought to be able to link to / and //. I can work on that. — Eru·tuon 07:50, 22 September 2018 (UTC)[reply]

Thank you (for the reply and the clean-up)! -08:44, 22 September 2018 (UTC)

: works fine for me. —Rua (mew) 12:30, 29 September 2018 (UTC)[reply]

Right, but there used to be an unsupported title (Colon slash slash), so {{l|mul|://}} used to link there and not to //. So using a colon might not do what you intend, though at the moment I don't see any unsupported titles beginning in a colon that, if one removes the colon, are a possible title that breaks the link syntax as [[//]] does, and hence needs a colon to make the link syntax valid.

Anyway, forgot to report here that I made it so that {{l|mul|//}} also works (the module now adds the colon): [Term?]. So there's no need for the colon now, and it's clearest if the colon is omitted in the wikitext. — Eru·tuon 18:23, 29 September 2018 (UTC)[reply]

Is there any reason why we can't have {{reconstruction}} automatically added to Reconstruction namespaces, perhaps using mw:Extension:SkinPerNamespace? --Victar (talk) 16:50, 24 September 2018 (UTC)[reply]

No. I wanted to suggest it too. Fay Freak (talk) 17:42, 24 September 2018 (UTC)[reply]

No... there is no reason why not, or no there is no way? --Victar (talk) 18:10, 24 September 2018 (UTC)[reply]

@Victar You have shown a way, haven’t you? I don’t know. I answered about the reason, not the way. Fay Freak (talk) 18:35, 24 September 2018 (UTC)[reply]

No, @Fay Freak, I was asking if the extension mentioned would make it possible, thus the "perhaps". Your reply was unclear and grammatically broken, so it needed clarification. Thanks for your support of the idea, however. --Victar (talk) 19:04, 24 September 2018 (UTC)[reply]

Another hacky way it could be done is something like this:

$.ajax({ 
  url: "https://en.wiktionary.org/wiki/Template:reconstructed", 
  type: "GET", 
  dataType: "html" 
}).done(function(html) {
  var messageBox = $(html).find('.messagebox');
  messageBox.prependTo('.ns-118.action-view #mw-content-text');
});

--Victar (talk) 19:04, 24 September 2018 (UTC)[reply]

I recall this being discussed before. I looked at mw:Extension:SkinPerNamespace, but didn't see anything specifically related to transcluding something at the top of all pages in a particular namespace. — Eru·tuon 19:09, 24 September 2018 (UTC)[reply]

A previous discussion (Wiktionary:Grease pit/2017/June § Citations at citations) mentioned that the PageNotice extension would make this possible, if it were installed, but apparently it wasn't put up for a vote. — Eru·tuon 19:19, 24 September 2018 (UTC)[reply]

@Erutuon, yeah I'm very clueless to how Wiki skinning works. I thought perhaps though if it allows for child skins, we could create a special page skin and apply that skin just to reconstruction namespaces. mw:Extension:PageNotice seems a much cleaner option though. I've pinged @-sche in the aforementioned discussion. --Victar (talk) 19:23, 24 September 2018 (UTC)[reply]

@Victar: Well, all I know is that skins modify CSS and maybe JavaScript. I don't know if they actually add or remove HTML elements, which would be required for adding the reconstruction message. — Eru·tuon 20:40, 24 September 2018 (UTC)[reply]

Huh, is that all skins do? I thought they housed custom Lua-coded pages too. --Victar (talk) 20:57, 24 September 2018 (UTC)[reply]

@Erutuon, any idea why I can't get this to work?

$(document).ready(function () {
  (new mw.Api()).get({
    action: 'expandtemplates',
    text: '{{reconstructed}}',
}).done(function (data) {
    var messageBox = data.expandtemplates['*'];
    messageBox.prependTo('.ns-118.action-view #mw-content-text');
  });
});;

--Victar (talk) 22:50, 24 September 2018 (UTC)[reply]

data.expandtemplates.wikitext is a string; it doesn't have the method prependTo. I tried calling $ (jQuery) on it to convert it to a jQuery object, which does have the method prependTo, but that doesn't work; I think jQuery rejects it because it's wikitext and can't be parsed as HTML. It needs to have its wikitext table syntax converted to the corresponding HTML tags. mw:API:Parsing wikitext might be nearer to what you're looking for. — Eru·tuon 23:12, 24 September 2018 (UTC)[reply]

To test JavaScript without the hassle of saving a page every time you make a change, you can use the user script sandbox, which requires adding mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Kephir/gadgets/jssand.js&action=raw&ctype=text/javascript'); to your common.js. — Eru·tuon 23:20, 24 September 2018 (UTC)[reply]

This seems to work:

($(document).ready(function () {
	(new mw.Api()).get({
		action: 'parse',
		text: '{{reconstructed}}',
		title: mw.config.values.wgPageName,
	}).done(function (data) {
		console.log(data);
		const result = data.parse.text['*'];
		if (result)
			$(result).prependTo('.ns-118.action-view #mw-content-text');
	});
}));

@Erutuon: HAH! Well done, sir. Well, I'd say that's a pretty fast alternative to PageNotice. --Victar (talk) 23:50, 24 September 2018 (UTC)[reply]

I'm experiencing several bugs in the code editor. Undo doesn't seem to be working, and I can no longer add new return lines above content. Anyone else experiencing this? --Victar (talk) 19:16, 24 September 2018 (UTC)[reply]

No on both counts here. Chrome v 69.0.3497.100. ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:51, 24 September 2018 (UTC)[reply]

@Eirikr, are you using the highlighted editor? --Victar (talk) 19:52, 24 September 2018 (UTC)[reply]

@Victar, ah, we're probably talking about different things -- you're probably talking about the Lua editor, yes? I misunderstood initially and thought you were having issues with the regular wikicode editor interface. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:33, 24 September 2018 (UTC)[reply]

@Eirikr, I'm talking about the standard editor with syntax highlighting turned on. Looks like syntax highlighter specific problem. --Victar (talk) 21:45, 24 September 2018 (UTC)[reply]

I'm using the wikitext highlighting here (Firefox Quantum 63) and am able to undo and redo and add newlines at the top of the textbox. As the wikitext highlighter uses JavaScript, maybe there'll be a message in your browser console. — Eru·tuon 22:09, 24 September 2018 (UTC)[reply]

Hmm, OK, must be some extension conflict. Thanks. --Victar (talk) 02:48, 25 September 2018 (UTC)[reply]

What is the "no head temp" tag that is now appearing in the edit summary of every single edit? Is it necessary? — SGconlaw (talk) 04:46, 26 September 2018 (UTC)[reply]

[6] DTLHS (talk) 04:51, 26 September 2018 (UTC)[reply]

Ah so. Thought it was a generalized problem. Thanks. — SGconlaw (talk) 04:55, 26 September 2018 (UTC)[reply]

In the notice that displays when you edit modules (MediaWiki:Editnotice-828), the link to the Scribunto source code is dead. The current location of the Scribunto source code is here (or on GitHub), and the libraries written in Lua (probably more interesting to Lua coders) are in a subdirectory (on GitHub). Not sure if I ever clicked that link till today though. — Eru·tuon 05:28, 26 September 2018 (UTC)[reply]

Updated. DTLHS (talk) 18:14, 26 September 2018 (UTC)[reply]

When trying to render a toponym from Amenhotep III's so-called "Aegean List"

WikiHiero shrinks all the hieroglyphs, especially those in the lower rows which should be much wider. I want pics in the first row to be twice larger and the next ones at least three times larger (the fourth pic aka second row actually rather ~5x) and I can't actually imagine a situation when height of 1 to 3 pixels can make any sense. Do you think you could fix it? Ain92 (talk) 17:41, 26 September 2018 (UTC)[reply]

@Ain92 Hello! Unfortunately, WikiHiero isn’t made for displaying blocks of hieroglyphs written in columns and ends up with poor rendering when it tries. The standard practice to get around this is to rearrange the blocks of glyphs into horizontal rows, following the principles of glyph arrangement that the Egyptians themselves used. This isn’t ideal, but it’s also not a very significant problem, since such rearrangement has been common practice in Egyptological academic publications for a long time anyway. I’d render the toponym you give as . — Vorziblix (talk · contribs) 07:28, 28 September 2018 (UTC)[reply]

• Thank you, I have put this rendering in Ἰωνία. Ain92 (talk) 09:52, 28 September 2018 (UTC)[reply]

I cleared the cache and tried different browsers, but I still can't play audio files in Chinese entries; there's no arrow to click. Ultimateria (talk) 18:00, 27 September 2018 (UTC)[reply]

Can you provide an example? — SGconlaw (talk) 19:05, 27 September 2018 (UTC)[reply]

中國, 上來. néng for example works, probably because the audio file is not in {{zh-pron}}. Ultimateria (talk) 19:26, 27 September 2018 (UTC)[reply]

Is there an example of an entry in Chinese characters (rather than Pinyin) that does work? — SGconlaw (talk) 19:51, 27 September 2018 (UTC)[reply]

What I'm trying to ascertain is whether {{zh-pron}} is designed to allow for the display of audio files but is not working properly, or whether the template actually doesn't provide for the display of audio files at all (and it's necessary to use {{audio}}). — SGconlaw (talk) 10:12, 28 September 2018 (UTC)[reply]

• @Suzukaze-c, Wyang, Justinrleung —Μετάknowledge^{discuss/deeds} 19:54, 27 September 2018 (UTC)[reply]
  • @Suzukaze-c, Wyang, Justinrleung: Pinging the same people because Chinese audio still isn't working. Ultimateria (talk) 05:15, 7 December 2018 (UTC)[reply]

I've been having a problem recently that hard purging a page no longer updates its categories and transclusions. Only a full "null edit" will. Is anyone else having this problem? To test, edit a template to add a category, then do a hard purge on one of the pages already transcluding it, and see if it shows up in the category page. —Rua (mew) 11:30, 28 September 2018 (UTC)[reply]

This has been true for a while, apparently for years, judging from this. Chuck Entz (talk) 19:21, 28 September 2018 (UTC)[reply]

But it has worked for me until recently. I could hard purge with a bot too. —Rua (mew) 10:33, 29 September 2018 (UTC)[reply]

I don't think this one's been reported yet: suppose you create a new noun with two plurals, like {{en-noun|qarleks|qarlekim}}. The first one (qarleks) shows up as green; the second one should also be green but is red. So you think "maybe a temporary glitch" and you go and create qarleks, come back and refresh, but qarlekim remains red, never accelerated. This definitely differs from the old behaviour, where all missing plurals could be accelerated immediately. Equinox ◑ 18:55, 29 September 2018 (UTC)[reply]

Fixed. There was "form-of-nostore" class in the HTML around qarlekim that prevented the script from accelerating it, as well as a bunch of other useless acceleration-related classes that were not around the first link. For the technical-minded, the linking function in Module:links uses the same table of acceleration information for both links (qarleks and qarlekim), and it was modifying the table while generating the first accelerated link, which messed up the acceleration generation for the second link. — Eru·tuon 22:13, 29 September 2018 (UTC)[reply]

"!" ? Chuck Entz (talk) 22:55, 29 September 2018 (UTC)[reply]

Thanks! Erutuon is bae. Equinox ◑ 23:20, 29 September 2018 (UTC)[reply]

Regarding "!", bugs are sometimes fun little puzzles to figure out. 😊 — Eru·tuon 23:35, 1 October 2018 (UTC)[reply]

I noticed there already exist {{R:KJV}} and {{RQ:KJV}} / {{RQ:AV}} for quoting the King James Version / Authorized Version of the Bible. Given the New International Version's recent ubiquity and more current language, should there be a {{R:NIV}} and a {{RQ:NIV}} as well? BlueCaper (talk) 21:36, 30 September 2018 (UTC)[reply]

The KJV is is the only really ubiquitous version, and its impact on the English language is unique. Quotations from the KJV illuminate the origin of innumerable words and expressions familiar to English speakers all over the world, and are often the only usage of archaic and obsolete terms known to a significant number of modern speakers.

The NIV, on the other hand, has basically zero impact on anything of lexicographic interest. It's one of literally dozens of modern translations floating around (look at the quite incomplete list template at the bottom of the Wikipedia article you just linked to). There are also specialized versions in various varieties of modern English, such as Clarence Jordan's Cotton Patch Gospel in US Southern English and Da Jesus Book in Hawaiian Pidgin. And that's not even getting into the various translations for specific denominations.

Our interest is in displaying usage, not in furthering understanding of Bible passages, so I would say "no" to your question. Chuck Entz (talk) 00:40, 1 October 2018 (UTC)[reply]

That having been said, it might be useful to have a {{R:NIV}} template in case it’s necessary to refer to Bible verses in etymologies and other parts of entries, rather than in quotations. Is there a stable, free online version of the NIV anywhere? — SGconlaw (talk) 01:58, 1 October 2018 (UTC)[reply]

Is it safe to assume that the citations from the Bible that do not use any template and do not have any date are nevertheless from KJV or AV, rather than a more recent version? (I think Tyndale's is usually so noted.) If not, how can we efficiently templatize these citations without making errors. One major benefit would be to actually have a date for the citation, which may give warning about possible unlabeled obsolescence or archaicism of the usage in the citation. DCDuring (talk) 19:32, 3 October 2018 (UTC)[reply]

There are at least 559 instances of undated "Bible" citations in English lemmas. DCDuring (talk) 19:37, 3 October 2018 (UTC)[reply]

What search terms did you use? Having a list written down would be a good start. DTLHS (talk) 19:48, 3 October 2018 (UTC)[reply]

Guess you'd need to compare the quotations with the actual Bible text to see if the KJV is indeed being cited. By the way, we currently have three English Bible quotation templates, for the Geneva Bible, King James Version and Tyndale Bible (New Testament): see "Category:Bible quotation templates". — SGconlaw (talk) 10:52, 4 October 2018 (UTC)[reply]