Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:GP)
Jump to navigation Jump to search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018


Contents

August 2018

Problems about fonts of Chinese characters[edit]

In English Wiktionary, the Chinese characters are displayed in a strange way, as shown in the screenshots. All other wiktionary projects do not have this problem.--Leiem (talk) 02:02, 1 August 2018 (UTC)

MediaWiki_talk:Common.css#Heiti_SC_and_Heiti_TC? —Suzukaze-c 02:12, 1 August 2018 (UTC)

Coverage tool wanted[edit]

I would like a tool (on the toolserver, I assume) that allows me to specify a language and enter a text, where the tool then splits the text into words, counts the frequency (number of occurrences), and looks up each word in Wiktionary to see whether it has an entry in the given language and possibly whether that entry is a form entry. For example, I specify English and the text "tools on a toolserver". Output: a (1 occurrence, entry exists), on (1, exists), tools (1, form entry exists, plural of tool), toolserver (1, does not exist). If the output can be sorted by frequency, this would provide a means to identify which words (e.g. in a chapter by Mark Twain) are in most dire need of entries. Note that the entry should exist for that language; this is not the same as a page existing.

Is this the right place to ask for such a tool? Maybe such a tool already exists? (Maybe what I want is instead the Dicompte tool for French Wiktionary? It lists words that occur in books in Wikisource but are missing from Wiktionary, unfortunately only for French.)

To find out whether a word has an entry for a certain language, I assume categories such as the category:English lemmas must be used? Is there any easy way for a tool to determine whether an entry is a form entry or a real one? --LA2 (talk) 14:26, 1 August 2018 (UTC)

I can do it as a Windows desktop thing if that's any good. Probably not ideal, but I hate Web programming. Equinox 20:06, 2 August 2018 (UTC)

it-IPA[edit]

Hi there. Would it be possible for someone to create a {{it-IPA}} template, along the lines of {{es-IPA}}? Italian pronunciation is very regular, and can be inferred directly from the spelling - we have the details in the pronunciation section of Wiktionary:About Italian. SemperBlotto (talk) 09:18, 2 August 2018 (UTC)

I'd like to work on this, it was already suggested by @GianWiki a while ago. With Italian's optional accents the pronunciation can't always be inferred directly from the spelling though. - Jberkel 11:38, 2 August 2018 (UTC)
You could make a template with a first parameter requiring the full word be entered, complete with accent. That would help determine the stress. For example, the pronunciation for the word cane would require you to type: {{it-IPA|càne}}, which would result in: IPA(key): /ˈka.ne/, [ˈkäːn̺e̞]. — GianWiki (talk) 12:29, 2 August 2018 (UTC)
It could work like this:
  • ⟨a⟩ is always /a/, [ä]
  • ⟨b, f, m, p, v⟩ remain the same
  • ⟨c⟩ is /k/ before /a, o, ɔ, u/, and /t͡ʃ/ before /e, ɛ, i/
    • ⟨ch⟩ is /k/ (but phonetically realized as a prevelar [k̟]) before /e, ɛ, i, j/
    • ⟨ci⟩ is /t͡ʃ/ when the ⟨i⟩ is unstressed and /a, e, ɛ, o, ɔ, u/ follows
  • ⟨d⟩ is always /d/, [d̪]
  • ⟨e, é⟩ is always /e/ (but phonetically lowered [e̞] when the previous syllable contains /a/)
    • ⟨è⟩ is always /ɛ/
  • ⟨g⟩ is /ɡ/ before /a, o, ɔ, u/, and /d͡ʒ/ before /e, ɛ, i/
    • ⟨gh⟩ is /ɡ/ (but phonetically realized as a prevelar [ɡ̟]) before /e, ɛ, i, j/
    • ⟨gi⟩ is /d͡ʒ/ when the ⟨i⟩ is unstressed and /a, e, ɛ, o, ɔ, u/ follows
  • ⟨gl⟩ is usually /ʎ/ (simple when word-initial, and geminated /ʎʎ/ elsewhere) before /e, ɛ, i/, but there are words, like glicine (pron. /ˈɡlit͡ʃine/) where this does not happen
  • ⟨gn⟩ is always /ɲ/ when word-initial, and geminated /ɲɲ/ elsewhere
  • ⟨h⟩ is always null
  • ⟨i⟩ is usually /i/. I'm not sure how to properly distinguish it from its semivowel counterpart /j/, though.
  • ⟨l⟩ is usually /l/, [l̺]. Phonetically, it's dentalized [l̪] before /d, s, t, t͡s, d͡z/, and palatalized [l̺ʲ] before /t͡ʃ, d͡ʒ/
  • ⟨n⟩ is usually /n/, [n̺]. Phonetically, it's dentalized [n̪] before /d, s, t, t͡s, d͡z/, velar [ŋ] before /k, ɡ/, labiodental [ɱ] before /f, v/, and palatalized [n̺ʲ] before /t͡ʃ, d͡ʒ/
  • ⟨o, ó⟩ is always /o/ (but phonetically lowered [o̞] when the previous syllable contains /a/)
    • ⟨ò⟩ is always /ɔ/
  • ⟨qu⟩ is always /kw/
  • ⟨r⟩ is always /r/, [r̺]
  • ⟨s⟩ is /z/, [z̪] when intervocalic (although with some exceptions), /s/, [z̪] before voiced consonants, and /s/, [s̪] elsewhere
  • ⟨sc⟩ is /ʃ/ (simple when word-initial, geminated /ʃʃ/ elsewehere) before /e, ɛ, i/; it's /sk/, [s̪k] elsewhere
    • ⟨sci⟩ is /ʃ/ (simple when word-initial, geminated /ʃʃ/ elsewehere) when the ⟨i⟩ is unstressed and /a, e, ɛ, o, ɔ, u/ follows
  • ⟨t⟩ is always /t/, [t̪]
  • ⟨u⟩ is usually /u/. Again, I'm not sure how to distinguish it from its semivowel counterpart /w/
  • ⟨x⟩ is always /ks/, [ks̪]
  • I don't believe there's any surefire way to determine if ⟨z⟩ will be realized as /t͡s/, [t̪͡s̪] or /d͡z/, [d̪͡z̪]. This is also true for geminated ⟨zz⟩.
