Wiktionary:Grease pit/2013/September

And I happen to use it a bit. Even though it may be a bit outdated and it has no data for the language I mostly use it for. Still, it saves me a few keystrokes, so I would like it to continue working — at least until something better arrives. Keφr 06:51, 1 September 2013 (UTC)

Fixed. (Ugh, that script was horribly written. I would rewrite it if not for now objecting to the concept as a whole these days...) --Yair rand (talk) 13:02, 1 September 2013 (UTC)

Thank you. I could not have put this better. (Though you mean the concept of this tool or the concept of rewriting it?) Keφr 13:06, 1 September 2013 (UTC)

Since I wrote the dirty hack in {{t-SOP}}, I became curious about when the migration to {{t}} will be done. So I put together a quick-and-dirty dump-scanning script, and found 23993 pages with translations in need of attention in the August 25th dump. Some of them are probably false positives ({{t}} translations with comments), but I estimate about 80% of them to be valid matches. And the others probably need some love too, even if these pages use {{t}} everywhere already. The list (with explanations for the matches) takes around 2.8 MiB, so if I post it here, it will have to be split, as it exceeds the top entry on Special:Longpages.

Some other observations:

• Within the span of 294 days between the November 4th and August 25th dumps, the amount of pages went down by 1882. That is 6.4 pages per day. If we want the migration to {{t}} to end before the end of the decade, we might want to increase that number. Say, we have eight editors (CodeCat, Atitarev, Mglovesfun, SemperBlotto, ZxxZxxZ, Metaknowledge, Ivan Štambuk and me) who seem to be able to come here every day. If each fixes 30 articles, the migration should be done in about 100 days. But of course things happen, so to be realistic I would double that period and increase the number of articles per day to 50. Especially since I will probably not come here this week.
• There is a quite large number (about 600) of translations like ] ] {{t+|fi|teksti}}, most of them into Finnish. xte does not detect those, as it skips any translation which contains a {{t}}-series template. These however look quite regular and machine-parseable and therefore may be handled by a proper bot.
• Un-marking translations for checking is a bit cumbersome. We need a JavaScript tool to do it with a few clicks. WT:EDIT seems to have some code which would make this easier, but I am unfamiliar with how it works, and have quite little time, so I will not attempt to create it soon.

That would be all for now. I think I will be posting the list shortly.

Keφr 07:28, 1 September 2013 (UTC)

I posted the list: User:Kephir/t.love. Keφr 12:19, 1 September 2013 (UTC)

I would like to help; I have not used your scripts before, so I suppose I'll need to do so. It would be nice if you could remove more false positives, though — stuff like the Korean translation at vivisection#Translations seems perfectly valid to me, but it's getting picked up. I'm sure there are more specific trends (like this one, namely hanja following hangeul in parentheses) that could be removed from the lists. —Μετάknowledge^{discuss/deeds} 21:13, 1 September 2013 (UTC)

Languages like Korean and Japanese seem to have features not well supported by the current t templates. Maybe we could add parameters so that translations into multiple scripts can be handled with one template invocation? This would also apply to Serbo-Croatian. DTLHS (talk) 21:25, 1 September 2013 (UTC)

@DTLHS: I strongly support that. While we're at it, there's another problem with S-C and some similar macrolanguages. Sometimes we display a redlink for sh.wikt even when hr.wikt or sr.wikt or bs.wikt has the entry, just because we have unified the dialects and they haven't. Now that we can detect script, we should try linking to the relevant dialect Wiktionary as well.

@Κεφr: Stupid question, but what's the basket for in xte? —Μετάknowledge^{discuss/deeds} 21:31, 1 September 2013 (UTC)

Not that stupid, actually. Initially I developed it thinking that it would be used for feeding User:MewBot with lists of pages to process: visit the pages, collect them in the basket, and then put them into MewBot's input page. Never finished it, though. I thought about accommodating it for manually going through a list of pages, like in this case. Keφr 21:52, 1 September 2013 (UTC)

That would actually be helpful, perhaps. As it stands I am unable to see the point of it, but then again I also can't figure out how to mass-edit my basket. —Μετάknowledge^{discuss/deeds} 18:32, 2 September 2013 (UTC)

I made an update, w:WP:BYPASS your caches. I added some kludgy code for import/export through wikitext. Open a random page for editing and two menu items shall appear that will put the basket contents into the editor and pluck wikilinks from it. You can also import a list of wikilinks from a page opened for reading. Open my index, import a list of pages, select "Pick a random page" (accesskey: ], for Chrome it means Alt+], not sure about other browsers) to jump to a page to work on. Process it (accesskey: \), save, rinse and repeat.

The basket is kept synchronised between tabs/windows (although I do not guarantee it being free from w:race conditions, so please do not stress it too much) and stored using the HTML5 localStorage object; depending on your browser policy, it may or may not persist across sessions. Also, please be cautious not to hit your browser storage quota (or you may increase it for Wiktionary, if you so wish). Keφr 16:16, 3 September 2013 (UTC)

True. Japanese kind of manages to squeeze into that format (ひらがな readings are put in |tr=, next to romaji, which is quite understandable), but for Korean it may be harder to think up something sensible. I wonder what should be done to {{zh-ts}} — pouring the contents into two cups of {{t}}, I guess?

There are also translations using {{l}}, which xte does not handle well. Perhaps I should look into fixing that. But not now. Keφr 21:52, 1 September 2013 (UTC)

In this edit to User:Mglovesfun/sandbox, I test whether User:Mglovesfun/sandbox and User:Mglovesfun are equal to the page name. Look at the top two lines; all normal. The bottom two lines are the same thing but subst:ed. Both come out as no, even though when no subst:ed, the top one comes out as yes. Why?? Mglovesfun (talk) 11:07, 2 September 2013 (UTC)

Did you subst: both the #if and the magic word (here {{PAGENAME}})? I often get bitten by forgetting to do this. Keφr 12:02, 2 September 2013 (UTC)

No I didn't subst: both, I don't see why it would matter but I'll try it. Mglovesfun (talk) 17:41, 2 September 2013 (UTC)

Hmm, that ought not to work. Mglovesfun (talk) 18:00, 2 September 2013 (UTC)

It makes sense if you understand how the parser works. When a page is submitted, first a PST (pre-save transform) is done on the wikitext and the result of that is written to the database; this is the phase when substitutions happen and four tildes become signatures. Templates not to be substituted are left as they are. When the page is rendered, the templates are first expanded: beginning the most deeply nested ones, then the expanded strings are passed as parameters "one level up", and so on, up to the point where no template calls remain. Then the result of expansion is parsed for the last time, resulting in HTML: this is when double brackets become links. I am sure this is documented somewhere on mw:, but I cannot remember where.

By the way, xte adds a keyboard shortcut to perform PST on the current selection. Just for the case when you want to edit. Alt+; on Chromium, not sure whether it works on other browsers. Keφr 18:28, 2 September 2013 (UTC)

To add to what Kephir (talk • contribs) says . . . if you need to do this in a template, you can write something like

