Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:BR)
Jump to: navigation, 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, 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".

It is said that while the classic beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... 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.
  • 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 +/-
2006
2007
2008
2009
2010
2011
2012
2013
2014


Contents

May 2014[edit]

Escape the equal sign[edit]

How could you escape the equal sign in Lua? %= doesn't seem to work. Wyang (talk) 02:47, 1 May 2014 (UTC)

You don't need to. --WikiTiki89 02:48, 1 May 2014 (UTC)
For example, the str_anal function at the bottom of this version fails to work for
{{#invoke:Pinyin-IPA|str_anal|Rìběn er=y tl=y}}
. I'd like to extract the three parts even though the text contains equal signs. Wyang (talk) 02:52, 1 May 2014 (UTC)
Ah, that's not a Lua thing, that's a template thing. Just use {{=}}. --WikiTiki89 02:53, 1 May 2014 (UTC)
I don't understand. How exactly? Wyang (talk) 02:55, 1 May 2014 (UTC)
Like this: {{#invoke:Pinyin-IPA|str_anal|Rìběn er{{=}}y tl{{=}}y}}
Or like this: {{#invoke:Pinyin-IPA|str_anal|2=Rìběn er=y tl=y}} --WikiTiki89 03:01, 1 May 2014 (UTC)
Why not make it like this? {{#invoke:Pinyin-IPA|str_anal|Rìběn|er=y|tl=y}}CodeCat 03:14, 1 May 2014 (UTC)
That technically does not answer the question, but it is a better solution. --WikiTiki89 03:17, 1 May 2014 (UTC)
Yes, it seems so. I was wondering why "Rìběn er=y tl=y" is one parameter, when it's three - 1. Pinyin, 2. erhua (yes) and 3. toneless (yes). --Anatoli (обсудить/вклад) 03:27, 1 May 2014 (UTC)
@Wikitiki89:, @CodeCat: Could you please have a look at the function 'str_anal' at Module:Pinyin-IPA. I'd like to let
{{#invoke:Pinyin-IPA|str_anal|Rìběn,er=y,tl=y|er}}

return 'y', and let

{{#invoke:Pinyin-IPA|str_anal|Rìběn,er=y,tl=y}}

return 'Rìběn'. Wikitiki89's method of using Module error seems to work, although I'm not sure how to get from 'Rìběn,er=y,tl=y' to 'Rìběn,er{{=}}y,tl{{=}}y'. The method of using '2' doesn't seem to work. Wyang (talk) 03:42, 1 May 2014 (UTC)

What do mean by "get"? --WikiTiki89 03:47, 1 May 2014 (UTC)
I see how to do it now. Thank you both! Wyang (talk) 03:52, 1 May 2014 (UTC)
I don't really understand why you're writing your own custom parameter parser instead of using the one that's built into the wiki software. —CodeCat 11:09, 2 May 2014 (UTC)
@Wyang, CodeCat, Wikitiki89: The function name is not counted as a parameter, so it's the 1st parameter instead of the 2nd. --kc_kennylau (talk) 07:50, 3 May 2014 (UTC)
Why did you ping me for that? —CodeCat 12:09, 3 May 2014 (UTC)
Maybe because I was drunk. --kc_kennylau (talk) 12:16, 3 May 2014 (UTC)
Ok good to know. --WikiTiki89 15:24, 3 May 2014 (UTC)

Adding categories for templates[edit]

I need to add entries using {{zh-noun}} to Category:Chinese nouns using

<includeonly>{{#if:{{NAMESPACE}}||<!--
  -->[[Category:Chinese nouns]]<!--
-->}}</includeonly>

Why didn't it work? E.g. why a test entry 略语 has no categories at the moment? (For testing, I deliberately didn't add Wyang's pronunciation templates, which add to Mandarin, Cantonese, etc. PoS categories, depending what's present). --Anatoli (обсудить/вклад) 06:03, 1 May 2014 (UTC)

You put it after the opening "noinclude" tag, so it's not included. In any case, it's probably preferable to write this: {{catlangname|zh|nouns}}. That way you get automatic sorting (as far as it's available for Chinese anyway). —CodeCat 12:10, 1 May 2014 (UTC)
Sorry, missed the answer. Thank you! Yes, I would like to add sorting, which is numbered pinyin ("pint=" in Mandarin templates). I think we should bring that across from Mandarin templates, even if Pinyin is a standard Chinese feature, not of other varieties. Otherwise we would have to sort by "radical sort value" (rs=田06 in this case, i.e. 田 + 6 strokes), which is too complicated for learners and many native speakers, or leave it unsorted - also messy.
@CodeCat: If for 略语 ({{zh-noun|lüe4yu3}}) the sorting would be "lüe2yu3" (sorted under letter "L") (numeric form of toned Pinyin "lüèyǔ"), how exactly {{catlangname|zh|nouns}} should be rewritten?
@Wyang:, please consider adding "pint=" parameter (or unnamed first parameter) to all Chinese PoS templates and accelerated templates. We need to sort out "sorting" early on, even though your pronunciation templates do the sorting correctly, it's better to do this (also) using headword templates. I know it complicates things. --Anatoli (обсудить/вклад) 02:23, 2 May 2014 (UTC)
{{catlangname|zh|nouns|sort=lüe4yu3}}. —CodeCat 10:11, 2 May 2014 (UTC)
I need to rewrite the template, so that it sorts nouns by the 2nd parameter. I haven't seen {{catlangname|zh|nouns}} used in such a way:
{{zh-pos|noun}}<noinclude>{{documentation}}</noinclude><!--

--><includeonly>{{#if:{{NAMESPACE}}||<!--
  -->[[Category:Chinese nouns]]<!--
-->}}</includeonly>
What about {{head|zh|noun|sort={{{2}}} { {PAGENAME } }}}? --Anatoli (обсудить/вклад) 10:27, 2 May 2014 (UTC)
That works too. It's probably better actually. But why would you need to add the page name to the sorting? —CodeCat 11:07, 2 May 2014 (UTC)
Perhaps just { { { 2 } } } is enough. Thank you. --Anatoli (обсудить/вклад) 11:19, 2 May 2014 (UTC)
Sorry Anatoli, I have removed all the unsorted categorisations in the headword templates. It nullifies the sorting by {{zh-pron}}. Wyang (talk) 03:40, 3 May 2014 (UTC)
@Wyang:. Yes, I saw. That's alright for the moment. I think the headwords are still meant to provide a default sorting, which you do using {{zh-pron}}. If we add a numeric pinyin to each entry as a second parameter (it shouldn't be hard, I reckon, using a bot) and change PoS templates to {{head|zh|noun|sort={{{2}}}}} to sort by it, then it should work too, even if there is no Mandarin pronunciation provided (only Cantonese, only Min Nan, etc.) or {{zh-pron}} is not used/missing in an entry. --Anatoli (обсудить/вклад) 06:33, 5 May 2014 (UTC)
There is a trick we could use to find unsorted entries more easily. It's possible to change Module:languages/data2 so that all Chinese characters are replaced by * in the default sorting. That way, they'll all be sorted at the beginning unless the sorting is explicitly overridden (which is what we want). —CodeCat 12:23, 5 May 2014 (UTC)

Error in {{Pinyin-IPA}}[edit]

These templates are getting so complicated that I have no idea who to turn to about this problem, so I'm posting it here - the IPA in this template is producing a module error on 人家. —Mr. Granger (talkcontribs) 01:43, 2 May 2014 (UTC)

Fixed. Wyang (talk) 02:00, 2 May 2014 (UTC)
谢谢 —Mr. Granger (talkcontribs) 02:03, 2 May 2014 (UTC)

cjy - Jin or Jinyu?[edit]

Code "cjy" stands for Jin Chinese, a Chinese topolect. The language (as per Module:languages/data3/c) name should be "Jin", even if the Chinese name is 晉語晋语 (jìnyǔ).

Category:Jinyu language

Category:Jin proper nouns (error: This category was designed to be called Category:Jinyu proper nouns.) --Anatoli (обсудить/вклад) 05:11, 2 May 2014 (UTC)

@Wyang: If it's decided that it should be called Jinyu, then you'd need to update your modules. --Anatoli (обсудить/вклад) 05:12, 2 May 2014 (UTC)
'Jinyu' does not make sense; it is like 'English language' for the code 'en'. Wyang (talk) 05:19, 2 May 2014 (UTC)
I agree. I will update Module:languages/data3/c to use Jin and Category:Jinyu language entries and categories have to be moved. --Anatoli (обсудить/вклад) 05:22, 2 May 2014 (UTC)
You really are supposed to run it by RFM to see if there's any conflict or other reason not to do it. I suspect the reason we have Jinyu is because Ethnologue calls it "Jinyu Chinese" and no one ever checked whether that was correct- but it would be better to be sure. Of course, we have very little existing infrastructure for the language on WT, so we may get away without totally trashing things on this one. Chuck Entz (talk) 05:51, 2 May 2014 (UTC)
Of course, I checked the impact and, as I said, moved categories and created new ones. Some redlinked categories appeared when Wyang edited entries, which have Jin info and added to to those categories. E.g. 中国, a Chinese word for China contains transliterations/recordings in various Chinese topolects. Jin is among them, so the entry got added to Category:Jin proper nouns. --Anatoli (обсудить/вклад) 06:04, 2 May 2014 (UTC)

Bot request: Lojban gismu (Lojban knowledge not required)[edit]

I am too lazy to do this on every single page, so I request a bot to do so. The languages in order are: Chinese(zh), English(en), Hindi(hi), Spanish(es), Russian(ru), Arabic(ar). Thanks in advance. --kc_kennylau (talk) 13:08, 2 May 2014 (UTC)

Navboxes[edit]

I want to have naxboxes show, but to have quotations not show. Unfortunately, I cannot have that - it's either both or neither. If I switch off the Browser preferences, navboxes just show up as two square brackets, without any collapsability. How can I fix this? Velociraptor888 (talk) 19:22, 3 May 2014 (UTC)

Have you tried showing the navboxes using the control panel on the left? It should remember your preference and open similar boxes automatically in the future. -Atelaes λάλει ἐμοί 19:55, 3 May 2014 (UTC)
Yes, I have done that, but currently, when they are turned on, I hide the quotations, but only for one non-refreshed visit to a page. It didn't use to do that. Velociraptor888 (talk) 20:05, 3 May 2014 (UTC)
I deleted my cookies. That seems to have done the trick. Velociraptor888 (talk) 20:23, 3 May 2014 (UTC)

Index:English is 3 years out of date[edit]

See Index_talk:English/h. I quite enjoy browsing the index now and then, but three years is really a big backlog. Does anyone know where I can find the scripts to update it? User:Conrad.Irwin used to do this, but he grew up and got a Real Job and is unlikely to respond to messages. Equinox 14:27, 5 May 2014 (UTC)

Index:Esperanto is also in need of an update. I would offer to help but I'm not an expert user of wikis. Rikat (talk) 14:50, 10 May 2014 (UTC)
I actually downloaded one of the XML dumps and might look into this, but I have exams and just got a part-time job, so don't hold your breath. Equinox 19:52, 22 May 2014 (UTC)

Bot no longer works[edit]

I'm now getting this:-

  • File "C:\Python-it\wikipedia.py", line 1573, in put
    • watchArticle = watchlist.isWatched(self.title(), site = self.site())
  • File "C:\Python-it\watchlist.py", line 58, in isWatched
    • watchlist = get(site)
  • File "C:\Python-it\watchlist.py", line 46, in get
    • refresh(site)
  • File "C:\Python-it\watchlist.py", line 92, in refresh
    • params['wlstart'] = data['query-continue']['watchlist']['wlstart']
  • KeyError: 'wlstart'

It happens after the "Copy of watchlist is one month old, reloading Retrieving watchlist for wiktionary:en" message (which I have never understood the need for)

Any ideas? SemperBlotto (talk) 10:10, 6 May 2014 (UTC)

What code triggered this error? --kc_kennylau (talk) 10:27, 6 May 2014 (UTC)
Any attempt to update the wiki (in this case - page.put(....). SemperBlotto (talk) 10:29, 6 May 2014 (UTC)
Tried logging out and logging back in? --kc_kennylau (talk) 10:35, 6 May 2014 (UTC)
This has been happening on all the different language versions of my bot for the past week or so (depending on when it last reloaded the watchlist). Now that it's happening on Italian I would like to get it fixed. (In other words, Yes) SemperBlotto (talk) 10:38, 6 May 2014 (UTC)
Any error when calling watchlist.py directly from the console? --kc_kennylau (talk) 10:45, 6 May 2014 (UTC)


OK. I have fixed it. I edited watchlist.py and stuck a "return" at the beginning of the "refresh" routine. That also saves several seconds of useless processing once a month! SemperBlotto (talk) 10:48, 6 May 2014 (UTC)
Then you're curing the symptoms instead of the diseases. I think that this is caused by the non-updated pywikibot. What version is your pywikibot? Mine is 2.7.6, for reference. --kc_kennylau (talk) 10:56, 6 May 2014 (UTC)
I don't care. SemperBlotto (talk) 10:57, 6 May 2014 (UTC)
user:SemperBlotto: You should probably update your script. This may be helpful: mw:API:Query#Continuing queries. Keφr 19:58, 6 May 2014 (UTC)

Automatization of German conjugation table[edit]

This discussion is put in both BP and GP because it involves both policy discussions and technical issues.

I am planning to make the German conjugation tables automatic. Module:de-conj has been built to realize this, but one must note that the module is not yet complete. For whatever reasons, Angr became the first user other than myself to actually use this template in an entry. Kephir helped me to simplify the codings of the module. The template calling this module is Template:de-conj-auto. The discussion below (if any exists) shall be about a few things:

  1. To actually use automatization or not.
  2. The usage of this template. It has been put in Template:de-conj-auto/documentation as a reference. The main rule I follow is to let the concatenation of all the parameters be equal to the page name itself. However, I am open to all potential changes which can improve it.
  3. Where to put the template. Currently, the template is located at Template:de-conj-auto instead of Template:de-conj because it already exists. However, if all German conjugation tables are automatized, it can be actually moved to Template:de-conj.

Of course, the discussion can be about anything related to this topic, other than the three points listed above. Examples of usage is located at Special:WhatLinksHere/Module:de-conj. --kc_kennylau (talk) 10:00, 10 May 2014 (UTC)

Flag for English broken[edit]

Hi.

I currently have the "Add country flags next to language headers" gadget on. As of recently, the flag for English seems to be broken. I inspected it and it seems to point to https://upload.wikimedia.org/wikipedia/commons/thumb/3/39/Flag_of_the_Commonwealth_of_Nations.svg/45px-Flag_of_the_Commonwealth_of_Nations.svg.png, which does not exist anymore. Can someone fix it please? Thanks, Malafaya (talk) 22:59, 10 May 2014 (UTC)

That choice should cement our low ranking among US users. DCDuring TALK 13:23, 11 May 2014 (UTC)
Yeah, we should do away with several of the random flags we currently use. If the primary purpose of the flags is to help people identify the languages, we are better served by using e.g. the diagonally-blended US-UK flags that other sites use to represent English (rather than this Commonwealth flag), and by using the Spanish flag for Spanish (rather than whatever obscure flag we use now - I think the flag of some NGO most Spanish speakers have never heard of?), etc. We have managed to use the French flag for French, it seems - whew. - -sche (discuss) 15:04, 13 May 2014 (UTC)
See MediaWiki_talk:Gadget-WiktCountryFlags.css#Flags_for_languages_spoken_in_multiple_countries. We probably need a dedicated discussion of this, since some users seem to prefer the obscure NGO flags. - -sche (discuss) 15:07, 13 May 2014 (UTC)
While we’re at it, are all the flags working for you lot? I was having some problem in the past due to the presence of the character '(' in some filenames. — Ungoliant (falai) 15:12, 13 May 2014 (UTC)

I am by no means advocating the use of the Commonwealth flag for English :). I'm just reporting the problem. So far it's the only problematic flag I have come across (there's this visible broken image placeholder in Chrome). Malafaya (talk) 23:01, 27 June 2014 (UTC)

mailing is nonfunctional[edit]

I sent e‐mails to Stephen G. Brown and one to Ruakh, but neither of them have replied yet. Just now I sent an e‐mail to myself, and it did not appear in my mailbox. Can somebody repair this? --Æ&Œ (talk) 02:08, 11 May 2014 (UTC)

Send one to me to be sure. DCDuring TALK 02:42, 11 May 2014 (UTC)
I got a copy of the e-mail I just sent you. DCDuring TALK 02:44, 11 May 2014 (UTC)
I also got one copy of an e-mail I sent myself. DCDuring TALK 02:46, 11 May 2014 (UTC)
I sent you one, and I did receive the one that you sent to me. --Æ&Œ (talk) 02:58, 11 May 2014 (UTC)
I didn't receive yours. DCDuring TALK 13:25, 11 May 2014 (UTC)

Module Error Bug?[edit]

What's going on with some templates right now? --Lo Ximiendo (talk) 13:21, 12 May 2014 (UTC)

I suspect User:CodeCat's edits on Module:scripts and Module:utilities have caused some global errors, but I am not sure. I have already left him a message on his talk page. --kc_kennylau (talk) 13:23, 12 May 2014 (UTC)
I made the suggestion there. --Lo Ximiendo (talk) 13:26, 12 May 2014 (UTC)
Well, he's already fixed the error. --kc_kennylau (talk) 13:29, 12 May 2014 (UTC)
What about this? --Lo Ximiendo (talk) 13:31, 12 May 2014 (UTC)
Module error bugs all over the kraal page too. Either it will take a while to reset all the pages that call the template, or there is still a problem. --EncycloPetey (talk) 13:53, 12 May 2014 (UTC)
CodeCat is a she, and I found that purging kraal got the module errors to go away, so I recommend trying that first on any page where you're finding them. —Aɴɢʀ (talk) 14:16, 12 May 2014 (UTC)
Purging all pages with script errors with my bot v..e..r..y.. s..l..o..w..l..y.. --kc_kennylau (talk) 14:42, 12 May 2014 (UTC)
How do I purge a page? --Lo Ximiendo (talk) 14:46, 12 May 2014 (UTC)
Done. You do a null edit to purge a page, or if you have pywikibot then it's page.purgeCache(). --kc_kennylau (talk) 14:49, 12 May 2014 (UTC)
Or add &action=purge to the url. - Amgine/ t·e 14:51, 12 May 2014 (UTC)
Sometimes this does not work. --kc_kennylau (talk) 14:52, 12 May 2014 (UTC)
No, it works. But you may connect to a slave which is slightly lagged. - Amgine/ t·e 14:57, 12 May 2014 (UTC)
@Lo Ximiendo: I find the easiest way to purge a page is to click "Edit" and then change the "=edit" (or "=edit&section=nn") at the end of the URL to "=purge" and then hit Return. This is often the only way I can get a red link to turn blue after I've created a new page. —Aɴɢʀ (talk) 17:10, 12 May 2014 (UTC)
  • The module that creates the heading in the NEC (new entry creator) not working. Donnanz (talk) 21:42, 12 May 2014 (UTC)
    • Fixed. —CodeCat 21:44, 12 May 2014 (UTC)
      • Cheers. It saves me typing out "Norwegian Bokmål". Donnanz (talk) 21:48, 12 May 2014 (UTC)

No frame object outside a function?[edit]

I've found that Module:debug's function track is causing errors when it's called from outside a function. For example, many headword-line modules have a call to getLanguageByCode at the top, outside any function. If tracking is added to that function, then an error results because mw.getCurrentFrame() is returning nil, while pcall (which does the tracking template transclusion) needs a valid frame object. Is there a way to create a frame object out of nothing? User:Kephir, since you wrote this function, can you help? —CodeCat 20:56, 12 May 2014 (UTC)

User:CodeCat: show me. (Also, why did I not get a notification?) Keφr 07:26, 13 May 2014 (UTC)

Transliteration linked to individual parts in usexes when hyperlinked[edit]

See [[доска]]: lýži iz doskí. Can they be delinked? lýži iz doskí -> lýži iz doskí.

Copying the usex here:

лы́жи из доски́lýži iz doskískis made from boards

--Anatoli (обсудить/вклад) 08:54, 14 May 2014 (UTC)

Per WT:USEX#Official policy, example sentences should not contain wikilinks anyway, so it needs to be changed to лы́жи из доски́lýži iz doskí — skis made from boards. —Aɴɢʀ (talk) 10:54, 14 May 2014 (UTC)
I don't think there's anything "official" about that page. Besides, the module definitely used to delink transliterations- something must have changed. DTLHS (talk) 22:27, 14 May 2014 (UTC)
I agree. Look at , for example, which has examples in different Chinese topolects or Cantonese 對唔住:
Chinese words are linked, transliteration is not (for Cantonese it's a manual transliteration). Without linking, users won't be even able to find word boundaries. I find this extremely useful. Other requirements in WT:USEX#Official policy seem also ridiculous - complete sentences (what about short collocations?). And I disagree with "as brief as possible". It does make sense people do make long examples, which I find interesting. Anyway, there are many hyperlinked usage examples, can we address the technical side of it, not the policy? {{l}} and {{term}} don't wikify transliterations: e.g. ба́за да́нных (báza dánnyx) --Anatoli (обсудить/вклад) 23:40, 14 May 2014 (UTC)
The statement at WT:USEX#Official policy is a direct quote from WT:ELE#Example sentences, which is official policy. Nevertheless I agree it's silly to require all usage examples to be complete sentences; also, the prohibition on wikilinks is explained with the statement "the words should be easy enough to understand without additional lookup", which makes me suspect whoever wrote that was thinking only of English example sentences at the time, not example sentences in other languages. But, alas, WT:ELE can only be changed by vote, common sense and discussion be damned. —Aɴɢʀ (talk) 10:40, 15 May 2014 (UTC)

Proposed new abuse filter: "mixing sailors" bot[edit]

I've just created Special:AbuseFilter/31: it is intended to block the "mixing sailors" spambot that periodically pops up here and on other wikis, always posting the exact same spam. I have ticked the box "Prevent the user from performing the action in question". Can somebody please review it, and enable it if it looks all right? Equinox 20:27, 14 May 2014 (UTC)

I don't think we're dealing with a bot, rather with a very persistent human with a rather lame sense of humor. After I protected the pages for every permutation of the magic phrase, they responded in a rather un-bot-like way by adding the same thing to other pages. The repetition of identical content is kind of like their way of marking territory- we always know it's the same person. It's not the only thing they post, though. They also create fake "Swedish" entries and a few other types of deliberately-nonsensical garbage in a similar style. I get the impression that they honestly think they're some kind of inspired trickster having fun at serious people's expense.
At any rate, I'm sure a filter would be harmless enough, but they'll just adjust things a bit and keep on doing it. Their efforts are an annoying waste of time, but only pop up now and then- and don't stay up for long. Chuck Entz (talk) 23:56, 24 May 2014 (UTC)
Looks like someone deleted this filter...? Special:AbuseFilter/31 is something quite unrelated now. Equinox 18:35, 24 July 2014 (UTC)
I repurposed it as a general "recurrent targeted vandalism" filter. You can reinstate the "mixing sailors" check if you feel it necessary. Keφr 19:05, 24 July 2014 (UTC)

XSAMPA to IPA module[edit]

Over at Wikipedia, I asked whether it would be possible to make a Lua module that converted XSAMPA input into IPA output. CodeCat said, "A module could accept IPA and X-SAMPA input fairly easily", so now I'm asking her or anyone else who feels so inclined to make such a module here. Entering pronunciations would be much easier for everyone if we could just type, say, {{IPA|/dIs"tINgwIS/|lang=en}} and it would appear as "IPA(key): /dɪsˈtɪŋɡwɪʃ/". —Aɴɢʀ (talk) 08:49, 18 May 2014 (UTC)

Just saying, a similar module Module:IPA was already created. However, there's only IPA to X-SAMPA currently. I'll add a function to convert X-SAMPA to IPA. --kc_kennylau (talk) 10:39, 18 May 2014 (UTC)
Cool, thanks. But now that we don't use XSAMPA in entries anymore, we only need XSAMPA to IPA conversion. If it goes both ways, how will the template know to always output IPA? —Aɴɢʀ (talk) 12:05, 18 May 2014 (UTC)
I've created a function to convert XSAMPA to IPA, but it's currently with flaw. --kc_kennylau (talk) 12:10, 18 May 2014 (UTC)
I've fixed the current cases. Feel free to plug in more cases in its documentation to test it. --kc_kennylau (talk) 12:27, 18 May 2014 (UTC)

Module error with {{rfv}} tags[edit]

I don't know what's causing this, but text like the following is appearing after the {{rfv}} tag on bludasolidotil, sangoscienco, ephemeris, and perhaps other pages too: <span id="attentionseekingla" class="attentionseeking" lang="la" title="Module error"> —Mr. Granger (talkcontribs) 18:25, 19 May 2014 (UTC)

The problem was in {{attention}}. I reverted the edit that caused it, but some pages may need cache-resetting. — Ungoliant (falai) 18:33, 19 May 2014 (UTC)
Thanks. —Mr. Granger (talkcontribs) 18:34, 19 May 2014 (UTC)

links to global account tools need to be updated[edit]

The links to the global tools on MediaWiki:Sp-contributions-footer no longer work as the Toolserver accounts have expired. Could an administrator please update them?

For reference, this is what we use on the English Wikipedia. Thanks in advance! --Ixfd64 (talk) 18:29, 21 May 2014 (UTC)

Done. Keφr 19:18, 21 May 2014 (UTC)
They work like a charm now. Thanks! --Ixfd64 (talk) 20:32, 21 May 2014 (UTC)

Batch Uploads[edit]

I'm sorry if this is the wrong place to ask, but there are so many discussion boards and users to directly address that I don't quite know where to ask. I'm having trouble with batch uploads - I don't understand how to do them (there is some explanation in one of the help pages but I didn't make much of it. I copied the code and saw the preview, and it was still just one page. Could some provide me with more detailed (and simplistic) instructions? I want to be able to produce dozens of pages with one click upon typing out one block of code rather than constantly searching words in the search bar and clicking on them when they appear in red to produce individual pages for each - this is going rather slowly at the moment.

Thank you in advanceMartin123xyz (talk) 07:56, 22 May 2014 (UTC)

@Martin123xyz: See Help:FAQ#How do I batch_upload?. Firstly, you have to have a bot account with the bot status required. Then, you should download python as well as pywikibot (download the "compat" version). After that, create a text file with the information for batch upload. When you have done that, run pagefromfile.py from the console (CMD). --kc_kennylau (talk) 09:48, 22 May 2014 (UTC)

Formatting on translation request pages[edit]

The formatting on Category:Translation requests (Spanish), Category:Translation requests (French), Category:Translation requests (Latvian), and so on is a mess, with the names of some of the pages in the category covering up the table to the right. Can this be fixed? —Mr. Granger (talkcontribs) 21:15, 23 May 2014 (UTC)

There's probably some css that could be added to fix it. DTLHS (talk) 21:28, 23 May 2014 (UTC)

Infinite-duration blocks of IP addresses 2[edit]

I'm not sure if anyone has been watching the Beer Parlour's January page, but I haven't seen any responses yet so I'm posting here again.

In January, there was a policy decision made at the Beer Parlour in Wiktionary:Beer parlour/2014/January#Infinite-duration blocks of IP addresses to lift any preexisting blocks from IP addresses that had been indefinitely blocked before 2010. I've finally gotten around to writing a script that could remove those blocks and I've posted in that thread and at User talk:-sche#Unblock script. I have a few more questions before I want to run it though:

  1. Do we still want to lift local blocks for globally blocked IPs pre-2010?
  2. Do we want to lift all local blocks for globally blocked IPs?
  3. Do we want to lift all local blocks for IPs blocked pre-2010?

I've got the script handy, and there's a few ways we could try to implement this. If there is an administrator willing to spend the time to check over the script, and most importantly they have pywikibot installed (because the script imports a lot of python modules), I could email the script and you could run it through your admin account if need be. Second way could be to have me run it from my account (but I would need admin perms first), and then we could have another admin check over my unblocks from time to time, there's a built-in throttle so don't worry. TeleComNasSprVen (talk) 23:12, 23 May 2014 (UTC)

To summarize the first BP discussion and my comments on my talk page for the benefit of those who don't click through: In the first BP discussion it was agreed that it doesn't make sense to issue infinite blocks to IPs, because IPs are reassigned over time. As a result, I lifted or made finite all blocks of IPs except those which were (a) blocked or locked globally or (b) proxies.
Also in that discussion, it was noted that even proxies' IPs are sometimes reassigned; furthermore, the "WMF makes exceptions for certain users which have justified to the stewards their use of such IPs[;] for such users the local blocks prevent their participation in project even though they have been cleared by community Stewards". Therefore, I think it makes sense not to locally indefinitely block IPs which are globally blocked. And if we ensure that the proxies we've blocked locally are also blocked globally, then if we lift all our local blocks of globally-blocked IPs, there shouldn't be any local indef blocks of IPs left.
There are so many locally-indef-blocked proxy IPs that it is not feasible to check by hand that they are also blocked globally, nor is it feasible to unblock them by hand. It may be debatable whether it is more ideal to unblock them via TeleCom's script or, as Kephir suggests on my talk page, to "poke someone from the WMF" to overhaul the database of blocks; but if we have a script available here and now, I think it is certainly more practical to use it than to shift the burden to the WMF, who may have the time for or interest in the matter.
- -sche (discuss) 21:05, 24 May 2014 (UTC)

Gadgets[edit]

Can you import these gadgets d:MediaWiki:Gadget-LocalLiveClock.js and d:MediaWiki:Gadget-historyNumbered.css from Wikidata? Regards and thanks. --Vivaelcelta (talk) 01:27, 26 May 2014 (UTC)

@Vivaelcelta: I was hoping someone would comment as to whether this was necessary/unecessary or desirable/undesirable, but since no-one has, I've copied the gadgets to MediaWiki:Gadget-LocalLiveClock.js and MediaWiki:Gadget-historyNumbered.css, respectively. The second half of the Numbered History gadget seems to be Spanish-centric; is it necessary here? - -sche (discuss) 19:28, 24 July 2014 (UTC)
Well, I declined to do anything in part because I did not think it was really desirable. Numbered history could be potentially useful, but I cannot understand why someone would need a local-time clock gadget. Do people not have clocks in their operating systems?
Anyway, the "Excepciones" seems to be styling for w:es:Special:Book, of which we do not have an equivalent here. It may be safely removed. Keφr 19:39, 24 July 2014 (UTC)

Module error in links for Korean[edit]

"Lua error in Module:links at line 99: attempt to index global 'annotation' (a nil value)", see Module_talk:links#Korean_transliteration --Anatoli (обсудить/вклад) 05:59, 28 May 2014 (UTC)

June 2014[edit]

Removing transliteration for full-width characters in Japanese usexes[edit]

Is it possible to remove transliteration for full-width characters only for ja-usex, so that nothing appears in furigana (ruby)? (transliteration in other places is still required, don't remove them from Module:ja)

A:わかった?B:おう。

A: Wakatta? B: Ō.
A: "You see?" B: "Got it."

Full-width characters A, B are only used here for display, they look better, not planning to use them in entries, in case anybody is concerned. --Anatoli (обсудить/вклад) 12:58, 31 May 2014 (UTC)

@Haplology:, @Wyang:, @Eirikr:, @Kephir: - do you think you can fix that? (Without removing from Module:ja)--Anatoli (обсудить/вклад) 02:39, 3 June 2014 (UTC)
Like the effect now? Wyang (talk) 03:11, 3 June 2014 (UTC)
Brilliant! --Anatoli (обсудить/вклад) 03:31, 3 June 2014 (UTC)
Except for the part with 80 module errors... Chuck Entz (talk) 04:10, 3 June 2014 (UTC)
That's the tracking error returned by Module:zh-han, not related to this. Wyang (talk) 04:20, 3 June 2014 (UTC)
The first couple I looked at (which have since magically disappeared) were Japanese. As for the "tracking error"... that makes about as much sense as a "tracking hand grenade". There has to be some way to track such things without blowing stuff up so you can spot the mushroom clouds. That way you could look in a tracking category to find out that you didn't allow for variant radical characters, like or instead of , instead of flooding the script error page so no one could spot the half dozen or so errors that you didn't do on purpose.
Of course, it's easier for me to point out what I think you're doing wrong than to provide a solution- let alone do it better (or even half as well) myself- I guess I'm just being cranky since it's past my bedtime... Chuck Entz (talk) 07:24, 3 June 2014 (UTC)
Oops, I see that's @Kc kennylau:'s mess. Never mind... Chuck Entz (talk) 07:36, 3 June 2014 (UTC)

Template:ko-hanja is (slightly) broken[edit]

Template:ko-hanja has been unable to show Korean hangeul characters as wikilinks by default (as in without added wikilink formatting brackets) for about almost a month now in the "hangeul=" parameter. This used to work before and doesn't now. Bumm13 (talk) 00:13, 3 June 2014 (UTC)

Lua version of langrev again[edit]

In a previous discussion I noted that our current solution for Lua-cising {{langrev}} was not efficient enough and was causing timeouts. User:Kephir suggested writing a script that generates a reverse lookup table, and then loading it with mw.loadData so that it would remain loaded for the duration of the whole page. That would make the first use relatively slow, as it would have to back-translate every single language in Module:languages and make a table of them. But hopefully that process would be fast enough, especially if it only ever has to be done once per page.

But I've been wondering about an intermediate solution. It's basically the same, except that instead of generating a single large reverse lookup table, we generate one for each of the data submodules of Module:languages. So for Module:languages/data2 there would be a corresponding Module:languages/data2/by name and so on. The assumption is that like with regular lookups, a lot of pages will not need to do a reverse lookup for every single data submodule, but only a few. So this might speed it up more still. Does anyone have feedback on this? —CodeCat 18:19, 7 June 2014 (UTC)

How can we maintain the correspondence between the two pages (without relying on a bot that someone may someday decide to stop running)? DTLHS (talk) 18:22, 7 June 2014 (UTC)
The reverse pages aren't actual tables. Rather they contain a script that runs when the module is first loaded (this is possible as far as I know), and generates the tables on the fly. —CodeCat 18:30, 7 June 2014 (UTC)
I created both Module:languages/by name (which generates one table for all languages in one go) and Module:languages/data2/by name, and tested them both. Generating a single table for all languages takes about 600-700 ms on average, while doing it for data2 alone took around 20-30 ms. So it looks like the time spent generating the tables roughly scales with the number of languages to process (as one might expect), and there is no huge difference between generating one table for all languages at once and generating 29 separate tables for each of our data modules. Presumably the latter is slightly slower because there may be a bit more overhead involved, but it doesn't seem too significant.
However, if the table is generated in one go, then any page using it will always take a 600 ms hit on load time. If we use individual tables for each submodule, then it would be less overall because pages would generally not need to reverse-lookup one language from each of the 29 possible tables. So it would be faster in the end. The downside is that we'd have to copy the table generation script 29 times, which is less than ideal. —CodeCat 19:03, 7 June 2014 (UTC)
Not really, a generic generation script could be put on one page, while the 29 reverse-lookup pages would have stubs like return require('Module:languages/genrevtable')('Module:languages/data3/x'). This is not a big issue anyway, since I doubt that the reverse-lookup generation code would ever have to be revised. Keφr 08:44, 8 June 2014 (UTC)
I may be reading this wrong though, because the time spent in Lua includes the time spent loading Module:languages/data2 and all the other data modules themselves. Every page will always load at least one of the data modules for other purposes, but probably many more, particularly for pages that use many different codes (translation tables or descendant trees for example). So that time would need to be subtracted. —CodeCat 19:07, 7 June 2014 (UTC)
I tested it again and it appears that loading all of our language data modules alone (via Module:languages/alldata) takes about 200-300 ms. Subtracting that from the total time spent creating the reverse tables leaves about 300-500 ms. —CodeCat 19:12, 7 June 2014 (UTC)
And I found out while working on Module:Unicode data that looking up phantom tables themselves tends to be somewhat expensive (hence all the memoisation there). Keφr 08:44, 8 June 2014 (UTC)
Given that the language data modules aren't changed that often, it's a shame there's no way avoid using all those resources to recreate the lookup table on the fly with every page view. I wish there were a way have updating of a module-based table triggered by saving changes to one of the data modules, or to have something analogous to doing a null edit on a template to make it reflect changes to the templates it transcludes. If there were a simple, automated way to update the lookup table, we could rely on the admins who edit the data modules to do so. Chuck Entz (talk) 20:33, 7 June 2014 (UTC)

I've now deployed the basic all-language table in Module:languages, and changed the three templates that used {{langrev}} to use it instead: {{ttbc}}, {{trreq}} and {{langcat}}. It looks like it works well, or at least well enough to be usable. I think we can delete {{langrev}} now? —CodeCat 14:29, 10 June 2014 (UTC)

After advertising the switch from the template to the Lua version for a little bit, yes. (@msh210: in particular as a user of the template.) The Lua langrev is inherently up-to-date (unlike the template), and can be used directly and even substed...yay! I've added some documentation on how to use it. - -sche (discuss) 15:50, 10 June 2014 (UTC)
Thanks for the ping. How do I use the module instead (the way I use langrev, viz with subst)?​—msh210 (talk) 15:58, 10 June 2014 (UTC)
If you know a language's code (for example, "en") and you want to find out its canonical name, you can use this:
  • {{subst:#invoke:languages/templates|getByCode|en|getCanonicalName}} (returns "English")
If you know a language's canonical name (for example, "English") and you want to find out its code, use this:
  • {{subst:#invoke:languages/templates|getByCanonicalName|English|getCode}} (returns "en")
- -sche (discuss) 16:04, 10 June 2014 (UTC)
It's actually just {{subst:#invoke:languages/templates|getByCanonicalName|English}}. I made it so that the templated version returns the code directly, rather than call functions on the language object. I did this because it should be possible to determine whether a canonical name exists or not (invocation returns empty string if not). I don't know if I should have done it this way though, there may be a better way that makes more sense. —CodeCat 16:18, 10 June 2014 (UTC)
Thank you both. Looks like it works (without |getCode; I didn't try it with).​—msh210 (talk) 05:02, 11 June 2014 (UTC)
The template {{langrev}} can probably be deleted either now or in a reasonably short time (or perhaps redirected), but the subtemplates definitely can not, as they are used directly by WT:EDIT in a manner that can not be replaced by the new method. --Yair rand (talk) 05:05, 11 June 2014 (UTC)
Why can they not be replaced? —CodeCat 10:03, 11 June 2014 (UTC)
Replaced with what? Keφr 11:01, 11 June 2014 (UTC)
Comment: A couple of years ago, I copied the trans adder (WT:EDIT) over to de.Wikt and tried get it to work there. Differences in entry format — such as the presence on en.Wikt and absence from de.Wikt of glosses atop trans tables, and of separate trans tables for separate senses — proved to be the main hurdle; once I set up a test entry with a modified, en.Wikt-style, gloss-having trans table, the trans adder worked, though it didn't move as quickly as it does here. de.Wikt has never had a Template:langrev or any subtemplates thereof.
The subtemplates of langrev add some peripheral functionality to WT:EDIT, pertaining according to its documentation to "autocomplet[ion of] language names", a feature which takes enough seconds to kick in that I always finish typing the language name before it does (in the rare instances I'm not just typing in the language code), except just now when I intentionally typed "Irish" very slowly into [[kitten]] to confirm that an autocomplete function did actually exist. WT:EDIT still works (core-functionality-wise) without the langrev subtemplates.
That's not an argument for deleting them, it's just to point out that they're not critical (which is good, because they're out of sync with Module:languages).
Can we find a way that WT:EDIT can search through the data modules, so that it can use them to autocomplete language names? Or should we have a bot periodically sync the subtemplates with the data modules? - -sche (discuss) 17:14, 11 June 2014 (UTC)

Danish Wiktionary[edit]

Hi! I am Ready Steady Yeti, and if you do not know me yet, I have been here for a few months, am really liking this project, and am making English and Danish entries, which I cannot say are perfect but I try the best I can because I actually have a goal for the "completion" of this project which can be viewed on my user page.

I have quite a history with the Danish language. I've self-teaching myself the language, and have been for almost 2 years now. I have been liking language since actually about 4 years ago when I started learning Spanish in school (which I do not speak anymore, because I completely ditched Spanish for Danish). None of my family or acquaintances know Danish or are from Denmark. I live in a southern US state, but I cannot remember exactly why I originally decided to learn Danish; I believe I read an article on the internet that was in Danish and it piqued my interest, but I'm not exactly sure if that's how it started. I have many methods of learning the language. I have 2 Danish learning books, and several regular books that were printed in Danish, such as Volmer: portræt af en samfundsstøtte. I also always use google.dk, and everything I can do online I do in Danish. I also chat with Danish people online a lot in Danish, which helps me greatly to be able to write in the language. Danish is a beautiful language (just my opinion). This is why I continue to learn it.

Anyway, as far as speaking Danish, I can write and type in a fluency of I'd say da-3, since I know more than just simple communication, but also some advanced words. My grammar is often very bad, but I do know the vocabulary at an advanced level. My speaking, as in like talking in real life, is unknown. I have no idea how well my Danish pronunciation is because I don't really have anyone to comment, but I listen to Danish music, videos, and other media, so I can kind of guess at how they talk. As far as speaking in real life though, it's much harder to understand Danish people when they're actually speaking than when they write. So I don't know if da-3 is an appropriate tag for me, but I use it because I'm able to write at that fluency, and that's all that really matters here, because we never speak to each other on wikis.

I'm not saying I'm an expert. I still have a lot to learn in this field.

All the stuff above is not actually important to the point of this discussion, but is an introduction to my knowledge of the Danish language[edit]

So anyway, yeah, as for the real discussion. I have been looking at the Danish Wiktionary for a while now, as I am trying to see if they have articles for a word I add or not (which they usually don't but occasionally they do, which is why I'm starting this discussion). Well the Danish Wiktionary has a massive load of problems that I will introduce to you now.

Well the first and foremost problem that I see that needs to be fixed more than anything else is the Danish Wiktionary itself and its entire layout. In its entry layout, it is nothing like it is here. It horribly represents pretty much all section headers using templates, such as { { -noun- | en } }, for the only purpose that I see of helping to categorize words, which we can do on our own here without those ridiculous templates. I mean don't you think that this layout is a bit too complicated for some people to understand, such as newcomers? I say, because I think very technically and I've been using the internet for a long time (since I was 2 years old to be exact), I think I know how to understand the source code. But this layout is just completely unnecessary not just because of newcomers not being able to understand it. It needs to be like our layout, and by the way instead of using the common { { head } } template they use silly things like { { pn } } to represent a noun, and I don't even know what the rest of their "heads" are. It is ridiculous. And they barely even use plural templates. I think that we should make their layout just like or very similar to our layout. They also have a huge lack of proper templates for lots of things, such as word forms, which is part of the reason why they have almost no entries at all for word forms, which I will get to later in this announcement. We should have the entry layout changed, first of all, having bots remove all the ridiculous messy layout that they have and replacing them with a layout that is not alienated to everyone besides the sysops. Secondly, we need new templates, such as the head template and word form templates for all languages we can, imported, and if necessary translated as well, straight from the English Wiktionary, and I somehow don't even think we need bots for this, but we could use bots if we wanted.

The second major problem that the Danish Wiktionary has (and trust me, many Wiktionaries have this problem actually), is that it has a huge lack of content. If you know what I mean by that. I will explain. The basic words that every Wiktionary needs are the basic words, at the very least, for their own language, which the Danish Wiktionary lacks a lot of those basic words. Like why is da:den missing? I'm sorry but that is just ridiculous. Besides that, as for the fact that Denmark's second language is English, it's English is lacking in the same way. Danish Wiktionary has certain specific words that the few users that they have have added. But what about the Malagasy Wiktionary? Despite the fact that Malagasy is a very rare and uncommonly known language, the Malagasy Wiktionary, thanks to User:Jagwar, is the second most successful Wiktionary there is (we are first, remember that?). As far as I know, he used bots to manipulatively import entries from other Wiktionaries and translate them, and is doing this very successfully, because this Wiktionary has an unbelievable amount of words from not only its own language but from various other languages as well. I think someone needs to do this same thing to the Danish Wiktionary, use bots to import entries straight from other Wiktionaries and have some method of translating them. The language that is specifically needed more than anything else are Danish entries. We could import some entries for Danish terms from other Wiktionaries, and we should also use online ordbogs (Danish dictionaries) to use to add Danish terms in the Danish Wiktionary. Second most important language that must be there is English. I've done some entries on my own in English, but it's a pain in the ass to have to do it all manually you know. So we should import all English entries straight from here including word forms, meaning we'd have to make the proper templates, once again. Thirdly, I'd say we should focus on importing all possible terms (and worm forms, you know the drill) from the following languages:

  • Swedish
  • Norwegian (Bokmål and Nynorsk)
  • German
  • Icelandic
  • Faroese
  • Greenlandic

I say these languages because they are languages for words that I'd imagine Danish speakers would commonly want to look up on a site like Wiktionary. Additionally, since Wiktionary is for all words in all languages, we should import more of these common languages as well:

  • French
  • Spanish
  • Portuguese
  • Italian
  • Dutch
  • Polish
  • Japanese
  • Chinese
  • Arabic
  • Hindi

And since ALL languages, after that we should import ALL possible languages, like rare ones like Malagasy and Slovenian and Romanian and Azerbaijani and all the other languages you can possibly think of.

I know this isn't exactly about the English Wiktionary (well it kind of is, since we would import from here). I honestly have no idea how this kind of stuff works. These are just my ideas. The point is, how do you think we can implement this for the Danish Wiktionary to have as many terms as possible. I really want to look up any term here and there be a "Dansk" link at the side. Thanks for the help. I appreciate it. Ready Steady Yeti (talk) 21:27, 8 June 2014 (UTC)

First of all, the number of entries is only one measure of success- the entries have to have content that is correct, usable and useful. While there's considerable debate right now over whether the type of definition-less entry that would result from a mass import is better than no entry at all, I don't think anyone would claim that such an entry begins to compare with an entry that's been prepared by a human being who knows the language. Although it might have more entries, I don't think the Malagasy Wikipedia is anywhere near to being in the same league with the German, French, or Russian Wiktionaries (to name just a few).
Read through the current debate in the Beer Parlor about the mass creation of Ukrainian entries, and you'll see that it's not an unmixed blessing, and not the kind of thing to do without a consensus. In all of your discussion of Danish Wiktionary, I see one thing lacking: any mention of what Danish wiktionarians think about the idea. It may not have as much content as we have, or as many editors, but there are people there who have put in considerable time and effort to get it to where it is now. They deserve to have a say in how- or whether- this should be done. If you want to accomplish anything, you need to get them to sign on.
You're young and energetic, and you have some big ideas. On the one hand, there are amazing things accomplished by people who were too inexperienced to know that they were impossible. On the other hand, fools rush in where angels fear to tread: we've been burned badly by many prolific editors who knew little about the languages they were editing, but plowed right ahead anyway- we're still repairing the damage, years after they were banned.
Besides, getting things done by consensus can be slow and sometimes maddening, but the alternative is alienating the people who do all the work and who are the life's blood of a wiki. Chuck Entz (talk) 22:55, 8 June 2014 (UTC)

Zazaki Wikipedia[edit]

I saw a module error caused by using the "lang=diq" in the {{wikipedia}} template, so I thought I would fix it by using the the code that we accept, zza. The only problem is that there was no conversion of our zza code to the diq code used by the Zazaki Wikipedia, so it ended up linking to a "not found" page at English Wikipedia.

I could probably trace down the place where such conversions are set, but I thought it better to leave it to those who deal with such things in case there was some factor I wasn't aware of. As it turns out, Zazaki Wikipedia has no page with that particular spelling anyway, but it would be nice for editors to be able to link to any pages that do exist. Thanks! Chuck Entz (talk) 21:55, 8 June 2014 (UTC)

This should do the trick. - -sche (discuss) 22:07, 8 June 2014 (UTC)
Thanks! I knew it would be fairly simple, but I didn't want to blunder in without knowing why things are set up the way they are. Chuck Entz (talk) 22:22, 8 June 2014 (UTC)
No problem. I've added some documentation to WT:LANGCODE in bid to increase institutional knowledge of the workings of Template:wikimedia language. - -sche (discuss) 22:48, 8 June 2014 (UTC)

Template:transterm and transliterations[edit]

If a language has automatic transliteration, {{transterm}} incorporates it:

But if a language does not have automatic transliteration, {{transterm}} does not allow a transliteration to be specified manually:

(And if a language has automatic transliteration but someone desires to override it, e.g. in the case of что, that is also not possible.) Can someone modify the template so that it does allow transliterations to be set manually? - -sche (discuss) 21:17, 11 June 2014 (UTC)

It now accepts tr= like {{m}} and {{l}} do. —CodeCat 21:47, 11 June 2014 (UTC)
Thanks! - -sche (discuss) 21:51, 11 June 2014 (UTC)

Category:Georgian preverbs includes templates which are too large and have too many arguments[edit]

While previewing this edit before making it, I got the following messages, in red (the first one is normal, it's the other two I find interesting):

Remember that this is only a preview. Your changes have not yet been saved! → Go to editing area
Warning: Template include size is too large. Some templates will not be included.
Warning: This page contains at least one template argument that has a too large expansion size. These arguments have been omitted.

The category is also in several automatically-added cleanup categories, viz. Category:Pages where template include size is exceeded, Category:Pages containing omitted template arguments and Category:Pages with script errors. (Category:Latin orthographic variant forms is also in these categories.) Anyone know what's causing this and how to fix it? PS, would it be better grammar to have the error message say "an expansion size which is too large"? - -sche (discuss) 23:02, 11 June 2014 (UTC)

It looks like it has something to do with cases where the label ("preverb") does not exist. That can probably be handled better, I'll have a look. —CodeCat 23:11, 11 June 2014 (UTC)
In any case, a short-term fix would be to either add these categories to {{poscatboiler}}, or to remove the template from them. —CodeCat 23:17, 11 June 2014 (UTC)

𩙿 (U+2967F) and Template:ja-readings not working correctly[edit]

After creating the 𩙿 (U+2967F) article, I copied its "Japanese" (L2) section from the article as the Japanese information is the same. For some reason, the "kun=" (Japanese kun form) reading information isn't displaying for me (in two different browsers). I don't know if it has something to do with the character being in the CJK Unified Extension B range or if it's just some other miscellaneous bug. Bumm13 (talk) 06:51, 12 June 2014 (UTC)

Thanks to whoever fixed this! :) Bumm13 (talk) 12:52, 16 June 2014 (UTC)

User:Conrad.Irwin/editor.js doesn't work for Cantonese[edit]

For some reason, User:Conrad.Irwin/editor.js doesn't work for Cantonese, even though checking for Interwiki seems to be disabled (or was disabled). E.g. on elder_sister#Translation trying to add 姐姐 (ze4 ze1). Clicking "Preview translation" has no effect. "Loading..." shows indefinitely long. --Anatoli (обсудить/вклад)

Checking for interwikis appears to be on. Cantonese has the Wiktionary prefix listed as "zh-yue", but https://zh-yue.wiktionary.org doesn't exist, which is probably what's causing the problem. --Yair rand (talk) 07:20, 12 June 2014 (UTC)
Removed the {wiktprefix:"zh-yue"}, seems to be working now. --Yair rand (talk) 07:22, 12 June 2014 (UTC)
Thank you! --Anatoli (обсудить/вклад) 07:28, 12 June 2014 (UTC)

Accelerated usexes[edit]

I tried to use the wizard provided to add a usex on авіаза́сіб (aviazásib). That's the result in this revision:

  1. Template:Cyrl
    aviazásobom
    by air

I meant this:

  1. авіаза́собомaviazásobom — by air

Can this be fixed? Besides, some languages don't require transliteration, this should be optional. The wizard forced me to add transliteration. --Anatoli (обсудить/вклад) 23:57, 12 June 2014 (UTC)

Transliterations are no longer required by the script. The template {{lang}} is now used instead of the deleted script templates. Do we no longer have any sort of standard for example sentences? ELE still says that both translations and transliterations are supposed to be on their own lines, below the sentence itself. --Yair rand (talk) 22:47, 15 June 2014 (UTC)
Thank you but the template should use the language codes and automatic transliteration. As for transliteration on their own lines, the rule must be out-of-date, also the rule that words must not be linked. Inline usexes are also used quite heavily.--Anatoli (обсудить/вклад) 23:27, 15 June 2014 (UTC)

Wiktionary:AZH[edit]

Can someone please either unprotect this page or change its text from "#redirect [[Wiktionary:About Sinitic languages]]" to "#redirect [[Wiktionary:About Chinese]]"? Thanks. —Mr. Granger (talkcontribs) 14:05, 14 June 2014 (UTC)

Yes check.svg Done; thanks for noticing the issue. - -sche (discuss) 14:08, 14 June 2014 (UTC)

Adding Accelerated Category Creation to Catboiler Templates[edit]

Since these are being cleaned up/de-sphagettified and Luafied, thanks to CodeCat, I had an idea to throw in with all the other changes:

Right now, many of the category templates display a row of wikilinked breadcrumbs representing the category tree the category belongs to. When one of those is a redlink, clicking on it goes to the usual empty edit window, at which point one has to enter the correct template with the correct parameters- with very ugly results if one gets so much as a single character wrong.

It occurred to me that the template that creates those wikilinks should have all the information necessary to preload any redlinks with the correct template with the correctly-spelled parameters already included. This would change creating the categories from an advanced test of typing skills and of knowledge on how to find resources on Wiktionary (quick- what's the code for Benue-Congo?) to a no-brainer.

Is this idea workable, and can we do it? I'm not talking about today, but whenever the rework gets around to that part of the interface. Thanks! Chuck Entz (talk) 19:02, 14 June 2014 (UTC)

I certainly think it's feasible, especially as we already have a lot of the code for it, it would only need some modification. I think it's a very good suggestion too. —CodeCat 19:05, 14 June 2014 (UTC)

Inflections of Latin verbs not showing?[edit]

When I search a latin verb, the inflection table that used to come up doesn't anymore. for example, for the verb divido, when I scroll down to Latin-Inflections, it says "Module error" in red text. When I click on the "Module error", the following error is shown: "Lua error in Module:la-verb at line 234: attempt to index field 'subtype' (a nil value) Backtrace: Module:la-verb:234: in function "get_regular_stems" Module:la-verb:298: in function "?" Module:la-verb:31: in function "chunk" mw.lua:478: ?" Can someone please look at this? Thanks. —This unsigned comment was added by Ws04 (talkcontribs).

The error may have been introduced in diff (the module is called by the inflection templates), I can't be sure. - -sche (discuss)
Wyang (talkcontribs) seems to have fixed the main problem. There are still 13 entries (for now- there may still be edits working through the queue) that didn't clear up after a null edit, and there are 5 conjugation templates that also are still showing module errors after null edits. Chuck Entz (talk) 03:38, 16 June 2014 (UTC)

chapter in quote-book[edit]

It has been brought to my attention that the chapter field in the quote-book template puts its value into the displayed quote preceding the book's title. It would be a lot better if it were to appear after the title. This should be fairly easy to arrange, and I would be grateful if someone would arrange it. ReidAA (talk) 04:29, 16 June 2014 (UTC)
Note that the value of the chapter field should be shown after that of the section field. ReidAA (talk) 04:43, 16 June 2014 (UTC)

Now at [[Wt:Beer parlour/2014/June#chapter in quote-book]], where it belongs. Striking here.​—msh210 (talk) 07:21, 20 June 2014 (UTC)

Automatic transcription appears to override manual transcription?[edit]

Discussion moved from Template talk:term#Automatic transcription appears to override manual transcription?.

Compare the following attempts to refer to Moksha эльде:

  • эльде (elʹde) (no transcription set; outputs elʹde)
  • эльде (elʹde) (transcription set to äĺďä; still outputs elʹde)

Also, from a quick look around, automatic transcription is apparently language-specific? OK, someone needs to turn it off of Moksha anyway since the Cyrillic orthography fails to distinguish /ɛ/ and /e/. But this override thing is a clear bug at least. --Tropylium (talk) 13:52, 16 June 2014 (UTC)


This is definitely a bug that needs fixing. As for Moksha itself, I don't know much about it but distinguishing between two sounds is not always necessary in a transliteration. --WikiTiki89 14:11, 16 June 2014 (UTC)
Not a bug but a feature, Module:mdf-translit uses standard Moksha transliteration. Moksha doesn't need manual transliteration. Tropylium, if you wish to use a different standard, you need to explain why and what system you propose to use. Here's the current standard WT:MDF TR. --Anatoli (обсудить/вклад) 14:30, 16 June 2014 (UTC)wiki
Do you think it's not a bug, it's a feature is idiomatic? Keφr 14:58, 16 June 2014 (UTC)
I don't know but I meant it literally. --Anatoli (обсудить/вклад) 22:01, 16 June 2014 (UTC)
What Anatoli said. If you want to change the Moksha transliteration rules, please start a discussion on the WT:MDF TR page, preferably linking to scholarly sources documenting your scheme (I am not saying your scheme is necessarily worse than the current one). --Vahag (talk) 14:36, 16 June 2014 (UTC)
Regardless of how perfectly correct the automatic transliterations are, there should always be a way to override them. Even if they should not be overridden in the main namespace, it may be useful in discussions. --WikiTiki89 20:13, 16 June 2014 (UTC)
I think it was decided some time ago that for certain languages the transliteration was "perfect" and should therefore override any manual ones, as they were occasionally incorrect. —CodeCat 20:23, 16 June 2014 (UTC)
Maybe you should re-read what I just said. --WikiTiki89 21:51, 16 June 2014 (UTC)
For discussions one could avoid using templates, which use automated transliteration. The automated transliteration could be turned off if a language can't use it but it's not proven that it's the case with Moksha. --Anatoli (обсудить/вклад) 22:01, 16 June 2014 (UTC)
But that's a workaround. If a language's transliteration is perfect, then we could just remove all the erroneous uses of tr=, but we should still be able to override it when we want to. Templates should be as flexible as possible so that they can serve a wide variety of expected and unexpected uses. Making them intentionally restrictive is pointless and annoying. --WikiTiki89 22:17, 16 June 2014 (UTC)
But that's why there are languages, for which automatic transliteration overrides manual, since there are too many existing transliterations and users may continue adding non-standard translit. A bot can remove but someone may re-add. As I said, there were no reasons stated for the current transliteration to be overridden. If Moksha has exceptions, which merit manual transliterations, they should at least be mentioned. The original poster wasn't complaining about exceptions but our methods, if I understand correctly. --Anatoli (обсудить/вклад) 22:27, 16 June 2014 (UTC)
Users could just as easily add other junk to a page as an incorrect transliteration. And I already said that the override should probably not be used in the main namespace, but who knows, a reason may come up even for that. Foresight is not 20/20. --WikiTiki89 22:59, 16 June 2014 (UTC)
I'm not sure you understood what I meant but anyway, let me clarify. We only have one current transliteration per language. You know that I am pro-phonetic transliteration for languages with exceptions. With Cyrillic languages it's only Russian and Mongolian, which are not 100% phonetic and its a dictionary style to use word stresses for Slavic languages (Macedonian word stress is about 90% predictable). If word stresses are inserted for all Slavic languages, then manual transliteration would only be required for exceptions but majority of languages might rely on 100% automatic transliteration. With Mongolian (Cyrillic) we have neither native speakers nor enough info to cater for exceptions, so Cyrillic Mongolian transliteration overrides manual (for the lack of a different solution or lack f information). We assume that Moksha has no exceptions, i.e. pronunciation may be derived from the script, if phonetic rules are known. Tropylium (the original psoter) didn't specify that "э" or "е" may have different readings in various words/positions, he/she was just not happy with the way both letters are automatically transliterated as "e" when palatalisation is not marked - like in Russian, consonants must be palatalised in Moksha in front of "е", so "д" in эльде must be [dʲ]. Note that many casual Russian contributors use "'" to mark palatalisation, like "d'ér'evo" for "де́рево"
Korean and Japanese kana now have fully phonetic transliteration, which is phonetic (almost automatic with Japanese, 100% automatic with Korean), Lao is almost 100% predictable but has rare Thai borrowings with traditional spelling. Transliterating Thai automatically would be much more challenging and manual override should be allowed. North Indic languages, apart from Sanskrit have exceptions, some predictable (dropping inherent "a"), some are not (letters without nuqta when it is implied), so 100% automatic transliteration won't work. --Anatoli (обсудить/вклад) 00:50, 17 June 2014 (UTC)
Then you misunderstood what I said. Occasionally it might be useful to use a non-standard transliteration scheme, especially on discussion pages, for some languages even in etymology sections. There is no reason for the template to prevent you from doing so. --WikiTiki89 01:14, 17 June 2014 (UTC)
That transliteration, if it's different from our default (Wiktionary standard) should be specific, perhaps, tr2= or named transliteration, such as "yale=", with params such as sprs=y (suppress=yes) or something but I don't think it's necessary, if the discussion is not about the word but transliteration, then just type it or copy paste, for example "hangul" is deried from McCune–Reischauer "han'gŭl", you don't have to use "tr=" here, just use the literal "han'gŭl", using templatised 한글 (han-geul) will only show currently accepted standard transliteration for Korean, no need to force it to show "han'gŭl", unless the Korean module couldn't handle transliteration correctly. Why would you otherwise, use a transliteration, which is not approved or default? --Anatoli (обсудить/вклад) 01:26, 17 June 2014 (UTC)
tr2= and yale= don't exist. If you want to make the templates more complicated by adding them then go ahead, but the better solution is to just allow overriding. Yes, there is always the workaround of not using the template, but the templates are more convenient (which is what they are for). --WikiTiki89 03:06, 17 June 2014 (UTC)
You can't help without complicating, if we allow overriding, then we get what we had before - thousands of non-standard transliterations, which was especially striking with Armenian, Georgian and many other languages. Vahagn asked for override for a reason. tr= calls automatic transliteration, if exists and there is only one method per language. In most cases, the transliteration used is the one that's required. "äĺďä" is not the current standard transliteration for Moksha "эльде". To use transliteration other than standard we should use other (new) templates, which could take tr= or rom= or don't use templates at all. For example, {{Zhuyin}} converts pinyin "lìshǐ" to Zhuyin ㄌㄧˋ ㄕˇ

.

One could make specialised templates for any additional romanisation or conversion. --Anatoli (обсудить/вклад) 03:24, 17 June 2014 (UTC)
  • I agree with Wikitiki89. People are smarter than machines, and when machines get in their way, people are good at working around them. If someone is adding a word, and really feels that a certain transliteration should be used for that word, then I'd rather let them (provisionally) use that transliteration; and if we think they're wrong, then we should discuss with them and reach consensus. Otherwise, there are three possible outcomes: (1) we get our way, by mechanized bureaucracy and faceless bullying; (2) they get their way, by circumventing our template system, discarding all language-tagging, etc.; or (3) neither of us gets our way, because they discard their edit and don't add the word. (I'm sure some of you will be happy with outcomes #1 and #3, and will accept outcome #2 because you're sure that you can devise smarter machines that will patch that hole as well; but I'm hoping that most Wiktionarians still have the good sense to recognize that all three of these are bad outcomes.) —RuakhTALK 04:05, 17 June 2014 (UTC)
  • Only enable manual translit for these languages when not in main namespace, and turn off the transliteration field for these languages in translation tables. Transliteration should be consistent when presented to readers. Wyang (talk) 04:24, 17 June 2014 (UTC)
While not totally disagreeing with Ruakh or Wikitiki89, I'd like to try to rephrase what I said before. The rationale for the override was that manual transliteration was redundant as a minimum, non-standard or wrong as a maximum. No transliteration can ever please everyone and you both know it. Now, with cases when we do really need to use a different transliteration - there are three reasons, in my opinion 1. because we don't like it - suggest to use a different system, 2. exceptions - languages with exceptions allow manual override, 3 - I accept the system but I want to use something else still - don't use templates or asks for a different conversion template. Does it sound fair? The first and the third reason are in conflict with each other, therefore there must be an additional parameter/template for this. @Vahagn Petrosyan: could you show some examples of bad transliteration, I don't remember.
@Wyang. Yes, it sounds reasonable but someone may still want to use automatic transliteration in discussions, so again - multiple templates or parameters may be the way to go. E.g. if tr2= is specified, tr= is suppressed or something similar. --Anatoli (обсудить/вклад) 04:34, 17 June 2014 (UTC)
There are two types of automatic transliteration: 1) when |tr= is empty, all languages with a specified translit_module in Module:languages/data2 etc. will be transliterated; 2) when |tr= is non-empty, languages specified in override_translit in Module:links will have the |tr= value overriden by the automatic transliteration. We could just further restrict the second condition, making it happen only if the page is in the main namespace. Wyang (talk) 04:39, 17 June 2014 (UTC)
I know but (I repeat) someone may still want to use automatic transliteration in discussions. One such application is, especially important, IMHO, is Wiktionary:Translation_requests but not only, automatic transliteration is helpful in many cases for people not familiar with native scripts, even outside the main namespace, e.g. if I want to say that Korean 반장 (banjang) (one of the senses) is related to Chinese 班長 (bānzhǎng) - the automatic transliteration immediately shows phonetic resemblance. --Anatoli (обсудить/вклад) 04:57, 17 June 2014 (UTC)
Making automatic transliteration not overridable still generates the automatic transliteration when there is no transliteration specified. The automatic transliteration is not displayed only when a transliteration is specified. Wyang (talk) 05:28, 17 June 2014 (UTC)
I know but for some languages it may be preferable to override. Even if I specify a non-standard transliteration "sri lankāva" for ශ්‍රී ලංකාව (ś‍rī laṁkāva), it will still show the correct "ś‍rī laṁkāva" because it has override_translit. --Anatoli (обсудить/вклад) 05:37, 17 June 2014 (UTC)
I actually think it would be far better for Korean to have override_translit because translations may soon be loaded again with Yale, McCune–Reischauer, etc. --Anatoli (обсудить/вклад) 05:40, 17 June 2014 (UTC)
  • I would tend to agree with Ruakh that we should allow manual override of automatic transliterations, except that I can see two big, connected problems with doing that, which Vahag hints at. (1) Not all languages have automatic transliteration, so users may supply manual transliterations not because they want to override the automatic ones in a particular case, but because they don't realize a transliteration would be provided automatically, and they think they have to set one manually. To catch such instances, we could (as I think we already do) category cases where manual transliteration overrides automatic transliteration. But (2) if there are more than a few dozen or hundred instances where we've intentionally overridden automatic transliteration, it will probably be difficult to spot new additions to the category. For example, if there are 250 words in Language X where we want to override automatic transliteration, 250 words out of, say, 300 000 words in the language is such a small percentage that it doesn't stop it from being worthwhile to turn automatic transliteration on for that language, but 250 is a large enough number that spotting the newcomers when the number of entries in the category goes up to 252 will be nontrivial.
    To address the first issue, we could use a tr2= parameter as was suggested above, so that it's harder for people to override manual transliterations without realizing that's what they're doing. To address the second issue, I suppose we could maintain an appendix of some sort of 'approved' cases of transliteration-override, and have a bot work from that to find new cases of transliteration-override... is that feasible? Is that worthwhile? - -sche (discuss) 15:04, 17 June 2014 (UTC)

OP here again. OK, I follow the concern that allowing too much manual transcription leads to a lack of standardized transcription — though also the counterargument that entirely disallowing this leads to people looking for workarounds. What's even the point of having a tr= field, if it's not actually usable? The suggestion of a tr2= might be a decent compromise.

(Also FWIW, this all really ought to be explained in the relevant template documentation.)

Contra Anatoli upthread, I am however indeed mainly complaining about being unable to render phonemic distinctions that the native script does not capture! (Specifically for the purposes of an etymology section or appendix.) I have by this point one main question: who decided and where that "Moksha doesn't need manual transliteration" or that "all languages written in the Cyrillic alphabet, other than Russian and Mongolian, are 100% phonetic"?? This is nonsense that is contradicted for plenty of few minority languages of Russia. E.g. Tundra Nenets, whose orthography does not distinguish /i u/ from /iː uː/; Mansi, whose orthography does not distinguish /e/ from /ə/; Erzya, Udmurt, Komi and Mari, whose orthography uses iotated vowels for both /ʲV/ and /jV/; etc. These are basic facts that anyone familiar with the languages in question ought to know. I can dig up sources if necessary, but I'd like to see where this all came from, first. If it was decided by "some пижонs" who knows nothing about the languages, spending a day or two digging up sufficiently explicit sources really should not be necessary for overturning this.

Though I guess there's also a transliteration (orthographic) vs. transcription (phonetic) issue here. I wouldn't mind automatic transliteration at all, if there were a way to independently indicate phonetic transcription. --Tropylium (talk) 12:31, 18 June 2014 (UTC)

I didn't say that any language is 100% phonetic but the scripts were made with the pronunciation already in mind, even if they don't match exactly the native pronunciation. In Russian, there are traditional spellings and most minority languages just didn't have such a long Cyrillic spelling tradition to have a traditional spelling. It's true that there are big differences between the spellings and the pronunciation but that's with phonetic transcription in IPA, not transliteration, isn't it? Long vowels are still transliterated as short vowels. Do you suggest to render iotated and palatalised consonants with different symbols? If yes, then what transliteration system is that? If you only need this for a demo, it may not work. As I said, we don't have people to work with Mongolian Cyrillic, so Mongolian automatic transliteration overrides manual, regardless of non-phonetic spellings. Note that with Russian, which has expected sound changes - voicing, devoicing, vowel reduction, consonant assimilation, deassimilation, etc. - are not rendered with special transliteration (molokó, not malakó, zub, not zup, etc.), only unpredictable exceptions are transliterated manually and those exceptions are documented, categorised and looked after. --Anatoli (обсудить/вклад) 13:06, 18 June 2014 (UTC)

Font of fake headers[edit]

The headers added by Template:fake== and Template:fake=== still used the old (sans serif) font, and so don't match actual L2 and L3 headers, which use serif font. - -sche (discuss) 04:47, 17 June 2014 (UTC)

They still use sans-serif for me. Keφr 05:44, 17 June 2014 (UTC)
For me too, which is what -sche said. The "real" L2 and L3 headers use a serif font; the "fake" ones use a sans-serif. I can't say I find this particularly tragic, though. —Aɴɢʀ (talk) 08:43, 17 June 2014 (UTC)
No, the real headers use sans-serif. Keφr 13:40, 17 June 2014 (UTC)
Ew. 2006 called; they want their skin back. —Aɴɢʀ (talk) 13:59, 17 June 2014 (UTC)
I prefer an ugly but stable skin to keeping getting annoyed with whatever UI changes the WMF feels like making. Which includes serif headers. Keφr 17:20, 17 June 2014 (UTC)

Wiktionary:Feedback is user-foely[edit]

The feedback tool disappears after you use it. Each section must be transcluded to its own talk page. Lysdexia (talk) 07:42, 17 June 2014 (UTC)

Yellow links[edit]

Yellow links don't work for me for some reason (ticked, save and hard-refreshed). Tried Firefox and IE. --Anatoli (обсудить/вклад) 14:33, 17 June 2014 (UTC)

What generates yellow links? I get red, orange, maroon, two shades of blue, and black, but never yellow. DCDuring TALK 17:22, 17 June 2014 (UTC)
He probably means the orange links. What generates maroon links? I've never seen those. —Aɴɢʀ (talk) 20:37, 17 June 2014 (UTC)
He is probably referring to visited and unvisited links. --WikiTiki89 21:30, 17 June 2014 (UTC)
That was my thought, too, but then what generates the second shade of blue? Internal vs external links? Goodness, it's all so confusing! haha. - -sche (discuss) 21:54, 17 June 2014 (UTC)
brown leaf Keφr 21:29, 17 June 2014 (UTC)
Orange, not yellow, sorry - WT:PREFS Color links to language sections that don't exist orange where they would otherwise be blue. --Anatoli (обсудить/вклад)
A color that appears marooon on my laptop, but some less distinct color on my tower's screen, is what shows up for visited redlinks. And I forgot green. DCDuring TALK 22:04, 17 June 2014 (UTC)
There are quite a number of different colors that links can have.
No idea what's causing the problem. The script works for me on Firefox, so I suspect something might just be broken by your personal JS. --Yair rand (talk) 23:00, 17 June 2014 (UTC)
What are other prerequisites for the orange links to work? Yesterday I tested on Belarusian за́яц (zájac) (Russian entry existed but not Belarusian). If an entry exists but in a different language, it should be orange. Is that a correct assumption? Using a different word, since заяц has been added: абза́ц (abzác) the link appears blue for me, not orange and it's a different computer. --Anatoli (обсудить/вклад) 23:42, 17 June 2014 (UTC)

Cyrillic font[edit]

The default font that is used for Wiktionary content has Cyrillic characters as well, but actual Cyrillic content is displayed in Helvetica instead. I don't think it looks very nice when Cyrillic is shown in a rather different font, it would look better if they matched. How could this be done? —CodeCat 20:22, 18 June 2014 (UTC)

I agree that Cyrillic should use the same font as the rest of Wiktionary if that font accommodates Cyrillic. While we're on the topic, the formatting imposed by {{m}} now puts Cyrillic in italics, e.g. {{m|ru|гит}} currently displays as гит (git), looking like sum but with the s in mirror writing. That's not too bad as far as I'm concerned (I know other people object to italic Cyrillic), but Early Cyrillic (Cyrs) is also displaying in italics, e.g. {{m|cu|гит}} currently displays as гит (git), which looks like crap. —Aɴɢʀ (talk) 20:35, 18 June 2014 (UTC)
I reinstated the italics just now. I don't know if many people will disagree with that, but I feel that if Cyrillic italics confuse people, then those are probably the people who are not native readers of the script. And those are exactly the people for which transliterations may be useful. Personally, I find Cyrillic italics very confusing too, but I still think we should have them for consistency with Latin script.
As for Old Cyrillic looking bad in italics, then I think we should look for better fonts, not remove the italics. It looks fine to me in any case. —CodeCat 20:39, 18 June 2014 (UTC)
FWIW, the previous discussion of Cyrillic and italics was Wiktionary:Beer parlour/2013/July#Scripts_and_italics. People seemed about evenly divided on the question of whether Cyrillic should be italicized or not. - -sche (discuss) 20:58, 18 June 2014 (UTC)
The issue here is (I think) that non-Slavic languages using Cyrillic script use certain characters that are missing in the default fonts. -- Liliana 21:02, 18 June 2014 (UTC)
For such cases, we often fork off a more specific variety of the script, like for many Arabic script languages. Would that not work here? —CodeCat 21:04, 18 June 2014 (UTC)
That certainly applies to Old Church Slavonic, as the default fonts tend not to include characters like ꙑ, ꙗ, ѩ, and ѭ. As the English Wikipedia, our target audience is not native readers of Cyrillic, but learners of Cyrillic, who may have mastered the roman form of the letters but not the italic form; and even for those of use more familiar with the italic form, things like питати are confusing because it looks so much like numamu—and that's a word in a language that uses both scripts. You say that гит (git) looks fine to you; what does ѩзꙑкъ (językŭ) look like? On my computer, the Early Cyrillic forms are not true italics but merely obliques and look very bad and unnatural (as bad and unnatural as oblique kanji and katakana look). —Aɴɢʀ (talk) 21:55, 18 June 2014 (UTC)
Or maybe set it for Cyrl and then reset it for all Slavic languages? There should be much less Slavic than non-Slavic languages using Cyrillic script (ru, uk, be, bg, sr, mk - anything else?) -- Liliana 09:44, 19 June 2014 (UTC)
Also Rusyn (rue). —Aɴɢʀ (talk) 10:22, 21 June 2014 (UTC)
Btw, it would be "sh" rather than "sr". Also, whether a language is Slavic or not is irrelevant. The real question is whether italics are used in that language. Here is an example of Mongolian in italics. --WikiTiki89 13:19, 21 June 2014 (UTC)
This is not about italics or not italics, it's whether the language needs special fonts. Slavic ones don't, but Mongolian for example has the letter Өө which is not present in contemporary fonts. -- Liliana 13:27, 23 June 2014 (UTC)
Except that it is. All the letters in scripts using Cyrl are present in the fonts we use for Cyrl. --WikiTiki89 14:12, 23 June 2014 (UTC)
Yes, and now people are whining because Russian uses a totally different font from the default. This is what the whole topic is about! -- Liliana 19:07, 24 June 2014 (UTC)
Russian does not use a different font from other (modern) Cyrillic languages. --WikiTiki89 20:21, 24 June 2014 (UTC)
It uses a different font from English though and that's the issue at hand! -- Liliana 20:23, 24 June 2014 (UTC)
So then the question is whether font used for English supports the non-Slavic characters you are referring to. The font used for English on my computer is Arial, which does support those characters. The problem with Arial is that it does not use actual Italics, but just slants the letters, which I think is just poor style (this applies to English as well). --WikiTiki89 22:05, 24 June 2014 (UTC)
It also uses a different font than Old Cyrillic on my computer - Old Cyrillic appears in the same font as English. —CodeCat 21:38, 24 June 2014 (UTC)
Yes, I was referring to Cyrl, not Cyrs. On my computer, Cyrs shows up in a different font called "Bukyvede" that resembles old Cyrillic manuscripts, probably because I installed it, but I don't remember whether I did or whether it came with Windows 7. --WikiTiki89 22:05, 24 June 2014 (UTC)
Incidentally, at diff you also put Greek into italics, but the Greek alphabet does not distinguish between roman and italic letter forms like Latin and Cyrillic do. Greek fonts tend to be somewhat oblique, but Greek doesn't have italics in the usual sense (apart from careless desktop publishing, an environment where you can find anything in italics, even East/Southeast/South Asian characters, Arabic, Hebrew, etc., none of which have any business being italicized). Please at least restore the italic inhibition for Cyrs, Grek, and polytonic, because italics are completely inappropriate for those scripts. And please consider restoring it for Cyrl as well, since the last time this was discussed 11 months ago, there was no consensus to display Cyrillic in italics. —Aɴɢʀ (talk) 22:05, 18 June 2014 (UTC)

I support using the same font for Cyrillic and Latin. I also support Cyrl in italic (but not Cyrs) and I just enabled italic for Armn. If people can't read italic Cyrillic, let them look at the transliteration. A good Russian dictionary would use italics to mention a word, e.g. here. --Vahag (talk) 07:59, 19 June 2014 (UTC)

I just got a talk page message here about this. The screenshot they attached shows that the fonts being used for Old Cyrillic are very different from the ones I'm seeing. They complain that the font is now too small, whereas I see Cyrs in the same font as regular Wiktionary text, so to me the extra 25% size makes it look oddly large, while not having it in italics looks odd when other Cyrillic text is. I suppose this is a very old problem with web design. But if our goal is to make Wiktionary look right for everyone, we really need to do something about this. Everyone needs to see the same fonts at the same sizes. There's no way we will get everyone here to agree on font display if everyone sees something else in the first place. —CodeCat 12:43, 19 June 2014 (UTC)

My font is similar to the one in that image. I don't think it's necessarily too small, but being oblique definitely makes it very hard to read. —Aɴɢʀ (talk) 14:23, 19 June 2014 (UTC)

Italicised Cyrillic is quite common and standard and used for various applications, even it's not normally used for book or movie titles like e.g. italicised English. Not sure about non-Slavic languages but I can't imagine that Kazakh, Kyrgyz, Tajik or minority languages of Russia never use italics, since this is/was quite normal and common in the USSR and Russia and punctuations, styles and many other things were for minority languages languages were just copied from Russian. In the previous discussion on italicised Cyrillic I did admit that italicised Cyrillic is significantly different from normal and may cause problems to non-native readers of Cyrillic but I didn't say it's not used, just to be clear on the distinction. I haven't seen Old Church Slavonic or Old Russian written in italicised script, so it's OK to NOT allow italicised Cyrs. @Vahagn Petrosyan: can Georgian also be italicised? --Anatoli (обсудить/вклад) 03:34, 23 June 2014 (UTC)

I know very little about Georgian, Anatoli. FWIW, I looked at a couple of linguistics books in Georgian: they use bold to mention a term and never use italic. --Vahag (talk) 07:30, 23 June 2014 (UTC)

Angr wrote “our target audience is not native readers of Cyrillic, but learners of Cyrillic, who may have mastered the roman form of the letters but not the italic form....” Our audience does read English, but it is very broad and we cannot pigeonhole it so tightly. Some readers find any foreign scripts and even many Latin characters and diacritics completely inaccessible, so one could argue that everything should be romanized and neutered. On the other hand, some use many languages and scripts, and some at an advanced native level.

But we have chosen to render foreign text in its native form, and supplement accessibility with romanizations. So our native renderings should be as true to native form as possible, for integrity and consistency, and for didactic purposes. If we present a language in a stilted form, then we should add a warning to readers that they need to go elsewhere to see how it should really be used.

I don’t see the point in avoiding oblique Cyrillics because some letterforms are new to some people, because all the letterforms are new to many people anyway. Michael Z. 2014-06-29 16:17 z

These principles are broken in the bizarro world of editing Russian of course, where editors transcribe the spoken word as if it were Chinese or something, and refuse to transliterate the written forms at all. Michael Z. 2014-06-29 17:31 z
Anyone learning Cyrillic would find it beneficial anyway to learn Italic Cyrillic. --WikiTiki89 16:40, 29 June 2014 (UTC)

I created a vote: Wiktionary:Votes/2014-06/Allowing Cyrillic to be italicized. —CodeCat 17:54, 29 June 2014 (UTC)

As there has been no further discussion, I've started the vote now. —CodeCat 14:02, 12 July 2014 (UTC)

Unresponsive script?[edit]

Lately I have been getting "Unresponsive script" messages regularly, 1-3 times a day.

The most recent message is got is:

Script: https://bits.wikimedia.org/en.wiktionary.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20140617T182240Z:69

  1. Am I the only one getting such messages?
  2. Is this a sign of some kind of real problem?

It's a little annoying, but only requires that I click a button to stop the script, so, unless there is a real underlying problem, this does not require action. DCDuring TALK 22:29, 20 June 2014 (UTC)

I get an unresponsive browser every time I open RFV/RFD. But no message about scripts. Try with ?debug=true added to the URL. Keφr 07:57, 21 June 2014 (UTC)
Never mind. Problem not limited to Wiktionary or even WMF. Maybe Firefox. DCDuring TALK 17:33, 25 June 2014 (UTC)

Mass deletion?[edit]

Category:Candidates for speedy deletion now contains several categories full of templates that need to be deleted. I have no idea how to delete them, though. There's just way too many. Is there a way to mass-delete pages? —CodeCat 16:46, 21 June 2014 (UTC)

Run a bot on your account (having granted yourself the bot flag beforehand). Otherwise no, apart from Special:Nuke, which seems not to be applicable here. Keφr 18:08, 21 June 2014 (UTC)

Significant problem with {{IPA}}[edit]

Apostrophes in {{IPA}} are now showing up as superscript j's. See for instance iri#Esperanto and bona#Catalan. I assume this is related to the edits that were made to the template in the past couple of days. —Mr. Granger (talkcontribs) 23:29, 21 June 2014 (UTC)

I’ve removed the code that is causing this until we figure out what to do. It’s not really the code’s fault, because iri, bona, etc. should be using ˈ (IPA stress mark) and not ' (dumb apostrophe), which is XSAMPA for ʲ. — Ungoliant (falai) 23:41, 21 June 2014 (UTC)
I imagine we may have to leave the 'ʲ code out permanently, because the misuse of apostrophes in place of stress marks has been common at all stages of Wiktionary's history. Incidentally, I've tried to compile all possible pronunciation-section problems into one list here (linked to from WT:TODO), in case any can be fixed by bot: for most languages, it would seem that changing apostrophes to stress marks could be done by bot. (But for languages that have ejective consonants, apostrophes may be misused for the ejective mark.) - -sche (discuss) 00:50, 22 June 2014 (UTC)
And in Gaelic languages, it's not unknown to use apostrophe for a prime, which is a non-IPA but used in textbooks (such as Ó Siadhail's Learning Irish) way of marking a palatalised consonant. --Catsidhe (verba, facta) 01:20, 22 June 2014 (UTC)
We should add a tracking category until the uses are fixed. DTLHS (talk) 00:51, 22 June 2014 (UTC)
It's a bad idea to convert X-SAMPA to IPA in {{IPA}}, we should have a new template for this, otherwise it leads to unwanted behaviors like this.
@Angr: Please read this discussion.
I had created a Lua version of the template at Module:User:ZxxZxxZ/IPA2, there's a list of all standard IPA characters there. There's also a list of obsolete and "non-standard" characters, entries which use them would be put in a tracking category, and entries using any other characters (i.e. invalid characters) would be put in a cleanup category. --Z 07:07, 22 June 2014 (UTC)
Well, but now there are other entries using the straight apostrophe in its XSAMPA meaning of ʲ, so if we just turn it off completely, those entries will get broken. Fortunately, there is another way of represent ʲ in XSAMPA, namely _j, so if we remember to always use that, then we can leave ' undefined. Maybe it could cause a module error, warning the user to correct to either " (for stress) or _j (for palatalization). If this is the only problem, then I don't think it's a bad idea at all to convert XSAMPA to IPA in {{IPA}}, especially considering the large number of entries that still use the "normal" g instead of the IPA ɡ. By allowing the existing {{IPA}} template to convert XSAMPA into IPA, we no longer have to track down and fix all of those. —Aɴɢʀ (talk) 13:52, 22 June 2014 (UTC)
The problem is in the overlap between them. I don't know if there are many cases where the same character can be interpreted in different ways depending on whether it's treated as IPA or X-SAMPA. But there are probably a few of such cases, which will cause problems if any entries mix the two (inadvertently in case of "g" or "'"). —CodeCat 13:55, 22 June 2014 (UTC)
Actually, there aren't any cases where the same character can be interpreted in different ways depending on whether it's treated as IPA or X-SAMPA. The straight apostrophe is not an IPA character; it has no meaning in IPA. The problem is that it looks enough like the IPA stress mark that some people have misused it that way. —Aɴɢʀ (talk) 14:32, 22 June 2014 (UTC)
Are there any other characters that are likely to be misused in a way that will cause conflict between IPA and X-SAMPA? —Mr. Granger (talkcontribs) 16:00, 22 June 2014 (UTC)
I can't think of any, but I'm always surprised by people's creativity when it comes to misusing the IPA. The bigger problem is people using Kirshenbaum instead of X-SAMPA, because there are a lot of characters that have one meaning in Kirshenbaum and a different one in X-SAMPA, including notably ', which is the stress mark in Kirshenbaum but the palatalization marker in X-SAMPA. —Aɴɢʀ (talk) 17:02, 22 June 2014 (UTC)
Looking at an X-SAMPA chart, maybe "!"? I imagine people might use it for "ǃ", but in X-SAMPA it seems to represent "". But fortunately alveolar clicks and ingressive airflow are both rare, so that shouldn't be a big problem. I guess there's also a risk of people using G for ɢ and R for ʀ, but that would be a pretty dramatic substitution. —Mr. Granger (talkcontribs) 17:20, 22 June 2014 (UTC)
@Mr. Granger:: possibly `, which is misused the same way the apostrophe is. And does the comma stand for anything in X-SAMPA? People sometimes misuse it for IPA ˌ. - -sche (discuss) 20:37, 22 June 2014 (UTC)
This is just one of the reasons it's a bad idea to mix IPA and X-SAMPA. --WikiTiki89 17:40, 22 June 2014 (UTC)
Well, maybe, but it's an even worse idea not to. —Aɴɢʀ (talk) 17:49, 22 June 2014 (UTC)
Umm... why? --WikiTiki89 18:10, 22 June 2014 (UTC)
Because of all the problems people have inputting IPA. I think a lot of people just don't bother with pronunciation information because it's such a hassle to the input the characters. —Aɴɢʀ (talk) 19:29, 22 June 2014 (UTC)
But that can be solved without mixing them. --WikiTiki89 19:43, 22 June 2014 (UTC)
Why not use a different template? —Mr. Granger (talkcontribs) 17:53, 22 June 2014 (UTC)
That's a better idea. --WikiTiki89 18:10, 22 June 2014 (UTC)
You mean bring back {{X-SAMPA}}? —CodeCat 18:15, 22 June 2014 (UTC)
Yes, and have it automatically convert from X-SAMPA to IPA. —Mr. Granger (talkcontribs) 18:21, 22 June 2014 (UTC)
I think there is a ramification in all this that hasn't been considered yet. If our entries end up containing X-SAMPA in their code, do I need to learn X-SAMPA in order to edit their pronunciations? —CodeCat 18:26, 22 June 2014 (UTC)
I was thinking we could have a bot periodically convert {{X-SAMPA|...}} to {{IPA|...}}. --WikiTiki89 18:39, 22 June 2014 (UTC)
That's the advantage to having one template do both IPA and X-SAMPA: people can use either system depending on what they're more comfortable with. —Aɴɢʀ (talk) 19:36, 22 June 2014 (UTC)
You may have misunderstood what I meant. A bot converting {{X-SAMPA|/@"baUt/}} to {{IPA|/əˈbaʊt/}} would mean that IPA and X-SAMPA are kept separate and that in the end we are left with only IPA. --WikiTiki89 19:43, 22 June 2014 (UTC)
But until the bot makes its rounds, if CodeCat spots an error in a transcription that's generated by {{X-SAMPA}}, she has to learn X-SAMPA in order to correct it. If we have a single template that does both, she can make the correction directly in IPA. So if it says {{IPA|/@"baut/}} by mistake, someone with no knowledge of X-SAMPA can correct that to {{IPA|/@"baʊt/}} and it'll still come out right. —Aɴɢʀ (talk) 20:24, 22 June 2014 (UTC)
A template named {{IPA}} with non-IPA characters in it... that's just asking for trouble, IMO. I like Wikitiki's idea. And couldn't the {{X-SAMPA}} template display "IPA: /IPA symbols/"? That way, people who don't know X-SAMPA get the same benefit you speak of CodeCat getting from an {{IPA}} template that accepts X-SAMPA input and displays IPA, while at the same time, there's no confusion about whether the input is IPA or X-SAMPA. - -sche (discuss) 20:37, 22 June 2014 (UTC)
That's exactly what I had in mind {{X-SAMPA|/@"baUt/}} and {{IPA|/əˈbaʊt/}} would display the same thing (and maybe the former can even be substed). --WikiTiki89 21:40, 22 June 2014 (UTC)
We don't have to use separate templates: make the first parameter a strictly-enforced IPA input, but have a named X-Sampa parameter for those who don't want to bother with direct IPA input (heck, we can throw in a Kirshenbaum parameter while we're at it). The error message for using non-IPA characters in the IPA field should tell people there's an X-Sampa option. Chuck Entz (talk) 20:57, 22 June 2014 (UTC)
But it makes much more sense to use separate templates rather than different parameters in one template. It's an arbitrary difference on the technical side, but a semantic difference on the user side. --WikiTiki89 21:40, 22 June 2014 (UTC)
I'm not so sure of that. The average user just wants to produce IPA output- do they really need two different templates to do basically the same thing? Chuck Entz (talk) 22:14, 22 June 2014 (UTC)
From a technical standpoint: Currently, if {{IPA}} is used without any content in its first parameter, it (appropriately) categorises the use as an error; if we were going to change it so that people could leave the first parameter blank and set an X-SAMPA parameter, we would have to change that. I think it would be tidier to use a separate {{X-SAMPA}} template; a separate template would also be simple to track (via Whatlinkshere). From a user-friendliness standpoint: Is a noob more likely to figure out that {{IPA}} accepts an X-SAMPA parameter, or that an {{X-SAMPA}} template exists? My guess is that it's the second one, or that it's a tie. We could even add the X-SAMPA template to the edittools, potentially with a note like "if you don't know IPA" to indicate that providing IPA is preferred. - -sche (discuss) 00:10, 23 June 2014 (UTC)

Did you notice that ULS provides an X-SAMPA input method? Why not point people to that instead? Keφr 19:51, 22 June 2014 (UTC)

What is ULS? —Aɴɢʀ (talk) 20:24, 22 June 2014 (UTC)
That thing we have been all throwing obscenities at a few months back. Gear icon next to the interwikis list. There is an "Input tools" tab, in which you can enable an X-SAMPA input method for inputting IPA. I never use it (I prefer to use the IME integrated with my operating system), but hey, it is there. Keφr 21:02, 22 June 2014 (UTC)
This thing, to be specific, if anyone wants to read up about it. - -sche (discuss) 00:13, 23 June 2014 (UTC)

I'm willing to undo the changes to {{IPA}} (and {{rhymes}}) that made them invoke Module:IPA if someone is willing to either (1) run a bot on a regular basis that fixes invalid IPA characters like g (should be ɡ) and : (should be ː) and the affricate ligatures like ʦ, ʧ, ʤ (should be t͡s, t͡ʃ, d͡ʒ etc.), or (2) set up a maintenance category listing pages where invalid characters are used inside {{IPAchar}} (which will include both {{IPA}} and {{rhymes}}). —Aɴɢʀ (talk) 07:01, 28 June 2014 (UTC)

Okay, a Feedback comment brought it to my attention that my change to how {{IPA}} works totally broke {{IPA letters}} (whose existence I was previously unaware of) in a way that I don't know how to fix, so I've gone ahead and undone my changes. {{IPA}} now works the way it used to up until about 8 days ago. I still hope someone can find a way to solve the issue of invalid IPA characters inside {{IPAchar}}, though. —Aɴɢʀ (talk) 11:26, 28 June 2014 (UTC)
Done: Category:IPA pronunciations with invalid IPA characters, Category:IPA pronunciations with obsolete or nonstandard characters, also Category:IPA pronunciations with invalid representation marks --Z 14:47, 28 June 2014 (UTC)
Thanks! I have to say, though, there are several entries in Category:IPA pronunciations with invalid IPA characters in which I can't find any mistakes. —Aɴɢʀ (talk) 15:22, 28 June 2014 (UTC)
Anything with a space will get added- not sure if that's intentional. DTLHS (talk) 21:38, 28 June 2014 (UTC)
Spaces need to be allowed. —Aɴɢʀ (talk) 21:42, 28 June 2014 (UTC)
What's invalid about 곤밥? - -sche (discuss) 17:08, 29 June 2014 (UTC)
The IPA there isn't enclosed in either slashes or square brackets, so it's unclear whether it's a broad/phonemic or a narrow/phonetic transcription. —Aɴɢʀ (talk) 17:28, 29 June 2014 (UTC)
Ah. That seems to be a problem many {{ko-pron}} entries have. They're probably all (or mostly) supposed to be /broad/, but I suppose they should be fixed in some human-checked way, e.g. with AWB, just to be sure. - -sche (discuss) 17:46, 29 June 2014 (UTC)

Many module errors[edit]

On the entry for cén, basically everything has module-errored. The page is practically unreadable because of all these module errors. Velociraptor888 09:31, 22 June 2014 (UTC)

Fixed already. Just purge the page. User:CodeCat accidentally deleted Module:languages. Keφr 10:28, 22 June 2014 (UTC)
Thank you! Velociraptor888 11:35, 22 June 2014 (UTC)
Yes, I'm sorry about that. I was using a bot to delete all the language code templates, and didn't notice that the module was also categorised in there, so it was deleted along with the rest... I restored it as soon as I saw what happened. —CodeCat 10:30, 22 June 2014 (UTC)

Macedonian: Alphabetical Order[edit]

When I view lists of Macedonian words in the category section, they are not in the proper alphabetical order. The list appears to go "ѕ", "j", "љ", "ќ", "џ" and then "а", "б", etc. See here: [[1]]. I think that this should be mended. Could someone take a look at it? Martin123xyz (talk) 20:16, 22 June 2014 (UTC)

I'm seeing this too, except for me it goes ', Ѕ, Ј, Љ, Ќ, Џ, Б, В, without an А in sight. - -sche (discuss) 20:45, 22 June 2014 (UTC)
Until custom collation orders for categories are implemented, we can't fix this. We're stuck with the Unicode collation order. —CodeCat 20:47, 22 June 2014 (UTC)

Macedonian: Wrong Apostrophe Sign[edit]

I seem to have been using the wrong apostrophe sign for the entries of Macedonian verbs starting with a syllabic "r". I used the apostrophe I have on my Latin keyboard outlay because I didn't know what button it was on the Cyrillic one and also because I though that there's no difference between a Latin and a Cyrillic apostrophe. However, there apparently is, and now all the entries of words starting with a syllabic "r" that I've made have the Latin type whereas all of the ones made by other users previously have the Cyrillic one. One reason why this is problematic is that the two apostrophes are alphabetized on different positions in lists. Could someone fix these entries for me? I don't know how to edit page titles (or delete pages). When I asked how, it was simply done for me. Martin123xyz (talk) 20:20, 22 June 2014 (UTC)

1. Move entries to the correct titles (click on More button, you will see this option) - this will also create a redirect from the original spelling. 2. Request deletion of the original spelling, if you don't think they should be kept. --Anatoli (обсудить/вклад) 03:24, 23 June 2014 (UTC)
I have moved the entries to the correct titles with the "More" button. However, I now cannot access the original pages to request deletion. They no longer appear on the list of nouns in the category "Macedonian Nouns" where they used to. Martin123xyz (talk) 07:11, 23 June 2014 (UTC)
They are no longer nouns but redirects, you can still access them and edit. --Anatoli (обсудить/вклад) 11:37, 25 June 2014 (UTC)
@Martin123xyz: Please also fix the broken links at Special:WhatLinksHere/'рскавица and Special:WhatLinksHere/'рж. --WikiTiki89 11:58, 25 June 2014 (UTC)
I have fixed something - I don't know if it's all alright now, though.
There's no such thing as a distinct Cyrillic apostrophe in Unicode. The entries have been moved from a version using the "typewriter" apostrophe ' to a version using the "curly" apostrophe , but both characters are equally Latin and equally Cyrillic. Since our custom here is to always use the "typewriter" apostrophe (e.g. don't; m'), I think these Macedonian entries should be moved back to the version with ', but the redirects kept (just as don’t and m’ exist as redirects). —Aɴɢʀ (talk) 19:44, 26 June 2014 (UTC)
I was thinking the same thing, but there is a difference here though. English Wikipedia uses the typewriter apostrophe for contractions, while Macedonian Wikipedia uses only the curly apostrophe for initial syllabic r, but the typewriter apostrophe for transliterations of the English apostrophe for example. --WikiTiki89 21:19, 26 June 2014 (UTC)

Vietnamese headword line template sorting issues[edit]

Come to the category chat to learn more. --Lo Ximiendo (talk) 03:19, 23 June 2014 (UTC)

Fixed. Chuck Entz (talk) 04:19, 23 June 2014 (UTC)
Thanks. The sorting errors on Vietnamese entries have been bugging me too. --Anatoli (обсудить/вклад) 04:23, 23 June 2014 (UTC)

Module:workgroup ping[edit]

(pinging: Keφr, Yair rand, CodeCat, Ruakh, Kenny, ZxxZxxZ from workgroup tech)

I just wrote a rough first draft of this module. It allows one to conveniently ping users interested in a particular topic. It works like this:

  1. Users add themselves to Module:workgroup ping/data indicating their areas of interest.
  2. When someone else wants to catch attention of a particular interest group, they use the {{wgping}} template. For example, {{wgping|sla}} will ping all the users interested in maintaining Slavic language entries.

I filled Module:workgroup ping/data with some sample data. Feel free to create new groups, add or remove yourself. This is just a proof-of-concept; I already have some ideas for changes (for example, requiring subst: for the template, to fix group members at the time of writing the post). And tell me what you think. Keφr 21:01, 23 June 2014 (UTC)

Is there still a limit (set by the site's software) on how many users can be pinged at once, or has that been lifted? In an ArbCom case on WP some time ago, a user pinged all the Arbs at once, so none of the pings went through. - -sche (discuss) 21:09, 23 June 2014 (UTC)
I might remember something like that, but I would have to dig though MediaWiki source code to be sure. Keφr 21:23, 23 June 2014 (UTC) (wrong URL anyway)
There is at least an upper limit of 100 users. Keφr 21:27, 23 June 2014 (UTC)
Is there any way to tie this into the babel templates somehow? DTLHS (talk) 21:13, 23 June 2014 (UTC)
I think no. Well, you might try abusing transclusion of Special:Whatlinkshere and work from that, but some sparse testing suggests it would not work. Keφr 21:23, 23 June 2014 (UTC)
That's what I thought. It just seems like a shame because we already have lists of users by language that will be somewhat duplicated. DTLHS (talk) 21:25, 23 June 2014 (UTC)
Plus that wouldn't separate knowledge of a language from interest in a language. --WikiTiki89 21:32, 23 June 2014 (UTC)
I have not set any fixed definition of a "work group" or an "interest group". I figure users could be pinged from WT:TRREQ as well. This module is whatever you make out of it. Keφr 21:48, 23 June 2014 (UTC)
We were discussing the idea of automatic groups from Babel templates. --WikiTiki89 22:20, 23 June 2014 (UTC)
Amazing idea! — Ungoliant (falai) 21:14, 23 June 2014 (UTC)

Refs in IPA template[edit]

I really want to undo this edit, but the anon has it right, the {{IPA}} template breaks when refs are inserted inside it. How can this be fixed? --WikiTiki89 02:54, 25 June 2014 (UTC)

I don't like the new IPA template. I cannot use <> or ~ inside the brackets now, as desired here, because things that should be interpreted as non-IPA are interpreted as IPA now. This new template should be moved to something like {{IPA-simp}}, leaving the original {{IPA}} functioning like before. Wyang (talk) 03:04, 25 June 2014 (UTC)
The subject of references inside {{IPA}} came up once before when a module or bot (I forget which) to check for the use of nonstandard symbols like " inside {{IPA}} was first being designed and I pointed out that things like {{IPA|/fu/<ref name="foo">Foobar</ref>|/fo/|lang=en}} existed. At the time, some other users argued that such things should be handled with {{IPAchar}}, like this. But using references within {{IPA}} was still possible at that time; if it's no longer possible, something must have changed. - -sche (discuss) 03:09, 25 June 2014 (UTC)
What changed is the support of X-SAMPA characters intermixed with IPA, which I think is a really stupid idea in the first place. --WikiTiki89 09:07, 25 June 2014 (UTC)
Then let's undo that change. The other discussion showed support for your two-template idea. - -sche (discuss) 17:31, 25 June 2014 (UTC)
Even if we undo support for X-SAMPA in the IPA template, we still shouldn't be putting ref tags inside the IPA template. It's just for displaying IPA. Put refs at the end, outside the template. —Aɴɢʀ (talk) 19:31, 26 June 2014 (UTC)

Bringing Russian verb conjugation templates here to the Korean Wiktionary[edit]

The mods in almost all the cases are no longer active in the Korean Wiktionary. And I want to bring the Russian verb conjugation templates here to the Korean Wiktionary. But the problem is that I don't know how. I wonder if anyone could help an ailing version of Wiktionary. Thank you. --KoreanQuoter (talk) 11:44, 25 June 2014 (UTC)

BTW, I wouldn't respond until Saturday. But thank you, again. --KoreanQuoter (talk) 11:54, 25 June 2014 (UTC)
Nobody? --KoreanQuoter (talk) 08:41, 28 June 2014 (UTC)

User:Conrad.Irwin/editor.js error[edit]

I am trying to add hærfest as a translation of autumn. When I type in the language code, the word, and the gender, and then click "Preview translation", the usual pop-up box comes up, but with an error: ERROR:TypeError: undefined is not a function. --WikiTiki89 13:03, 25 June 2014 (UTC)

It was the {{trreq|or}} that would follow the Old English translation. — Ungoliant (falai) 15:36, 25 June 2014 (UTC)
Oh. I presume that's a known issue, so I can close this discussion. --WikiTiki89 17:27, 25 June 2014 (UTC)

Module:links[edit]

Hi,

In Slovene, we have the word Franche-Comté (like in English and in French). But when we want to create a link to the Slovene section for this word (even if it doesn't exist now) with the {{l}} template, the link will be a link to Franche-Comte. A such link is not correct, is it? — Automatik (talk) 22:51, 25 June 2014 (UTC)

That's because {{l}} strips the accents from words. I'm not sure how we would prevent it in this case. —CodeCat 22:54, 25 June 2014 (UTC)
(e/c) @CodeCat: Perhaps we should provide an override for the accent removal? I imagine something like {{l|sl|Franche-Comté|target=Franche-Comté}}, which can maybe be shortened even to {{l|sl|target=Franche-Comté}}. --WikiTiki89 22:58, 25 June 2014 (UTC)
If that is how it should work, then we might as well just make it {{l|sl|Franche-Comté|Franche-Comté}}. That is, always disable the removal of diacritics if the alt parameter is present. This will break some of our current entries, but probably not too many and we can track them down first. On the other hand, it is kind of cumbersome to do it this way, but considering we've run into this problem only now, I don't think it's a serious issue. —CodeCat 23:07, 25 June 2014 (UTC)
If we have {{l|sl|Franche-Comté|Franche-Comté}} do that, it may not break many manual links, but it will break some logic in inflection table modules, where this feature is actually useful. --WikiTiki89 23:14, 25 June 2014 (UTC)
True. What's important though is that this change is compatible with a wide range of templates and their parameters. We could give all of them target= parameters, but there may be another way. Just like we have the character * in front of words to indicate that they are reconstructions, we could think of some other character that indicates that the link should receive no postprocessing. —CodeCat 23:22, 25 June 2014 (UTC)
That's also a good idea. What characters are not allowed in entry titles? --WikiTiki89 23:26, 25 June 2014 (UTC)
Alternatively, instead of using a single character, we could use a prefix string, like raw: for example. This is pretty much guaranteed to never occur at the start of a page title? The question then is what happens when this is combined with *, like *raw: and raw:*. Presumably the former should not process the name but still link to appendix pages, while the latter should link to an actual page beginning with * (like *nix). —CodeCat 23:36, 25 June 2014 (UTC)
That would work. I imagine raw:* being much more useful than *raw:, since we don't really do any postprocessing of reconstructed languages. --WikiTiki89 23:42, 25 June 2014 (UTC)
Not all appendix entries are reconstructed languages, though. We have quite a few Latin ones as well. —CodeCat 23:54, 25 June 2014 (UTC)
That's a good point. But they are still only reconstructed terms, which are likely to follow our notion of Latin orthography, which is not going to include words that are required to be written with a macron or anything like that. --WikiTiki89 00:02, 26 June 2014 (UTC)
How about just a colon? It would create the advantage of not having the syntax of vanilla markup and {{l}} diverge too much. (And it already works for "*".) Keφr 05:52, 26 June 2014 (UTC)
I thought about that before, but thought it would be counterintuitive given the existing purpose of a plain colon. But now that you bring it up again, I realize that it makes perfect sense. In fact, I'd even say that we should just check for the presence of a colon anywhere, that way other namespaces can be linked to without screwing up the link. But then the question remains of whether we should add the language section fragment after a raw link; it would be convenient in most cases, but might not always be desired. --WikiTiki89 06:03, 26 June 2014 (UTC)
Such target-page-related issues (diacritics removal, linking to appendices e.g. for *nix) rarely occurs, we can simply introduce an on-off parameter for linking templates to disable the functionality of make_pagename in line 216 completely. Let's avoid manipulating the string as far as possible, introducing a new character like "*" or "raw:" in the string may complicate our codes too much, without much benefit. --Z 08:14, 26 June 2014 (UTC)

I've implemented the : prefix for raw links now: {{l|sl|Franche-Comté}} > Franche-Comté but {{l|sl|:Franche-Comté}} > Franche-Comté. Likewise, {{l|en|*nix}} > *nix but {{l|en|:*nix}} > *nix. —CodeCat 19:43, 29 June 2014 (UTC)

We should have checked for existing usages with initial ":" first. --Z 20:08, 29 June 2014 (UTC)
They would have worked pretty much the same anyway: *nix. See? Keφr 20:22, 29 June 2014 (UTC)
And links to ":" don't work even in raw code: [[:]]. So nothing should be broken. —CodeCat 20:24, 29 June 2014 (UTC)
I know, I was talking about interwiki links. --Z 21:03, 29 June 2014 (UTC)

English genitive forms[edit]

Other Wiktionaries have genitive forms for nouns, such as the Swedish Wiktionary. Like "toad's", "frog's", "dogs'", "Ohio's", "Teletubby's", "Teletubbies'", "log's", etc. Please see sv:frog and sv:toad for an example. Why do we not have these forms? We have various word forms for other languages, including genitives and things with apostrophies, so the thing I don't get is why do we not have these? They are just as good of word forms as anything else. And other Wiktionaries are being a bit more clever than us at our own language. Please, let's get bots, or something, to add all these genitive forms that are missing from the English language. Let's put it in our policy now, there are 4 verb forms, nominative singular, nominative plural, genitive singular, and genitive plural. We are missing the genitives. Who's with me? Vote? Rædi Stædi Yæti {-skriv til mig-} 15:44, 26 June 2014 (UTC)

There has already been a vote where it was decided not to include these. The reason is that these are not true genitive forms. Rather, the suffix is a clitic and attaches to the whole phrase, rather than to the head of the phrase like in a real genitive case. —CodeCat 15:47, 26 June 2014 (UTC)
Why don't we tell this to the Swedish Wiktionary then, and tell them to stop adding the genitive case and confusing us with it? Rædi Stædi Yæti {-skriv til mig-} 15:50, 26 June 2014 (UTC)
Feel free to tell them. I'm not confused. But if you want to understand what I mean, look at The king of France's crown for example. The genitive marker follows France, but that doesn't mean that word is in the genitive. If it were, then the phrase would mean "The king of the crown of France" where it of course really means "The crown of the king of France". —CodeCat 15:52, 26 June 2014 (UTC)
Regardless of whether you call it a genitive or a possessive particle, the reason we don't include it is because it is easily predictable. --WikiTiki89 15:55, 26 June 2014 (UTC)
Does that mean that genitive forms are only useful in other language Wiktionaries, as someone who knows almost no English, but speaks Arabic or some random language like that, would have no idea what "dog's" means, despite the fact that they know what "dog" means? Whereas here, it is already obvious. Rædi Stædi Yæti {-skriv til mig-} 15:58, 26 June 2014 (UTC)
Each Wiktionary makes its own decisions. Editors here believe that even foreigners would have no problem figuring out what "dog's" means if they know what "dog" means. --WikiTiki89 16:09, 26 June 2014 (UTC)
The problem is actually more serious than that. It's that if you treat "dog's" as a form that is independent from "dog", then almost every word in the English language has a genitive form, even verbs, adverbs, prepositions and so on. Some examples: the dog I never saw's tail, the man who walked quickly's briefcase, the band I have an album of's latest single. —CodeCat 16:11, 26 June 2014 (UTC)

Danish verb forms[edit]

Well let's see. We have lots of Danish entries but we are lacking in many areas, I am saying once again. I just found out that the forms we use are not all of the forms that Danish uses in conjugation. Such as let's take antyde for an example. We only support the things for imperative, present tense, past tense, and past participle forms of antyde. However there are many other forms, and I will name a few as examples. I believe the following are called passives:

Also we are missing future tense:

Where are these forms in our templates? And are there more that I have not yet mentioned? (I am not a native speaker)

Please, let's make a conjugation template or something for Danish verbs. If not, let's improve the Template:da-verb template. Rædi Stædi Yæti {-skriv til mig-} 04:49, 27 June 2014 (UTC)

I believe there are an active and passive tense, much like Swedish. Why don't we make a conjugation table? This would make things much more clear. Rædi Stædi Yæti {-skriv til mig-} 05:14, 27 June 2014 (UTC)

Fill in as you wish and put at Template:da-conj-whatever:

<div class="NavFrame">
<div class="NavHead">Conjugation of {{m|da||{{{1<includeonly>|{{PAGENAME}}</includeonly>}}}}}</div>
<div class="NavContent">
{| class="wikitable inflection-table"
<!-- your table goes here -->
 |}
</div></div><noinclude>{{documentation}}

Keφr 09:01, 28 June 2014 (UTC)

Emoticons[edit]

Shouldn't we include emoticons in Wiktionary? I mean, I kind of was trying to look up a specific emoticon here but we didn't have it. Is this includable for the dictionary, emoticons? Because I don't see any here at all. Rædi Stædi Yæti {-skriv til mig-} 05:12, 27 June 2014 (UTC)

We have a few: Category:Emoticons by language. Someone of them need to be subpages of Unsupported titles because the first character of pagenames can’t be :. — Ungoliant (falai) 08:32, 27 June 2014 (UTC)
Not sure whether they are "words in a language", but neither are the mathematical symbols. What we shouldn't do at least is add the silly, complicated ones that only occur in lists: they should be held to the usual attestation standards (use, not mention). Equinox 13:38, 27 June 2014 (UTC)
Well what I'm thinking is we can make "Translingual" entries for these emoticons. Rædi Stædi Yæti {-skriv til mig-} 14:59, 27 June 2014 (UTC)
If you can attest them in multiple languages, then surely. (By the way, WT:BP seems better suited for this question.) Keφr 15:04, 27 June 2014 (UTC)
I'm more than positive that we can find most emoticons in Google Books in a flash. The question is is this allowed, and how can we implement this? Rædi Stædi Yæti {-skriv til mig-} 15:07, 27 June 2014 (UTC)
-1. Yes; 0. Open a page, 1. Type in a definition, 2. Paste citations, 3. Save page, 4. Done. Keφr 15:12, 27 June 2014 (UTC)

Creating a non-standard Capitalization entry[edit]

I tried to create eSports by typing the word into the Search box, and was taken straight to esports, which at the time was solely the Catalan entry. I then clicked on a redlink, and was taken successfully to page creation. I don't know if this is a bug or a feature. If it's a feature, I found nothing on it while quickly scanning the obvious page creation information.

I also double-checked: if you try to create (from the Search box) an oddly capitalized word that does not exist in all-small, you will be taken to page creation. Choor monster (talk) 13:04, 27 June 2014 (UTC)

It's a feature, and a relatively new one. The same is true for diacritics: if you enter a word with a diacritic in the search box, and if that word doesn't already exist as an entry, but another word with similar or no diacritics does exist as an entry, you'll be taken to the existing entry instead. You'll only be taken to the Search page if there are multiple entries with other diacritics, since in that case the search feature won't know which one you wanted. However, if you move your cursor down to the bottom of the suggested entries in the search box, where it says "containing..." and click there, you'll be taken to the Search page no matter what. —Aɴɢʀ (talk) 14:05, 27 June 2014 (UTC)
Perhaps in the case of a single valid entry, the entry should be displayed, but the typed-in version should be made available as a red-link below the top of the entry. Sort of like WP redirects. Choor monster (talk) 20:47, 27 June 2014 (UTC)

Volapük Conjugation Template[edit]

I've been thinking about making a conjugation template for Volapük verbs, most likely based on the one from the Portuguese Wiktionary. Any ideas and questions? --Lo Ximiendo (talk) 06:15, 28 June 2014 (UTC)

My bet for the conjugation table: {{vo-conj-verb}} followed by the verb's stem. --Lo Ximiendo (talk) 23:48, 28 June 2014 (UTC)

Keep getting logged out[edit]

Hello. Since yesterday, every time I visit this website, I find out that I am logged out. I am telling it to remember my login and everything, but it just keeps on logging me out. This is really annoying, and also means I have to get a new temporary password each and every time, as for some reason, it just doesn't accept the current one. Is there a solution to this? Velociraptor888 08:57, 28 June 2014 (UTC)

Template for Den Danske Ordbog[edit]

Can a template be set up for Den Danske Ordbog, which can be used for reference purposes in Danish entries? I was thinking of something like “Grease pit” in Den Danske Ordbog. Or is there already a template under a different name? Donnanz (talk) 14:36, 28 June 2014 (UTC)

No reason you can't do it yourself at {{R:Den Danske Ordbog}} (ie, Template:R:Den Danske Ordbog) or {{R:Danske Ordbog}}, using as models {{R:ODS online}} for categories and {{R:Webster 1913}} for including bibliographic info and for linking to the site (or to a Danish or English WP article) and to a specific page of any online edition, if that is possible. Linking to a specific page is not always straightforward. DCDuring TALK 22:54, 28 June 2014 (UTC)
I have tried setting it up, but I'm going wrong somewhere, or the link to the dictionary won't work. The link would need to use http://ordnet/ddo/ordbog?query?= . I also tried ODS online, but that leads you to the old dictionary (pre-1950). Donnanz (talk) 00:52, 29 June 2014 (UTC)
  • I am basically monolingual and no template maven either, but I have made some reference templates work. Where can I find a copy of your efforts? DCDuring TALK 01:08, 29 June 2014 (UTC)
Here: https://en.wiktionary.org/wiki/Den_Danske_Ordbog

The website isn't helping at the moment - it has decided to crash. http://ordnet.dk/ddo (I left out .dk before). Donnanz (talk) 01:21, 29 June 2014 (UTC)

I deleted it because templates need to start with "Template:" I created {{R:Den Danske Ordbog}} and gave it my best shot- but I'm no template maven either. The tricky part was getting it to output an = instead of interpreting it as part of the template syntax. You also got the query syntax a little muddled, but I saw a couple of good ones in some Google search results. Here's an example of use: {{R:Den Danske Ordbog|dansk}} gives “dansk” in Den Danske Ordbog
Chuck Entz (talk) 01:47, 29 June 2014 (UTC)
I realised my effort had to be deleted. I have just tried it for soveværelse, and it worked well, taking the letter æ into account. Thanks a million, Chuck Entz! Donnanz (talk) 07:16, 29 June 2014 (UTC)
  • Funnily enough, dansk is one of those words hinted at by DCDuring - "Linking to a specific page is not always straightforward." There are separate entries for the noun and the adjective - the adjective appears at dansk2 - http://ordnet.dk/ddo/ordbog?select=dansk,2&query=dansk. I will have to find a way round that. Donnanz (talk) 08:06, 29 June 2014 (UTC)

When creating new citations pages, template documentation page things are preloaded[edit]

When I go to create a new citations page, the edit window opens with the following preloaded:

 {{documentation subpage}}
 {{documentation needed}}<!-- Replace this with a short description of the purpose of the template, and how to use it. -->
 <includeonly>
 [[Category:Uncategorized templates]]<!-- replace this category with the category of your choice -->
 </includeonly>

This is also preloaded when I go to create a template documentation subpage, but it's to be expected and desired there. It's the preloading of it onto citations pages that should be stopped... - -sche (discuss) 22:24, 28 June 2014 (UTC)

I could probably fix this, but I forgot which script this code is in. Can someone tell me? —CodeCat 13:11, 30 June 2014 (UTC)
MediaWiki:Gadget-DocTabs.js (formerly MediaWiki:Common.js), and I already fixed it. Keφr 14:06, 30 June 2014 (UTC)
Thanks! - -sche (discuss) 14:08, 30 June 2014 (UTC)
@Kephir: Is there a reason why this was moved to its own dedicated script? —CodeCat 14:40, 30 June 2014 (UTC)
(for some reason the ping did not work.) To decrease its impact on other scripts; an error in it will not prevent others from running. And I have been planning to split out scripts from MediaWiki:Common.js in general. I wanted to move most of MediaWiki:Common.js to the LegacyScripts gadget, and start working on replacements. Right now looking at it makes me think of The Gospel of the Flying Spaghetti Monster. Keφr 16:26, 30 June 2014 (UTC)

Can we move away from wrapping collapsible tables in divs?[edit]

Our current and longstanding practice is to wrap collapsible tables in a pair of "div" elements with the "NavFrame" class, which are then handled by JavaScript (MediaWiki:Common.js) accordingly. However, this arrangement is kind of cumbersome. It means that the outer div can never adjust its width according to the table that's inside it. Instead, we have to do things like trying to pick some sensible default width and put up with wrapping if the content is too wide. Or alternatively, some of our collapsible tables are always as wide as the page, even if we don't need that much space (it looks very bad on wide displays like 1920x1080). Of course this is not ideal. So I wonder if we can move away from this practice somehow, and instead make the table itself collapsible, without wrapping it in anything. Of course collapsible things that are not tables, like translations or derived terms lists, will not change. —CodeCat 13:23, 29 June 2014 (UTC)

Maybe display:table-cell and friends can provide a fix? Michael Z. 2014-06-29 15:27 z
Some collapsing divs have text outside tables (i.e. see recolher). How would that be dealt with? — Ungoliant (falai) 17:15, 29 June 2014 (UTC)
We can put that in the table. I think it would look nice to put it in the table even if we don't get rid of the divs. It looks pretty bad right now. —CodeCat 17:19, 29 June 2014 (UTC)
We could use the <caption> tag (|+ below {| in wiki markup). But there is a problem; <caption> cannot be styled the way NavFrames can. Also, collapsing a table will also collapse its width to match the caption text (though that is also true of captionless tables). Keφr 18:11, 29 June 2014 (UTC)
Isn't it possible for JavaScript to determine the width of the table before it is collapsed, and set the collapsed-state width accordingly? —CodeCat 18:22, 29 June 2014 (UTC)
No, it is. But not if the table is collapsed before the script runs (which is what we do with NavFrames now). Keφr 18:29, 29 June 2014 (UTC)
The tables should start expanded though, so that the page's contents is accessible even if JS is turned off. —CodeCat 18:36, 29 June 2014 (UTC)
Right now I believe they start "expanded", but the JS collapses them before they are even rendered, so I don't the width would be determinable at that point. --WikiTiki89 18:42, 29 June 2014 (UTC)
Right. What happens is, the rendered HTML of every page has <html lang="en" dir="ltr" class="client-nojs">, and there's some early-running JS that changes the class from client-nojs to client-js. (That's not an enwikt-specific thing; it's handled for us by MediaWiki.) In MediaWiki:Common.css, we specify that .client-js .NavFrame .NavContent should not be displayed. It's not a perfect system — it means that if a browser manages to add the .client-js, but then runs into problems handling later JS, then the user will not have any way to expand the content — but it's not obvious how it can be improved. —RuakhTALK 19:00, 29 June 2014 (UTC)
Then I guess the question is, is it so bad that the table width changes when it's collapsed? I think the current alternative, with tables that don't resize at all, is worse. —CodeCat 14:41, 30 June 2014 (UTC)

Module:la-verb[edit]

Can someone edit Module:la-verb so that the imperative headers don't show for verbs that have no imperatives (such as this one)? Esszet (talk) 00:41, 30 June 2014 (UTC)

July 2014[edit]

Loading entry data in JavaScript[edit]

I was thinking of having pregenerated entries stored somewhere on Wiktionary so that those entries could instead of being mass-uploaded by a script on demand (which is objectionable on various grounds) be generated on a mouse click on a green link like those Pinyin entries (e.g. from translation tables, also stealing pagename and a translation table gloss for a stub translation), which is much more interactive and appealing to editors. Is it feasible? We're talking about few dozen MB of textual data per language, much lower if some kind of runtime decompression binary->text is possible. Data should be stored centrally as a simple dictionary, key=lemma content=entry or, at worst, I could have it uploaded on subpages e.g. {entryname}/langcode/data, which could then be script-deleted when used. --Ivan Štambuk (talk) 10:40, 1 July 2014 (UTC)

If we could do this then why bother having "regular" entries at all? DTLHS (talk) 20:04, 1 July 2014 (UTC)
Well Wiktionary should evolve into a fancy interface for some structured storage (WikiData, what else), where every data item is properly tagged and can be independently queried by its attributes and relationships in Lua and JS. But the technology still isn't there yet...
Anyway, the simplest working solution seems to be plain ajax + storing everything in a database with CORS-enabled REST interface. --Ivan Štambuk (talk) 21:03, 1 July 2014 (UTC)

Lua error: not enough memory[edit]

At . Appears to be caused by Module:och-pron, although I'm not sure how to fix it. Wyang (talk) 12:37, 1 July 2014 (UTC)

And that, folks, is why depending on Lua for critical structure like inflection lines or even simple links is a bad idea. -- Liliana 18:22, 1 July 2014 (UTC)
No, that is why shoving 600K of data into one page on which even the syntax highlighter screams in agony is a bad idea. Loading it with mw.loadData instead of require seems to have helped, but if we do not manage this data responsibly, there is another disaster waiting to happen here. User:Wyang and User:kc_kennylau, you should follow the example of Module:languages and Module:Unicode data and split this. Keφr 19:27, 1 July 2014 (UTC)
If there is some way to group the characters, then you can split it the way we've done with Module:languages/data. --WikiTiki89 19:44, 1 July 2014 (UTC)
Well, the easiest way would be to divide it into pages of contiguous code point numbers, since the data seems to be assigned to individual characters and accessed as such. Keφr 19:51, 1 July 2014 (UTC)
That's one way, but the downside is that humans don't know the code points and thus won't be able to find the correct page. The work around is to add a JS text box to a disambiguation page, where you would type in the character and press a button and it would take you to the correct subpage. --WikiTiki89 19:55, 1 July 2014 (UTC)
Thanks! There seem to be problems with mw.loadData in Module:zh and Module:zh-usex. For example, the functions in {{zh-new}} (Pinyin, ts-conversion) relying on Module:zh no longer work, and {{zh-usex}} is not working on . @Kephir: How could this be fixed? Wyang (talk) 23:42, 1 July 2014 (UTC)
Hi guys. Just saw this conversation. I reverted Kephir's change to Module:zh as it now made things worse by causing module errors when using subst:zh-new. JamesjiaoTC 23:48, 1 July 2014 (UTC)
I was going to complain about {{zh-new}} not working (see this revision of 君主制, which failed to generate pinyin) . If Module:zh is "improved", it shouldn't break the stuff that's working. --Anatoli (обсудить/вклад) 23:51, 1 July 2014 (UTC)
Note to self: mw.loadData tables do not play well with mw.ustring.gsub. Note to User:Wyang: when you have a single character in a variable, using mw.ustring.gsub to look it up in a table is completely unnecessary. Just index the table. (There were also some arguably legitimate uses of gsub there, but I changed these.) Keφr 05:16, 2 July 2014 (UTC)
Also, User:Wyang: I noticed that in all these Chinese modules you often forget to declare variables as local. Which means they become globals, and they are not garbage-collected after they they stop being used. Which probably contributes to the memory problem. Keφr 10:10, 2 July 2014 (UTC)
OK, thanks. Wyang (talk) 23:50, 2 July 2014 (UTC)
Well, there are now 120 module errors that seem to be due to your removing a variable, but not changing all the references to it in the code. I'm not quite sure how your rewrite is supposed to work, so I can't fix it myself with my limited knowledge of Lua. Could someone correct this obvious error that's been sitting there untouched for over a most of the day? Chuck Entz (talk) 00:16, 4 July 2014 (UTC)
Eventually fixed, by Kc kennylau‎ and Wyang. Thanks! Chuck Entz (talk) 17:24, 4 July 2014 (UTC)
Hi again guys. I am not sure exactly why the Chinese pronunciation section is erroring out on . JamesjiaoTC 03:39, 3 July 2014 (UTC)
It was wrong Jyutping. Fixing now. --Anatoli (обсудить/вклад) 03:49, 3 July 2014 (UTC)

User:Wyang, I warned you about large pages causing problems, and now you upload Module:zh/data/och-pron-ZS, which is more than twice the size of the previous culprit? [[]] already fails to render. Keφr 10:59, 5 July 2014 (UTC)

Could you please demonstrate how it should be split by codepoint? I'm not sure how it should be done. What's an acceptable size for a split page? Wyang (talk) 11:06, 5 July 2014 (UTC)
When I created the Unicode character names list, I split the Unicode database into contiguous pages of 4096 (0x1000) code points each. This makes an individual page contain no more than 30K of Lua source code. My aim was having it below 50K or 100K (compare Special:Longpages), so I was rather satisfied. To access this list, I use the lookup_name function in Module:Unicode data. The most important fragment here being:
function export.lookup_name(codepoint)
	-- ...
 
	local success, data = pcall(mw.loadData,
		('Module:Unicode data/names/%03X'):format(
			math.floor(codepoint / 0x1000)
		)
	)
 
	if success then
		return data[codepoint] or ("<U-%06X>"):format(codepoint)
	else
		return ("<U-%06X>"):format(codepoint)
	end
end
where codepoint is a numeric value of the Unicode code point, which you can extract with mw.ustring.codepoint. You may even use metatables to create a proxy table which does something like that in the __index metamethod; it may save you some code rewrites, though I think they are due anyway. Just a caveat (I doubt it will be relevant here, but here it is): for the Unicode database I usually only need to get names for a handful of characters, or a contiguous block, which means I only have to load up to four or something data subpages, and usually only one. In your case, I guess accesses will be more spread out; if you keep running into out-of-memory errors, you will probably need to make pages even smaller. And do not expect it to work on a mass scale. Processing hundreds (or maybe even tens) of words in this module is rather out of the question. Keφr 11:56, 5 July 2014 (UTC)
@Kephir: Thanks for the explanation. Working now. Wyang (talk) 02:37, 7 July 2014 (UTC)

Converting WT:Information desk to monthly pages[edit]

Moved to WT:Beer parlour/2014/July#Converting WT:Information desk to monthly pages

Bare subpages as destinations for discussion section links?[edit]

Shouldn't a watchlist link to a section of a discussion page take one to a page that appears like the entire page - or at least has more orienting context for newer users rather than ultra-terse abbreviations? It now has the look of something designed by insiders for insiders, probably because that's what has happened. DCDuring TALK 11:35, 2 July 2014 (UTC)

I failed to parse the first sentence. Keφr 11:42, 2 July 2014 (UTC)
I think what he means is that in the watchlist, we should have links to Wiktionary:Beer parlour whenever any of the subpages are edited, rather than to the specific subpages. I have mixed about this. And regardless, it will be very difficult on the technical side. --WikiTiki89 13:37, 2 July 2014 (UTC)
That is what I meant. Isn't that the way it worked until recently — or did I just now notice the newish header because it was the beginning of the month? DCDuring TALK 15:34, 2 July 2014 (UTC)
No, it hasn't been like that since before we started using monthly subpages. --WikiTiki89 15:47, 2 July 2014 (UTC)
@Wikitiki89: Has it been like that continuously since we started using monthly subpages? DCDuring TALK 19:01, 2 July 2014 (UTC)
What newish header? The watchlist link points to the page that has been edited, simple as that. Changing it would be nonsensical. Half the reason for these monthly subpages is that one can open a page with a much smaller number of discussions and not overtax their browser. Keφr 16:57, 2 July 2014 (UTC)
@Kephir: The minimalist subpage header makes sense to us because we know what GP, BP, et al mean. I don't object to it as a subpage header, but I was under the impression that the link from, for example, the watchlist page went to a page that appeared the same as the page did before we had subpages. I thought that it was only on click-to-edit would we go to the subpage, via the edit box. In other words, the existence of the subpages was only apparent because users could sometimes start a discussion on the main page, which is not intended to have actual content. DCDuring TALK 19:01, 2 July 2014 (UTC)
The monthly subpages are pages like any other. Since this is where the actual discussions are located, they are added directly to the watchlist. Simple. And the inter-room navigation is a quite recent addition. Keφr 19:08, 2 July 2014 (UTC)
The only way you can see more than one month is to go to the main page for the discussion forum, such as Wiktionary:Grease pit, which has the necessary transclusions and altered edit links to create the illusion that it's all one page. The only time the main forum page shows up in your watchlist listing is when an edit has been made to that page- the software that does the watchlist has no way to know that the pages are related or linked in any way. It's true that the watchlist membership for the main pages has been extended to the subpages by fooling the system into sort of thinking they're the same page through some tricky deleting/moving/restoring maneuvers, but the links are always to the page where the actual edits have been made. This has been true ever since the subpages were implemented.
Not that it makes much difference to non-regulars, since they would normally go to the main page for the Information Desk to start with, and the doctored edit links would create the topic in the monthly page where we would want it to be. The only irregularity is when they follow the link from the watchlist- and I assume they would generally be more interested in the content they're checking out than in the details of the page name. There would be some difficulty in figuring out how to manually link to a topic from elsewhere, though. Chuck Entz (talk) 01:37, 3 July 2014 (UTC)
So I just hadn't noticed before, because the top of the subpage was not visible to me either because it was above the section of interest or because I was "more interested in the content" and didn't notice. And, in any event, there's no currently known way to make the subpage architecture completely invisible at the beginning of the month, such as by substituting a link to the main page presentation for the link to the subpage. I suppose there would be a way, but it doesn't seem worth the apparently substantial trouble. DCDuring TALK 01:53, 3 July 2014 (UTC)

Template:t-check and Template:t-needed[edit]

Previously: Wiktionary:Beer parlour/2014/January#Proposal to change how translation checks and requests are formatted

Some time ago WT:EDIT has been edited to use {{t-needed}} instead of {{trreq}}, while keeping compatibility with the latter. Likewise, xte has been changed to mark suspicious translations with {{t-check}} instead of marking the language header with {{ttbc}}. No problems have arisen since then. Shall we migrate {{ttbc}} and {{trreq}} to the new format? Keφr 13:51, 3 July 2014 (UTC)

I support doing this by orphaning the old templates and replacing them with the new ones. But we would need to look at the entries in Category:Language code is name, as the replacement would mean using "und" as the language code for these translations. —CodeCat 15:51, 3 July 2014 (UTC)
I've managed to fix about a third of the things in Category:Language code is name/ttbc/unrecognised. The things in Category:Language code is name/trreq look like they can be bot fixed without difficulty. Hopefully nothing, or very few things, will have to use "und" as the language code. - -sche (discuss) 04:20, 7 July 2014 (UTC)
Support. This will fix the issue where the translation-adder (WT:EDIT) breaks down if you try to add a translation and it falls in alphabetical order next to a ttbc, right? - -sche (discuss) 04:20, 7 July 2014 (UTC)
Oh, that has been fixed already. The main issue here is more straightforward markup: only the thing that actually needs checking is denoted as such, and the markup for the "translation request" case corresponds a bit more intuitively to the rendered text. I think even DP should be okay with this (jugding from his last reply here; though you never know). Starting up my bot. Keφr 07:43, 7 July 2014 (UTC)
{{trreq}} has been orphaned. {{ttbc}} will take a bit longer, though. Keφr 18:47, 7 July 2014 (UTC)
More than half of {{ttbc}} transclusions have been converted. The task is somewhat tricky though, and some items will probably have to be dealt with manually. Keφr 07:47, 9 July 2014 (UTC)

Linkrot in IP Contributions Page Footer[edit]

Someone earlier fixed the footer displayed at Special:Contributions for regular accounts, but there's a different footer for IPs, which is showing the effects of the Toolserver phaseout. Could someone fix it, please? Chuck Entz (talk) 17:33, 4 July 2014 (UTC)

{{anontools}}. Keφr 18:58, 4 July 2014 (UTC)

Rhymes adder doesn't set lang parameter[edit]

I notice that the rhymes adder (the "add new rhyme" function accessed via rhymes pages like Rhymes:English:-ɪpsi) does not specify lang=. I believe a bot goes around and adds lang= to entries which it notices are missing it, but this seems like working harder not smarter. Couldn't we simply adapt the rhyme-adding code to pull the language from the title of the page the rhyme is added via (Rhymes:English:-ɪpsi)? - -sche (discuss) 18:27, 4 July 2014 (UTC)

Worse yet, the "add new rhyme" function, which is not supposed to add the rhyme to the entry page if it's already present, does add the rhyme to the entry page if the entry page uses {{rhymes|lang=en}} as opposed to {{rhymes}} alone. In other words, if I add tipsy to Rhymes:English:-ɪpsi using the "Add new rhyme" button, then if tipsy already has {{rhymes|ɪpsi|lang=en}} on it, {{rhymes|ɪpsi}} will be unnecessarily added to the page (though the page is left untouched if {{rhymes|ɪpsi}} is already present). —Aɴɢʀ (talk) 19:01, 4 July 2014 (UTC)
I tried to make some minor adjustments to User:Yair rand/rhymesedit.js, but I don't know if that fixed it. Please test it. —CodeCat 19:17, 4 July 2014 (UTC)
It seems to work. It doesn't add a new "rhymes" line to a page if one is already present, regardless of whether or not the pre-existing "rhymes" line has lang= set. And it does add a "rhymes" line to a page if one doesn't already exist. - -sche (discuss) 01:40, 7 July 2014 (UTC)

template:suffix and Hebrew hyphens[edit]

{{suffix|lang=he|בֵּן|וֹ|tr1=ben|tr2=o}} generates:

<i class="Hebr mention" lang="he">[[בן#Hebrew|בֵּן]]</i> (<span lang="" class="tr mention-tr">ben</span>) +&lrm; <i class="Hebr mention" lang="he">[[־ו#Hebrew|־וֹ]]</i> (<span lang="" class="tr mention-tr">־o</span>)

Note that the character before the suffixed o is U+05BE. This is an error: it should have the standard hyphen-minus character. (It is correct, however, to have U+05BE before the וֹ and the ו, as above.) I'd fix it, but don't know how to edit the module to do so. Can someone please? Note also that the other functions in the same module may need similar adjustment.​—msh210 (talk) 05:49, 6 July 2014 (UTC)

Why is the normal hyphen correct in this case, but not in some other cases? —CodeCat 10:32, 6 July 2014 (UTC)
Because it's part of the English-transliteration string -o, not a Hebrew-language Hebrew-script string.​—msh210 (talk) 23:42, 6 July 2014 (UTC)
I think I understand. What you're saying is that the hyphen should be transliterated too? —CodeCat 00:01, 7 July 2014 (UTC)
Yes, from U+05BE to a hyphen-minus character. That's the way the template used to work. (Note also that the current way displays terribly.)​—msh210 (talk) 02:50, 7 July 2014 (UTC)

{{look}}Can someone please do this? As mentioned, the templates displays badly now (at e.g. [[בנו]]). Pinging CodeCat: you're the one who converted the template to use the module, and you're the one who's done most of the editing of the module. You should test when you write code that's to be used live (and perhaps you did), but at the very least should fix a bug when informed of it.​—msh210 (talk) 16:21, 9 July 2014 (UTC)

Yes check.svg Done (diff). The bug was introduced by User:Kc kennylau in this edit. --WikiTiki89 16:57, 9 July 2014 (UTC)
Thank you! And my apology to CodeCat for the above tirade. Striking this section and nowikiing the look template.​—msh210 (talk) 20:46, 10 July 2014 (UTC)

Chinese interwiki warnings[edit]

I oppose Chinese interwiki warnings as with 赫茲, which is a traditional form of 赫兹. Traditional and simplified forms in Chinese are considered the same word. Even if the Chinese Wiktionary may only use one form (simplified forms are more common), a traditional form will redirect to simplified and a traditional form may be for a Japanese term. Missing interwikis will not allow users to look up terms on sister projects. It's just the way Chinese wiki works. So, please make an exception for Chinese interwikis, which is also made for translations into Chinese (i.e. use of {{t+}} when only the other form exists). --Anatoli (обсудить/вклад) 23:27, 6 July 2014 (UTC)

I gather you added [[zh:赫兹]] as an interwiki to 赫茲, and were warned by the filter that discourages people from adding interwikis to non-identical pagetitles. I don't know that there's a feasible way for the filter to recognize and make exceptions for trad—simp pairs without allowing other things that aren't desirable (e.g. vandalistic addition of links to zh:暴君 to , or additions of translations as interwikis). And even if there were a way to make the filter make such exceptions, the bots which maintain our interwiki links remove links that aren't to the same pagetitle, so the links would still get removed, unless all of the bots were also updated with the massive list of allowable trad—simp correspondences... all of which is asking a bit much. I say the onus is on zh.Wikt to make use of redirects from the trad forms to the simp forms, or vice versa (whichever set of forms they centralize the content on), so that we can have interwiki links to those redirect pages, so that users get to the content in the end. We ourselves already make use of redirects like this to accommodate such things as fr.Wikt's use of curly apostrophes (and fr.Wikt reciprocally makes use of redirects to accommodate our use of straight apostrophes). - -sche (discuss) 01:34, 7 July 2014 (UTC)
Yes, it was [[zh:赫兹]] as an interwiki to 赫茲. That would be a pity if the interwiki were removed by a bot. I don't know how Chinese redirects work (or searches) but [[zh:赫兹]] would/should match an existing Chinese redirect, even if it redirects to [[zh:赫兹]] (a simplified form). --Anatoli (обсудить/вклад) 01:49, 7 July 2014 (UTC)
There are various forms of phrases on enwikt, some of which hard redirect and others of which soft redirect. Same for things like color and colour. There are various (plene and defective) spellings of Hebrew words, where hewikt and enwikt have different entries; enwikt soft-redirects between them and hewikt hard-redirects. We handle all of these the same way: we interwiki only between the exact titles, and let the redirects work. (As -sche pretty much has stated.) I don't see justification in the above discussion for making an exception for Chinese. (I'm not saying no such justification exists: I don't know. But it hasn't been voiced here yet AFAICT.)​—msh210 (talk) 02:54, 7 July 2014 (UTC)
Just to clarify that our English wiki entry 赫茲 has an interwiki to the same title [[zh:赫茲]] on the Chinese Wiktionary. The redirect is handled on the Chinese side. The justification, if one is needed, is that Chinese and English wiktionary shows both trad. and simpl. forms on each form but the Chinese Wiktionary usually has only one, e.g. simplified zh:赫兹], which displays (or supposed to) both forms and has all linguistic info there. I see no problems in having interwikis to redirects, same with French, Hebrew, etc. --Anatoli (обсудить/вклад) 04:09, 7 July 2014 (UTC)

Indentation and RQ templates[edit]

I have just now discovered that when an RQ template is used in a line starting with ##* then the extra indentation doesn't happen. For example, when this is used for a second level quotation, it actually takes the displayed text back to the first level as far as numbering is concerned. Would someone with the necessary skills please fix this.—ReidAA (talk) 05:47, 7 July 2014 (UTC)

This request doesn't seem have attracted any attention. Maybe I should give an example. So:

  1. This is a sense.
    1. This is a second level sense.
      • This is a simple second level quote.
      • So is this.
      • 1960, P. G. Wodehouse, Jeeves in the Offing, chapter V:
        This should be a second level quote with an RQ template.
      • This is a simple second level quote (should be an unnumbered quote of the second level sense).
      • So is this.

I hope this makes the problem clearer—ReidAA (talk) 08:45, 8 July 2014 (UTC)
Hmm, compare this:

  1. This is a sense.
    1. This is a second level sense.

The difference is that {{RQ:Wodehouse Offing}} uses {{quote-book}}, so that seems to be where the/a problem lies. I vaguely recall problems with indentation being noticed in the past. Pinging User:Robin Lionheart who's edited the template heavily in the past, and User:Visviva who fixed the previous problem with indentation, in case they know how to fix it. - -sche (discuss) 19:27, 8 July 2014 (UTC)

Thanks very much for your response! Of course, the problem doesn't seem to be simply with the {{quote-book}}:

  1. This is a sense.
    • This is a simple quote.
    • So is this.
    • 1066, William, I came:
      This is a quote with a quote-book template.
    • This is a simple quote.
    1. This is a second level sense.
      • This is a simple second level quote.
      • So is this.
      • 1066, William, I came:
        This is a second-level quote with the same template.
      • This is a simple second level quote.
      • So is this.

That's probably why the problem hasn't been cleaned out already. I hope User:Robin Lionheart will be able to fix it.—ReidAA (talk) 22:28, 8 July 2014 (UTC)   Or User:Visviva (sorry; I overlooked him/her, though I now see that the single message on User:Visviva suggests (s)he has become inactive).—ReidAA (talk) 03:08, 9 July 2014 (UTC)

Trying out Template:wgping: (pinging: Keφr, Yair rand, CodeCat, Ruakh, Kenny, ZxxZxxZ from workgroup technical). - -sche (discuss) 02:11, 13 July 2014 (UTC)
It's fixed !! Great !!!! Many thanks to whoever managed it. Maybe this item (and the related one in the Information Desk) should now be crossed out, if someone who knows how could do that, please. — ReidAA (talk) 09:55, 13 July 2014 (UTC)
'Twas Kephir who fixed it, with diff. I just checked, and as of the last database dump, Template:RQ:Wodehouse Offing is the only RQ template that used an explicit "#*". Who knows why it did. - -sche (discuss) 16:39, 13 July 2014 (UTC)

The new lemmas that are popping up.[edit]

I'm actually in favour of them, and the way to get a word on the list for the respective language seems to be to update the entry. However it doesn't seem to work with some entries with outdated headings, so the only way to cure that seems to be to rewrite them, altering them to {{head|nb| or whatever. I did this with linje, and it's now on the lemma list. On the other hand, I didn't do it with stoff (Bokmål) and stoff (Nynorsk), and it hasn't appeared on the lemma list. Both entries' headings will have to be updated, and the same may be true with entries in other languages. Donnanz (talk) 18:19, 8 July 2014 (UTC)

I'm a bit confused about the edit you made. Why didn't you update the template instead? In the discussion you had with me you mentioned replacing form-of templates with others because of not displaying the correct text, rather than fixing the templates themselves. I wonder, is there something you have in principle against fixing templates, and instead prefer to work around using them in strange ways? (I don't mean this as any kind of attack, I just don't understand your thought process here) —CodeCat 18:40, 8 July 2014 (UTC)
Which edit are you referring to - linje or stoff? Donnanz (talk) 18:44, 8 July 2014 (UTC)
linje. You replaced the normal Norwegian headword template - which should presumably be used on all applicable entries - with a rather large and unwieldy call to {{head}}. —CodeCat 18:47, 8 July 2014 (UTC)
I agree with CodeCat. Why didn't you just fix the template or ask someone else to fix the template? Clearly that would be a much cleaner and easier solution than just throwing the template away because one thing in it is broken. --WikiTiki89 18:48, 8 July 2014 (UTC)
  • OK. I am highlighting a problem, and I get shot down in flames about templates. If templates need fixing, someone will have to do it. I don't regard it as my job. Donnanz (talk) 18:56, 8 July 2014 (UTC)
    We didn't say it was your job. You could have highlighted the problem without making the destructive edit to linje. --WikiTiki89 18:58, 8 July 2014 (UTC)
    The edit was hardly destructive. It works rather well. As for the template used for stoff, you can sort that out. Donnanz (talk) 19:04, 8 July 2014 (UTC)
    Obviously it works well, but it defeats the purpose of having templates if we're gonna go write everything out anyway. --WikiTiki89 19:21, 8 July 2014 (UTC)
    If a template acts incorrectly or in an undesired way, it is altogether fitting and proper to avoid using it (using plain wikitext or a more general template like template:head instead). That is, in fact, far better than using the incorrectly acting template. Our primary concern should be how pages look to our readers, not uniformity of template use. This case is less crucial, as the template merely lacked a feature rather than acting truly badly, but the same principle applies, if to a lesser extent. Certainly, one should also bring the incorrectly acting template to the attention of someone who can fix it — and that's what Donnanz did.​—msh210 (talk) 16:29, 9 July 2014 (UTC)
    In this particular case, everything was displaying fine except that the new lemma category wasn't being added. --WikiTiki89 16:47, 9 July 2014 (UTC)
  • By the way, whoever is creating the lemmas needs to add an ABC index at the top. Donnanz (talk) 19:08, 8 July 2014 (UTC)
    No one is creating them. They get added whenever a page is purged, thus updating the templates on it. Anyway, I think the ABC index is automatically added when there are enough entries in the category. --WikiTiki89 19:21, 8 July 2014 (UTC)
    OK, if not, I have added ABC indexes before, though I'm looking for an ABC template specific to the Danish and Norwegian alphabets, i.e. including Æ, Å and Ø. Donnanz (talk) 19:36, 8 July 2014 (UTC)
    The rules for automatically adding indexes are in Module:category tree (at the bottom), and they're more or less as follows. If the category contains more than 2500 items, and a template called "xx-categoryTOC/full" exists, use that. Otherwise, if the category contains more than 200 items, and a template called "xx-categoryTOC" exists, use that. Otherwise, show nothing. This only applies to categories for a specific language, so "by language" categories never get an automatic index. This will probably be added at some point, though. —CodeCat 19:59, 8 July 2014 (UTC)
    I will try to make some sense out of that, if not, I may have to call on your services. These lemma files could grow to a massive size, as they contain all nouns, adjectives, verbs etc., in other words everything except noun forms etc. Donnanz (talk) 20:44, 8 July 2014 (UTC)
    Yes, they would basically contain a list of all the entries that can be found in a paper dictionary. That's also why it's useful, though. —CodeCat 20:52, 8 July 2014 (UTC)
    To translate that to something more useful, Danish categories get indexes because Template:da-categoryTOC exists. Norwegian Bokmål ones do not because Template:nb-categoryTOC does not exist. --WikiTiki89 02:07, 9 July 2014 (UTC)
    Thanks for finding the Danish template. Can you create the nb template, and could it be used for nn as well, or would that require yet another template? (nb/nn would be the same as the Danish one) Donnanz (talk) 07:10, 9 July 2014 (UTC)
    Can you? You know more about Norwegian than I do and you can use the Danish one as a starting point. For Nynorsk, you would have to also create Template:nn-categoryTOC (I thought that would have been obvious...). --WikiTiki89 13:43, 9 July 2014 (UTC)
    At the very least, just give me a list of the letters in the desired order and I will create the templates for you. --WikiTiki89 13:44, 9 July 2014 (UTC)
    The Danish and Norwegian alphabets are exactly the same, and have exactly the same letter order. The Danish template alphabetical order is correct, so it can be adapted without change for nb and nn. I did confirm this in the Norwegian Wikipedia (Det danske-norske alfabetet). Donnanz (talk) 14:41, 9 July 2014 (UTC)
    In that case, all you need to do is copy the code in the Danish template into the Norwegian templates, changing only the name of the category at the bottom. But if you are really that afraid to do it yourself, then ask and I'll do it for you (but I will be disappointed). --WikiTiki89 14:52, 9 July 2014 (UTC)
    You're calling my bluff, huh? OK, I've created Template:nb-categoryTOC. You had better check it before I do nn. Donnanz (talk) 17:58, 9 July 2014 (UTC)
    Looks fine! --WikiTiki89 19:27, 9 July 2014 (UTC)
  • Template:nn-categoryTOC is now done, but now I have discovered another little problem. All da, nb and nn files are sorted incorrectly as Å Æ Ø instead of the correct order of Æ Ø Å. This may have occurred years ago. Donnanz (talk) 21:46, 9 July 2014 (UTC)
    We're not able to fix that unfortunately. The software is limited to sorting by Unicode codepoint order. —CodeCat 21:47, 9 July 2014 (UTC)
    Oh I see. I guess we'll have to live with that problem. Donnanz (talk) 21:57, 9 July 2014 (UTC)

add a word[edit]

Noticed Wiktionary doesn't have the words kevlar or xray......Just to name a couple... New here...don't know how to add...

kevlarKevlar
x-rayX-ray
--Catsidhe (verba, facta) 04:25, 10 July 2014 (UTC)

Template with raw link[edit]

Category:Template with raw link/ga-noun contains over 1500 entries, and as far as I can tell, there's nothing wrong with any of them. Template:ga-noun includes the following code:

{{#if:{{isValidPageName|{{{1}}}}}||[[Category:Template with raw link/ga-noun]]}}
{{#if:{{isValidPageName|{{{2}}}}}||[[Category:Template with raw link/ga-noun]]}}

Now Template:isValidPageName says it's deprecated and will soon be deleted and should be removed. Can I simply delete the two above lines of code from {{ga-noun}} without breaking anything? —Aɴɢʀ (talk) 16:12, 13 July 2014 (UTC)

I think it's done via a module now, which may or may not be Module:links. I think it (isValidPageName) needs to be replaced not removed. Renard Migrant (talk) 16:27, 13 July 2014 (UTC)
The template is fine, but there was a bug in the code you pasted above. I fixed it now, and it looks like the category is emptying out slowly. —CodeCat 16:35, 13 July 2014 (UTC)

Template:quote-web[edit]

This template breaks the numbering of definitions and doesn't play well with quote-hiding. See rape culture and "what links here" for instances. DCDuring TALK 22:20, 13 July 2014 (UTC)

Probably because of the explicit "#*" it contains (compare Wiktionary:Grease pit/2014/July#Indentation_and_RQ_templates). - -sche (discuss) 00:13, 14 July 2014 (UTC)
Now it works, though there has been no net change in the template. Changes not in the template seem to be the cause. I miss the days when sometimes folks would own up to having caused this kind of thing. DCDuring TALK 00:48, 14 July 2014 (UTC)
Apparently the problem was a glitch in a tidying of {{cite meta}} that was done earlier today. DCDuring TALK 00:53, 14 July 2014 (UTC)

Template:wikimedia language name seems incomplete[edit]

Hi,

{{wikimedia language name|nrm}} should return "Norman" according to Wiktionary:Wikimedia language codes, isn't it? (Current result: "Narom") — Automatik (talk) 01:13, 14 July 2014 (UTC)

(general questions, not specifically for Automatik:) What is the difference between Template:wikimedia language and Template:wikimedia language name? Template:wikimedia language contains some things that Template:wikimedia language name and Wiktionary:Wikimedia language codes don't; do the latter need to be updated? - -sche (discuss) 01:34, 14 July 2014 (UTC)
For the first question: it seems {{wikimedia language name}} take a code and returns a language name whereas {{wikimedia language}} take a code and returns a wikimedia code. — Automatik (talk) 12:50, 21 July 2014 (UTC)

"Show-hide" boxes that are full width[edit]

I have noticed that we have templates that insist on occupying the full width of the frame whether or not they need to. This has the effect of forcing white space to appear when there are right-hand side elements, especially images. An offending template that I noticed today is {{hy-noun-ի-եր}} as used in [[սեխ]].

What is the cause? What is the remedy? How can I help apply the remedy? DCDuring TALK 12:58, 20 July 2014 (UTC)

What white space? I see no white space. --Vahag (talk) 22:20, 20 July 2014 (UTC)
See screenshot at Talk:սեխ. DCDuring TALK 22:49, 20 July 2014 (UTC)
I don't think the boxes are forcing anything- if they weren't there, the right-hand elements would be in exactly the same position relative to the left side of the screen, with the same amount of white space. The boxes simply fill the available space- with the size of the available space being determined by other elements on the page. Chuck Entz (talk) 00:23, 21 July 2014 (UTC)
I think he means the whitespace between the ===Declension=== heading and the declension table. --WikiTiki89 00:27, 21 July 2014 (UTC)
Thank you. Yes.
Also, the Old Armenian declension template on the same page didn't seem to have the same problem when I inserted an image. It simply rendered a narrower declension table, leaving room for the image. DCDuring TALK 00:31, 21 July 2014 (UTC)
Perhaps it has something to do with the right-hand TOC, which is pushing the other right-hand elements down the page: perhaps the Javascript that's moving the TOC box is running after the code that sizes the collapsible box. Chuck Entz (talk) 00:39, 21 July 2014 (UTC)
@Chuck Entz: That's a good hypothesis, so I tested using {{tocright}} at User:DCDuring/Sandbox. {{rel-top}} behaves the way I think a well-behaved show-hide template should, despite the rhs ToC. DCDuring TALK 01:40, 21 July 2014 (UTC)
You have a point. In preview mode, I just moved the declension template up to where the dialect alternative forms box is, and it refused to share horizontal space with the image in the same place where the {{rel-top}}-based box behaved correctly. The declension template does, indeed, behave differently. Chuck Entz (talk) 03:35, 21 July 2014 (UTC)
I'm guessing that it's CSS, but almost anyone has a better idea about this kind of thing than I do. DCDuring TALK 04:55, 21 July 2014 (UTC)
It looks like <div class="NavFrame" style="width:100%"> in {{hy-decl-noun}} is the culprit. I created {{hy-decl-noun-test}} without the style parameter, and {{hy-noun-ի-եր-test}} to use it in the entry. The box behaves nicely when collapsed, but has an annoying way of overlapping with the Wikipedia box when you uncollapse it. Even worse, the Wikipedia box displays on top of the declension table, which could hide some of the content. I'm sure that's why the difference is there. Chuck Entz (talk) 05:42, 21 July 2014 (UTC)
I took the liberty of changing {{hy-decl-noun}}. Please revert if it misbehaves. DCDuring TALK 11:51, 21 July 2014 (UTC)
OK, but why this? --Vahag (talk) 12:16, 21 July 2014 (UTC)
Sorry. That was a quick test that I thought was only in preview mode and not saved. DCDuring TALK 14:32, 21 July 2014 (UTC)
  • Am I correct that if a template intended for use in an entry uses NavFrame directly or indirectly and NavFrame width is "too wide", eg, 100%, then it does not play well with images, project-link boxes, and right-hand side tables of content? DCDuring TALK 20:32, 21 July 2014 (UTC)

POS TOC[edit]

I notice that the TOC for categories with a shitton of pages has aa, ab, ac, etc, and it has æ and œ, but it doesn't have 1, 2, 3, 4, 5, 6, 7, 8, 9 and 0, even though some POSes have hundreds of entries that start with those. Where does one go to fix this? Purplebackpack89 21:45, 21 July 2014 (UTC)

The answer is actually above in #The new lemmas that are popping up. But to save you some reading time, each language has its own TOC. The English one is: Template:en-categoryTOC for smaller categories and Template:en-categoryTOC/full for large categories. --WikiTiki89 22:45, 21 July 2014 (UTC)
I have added 0-9 for Template:en-categoryTOC/full and the 10th, 11th and 12th parameters to Template:Cattoc Purplebackpack89 23:02, 21 July 2014 (UTC)

User page filter[edit]

Seriously. Whenever I try to edit anyone else's user page, the filter always says my edit was unconstructive, even if the edit actually was clearly not vandalism or anything and was trying to help. I think we should get rid of this dumb filter, because the filter is getting on my last nerve. I can't even edit the user pages of my own backup accounts unless I log into those accounts.

If we don't want people editing other people's user pages, we should just protect everyone elses' user pages from ability to edit. I believe Pikipedia, the Pikmin Wiki website, has already found a way to do this, since they apparently don't want people editing user pages there that aren't your own.

So here are some suggestions:

  1. Make it clear that there is a rule about editing other users' user pages somewhere in Wiktionary's namespace.
  2. Lock all user pages from others so that others can't edit them, instead of using a filter, if we don't want people editing user pages.
  3. Let's just forget the entire idea of restricting edits on user pages and get rid of the filter altogether and let people freely edit user pages, as this is a "free, collaborative dictionary". Rædi Stædi Yæti {-skriv til mig-} 23:32, 22 July 2014 (UTC)
You hit this filter like, four times and you are already bloodthirsty? Chill, mate.
Previous discussions:
Anyway, since nearly all (if not all) vandalism hits for this filter have been from IPs and brand-new accounts, I have lowered the rights threshold to confirmed. Keφr 08:50, 25 July 2014 (UTC)

cmn user templates playing up[edit]

User:Ready Steady Yeti advised me that Babel with {{User cmn-3}} now displays two cmn, before it was showing a red link, even if the template existed. Not sure what's happening there. --Anatoli T. (обсудить/вклад) 23:40, 22 July 2014 (UTC)

What happened in my eyes was that the template zh-3 was before missing on Anatoli's user page as a red link, but either when someone pressed the save page button on Anatoli's user page, or the template was recreated somehow, the template now redirects to cmn-3, furthermore making his babel repeat the "cmn-3" box twice. Rædi Stædi Yæti {-skriv til mig-} 23:47, 22 July 2014 (UTC)
Just edit {{User zh-3}} if you don't want it to redirect to cmn. DTLHS (talk) 00:02, 23 July 2014 (UTC)
Thanks, done. Recreated Category:User zh. --Anatoli T. (обсудить/вклад) 00:13, 23 July 2014 (UTC)

Edit filter to prevent bad sh L2's[edit]

Can we add a filter to disallow "Serbian", "Croatian" and "Bosnian" as L2s? Chuck Entz (talk) 14:04, 24 July 2014 (UTC)

There is one already: "THL". It only tags for now, but that can be changed. If you are going to flip the switch, I suggest adding an explanatory warning too. Keφr 14:11, 24 July 2014 (UTC)

Updating legacy scripts[edit]

(pinging: Keφr, Yair rand, CodeCat, Ruakh, Kenny, ZxxZxxZ from workgroup tech)

For a quite a bit of time, I have been drafting plans to modernise JavaScript modules on Wiktionary; deprecate loads of shabby code and replace them with something faster, more modern and reliable; turn scripts scattered around people's user space into proper gadgets. The plans have grown quite ambitious, and I will most probably not carry them out at once, nor in the nearest future, and I hope not alone. But to make some preparations at least, I came up with an idea to move most of our scripts from MediaWiki:Common.js into a separate gadget, enabled by default, which individual editors could then turn off. The rationale being that it would aid in developing the replacements in a more "vanilla" environment, avoiding interference between the new and old scripts.

But truth is, I am not sure what would be the side effects of that. Scripts could run faster or slower, race conditions may start appearing which we have not noticed before, we might get missing symbols (like newNode some time ago), older browsers may stop working. So, this is a bit risky. Shall I go with it? Keφr 13:25, 25 July 2014 (UTC)

I think some temporary minor problems are worth the risk, and I think you are competent enough to handle it. —CodeCat 13:26, 25 July 2014 (UTC)
I performed the move. Nothing seems to break yet. It even feels a bit faster, but I am not sure if this is ResourceLoader magic, or just a perception.
I left in only three enhancements: "add section" link redirection, &withmodule= query parameter and WT:Preferences/V2, my intended replacement for WT:PREFS (whose preference page you can test without logging out by using the aforementioned &withmodule=). Disabling the "legacy scripts" gadget now will break collapsible inflection tables, so I do no recommend doing that. Unless you want to develop a replacement script for that — which I am planning to do, but I am not so sure if I will fulfil this plan. Keφr 15:36, 26 July 2014 (UTC)
As for the collapsible inflection tables, see also mw:MediaWiki:Gadget-collapsibleTables.js, which is now rasonably similar to the one used on English Wikipedia, and consider using the default jQuery.makeCollapsible plugin instead of a local implementation. Helder.wiki 13:49, 27 July 2014 (UTC)
Thanks, but I think we will have to keep around a custom "collapsibles" script anyway; we also have collapsible quotations, which cannot be made so merely by slapping a CSS class on them. Keφr 15:07, 27 July 2014 (UTC)

After editing a page with duplicate headings[edit]

Page 'all' has three 'Translations'. After editing #Translations_2, clicking 'Save page' went to #Translations, not #Translations_2. History entry '→‎Translations' also linked to #Translations. (JS disabled.) Jisok (talk) 03:29, 27 July 2014 (UTC)

That always happens. If you edit a "Noun" section in one language, and there's another "Noun" section for another language higher up the page, when you click "Save" you'll be taken to the highest "Noun" section on the page, even if it's not the one you just edited. It's a little annoying, but not really bad, since the correct section was edited. —Aɴɢʀ (talk) 07:05, 27 July 2014 (UTC)

Gothic declension templates are acting out[edit]

Some or all of the Gothic noun inflection-table templates are causing the entries where they're transcluded to be categorized into Category:Terms with manual transliterations different from the automated ones/got. Not sure why, or how to fix it. —Aɴɢʀ (talk) 12:25, 27 July 2014 (UTC)

It's because the Gothic headword line templates add a link to the transliteration. You can ignore it though. —CodeCat 12:38, 27 July 2014 (UTC)
Of course you can ignore it, but it makes the cleanup category useless, since you can no longer use it to find terms that genuinely need cleaning up. —Aɴɢʀ (talk) 14:32, 27 July 2014 (UTC)
All the entries that can be ignored are in Gothic script though, so it's not that much of a problem to sift them out. —CodeCat 14:35, 27 July 2014 (UTC)

Update to xte[edit]

I have updated the list of pages at User:Kephir/t.love. It has not changed much since the last Buttermilch run. Unfortunately, I cannot see much pattern in the current dumps, which means that the remaining translations will have to be dealt with manually. Many of them use some bizarre hybrid markup - half of the translation is inside {{t}}, the other half is not. Or a two-word SOP translation with each word under {{t}}.

But the good news is, xte has been updated to deal with this case too. It has to be noted that these cases have to be reviewed more carefully than usual. So if you feel sad and lonely and in need of filling your time with an utterly brain-dead activity, here is your chance. Open one of the subpages of User:Kephir/t.love, load it into the xte basket (xte menu → "Add links on this page"), Alt-Shift-], Alt-Shift-\, review, Alt-Shift-s, Alt-Shift-], Alt-Shift-\, review, Alt-Shift-s, Alt-Shift-], Alt-Shift-\, review, Alt-Shift-s…

Keφr 15:41, 28 July 2014 (UTC)

What would Freud say about "have to be death with"? —Aɴɢʀ (talk) 16:20, 28 July 2014 (UTC)
"A sure sign of deeply repressed homosexual urges", of course. Either that, or "indication of unconscious lust for the poster's mother". Or both. Keφr 17:43, 28 July 2014 (UTC)

Category TOCs, collapsible rows in a table?[edit]

I noticed that with the new lemma categories, some of them take a long time to load. I found the culprit, and it's the line I commented out here. The mw.site.stats.pagesInCategory function is very slow; it make the page take up to 4 seconds for Category:English lemmas, compared to 0.1 seconds with the code commented out.

This code is used to determine whether to display an alphabetic index ("table of contents" is a rather bad name for these) like {{en-categoryTOC}} or {{en-categoryTOC/full}}, and which one to display depending on how large the category is. I don't think there is much doubt that we should get rid of mw.site.stats.pagesInCategory, but it means that we would have to show the index template regardless of how many entries are in a category, and we can only have one of them, rather than the current standard one and longer one, as there is no way for the module to determine which to use (because it can no longer count entries).

So I'm wondering if we could use the longer version as the base, but make the extended part collapsible. By default it would show only the basic alphabet, but clicking the expand button would show the rest. Is this possible, and if so, how? —CodeCat 19:53, 28 July 2014 (UTC)

Before we do that, is there any faster way to determine the size or approximate size of a category? (Also note that mw:Extension:Scribunto/Lua reference manual#mw.site.stats.pagesInCategory mentions that this function is expensive.) --WikiTiki89 20:01, 28 July 2014 (UTC)
I don't think so. That function is the only one available in Scribunto for counting in categories. It's the Lua equivalent of the magic word {{PAGESINCATEGORY:(name)}}, which is also expensive. This magic word is what {{catboiler/toc}} used before it was converted. —CodeCat 20:07, 28 July 2014 (UTC)
I can see why it would be expensive to count the exact current number of entries, but it seems like it would be pretty easy to add a cached size to categories that may not always be current, but would be good enough for determining the type of TOC. But I doubt we'd be able to convince the developers to do that. On the other hand, does it really matter that it is so slow? The only time it runs is when updating/purging the category page. --WikiTiki89 20:13, 28 July 2014 (UTC)
It's actually so slow that it has caused timeouts on a few occasions. And it's also slow just to view the page, by any user. Is the minor convenience of changing the TOC really worth a 40 fold increase of load time? Especially when there are alternatives? —CodeCat 20:21, 28 July 2014 (UTC)
No it's not worth it. But why does it affect page load time? --WikiTiki89 20:25, 28 July 2014 (UTC)
I'm not sure but I think that caching works differently for content generated through templates/modules. I've noticed before that loading a page with a slow template/module, and then loading it again, gives intermittent results. —CodeCat 20:33, 28 July 2014 (UTC)
CodeCat's idea seems promising, minimizing the loss of content space on the visible landing page while speeding page loading. I hope that it actually works as intended. The big (eg, 40x) benefit would be limited to really large categories, not those with mere thousands of members.
But where does the N come form in "The following 200 pages are in this category, out of N total." DCDuring TALK 20:25, 28 July 2014 (UTC)
I think that number is probably cached. Why templates and scripts don't use that cache, I'm not sure. But that's not really something we can change anyway. And yes you're right, the benefit would be less for smaller categories. But those are the ones that don't need those big index tables anyway. —CodeCat 20:33, 28 July 2014 (UTC)
Maybe it's all cached, but the cache gets invalidated often for big categories, like "English lemmas". I suppose it wouldn't be updated incrementally, but recomputed from scratch.
The only loss is a tiny (I hope) loss in content-available screen space, which can be annoying for really small (ie, one-page) categories. IOW, please make the index the smallest horizontal format that you can. DCDuring TALK 21:17, 28 July 2014 (UTC)
I'll try, but right now the question is how to make it partly collapsible. —CodeCat 21:19, 28 July 2014 (UTC)
Here's what I think: All category members must be found when updating the Category's cache, so the number of members is available at that time for use in the 200 of N. However, the {{PAGESINCATEGORY:(name)}} and mw.site.stats.pagesInCategory are meant to find the number of members of any category when loading any page, and thus does not take advantage of this when counting the members of the current category being loaded. There are things the devs could do (if we can convince them): either make {{PAGESINCATEGORY:(name)}} and mw.site.stats.pagesInCategory run faster when requesting the category from the category page itself or create a new function that does only this and works only from the category's own page. --WikiTiki89 21:26, 28 July 2014 (UTC)
(pinging: Keφr, Yair rand from workgroup JS) Can you help out? —CodeCat 22:37, 28 July 2014 (UTC)

Sanskrit transliteration[edit]

Why is Sanskrit no longer automatically transliterated by {{l}}, {{m}}, and {{t}}? —Aɴɢʀ (talk) 20:23, 28 July 2014 (UTC)

This edit did it. I have no idea why Ivan did that though. —CodeCat 20:36, 28 July 2014 (UTC)
The module overrides the more accurate transcription in IAST so I turned it off. It was a dumb idea to have it in the first place. --Ivan Štambuk (talk) 20:45, 28 July 2014 (UTC)
But the module generated the IAST transcription; how is the user-written one more accurate? Anyway, I've been removing Sanskrit transliterations left, right, and center for several weeks now because they were being generated automatically, and now all those forms are left without any translit at all. Couldn't manual translits override the automatic translits, but automatic translits still appear when no manual is provided? That would at least be better than no translit at all when there's no manual one, which is what we have now. —Aɴɢʀ (talk) 21:05, 28 July 2014 (UTC)
Automatic transliterations don't have stress marks, but that's the only problem I can think of. —CodeCat 21:18, 28 July 2014 (UTC)
Of course they could. The language code just needs to be removed from the list in Module:links. The "override_translit" list has been greatly expanded some time ago, I have no knowledge why. Keφr 21:26, 28 July 2014 (UTC)
The generated transliterations don't have accent marks and don't separate members of compounds. You need to undo all of your edits. --Ivan Štambuk (talk) 22:08, 28 July 2014 (UTC)
The stress marks on Sanskrit entries/translations were rare, I don't know who added them and how reliable they are. I personally haven't removed any transliterations with stress marks. The problem is - 1. it's not very common to have stress marks in dictionaries, 2. Devanagari script is not marked with stresses, 3. we lack a dedicated, knowledgeable Sanskrit speaking editor. As I suggested before, a system with invisible stress marks could be employed (like invisible spacing (ja and zh), capitalisation (symbol ^) and hyphens with Chinese, Japanese and Korean transliterations). Of course, care should be taken not to break consonant conjuncts and the original script otherwise. --Anatoli T. (обсудить/вклад) 22:24, 28 July 2014 (UTC)
Undoing my edits isn't an option at this point. I've been doing this for weeks if not months, usually in combination with removing several other redundant transliterations from translation tables at the same time. For Cyrillic, I've been dutifully moving the stress mark onto the Cyrillic before deleting the translit, but for Sanskrit the stress mark just gets lost. It isn't really all that crucial anyway; having it on the entry page itself is probably sufficient. —Aɴɢʀ (talk) 22:29, 28 July 2014 (UTC)
This is an example of an edit I have no intention of undoing, especially since the Sanskrit entry didn't provide stress marks in the first place. But now those Sanskrit words are without any translit at all. That's why it would be better if manual translits overrode automatic ones, but if automatic translits appeared when no manual one was present. —Aɴɢʀ (talk) 22:33, 28 July 2014 (UTC)
Yes, I agree it's not crucial, having a standard IAST transliteration is more important than non-standard with stress marks. Besides, it seems hard to verify the accuracy of the stress. If I don't know the stress, say for Bulgarian, I just leave it unstressed. Can anyone say, which Sanskrit dictionary provides stress marks? I've seen them in a Sanskrit textbook and here but not in dictionaries I've seen. I have restored automatic transliteration for Sanskrit in Module:languages/data2 but it's not mandatory - not in "override_translit" list in Module:links. --Anatoli T. (обсудить/вклад) 22:40, 28 July 2014 (UTC)
I do think the stress marks are important. According to w:Vedic accent, there is a native way to transcribe the accent. I think we should use it as it would simplify transliteration. —CodeCat 22:47, 28 July 2014 (UTC)
@Atitarev: Accent marks are a part of IAST, read here p. 13. --Ivan Štambuk (talk) 22:57, 28 July 2014 (UTC)
@Atitarev: Pretty much all Sanskrit dictionaries mark accents, either in Devanagari or Latin transcription. Having accents marked in Devanagari is not an option due to many different conventions used in various texts, the difficulty to type them, and the lack of font support. Accents are important and have to be marked. It's absurd to argue that they don't matter, or that they are not reliable (do you think that they were guessed by editors who added them?). Devising an obscure secondary system with invisible stress marks and whatever in Devanagri is similarly absurd. Why not just type it in Latin instead? Jesus. --Ivan Štambuk (talk) 22:49, 28 July 2014 (UTC)
I can see that in Wiktionary the stress marks are rather rare, it's not easy to find words marked with accents. OK, they do matter but who will maintain them - who is the Sanskrit editor? As for invisible accent marks, I'm actually suggesting this - e.g. use संस्कृत́ (saṃskṛtá) with an invisible acute accent on Devanagari word, visible here, which would link to संस्कृत (saṃskṛtá) (without the acute accent on Devanagari word) and display transliteration "saṃskṛtá" with a stress mark. --Anatoli T. (обсудить/вклад) 23:00, 28 July 2014 (UTC)
Anyway, this dispute should be over now. Module:sa-translit will now provide automatic transliteration only when the manual is missing. It can also be used to add a more standard manual transliteration with a stress mark (using preview). --Anatoli T. (обсудить/вклад) 23:09, 28 July 2014 (UTC)
We don't necessarily have to faithfully represent all the stress marks, as we add them to many words that never had them in the original text. So we can choose our own scheme. A very simply one is to use the vertical "udātta" mark for stress, and mark nothing else. —CodeCat 23:23, 28 July 2014 (UTC)
Accent are only marked for words for which they are unpredictable, i.e. of pre-classical Vedas. There are no instances of accents marked for words that "did not have them".
Yes, acute accent was just one idea. If there are any native means, it would be even better. We can use udātta, anudātta, svarita, etc. --Anatoli T. (обсудить/вклад) 23:45, 28 July 2014 (UTC)
There are many schemes for marking accents in Sanskrit text that employ some dozen different special marks, and it makes no sense to invent some Wiktionary-specific one that is not used anywhere, solely to impose some kind of artificial uniformity. --Ivan Štambuk (talk) 23:37, 28 July 2014 (UTC)
I think you misunderstood. You were worried about one missing symbol - acute accents marking the stress, is that right? We can still use automatic transliteration if we add one of invisible symbols (can be your choice - doesn't have to be acute accent), which would convert to áéíóú in transliterations. I don't know why are you being uncooperative, what exactly seems to be a problem, Ivan? --Anatoli T. (обсудить/вклад) 23:45, 28 July 2014 (UTC)
Three symbols - acute, grave and hyphens. The first two for accents, hyphen for compounds. I'm not being uncooperative it's just that you're trying to solve a non-issue. --Ivan Štambuk (talk) 00:14, 29 July 2014 (UTC)
We can add all three, you know :) Automatic is still far better than manual when none of those accents are present or necessary. Some hyphens may not be necessary too, etymology sections can show the compounds. E.g. Korean is now much more selective with the usage of hyphens. The "issue" was numerous Sanskrit translations without transliterations, which is now solved. --Anatoli T. (обсудить/вклад) 00:21, 29 July 2014 (UTC)
I'll maintain the accents. Just don't remove them anymore. संस्कृत (saṃskṛta) is in fact a perfect example why manual transcription is superior and irreplaceable. --Ivan Štambuk (talk) 23:40, 28 July 2014 (UTC)
Good idea to maintain the accents! Note that you can do संस्कृत (saṃskṛtá) with a manual transliteration. --Anatoli T. (обсудить/вклад) 23:45, 28 July 2014 (UTC)
Okay, so the etymology sections of both φέρω (phérō) and ferō claim that the stress of भरति (bharati) is bhárati, so I added an acute accent to its transliteration on the entry page, but then I remembered from Sanskrit class 20 years ago that finite verbs in Sanskrit are always unstressed. So why is this bhárati and not bharati? —Aɴɢʀ (talk) 14:34, 29 July 2014 (UTC)

Invoking/using templates within a module[edit]

So, is it possible? Currently, something like this won't work

return "{{term|word|lang=en}}"

this just returns text... The template is not run.--Dixtosa (talk) 17:54, 29 July 2014 (UTC)

There is a method that does this: frame:expandTemplate, but for some reason we tend to avoid using it. --WikiTiki89 17:58, 29 July 2014 (UTC)
Probably because it is usually cleaner to invoke the underlying Lua function directly. Keφr 18:11, 29 July 2014 (UTC)
If there is an underlying Lua function (which in this case there is, so it should definitely be used). --WikiTiki89 18:18, 29 July 2014 (UTC)
That was too bad example it seems :D.
Actually, What I'm trying to do is a lot different. I have several templates for the sake of simplicity call them temp-1, temp-2 and temp-3. Each of them receives different number of arguments (say, 2-4). I want to have one unified template that, based on the logic of some helper Lua module, calls appropriate template. The thing is that I'd prefer to do Lua processing rather than template one. Moreover the only template-oriented solution I can think of is ugly:

{{temp-{{#invoke:module|get_id}}|{{#invoke:module|get_first_arg}}|{{#invoke:module|get_second_arg}}|{{#invoke:module|get_third_arg}}|{{#invoke:module|get_4th_arg}}}}

Ugly in the sense that it passes unused dummy arguments.--Dixtosa (talk) 18:38, 29 July 2014 (UTC)
And why not implement the logic for the three templates in Lua too? Keφr 18:41, 29 July 2014 (UTC)
If you just want to format output, I created a template-like string processing module: Module:string utilities. For an example, scroll down to the bottom of Module:ru-noun. --WikiTiki89 18:47, 29 July 2014 (UTC)
@Kephir, well, I thought I would just use what is already written. Plus, there are ~6 not-so-small templates to be rewritten.
@Wikitiki89, that will definitely ease my life if I plan to rewrite the whole thing. Because I am too working on improving declension-related templates.--Dixtosa (talk) 20:14, 29 July 2014 (UTC)

Bot request: Interlanguage links in Rhymes namespace[edit]

I just added interlanguage links to en.wikt on de.wikt rhyme pages. Now someone could just add the backlinks over here. --Kronf (talk) 01:57, 31 July 2014 (UTC)

Orange links in tables of contents[edit]

A few hours ago, some lines in some entries' tables of contents started showing up in the same orange colour as links like kitten (links to nonexistent sections of pages). For example, the link in Courtney's TOC to "Anagrams" is orange, and the links in book's TOC to "Statistics", to "Anagrams" and to both "Synonyms" sections are all orange. Quite a large swath of iron's TOC is orange. The other links are the usual blue, and all of the links work as expected. The orange colouring only shows when I am logged in and the page has finished loading. It persists even if I clear my cache. I am using Windows 7 and Firefox 31, and I thought I had enabled the gadget that turns links to nonexistent sections of pages (like the aforementioned kitten) orange — and that link does looks orange to me — but the "OrangeLinks" box isn't checked when I go to Special:Preferences#mw-prefsection-gadgets. Checking it and clearing my cache does not, however, have any effect. - -sche (discuss) 04:43, 31 July 2014 (UTC)