Sorry for the wall of text, but I thought I would throw a few suggestions out there. Any thoughts? — GianWiki (talk) 14:10, 2 August 2018 (UTC)
Started a module at Module:it-pronunciation. It handles a few features of the phonemic transcription so far. It would be great if you or other people who are familiar with Italian added more testcases. — Eru·tuon 20:30, 5 August 2018 (UTC)

@GianWiki, SemperBlotto: I've created {{it-IPA}}. It only generates a phonemic transcription right now. — Eru·tuon 05:54, 1 September 2018 (UTC)

@Erutuon, GianWiki, SemperBlotto: Thanks for the efforts. Italian has long vowels, mostly predictable, if not, phonetic respellings could use macrons. --Anatoli T. (обсудить/вклад) 06:49, 3 September 2018 (UTC)

Apparent bug with "thanks" link to entry revision[edit]

Donnanz sent me a "thanks" notification for fashion show. When I clicked it to see which edit was being "thanked", I was taken here [1], which gives an error message: "One revision of this difference (5274261) was not found. This is usually caused by following an outdated diff link to a page that has been deleted. Details can be found in the deletion log." However, the page does not seem to have been deleted at any point. Is this a bug? Equinox 20:05, 2 August 2018 (UTC)

If you were thanked for creating the page, perhaps one revision of that diff does not exist, namely the nonexistant revision from before your edit creating the first revision... although that didn't used to cause a problem (I've viewed thanks for creating pages before). I just thanked you for creating gift economy, where yours is the only revision; can you see that diff? - -sche (discuss) 21:04, 2 August 2018 (UTC)
Your "thank" gives me the same error ("One revision of this difference (50062656) was not found"). Equinox 21:06, 2 August 2018 (UTC)
I would hazard a guess the software has changed, then. Seems like a regression, although unimportant. - -sche (discuss) 21:11, 2 August 2018 (UTC)
  • I think we should all just stop thanking each other and get back to work. --New WT User Girl (talk) 21:21, 2 August 2018 (UTC)
@Equinox: Ignoring the comment above, as the only edit you have made to the page was when you created it, it was for that. A bit late in the day I know, maybe I shouldn't be so enthusiastic. DonnanZ (talk) 17:12, 21 August 2018 (UTC)
@Equinox: BTW, is it possible to "unthank" you for terrorstricken? DonnanZ (talk) 13:13, 24 August 2018 (UTC)
When I want your prescription I'll come to your surgery :) Equinox 19:10, 26 August 2018 (UTC)
Sometimes I thank someone, only to immediately revert their edit. It might be trolling, or acknowledging humour. --XY3999 (talk) 19:32, 26 August 2018 (UTC)

Monthly subpages[edit]

If we're not already, we should be thinking of a replacement for the no-longer-running bot by the no-longer-present user who previously created subpages like Wiktionary:Grease pit/2019/January with {{discussion month}}, and more importantly briefly moved each subpage over top of an existing subpage (which in turn had initially been moved over top of the central page) so new pages were "automatically" in the watchlists of everyone who watched the (main) Grease pit (Beer parlour, etc). The "Click here to start a new discussion" links will presumably keep linking to the right subpages (whether they are blue or red links) indefinitely, and we could probably make redlinked monthly subpages preload with {{discussion month}}, but a system which (like the current one) doesn't require people to start manually watchlisting each new month's subpage in order to notice in one's watchlist that discussions are happening would be preferable. - -sche (discuss) 01:23, 3 August 2018 (UTC)

(Wow I never knew how that "keep it on your watchlist" thing worked! I asked about it once but nobody knew what I was talking about.) Equinox 01:31, 3 August 2018 (UTC)
Here is the source code, have fun.
#!/usr/bin/env python3
#coding: utf-8

import blib, pywikibot

discussion_pages = ["Beer parlour", "Grease pit", "Tea room", "Etymology scriptorium", "Information desk"]
months = ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"]
year = 2018

for discussion_page in discussion_pages:
	current = pywikibot.Page(blib.site, "Wiktionary:" + discussion_page + "/" + str(year - 1) + "/December")
	current.move("Wiktionary:" + discussion_page + "/" + str(year) + "/January", "Creating new monthly discussion pages")
	current = pywikibot.Page(blib.site, "Wiktionary:" + discussion_page + "/" + str(year) + "/January")
	current.move("Wiktionary:" + discussion_page + "/" + str(year - 1) + "/December", "Creating new monthly discussion pages")

	for i in range(len(months) - 1):
		current = pywikibot.Page(blib.site, "Wiktionary:" + discussion_page + "/" + str(year) + "/" + months[i])
		current.move("Wiktionary:" + discussion_page + "/" + str(year) + "/" + months[i+1], "Creating new monthly discussion pages")

	for i in range(len(months)):
		current = pywikibot.Page(blib.site, "Wiktionary:" + discussion_page + "/" + str(year) + "/" + months[i])
		current.text = "{{discussion month}}"
		current.save(comment = "Creating new monthly discussion pages")

Rua (mew) 16:50, 21 August 2018 (UTC)

Behaviour of "Template:audio"[edit]

I renamed a pronunciation sound file to "File:En-us-insouciant.flac" to correct a spelling mistake. However, at insouciant the {{audio}} template no longer displays properly. What is causing the problem? — SGconlaw (talk) 13:52, 4 August 2018 (UTC)

I figured out that I need to reset the transcodes at the Wikimedia Commons. — SGconlaw (talk) 17:21, 5 August 2018 (UTC)

thiz.elements.lang.update is not a function[edit]

When I tried to add a Pazend Middle Persian translation in diff, I got "ERROR:TypeError: thiz.elements.lang.update is not a function" and, even though the preview and automated edit showed the translation working just fine, it did not add. Perhaps in this specific case the Pazend alt form should just be consigned to the lemma page anyway, but the issue still seemed worth reporting. - -sche (discuss) 19:23, 4 August 2018 (UTC)