{{safesubst:<includeonly/>#ifeq:{{safesubst:<includeonly/>PAGENAME}}|Mglovesfun/sandbox|yes|no}}

which will work properly whether or not the template is substituted. (Conrad.Irwin (talk • contribs) created that feature.)
—Ruakh_TALK 18:49, 2 September 2013 (UTC)

{{term|ກອງ|lang=lo}} returns nothing currently: ກອງ (kǭng). Please fix! Wyang (talk) 09:20, 4 September 2013 (UTC)

This is a MediaWiki bug: Lao Wiktionary is rendered as all squares! Someone needs to report this to Bugzilla. -- Liliana • 09:36, 4 September 2013 (UTC)

When I look at, e.g., Category:Old Church Slavonic nouns, I see some default Cyrilic font, rather than the Old Church Slavonic font that I used to see until a few days ago. Did something happen? Was something changed in the defaults for Old Church Slavonic? Is a new font that I don't have now in use? --Pereru (talk) 09:51, 4 September 2013 (UTC)

• In "Module:Languages", Old Church Slavonic is defined as using "Cyrs", "Glag" scripts. Should the two scripts be the other way round? SemperBlotto (talk) 09:56, 4 September 2013 (UTC)
• I guess this is the ULS. It also recently changed my editor font from a monospace font to sans-serif. Utterly infuriating. Add delete mw.webfonts; to Special:MyPage/common.js and hard-refresh the page. Does this help? Keφr 10:08, 4 September 2013 (UTC)

No, it doesn't help. And the problem is not just with Old Church Slavonic. MediaWiki:Common.css is being overridden for me. --Vahag (talk) 10:25, 4 September 2013 (UTC)

There is unfortunately a race condition here. If the ULS runs before common.js, this will do nothing. I think I can detect when this happens, but I am not sure how to undo the damage. Keφr 10:46, 4 September 2013 (UTC)

Try this also: $(', , ').css('font-family', '');. Keφr 11:33, 4 September 2013 (UTC)

That works, but it doesn't matter. All users can't add special code to their Common.js. ULS should be disabled on Wiktionary. --Vahag (talk) 12:02, 4 September 2013 (UTC)

Read and weep: mw:Thread:Talk:Universal Language Selector/Disabling ULS, bugzilla:46306. We probably need to organise some torches-and-pitchforks campaign against it. It kind-of worked for VisualEditor; it still cannot be disabled completely, but is now quite easy to avoid. In the meantime, we may put this thing (or a more elaborate version) into MediaWiki:Common.js. Keφr 12:47, 4 September 2013 (UTC)

All those discussions seem to revolve around everything but the web fonts. I had disabled web fonts when I had that option because the Burmese font crashes my browser and I had to use a different browser to visit pages with Burmese on them (I have a Burmese font on my system that works just fine). I find the ULS mildly annoying, but I could live with it if it didn't come with mandatory web fonts. Chuck Entz (talk) 18:43, 6 September 2013 (UTC)

I just wanted to mention that the Gothic font I used to see has also now become little squares. I'm not a technician, so I can't help with the stuff you're discussing, but I hope a solution will be found... things were OK, and then suddenly they weren't. :-(... --Pereru (talk) 17:40, 4 September 2013 (UTC)

Why have I been seeing a serif font for terms in {{term}} and {{mul-proper noun}} lately? Is this they way it's supposed to be? If so, why? DCDuring TALK 00:42, 5 September 2013 (UTC)

Could it be related to the problem above? —CodeCat 00:47, 5 September 2013 (UTC)

How would I know? You're the expert. DCDuring TALK 00:53, 5 September 2013 (UTC)

Which page? which problem? DCDuring TALK 00:54, 5 September 2013 (UTC)

Why haven't we added Kephir's fix to common.js yet? DTLHS (talk) 01:03, 5 September 2013 (UTC)

I inserted the one line fix in my common.js and I still have problems with many languages (eg, fro, enm, frm) for {{term}} and for all uses of {{mul-proper noun}}. Also the IPA font doesn't look right to me, not that I know what it should look like. DCDuring TALK 01:23, 5 September 2013 (UTC)

There is no "the" "one line" "fix". I posted two lines above, each mitigates the problem from a different angle, and it is not a "fix" even, but a very brutal workaround that actively breaks ULS (and I use a more elaborate version myself). They should probably be inserted very early, and you of course need to hard-refresh the page for it to take effect. The proper fix is to punch the WMF technicians in the face, repeatedly, until they come back to their senses and add a per-browser/user/project opt-in/out to this ULS/WebFonts thing. Because apparently this is the only way that would work.

Strange that you get a serif font. I got everything overridden to sans-serif. That would suggest this may not be it. Do you have a sans-serif font set as your browser default? In which font does display? (The link will not render, but try opening it anyway) Keφr 07:53, 5 September 2013 (UTC)

I copied the entire section that seemed relevant from your common.js and hard-refresed. That did the trick.

Before I did that, I checked the Options box in Firefox that allowed the website to choose fonts and was horrified by the fonts that resulted.

I also checked by browser font settings: The default is Arial, which is also the sans-serif font.

The snippet does not render and does not lead to anything when I click on it. Is there some precursor step, obvious to you, but not obvious to me, that I am neglecting?

I have whined previously at Bugzilla about watchlists and Special:WantedPages with no great success. Where can I deliver my whine now, perhaps to better effect? DCDuring TALK 12:12, 5 September 2013 (UTC)

Well, the data:text/html,%3Cp%3Ehello string is an URI, but MediaWiki is not willing to recognise it as such. It ought to be a link. But never mind, it seems that we have located the problem.

Like I said, Wikipedians seem to be somewhat effective at getting what they want by throwing tantrums at the developers, so... ask them. Keφr 19:25, 5 September 2013 (UTC)

Is this why I'm seeing a proportional sans-serif font in the editing window rather than the monospace one I'm used to (and still get at Wikipedia)? Thryduulf (talk) 12:15, 5 September 2013 (UTC)

Yup. Funnily enough, I discovered it the same way. My first thought was that it was the recently updated Dot's highlighter (it messes a bit with the editor's styling), but no. Then I killed the ULS and that worked. Though changing the "Edit area font style" preference to something other than "Browser default" should also do the trick. On the other hand, now that the ULS messes with it, the name "browser default" is a lie. Keφr 19:25, 5 September 2013 (UTC)

Thank you. Is that "browser default" label a setting here or does it need correcting in MediaWiki? Thryduulf (talk) 19:41, 5 September 2013 (UTC)

I did it. You can thank me later. -- Liliana • 19:44, 5 September 2013 (UTC)

What exactly? DCDuring TALK 19:45, 5 September 2013 (UTC)

-- Liliana • 19:47, 5 September 2013 (UTC)

Tentative thanks now for all those who will get the benefits without having to insert the code in their own common.js. If it keeps working and doesn't have too many ugly side-effects, I will more graciously thank you later.

I suppose there is some risk that users expecting us to have anything (the enhanced editor?) that needs ULS will not bother contributing. But we might also pick up some refugees. DCDuring TALK 19:57, 5 September 2013 (UTC)

At a later stage, enabling ULS could become a preference any editor could enable if they so wished via WT:PREFS. -- Liliana • 20:13, 5 September 2013 (UTC)

But not necessarily for the less technically adept potential contributor, always an object of my "concern trolling". DCDuring TALK 20:21, 5 September 2013 (UTC)

I've pinged the WMF language engineering team to let them know about the problems here. Generally, the best way to get things fixed is to file a bug in Bugzilla, although I know this can be a slow/frustrating process. At least it lets the people who could fix the problems know that the problems exists, which is half the battle. Kaldari (talk) 18:38, 6 September 2013 (UTC)

Someone moved the tracked template at the top, but to be clear that report is mostly about something else so you need to file a separate one for the individual issues you have (not for the proposed solutions). Nemo 10:18, 7 September 2013 (UTC) P.s. Standard edit toolbar is broken for me here.

P.p.s.: Broken toolbar is probably the same problem as in #Adding IPA characters/other symbols not working properly. Works now! --Nemo 08:45, 16 September 2013 (UTC)

This script, as it stands now, is a bit of a mess. The script actually has two completely different ways of generating form-of entries. One generates the entries internally with JavaScript, while the other uses external templates (which are subpages of the script) with parameters to fill in. The external generation with templates is how it originally worked. It's easier to comprehend, but it's a lot less flexible because you can't easily define different rules and conditions for them. This led to many "hacks" and ad-hoc extensions to the system which made it rather messy and inconsistent. Basically, very little of the original system actually does what it was originally meant to do, even to the point where parameters for language codes no longer contain language codes. Yes, it's that bad. The internal system is written all in JavaScript so it has the downside that you need to understand this language a bit in order to write new generation rules in it. The upside is that it's conceptually much simpler and it's easier to use when you do understand JS, and it is also much more flexible and can account for many more exceptions.

I think that either one or the other system should be used so that it's easier to understand, and people who want to add rules don't need to ask "which method should I use". I prefer the internal generation myself because it's very straightforward for me; you just have to write one JS function that gives back the whole entry's text, no strings attached. But I can imagine that others prefer the external generation system because it uses templates, which they may find easier to work with and thus makes the acceleration system as a whole more accessible for laypeople. The downside of course is that it would also make it more limited, and make it much harder (if not impossible) for it to cover all use cases. This is why the internal system was added to it in the first place.

I also think that the script should be moved. It was originally developed primarily by User:Conrad.Irwin, but it has really become a part of Wiktionary so it doesn't seem appropriate to keep it on his user space. A more "global" location would be more fitting. —CodeCat 16:19, 7 September 2013 (UTC)

Okay, another nag, I'm afraid. When I create a new entry (in Opera) I sometimes want to go back and copy the contents as the basis of another similar entry. Since recently, the Back button seems to activate some JavaScript instead (?) and I keep getting thrown back to the newly created page. Any good reason for this? Equinox ◑ 21:27, 7 September 2013 (UTC)

I'm guessing it has to do with the fragment identifiers (the stuff after # in a URI) added and used by Tabbed languages. Do you have Tabbed languages enabled? If yes, then — does disabling Tabbed languages fix the problem? —Ruakh_TALK 22:09, 7 September 2013 (UTC)

I don't have that enabled. Equinox ◑ 22:11, 7 September 2013 (UTC)

Could it have something to do with the "Warn me when I leave an edit page with unsaved changes" preference? DTLHS (talk) 22:11, 7 September 2013 (UTC)

As you may be aware, Foundation devs have been working heavily on improving the search system used in MediaWiki. Two of the major problems for Wiktionary have been accurate (and complete) search indexing across scripts, and expanding all templates before indexing. For the past couple months this system has been being used on the labs wikis, and is about to be made default on MediaWiki.org. (see thread on wikitech-l)

Nemo has suggested the next roll-out should be Wiktionary, and I whole-heartedly agree. With our extensive use of templates, and non-latin scripts, it would be a huge bonus for us. - Amgine/ ^t·e 07:44, 8 September 2013 (UTC)

Oh, so I guess this is why searches have been often timing out and spitting with database errors recently. Awesome. Keφr 08:51, 8 September 2013 (UTC)

No. That was before they even started working on this extension. And before those error messages were introduced, you would only get bogus 0 matches results. Nemo 11:09, 8 September 2013 (UTC)

I'm getting confused by this template. I thought it was a replacement for {{recons}} but it's also now linking to attested terms. It seems to have some of the functionality of {{term}} and of {{l}} but nothing that these two don't already do, or shouldn't do. For example term should recognize that {{term|*dingua|lang=la}} is unattested and link to Appendix:Latin/dingua. So what is term/t for? Should it in fact be orphaned and replaced by {{term}}? Mglovesfun (talk) 10:49, 8 September 2013 (UTC)

It's a replacement for both {{recons}} and {{term}}, in the same way that the new {{l}} replaced both itself and {{lr}}. {{term/t}} and {{term}} have the same capabilities, so you can link to reconstructed terms with either of them. The difference is that {{term/t}} takes its parameters in the same order as {{l}} (language name first), so it needs a different name to avoid breaking compatibility with existing uses. I think the expectation is that {{term/t}} will be renamed at some point and that it will replace {{term}} over time. We haven't settled on a name yet. I think {{m}} is the most popular candidate currently, but it would mean converting all existing uses of {{m}} to {{g|m}} first. —CodeCat 11:26, 8 September 2013 (UTC)

What would m stand for? Mglovesfun (talk) 11:28, 8 September 2013 (UTC)

It stands for "mention", which seems rather fitting. We can't use {{t}} for "term" as it's already in use. Once the change is made though, we will have a nice pair of templates {{l}} and {{m}} :). —CodeCat 11:30, 8 September 2013 (UTC)

So I guess we should orphan {{m}} now. Bad news: {{m}} has a lot of direct uses. Most are in translation lists, some are in headwords (most look Italian), while others are in "Related terms" lists. Each probably needs a different proper fix, rather than just slapping {{g}} around it. Translation lists are being dealt with, but slowly, while I think the very simplest cases can be handled algorithmically. The headwords and "related terms" lists also look quite easy to tackle with automated tools. Keφr 11:52, 8 September 2013 (UTC)

At the very least, a temporary fix by adding {{g}} is probably still better than waiting for a proper fix. Of course, a temporary fix doesn't preclude a proper one either. In fact, it may make it easier because xte would have less cases to examine: anything that begins with {{g| would be a gender, no need to handle all the different gender templates then. —CodeCat 12:15, 8 September 2013 (UTC)

Actually it will create more cases, and more complexity, not less: the already-processed-to-use-{{g}} items and not processed ones. And I will have to pluck {{g}} out of the former. Not very hard, but still. While detecting cases where {{head|it|...|g=m}} should be put, or converting the "related terms" list to {{l}} seems rather simple.

I think I am going to write a bot and run it on my User:Buttermilch account to handle the latter two tasks. But maybe not very soon. Keφr 12:36, 8 September 2013 (UTC)

Just to note: I have counted over 90000 uses in the last August dump. The actual number might be higher, as I simply grepped the dump against the string "{{m}}". Keφr 14:24, 8 September 2013 (UTC)

The number of uses isn't a significant issue. The bot will just take longer. It's taking MewBot over a week now to clean out Category:Link alt form tracking/redundant/la... —CodeCat 14:26, 8 September 2013 (UTC)

Moving the gender from {{g}} to {{head}}, {{l}} etc. is a purely cosmetic change in code, why should we care about that and stop an important change ({{term|lang=xx|...}} > {{m|xx|...}}, 8 less keystrokes for every mentioned term) because of it? --Z 15:08, 8 September 2013 (UTC)

Because moving it into {{g}} is also a "purely cosmetic" change in code? Why not kill two birds with one stone and do it the right way the first time, especially when it is that easy? Though the translation lists will probably need to be dealt with in two phases anyway. At the current rate, we will not be done with migration to {{t}} in the next ten years. Keφr 17:52, 8 September 2013 (UTC)

No, it's not. If we move genders to {{g}}, {{m}} will be orphaned and we can do that important change - moving {{term/t}} to {{m}}. But what is the point of moving them from {{g}} to {{head}}/{{l}}? The change is not even worth it to run a bot on so many pages if you ask me. Of course you are most welcome to go ahead and kill two birds with one stone if you think it's that easy, I don't think it is, because these gender templates are mostly used where {{head}}/{{l}} are not used (while they should be), so the bot has to add head/l as well, which is almost impossible in many cases (there may be inflected/other forms on headword, transliterations, qualifiers, etc. quite hard to distinguish for machine). --Z 19:58, 8 September 2013 (UTC)

Exactly, why move gender twice? Better move it in the right place the first time. And this already takes care of the vast majority of direct uses (64602 headwords, 3206 already using {{head}} with gender detached and 9969 related terms). Why waste time on temporary hacks when a proper solution is easy? Keφr 05:28, 9 September 2013 (UTC)

We are not going to move them twice, as I said, we should just move them to {{g}}, but moving from {{g}} to other templates is not important and we should not care about that. --Z 06:34, 9 September 2013 (UTC)

Has anyone suggested "lex" for "lexical item"? Chuck Entz (talk) 15:04, 8 September 2013 (UTC)

Currently {{lex}} is a language template; and even if/when we completely eliminate language templates (in favor of the Lua module), I think we'll want to avoid template-names that happen to be language-codes (or that happen to begin with language-code-plus-hyphen). —Ruakh_TALK 19:08, 8 September 2013 (UTC)

If you wanted to skip m and n because they're genders, {{o}} is the next available alphabetically. Mglovesfun (talk) 19:45, 9 September 2013 (UTC)

From what I can see and judge based on Kephir's recent changes to templates, there is agreement that we will orphan the gender templates by prefixing them with {{g|. Once {{m}} has no more transclusions, {{term/t}} will be moved to {{m}} and all uses of the old name will be fixed. We can then make an attempt at changing {{term}} into the new {{m}}.

Many of the current uses of gender templates or {{g}} should eventually be integrated into another template such as {{head}} or {{t}}, but this is a more long-term task that needs a different approach. For the time being, adding {{g| does not preclude this step. However, it allows us to solve the overall problem in stages rather than needing to fix it all in one go, which would prevent us from orphaning the gender templates while there is nothing a priori that prevents us from doing so, other than the desire to "fix everything". So is this agreed? —CodeCat 14:06, 12 September 2013 (UTC)

Well, converting to {{g}} is better than doing nothing at all, so yes. My edits to headword templates I consider rather temporary measures, just to decrease the transclusion count of {{m}} so that only the direct uses remain to be dealt with. I think eventually headword templates should also delegate out to central templates/modules. Still, I think converting the manually formatted headwords (as in: '''{{PAGENAME}}''' {{m}}, seriously) seems rather easy and may save some work later, so… never mind. Keφr 14:44, 12 September 2013 (UTC)

I'd suggest waiting for input at Wiktionary:Requests for deletion/Others#Template:m before proceeding. Even if this discussion supports a bot-task, your theory that "Once {{m}} has no more transclusions, {{term/t}} will be moved to {{m}} and all uses of the old name will be fixed" may not be borne out by that discussion. (Also, BTW, I'd ask that you give your own input there, since you obviously have an opinion!) —Ruakh_TALK 14:53, 12 September 2013 (UTC)

Has the same transliteration twice consecutively. When I remove the manual transliteration, it adds the category Ancient Greek terms needing transliteration. Please remedy. Mglovesfun (talk) 19:40, 9 September 2013 (UTC)

Thanks to User:ZxxZxxZ, who wrote Module:grc-translit, Ancient Greek is now transliterated automatically. So I have removed the manual transliteration option from {{grc-verb}}. But I am not sure I won't be reverted. Many people here love duplication and redundancy. --Vahag (talk) 20:02, 9 September 2013 (UTC)

Manual transliteration should not be removed. It should override the automatic one. —CodeCat 20:07, 9 September 2013 (UTC)

I've added a feature to Module:languages and to the modules (and accompanying templates) that use genders. It lets you specify which genders are valid for that language, and a script error results if the given gender isn't valid. So if you were to give "n" as the gender for Spanish, it would show an error, because Spanish doesn't have a neuter gender. It's given using the genders value in Module:languages and it's opt-in, so if it's not desirable you don't need to specify it. If the gender contains a ? then the check is skipped, because this indicates an incomplete or uncertain gender and a check would not make much sense then. I don't know if it will be useful in the end, it still needs to be tried out to see how well it works in practice. But I think it can be useful as an extra automatic validation of our content. I'm also not sure if a script error is the best way to handle errors, maybe a category would also work, but we'll have to see. Script errors have the advantage that they're spotted very quickly and so errors don't linger around for too long. The same can't be said for cleanup categories... —CodeCat 11:58, 10 September 2013 (UTC)

I think we should not use script errors, we have already overused it, it should be used when the code can not really do anything, otherwise it's not a good idea because it affects the readers. Currently if we pass an invalid language code to the linking templates, they stop working completely and just return a big horrible text, while they can still work and show the term (the term can be tagged with lang="und" in this case). There are other ways to make errors easier to spot for editors without affecting the readers that much. --Z 13:11, 10 September 2013 (UTC)

Strongly agreed! Script errors give the impression that there's some kind of technical error that will take a programmer to fix. We want contributors to think of templates as tools to use and correct inputs for as needed, not some kind of scary high-tech black box that starts flashing red lights and sounding alarms if you press the wrong button. Chuck Entz (talk) 13:23, 10 September 2013 (UTC)

I agree (w/ZxxZxxZ and Chuck Entz). —Ruakh_TALK 14:24, 10 September 2013 (UTC)

Lua really needs something like a "warning" that triggers an error without actually exiting the script. Even so, I think this is a case of trying to have your cake and eat it. You can't alert someone of a problem without alerting them. —CodeCat 14:35, 10 September 2013 (UTC)

We can implement a "warning" ourselves, e.g. by using pcall. But in this case, any such warning should be invisible by default, like hidden/request categories. —Ruakh_TALK 18:53, 10 September 2013 (UTC)

Re: "So if you were to give 'n' as the gender for Spanish, it would show an error, because Spanish doesn't have a neuter gender": Except that it does: there are a handful of neuter words, including lo and esto/eso/aquello. Languages are bigger than the boxes you want to put them in. —Ruakh_TALK 14:24, 10 September 2013 (UTC)

How are those words neuter though? I mean, if they are neuter, how can you tell when there are no neuter nouns for them to agree with? —CodeCat 14:35, 10 September 2013 (UTC)

Is that really what you want to argue about? As far as I'm aware, all dictionaries and grammars of Spanish agree that these forms are neuter. Even if you feel that you can offer some better analysis, do you really believe that we should use technical means to prevent knowledgeable editors from adding information you've now decided you disagree with? —Ruakh_TALK 18:53, 10 September 2013 (UTC)

We've been getting a steady smattering of edits to talk and user pages lately that really look a lot like someone testing the waters for a spambot invasion. They consist of the words "Hello. And Bye." with "(Test, just a test)" in the comment line. The latest incarnation was 220.176.200.137 if any admins want to see their deleted handiwork.

Would someone who knows how to do so add a rule to the filter to pre-emptively block these edits? I can't conceive of any possible situation where a legitimate editor would post anything that could be mistaken for such an edit. Thanks! Chuck Entz (talk) 03:41, 11 September 2013 (UTC)

When I clicked on the + symbol at the top of WT:Grease pit I almost made my comment there on the main GP page instead of being brought to the current month. There was a banner warning me not to do that, but couldn't it be arranged that clicking that symbol automagically brings one to the current month? I think our other dicussion pages do that, don't they? —Angr 11:43, 11 September 2013 (UTC)

It already does, see MediaWiki:NewSectionRedirects.js and Wiktionary:Grease pit/header. It executes as an onload hook though, and that happens to fire quite late, after all content loads. Especially on such a large page. You probably clicked it too soon.

Why do we even keep so many discussions on these pages anyway? Can we not just use LiquidThreads? It would be much simpler. Keφr 12:23, 11 September 2013 (UTC)

To your first point, I'm currently on a computer with a pretty low-quality browser. Another thing I usually can't do is open collapsible tables. I knew that was because of the poor browser on my company computer, but I didn't know that the problem I mentioned above was also related. To your second point, I don't know enough about the differences to comment; I'll leave that to others to hash out. —Angr 12:39, 11 September 2013 (UTC)

I can now confirm that it works properly on my home computer. Sometimes I think my company forces us to use a slow, stupid browser to dissuade us from editing wikis when we're supposed to be working. —Angr 19:39, 11 September 2013 (UTC)

When I added {{context|Anglicanism|lang=ga}} to íoseaglais and íoseaglasta I expected it to automatically put them in Category:ga:Anglicanism, but it didn't. Is there some change that has to be made to a template or module to make that happen? —Angr 11:43, 11 September 2013 (UTC)

All three of the items in Category:ga:Anglicanism are hard-categorized into it. That makes me think that "Anglicanism" may not be on the relevant list of categorizing contexts. When Conrad Irwin (I think it was him) was doing this, he had some threshold level at which he made a template for the term, possibly a redirect, and determined if it should categorize, probably based on his understanding of consensus. It was possible to imitate what he did for new labels.

I don't know what the current system is for accomplishing the result. Perhaps it is properly documented somewhere. We really do need maintenance-level documentation, even more than technical documentation. DCDuring TALK 12:41, 11 September 2013 (UTC)

I've checked them and they all seem fine; I wonder if it's due to a typo in a module somewhere. Mglovesfun (talk) 12:25, 11 September 2013 (UTC)

It's due to CodeCat's OMG-the-gender-is-wrong-so-we-should-destroy-everything change to Module:languages; see #Automatic checking of genders. I reverted that change yesterday, but I guess the reversion didn't propagate out to all pages. (It's a single enormous module used on a large proportion of the pages on the project, and it's being edited, on average, more than once a day, so I guess it's not surprising that some (many? most? all?) of these edits overwhelm the job queue and cause breakage.) I've just made a null edit to ], which fixed the problem there. I guess the same needs to be done for the other entries.
That said, CodeCat apparently feels that Slovene terms should never use the gender m, only m-an (for animate nouns) and m-in (for inanimate ones); if you agree with her, and you have the wherewithal to make the appropriate change, you might consider doing so.
—Ruakh_TALK 14:09, 11 September 2013 (UTC)

Using the last database dump, I generated a list of affected entries, and placed it at Wiktionary:Todo/Slovene masculine translations if anyone wants to work on it. (All told, CodeCat vandalized something like 1,851 Slovene translations with her edit. I really don't get why she thought that was O.K. . . .) —Ruakh_TALK 14:33, 11 September 2013 (UTC)

Why on earth do you see this as vandalism? Slovene doesn't have a plain masculine gender in the singular; all masculine genders are either animate or inanimate. I was trying to fix these by adding the animacy but then I realised there were too many. So instead I decided to change it to "m-?" which specifically means "masculine, but incomplete". This causes {{t}} to put the entry into Category:Slovene terms with incomplete gender, which allows them to be fixed more gradually. You really think that's such a bad thing? —CodeCat 17:29, 11 September 2013 (UTC)

You intentionally replaced 1,851 Slovene translations (give or take) with Script error. How is that not vandalism? Before your change, these translations included links to en.wikt entries and to sl.wikt; they included the translation itself; and they indicated that the gender was masculine. After your change, they were useless. Granted, as is standard in Slovene dictionaries, they didn't explicitly indicate whether the translation was animate or inanimate (leaving that to be inferred from the semantics); but you can hardly pretend that Script error is an improvement. —Ruakh_TALK 18:53, 11 September 2013 (UTC)

But you prevented me from fixing those errors, so you don't get to complain about them. —CodeCat 19:15, 11 September 2013 (UTC)

Bullshit. You vandalized 1,851 entries (give or take) with the plan of using an unapproved bot to fix them afterward. (See Wiktionary:Bots.) Why, exactly, am I not allowed to complain about that? (And even if the bot run had been approved, there was no need to start with vandalism; you could run the bot by generating the list based on the database-dump, rather than by breaking all the entries and using the "entry is broken" category to find them. In addition to the obvious advantage of avoiding massive preliminary breakage, this also has the advantage of ensuring that you only touch entries that your bot actually knows how to fix, as opposed to breaking all entries and having your bot fix whichever ones it can, leaving the rest broken. And even if you're really only willing, for whatever reason, to generate lists by populating categories programmatically — in which case I think that's a serious failing that you need to address — even then, you could have populated a custom hidden category for this purpose, with no visible effect on the entries, rather than replacing translations with Script error.) —Ruakh_TALK 19:49, 11 September 2013 (UTC)

I'd call this stupidity or ignorance rather than vandalism. Mglovesfun (talk) 15:51, 12 September 2013 (UTC)

It's not "ignorance", because she knew exactly what she was doing. I wouldn't call it "stupidity"; it was foolishness, certainly, but not caused by actual stupidity AFAICT. It was willful destruction with no regard for whether the community would support it. I admit, "vandalism" is not exactly the right word, because true vandalism is generally destruction for the sake of destruction (or for consequences of destruction: terror, notoriety, demoralizing an enemy, etc.), whereas in this case the destruction was incidental to her real goals, and most of the destruction was planned to be temporary (albeit with an infinitely long trail of small bits of destruction for the sake of coercion); but she did it without regard for the many better alternatives, because she simply did not care to avoid it. I think "vandalism" is the best approximation. —Ruakh_TALK 20:17, 12 September 2013 (UTC)

Is anyone else having problems with the tool below the edit window when trying to add IPA characters or other symbols? Whenever I use it at the moment, there seems to be only about a 1 in 4 chance that it will work. Most of the time it just adds a hash sign to the URL and takes me to the top of the page. If I reload the page enough times it eventually works, but it's very frustrating because it's a very useful tool when trying to add pronunciations. I'm not getting the same problem on Wikipedia, only here. Any suggestions? BigDom (t • c) 16:24, 11 September 2013 (UTC)

Sounds like a JavaScript is not loaded – perhaps it is failing to load, or just taking too long. Watch your browser’s progress indicator and make sure the page is finished loading before you click a symbol. Hope this helps. —Michael Z. 2013-09-11 16:55 z

If you're talking about the edit tool MediaWiki:Edittools then yes I've been having this problem for a few days. Mglovesfun (talk) 20:38, 11 September 2013 (UTC)

Yes, Edittools is the one, didn't know what it was called. Thanks. BigDom (t • c) 21:34, 11 September 2013 (UTC)

Me, too, though in my case I think it works more often than it fails. Based on the timing, I'm guessing it has to do either with the Universal Language Selector (ULS), or with the hackery we put in place in an attempt to disable the ULS. —Ruakh_TALK 20:49, 11 September 2013 (UTC)

Does forcing a refresh (ctrl+F5) work? I haven't had any problems with it, the edit tools work for me. —CodeCat 21:37, 11 September 2013 (UTC)

Yep, it's a ULS issue:

 JavaScript - https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=User:Liliana-60&action=edit
Event thread: click
Uncaught exception: TypeError: Cannot convert 'mw.uls' to object
Error thrown at line 9, column 1296 in <anonymous function: mw.ime.getIMELanguageList>() in https://bits.wikimedia.org/en.wiktionary.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.dismissableSiteNotice%7Cext.uls.i18n%2Cime%2Cinit%2Cinterface%2Clanguagenames%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cjquery.byteLength%2CbyteLimit%2Cclient%2Ccookie%2Ci18n%2CjStorage%2Cjson%2CmwExtension%2CtextSelection%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Uri%2Capi%2Cnotify%2Cuser%2Cutil%7Cmediawiki.action.edit%7Cmediawiki.action.edit.styles%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup&skin=monobook&version=20130911T214249Z&*:
    imeLanguageList=previousIMELanguages.concat(mw.uls.getFrequentLanguageList());
called from line 12, column 1126 in <anonymous function: mw.ime.setup>() in https://bits.wikimedia.org/en.wiktionary.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.dismissableSiteNotice%7Cext.uls.i18n%2Cime%2Cinit%2Cinterface%2Clanguagenames%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cjquery.byteLength%2CbyteLimit%2Cclient%2Ccookie%2Ci18n%2CjStorage%2Cjson%2CmwExtension%2CtextSelection%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Uri%2Capi%2Cnotify%2Cuser%2Cutil%7Cmediawiki.action.edit%7Cmediawiki.action.edit.styles%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup&skin=monobook&version=20130911T214249Z&*:
    $input.ime({languages:mw.ime.getIMELanguageList(),languageSelector:function(){var $ulsTrigger;$ulsTrigger=$('<a>').text('...').addClass(
called via Function.prototype.apply() from line 45, column 74 in <anonymous function: dispatch>(event) in 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=monobook&version=20130905T145332Z:
    ret=((jQuery.event.special||{}).handle||handleObj.handler).apply(matched.elem,args);
called via Function.prototype.apply() from line 38, column 454 in <anonymous function: eventHandle>(e) in 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=monobook&version=20130905T145332Z:
    return typeof jQuery!=="undefined"&&(!e||jQuery.event.triggered!==e.type)?jQuery.event.dispatch.apply(eventHandle.elem,arguments):undefined;
called via Function.prototype.apply() from line 42, column 909 in <anonymous function: trigger>(event, data, elem, onlyHandlers) in 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=monobook&version=20130905T145332Z:
    handle.apply(cur,data);
called from line 53, column 1885 in <anonymous function: trigger>() in 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=monobook&version=20130905T145332Z:
    jQuery.event.trigger(type,data,this);
called via Function.prototype.call() from line 8, column 1401 in <anonymous function: each>(obj, callback, args) in 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=monobook&version=20130905T145332Z:
    if(callback.call(obj,i,obj)===false)
called from line 4, column 280 in <anonymous function: each>(callback, args) in 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=monobook&version=20130905T145332Z:
    return jQuery.each(this,callback,args);
called from line 53, column 1820 in <anonymous function: trigger>(type, data) in 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=monobook&version=20130905T145332Z:
    return this.each(function(){jQuery.event.trigger(type,data,this);});
called from line 54, column 1720 in <anonymous function>(data, fn) in 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=monobook&version=20130905T145332Z:
    return arguments.length>0?this.on(name,null,data,fn):this.trigger(name);

-- Liliana • 21:45, 11 September 2013 (UTC)

A-ha. This is our hackery. I probably should never write code while utterly infuriated. Try mw.webfonts.setup = mw.uls.init = function () {}; $.fn.webfonts.default.exclude = '*'; instead of the deletes. And maybe remove that accessor overrides. Keφr 07:21, 12 September 2013 (UTC)

WRT (for example: பற்றிய வகையில் (paṟṟiya vakaiyil))- definitely changed recently. I don't see this with any other scripts. DTLHS (talk) 21:44, 11 September 2013 (UTC)

MZajac made some changes to the CSS recently. That might be it. —CodeCat 21:46, 11 September 2013 (UTC)

Are you still seeing the problem? In my browser, your sample above is in an upright font, and my web inspector shows that it is set to font-style: normal. Try force-reloading the style sheet. What browser are you using? —Michael Z. 2013-09-12 00:37 z

Chrome, Firefox. Maybe it's just the font- here's two screenshots with the font family on and off: 1, 2 The latter is what I had been seeing before this change. DTLHS (talk) 00:47, 12 September 2013 (UTC)

It looks italicky to me too. —Angr 10:26, 12 September 2013 (UTC)

DTLHS, thanks for the screenshots. I see you have the a element selected and the inspector indicates font-style: normal;, struck out. I don’t see this in Safari/Mac or Firefox/Mac. Why is the link italicized in your browser at all? – it is not in an em or i element. Maybe you have some custom style sheet that renders a.new in italics? Do you see the improper italics only on links or in all Tamil text? Do they remain italicized if you log out of Wiktionary? —Michael Z. 2013-09-12 21:13 z

I don't know why "font-style: normal" is struck out (but unstriking it has no effect). I only see this with the Taml class and I don't think I have any custom CSS active. It remains if I log out (this is on Windows). DTLHS (talk) 21:26, 12 September 2013 (UTC)

Or try leaving the font list activated, but edit the list. Remove the first font name and see if the oblique text changes and becomes upright – If so, then maybe the font you removed only shows italics. If not, then remove the second font name, and so on, until you find which one was in effect. —Michael Z. 2013-09-12 21:22 z

Removing Vijaya from the list fixes it. DTLHS (talk) 21:26, 12 September 2013 (UTC)

After a little research, it looks like Vijaya, ETTamilNew, and Arial Unicode MS all have some slant in the default “roman” version. The first is included in at least Windows 7 and 8, and the third is included in some versions of MS Office, in Mac OS X 10.5 and newer, and has been freely downloadable in the past. It looks like these fonts are designed to give some sense of cursive style, and I think the slant is exaggerated at the tiny font-size in your browser.

Should we remove these fonts from the style sheet for .Taml script? —Michael Z. 2013-09-12 21:39 z

Of course slanted doesn't make much sense, but I was under the impression that the language community likes the slanted style (hence why the Latha font is at the very end of the list), so I dunno. -- Liliana • 12:53, 15 September 2013 (UTC)

Hi. The automatic edit summary from rollbacks says something like "if you disagree, please leave a message on my talkpage". Could someone please change it to say "talk page" with a space? This is how Mediawiki spells the term everywhere else. Equinox ◑ 02:24, 12 September 2013 (UTC)

Done. --Yair rand (talk) 03:16, 12 September 2013 (UTC)

What is happening with translations? Very often it's impossible to unhide them; the show key is missing. I just visited bass and I had to look at the source to find the translation I wanted. Is it only my problem? I'm using Firefox 23.0.1 --flyax (talk) 17:26, 14 September 2013 (UTC)

I think it may be related to the ULS problem above. The script is crashing which then takes all other scripts with it. Something like that? —CodeCat 17:33, 14 September 2013 (UTC)

Yes, and some other features also seem to be broken. Like the diff radio unhiding, making them almost unusable. I also mentioned a bit less invasive fix above. Keφr 17:38, 14 September 2013 (UTC)

Has the less invasive fix been tested in anyone's common.js? Is it ready for site-wide deployment? DCDuring TALK 18:05, 14 September 2013 (UTC)

I tried it on Wikipedia, it seems to do its job with less collateral damage. Keφr 18:27, 14 September 2013 (UTC)

I'll guinea-pig it here, though I haven't experienced as many problems as others. DCDuring TALK 18:40, 14 September 2013 (UTC)

It will be useless, unless we disable the global ULS killer. Keφr 18:52, 14 September 2013 (UTC)

I've copied your current WP version to MediaWiki:Common.js. Let me know if you want me to wrap it in some sort of "if(user is not Kephir) {...}" so you can test more flexibly using User:Kephir/common.js. —Ruakh_TALK 19:24, 14 September 2013 (UTC)

My gadgets don't seem to be running. Can't open translations or see the quote unhider. The site notice and logo are back too. I think I'll go read. DCDuring TALK 22:07, 14 September 2013 (UTC)

Now some things are back, but not things from my gadgets. DCDuring TALK 22:10, 14 September 2013 (UTC)

WT:PREFS or actual gadgets? Keφr 22:16, 14 September 2013 (UTC)

I got a bit confused because some items appear in both per-browser and per-user preferences. My specific problems seem to be with the per-browser preferences. And on trying to open them, I didn't see the list of items and checkboxes. I have had the boxes checked to suppress the site notice and the logo and to display special characters under the search box. None of that is working. DCDuring TALK 23:01, 14 September 2013 (UTC)

And once more I have serif scripts appearing for text in templates that use the script templates, but not in those that rely on Latn being the default script. That makes me think that the new common.js is either not yet effective or is defective in some way. DCDuring TALK 23:40, 14 September 2013 (UTC)

O.K., I've reverted the change. I'm sorry; I really should have tested it here myself first, rather than assuming that Kephir's successful tests at en.wiki would translate into success here. —Ruakh_TALK 03:00, 15 September 2013 (UTC)

It's not the kind of thing that breaks everything. You could say it was a successful field test: We learned that something doesn't work. Also that the problem effects small entries as much as big ones. I've learned that templates that bypass our script-and-language system are not subject to the problem. {{taxoninfl}} was not effected but {{mul-proper noun}} was on the same entry. {{taxoninfl}} is incredibly basic, because the application has no need for language/script functionality. DCDuring TALK 03:37, 15 September 2013 (UTC)

It's back again. I'm converting a lot of {{mul-proper noun}} to {{taxoninfl}}, those I edit for other reasons and those that I wanted to change eventually. DCDuring TALK 23:56, 17 September 2013 (UTC)

Yes, the global ULS killer has been disabled because of all the unfortunate side effects. I guess the snipped which undoes what ULS does can be enabled safely, but I am not sure how to prevent it from starting in the first place without breaking anything else. Keφr 06:53, 18 September 2013 (UTC)

I've had to use the webfont killer you use. I haven't had bad side-effects and almost everything works. As I only edit Translingual and English and don't push the limits, I'm not much of a test case, but I do whine vocalize about my problems. DCDuring TALK 16:51, 21 September 2013 (UTC)

These templates are not working. See рассказчик, идти. Maybe it’s the "hide" function that is no longer supported? Everything is hidden, but cannot be opened. —Stephen ^(Talk) 21:38, 14 September 2013 (UTC)

It's the same problem as above. But forcing a refresh has fixed it for me. —CodeCat 21:39, 14 September 2013 (UTC)

Hmm. Refreshing does not help me. —Stephen ^(Talk) 22:35, 14 September 2013 (UTC)

The tab is not showing up for me. I see it in the preview screen, but it's not there after I save. bd2412 T 22:09, 14 September 2013 (UTC)

Again this is probably the same as above. Nothing that uses JS works right at the moment. —CodeCat 22:11, 14 September 2013 (UTC)

God damned bastards. bd2412 T 22:12, 14 September 2013 (UTC)

Having recently returned to editing Latin, I tried using the edit tool in which you click on a character (with macrons in this case) at the bottom of the edit page. Nothing happens. I have to copy/paste the character instead. Is this yet another manifestation of the above problems? If so, when are they going to be fixed? SemperBlotto (talk) 07:13, 15 September 2013 (UTC)

Yes it's the same problem as #Adding IPA characters/other symbols not working properly above. By the way I use the enPR section for the macrons ā ē ī ō but it doesn't have ū or ȳ. Mglovesfun (talk) 13:22, 15 September 2013 (UTC)

I had the same problem and it was fixed after going to "Language settings" > "Input" > "Disable input tools" > "Apply settings" --Z 13:38, 15 September 2013 (UTC)

I'm experimenting with Lua, trying to write a module producing the sortkey for Romanian entries. Unfortunately, it seems that Lua cannot handle the Romanian ș as a UTF-8 character. For example, mw.ustring.sub("șurub",1,1) gives the following error: bad argument #1 to 'sub' (string is not UTF-8). Any idea? --flyax (talk) 21:57, 15 September 2013 (UTC)

I just tried it in the console, and it worked. Keφr 22:06, 15 September 2013 (UTC)

You are right. The problem is totally different. Here is a piece of my code:

p = {}
--Remove a certain character from a string
function stripchars( str, chr )
    local s = ""
    for g in str:gmatch( "" ) do
        s = s .. g
    end
    return s
end

p.rom = function(word)
    local mystring = stripchars(word,"’")
    return mw.ustring.sub(mystring,1,1)
end

return p

The idea was to remove commas, apostrophes etc prior to construct the sortkey. So, trying to remove the "’" character from the word șurub renders it untreatable. Or at least I think so. I'm sorry I got a wrong conclusion, but still there is a mystery for me here. Try print(p.rom('șurub')) in the console. --flyax (talk) 23:02, 15 September 2013 (UTC)

We already have a mechanism for generating sort keys though. It's in Module:languages. —CodeCat 23:11, 15 September 2013 (UTC)

I know that, however, as I said, I'm experimenting. There is something weird here, isn't it? --flyax (talk) 23:20, 15 September 2013 (UTC)

I think I see at least a possible issue. You've used string.gmatch, but that only searches for individual bytes, not UTF-8 characters. So if chr is a multibyte UTF-8 character, then it searches for all of the bytes that make up chr individually. Try using mw.ustring.gmatch? —CodeCat 23:32, 15 September 2013 (UTC)

Yup, exactly. (Or, almost exactly: "UTF-8 character" is not really precise; something like "UTF-8-encoded characters" would be more accurate. But, close enough.) The problem is that although U+2019 RIGHT SINGLE QUOTATION MARK does not appear in word, the third byte of its UTF-8 representation is 153 (hex 99), which is also the second byte of the UTF-8 representation of U+0219 LATIN SMALL LETTER S WITH COMMA BELOW. So, when Flyax edits word to remove all the bytes that appear in the UTF-8 representation of the quotation-mark, (s)he removes part of the UTF-8 representation of the S-with-comma.
In addition, stripchars is more complex than it needs to be; it can be written as just mw.ustring.gsub(word, '', ''), and personally I'm not sure it really needs to be its own function. (And if it is going to be its own function, then I think some care is needed to escape the contents of chr.)
—Ruakh_TALK 07:25, 16 September 2013 (UTC)

It seems I have to try another approach to solve my problem. Thank you all for the immediate and detailed answers. --flyax (talk) 10:54, 16 September 2013 (UTC)

FYI: mw:Thread:Project:Support_desk/Site_accessibility_for_blinds (I've told the user to look for an answer here, in case en.wikt is the Wiktionary in question). Nemo 08:42, 16 September 2013 (UTC)

I wonder if that screen reader understands CSS, and just skips elements which are styled as display: none (as they are by default, with JavaScript enabled). Technically, display should not affect screen readers and speak: none; should be the style to make them skip an element, but since nobody cares for non-visual media on the Web, screen readers have to resort to such hacks. Keφr 10:12, 16 September 2013 (UTC)

I've forwarded this information to the user and asked more pointers to help us debug the problem. The software in question is JAWS For Windows, 9.0, with Internet Explorer 8.0.6001.18702. She speaks Italian. Nemo 19:47, 17 September 2013 (UTC)

Could the problem be JavaScript issues? (Specifically — the same JavaScript issues that those of us with visual user agents have been encountering, due to ULS and anti-ULS?) —Ruakh_TALK 19:52, 17 September 2013 (UTC)

Most screen readers let the browser render the page with all of its CSS and JavaScript, and then navigate the resultant DOM (document object model) in the browser window. I think few, if any, support CSS speech declarations. So if a table is collapsed and lacking an “expand” button, everyone is S.O.L. Sounds like that was what happened in this case. —Michael Z. 2013-09-18 18:27 z

Yes, the screen reader in question was JAWS on IE8. From what I heard about JAWS, it works pretty much the way you just described.

And it seems it is yet another innocent victim of our ULS killer kludge. I wrote a new version, this time trying to not break anything. Please test. Keφr 19:21, 18 September 2013 (UTC)

Just a shot in the dark...I wonder if this could be due to the recent URL change from http to https. I have found some Firefox addons that no longer work properly, and I think the reason is the https. —Stephen ^(Talk) 23:28, 18 September 2013 (UTC)

Thanks Keφr, it's fixed now. --Nemo 12:58, 20 September 2013 (UTC)

When I click the signature button, I just become taken to the top of the page. Nothing is inserted. This has been occurring for about a week or two now, and I am becoming tired of pasting a premade signature in. My keyboard is modified so that I type ∼ and not ~. —Æ&Œ (talk) 18:09, 17 September 2013 (UTC)

Works for me: --—Angr 18:57, 17 September 2013 (UTC). Something to do with your browser, perhaps? —Angr 18:57, 17 September 2013 (UTC)

It doesn't work for me, either. I'm using Chrome on Snow Leopard. BB12 (talk) 19:04, 17 September 2013 (UTC)

Is there anything in the Error console output when you click (if your browser has something like that)? For Chrome, see https://developers.google.com/chrome-developer-tools/ --AKlapper (WMF) (talk) 19:25, 17 September 2013 (UTC)

On other Wiki projtects, the button functions finely, so I’m not sure how Opera is relative to this. —66.190.69.246 19:33, 17 September 2013 (UTC)

Works fine for me in Opera 12.16 (the latest version). Equinox ◑ 19:36, 17 September 2013 (UTC)

--Z 19:44, 17 September 2013 (UTC) <-- worked (FF).

Let me guess: our ULS killer kludge. It has been globally enabled without perhaps rigorous enough testing. It has several ill side effects. And yet we would rather choose to suffer them over ULS. This should tell you something, WMF people. Keφr 19:48, 17 September 2013 (UTC)

It functions finely now. Not sure what you guys did. Only complaint is that I wish that the two dashes were just —. --Æ&Œ (talk) 20:17, 17 September 2013 (UTC)

For the record, it works for me, now, too. --BB12 (talk) 18:48, 18 September 2013 (UTC)

If you want — in your signature, just go to preferences and change your signature to —Æ&Œ. —Stephen ^(Talk) 23:32, 18 September 2013 (UTC)

I was talking about what the button itself generates. --Æ&Œ (talk) 23:36, 18 September 2013 (UTC)

For some time, I have been annoyed by Tabbed Languages not working at random. So I decided to investigate. And today I found the cause.

The problem is a simple race condition. There is a newNode function defined in MediaWiki:Common.js, and MediaWiki:Gadget-DefSideBoxes.js is making use of it. But MediaWiki:Common.js is not guaranteed to run before it. When the gadget runs fist, it fails to work, and takes everything with it. The simplest fix would be to copy the newNode function into it. And maybe some others, because I have not really read the code very carefully.

Another problem I have been noticing for quite a while: Tabbed Languages and autocollapsing tables do not work very well with dynamic preview. Someone needs to hook $(mw).bind('LivePreviewDone', function () { /* ... */ });. I would also like an option to keep them expanded by default.

Keφr 12:53, 19 September 2013 (UTC)

Does JavaScript not have a "require" function that we could use? That way we would avoid duplicating the code but still guarantee that one part is loaded before the other. —CodeCat 12:55, 19 September 2013 (UTC)

No such thing built-in. Welcome to JavaScript, the second-worst programming language in existence. I think MediaWiki ships with facilities which provide something similar, but it relies on callbacks, and I have not really studied it. Keφr 13:11, 19 September 2013 (UTC)

Are you sure about your explanation? It doesn't make a lot of sense to me: MediaWiki:Gadget-DefSideBoxes.js does everything inside jQuery(document).ready(function () { ... }), which shouldn't run until after MediaWiki:Common.js has already added newNode. No? —Ruakh_TALK 14:43, 19 September 2013 (UTC)

I am pretty damn sure. I looked up the error in the console and the message was "newNode is not defined". Tracing it back to MediaWiki:Gadget-DefSideBoxes.js was kinda tricky, with all the indirection, minifying and error catching, but I finally got it. Perhaps we could update our scripts to use mw:ResourceLoader. Or something. Keφr 15:08, 19 September 2013 (UTC)

Another broken gadget: MediaWiki:Gadget-FastRevert.js throws a TypeError: "Cannot read property '1' of null" when processing the last list element. May be related to radio buttons not unhiding on history pages. Keφr 16:14, 19 September 2013 (UTC)

I just realised why the radio buttons stopped dis-/re-appearing as they should. Jesus H. W. Christ, innerHTML... This gadget seriously needs to be rewritten from scratch or removed. Keφr 14:18, 20 September 2013 (UTC)

Can anyone explain why so many things seem broken here (apparently not just for me), but rarely seem so on the other MW sites that I visit Wikispecies, WP, and Commons? The problems vary, pop up irregularly, and seem resistant to lasting fixes. They seem to have gotten much, much worse in the last weeks. Why would that be?

To blame MW seems silly. Their software is our foundation and their servers hosts us at no cost. What is it about our "enhancements" that has become so problematic lately? Do we have the technical resources to get answers and solve the problems or do we need to beg for help from MW? DCDuring TALK 14:56, 19 September 2013 (UTC)

MW = MediaWiki ≠ Wikimedia Foundation = WMF. Nevertheless, I think this is true at least in part. We use quite a lot of JavaScript code written ages ago, which may be using deprecated features and definitely does not use modern practices which are supposed to ensure proper modularisation and better reliability of scripts. There are few people here — too few — who are able to maintain it. Part of it can be probably blamed on the ULS killer which was a quite brutal kludge (it stopped ULS from functioning by triggering a runtime error) and, in retrospect, should have been tested with more care before enabling it globally.

That said, I think WebFonts actually is buggy (it seems to set the font-family style of each element with a lang attribute to "sans-serif") and should be disabled for now. And even after it is fixed, it should have an opt-out — or better, opt-in — even after it is fixed. I think we should be quite angry that the WMF forces certain solutions on us without first asking whether we have already dealt with the issue (like the fonts problem; our script templates worked quite fine and allowed for various customisations, which cannot be said about WebFonts: it is "either use one of the options we provide, or disable JavaScript completely"). Maybe the VisualEditor fiasco has taught them a lesson.

But perhaps not. I have seen people mention "Wikidata" a few times, but I am yet to see anybody from the WMF to actually come here and explain why and how. Instead of putting out decrees saying "this is the way you will do it from now onward, and if you dislike it, go fuck yourself". (WebFonts again.) Keφr 15:23, 19 September 2013 (UTC)

I get the impression that WMF does not have limitless technical resources to handle the problems that they've got, so I'm not surprised that en.wikt, far less popular than pedia, gets the short end.

It is a question of how we can best go forward. If we do not have the resources to do things as we have been, when we had more resources; apparently, a somewhat simpler technical environment; and probably demanded less of the software, do WE need to change? Do we need to seek accommodation with the current bugginess of WebFonts and throw over our possibly unsustainable self-reliance? DCDuring TALK 15:55, 19 September 2013 (UTC)

But if the WMF, due to limited resources, is going to treat us like a redheaded stepchild like you say, we will have to be self-reliant to some extent anyway. And if we give up our JavaScript helpers (like WT:EDIT), we might lose some pretty valuable casual, unregistered contributors, who might be scared away by raw markup. We just cannot afford that. Another reason why we probably should migrate to some kind of a semantic database: only then easy and reliable editing tools will be possible. Another reason why we should harmonise our markup into a more machine-readable form, use more templates and as an unfortunate side effect make it somewhat more non-obvious — because that will make the eventual migration easier. Otherwise this wiki may collapse under the sheer maintenance burden. Yes, Wikidata could be a step in the right direction. But since nobody is now talking about how it will look like, I predict a disaster like with the VE. It was too in part a communication failure, and in part (WMF) developer arrogance. Keφr 16:13, 19 September 2013 (UTC)

For my better understanding, can I get recent examples of communication where WMF treated Wiktionary like a redheaded stepchild? --AKlapper (WMF) (talk) 16:33, 19 September 2013 (UTC)

Rest assured that there is also enough brokenness on other sites. To comment on some points here: Webfonts: https://www.mediawiki.orghttps://dictious.com/en/Universal_Language_Selector/FAQ#Can_I_change_the_font_for_the_language covers how to change a font (as a workaround). If there are specific issues with webfonts, a bug report with good steps to reproduce (and screenshot) is very welcome. My impression is that WMF's Language Engineering team cares about community feedback (and you are free to disagree). If there are existing bug reports in Wikimedia's bugtracker with a "go fuck yourself" attitude then please point out the numbers so I can take a look myself. Wikidata: I'm confused - Why is somebody from the WMF expected to come and explain Wikidata instead of people, if you say that "people" have mentioned Wikidata before? I am aware of regular IRC office hours, talk pages, and other outreach and communication by/with the Wikidata team (which is not even related to WMF in case that somebody assumed, so the expectation that somebody from the WMF should come feels even weirder to me as they might not have the expertise), and I wish that you have brought up your Wikidata related questions to the Wikidata team in order to get heard and to get more information, or that you plan to. In general: If there are specific technical problems on Wiktionary which are due to changes in MediaWiki software or Wikimedia server configurations, feel free to drop me a line and I'll see what I can do. I try to take a look here from time to time but there are also many other places where I try to get an overview of issues. In general I am interested to get bugs into the bugtracker at https://bugzilla.wikimedia.org so developers (may they be WMF staff or may they be volunteers; I don't like that "we vs. them" tone that is sometimes between the lines) get aware of them. Thanks! (Disclaimer: I work for the WMF and my comment here is my personal opinion and should not be interpreted as something "official" or such. I'm an individual, just sayin'.) --AKlapper (WMF) (talk) 16:30, 19 September 2013 (UTC)

I just expressed a frustration (that I think some editors share here, and at Wikipedia), of WMF's apparent practice of developing features, putting them on wikis and just leaving the community out there to figure them out. WebFonts is an pretty good example here. It just arrived one day, fonts broke and no one knew why.

The initial VisualEditor roll-out was a complete catastrophe. It was not marked as an experimental feature it clearly was, the old editing option was hidden under an inconvenient and annoying interface, it broke people's habits, requests to rectify these flaws or create an opt-out were repeatedly denied, or people were referred to an ugly hack of a gadget. They were basically forcing people to use it. And XKCD #1172 aside, this is the worst thing you can do to a user interface. The WMF also seemed to be rushing to deploy it as soon as possible, without caring about bugs. Only after people started rioting on the talk pages, the developers have addressed the issues. Now that VE is quite bearable, almost nobody uses it. I imagine that the initial backlash is part of the reason.

The same thing with ULS: requests to make it go away completely were repeatedly denied on Bugzilla. It is either put up with it, give up JavaScript altogether, or just go somewhere else. I have no Bugzilla account myself; I have no e-mail under this identity. I might have reported this if I had one, but the tone of the discussions there is surely discouraging. We at Wiktionary have no rioting editors. But we have coders. So we fight code with code. Yes, this is unfortunately a fight, a fight that we would rather not be having. (On the plus side, I will note that mw:Flow seems to be better-discussed with the community. There is some hope. Although you cannot please everyone, so expect some disgruntled editors anyway.)

And it seems now quite warranted to suspect that the migration to Wikidata (a potentially beneficial step, I shall not deny) is heading in the same direction. Somebody mentioned it above — I am quite sure that some people asked in their minds "WTF is Wikidata?". At d:Wikidata talk:Wiktionary I see none of the regulars from here. There is hardly any communication, so do not expect cooperation. Another problem is that the whole thing is seemingly designed like a massive overhaul of everything at once. I do not believe in revolutions. I prefer incremental improvements. I proposed an iterative scheme of migration to a semantic database a few months earlier on WT:GP, maybe you can find it somewhere. (Look for coöperation with an umlaut.) Keφr 17:37, 19 September 2013 (UTC)

The conflict quite often seems to be how much influence on technical decisions the community vs. WMF have (or maybe even "the final word"). Personally I believe that ULS (webfonts and input methods) helps many people to be finally able to read and edit Wikimedia wikis without additional cumbersome fiddling with fonts) but I can see that for some other people it's rather useless. From a development point of view, removing ULS completely is not an option but here starts the philosophical question "How much can communities decide against either specific feature changes (functionality level) planned by WMF, or even against specific deployments of extensions (technical level) planned by WMF? Personally I don't know the answer either. So yeah, to some extend I share your point. :-/ --AKlapper (WMF) (talk) 12:53, 24 September 2013 (UTC)

Speaking as a non-techie, I think that the story is that WMF didn't well support the range fonts that Wiktionary needed at an early stage, forcing en.wikt to pioneer an elaborate system to provide that support, in which we have a substantial investment of manpower. Now we seem to have to throw much of that away to adapt to ULS and Webfonts, which also seem to create problems with our JS. I am reasonably sure that wiktionaries have more of that kind of investment than any of the sister projects. How are wiktionaries like de and fr are accommodating ULS and Webfonts? Have they made as much pre-ULS, pre-Webfont investment in methods of handling fonts? DCDuring TALK 14:07, 24 September 2013 (UTC)

The script-class system was developed before anyone supported any fonts, because there were no practical web fonts. It was mainly created for MSIE 6 because that browser was too brain-dead to even render all of the characters even when it had the fonts. In my opinion, the “investment in manpower” is largely wasted, because there is no testing and documentation, so there are likely scores of pointless font declarations in our CSS. The system only helps a dedicated minority who bother to research, download, and install the required fonts (we don’t even help them by documenting the requirements).

Text should just work. That is a feature for the Web as it is designed, and I can’t wait until our whole mess of workarounds is minimized or eliminated.

I suggest we help expand the docs for ULS by document the Unicode range for each of the installed fonts. When we know what works and what doesn’t, we can start paring down our code and requesting the fonts that are lacking. Thus we make the software work for us, and improve it for everyone. —Michael Z. 2013-09-24 20:11 z

I started the list at mw:Universal Language Selector/FAQ#What fonts are included?. I would like to start checking the fonts for language/Unicode block support, and documenting it there. —Michael Z. 2013-09-24 20:27 z

Wasted investment or not, some seem to have an emotional commitment to our current way of doing things and a visceral dislike of ULS/Webfonts. I am trying to understand that.

Can Wiktionary afford to continue down a path that requires a massive technical effort. The effort seems so massive that it seems not leave any time for documentation suitable for anyone other than the handful of those actively engaged nor for fixing things that go wrong. DCDuring TALK 21:33, 24 September 2013 (UTC)

The automatic edit summary doesn't use the new language tools. For example, a translation I made for ] shows "эпизо́д" in red, as if the entry doesn't exist, not "эпизод", as it should in my opinion, or it should show эпизо́д - displayed diacritics but links without. --Anatoli ^{(обсудить}/^вклад) 00:45, 20 September 2013 (UTC)

The reason for this is that the new language tools do not expose any interface for use by client-side JavaScript, so WT:EDIT has no way of knowing that {{t-|ru|эпизо́д|m|sc=Cyrl}} means {{t-|ru|эпизод|m|alt=эпизо́д|sc=Cyrl}}. (This is the same reason that WT:EDIT selected {{t-}} rather than {{t+}}: ru:эпизод exists, but ru:эпизо́д does not, and WT:EDIT had no way of knowing that the latter is what counts.) I hope to fix it in the next few days; in the meantime, if you want the right language-template to be used, and the right form to show up in the edit-summary, you'll just need to continue to specify the pagename when adding the translation, like you used to do before the new language tools existed. (Up to you.) —Ruakh_TALK 14:38, 20 September 2013 (UTC)

Is it part of the whole ULS / WikiFonts problem that I can no longer see Gothic words in the Gothic font on my computer, as I was used to, but only a sequence of squares? Is there something I can do about this? --Pereru (talk) 09:58, 20 September 2013 (UTC)

Probably. A new iteration of the disabling script has been put in MediaWiki:Common.js, but it is enabled only for two admins, to test. You can copy the code to your own User:Pereru/common.js. Please report any problems that arise. Keφr 10:07, 20 September 2013 (UTC)

Just to say 'me too', been able to see Gothic for months now, and suddenly nothing. Mglovesfun (talk) 11:03, 20 September 2013 (UTC)

This is really getting out of hand. Maybe we should organize a strike to protest against this, if they won't listen to us any other way. —CodeCat 12:42, 20 September 2013 (UTC)

Erm, pot, kettle! Mglovesfun (talk) 13:52, 20 September 2013 (UTC)

What is an "erm"? Keφr 13:58, 20 September 2013 (UTC)

erm. —Aɴɢʀ (talk) 15:25, 20 September 2013 (UTC)

Erm... I am still in the dark. (By the way, I made an update, I have it in User:Kephir/common.js.) Keφr 15:44, 20 September 2013 (UTC)

I'm accusing the pot of calling the kettle black. Mglovesfun (talk) 16:48, 20 September 2013 (UTC)

Add yourselves to the list, hard-refresh and test. Thoroughly. When you think it is ready, enable it globally. I am powerless to do anything else. Keφr 13:45, 20 September 2013 (UTC)

I'm disappointed that no other admins have added themselves to the test (in the first few lines of MediaWiki:Common.js). If ULS/WebFonts bothers you, the solution is to help test that, so we can turn it on for everyone. —Ruakh_TALK 15:53, 20 September 2013 (UTC)

Would it be an option to embrace the ULS instead? Do we even know how to configure how it specifies fonts? Since it is part of MW going forward, can’t it replace the complex web of CSS that we are using? —Michael Z. 2013-09-20 16:07 z

Oh, we know — we cannot. The choice is between "System fonts" (which actually means overriding everything to "sans-serif") and "OpenDyslexic". If there were any choice, we would have probably found them now. (But try figuring out yourself: mw:Extension:UniversalLanguageSelector. Some configuration options seemingly exist, which determine how WebFonts chooses fonts, but I could not find any documentation, and they apparently cannot be set from JavaScript. At least not more elegantly than the disabling script does its business.) Keφr 16:32, 20 September 2013 (UTC)

I've added the code in question to my common.js page, and voilà -- the Gothic fonts are back! As are the Old Church Slavonic fonts. Thanks for the tip! (Should I, by the way, simply add myself to the list at MediaWiki:Common.js instead of to my own commons.js page? Would that be better?) --Pereru (talk) 16:44, 20 September 2013 (UTC)

Yes, it would be better for you to add yourself to MediaWiki:Common.js rather than copying the code to your Special:MyPage/common.js: the goal here is to enable this code for everyone, and in order to help with that goal, you have to be participating in the shared test. (When there are race conditions, we can't just assume that testing in your own user JS will always give the same results as testing in sitewide JS.) —Ruakh_TALK 19:12, 20 September 2013 (UTC)

I added myself, in spite of misgivings about getting the syntax right, and unfamiliarity with the quirks of the user interface in the edit box. I thought quitting Firefox would be enough to clear the cache, but when I went to water and expanded the translations, the Burmese webfont crashed my browser as it always does. After restarting, though, I was able to view the translations with no problems, and even Category:Burmese nouns. So far no side-effects. Chuck Entz (talk) 19:59, 20 September 2013 (UTC)

I have had some but not all of the problems others have had with Webfonts / the Webfont-killing kludges. Nothing flickers when I load pages (though people on other wikis complain that Webfonts makes something flicker, appearing/loading and then disappearing when it realises it's not wanted). I can still see Burmese and Gothic. OTOH, Old Church Slavonic does show up in a Cyrillic/thin/type-style font rather than an OCS/thick/manuscript-style font, and some words appear in a font slightly larger than Russian's, whilst others appear in a font slightly smaller. Also, Tamil did show up in a small and slanted font for me back when DTLHS started this discussion, but it now shows up in a large, upright font. I'll add myself to the common.js test and see what changes. - -sche (discuss) 20:12, 21 September 2013 (UTC)

With the Webfonts-killer enabled, I find that Tamil is small and slanted again. OTOH, Old Church Slavonic is now thick again (i.e. it displays in a OCS/manuscript-style font). Gothic is unchanged. Burmese is now broken, with some characters displaying as boxes (but other characters displaying correctly). I could upload screenshots if necessary. - -sche (discuss) 20:38, 21 September 2013 (UTC)

Have you got the appropriate fonts installed on your computer? What is your browser? Etc. Keφr 20:45, 21 September 2013 (UTC)

I'm using Firefox 23 in Windows 7. Of the Tamil fonts listed in Mediawiki:common.css, I had only Akshar Unicode, Code2000 and Arial Unicode MS; of the Gothic fonts, I had only Code2001 and MPH 2B Damase. I didn't have any of the listed Burmese fonts. For OCS, I had only Dilyana, Code2000, DejaVu Sans, Arial Unicode MS, Lucida Sans Unicode. Of the fonts listed here, I have only Akkadian, DoulosSIL, GentiumPlus, Jomolhari, Junicode, LohitPunjabi, UnifrakturMaguntia (and Unifraktur Maguntia... hmm...). - -sche (discuss) 21:41, 21 September 2013 (UTC)

I have installed InaiMathi, TharLon Regular, Padauk and BukyVede. With the ULS-killer enabled, Gothic is unchanged (still works, has always worked). Burmese works again (good). Tamil still displays in a small, slanted font (presumably bad). OCS displays in the same thick/manuscript-style font (good).

If I disable the ULS-killer (while keeping all the new fonts installed), Gothic is still unchanged (good), Burmese continues to work (good), Tamil displays in a large, upright font again (presumably good), and OCS is back to a "thin" font (bad).

So, on the whole, everything works better with the ULS-killer enabled, now that I have installed more fonts. The only exception is Tamil, and that may just be a matter of preference (since both the italic font and the upright font are presumably legible to anyone who can read Tamil script). - -sche (discuss) 21:41, 21 September 2013 (UTC)

I think some people above determined that the "italic" font is Arial Unicode MS. But I have not checked myself, I do not have it. (For me, தமிழ் (tamiḻ) displays in Code2000.) Keφr 07:05, 22 September 2013 (UTC)

Also, you can download the fonts that the WMF provides through WebFonts. They are in https://bits.wikimedia.org/static-1.22wmf17/extensions/UniversalLanguageSelector/data/fontrepo/fonts/ — instead of the listing you get the 403 error, but you can look at the WebFonts JS and extract the list of available fonts from there. We may also write a CSS gadget to make them available. See below. Keφr 07:36, 22 September 2013 (UTC)

{
	"AbyssinicaSIL": {
		"version": "1.200",
		"license": "OFL 1.1",
		"eot": "AbyssinicaSIL/AbyssinicaSIL-R.eot",
		"ttf": "AbyssinicaSIL/AbyssinicaSIL-R.ttf",
		"woff": "AbyssinicaSIL/AbyssinicaSIL-R.woff"
	},
	"Akkadian": {
		"version": "2.56",
		"license": "George-Douros",
		"eot": "Akkadian/Akkadian.eot",
		"ttf": "Akkadian/Akkadian.ttf",
		"woff": "Akkadian/Akkadian.woff"
	},
	"Alef": {
		"version": "1.0",
		"license": "OFL 1.1",
		"ttf": "Alef/Alef-Regular.ttf",
		"eot": "Alef/Alef-Regular.eot",
		"woff": "Alef/Alef-Regular.woff",
		"variants": {
			"bold": "Alef Bold"
		}
	},
	"Alef Bold": {
		"version": "1.0",
		"license": "OFL 1.1",
		"fontweight": "bold",
		"ttf": "Alef/Alef-Bold.ttf",
		"eot": "Alef/Alef-Bold.eot",
		"woff": "Alef/Alef-Bold.woff"
	},
	"Amiri": {
		"version": "1.0.2",
		"license": "OFL 1.1",
		"ttf": "amiri/amiri-regular.ttf",
		"eot": "amiri/amiri-regular.eot",
		"woff": "amiri/amiri-regular.woff",
		"variants": {
			"bold": "Amiri Bold",
			"bolditalic": "Amiri Bold Italic",
			"italic": "Amiri Italic"
		}
	},
	"Amiri Bold": {
		"version": "1.0.2",
		"license": "OFL 1.1",
		"fontweight": "bold",
		"ttf": "amiri/amiri-bold.ttf",
		"eot": "amiri/amiri-bold.eot",
		"woff": "amiri/amiri-bold.woff"
	},
	"Amiri Bold Italic": {
		"version": "1.0.2",
		"license": "OFL 1.1",
		"fontweight": "bold",
		"fontstyle": "italic",
		"ttf": "amiri/amiri-boldslanted.ttf",
		"eot": "amiri/amiri-boldslanted.eot",
		"woff": "amiri/amiri-boldslanted.woff"
	},
	"Amiri Italic": {
		"version": "1.0.2",
		"license": "OFL 1.1",
		"fontstyle": "italic",
		"ttf": "amiri/amiri-slanted.ttf",
		"eot": "amiri/amiri-slanted.eot",
		"woff": "amiri/amiri-slanted.woff"
	},
	"AnjaliOldLipi": {
		"version": ".0.730",
		"license": "OFL 1.1",
		"eot": "AnjaliOldLipi/AnjaliOldLipi.eot",
		"ttf": "AnjaliOldLipi/AnjaliOldLipi.ttf",
		"woff": "AnjaliOldLipi/AnjaliOldLipi.woff"
	},
	"CharisSIL": {
		"version": "4.011",
		"license": "OFL 1.1",
		"eot": "CharisSIL/CharisSIL-R.eot",
		"ttf": "CharisSIL/CharisSIL-R.ttf",
		"woff": "CharisSIL/CharisSIL-R.woff"
	},
	"Doulos SIL": {
		"version": "4.112",
		"license": "OFL 1.1",
		"eot": "DoulosSIL/DoulosSIL-R.eot",
		"ttf": "DoulosSIL/DoulosSIL-R.ttf",
		"woff": "DoulosSIL/DoulosSIL-R.woff"
	},
	"East Syriac Adiabene": {
		"version": "1.21",
		"license": "East Syriac Adiabene License",
		"eot": "EastSyriacAdiabene/SyrCOMAdiabene.eot",
		"ttf": "EastSyriacAdiabene/SyrCOMAdiabene.ttf",
		"woff": "EastSyriacAdiabene/SyrCOMAdiabene.woff"
	},
	"Estrangelo Edessa": {
		"version": "1.21",
		"license": "Estrangelo Edessa License",
		"eot": "EstrangeloEdessa/SyrCOMEdessa.eot",
		"ttf": "EstrangeloEdessa/SyrCOMEdessa.ttf",
		"woff": "EstrangeloEdessa/SyrCOMEdessa.woff"
	},
	"FreeFont-Thaana": {
		"version": "1.0",
		"license": "GPL 3",
		"ttf": "FreeFontThana/FreeFont-Thaana.ttf",
		"eot": "FreeFontThana/FreeFont-Thaana.eot",
		"woff": "FreeFontThana/FreeFont-Thaana.woff",
		"variants": {
			"bold": "FreeFont-Thaana Bold"
		}
	},
	"FreeFont-Thaana Bold": {
		"version": "1.0",
		"license": "GPL 3",
		"fontweight": "bold",
		"ttf": "FreeFontThana/FreeFont-Thaana-Bold.ttf",
		"eot": "FreeFontThana/FreeFont-Thaana-Bold.eot",
		"woff": "FreeFontThana/FreeFont-Thaana-Bold.woff"
	},
	"GentiumPlus": {
		"version": "1.510",
		"license": "OFL",
		"ttf": "GentiumPlus/GentiumPlus-R.ttf",
		"eot": "GentiumPlus/GentiumPlus-R.eot",
		"woff": "GentiumPlus/GentiumPlus-R.woff",
		"variants": {
			"italic": "GentiumPlus Italic"
		}
	},
	"GentiumPlus Italic": {
		"version": "1.510",
		"license": "OFL",
		"fontstyle": "italic",
		"ttf": "GentiumPlus/GentiumPlus-I.ttf",
		"eot": "GentiumPlus/GentiumPlus-I.eot",
		"woff": "GentiumPlus/GentiumPlus-I.woff"
	},
	"Gubbi": {
		"version": "1.3",
		"license": "GPLv3+",
		"eot": "Gubbi/Gubbi.eot",
		"ttf": "Gubbi/Gubbi.ttf",
		"woff": "Gubbi/Gubbi.woff"
	},
	"Iranian Sans": {
		"version": "1.0",
		"license": "IranianSans",
		"eot": "IranianSans/IranianSans.eot",
		"ttf": "IranianSans/IranianSans.ttf",
		"woff": "IranianSans/IranianSans.woff"
	},
	"Jomolhari": {
		"version": "0.003",
		"license": "OFL 1.1",
		"eot": "Jomolhari/Jomolhari.eot",
		"ttf": "Jomolhari/Jomolhari.ttf",
		"woff": "Jomolhari/Jomolhari.woff"
	},
	"Junicode": {
		"version": "2013-01-17",
		"license": "OFL",
		"ttf": "Junicode/Junicode.ttf",
		"eot": "Junicode/Junicode.eot",
		"woff": "Junicode/Junicode.woff",
		"variants": {
			"bold": "Junicode Bold",
			"bolditalic": "Junicode Bold Italic",
			"italic": "Junicode Italic"
		}
	},
	"Junicode Bold": {
		"version": "2013-01-17",
		"license": "OFL",
		"fontweight": "bold",
		"ttf": "Junicode/Junicode-Bold.ttf",
		"eot": "Junicode/Junicode-Bold.eot",
		"woff": "Junicode/Junicode-Bold.woff"
	},
	"Junicode Bold Italic": {
		"version": "2013-01-17",
		"license": "OFL",
		"fontweight": "bold",
		"fontstyle": "italic",
		"ttf": "Junicode/Junicode-BoldItalic.ttf",
		"eot": "Junicode/Junicode-BoldItalic.eot",
		"woff": "Junicode/Junicode-BoldItalic.woff"
	},
	"Junicode Italic": {
		"version": "2013-01-17",
		"license": "OFL",
		"fontstyle": "italic",
		"ttf": "Junicode/Junicode-Italic.ttf",
		"eot": "Junicode/Junicode-Italic.eot",
		"woff": "Junicode/Junicode-Italic.woff"
	},
	"KhmerOS": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOS/KhmerOS.eot",
		"ttf": "KhmerOS/KhmerOS.ttf",
		"woff": "KhmerOS/KhmerOS.woff"
	},
	"KhmerOSbattambang": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSbattambang/KhmerOSbattambang.eot",
		"ttf": "KhmerOSbattambang/KhmerOSbattambang.ttf",
		"woff": "KhmerOSbattambang/KhmerOSbattambang.woff"
	},
	"KhmerOSbokor": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSbokor/KhmerOSbokor.eot",
		"ttf": "KhmerOSbokor/KhmerOSbokor.ttf",
		"woff": "KhmerOSbokor/KhmerOSbokor.woff"
	},
	"KhmerOSfasthand": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSfasthand/KhmerOSfasthand.eot",
		"ttf": "KhmerOSfasthand/KhmerOSfasthand.ttf",
		"woff": "KhmerOSfasthand/KhmerOSfasthand.woff"
	},
	"KhmerOSfreehand": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSfreehand/KhmerOSfreehand.eot",
		"ttf": "KhmerOSfreehand/KhmerOSfreehand.ttf",
		"woff": "KhmerOSfreehand/KhmerOSfreehand.woff"
	},
	"KhmerOSmuol": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSmuol/KhmerOSmuol.eot",
		"ttf": "KhmerOSmuol/KhmerOSmuol.ttf",
		"woff": "KhmerOSmuol/KhmerOSmuol.woff"
	},
	"KhmerOSmuollight": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSmuollight/KhmerOSmuollight.eot",
		"ttf": "KhmerOSmuollight/KhmerOSmuollight.ttf",
		"woff": "KhmerOSmuollight/KhmerOSmuollight.woff"
	},
	"KhmerOSmuolpali": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSmuolpali/KhmerOSmuolpali.eot",
		"ttf": "KhmerOSmuolpali/KhmerOSmuolpali.ttf",
		"woff": "KhmerOSmuolpali/KhmerOSmuolpali.woff"
	},
	"KhmerOSsiemreap": {
		"version": "1.10",
		"license": "LGPL 2.1+",
		"eot": "KhmerOSsiemreap/KhmerOSsiemreap.eot",
		"ttf": "KhmerOSsiemreap/KhmerOSsiemreap.ttf",
		"woff": "KhmerOSsiemreap/KhmerOSsiemreap.woff"
	},
	"Linux Libertine": {
		"version": "5.3.0",
		"license": "OFL 1.1",
		"ttf": "LinuxLibertine/LinLibertine_Rah.ttf",
		"eot": "LinuxLibertine/LinLibertine_Rah.eot",
		"woff": "LinuxLibertine/LinLibertine_Rah.woff",
		"variants": {
			"bold": "Linux Libertine Bold",
			"bolditalic": "Linux Libertine Bold Italic",
			"italic": "Linux Libertine Italic"
		}
	},
	"Linux Libertine Bold": {
		"version": "5.3.0",
		"license": "OFL 1.1",
		"fontweight": "bold",
		"ttf": "LinuxLibertine/LinLibertine_RBah.ttf",
		"eot": "LinuxLibertine/LinLibertine_RBah.eot",
		"woff": "LinuxLibertine/LinLibertine_RBah.woff"
	},
	"Linux Libertine Bold Italic": {
		"version": "5.3.0",
		"license": "OFL 1.1",
		"fontweight": "bold",
		"fontstyle": "italic",
		"ttf": "LinuxLibertine/LinLibertine_RBIah.ttf",
		"eot": "LinuxLibertine/LinLibertine_RBIah.eot",
		"woff": "LinuxLibertine/LinLibertine_RBIah.woff"
	},
	"Linux Libertine Italic": {
		"version": "5.3.0",
		"license": "OFL 1.1",
		"fontstyle": "italic",
		"ttf": "LinuxLibertine/LinLibertine_RIah.ttf",
		"eot": "LinuxLibertine/LinLibertine_RIah.eot",
		"woff": "LinuxLibertine/LinLibertine_RIah.woff"
	},
	"Lohit Assamese": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitAssamese/Lohit-Assamese.eot",
		"ttf": "LohitAssamese/Lohit-Assamese.ttf",
		"woff": "LohitAssamese/Lohit-Assamese.woff"
	},
	"Lohit Bengali": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitBengali/Lohit-Bengali.eot",
		"ttf": "LohitBengali/Lohit-Bengali.ttf",
		"woff": "LohitBengali/Lohit-Bengali.woff"
	},
	"Lohit Devanagari": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitDevanagari/Lohit-Devanagari.eot",
		"ttf": "LohitDevanagari/Lohit-Devanagari.ttf",
		"woff": "LohitDevanagari/Lohit-Devanagari.woff"
	},
	"Lohit Gujarati": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitGujarati/Lohit-Gujarati.eot",
		"ttf": "LohitGujarati/Lohit-Gujarati.ttf",
		"woff": "LohitGujarati/Lohit-Gujarati.woff"
	},
	"Lohit Kannada": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitKannada/Lohit-Kannada.eot",
		"ttf": "LohitKannada/Lohit-Kannada.ttf",
		"woff": "LohitKannada/Lohit-Kannada.woff"
	},
	"Lohit Marathi": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitMarathi/Lohit-Marathi.eot",
		"ttf": "LohitMarathi/Lohit-Marathi.ttf",
		"woff": "LohitMarathi/Lohit-Marathi.woff"
	},
	"Lohit Nepali": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitNepali/Lohit-Nepali.eot",
		"ttf": "LohitNepali/Lohit-Nepali.ttf",
		"woff": "LohitNepali/Lohit-Nepali.woff"
	},
	"Lohit Oriya": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitOriya/Lohit-Oriya.eot",
		"ttf": "LohitOriya/Lohit-Oriya.ttf",
		"woff": "LohitOriya/Lohit-Oriya.woff"
	},
	"Lohit Punjabi": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitPunjabi/Lohit-Punjabi.eot",
		"ttf": "LohitPunjabi/Lohit-Punjabi.ttf",
		"woff": "LohitPunjabi/Lohit-Punjabi.woff"
	},
	"Lohit Tamil": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitTamil/Lohit-Tamil.eot",
		"ttf": "LohitTamil/Lohit-Tamil.ttf",
		"woff": "LohitTamil/Lohit-Tamil.woff"
	},
	"Lohit Tamil Classical": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitTamilClassical/Lohit-Tamil-Classical.eot",
		"ttf": "LohitTamilClassical/Lohit-Tamil-Classical.ttf",
		"woff": "LohitTamilClassical/Lohit-Tamil-Classical.woff"
	},
	"Lohit Telugu": {
		"version": "2.5.3",
		"license": "OFL 1.1",
		"eot": "LohitTelugu/Lohit-Telugu.eot",
		"ttf": "LohitTelugu/Lohit-Telugu.ttf",
		"woff": "LohitTelugu/Lohit-Telugu.woff"
	},
	"Madan": {
		"version": "2",
		"license": "GPL",
		"eot": "madan/madan.eot",
		"ttf": "madan/madan.ttf",
		"woff": "madan/madan.woff"
	},
	"Meera": {
		"version": "5.0.1",
		"license": "GPL 3+ with exceptions",
		"eot": "Meera/Meera.eot",
		"ttf": "Meera/Meera.ttf",
		"woff": "Meera/Meera.woff"
	},
	"Miriam CLM": {
		"version": "0.105",
		"license": "GPL2+",
		"eot": "MiriamCLM/MiriamCLM-Book.eot",
		"ttf": "MiriamCLM/MiriamCLM-Book.ttf",
		"woff": "MiriamCLM/MiriamCLM-Book.woff"
	},
	"Myanmar3": {
		"version": "3.0",
		"license": "LGPL 2.1+",
		"eot": "Myanmar3/Myanmar3.eot",
		"ttf": "Myanmar3/Myanmar3.ttf",
		"woff": "Myanmar3/Myanmar3.woff"
	},
	"NafeesWeb": {
		"version": "1.2",
		"license": "GPL-2",
		"eot": "NafeesWeb/NafeesWeb.eot",
		"ttf": "NafeesWeb/NafeesWeb.ttf",
		"woff": "NafeesWeb/NafeesWeb.woff"
	},
	"Nazli": {
		"version": "0.4",
		"license": "GPL-2",
		"eot": "Nazli/Nazli.eot",
		"ttf": "Nazli/Nazli.ttf",
		"woff": "Nazli/Nazli.woff"
	},
	"Nuosu SIL": {
		"version": "2.1.1",
		"license": "OFL",
		"ttf": "NuosuSIL/NuosuSIL.ttf",
		"eot": "NuosuSIL/NuosuSIL.eot",
		"woff": "NuosuSIL/NuosuSIL.woff"
	},
	"OpenDyslexic": {
		"version": "0.6",
		"license": "Creative Commons Attribution 3.0 Unported License",
		"ttf": "OpenDyslexic/opendyslexic.ttf",
		"eot": "OpenDyslexic/opendyslexic.eot",
		"woff": "OpenDyslexic/opendyslexic.woff",
		"variants": {
			"bold": "OpenDyslexic Bold",
			"italic": "OpenDyslexic Italic"
		}
	},
	"OpenDyslexic Bold": {
		"version": "0.6",
		"license": "Creative Commons Attribution 3.0 Unported License",
		"fontweight": "bold",
		"ttf": "OpenDyslexic/opendyslexic-bold.ttf",
		"eot": "OpenDyslexic/opendyslexic-bold.eot",
		"woff": "OpenDyslexic/opendyslexic-bold.woff"
	},
	"OpenDyslexic Italic": {
		"version": "0.6",
		"license": "Creative Commons Attribution 3.0 Unported License",
		"fontstyle": "italic",
		"ttf": "OpenDyslexic/opendyslexic-italic.ttf",
		"eot": "OpenDyslexic/opendyslexic-italic.eot",
		"woff": "OpenDyslexic/opendyslexic-italic.woff"
	},
	"OskiEast": {
		"version": "2.200",
		"license": "GPL-3",
		"ttf": "OskiEast/oskie.ttf",
		"eot": "OskiEast/oskie.eot",
		"woff": "OskiEast/oskie.woff",
		"variants": {
			"bold": "OskiEast Bold",
			"bolditalic": "OskiEast Bold Italic",
			"italic": "OskiEast Italic"
		}
	},
	"OskiEast Bold": {
		"version": "2.200",
		"license": "GPL-3",
		"fontweight": "bold",
		"ttf": "OskiEast/oskiebold.ttf",
		"eot": "OskiEast/oskiebold.eot",
		"woff": "OskiEast/oskiebold.woff"
	},
	"OskiEast Bold Italic": {
		"version": "2.200",
		"license": "GPL-3",
		"fontweight": "bold",
		"fontstyle": "italic",
		"ttf": "OskiEast/oskiebolditalic.ttf",
		"eot": "OskiEast/oskiebolditalic.eot",
		"woff": "OskiEast/oskiebolditalic.woff"
	},
	"OskiEast Italic": {
		"version": "2.200",
		"license": "GPL-3",
		"fontstyle": "italic",
		"ttf": "OskiEast/oskieitalic.ttf",
		"eot": "OskiEast/oskieitalic.eot",
		"woff": "OskiEast/oskieitalic.woff"
	},
	"Padauk": {
		"version": "2.8",
		"license": "OFL 1.1",
		"eot": "Padauk/Padauk-Regular.eot",
		"ttf": "Padauk/Padauk-Regular.ttf",
		"woff": "Padauk/Padauk-Regular.woff"
	},
	"Pagul": {
		"version": "1.0",
		"license": "GPL 3 with exceptions",
		"eot": "Pagul/Pagul.eot",
		"ttf": "Pagul/Pagul.ttf",
		"woff": "Pagul/Pagul.woff"
	},
	"Phetsarath": {
		"version": "1.01",
		"license": "OFL",
		"ttf": "Phetsarath/Phetsarath-Regular.ttf",
		"eot": "Phetsarath/Phetsarath-Regular.eot",
		"woff": "Phetsarath/Phetsarath-Regular.woff",
		"variants": {
			"bold": "Phetsarath-Bold"
		}
	},
	"Phetsarath-Bold": {
		"version": "1.01",
		"license": "OFL",
		"fontweight": "bold",
		"ttf": "Phetsarath/Phetsarath-Bold.ttf",
		"eot": "Phetsarath/Phetsarath-Bold.eot",
		"woff": "Phetsarath/Phetsarath-Bold.woff"
	},
	"Saab": {
		"version": "0.91",
		"license": "GPLv2+ with exceptions",
		"eot": "Saab/Saab.eot",
		"ttf": "Saab/Saab.ttf",
		"woff": "Saab/Saab.woff"
	},
	"Saweri": {
		"version": "2",
		"license": "GPL3",
		"eot": "saweri/saweri.eot",
		"ttf": "saweri/saweri.ttf",
		"woff": "saweri/saweri.woff"
	},
	"SertoUrhoy": {
		"version": "1.20",
		"license": "SertoUrhoy License",
		"eot": "SertoUrhoy/SyrCOMUrhoy.eot",
		"ttf": "SertoUrhoy/SyrCOMUrhoy.ttf",
		"woff": "SertoUrhoy/SyrCOMUrhoy.woff"
	},
	"Shapour": {
		"version": "001.000",
		"license": "GNU GPL",
		"eot": "Shapour/Shapour.eot",
		"ttf": "Shapour/Shapour.ttf",
		"woff": "Shapour/Shapour.woff"
	},
	"Siyam Rupali": {
		"version": "1.070",
		"license": "GPL3",
		"eot": "SiyamRupali/SiyamRupali.eot",
		"ttf": "SiyamRupali/SiyamRupali.ttf",
		"woff": "SiyamRupali/SiyamRupali.woff"
	},
	"Taamey Frank CLM": {
		"version": "0.110",
		"license": "GPL2+",
		"eot": "TaameyFrankCLM/TaameyFrankCLM.eot",
		"ttf": "TaameyFrankCLM/TaameyFrankCLM.ttf",
		"woff": "TaameyFrankCLM/TaameyFrankCLM.woff"
	},
	"TharLon": {
		"version": "1.0",
		"license": "OFL 1.1",
		"eot": "TharLon/TharLon.eot",
		"ttf": "TharLon/TharLon.ttf",
		"woff": "TharLon/TharLon.woff"
	},
	"Thendral": {
		"version": "1.0",
		"license": "GPL 2",
		"eot": "Thendral/ThendralUni.eot",
		"ttf": "Thendral/ThendralUni.ttf",
		"woff": "Thendral/ThendralUni.woff"
	},
	"Thenee": {
		"version": "1.0",
		"license": "GPL 2",
		"eot": "Thenee/TheneeUni.eot",
		"ttf": "Thenee/TheneeUni.ttf",
		"woff": "Thenee/TheneeUni.woff"
	},
	"Tuladha Jejeg": {
		"version": "2.0.1",
		"license": "OFL 1.1",
		"eot": "TuladhaJejeg/TuladhaJejeg_gr.eot",
		"ttf": "TuladhaJejeg/TuladhaJejeg_gr.ttf",
		"woff": "TuladhaJejeg/TuladhaJejeg_gr.woff"
	},
	"UnifrakturMaguntia": {
		"version": "2012-10-19",
		"license": "OFL 1.1",
		"ttf": "UnifrakturMaguntia/UnifrakturMaguntia.ttf",
		"eot": "UnifrakturMaguntia/UnifrakturMaguntia.eot",
		"woff": "UnifrakturMaguntia/UnifrakturMaguntia.woff"
	},
	"Utkal": {
		"version": "0.13",
		"license": "GPL",
		"eot": "utkal/utkal.eot",
		"ttf": "utkal/utkal.ttf",
		"woff": "utkal/utkal.woff"
	},
	"Xerxes": {
		"version": "1.301",
		"license": "Xerxes",
		"eot": "Xerxes/Xerxes.eot",
		"ttf": "Xerxes/Xerxes.ttf",
		"woff": "Xerxes/Xerxes.woff"
	},
	"lklug": {
		"version": "0.6",
		"license": "GPL-2",
		"ttf": "lklug/lklug.ttf",
		"eot": "lklug/lklug.eot",
		"woff": "lklug/lklug.woff"
	}
}

The official list of fonts in the ULS. —Michael Z. 2013-09-24 14:03 z

Notably, the font.ini file in each font’s directory determines how the ULS applies it to text. For example, the font.ini file for CharisSIL font includes the line languages=cdo*,nan which means that this font is usable with Category:Min Dong language (cdo) and Min Nan (nan) languages, and is the default display font for Min Dong (indicated by the asterisk).

This is one place we can request changes to the ULS, to improve the way it works. —Michael Z. 2013-09-25 15:28 z

Yeah, ULS is a train wreck at the moment, but web fonts represent the only sane future. With about 100 font stacks in Common.css, dozens of browsers and versions, each with infinite possible sets of installed fonts, and millions of mobile users who can’t even install a font, there is no other way to make this dictionary look right.

So in the interest of making this work, please vote for Bug 54453 - Don’t override site authors’ styles by using inline style. —Michael Z. 2013-09-22 19:29 z

General comment (I wonder if this should be moved to its own section): the devs turned ULS on by default here, and won't turn it off or make it opt-in even though we dislike it so much that we modify en.Wikt's common.js to kill it. The devs turned VE (VisualEditor) on by default on Wikipedia, and won't make it opt-in even though the Wikipedia community held an RFC in which ~600 people expressed an almost 5-to-1 preference for making it opt-in, leading administrators there to modify en.WP's common.js to disable it. Why is there this disconnect between the devs/tech people and the wiki communities? Many of us here on en.Wikt don't have bugzilla accounts, but enough of us do have bugzilla accounts (and enough others on other wikis have the same concerns as us) that our concerns do seem to make it to bugzilla. And WMF tech people comment on these discussions periodically, implying that they monitor this page or are alerted to developments on it.