Arabic Script "see also" suggestions problem[edit]

On many pages using the Perso-Arabic script, there are "see also" suggestions for related words. While this is often helpful (especially because of various graphical differences between languages), it is often overused or rather superfluously suggesting something that is completely unrelated. E.g.: بردن; I was looking up the Persian word بردن (brdn) and noticed that there are "see also" suggestions for the unrelated words تردن (trdn) and تزدن (tzdn) with the format:

See also: تزدن and تردن

This is reciprocated for تردن and تزدن. These suggestions are helpful for words like دليل (Arabic dalīl) and دلیل (Persian dalil) which look the same and are hand-written the same way, but the first one using the unicode letter 064A ARABIC LETTER YEH (ي) for the 3rd letter, and the second one using the letter 06CC ARABIC LETTER FARSI YEH (ی) for the 3rd letter. This is the same as تازه (Persian tâze) and تازە (Kurdish taze), the first using 0647 ARABIC LETTER HEH for the final letter and the second using 06D5 ARABIC LETTER AE for the final letter.
This is also helpful for related words like بهلوان (Arabic bahlawān) and پهلوان (Persian pahlavân), where Arabic doesn't have a "p" and so use a "b" when adopting the word from Persian.
It is helpful for closely related dialectal and etymological variations like ذئب (Arabic ḏiʾb), ديب (Egyptian Arabic dīb), and ذيب‎ (Malay zib), all of which have the same meaning and are closely related. Another example of this that incorporates the first example is موسيقى (Arabic mūsīqā), موسيقي (Arabic mūsīqī), and موسیقی (Persian musiqi).
To people studying Middle Eastern languages (depending on experience and exposure) will readily recognize the relations between these words and the suggestions are pleasant and helpful. However, to the untrained eye, بردن and تردن and تزدن look as much like each other as دئب and ديب and ذیب, even though the first set are unrelated and should not be suggested to each other. This can be especially problematic with a set such as زن (Persian zan), ژن (Kurdish jin), and رن (Arabic rin), where زن and ژن are related etymologically, but رن is completely unrelated.

To make sure this is in perspective to users who don't deal with Arabic script, this is like the entry for dad, which has these suggestions (edited to

See also: Dad, DAD, dåd, -dad, ḍaḍ, and dáð

wherein "Dad", "dåd", "bað", etc. may be very helpful to a user because each one is a variant of the initial word "dad"; but if the suggestions included unrelated variants based on superficial letter appearances, the "see also" would likewise include: "bad", "pad", "dab", "daq", etc.
Is there a way to keep helpful suggestions and select out the misleading suggestions? Or would such a task have to be done to each entry, one by one? Would it be more feasible to only allow related groupings of letters (for the letters that differ between entries)? e.g.: ا,أ,إ,آ and ي,ئ,ې,ى,ی,ێ and ب/پ and ه,ة‎,ہ,ۀ,ھ‎ and ط/ت but not ت/ب and پ/ت and ث/ب and ر/ژ.

Binya2021 (talk) 10:10, 5 August 2018 (UTC)

It is not supposed to refer to related words. {{also}} entries are generally completely bot-added, in case you haven’t noticed. Also regard if you are of the same opinion when you consider rasm. Fay Freak (talk) 21:44, 7 August 2018 (UTC)
They are bot added, but somebody needs to write another bot that can add and maintain them since the previous adder doesn't seem to contribute to the project any more. The actual bot is trivial, but what's hard is writing down all the rules. DTLHS (talk) 21:46, 7 August 2018 (UTC)

C[edit]

Add these related terms to C:

-Lamanapa (talk) 23:25, 10 August 2018 (UTC)

Updating conjugation templates[edit]

Requesting help with updating {{az-latin-verb-conj}}. Thanks in advance.

  • renaming ”indicative future simple” into ”indicative future certain”
  • adding ”indicative future uncertain”
    • formed the same way as ”indicative future simple”, but with "a" for all back vowels and "ə" for all front vowels.

Example:

Formation of future uncertain
1SG indicative present simple 1SG indicative future uncertain
oluram olaram
qorxuduram qorxudaram
oxuyuram oxuyaram
deyirəm deyərəm
böyüdürəm böyüdərəm
üşüyürəm üşüyərəm
görürəm görərəm
alıram alaram
sarsıdıram sarsıdaram
anlayıram anlayaram
verirəm verərəm
edirəm edərəm
çatıram çataram

Allahverdi Verdizade (talk) 10:55, 11 August 2018 (UTC)

Per discussion we had on the Discord, I have implemented these changes now. SURJECTION ·talk·contr·log· 16:47, 11 August 2018 (UTC)

Add audio pronunciation[edit]

When I click on the "Add audio pronunciation" link, I get the error message "Error: NotFoundError: The object can not be found here". — SGconlaw (talk) 13:30, 12 August 2018 (UTC)

Anyone can help? — SGconlaw (talk) 12:21, 16 August 2018 (UTC)

I figured out what the problem was. The error message appears when a microphone is not present (my computer does not come with a built-in one). Perhaps the error message can be made clearer. Anyone know how to edit this tool? — SGconlaw (talk) 09:56, 28 August 2018 (UTC)

Expansion of the {{attention}} template[edit]

The {{attention}} template can be used to request help from a user with knowledge of a particular language. It would be good if we could also use it to get help in a specific knowledge area, For instance, I would like a mathematician to improve the definition of quasicyclic. Is this possible? SemperBlotto (talk) 14:45, 14 August 2018 (UTC)

  • Ah - I have found the "topic=" parameter. Let's see. SemperBlotto (talk) 14:52, 14 August 2018 (UTC)

{{xlit}} template[edit]

Can someone add an optional parameter to this template to write first letter in uppercase? For example check here, there is no way to write "Mukriyanî" (instead of "mukriyanî"). Thanks.--Calak (talk) 15:21, 15 August 2018 (UTC)