Michael does make a good point above, that if we could control which fonts ULS set, it would seem better than our current common.css system. And on en.WP, the Foundation made the argument that by having VE turned on by default, and by (as opponents put it) seeing how many new kinds of pages it broke each day, the devs could improve it more quickly than they could improve something only experienced users were testing. Is this just a case of the devs thinking we'll figure out sooner or late that they were right all along? - -sche (discuss) 21:15, 22 September 2013 (UTC)

It reminds me of the famous w:Yes, Minister scene where the bureaucrats have moved the patients out of a hospital so they can process paperwork more efficiently. The central idea of that series reminds me of the current situation: that the Civil Service is always trying to minimize interference from the politicians who are nominally in charge so they can continue to run everything as they always have.

In our case, instead of Civil Service we have the developers, who see nothing wrong with using contributors as involuntary beta testers/cannon fodder in order to save time in rolling out new systems and features. Yes, having things hurtle to the ground in flames with people on board does make it easier to see where the flaws in the system are, but it also critically endangers the raison d'être of wikis, which is getting volunteers to donate their time and effort to produce content. They're forgetting that nothing is forcing contributors to contribute- if conditions get too bad, they'll just find something else to do with their time.

We can't do what we do without the infrastructure the WMF and the developers provide, but that infrastructure is worthless without a community of contributors to give it life: a community that's a living, breathing organism, unable to survive without the right conditions. Let's hope they wake up to what they're doing before the damage is irreversible. Chuck Entz (talk) 22:22, 22 September 2013 (UTC)

Bug 54453 has been confirmed by a developer, who has started working on fixing it. Please report other bugs and feature requests on bugzilla so we can help get this thing working for Wiktionary. —Michael Z. 2013-09-24 14:03 z

Thanks. I have added myself to the test list, instead of having the code bit in my common.js, where it didn't seem to be fully effective anyway.

I had and am still having some characters appear incomplete in my screen (eg, missing a vertical or having a half-width vertical part). Highlighting the area of incomplete characters "solves" the problem. What could be causing this?

To better understand my situation and its possible remedies and aid others in interpreting my complaints, is there a possibility that I need to consider trying to improve my hardware or my IP speed? DCDuring TALK 16:56, 25 September 2013 (UTC)

Care to provide a screenshot? Right now it sounds like font renderer acting up. (Just to note, my quite recent version of Chromium likes to randomly render text in the wrong font; clicking on the affected element seems to correct the problem. Not sure what is happening.) Keφr 17:56, 25 September 2013 (UTC)

Funnily enough, hitting my windows "Start" button to get the snip tool "solves" the problem instantly. I'll see if I can find a way to get snapshot. I use FF. This has been a problem off and on for a while, now that I think of it, so it probably has nothing to do with this thread, except that those of my other difficulties not shared with others may have cause connected with this. This laptop does not have good graphics. What does the font rendering? hardware? windows? FF? MW software? DCDuring TALK 18:45, 25 September 2013 (UTC)