@Calak: You can use the "magic word" {{ucfirst:}} to do that. — Eru·tuon 04:00, 16 August 2018 (UTC)
Thanks. All templates (with transliteration) have same problem for languages which don't distinguish case, so I think we should find a fundamental solution.--Calak (talk) 11:54, 16 August 2018 (UTC)
@Calak: What do you mean by a fundamental solution? {{ucfirst:}} seems sufficient in this case, unless you want to do something else. — Eru·tuon 18:51, 16 August 2018 (UTC)
@Erutuon: I mean, using "magic words" in the main namespace (entry) is not a good idea. Yes it is great for other namespaces like templates.--Calak (talk) 18:25, 20 August 2018 (UTC)
@Calak: Oh, so you would like to capitalize transliterations in other places in entries? In some other languages without lettercase, like Arabic and Persian, editors regularly remove capitalization from the transliteration. I don't know if this is a general policy for all languages. — Eru·tuon 21:23, 20 August 2018 (UTC)
They do this because their languages don't have a formal Latin script. But Kurdish uses both Latin and Arabic scripts formally.--Calak (talk) 23:04, 20 August 2018 (UTC)
@Calak: Okay, that makes sense. Well, now I recall that there are at least two existing templates, {{ja-r}} and {{zh-x}}, that have a way of doing this. They use ^ to trigger capitalization. The complication is that ^ has to be removed from the displayed text or entry name. Using that method, {{xlit|ckb|^موکرْیانی}} would result in Mukriyanî. — Eru·tuon 03:32, 21 August 2018 (UTC)
@Erutuon, Calak: I oppose capitalisation of transliteration of scripts where there is no distinction between capital and lower case letters. Yes, Kurdish in Roman letters can be capitalised but the transliteration of Kurdish in Arabic should only be in lower case letters. "^" is currently reserved for languages where the capitalised transliteration is standardised, such as Japanese or Mandarin Chinese. --Anatoli T. (обсудить/вклад) 03:51, 21 August 2018 (UTC)
In case of Kurdish (as against Persian, Arabic or other scripts), we don't transliterate the word. Actually, we just convert it to Kurdish Latin alphabet. So the output shouldn't be different from Kurdish Latin alphabet.--Calak (talk) 07:02, 22 August 2018 (UTC)

Quotations automatically expanded[edit]

When I copied and pasted a definition that included quotations into the "Tea Room" page, in order to illustrate a layout problem, the quotations were automatically expanded, rather than appearing as a "quotations" dropdown list as on the original page. The lines in question were:

  1. (figuratively, depreciatory) A woman, particularly
    • 1785, Francis Grose, A Classical Dictionary of the Vulgar Tongue:
      Hen, a woman. A cock and hen club; a club composed of men and women.
    1. (Britain, informal) A bride-to-be, particularly in the context of her "hen night" festivities.

As you can see, it happens here too. Does anyone know whether this is by design (and if so, why), or whether there is a glitch somewhere? Mihia (talk) 18:05, 15 August 2018 (UTC)

The Javascript that hides quotations only functions in the main namespace. DTLHS (talk) 18:08, 15 August 2018 (UTC)
OK, thanks. (I wonder why ...) 19:56, 15 August 2018 (UTC)
Probably because the average user doesn't come to other namespaces. --XY3999 (talk) 19:33, 26 August 2018 (UTC)

Some new modules for Finnish and whether to integrate them[edit]

My sandbox right now has some new stuff: Special:Permalink/50144302; more precisely a template showing off a modified version of Module:fi-nominals with added support for term with multiple inflections, such as for multiword terms. There are also possessive form tables, and that module too heavily relies on fi-nominals, where it could possibly be merged into fi-nominals. Would it be worth it to implement either of these two and integrate one or both into fi-nominals? SURJECTION ·talk·contr·log· 18:19, 16 August 2018 (UTC)

(If anyone wants to look at and improve the code, feel free to) SURJECTION ·talk·contr·log· 18:19, 16 August 2018 (UTC)

emergency mode?[edit]

Some files seem to have gone into emergency mode, first noticed yesterday.

Category:etyl cleanup
Category:Norwegian Bokmål verbs
DonnanZ (talk) 10:45, 21 August 2018 (UTC)
What's emergency mode? — SGconlaw (talk) 10:48, 21 August 2018 (UTC)
I don't really know what to call it, but files are definitely not in their normal format at present. DonnanZ (talk) 11:08, 21 August 2018 (UTC)
Everything seems normal to me at those two categories. (When you say "files", do you mean Wiktionary entries?) — SGconlaw (talk) 18:06, 21 August 2018 (UTC)
I mean the whole display for the category. They should look more like this one, Category:etyl cleanup/sv. I'm not sure why this one hasn't been affected. DonnanZ (talk) 18:16, 21 August 2018 (UTC)
Another unaffected one: Category:Norwegian Bokmål uncountable nouns. Someone must have broken something somewhere which isn't affecting all categories. DonnanZ (talk) 19:38, 21 August 2018 (UTC)
  • Update: It seems to have been fixed by someone. DonnanZ (talk) 15:35, 22 August 2018 (UTC)

Chrome in edit mode[edit]

Does anyone else experience problems using Chrome in the edit mode? The edit page seems just blank (as if there is no memory) and it happens on different PC's with different versions of Windows. I've switched to MS Edge temporarily. --Anatoli T. (обсудить/вклад) 12:21, 21 August 2018 (UTC)

Good old IE works fine. I have tried Edge because one website wanted me to switch, but found that Favourites are better on IE, so I have gone back to it. DonnanZ (talk) 17:21, 21 August 2018 (UTC)
No problems with Mozilla Firefox so far. — SGconlaw (talk) 18:05, 21 August 2018 (UTC)
My Chrome is fine; tried on two computers on different networks and in different buildings. Equinox 18:57, 21 August 2018 (UTC)
I'm still having this problem. I can edit this small section but if I try a large L2 section, e.g. [2] - getting a blank screen. --Anatoli T. (обсудить/вклад) 20:17, 21 August 2018 (UTC)
Are there any errors in your browser console? DTLHS (talk) 21:58, 21 August 2018 (UTC)
No, only warnings (deprecated jquery). I will try to disable some plug-ins in a few hours. --Anatoli T. (обсудить/вклад) 22:33, 21 August 2018 (UTC)

Suggestion to search for results from single language[edit]

Instead of creating new pages with a single entry in one language as described on this post: <https://en.wiktionary.org/wiki/Wiktionary:Per-language_pages_proposal>, I have another suggestion (from a non-coder here).

I notice that when I go to the German entry for a word, the URL tacks on #German at the end. Would it be possible to have a function (possibly at the top of the page, or on the sidebar) where users can click the language they want to see results in, so when we enter a new search it will jump directly to that section? And the target language can be changed at will (for those of us who research more than one language at different times.)

It seems like a much simpler solution and seems to bypass the difficulties of the single-language entry proposal. And it would be such an added convenience for, I assume, most users who just want to browse definitions in a single language at a time. Thoughts? —This unsigned comment was added by Vaugue (talkcontribs) at 04:50, 26 August 2018 (UTC).

@Vaugue and everyone: Yes, that seems like a good idea! Please put the following code into your common.js page: importScript('User:V111P/PrefLangs.js'); You should now have a new input box below the search box. You have to type the name(s) of the language(s) into it. You can enter several languages separated by a comma, for example: German, French. If there is a section for the first language, the page will be scrolled to it, if not, to the second, etc. (It won't work when clicking a link from the "Search results" or another page, only on the first page that opens after searching from the search box at the top right.) --V111P (talk) 10:13, 6 September 2018 (UTC)

Bugfixes for WT:ACCEL[edit]

Please replace MediaWiki:Gadget-AcceleratedFormCreation.js with User:Rua/Gadget-AcceleratedFormCreation.js, which contains a few small fixes. —Rua (mew) 22:45, 28 August 2018 (UTC)

@TheDaveRoss, with this interface admin silliness, I don't even know who can edit these pages. Best solution is to get 'cratting. —Μετάknowledgediscuss/deeds 22:58, 28 August 2018 (UTC)
According to Special:ListUsers/interface-admin, there are currently no users on this wiki who can edit these pages. --Yair rand (talk) 23:04, 28 August 2018 (UTC)

Lua[edit]

Why is this a pitiful mess, when I copied it from a wiki user manual: User:Equinox/LuaTest. Given that I've programmed for years and I can count backwards in binary and I know how a CPU works, anyone want to teach me how to do some shit on here? I promise I won't mess with templates, I just feel like it would be nice to know how the wiki does it. Equinox 02:30, 30 August 2018 (UTC)

@Equinox: It has to be in the Module: namespace: [3]. —Suzukaze-c 02:31, 30 August 2018 (UTC)
Thank you. It still looks like broken shit. Can you set me up with a tiny "hello world" that will at least run and then I could mess with that. Equinox 02:35, 30 August 2018 (UTC)
It is still in the user namespace. DTLHS (talk) 02:36, 30 August 2018 (UTC)
Seriously pretend I just hatched out of an egg and hold my hand. Equinox 02:37, 30 August 2018 (UTC)
The title should be Module:User:Equinox/LuaTest. DTLHS (talk) 02:38, 30 August 2018 (UTC)
Created. {{#invoke:User:Equinox/LuaTest}} doesn't work. How do I "embed" my hello-world. I just wanna write void Name() { DO A THING } and call Name. But I'm very old and useless. Equinox 02:43, 30 August 2018 (UTC)
I'm even older and more useless. DonnanZ (talk) 10:49, 30 August 2018 (UTC)
You need to use the name of the function you want to call. {{#invoke:User:Equinox/LuaTest|hello}} DTLHS (talk) 02:45, 30 August 2018 (UTC)
There we go. Now I think I can "bootstrap". Thanks :D Equinox 02:46, 30 August 2018 (UTC)
Don't suppose anyone would subject themselves to teaching Equinox a little Lua, on IRC or elsewhere? I have many brief questions along the lines of: why am I "returning a package" from my Lua module, and what is the package, and what is doing the returning if we aren't inside a function? Tutorials are not hugely helpful because they tend to assume you are a complete newbie to everything and so you get a ton of "this is called a Boolean, and here's a thing called a loop" without getting the bigger picture. I would sort of like to be able to say "this doesn't look like how [C++, Java, C#, JS, Perl...] does it, what is the difference?" which is probably very quickly answered by anyone who knows both. (Full disclosure: there is nothing I actually want to do on Wiktionary with Lua. Just seems worth knowing a handful of it.) Equinox 21:46, 6 September 2018 (UTC)
Essentially, every module is a giant function. It can do anything a function can, it can have local variables, and can return anything or nothing. When you require a module, it just calls that function and returns it. The thing about returning tables is so that modules can return multiple functions and have them be called later. Also, the Lua-to-template interface requires that modules return tables containing functions. But we often return other things when modules don't need to be called from templates. Our language data modules return the data directly, without functions. —Rua (mew) 22:13, 6 September 2018 (UTC)
So would I be (vaguely) correct in saying that the "package p, return" stuff surrounding the meat of the module is sort of analogous to indicating the functions you want to export from a DLL on Windows? And if we didn't return the package at the end, then the caller wouldn't have visibility of the functions in the module? Equinox 22:19, 6 September 2018 (UTC)
Yes, pretty much, although I'm not familiar with "package" in the context of our modules. Anything you don't return from a function will disappear when the function ends, so the same applies to the module-level "function". —Rua (mew) 22:22, 6 September 2018 (UTC)
A lot of Lua example code uses print for output. Presumably we can't do this here because it would print into the vacuum of outer space (?). The correct behaviour is always to build a string and return it? Equinox 22:26, 6 September 2018 (UTC)
Yes. It can get kind of awkward because you can't print even for debug purposes. Supposedly there is a debug console but I have yet to make it work. Module:debug has some things that help though. Often, I use error to print debug things temporarily, and then preview a page with it. —Rua (mew) 22:30, 6 September 2018 (UTC)
You are very helpful <3 Can you explain the "frame" parameter super quickly? Do we ever need this in a function, does it give us access to the calling page, etc.? or is it just part of the infrastructure. Equinox 22:31, 6 September 2018 (UTC)
You need frame (though in theory you can call it anything you like) to access any arguments that are given in an invocation ({{#invoke:whatever|somefunction|param1|param2}}), or to a template that then invokes the module. It also contains other things like what the name of the current page is, it lets you transclude other templates (necessary because templates also have to have the current page name, and for tracking transclusions and such), etc. Simply said, it contains all the information about the context in which the module was called. On the other hand, you can always retrieve the frame with mw.getCurrentFrame, so the parameter is technically unnecessary. —Rua (mew) 22:38, 6 September 2018 (UTC)
Oh yeah I didn't even think about how we would unpack params from the caller. Excellent, thanks very much. Equinox 22:40, 6 September 2018 (UTC)
Many of our modules use Module:parameters to help in dealing with parameters. It will validate the parameters to some degree, make sure required ones are present and that there are none that the module doesn't recognise. It also does things like converting empty values to nil, and handling numbered parameters that should be grouped together in a sequence, like {{en-noun}}'s pl2=, pl3= etc. —Rua (mew) 22:44, 6 September 2018 (UTC)

Regarding the debug console, it provides the module as p, so if the module table contains a function called hello, you can call it in the console with p.hello(), and you can see what it returns by doing = p.hello(). (I wish it was like Lua 5.3 where you don't have to type the equals sign.) — Eru·tuon 22:45, 6 September 2018 (UTC)

Ahhh this wasn't so hard. Setting shit up is always much more of a pain than using it. (One lecturer said "once you know one language, any other language is merely a matter of syntax". Hawwhhj! Really: once you know one language, any other language is merely a matter of maybe OOP, maybe functional-ness/side-effects, maybe interop, and a lot of configuration fun. But bless his heart, professors don't live in the real world.) Now I just need to think of something worth doing with Lua. "Hi, what's your name? Hello, (null), welcome to my Wiktionary page!" Equinox 22:57, 6 September 2018 (UTC)

At least Lua saves you from that mistake. Instead of converting nil to a string, you get an error when you try to concatenate it. —Rua (mew) 22:58, 6 September 2018 (UTC)
lol, I am starting to understand why genuine code improvements got you yelled at. There's unfortunately a fair amount of Equinox SQL out there (some of it delivering our groceries) surrounded by panicky flower boxes saying "you THINK you can rewrite this better without the NULL, but it's going to cost you an afternoon of angry phone calls". Equinox 23:06, 6 September 2018 (UTC)
Suppose I wanted to grab the contents of some other page on the same wiki as a string (maybe the entry "duck"), for some reason, what is the appropriate API call? Equinox 23:41, 6 September 2018 (UTC)
mw.title.new("duck"):getContent(). — Eru·tuon 23:44, 6 September 2018 (UTC)
I'm sort of trying to work out what I get here. It must be a string. But when it is rendered we get all the pretty layout (section headers, images right-aligned!) but any templates are not evaluated. What is in my string? Presumably not HTML. But enough to include images and stuff. What if I wanted to render the template results? Equinox 23:53, 6 September 2018 (UTC)
It's just that in module output, some parts of wikitext syntax are parsed (headers, links, categories, media, italic and bold markup, HTML) and some aren't (templates, special tags like <ref>). So to parse the rest of the stuff you can do frame:preprocess(content_of_duck). (See above if you don't have access to the frame object.) — Eru·tuon 00:04, 7 September 2018 (UTC)
Thank you for putting the docs link in there! I think I am starting to understand what a "frame" is. Lua colon is confusing me. I read [4] and got scary Perl @ARGV flashbacks. I'll pick it up eventually. Equinox 00:34, 7 September 2018 (UTC)
(Although there's nothing scarier than PHP spitting a cavalier warning about "instance call made to static method" and then doing it anyway. COME ON at least pretend to give a crap about your objects.) Equinox 00:42, 7 September 2018 (UTC)
Well, Lua is more straightforward than JavaScript, which has all the rules for what this is. (JavaScript is pretty much my only reference point for object orientation.) Any time the function needs access to the object (usually table) that it's stored as a field in, the object has to actually be supplied as a parameter, either explicitly or through the syntactic sugar of colon syntax. So for instance the function frame.getParent requires frame, so you have to call it as frame.getParent(frame) or frame:getParent(). Otherwise, frame.getParent has no way to gain access to frame, unless it is a global variable, or a local variable that is accessible at the point where frame.getParent is defined. But mw.getCurrentFrame() doesn't use the table mw, so it is called without colons or any parameters. In this way Lua is sort of like the GObject style of object orientation: the object is always the first parameter. — Eru·tuon 01:29, 7 September 2018 (UTC)

Since I can't see it mentioned here: you can print using mw.log() when previewing pages using the module. The output appears in the parser profiling data below the edit box. --Njardarlogar (talk) 09:00, 7 September 2018 (UTC)

der templates[edit]

I think the way {{der4}} and other variants sort has been changed by somebody, and the result is not terribly user-friendly in my opinion. A good example is at low#Derived terms, where, for example, low side is sorted miles away from low-sided. DonnanZ (talk) 10:59, 30 August 2018 (UTC)

Module_talk:columns#Broken_sort_in_Latin_script DTLHS (talk) 16:02, 30 August 2018 (UTC)
Thanks for finding that. Can this be reverted? It doesn't make sense to me (and maybe others). The trouble is you can't please everybody. DonnanZ (talk) 16:30, 30 August 2018 (UTC)
Pinging @Urhixidur and @Erutuon. DTLHS (talk) 16:32, 30 August 2018 (UTC)
It certainly can be reverted, but I don't know how to decide between these two sorting systems. Maybe there is a third more complicated option somewhere in between. — Eru·tuon 20:07, 30 August 2018 (UTC)
I think we need strict alphabetical order, regardless of hyphens and compound words. I think that was achieved before, but certainly isn't happening now. You may as well use {{der4-u}} instead (but you shouldn't have to). DonnanZ (talk) 22:33, 30 August 2018 (UTC)

@Erutuon: There has been no reply from User:Urhixidur, and this is still annoying me so much, not only at low but everywhere else. I would revert it myself if I was allowed and knew how to. If nothing is done I will be forced to use {{der3-u}} and {{der4-u}} instead, despite the manual sorting. DonnanZ (talk) 10:49, 8 September 2018 (UTC)

I don't like it either, reverted. DTLHS (talk) 16:54, 8 September 2018 (UTC)
Thanks. It's best not to have the sorting method drive anyone to not use templates with automatic sorting. I still wonder if there's a middle ground. Probably I need to read more about sorting algorithms. — Eru·tuon 19:37, 8 September 2018 (UTC)
What an improvement! Thanks a lot! DonnanZ (talk) 19:40, 8 September 2018 (UTC)

Watchlist header mess[edit]

The "Planned, running and recent votes" box, which appears (at least) in the Watchlist header seems to insist of being centered (or nearly so) on that page in Chrome (at least). I would have thought it should be on the far right. The only thing that appears on the far right of the header is the control "Edit your list of watched pages". We do have two interface admins who presumably have the powers to edit the relevant pages. DCDuring (talk) 17:18, 30 August 2018 (UTC)

On IE it appears almost on the left, but I agree that the whole layout at the top of the page looks messy. DonnanZ (talk) 18:31, 30 August 2018 (UTC)
Exactly where it depends on how wide your window is, text size, etc, probably browser. For me the ugly appearance is about the same in Firefox and Chrome.
The various boxed and graphical items (requests, images, rhs ToC, pronunciation boxes, declension tables, etc), especially those appearing at the top of pages don't seem to play well together in general. There might have to be some kind of restrictions on the permitted CSS to preserve appearance for common browser configurations and gadget selections. DCDuring (talk) 19:23, 30 August 2018 (UTC)

Translation adder[edit]

Translation adder is stuffed. Can't use the "assisted" method. --Anatoli T. (обсудить/вклад) 02:30, 31 August 2018 (UTC)

@Atitarev: It's probably explained by a syntax error; see this edit. A comma needs to be added after the first instance of wiktprefix: "ku". (See the discussion about this edit on my talk page.) — Eru·tuon 04:50, 31 August 2018 (UTC)
Fixed now, I think. Sorry! - -sche (discuss) 04:59, 31 August 2018 (UTC)
@Erutuon, -sche: Thanks for addressing this quickly! --Anatoli T. (обсудить/вклад) 07:39, 31 August 2018 (UTC)

September 2018

Lines as partition in declension table is not shown in ipod touch (and maybe in iphone)[edit]

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)

  • Sounds like a hardware problem to me. SemperBlotto (talk) 05:29, 3 September 2018 (UTC)
    • 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)
      • 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)
        • 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)

Audio template not displaying properly on iPhones[edit]

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)

"Add audio pronunciation" still not working[edit]

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)

User:Conrad.Irwin/creationrules.js update[edit]

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

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

My first submission to the "Tea Room" was "identified as harmful"![edit]

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 (talkcontribs) at 23:19, 3 September 2018 (UTC).

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)

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)

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)