Font rendering is usually done in software these days (client side, just to be 100% clear — most of the time), and yes, Windows provides facilities for it. Though I vaguely remember reading somewhere that Firefox uses its own text rendering engine. "IP speed" has nothing to do with it. Keφr 18:52, 25 September 2013 (UTC)

This link has a photo (!!!) of my screen as activating a snip tool also seemed to refresh the screen. The top third or so has the problem, not the whole screen. Any advice on where I should whine would be appreciated. DCDuring TALK 19:14, 25 September 2013 (UTC)

Strange. Looks like a hinting or antialiasing bug. Maybe misconfigured ClearType? (Or since you having bad graphics, maybe font rendering actually is accelerated by your crappy GPU driver? GPU-accelerated scrolling?) I would toggle every option in every preferences window I could find. Anyway, this is not us. Keφr 19:36, 25 September 2013 (UTC)

Thanks, I think it was FF. I have now "let pages select their own fonts". (Why did I have the other options selected? I don't know. Maybe I just wanted to control something.) DCDuring TALK 20:00, 25 September 2013 (UTC)

. I added 1= and that made it work, but I can't see which character's causing the problem; I can't see an equals sign or a vertical line that would cause such a problem. Really a point of interest rather than something that needs worrying about. Mglovesfun (talk) 13:49, 20 September 2013 (UTC)

<font style=, I think. Keφr 13:55, 20 September 2013 (UTC)

Really? Should happen more often then in that case. Mglovesfun (talk) 16:47, 20 September 2013 (UTC)

No, our signatures are way less fancy than Wikipedians'. We rarely use anything more than a superscript. (And I love it.) Keφr 17:08, 20 September 2013 (UTC)

Speak for yourself! ;-) bd2412 T 18:34, 20 September 2013 (UTC)