Two things with desctree[edit]

  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)
@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)
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)
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)
@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)
@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)
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)
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)
No, I noticed that, and tested {{desctree|en|wine}} on a sandbox page. — Eru·tuon 05:01, 5 September 2018 (UTC)
Thank you, Erutuon. Ultimateria (talk) 19:12, 6 September 2018 (UTC)

Arabic diacritics in MediaWiki:Edittools[edit]

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)

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

Sanitized CSS in Module namespace[edit]

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)

Admins are not able to change PHP variables. DTLHS (talk) 04:16, 6 September 2018 (UTC)
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)

Suggestion: More languages should generate the inflected forms from inflection.[edit]

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)

  • 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)

"Automotive" topic[edit]

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)

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)
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)
It's reading "automotive" now. DonnanZ (talk) 19:42, 8 September 2018 (UTC)

Module:accel[edit]

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)

I think that's a great idea. I will help. — Eru·tuon 22:22, 6 September 2018 (UTC)
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)

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)

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)
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)
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)

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

@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)

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)

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

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

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

WT:ACCEL for Ancient Greek?[edit]

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 (talkcontribs).

@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)
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)
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)
@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)
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)

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)

@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 (talkcontribs) at 23:38, 9 September 2018 (UTC).
@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)
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)
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)
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)

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)

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)