The reason: if you look at the template documentation, it requires a named parameter, "text=". Chuck Entz (talk) 17:26, 20 September 2013 (UTC)

I seem to think I wrote that; doesn't accept either text or 1? Otherwise my edit wouldn't've worked, and it did. Mglovesfun (talk) 21:21, 21 September 2013 (UTC)

After progressively deleting characters and previewing, it would seem that class="Unicode" inside of a span tag is the culprit. It's not any embedded special characters, because I deleted that part, causing it to show everything on preview, then typed it in by hand, causing it to not show anything on preview. Methinks something's wrong with the css with regard to that class. Chuck Entz (talk) 22:19, 21 September 2013 (UTC)

I tried substituting other classes such as LATN, and it does the same thing. Chuck Entz (talk) 23:42, 21 September 2013 (UTC)

No, you're not understanding. The problem is that when you write {{foo|bar=baz}}, the software thinks you're passing a parameter named bar with the value baz, even if you meant to pass in a parameter named 1 with the value bar=baz. This is so even if the = is inside HTML-style wikitext; for example, {{foo|<span class="…">…</span>}} passes a parameter named <span class. Mglovesfun fixed it by adding an explicit 1= (which we usually leave implicit, e.g. by writing {{l|en|foo}} as shorthand for {{l|1=en|2=foo}}); your fix, using text= instead of 1=, is equivalent, since the template treats parameters 1 and text as equivalent alternatives. Another fix would be to replace the = with &#x3D; or {{=}}. (Personally, I think your fix is actually the best — we should just always use text= with this template, rather than worrying about whether there's an equals sign somewhere — but from a technical standpoint there's no difference. And of course even with text= we have to hunt down pipes, to change them to {{!}}.) —Ruakh_TALK 06:49, 22 September 2013 (UTC)

How about having two templates, one for putting above, and another for below? Keφr 06:57, 22 September 2013 (UTC)

A few years ago I split {{archive box}} into {{archive box top}} and {{archive box bottom}}, for exactly that reason, but then it doesn't look like I modified any of the templates that use it. I don't remember why not. —Ruakh_TALK 09:20, 22 September 2013 (UTC)

(Edit conflict) Ah, I get it! So, everything before the ="Unicode" is parsed as the parameter name, and everything after class= is parsed as the parameter. That parameter is neither a named parameter referenced in the template nor a positional parameter, so it's ignored, leaving nothing to be displayed. If there were no "="s in the text, it would be parsed as a positional parameter, and it would work. That makes sense. Chuck Entz (talk) 07:13, 22 September 2013 (UTC)

Why is it that after adding a Lithuanian cognate with an alternative spelling (in which I add intonation/stress marks) to the etymology section of a Latvian word, the page gets added to that (non-existing) category? Is anyone using it for something? Is it some automatic feature of {{term}}? --Pereru (talk) 16:48, 20 September 2013 (UTC)

It's because Module:links allows links template to understand that Latin agō refers to ago#Latin and not agō#Latin. So {{term|ago|agō|lang=la}} is now redundant to {{term|agō|lang=la}}. Mglovesfun (talk) 16:51, 20 September 2013 (UTC)

As a specific example of the Latin term ago. Mglovesfun (talk) 16:52, 20 September 2013 (UTC)

I could remove the language and leave only Category:Link alt form tracking/redundant, which is a hidden category so it wouldn't show up in the entries. But I've found that having the language category visible on the page (I have my preferences set to display hidden categories) helps in finding the link on large pages with many links on them. —CodeCat 17:04, 20 September 2013 (UTC)

Ah, I see. But is this feature also available for Lithuanian? In other words, will, say, vãsara link automatically to vasara? --Pereru (talk) 18:47, 20 September 2013 (UTC) Oh, I see that it does! I wasn't aware of that. I see I don't need alternative forms for Lithuanian words anymore. Great! --Pereru (talk) 18:48, 20 September 2013 (UTC)

Hm, I've noticed that the correct spelling is not always linked to -- so krū́mas should link to krūmas, but these link to different pages still... Why is that? --Pereru (talk) 18:51, 20 September 2013 (UTC)

Maybe the rules for generating the page name aren't complete or correct. Could you check those for Lithuanian in Module:languages? —CodeCat 19:09, 20 September 2013 (UTC)

Indeed they are incomplete -- there are several tone-bearing letters that are not mentioned there. I tried to add ū́ (-> ū) to the list, but I must have done something wrong, since now krū́mas tries to link to krūūmas... I don't know anything about modules or their format; perhaps someone else could do that? (Here's a list of possible Lithuanian tone marks combinations: either an acute accent, a grave accent, or a circumflex (~) on top of any simple vowel, and also on top of ą, ę, ė, į, ų ū, m, n, l or r. The orthographic norm would those same letters, without the accents. --Pereru (talk) 19:57, 20 September 2013 (UTC)

The problem is that <ū́> is represented in Unicode as two characters: one for <ū>, one for <´>. So the character class means "either ū or ´"; so when you replace that character class with <ū>, you're replacing <ū> with <ū> and <´> with <ū> — and, as a result, you're replacing <ū́> with <ūū>. The solution, in this case, is not to use a character class: instead of , just write ū́. (CodeCat has now fixed it for you.) Also, in future, I'd appreciate if you avoided making experimental edits to that module, since it's used on millions of pages. —Ruakh_TALK 20:23, 20 September 2013 (UTC)

I think it's fairly harmless to experiment with it. The module only contains data, so there is little danger of triggering a script error. I suppose the only chance would be if you were missing a closing ] in a character class somewhere. —CodeCat 20:27, 20 September 2013 (UTC)

But there is a potential to generate subtle and undetected errors that would mislead an unsuspecting reader. I would argue that this is actually more dangerous than a script error, which at least is obviously an error. (Conclusion: We need more unit tests.) Keφr 20:53, 20 September 2013 (UTC)

Unit tests wouldn't help at all in this case. What we really need is people who put it on their watch list and check every change that's made. That's how I spotted Pereru's too. —CodeCat 21:01, 20 September 2013 (UTC)

Maybe they would, if we had a handful of unit tests of the diacritic-stripping function per language (for which we strip). I think an error like that would quickly show up as a failing testcase. Keφr 21:19, 20 September 2013 (UTC)

How do you imagine that would be done? —CodeCat 21:39, 20 September 2013 (UTC)

...edit the data module, go to testcases page (where some sample words would be checked against their diacritic-stripped versions) to check if any testcase started failing and revert the change if so? Keφr 21:46, 20 September 2013 (UTC)

Please don't delete these categories as soon as they are empty as they are likely to be filled quite often. I restored Category:Link alt form tracking/redundant/sh with 125 entries in it after just 4 days of being deleted. Mglovesfun (talk) 10:56, 21 September 2013 (UTC)

Sorry if I did something wrong, and, believe me, I won't touch that page again. I have a lot to learn in this coding business... not the usual stuff historical linguists live on, but certainly very useful.--Pereru (talk) 11:45, 21 September 2013 (UTC)

Hmmm... showing that I'm human, I have, despite the above promise, just added "í" (> "i") to the Lithuanian part of that page. Since it is a fairly obvious change and it indeed has worked, I thought it would be OK if I did it... --Pereru (talk) 13:46, 21 September 2013 (UTC)

Please add a few Lithuanian examples to Module:links/testcases. In the very last function defined on that page. (Perhaps it could be split into its own page.) It may be much helpful in finding errors later. Keφr 14:08, 21 September 2013 (UTC)

I don't think I know how to do that -- I only see code, and a table with identical forms... and the format and intention of the forms is not clear to me. --Pereru (talk) 02:11, 22 September 2013 (UTC)

WT:ACCEL currently doesn't take display forms into account. That means that if an accelerated link links to one entry but displays another, the latter form is completely ignored. It would be much better if, in this case, a head= parameter (or the equivalent for the particular template) would be added in this case so that the display form is carried over to the new entry. To avoid breaking things I will not add this to existing acceleration rules (which are rather messy anyway) but I would like this to be an option at least to add to new rules. I currently need it to work for Slovene, which has alt forms on pretty much every single word, like Serbo-Croatian does.

So how do I retrieve the link text and the link target separately in JavaScript? I found the following in the existing script:

var pagename = (link.innerText || link.textContent);

But I don't know what this does. Does this give the linked page name or the displayed text? —CodeCat 15:41, 21 September 2013 (UTC)

The displayed text, of course. link is an A element node. link.href gives the URL, from which you can extract the page name. Keφr 15:46, 21 September 2013 (UTC)

How would I extract the page name from a redlink "create new entry" URL? Would I have to do all kinds of complicated text matching? Or is there an easier way? —CodeCat 16:17, 21 September 2013 (UTC)

I just discovered a mw.Uri object which may be helpful here. The dependency you (may) need to declare is probably "mediawiki.Uri". Keφr 16:41, 21 September 2013 (UTC)

I noticed that links always have a title= attribute with the page name in it. Could I use that? —CodeCat 16:54, 21 September 2013 (UTC)

I would not count on it. The title attribute is for humans. The contents of it are not guaranteed to be in any machine-readable form. What if another script modified it? What if a MediaWiki update changed it? (And I think it already appends a locale-specific string to it if the link is a redlink…) Keφr 17:01, 21 September 2013 (UTC)

I agree. Indeed, a while back The Powers That Be turned off the title-attribute in certain circumstances when it was identical to the display-text. (I remember because it broke the 'did-you-mean' JS-redirect stuff.) That seems to have been reverted, but I didn't see a rainbow afterward to promise it would never happen again . . . —Ruakh_TALK 18:35, 21 September 2013 (UTC)

The browser-specific preferences include "Show a special character input (like the one beneath the edit field) for the search field. "

This has not been available for some time and seems unrelated to other problems I've been having, including other problems with browser-specific preferences. (Resolved now. Thanks for asking.) Does anyone else have the problem. Can it be fixed in general? Is there a custom-fix? I use Monobook and a recent FF which apparently prevents some JS from working for security reasons. DCDuring TALK 16:57, 21 September 2013 (UTC)

Problem solved. Thanks, Yair. DCDuring TALK 14:54, 9 October 2013 (UTC)

These two modules are currently not used anywhere. Their functionality can be probably folded into Module:languages, and the modules themselves deleted. Keφr 19:31, 21 September 2013 (UTC)

Would anybody be kind enough to knock together a couple of little headword templates, {{lb-adj}} and {{lb-verb}}? There's enough adjectives and verbs in Luxembourgish that these would be really useful, especially for those where I haven't got round to making the declension templates work yet, and for people reading on mobile devices where tables are unwieldy. For the adjective template, it would need three parameters, one each for masculine, feminine and neuter (the dictionary form of Luxembourgish adjectives is the one used predicatively) and add the word to Category:Luxembourgish adjectives. For the verb template, just the past participle and auxiliary verb (usually hunn, sometimes sinn) and adding the verb to Category:Luxembourgish verbs would suffice. I'd try it myself but I've never worked with headword templates and I've no idea what to do. Thanks, BigDom (t • c) 19:51, 21 September 2013 (UTC)

I will try to make something simple. But why would the masculine, feminine and neuter need to be displayed on the headword line? Are they not predictable from the headword, like in German? —CodeCat 19:57, 21 September 2013 (UTC)

Thanks a lot for your help. Yes it is similar to German, but I have seen a few languages where these inflections are shown in the headword line despite them being (fairly) predictable. It's also helpful to people who don't know the language well enough to be able to predict those forms. BigDom (t • c) 20:08, 21 September 2013 (UTC)

There are no official written rules for this, but the normal practice seems to be that if a word has a separate inflection table, then the headword line is used for two cases:

• "Principal parts": Forms of the word that are not predictable from the base form, but give enough information together to reconstruct most regularly-inflected words. Examples are Latin, Spanish and German verbs, Latin nouns and adjectives.
• Word forms that could be considered separate lemmas with their own inflection and part of speech, such as comparatives or adverbial forms. Examples are Dutch and German adjectives.

So it might make more sense to follow the practice of German and show the comparative and superlative forms, as these are (presumably) less predictable than the feminine and neuter forms are. These forms also inflect themselves too, so they are somewhat separate lemmas. —CodeCat 20:14, 21 September 2013 (UTC)

There's no such thing as the comparative in Luxembourgish apart from three words (gutt → besser, wéineg → manner, vill → méi) so there's not much point including that because in every other case it's just formed analytically using méi, e.g. méi aarm = poorer. Admittedly the feminine inflection is almost always the same as the dictionary form but there are some exceptions. I'll leave it to your discretion; if you don't think they need to be there just take them out. BigDom (t • c) 20:30, 21 September 2013 (UTC)

I have just completed writing a bot which will handle the simplest of the simplest cases of converting translation lists to {{t}}. I already did a sample run. To prevent it from making too many errrors, the bot has the following limitations:

• Only translations which contain a single unpiped link, and optionally a gender template, are converted.
• If a translation list item contains any unrecognised markup, the list item is not touched. {{t}} is recognised, but untouched, except when the bot detects a verb aspect template, in which case it attaches the verb aspect to {{t}}.
• Translation groups are not supported at all. (I might add support soon.)
• Lines with {{ttbc}} are not touched, as they may potentially contain faulty or difficult-to-parse markup.

There is a one-second delay implemented after saving a page and between requesting batches of page markup. The bot currently requests pages in batches of 50.

Keφr 16:12, 22 September 2013 (UTC)

I thought there was a requirement that all bots (or at least all new bots) have names ending in "bot". Or is that only at WP and not here? —Aɴɢʀ (talk) 16:38, 22 September 2013 (UTC)