@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)

All topics, list of topics.[edit]

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)

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)
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)
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)

Module error in ablativo absoluta[edit]

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)

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)
The function getPos(word) thinks "ablativo absoluta" is an adjective. DTLHS (talk) 18:19, 8 September 2018 (UTC)
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)
Your fix causes a lot more errors. DTLHS (talk) 19:57, 8 September 2018 (UTC)
@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. —Μετάknowledgediscuss/deeds 22:43, 8 September 2018 (UTC)
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)
@Erutuon: If I remove |pos=noun from ablativo absoluta, it still gives me a Lua error. —Μετάknowledgediscuss/deeds 23:28, 8 September 2018 (UTC)
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)
See my comment before last in this thread. —Μετάknowledgediscuss/deeds 23:30, 8 September 2018 (UTC)
@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)
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)
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)
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)
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. —Μετάknowledgediscuss/deeds 20:30, 9 September 2018 (UTC)
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)

Error in ang-noun[edit]

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)

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)
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)
Ah sorry, that was a stupid oversight on my part. —Rua (mew) 19:33, 8 September 2018 (UTC)

Entry adder gadget[edit]

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)

Mobile display of Chinese characters - every infobox is expanded[edit]

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)

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)
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)
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)
"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)


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)

Blanking my talk page[edit]

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)

Do you have small tasks for new contributors? It's Google Code-in time again[edit]

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)

Strange JavaScript behaviour[edit]

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)

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)

Edittools in translation adder?[edit]

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)

Tracking translations[edit]

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)

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)
Can't you just search for {{t|xx}}? Alternatively download the database dump. DTLHS (talk) 16:07, 10 September 2018 (UTC)
Can a bot do searches? —Rua (mew) 17:41, 10 September 2018 (UTC)
There is a search API, [5]. DTLHS (talk) 17:49, 10 September 2018 (UTC)

Aliases in labels module[edit]

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)

Yes check.svg Done. You almost got it. — SGconlaw (talk) 07:54, 11 September 2018 (UTC)
OK, it's a little inflexible. It doesn't allow you have "color" reading "color". Thanks. DonnanZ (talk) 08:02, 11 September 2018 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
  • hue ? DCDuring (talk) 10:02, 11 September 2018 (UTC)
    • Not as clear as "color" or "colour", IMHO. — SGconlaw (talk) 12:38, 11 September 2018 (UTC)
  • 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)
    • Re language: wouldn't that be covered by "linguistics"? — SGconlaw (talk) 11:41, 12 September 2018 (UTC)
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)
Maybe a label should read "languages" so there is no confusion with linguistics. DonnanZ (talk) 12:04, 12 September 2018 (UTC)
Mmmm, what sort of entries would a "language" tag be placed on? — SGconlaw (talk) 12:15, 12 September 2018 (UTC)
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)
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)
Right. This has been discussed before. - -sche (discuss) 21:30, 12 September 2018 (UTC)
I can't win 'em all. I don't feel like arguing the toss. DonnanZ (talk) 10:46, 13 September 2018 (UTC)

I don't know why but the table of contents in mobile page is not shown in iPod touch.(Maybe also in iphone)[edit]

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

Using quotations multiple times[edit]

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 (talkcontribs) at 21:30, 11 September 2018 (UTC).

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)
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)
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)
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)
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)
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)
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)
@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)
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)
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)
Maybe at some stage this information would be stored on Wikidata. — SGconlaw (talk) 08:41, 12 September 2018 (UTC)
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)
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)
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)
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)
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)
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 "&shy;" 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)
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 &shy; will cause problems in the function right now, though. — Eru·tuon 20:36, 13 September 2018 (UTC)
@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&shy;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)
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)
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)
@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)

──────────────────────────────────────────────────────────────────────────────────────────────────── 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)

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 ᨴᩮᩅᨲᩣ. 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)
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)
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)
@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)

Force derived terms to single column on mobile[edit]

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)

Does it need to go in MediaWiki:Mobile.css? DTLHS (talk) 21:48, 11 September 2018 (UTC)
@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)
Added, please test. DTLHS (talk) 22:13, 11 September 2018 (UTC)
@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)
Perfect. --Victar (talk) 22:47, 11 September 2018 (UTC)
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)
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)

Swapping <nowiki> for <source lang="moin">[edit]

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)

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)
"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)
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 (talkcontribs) 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)
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)
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)
2018 September 14, “mw:Extension:SyntaxHighlight#Advanced”, in MediaWiki:
Unlike the <pre> and <code> tags, HTML character entities such as &nbsp; need not (and should not) have the & character escaped as &amp;.
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 &lt;, 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)
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)
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)
2013 September 9, “Unnecessary <nowiki>s in <source>”, in Help:Glosses[6]:
 <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)

Langcatboiler and language indices[edit]

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). —Μετάknowledgediscuss/deeds 23:44, 13 September 2018 (UTC)

WT:ACCEL bug: inserting language sections in wrong order[edit]

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

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)
I understand. It used to work fine so I think someone has broken it. Equinox 06:32, 14 September 2018 (UTC)
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)

Mobile site still links to deleted Index:English[edit]

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

Fixed by removing that line in MediaWiki:Noarticletext. —Μετάknowledgediscuss/deeds 16:18, 15 September 2018 (UTC)

Updating template:az-latin-verb-conj[edit]

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)

{{es-IPA}} doesn't show spaces?[edit]

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)

Provide a Wikibase instance where we can import Wikitionaries materials and that can be queried from Wiktionaries[edit]

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)

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? Face-smile.svg Noé 16:52, 20 September 2018 (UTC)

Feedback wanted on mobile web contribution prototype[edit]

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

"CollabPad"[edit]

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)

[9] DTLHS (talk) 21:00, 19 September 2018 (UTC)
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)

Alerts for replies to posts[edit]

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)

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)
How about the watchlist? —Suzukaze-c 02:32, 20 September 2018 (UTC)
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)
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)
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)

Accelerated plurals not working[edit]

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)

  • And the same happens for verb forms. SemperBlotto (talk) 05:45, 20 September 2018 (UTC)
(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)
I tried that but it's still broken. DTLHS (talk) 06:00, 20 September 2018 (UTC)
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)
Working version in User:Erutuon/scripts/accel.js. — Eru·tuon 06:53, 20 September 2018 (UTC)
OK. Could you copy that to the live version (wherever that is) please? SemperBlotto (talk) 08:16, 20 September 2018 (UTC)
Thanks, still doesn't work. DTLHS (talk) 16:11, 20 September 2018 (UTC)
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)
Never mind, it must have been cached. DTLHS (talk) 19:08, 20 September 2018 (UTC)

Discussion about a...System message?[edit]

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)

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)
The message in question is MediaWiki:Newarticletext. - TheDaveRoss 12:22, 21 September 2018 (UTC)
Yes check.svg Done Changed it to "Antarctica". Equinox 13:45, 21 September 2018 (UTC)

[[//]][edit]

entry https://en.wiktionary.org/wiki/// exist, but link doesn't work, neither as [[//]] ([[//]]) nor as [[10]] ({{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)
Thank you (for the reply and the clean-up)! -08:44, 22 September 2018 (UTC)