As far as I remember, the requirement is to "clearly indicate" that the account is used by a bot. "Bot" in a username is, I think, only a suggestion. (Though I might need to edit the account's user page now.) This was the reason for two "opposes" in Wiktionary:Votes/bt-2009-03/User:Walled gardener for bot status, and yet the vote passed.

I am not sure of the merit of this requirement anyway. Since the edits are marked with the "bot" flag anyway, it is already possible to discern bot from non-bot edits. Keφr 16:45, 22 September 2013 (UTC)

The bot flag is indicated on some pages, such as Special:Watchlist and Special:RecentChanges, but not on others, such as action=history and Special:Contributions. Also, personally, when I see a bot flag from a non-bot, I tend to assume that it means a semi-automated task using the flood flag, rather than a true bot task running under a normal account. (But maybe that's just me.) —Ruakh_TALK 18:49, 22 September 2013 (UTC)

If it needs to be marked as a bot, you could have the account renamed to "Bottermilch" or "BOTtermilch"- corny, yes, but it would meet such a requirement. Chuck Entz (talk) 21:01, 22 September 2013 (UTC)

It looks good overall. Two comments:

• If a one-second delay means that it could potentially make dozens of edits per second minute, then that is not nearly enough delay.
• The verb-aspect-merging does not look very good. It looks like it's just adding it to the end of the template call, which is slightly wrong in and of itself, but more seriously, it makes me worry that the bot doesn't really read and understand the template call, it just assumes that a specific correct number of positional parameters has been used.

—Ruakh_TALK 18:49, 22 September 2013 (UTC)

Bots can't really do dozens of edits per second because of the round trip time involved. The best MewBot ever seems to do is one edit every one or two seconds. As for understanding templates, I highly recommend MWParserFromHell. It's very good and powerful and it's still in development so it is getting more features rather quickly. —CodeCat 18:58, 22 September 2013 (UTC)

Sorry, typo: I meant "dozens of edits per minute". And yes, you still need to fix MewBot: one edit every one or two seconds is way too many. —Ruakh_TALK 21:31, 22 September 2013 (UTC)

The pages are downloaded in batches of whatever-number-API-allows and processed serially. One at a time. One-second delay after a successful save and after processing a whole batch makes "dozens of edits per second" a physical impossibility.

Sorry, typo: I meant "dozens of edits per minute". Wiktionary and WMF policy require much more than one second between edits. (But a one-second explicit delay could be fine, if your bot is slow enough that an implicit delay makes up the difference.) —Ruakh_TALK 21:31, 22 September 2013 (UTC)

That will make it 6 second delay, giving at most 11 edits per minute. Not even a single dozen. Keφr 22:21, 22 September 2013 (UTC)

Aspect merging — I can add a check for enough positional parameters, and leave the template alone when the check fails. However, I would expect that any misuses of {{t}} (in this way, at least) have already cropped up in Category:Pages with script errors and been dealt with appropriately. MediaWiki accepts simply attaching the aspect after everything else, so I think it should not cause problems.

Our practice, with a few exceptions, is to put positional parameters before named parameters. (Not to mention numbered parameters, which are their own can of worms.) And it will cause problems if you add impf as a positional parameter when there's already a gender in place. —Ruakh_TALK 21:31, 22 September 2013 (UTC)

I do not follow. Cause what problems exactly? impf becomes just another positional parameter, it does not replace anything. If having both a gender and aspect in a translation is problematic, it would actually help detecting problems — just modify Module:translations to add the entry to a cleanup category. Although from the dump, I see just 31 cases of this, all but one involving Russian. Might as well fix them before running the bot. Keφr 22:21, 22 September 2013 (UTC)

*tests* Oops, I thought that e.g. {{t|ru|foo|m|pf}} would explode with a complaint about the mixture of gender and aspect codes, but no, it only explodes when you mix gender or aspect codes with noun-class codes. (I mean, technically that could be a problem, but I think it's unlikely that we have any instances of anything like {{t|ru|foo|c1}} {{pf}}: it's probably not worth worrying about.) Incidentally, I disagree with your view that it's good for bots to break things in the hopes that they'll be fixed. —Ruakh_TALK 23:12, 22 September 2013 (UTC)

Even {{t|ru|foo|m|pf}} would be rare. Which languages have verbs with both aspects and genders? Also, the "exploding" behaviour when you mix genders and noun classes is because they are formatted differently. If you mix them up, then it would no longer be straightforward which of the two to choose. So rather than trying to make a (bad) guess, it just says "you can't do that, Dave". —CodeCat 23:31, 22 September 2013 (UTC)

It's rare, yes, but once Kephir thought to look for it, he found 31 instances of it. (I assume each one is a mistake, but what of it? It's not your job — or anyone else's — to seek out things that are slightly broken for the purpose of making them very broken. Not using templates, not using Lua, not using bots.) —Ruakh_TALK 03:14, 23 September 2013 (UTC)

Slavic language verbs have intrinsic aspect and inflect for gender. It is just infinitives that are genderless. I can imagine a process whereby an infinitive of a verb would fall out of use — like with powinienem m (“ought”), though I am not sure what aspect it has (probably perfective). So marking both aspect and gender is not necessarily an error, a gendered form could become the lemma. However the translations I found seem to be all infinitives.

Mixing gender and aspect does not generate errors, which I knew because I found out earlier, and you just assumed the contrary. Gluing them together into one template may actually help in detecting this unusual condition. It is not making things any more broken than they already are. At all. What are you talking about? Keφr 06:52, 23 September 2013 (UTC)

I'm replying to CodeCat, so I'm talking about what she's talking about. Rather than ask me to repeat the thread of conversation, you might simply scroll up and read it. (Re: "you just assumed the contrary": Not at all. A while back CodeCat added some explosions when you combined, for example, noun-class and aspect. I didn't remember that combining gender and aspect wasn't set to explode — yet — though now that the possibility has occurred to her . . .) —Ruakh_TALK 15:18, 23 September 2013 (UTC)

No, you replied to me that "it would cause problems". CodeCat only responded that the so-called "explosion" happens in different circumstances. The relevant settings in Module:languages have been removed anyway, and even if they were not, I infer from reading Module:gender and number that it would not explode in this case — it would have for cases like "n-pf" or "n-impf", but this bot does not combine the two into one gender specification in this way. Keφr 15:47, 23 September 2013 (UTC)

I think you must have missed part of the above conversation. You keep saying things that are mostly true, but that do not make sense as replies to the comments that they're replies to . . . —Ruakh_TALK 15:58, 23 September 2013 (UTC)

Let me summarise the above discussion:

Kephir: I made you a bot! What do you think about it? Will you let it run?

Ruakh: Maybe. But the aspect-attaching thing is smelly!

Kephir: What do you mean?

Ruakh: Aspect should be placed before named parameters! And it can cause problems.

Kephir: What problems?

Ruakh: Oops, my mistake. There are no script errors when mixing genders with aspect.

CodeCat: That is not a possibility worth considering anyhow. No language has both verb aspect and gender!

Ruakh: Of course it is worth considering! Stop breaking stuff, you bastards!

Kephir: But Slavic languages actually do have both! And mixing the two does not break anything.

Ruakh: I was talking about what CodeCat was talking about! And I was not making counterfactual assumptions!

Kephir: What the fuck?

What did I miss? Keφr 17:04, 23 September 2013 (UTC)

You missed half of CodeCat's comment, the half where she wrote (summarizedly) "Explosions are good, because when something is less-than-ideal, it's best to make it so terrible that everyone is sure to notice." (You also missed some of its context: she said "it's not a possibility worth considering anyhow" after you already pointed out that it's not a possibility, but a reality in a few dozen entries.) Re: "Ruakh: And I was not making counterfactual assumptions!": This would be better summarized as "I didn't 'just assume'; I just misremembered one of the details." (I was replying to your accusation that I had "just assumed" something.) —Ruakh_TALK 17:32, 23 September 2013 (UTC)

Well, I wonder if you will like an alternative formulation of a similar principle more. Keφr 18:03, 23 September 2013 (UTC)

I agree with that principle, and apply it in my own software (for example: my bots always make sure that the wikitext conforms to their assumptions, and if it doesn't, they write to an error-log rather than plowing ahead with bad edits). But firstly, it's a principle of API design ("programs cooperate with other programs"), not of UI design, and secondly, you can't take it too literally. For example, imagine that an HTML document has a typo: </i] instead of </i>. The absolute noisiest way to fail would be to crash the webserver (or maybe to launch a DOS attack against the other hosts on the network). The point of that principle is "don't conceal problems that will only get worse", or perhaps "simple and predictable is better than complicated and wrong". It's not "as long as my software would work in a perfect world, I don't have to worry about whether it works in the real world". —Ruakh_TALK 21:17, 23 September 2013 (UTC)

The part about crashing or DDoSing nearby servers is a strawman. And yes, this rule applies to user interfaces too, if not mostly: the point of it is "try to recover from whatever you are able to, but when errors do arise, make them obvious to spot and diagnose". Unfortunately the "Script error" message does not quite help with the latter. Perhaps we could temporarily change the message to something like "Script error: click for details". Did anyone go to bugzilla: with this? Keφr 21:41, 23 September 2013 (UTC)

The part about crashing or DOSing servers isn't a straw man; it would be a straw man if my conclusion were "so that whole rule is bollocks", but my actual conclusion was just "so you need to apply common sense." And the problem with replacing an entire translation with Script error just because of gender problems is not that it makes the error obvious, but that it's only useful to the person who'll fix it. We have useful information (the translation itself), but we choose to hide it, in an attempt to force someone to fix a problem that they may not even be able to solve. (I mean, don't get me wrong, I also think the big red Script error is overkill; but at least I'd mind it less if it were non-destructive.) And when we're talking about script errors resulting from bot actions or template changes, the notion that this helps us find problems is misguided: it results from a false dilemma, whereby our only choices were "leave be" or "break", as though Category:Pages with script errors were our only cleanup category and Script error were our only means of populating it. —Ruakh_TALK 04:13, 24 September 2013 (UTC)

Well, I can agree to that. But then, it is the presentation of the error that is problematic, not error detection itself. Which previously barely happened at all. Keφr 04:33, 24 September 2013 (UTC)

Also, |sc= is not added. Though I will note that most translations to non-Latin scripts have probably supplied transliterations, and because of that they will not be touched anyway (transliterations are simply too easy to confuse with qualifiers, or optional parts of a SOP-py translation). Should I also add that, and if so, can I blindly use the default script for a given language, or should I scan through the code points to detect the script? (I guess the latter, but...) Keφr 19:06, 22 September 2013 (UTC)

I don't think you need to add |sc= — actually I think we should change WT:EDIT to stop adding it — but you should make sure that the end-result is correct. (You don't really need to "detect" the script, per se, so much as just confirm that the script is what you expect. The details, of course, will depend on how you've coded the bot; if you've written it in a way that tries to be completely language-agnostic, then this will be more difficult.) —Ruakh_TALK 21:31, 22 September 2013 (UTC)

I will not bother then. Keφr 22:21, 22 September 2013 (UTC)

Aspect is now attached right after the last positional parameter. Also, the bot tries to unlink language name whenever it determines it is safe to do so. Is there anything else I should do? Keφr 08:51, 25 September 2013 (UTC)

Do you verify and flag language names that do not match the language code in {{t}}? DTLHS (talk) 20:16, 25 September 2013 (UTC)

Why would I? It is not relevant to the task I wrote it for. Keφr 20:54, 25 September 2013 (UTC)

...Hello? ...Anybody? Keφr 21:33, 4 October 2013 (UTC)

You need to create a vote to get a bot flag. DTLHS (talk) 21:34, 4 October 2013 (UTC)

Done. (Those instructions are surely confusing.) Keφr 06:37, 5 October 2013 (UTC)

Over the last few days more and more Polish entries have begun appearing with script errors. I'd expect that anyone who edits modules or templates should check this category regularly to see if things aren't breaking. But it seems that it may have been forgotten now so I'm bringing it to attention.

There are also some language code templates listed. I'm not sure what to do about those. —CodeCat 16:52, 25 September 2013 (UTC)

Why didn't abuse filter 24 catch this? - -sche (discuss) 04:31, 27 September 2013 (UTC)

• Because that user's totally awesome, of course. -WF
  • The degree of awesomeness of the user has nothing to do with how a bot was able to post spam on the user's page. Spam is not awesome, and spambots have to rank somewhere close to negative infinity on the awesomeness scale... Chuck Entz (talk) 23:09, 28 September 2013 (UTC)

•  Fixed. But more tweaking may be warranted; for example, the filter's description is "Users creating other users' user pages", but nothing in the filter restricts it to page-creations. —Ruakh_TALK 08:05, 29 September 2013 (UTC)

Header changed from: == I know why I came here ==

It was to wonder how pages like Category:Entries missing taxonomic name Thlaspi arvense can be useful. There's probably a bug somewhere over the rainbow that causes these categories to exist. -WF

It's not a bug, and those phantom categories are useful to those adding taxonomic name entries, though not so much to the rest of us. DCDuring (talk • contribs) has explained it recently on one of the other forums, though I don't remember offhand which one. Chuck Entz (talk) 23:15, 28 September 2013 (UTC)

When the category appears with multiple members in Special:WantedCategories it is a relatively high priority taxon to be added. Once added the red category link disappears from the entries that are members of the wanted category, though the category remains on the Special page until that page is updated. On the current list number 93 is "Entries missing taxonomic name Carduelis carduelis (8 members)". As Carduelis carduelis has been added, the category is now empty.

It is difficult to set priorities for adding taxonomic names. This is a help. If Special:WantedPages or a substitute ran regularly, then this approach would not be at all warranted. Taxa for European species tend to constitute a large share of these because so many of our contributors are European and the species tend to not respect language areas or national borders. The plan is to rotate the taxonomic level every few days so that there are not too many red links on a page at any one time and the most needed entries are added at all taxonomic levels. Unfortunately, species names, which are often missing and often appear on many pages, are the selected level now. And the updating of the special pages, usually twice weekly or so, has not taken place since September 10. (There is something on Bugzilla for this.) The redlinked categories can be very numerous on genus-level entries if we explicitly list the species. I usually do not if there are more than a dozen species. DCDuring TALK 23:30, 28 September 2013 (UTC)

Of course, I welcome any help in adding these entries. I have some stuff that I cut-and-paste for them to save typing that I'd be happy to share. DCDuring TALK 23:30, 28 September 2013 (UTC)

Yeah these are DCDuring's private categories. Mglovesfun (talk) 17:52, 1 October 2013 (UTC)

They are available for all to use. If several people, besides CodeCat and I, used wanted categories this way we might need to figure out some way to allocate or limit the use. As the categories are populated by template it is easy to clean up the page. This is a labor-intensive substitute for Special:WantedPages which hasn't been run for about four years, but is supposed to be run again periodically, in response to the request of users at several wikis including me for this one. If we had more folks capable of creating useful lists from processing the dumps, this would not be happening. DCDuring TALK 19:22, 1 October 2013 (UTC)

If you're willing to run list-generation commands, e-mail me. I'm willing to write scripts, but not to keep track of all the scripts and run them all every time. My experience to date has been that when I post a list-generation command on a TODO-list talk-page, it's effectively a note-to-self, because in general, no one but me will ever run the command again. —Ruakh_TALK 00:27, 2 October 2013 (UTC)

I suppose this is what the toolserver (or whatever replaced it) was for. I'm not sure if it would be worth my time to figure out how to use it though. DTLHS (talk) 00:35, 2 October 2013 (UTC)

Yeah, that's how I feel. It always felt like the toolserver was more trouble than it was worth. —Ruakh_TALK 05:19, 2 October 2013 (UTC)

@Ruakh: there was a while there when I reused the scripts/commands you posted. :b But after a few runs, I and others had fixed all the entries that the scripts could find. Now that you mentioned it, though, I should probably re-examine/run them to see if new entries have cropped up with the same old problems. - -sche (discuss) 06:12, 2 October 2013 (UTC)

Header was: == Greek transliteration ==

The transliteration for Greek turns οἱ into "ohi", even though it should be "hoi". What is going on? I thought the transliteration for Greek was pretty much perfect. —CodeCat 18:47, 30 September 2013 (UTC)

Module:grc-translit has various special cases for vowel combinations (and rho-plus vowel combinations) with breathing marks, but this one isn't covered. —Ruakh_TALK 00:33, 2 October 2013 (UTC)

Since this module is not completed, it would be a good idea to unprotect it. --flyax (talk) 19:48, 6 October 2013 (UTC)

It's already used on thousands of pages, so I think it's too late to consider it "not completed"; it just has some mistakes. —Ruakh_TALK 20:51, 6 October 2013 (UTC)

Not completed or not completely correct, whatever you call it, it needs to be fixed; by someone. --flyax (talk) 06:26, 7 October 2013 (UTC)

Yes, I agree. Personally, I don't know enough about Ancient Greek to feel comfortable messing with it, but if someone supplies the necessary knowledge of transliteration rules for Ancient Greek, I can supply the Lua knowledge and the actual editing. —Ruakh_TALK 06:42, 7 October 2013 (UTC)

Actually, I really just want someone to confirm the following:

• a breathing mark can only ever appear on a vowel letter or on a rho
• when it appears on a vowel letter, it should necessarily be transliterated as a word-initial <h> (even if the vowel letter itself is not word-initial)
• when it appears on a rho, it should necessarily be transliterated as an <h> after the corresponding <r>

If that's all correct, then this is straightforward to fix.
—Ruakh_TALK 06:51, 7 October 2013 (UTC)

All correct. My only hesitation is whether Οἱ should be translitetated as hoi or Hoi. If the latter then the following lines, if added after line 72, should be enough (I'm copying the syntax of module's line 71).

text = gsub(text, "α", "hau")
text = gsub(text, "ε", "heu")
text = gsub(text, "η", "hēu")
text = gsub(text, "ε", "hei")
text = gsub(text, "ο", "hoi")
text = gsub(text, "α", "hai")
text = gsub(text, "υ", "hui")
text = gsub(text, "Α", "Hau")
text = gsub(text, "Ε", "Heu")
text = gsub(text, "Η", "Hēu")
text = gsub(text, "Ε", "Hei")
text = gsub(text, "Ο", "Hoi")
text = gsub(text, "Α", "Hai")
text = gsub(text, "Υ", "Hui")

--flyax (talk) 07:08, 7 October 2013 (UTC)

 Done, thanks; and, good point about capitalization. Lua-wise, I actually took a somewhat different approach, I hope that's O.K. (See Module:grc-translit?diff=23444968.) —Ruakh_TALK 07:48, 7 October 2013 (UTC)

Yes, I think it's OK. Thank you. --flyax (talk) 12:13, 7 October 2013 (UTC)

That's about it really; an example would be {{term|decipere|dēcipĕre|lang=la}}, which contains the character ĕ. Mglovesfun (talk) 17:54, 1 October 2013 (UTC)

We could add temporary one-off logic to Module:links just for this, but I'm not really thrilled about that idea. It's conceivable that we may want to do this for other languages as well, so we should probably think of a way that makes this extendable. I propose adding a forbidden_chars value to Module:languages that works the same as the other "pattern matching" values, except that this one has no replacement and just matches. If a match is found in a link, then it would add the entry to a cleanup category. We could also add such logic to Module:headword, which could allow us to detect misspelled entry names too. —CodeCat 18:34, 1 October 2013 (UTC)

Makes sense to me. But I think we really need to create a wrapper around Module:languages for this stuff. (Actually, I think Module:languages should be a normal Scribunto module, with the raw data being in Module:languages/data or something. But either way, I think it's becoming a problem that we use Module:languages directly from so many places, given that a lot of it only makes sense in the context of logic stored elsewhere.) —Ruakh_TALK 00:30, 2 October 2013 (UTC)

What do you suggest? —CodeCat 00:46, 2 October 2013 (UTC)

Well, I'm not sure how easy it would be to migrate; but ideally, I think what we currently have at Module:languages would instead be at Module:languages/data or Module:languageData, with most or all of its implied functionality being in Module:languages. For clear-cut data-retrieval purposes, other modules might use Module:languageData directly, but things like m.language_code.entry_name.from (which is only meaningful as part of a nontrivial associated algorithm) would certainly only be used by functions in Module:languages (e.g. getEntryNameForDisplayText). (Actually, even for what might seem like clear-cut data-retrieval purposes, it might be best to use wrapper functions: calling getCanonicalName and getAllNames is more explicit than using foo.names and foo.names directly, with the canonical being implicit in the . But if you prefer foo.names, I don't feel strongly about it.) —Ruakh_TALK 05:31, 2 October 2013 (UTC)