Wiktionary:Grease pit

Wiktionary > Discussion rooms > Grease pit

Click here to start a new Grease pit discussion.

Wiktionary discussion rooms (edit) see also: requests
Information desk comment | history | archives Newcomers' questions, minor problems, specific requests for information or assistance.	Tea room comment | history | archives Questions and discussions about specific words.	Etymology scriptorium history | archives Questions and discussions about etymology- the historical development of words.	Beer parlour comment | history | archives General policy discussions and proposals, requests for permissions and major announcements.	Grease pit comment | history | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 - All discussion pages 1 2 3 4 5

A grease pit

Welcome to the Grease pit!

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

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

It is said that while the classic beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

• Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
• Other tips and tricks are at WT:TAT.
• Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.
  
  

April 2013

Module:links

Current code can do {{l}}'s job, and {{l}} will use the module instead of its current code soon. The aim of the module is generally handling wikilinks, though -- not just in {{l}}, but in {{term}}, head templates, and other similar templates that create wikilinks.

Some new features have been proposed at Template_talk:l#Lua-ising. The code for the features has been written and tested, we just need to gain official community consensus to implement it.

Any thoughts or suggestions would be welcomed. --Z 04:28, 1 April 2013 (UTC)

Have you tested it to make sure it works in all cases that {{l}} works, and that it doesn't do anything it shouldn't? Also, what is the purpose of Module:useful stuff? "detect_script" in particular doesn't seem like it does anything useful. And the list of languages that have automated transliteration should be in Module:languages. I also warned you not to start adding all kinds of extra code to this until we're sure that it works the way it should. —CodeCat 13:41, 1 April 2013 (UTC)

Assuming "detect_script" does what it seems to based on its name, that would be extremely useful. Several templates for multiscriptal languages like Tatar, Ladino, and Japanese have parameters that require the user to input what script an entry is in. If we can scrap that, that's be great. —Μετάknowledge^{discuss/deeds} 14:20, 1 April 2013 (UTC)

But what do you do when the word contains characters in multiple scripts? —CodeCat 16:40, 1 April 2013 (UTC)

That doesn't happen in Tatar or Ladino. It does happen in Japanese, and I'm not sure how it works. For example, アメリカ合衆国 is in both katakana and kanji, but is marked as katakana (in the template, that's kk). We'll have to ask a Japanese editor. —Μετάknowledge^{discuss/deeds} 00:45, 2 April 2013 (UTC)

Why use kk, the language code for Kazakh? In case it matters, the Japanese ISO script codes are:[1]

• Hira: Hiragana
• Kana: Katakana
• Hrkt: Japanese syllabaries (alias for Hiragana + Katakana)
• Jpan: Japanese (alias for Han + Hiragana + Katakana)

 —Michael Z. 2013-04-03 21:38 z

This is totally off-topic, but I guess it's a valid complaint about the template. The answer is that it's faster to type, just like pl= (code for Polish, means plural in templates) or tr= (code for Turkish, means transliteration in templates). In cases like these, editors' ease definitely outweighs using ISO script codes, because it really doesn't matter which we use. —Μετάknowledge^{discuss/deeds} 23:45, 3 April 2013 (UTC)

Where is the code for the version with the proposed features?

Automatically detecting script sounds like a very good idea, imo. --Yair rand (talk) 01:22, 4 April 2013 (UTC)

Some are removed by CodeCat and you can find them in older revisions, some were moved to this module, others are in commented part of the code, e.g. recognizing reconstructed terms from "*" and linking to appendix is in prepare_title(). --Z 01:42, 4 April 2013 (UTC)

Can somebody please help me work out how to implement script recognition in {{tt-pos}}? —Μετάknowledge^{discuss/deeds} 02:31, 4 April 2013 (UTC)

I'm not opposed to these innovations in principle, but I do think that we should first get {{l}} to work with this module first, and keep it that way for at least a week or two so that we can be sure there are no unexpected problems. —CodeCat 03:20, 4 April 2013 (UTC)

Why would we want to get {{l}} working with it first? That might could be a while... —Μετάknowledge^{discuss/deeds} 04:22, 4 April 2013 (UTC)

Currently detect_script() can't be invoked from templates, it's a better idea to rewrite that template in Lua. --Z 03:29, 4 April 2013 (UTC)

Is it? I was hoping to have a model off which I might be able to design more templates with these features. —Μετάknowledge^{discuss/deeds} 04:22, 4 April 2013 (UTC)

It would be possible after Lua-ization of {{l}} and {{head}} and adding the ability of detecting scripts to them. --Z 05:08, 4 April 2013 (UTC)

Regarding Japanese, I have no idea about how its writing system works, but it's possible to find katakana characters of a word and tag it with Kana class, and other non-katakana characters of the word (if there is any) would be kanji, I assume? If so, it's easy to fix. Does similar thing happen in any other language? --Z 03:29, 4 April 2013 (UTC)

Not that I can think of, but we should assume so just to be safe. —Μετάknowledge^{discuss/deeds} 04:22, 4 April 2013 (UTC)

The module is tested, the only problem is gender/number part -- output of Module:gender and number and those of gender/number templates are not identical. That's not much of a problem though, we can use the gender templates in the module for now. --Z 05:32, 4 April 2013 (UTC)

Just use the module. The output of the module can always be changed if necessary, that isn't a good reason not to use it. —CodeCat 22:59, 5 April 2013 (UTC)

Ok, change it then. I can't even edit the page, you locked it. The gender templates should be used until gender_and_number is fixed.

The outputs of Template:l and Module:l are identical now (don't know why the forth test fails, they're the same really). I won't have regular internet access after 14th and apparently no one else cares about working on the module, so I would be grateful if Module:l is implemented soon so that I would be able to work on the extra features in this period of time. --Z 05:14, 10 April 2013 (UTC)

Substring module

Thanks, Z! New question: do we have a basic string manipulation module, just to store stuff like taking a substring of a certain length from the end of a word, etc? If not, should I create Module:string or something? —Μετάknowledge^{discuss/deeds} 00:23, 5 April 2013 (UTC)

NP, no that's not needed, for this certain task you can simply use string.sub(). --Z 00:39, 5 April 2013 (UTC)

But I want to invoke it directly in an un-Luacized template. That's why I reckon there should be a separate module for it. —Μετάknowledge^{discuss/deeds} 22:51, 5 April 2013 (UTC)

I see a need to decompose words in any script into components, including any diacritics and ligatures. Use: say you want to check how to pronounce a word in a complex script with diacritics - Burmese, Hindi, Bengali, Thai, Arabic, Hebrew, etc. A Devanagari syllable रा (rā) can't be looked up in Wiktionary:Hindi transliteration because it's र + ा and you can't take out the diacritic ा from रा to look it up. Some word processors allow to break strings into parts. So, yes, please. Not just the substring but a break up.

Module:ko-hangul has the function syllable2Jamo, which in debug mode shows individual jamo for each hangeul (한 (han) = ㅎㅏㄴ (h a n). Need to make it break up hangeul in the run mode. Tried to do it with "syllable2JamoSep" but didn't work. --Anatoli ^{(обсудить}/^вклад) 00:41, 5 April 2013 (UTC)

If I understand you correctly, you need mw.ustring.gsub(text, "(.)", "%1 ") (try print(mw.ustring.gsub("रा", "(.)", "%1 ")) in console). --Z 00:58, 5 April 2013 (UTC)

Module:String exists on Wikipedia. Because it doesn't exist here yet, I copied the entire code and added extra bits to it when I wrote Module:bo-translit. Wyang (talk) 01:01, 5 April 2013 (UTC)

Great stuff, thank you! I also tried Thai "เค็ม" = เ ค ็ ม and Arabic "اَلْلُغَةُ ٱلْعَرَبِيَّةُ"‎ = ا َ ل ْ ل ُ غ َ ة ُ ٱ ل ْ ع َ ر َ ب ِ ي َ ّ ة ُ‎. --Anatoli ^{(обсудить}/^вклад) 01:11, 5 April 2013 (UTC)

Wyang, it seems you're able to do auto-translit for a few complicated script languages, especially those you're familiar with, you've done Burmese before in the Chinese Wiktionary, haven't you? I'm especially keen if you could do Hindi, Bengali, Thai, Lao, Burmese and Khmer in any order, possibly Sinhalese. Korean module needs to be made better as well. I'm happy to assist with testing and getting/checking for translit. rules. I'm only familiar to some degree with Korean, Hindi and Thai. Angr is our Burmese expert and Stephen G. Brown knows a bunch, including Khmer and Telugu (no tones in Khmer, so it's simpler than some others). ZxxZxxZ has done a great job with Arabic and Persian but you can only do that much with partially phonetic languages. --Anatoli ^{(обсудить}/^вклад) 01:23, 5 April 2013 (UTC)

Wyang knows a lot about Burmese himself, I doubt he'll need much if any help from me for it! —Angr 10:18, 5 April 2013 (UTC)

OK. Anyway, I hoped that function print(mw.ustring.gsub("လုံချည်", "(.)", "%1 ")) could also be used for reading out individual characters, so that one could look up each character in e.g. WT:MY TR but are we missing some characters in လ ု ံ ခ ျ ည ်? I can't find some characters, e.g. ု. --Anatoli ^{(обсудить}/^вклад) 10:59, 5 April 2013 (UTC)

ု alone is "u." in MLCTS, ု+ ံ is "um". They are both on the my-translit page. As for the transliteration modules, I'll try to get more familiar with Lua first. While certain string decomposition functions are easier to use than wiki code, some others seem less straightforward, for example the equivalent of {{#switch: (?) Wyang (talk) 11:06, 5 April 2013 (UTC)

What exactly is the purpose of all these string functions when most of them already have more complete Scribunto equivalents? Isn't this just reinventing the wheel? —CodeCat 22:57, 5 April 2013 (UTC)

No one really answered my original question. For example, we need to strip leading hyphens from suffixes for sorting purposes. Where should I put the function that does that? —Μετάknowledge^{discuss/deeds} 05:44, 17 April 2013 (UTC)

Use mw.text.trim(text, "%-"). Almost whatever string-related function you think of is already defined in Lua and Scribunto. --Z 06:42, 17 April 2013 (UTC)

You don't get it. I know that, I just want to know where to put it. We need to be organized before we put stuff in templates. —Μετάknowledge^{discuss/deeds} 13:53, 17 April 2013 (UTC)

I understood that was just an example, but as I said, basic string-related functions are already defined and I can't think of anything that isn't defined. Maybe I'm misunderstand what you mean, so lets wait for another person to comment. --Z 14:24, 17 April 2013 (UTC)

Non-basic string functions are usually language-specific, which we have put them in Module:xx-common modules so far, where xx is the language code. Anything else (if there is any) may be put here. --Z 14:28, 17 April 2013 (UTC)

So I should put this in Module:useful stuff? And what should I name the function, suffixSort? —Μετάknowledge^{discuss/deeds} 14:33, 17 April 2013 (UTC)

Yeah, that looks fine. There was a worthless timewasting discussion about what to name that module, and after thinking a lot, I came up with that title, because I think thinking about what to name a module is ridiculous; no one cares what it is named, only that it works, so I named it after the first thing came to my mind, I suggest you do that too. --Z 15:08, 17 April 2013 (UTC)

Documentation subpage tab for templates

As an example, {{head}}, at the top the tab is still Template:head/doc but we're migrating these to /documentation (Template:head/documentation). I guess there's a MediaWiki page somewhere that needs updating. Please. Mglovesfun (talk) 12:23, 5 April 2013 (UTC)

Yes, but currently the majority still uses /doc. Would it be possible for it to support both, until all the subpages have been moved over? {{documentation}} already does this (it shows /doc if it exists, but prefers /documentation otherwise) —CodeCat 14:17, 5 April 2013 (UTC)

An idea for a new way to make form bots

This idea just kind of came to me but I think it could be very useful. The way that User:MewBot and probably all the other bots currently work is that they parse the invocation of the template, and then try to mimic the template as closely as possible. This is really a lot of work and it's not ideal, because it means all the code has to be duplicated and kept synchronised. So I thought... why not let another template or Lua generate the forms in a machine-readable format? That way, the bot only has to understand the output, but no longer has to duplicate any of the intricacies of the template/module. I have added this to Module:nl-verb and less than 5 minutes later I already have a working example. :) See User:CodeCat/bot example. To use it on any Dutch verb table, just add the parameter bot=1 to the template. It is really easy to do as long as your template or module has a strict separation between the part that generates all the forms and the part that displays the table. By writing a second output function that displays a list of forms instead of a fancy table, you can get this result. It can even be done without Lua at all, but Lua does make it a lot easier.

So what can we do with this? In its current form, a bot script could "find" the inflection template on a page like it does before, but it could then add the bot=1 parameter and expand the template (via the MediaWiki API, which is built into the Python wikibot framework). It can then parse the machine-readable output and use that to create entries for each of the forms as before, instead of having to generate all the forms itself. However, this concept could be taken further. The template or module that generates the machine-readable format could actually generate the full form-of entries itself, so that the bot doesn't even need to parse the output but could just flat out create entries straight from it. This, in turn, would open up one huge door: a single bot that can do any inflection table, in any language, without modifications, as long as the template/module generates the proper output. —CodeCat 01:31, 6 April 2013 (UTC)

I've now made these changes to User:MewBot, and it seems to work ok with the few test entries I've tried it on. —CodeCat 22:01, 6 April 2013 (UTC)

Looks good to me. —Ruakh_TALK 23:54, 6 April 2013 (UTC)

toolserver

I’ve tried to use several toolserver utilities yesterday and this morning, such as SUL accounts, and I have not been able to make a connection. Is toolserver temporarily down, or is it gone? I remember someone saying that the toolserver tools were being migrated to Wikimedia Labs. If the SUL accounts tool is now at Wikimedia Labs, is there a way to fix the links here (SUL accounts link appears at the bottom of anyone’s contributions page, such as Special:Contributions/Stephen_G._Brown)? —Stephen ^(Talk) 06:16, 6 April 2013 (UTC)

The toolserver has issues, but it is unrelated to tools migrations. Dakdada (talk) 15:40, 6 April 2013 (UTC)

Thanks. It seems to be working again, although very slow. —Stephen ^(Talk) 08:48, 7 April 2013 (UTC)

Limits on display of "orange link for missing language section"

If one checks the appropriate box in per-browser preferences, links display in orange instead of blue "if the target language is missing on an existing page" (actually if the specified section of whatever kind is missing), eg, plate#Latin. plata#Latin displays blue though there is no Latin section at [[plata]]. Does anyone know whether there some kind of limit on the number of headings that are searched in the operation of the this feature? DCDuring TALK 12:28, 6 April 2013 (UTC)

No idea, but the reverse happens too. In the etymology sections of သစ်, 薪#Mandarin, 薪#Cantonese, 新#Middle Chinese, and 新#Cantonese all appear orange even though those sections do exist. —Angr 12:36, 6 April 2013 (UTC)

Angr, that's a different problem. I'm pretty sure that's because none of the sections you linked to has a definition yet. —Μετάknowledge^{discuss/deeds} 16:45, 6 April 2013 (UTC)

Uncategorized sections come up orange, yes. Mglovesfun (talk) 18:21, 6 April 2013 (UTC)

OK, that's good to know. But what about DCDuring's issue? Why is plata#Latin blue? —Angr 18:28, 6 April 2013 (UTC)

• I had a hunch.

I searched the plata page for the word "Latin". It appeared in a context note in the second Spanish def.

After deleting that context note, so the word "Latin" doesn't appear on that page, the plata#Latin link now appears in orange.

Yair, that looks like a bug, maybe in page parsing -- would that be hard for you to fix? -- Eiríkr Útlendi │ Tala við mig 19:47, 6 April 2013 (UTC)

• No, that's the same problem. It's not that you removed Latin from the text, it's that you removed the page from Category:Latin American Spanish. The script works by examining a page's categories; if the page appears in a category that starts with a given language-name, then the script infers that the page has a section for that language. (In particular, the script does not download and parse the page. That would give more accurate results, but would be prohibitively expensive.) —Ruakh_TALK 00:09, 7 April 2013 (UTC)

  And that answers the lingering question I had about why orange appears when I try to link to a PoS or Etymology section in English. DCDuring TALK 00:40, 7 April 2013 (UTC)

  Does the script not look at hidden categories? 新 has a hidden Cantonese category (definition needed). Why not use it? DCDuring TALK 00:44, 7 April 2013 (UTC)

• Re: "Does the script not look at hidden categories?": Correct, it doesn't.   Re: "Why not […] ?": Not being the author, I can only speculate, but it sort of makes sense to me: if our only Cantonese category is Category:Cantonese definitions needed, then we arguably don't really have a Cantonese entry. I mean, sure, we've got the ==Cantonese== L2 header, but we don't even identify the POS? —Ruakh_TALK 02:20, 7 April 2013 (UTC)

I don't know if it would help or even be useful, but we could restrict the script further by requiring that a PoS category have a specific name. The script would have a list of possible PoS names which it could choose from, and it would make the link orange if it finds no match. Since "American Spanish" isn't a PoS category, it would fix the problem above. —CodeCat 02:31, 7 April 2013 (UTC)

That doesn't seem like it should impose much of a performance penalty. (Does Lua/Scribunto help?) If there is any significant performance penalty, should just learn to live with the problem.

I guess there could be other instances of a name of regional dialect or dialect grouping starting with a language name. DCDuring TALK 04:00, 7 April 2013 (UTC)

No performance penalty, no. (Also, that part of it would be handled entirely on the client-side (your browser), via JavaScript, so even if it did have a performance impact, the considerations would be a bit different than for stuff that runs on the server-side.) —Ruakh_TALK 05:26, 7 April 2013 (UTC)

have#Etymology also comes up orange (well, yellow to me) because there are no categories starting with the word Etymology. Mglovesfun (talk) 11:33, 7 April 2013 (UTC)

We could apply the same idea to that as well. If the script is able to recognise which categories are valid, maybe it could also tell a valid language from an invalid one. The problem, of course, is that there are hundreds of languages, so putting them all into the script might be overkill. I guess this is yet another example of a case where linking to non-language sections just doesn't work. And I kind of agree with that anyway, because have#Etymology would link to the first Etymology section on the page. That works out right in this case, but what about cantar#Conjugation? And never mind if we want to link to the etymology of another language, then you're out of luck... —CodeCat 13:02, 7 April 2013 (UTC)

It only matters for those who select the preferences box. It doesn't really matter for the users we should care most about: casual users. The simple and cheap part (PoS) may be worth installing in the script, not the language part.

I still have hopes that links to English L2s can be to be more narrowly directed to the appropriate L2 headers like Etymology n and the PoS headers instead of running the risk of confusing users at our longer entries. DCDuring TALK 14:07, 7 April 2013 (UTC)

I prefer the opposite, that all languages can be treated equally so that people don't get confused when something that works for English doesn't work for any other language. That doesn't mean that we wouldn't be able to link to specific sections, but we should be able to link to the specific section of any language. Currently, Mediawiki equates sections with the actual name of the header, so it assumes that every header will only ever appear once on a page. That is really a rather strange assumption. —CodeCat 14:11, 7 April 2013 (UTC)

English is the host language. It already behaves differently.

The less attractive we make this for normal users the less we will track real English. Plenty of users are confused by the existence of uppercase entries for English words that don't contain English sections, just German or Translingual. Why not finish the job by putting English in its alphabetical position in multilanguage entries and encourage non-English-language discussions for non-English entries? We already run the risk of turning this wiktionary into one that doesn't track current UK or US English, but some blend of what Webster 1913 tracked and Globish. And there will be fewer to challenge the dated, archaic, and obsolete glosses in our FL entries. But it will still be fun for polyglots. DCDuring TALK 14:25, 7 April 2013 (UTC)

"Bla bla bla think of the children, it will be doom if we allow such transgressions". Ok, can you actually read what I am saying and not go off on a panic spree? —CodeCat 16:07, 7 April 2013 (UTC)

• Fixed. --Yair rand (talk) 22:22, 7 April 2013 (UTC)

  What is fixed exactly? Not 新#Cantonese which should arguably not be.

The non-L2 header links? So, for a missing header like Gorilla#Etymology at Gorilla#Translingual it is the contributors responsibility to avoid the reference.

Is plata#Latin fixed using CodeCat's approach? DCDuring TALK 23:06, 7 April 2013 (UTC)

See diff. I set it to ignore categories listed in the exceptionCategories array, which currently only contains Category:Latin American Spanish. Not an ideal solution, but I can't think of a better one that won't come with its own problems.

I think it would be best to leave the 新#Cantonese issue as it is. A link to an empty section like that isn't really much better than a broken one. --Yair rand (talk) 00:10, 8 April 2013 (UTC)

Thanks for making the change and for the helpful explanation. If I see a problem that can't be solved by adding to the array, I'll let you know. DCDuring TALK 00:57, 8 April 2013 (UTC)

• Um, plata#Latin still shows up as blue for me, despite the lack of any Latin entries on that page. Flushing my browser cache (Chromium on Ubuntu) doesn't seem to have any effect on this issue. -- Eiríkr Útlendi │ Tala við mig 22:19, 8 April 2013 (UTC)

  If you have the per-browser preference box "Color translation links orange instead of blue if the target language is missing on an existing page." checked, I wonder whether it's indeed a browser/OS issue. Do others with Chrome on other OSs have the problem? We don't - and probably can't - have a robust capability for handling less common combinations on our local specials. DCDuring TALK 22:46, 8 April 2013 (UTC)

Very minor bug

Relevant script: MediaWiki:Gadget-PatrollingEnhancements.js

In the recent changes script that provides for admins the red bar at the bottom right, when I type in that bar it scrolls down the page. It's so innocuous I haven't bothered to report it yet. So if I type a really long deletion summary, I then have to scroll back up to click the red 'd' link to delete the offending page. Mglovesfun (talk) 11:24, 7 April 2013 (UTC)

What browser/system are you using? FWIW to whomever troubleshoots/fixes this issue, I can't reproduce that behaviour; I can type lots of text into the deletion-summary bar, and the page doesn't scroll (using Firefox 19 on Windows XP). - -sche (discuss) 22:43, 7 April 2013 (UTC)

Hmm. Can you experiment a bit, and describe the behavior a bit more precisely? For example:

• If you type a single letter, then wait a moment, then type another letter, do you find that it scrolls a certain distance when you type the first letter, and then scrolls the same distance when you type the second letter?
• Or do you find that the scrolling only happens when you hit the space bar? (In many browsers, the space bar can be used to scroll down the page, but of course it's not supposed to do that when you type an actual space into an actual text field!)

—Ruakh_TALK 23:03, 7 April 2013 (UTC)

Couldn't duplicate just by typing in the box no matter how many spaces using FF 19.0.2. and Windows, but I didn't undertake any actual deletion. DCDuring TALK 23:13, 7 April 2013 (UTC)

One small downward movement per character typed, not only the space bar, the same length of movement for every character. Using Google Chrome - I hadn't thought of testing it in Explorer and Firefox which I also have but no longer use. Mglovesfun (talk) 12:29, 9 April 2013 (UTC)

Category:Mandarin pinyin

The category needs a bit of clean up. With or without the main entry, the structure of the pinyin entry should stay strictly a link to Chinese characters - one word per line, traditional/simplified (if different) are passed as additional parameters. There should be no other definitions, pronunciation or references. (Monosyllabic are a bit different).

The parameters are unnamed. There were only a few entries, which used sim/trad, simp/trad named parameters. They are now gone and could be removed from the Template:pinyin_reading_of template.

Here's an example of a correct entry where trad/simp. are different characters "biànchéng":

==Mandarin==

===Romanization===
{{cmn-pinyin}}

# {{pinyin reading of|變成|变成}}

I wonder what tools we have for repetitive tasks like this other than manual editing -need to remove all references to dictionaries, short translations and pronunciation sections. --Anatoli ^{(обсудить}/^вклад) 01:54, 8 April 2013 (UTC)

GSOC Proposal -Pronunciation Recording Extension

Hello Everyone,

On the wikitech-l mailing list,i saw Pronunciaton Recording Tool feature request so i felt i could give this a try and now i am planning to undertake this as my gsoc project Since i am new to open source development if anyone could help me out or mentor me through the project i would be very happy

• My rough proposal is at https://www.mediawiki.org/wiki/User:Rahul21/Gsoc
• Feedback and suggestions are always valued and welcome

Thanks Rahul(Rahul_21 on the IRC #mediawiki,#wikimedia-dev)

A quick update on this:

Rahul21 has collected a team, including MDale as code mentor and Lars Aronsson as the community Liaison. The Google Summer of Code application draft is firming up with feedback from WMF, Mozilla, Vorbis, and several languages of Wiktionary. If the English wiktionary wants to have influence in the project's goals, now is the time!

- Amgine/ ^t·e 15:16, 16 April 2013 (UTC)

Question about data normalization and where entry data goes

Previous discussions of somewhat similar ideas: WT:BP#Restructuration_of_foreign_languages, WT:BP#Pages_getting_too_big.3F

I've been chewing on this idea for some time.

Why do we put all data for all languages in one big page? This is extremely messy, from a data organization viewpoint.

Putting each language on its own subpage would resolve many different issues. (Ignore, for the moment, the major amount of work required to refactor existing entries to implement this.)

• Instead of putting all information for all languages that have a term spelled "ni" on the [[ni]] page, there would be one [[ni]] page with one subpage for each language: [[ni/Navajo]], [[ni/Japanese]], etc. Or, perhaps using the lang codes, giving [[ni/nv]], [[ni/ja]], etc.

• Each subpage would be transcluded onto the main page, so any reader looking at [[ni]] would perceive no change.

• One could tell immediately whether a term were missing in a given language, without having to parse the page or check categories. This would resolve, or at least help resolve, issues like as the link color oddities for plata#Latin in the thread further up this page.

• Special:WhatLinksHere would be much more useful -- one could find out much more easily whether a given template is used by a given language, for instance.

• Tabbed languages would potentially be simpler to implement.

I'm keen to find out if anyone knows why we are using the current "all languages on one page" format. I suspect it's entirely due to legacy data and momentum, but I'm aware that I may be missing some other big gotcha or limitation of the MediaWiki software that would render the "each language on a subpage" data format unworkable.

Curious, -- Eiríkr Útlendi │ Tala við mig 22:36, 8 April 2013 (UTC)

I would support this idea and have supported it in the past, but it seems to have enough opposition here that it never actually gets any further than an idea. —CodeCat 22:50, 8 April 2013 (UTC)

I somehow like the reverse naming: [[ja/ni]], [[nv/ni]], but I guess this is harder to use. Wyang (talk) 23:13, 8 April 2013 (UTC)

• Would the parent pages ([[ja]] and [[ni]] in this example) then be the indices for each language?

However, that does run into the problem that [[ja]] and [[ni]] are already existing pages. -- Eiríkr Útlendi │ Tala við mig 23:39, 8 April 2013 (UTC)

All those look like real advantages. It would also mean that template such as {{l}} would be unnecessary for same-language links and that omitted lang= parameters in {{term}} etc could default to the same language. It would also dramatically improve load time for non-English terms that were homographs of English terms, especially those with really large translation tables. The load-time problem for English terms with large translation tables would not be helped significantly, unless translation tables, too, were on a separate subpage, not automatically transcluded.

How should Translingual pages (characters, symbols, taxons) be handled in such a regime? DCDuring TALK 23:18, 8 April 2013 (UTC)

• Translingual entries would presumably be at the */mul subpage, so [[ni/mul]] in this example. My thought is that the top-level term page would only ever be the container, but perhaps some other arrangement might work better. -- Eiríkr Útlendi │ Tala við mig 23:39, 8 April 2013 (UTC)

  Translingual entries are supposed to be useful in many languages. Taxons are usable by biology professionals even in languages using non-Latin script. Characters and symbols have similar broad reach. That's the justification for having them at the top of the page, so that there is no need to repeat the content in every (applicable) language. We would need some kind of obvious way of reminding users of these things and might have to be much more explicit about the precise scope of the Translingual terms and each particular sense thereof. We have largely finessed this point. DCDuring TALK 02:03, 9 April 2013 (UTC)

• Agreed. I'm not sure how this affects this proposal, however? The idea is that anyone looking at [[ni]] (or any other page) as a reader would see exactly what's already there. -- Eiríkr Útlendi │ Tala við mig 05:08, 9 April 2013 (UTC)

  If all the content is transcluded, then the page-load time improvement doesn't apply. In fact page-loads would be slightly worsened. DCDuring TALK 11:06, 9 April 2013 (UTC)

Both arrangements have advantages. When it comes to templates or modules, it doesn't really matter because we can extract both the base name and the subpage name. One advantage of putting the word first is that it matches our current arrangement somewhat more, because each base page would then have one subpage for every language. On the other hand, the reverse arrangement with the language first is more like how we treat Appendix entries. I don't think either one really has any clear advantages or disadvantages, it's more down to our own preference and logical approach to entries. Another question we need to answer though is whether we use language names or codes in the title. And what to do with the thousands of bare links and uses of {{term}} without a lang= parameter, which will break? —CodeCat 00:46, 9 April 2013 (UTC)

• Lang codes would be shorter. Lang names would be more human-friendly.

Why not use both? Lang names could redirect to the lang code subpages, or the reverse, as deemed appropriate.

• {{term}} would presumably just link to the bare entry, [[ni]] in this case, which would be the container into which all of the language pages would be transcluded. [[ni/mul]] would go at the top if it exists, followed then by [[ni/en]], and then all the other langs in alphabetical order. -- Eiríkr Útlendi │ Tala við mig 00:51, 9 April 2013 (UTC)

The only way to make redirects like that work is to have a redirect for every entry. I don't see that happening... —CodeCat 01:21, 9 April 2013 (UTC)

• We have bots for basic maintenance stuff, no?

Assuming we're putting the data under the lang code, then a bot would check for each [[ni/langcode]], to see if there is a corresponding [[ni/langname]]. If it's missing, the bot would create it as a redirect to [[ni/langcode]].

But that's even assuming that we'd want both lang code and lang name URLs. -- Eiríkr Útlendi │ Tala við mig 05:12, 9 April 2013 (UTC)

• I don't see any significant possible benefit, and a lot of potential downsides. Anyway, we have no real technical means to do this. --Yair rand (talk) 01:01, 9 April 2013 (UTC)

  Could you add more detail to that? I'm not aware of the downsides, which is partly why I asked.

  I'm also a bit confused about your comment that "we have no real technical means to do this" -- this would be very bot-able, as there's nothing that complicated involved in changing the structure of existing entries, just the tedium of actually doing so. -- Eiríkr Útlendi │ Tala við mig 01:19, 9 April 2013 (UTC)

  We don't have any way that I know of to have each page display the contents of each of its subpages. The downsides: Categories would be severely messed up. The category pages would be packed with languages codes, and would link to problematic "part-entries". The entries either wouldn't list categories at all at the bottom, or would be doubled in the category page. Special:WhatLinksHere would also go to the "part-entries", and would additionally contain main entry duplicates for every link. The search bar would be clogged with extra suggestions that wouldn't mean much to the users. --Yair rand (talk) 01:34, 9 April 2013 (UTC)

Splitting these various issues up for reply.

• "Categories would be severely messed up."
  • "The category pages would be packed with languages codes,"

    Not necessarily a problem. I'd actually prefer it if I could tell at a glance whether a term in a given language were present in a category.

    Is this helpful to our readers? Afaik, all mainspace categories are single-language. Having "/French" added to every link would just cause confusion. --Yair rand (talk) 06:44, 9 April 2013 (UTC)

  • "[The category pages] would link to problematic "part-entries"."

    I think maybe you've misunderstood what I'm proposing? Or maybe I've misunderstood what you mean by "part-entries"? The idea is that the whole Japanese entry would be moved to [[ni/ja]] or [[ni/Japanese]], depending on whether folks prefer lang codes or lang names. There wouldn't be any part-entries.

    If you think that having the entire Japanese entry for ni at [[ni/Japanese]] would be problematic, I don't understand what would be problematic about that. Could you explain?

    I thought you were suggesting that the viewing of entries would still take place through a central non-single-language page so that there could still be quick switching between languages. If so, then links that go directly to single-language entries ("part-entries") as though they were full entries would be problematic. --Yair rand (talk) 06:44, 9 April 2013 (UTC)

    • Unclear what the problem would be. If a reader clicks a link that is intended by both the reader and the editor who added the link to lead the reader to the Romanian entry, then I fail to see any problem at all if the user does not see the Welsh entry. Actually, not seeing the Welsh entry could be argued to be a bonus, rather than problematic.

    If instead you mean that the problem is ease of changing between languages for any given term, what I'm envisioning would ultimately be a combination of a parent page (see sample at [[User:Eirikr/Sandbox3/ni]]) that would be identical to our current format for readers, and the individual language subpages (such as [[User:Eirikr/Sandbox3/ni/sq]] or [[User:Eirikr/Sandbox3/ni/cy]]) which would ultimately be quite similar in appearance to Tabbed Languages. One would provide an all-in-one view, the other would provide just the target language, with links at the top to the others. {{subpages}} already offers a basis from which to create such a header. -- Eiríkr Útlendi │ Tala við mig 02:49, 10 April 2013 (UTC)

  • "The entries either wouldn't list categories at all at the bottom,"

    I just created a test sample at [[User:Eirikr/Sandbox3/ni]]. All cats on the various sub-pages appear on the parent page (excluding those cats where the including template has logic to check the namespace and only include the cat if in the main namespace).

  • "...or [the entries] would be doubled in the category page."

    Category:Swahili_terms_needing_attention is called from the test page. I do see both [[User:Eirikr/Sandbox3/ni]] and [[User:Eirikr/Sandbox3/ni/sw]] listed there now.

    While this is an issue, it seems little more than a minor nuisance, and is not insurmountable. For categories included by templates, the templates could contain logic to limit category inclusion to only lang-specific sub-pages.

    Fixing this problem would cause the one mentioned above, and vice versa. --Yair rand (talk) 06:44, 9 April 2013 (UTC)

  • "Special:WhatLinksHere would also go to the "part-entries","

    See above about "part-entries".

  • "and [Special:WhatLinksHere] would additionally contain main entry duplicates for every link. "

    Yes, this would be an issue, but again, it seems little more than a minor nuisance.

  • "The search bar would be clogged with extra suggestions that wouldn't mean much to the users."

    This could be at least partially addressed by using lang names instead of lang codes in the URLs. If a user searches for [[ni]] in search of the Zulu term, and [[ni/Zulu]] is one of the hits, they know right where to go.

    Past there, the search index hasn't yet been updated to include my test page.

So aside from the "part-entries" bit where I'm not sure what you mean, it looks like the net negative effect would be a couple of minor nuisances.

In terms of positives, just on the surface of it, it would be much easier to tell what languages have an entry for any given term. This does away with a whole class of problems, including the script rejiggering required just earlier this week to handle lang-specific orange links. Does that really qualify as "[not] any significant possible benefit"?

-- Eiríkr Útlendi │ Tala við mig 06:18, 9 April 2013 (UTC)

That issue is bug 16561, which is probably far more likely to be fixed than the necessary changes to split entries into language subpages, largely because identifying broken section links is also a somewhat important issue for a certain large sister project of ours. --Yair rand (talk) 06:44, 9 April 2013 (UTC)

• I see a lack of any comments in that thread since late 2010. It's also not entirely clear what "certain large sister project of ours" you intend; I assume you mean Wikipedia, but that isn't very clear from the thread. -- Eiríkr Útlendi │ Tala við mig 02:49, 10 April 2013 (UTC)

Sounds like a great idea to me.

But why transclude the entries into the root page? Just put an automatic index there, floated to the right of the the multilingual entry. Categories should collect entries okay, but can they display their titles correctly? The only problem I can see is displaying the title at the top of a language entry’s page.

If we’re reorganizing, is there a way to avoid adding a level of subheadings for “Etymology 1,” &c.? —Michael Z. 2013-04-09 02:50 z

• I proposed transclusion simply because that can be done right now, whereas an automatic index would presumably require that someone code one up first. Now that we have Lua, that should be easier to do. It could also have the side benefit of obviating the nuisance issues mentioned above.

However, I'm also keen to avoid any major disruption to readers, and transclusion into the parent page would result in an entry page visually identical to what we already have.

• Not sure what you mean about "adding a level of subheadings", though. -- Eiríkr Útlendi │ Tala við mig 06:20, 9 April 2013 (UTC)

I mean while rat#Noun is an <h3> heading as expected, but, inconsistently, root#Noun is an <h4> because it is pushed down by the “Etymology 1” and “Etymology 2” heading. Bugs me. —Michael Z. 2013-04-09 23:02 z

Why is it that WT:ELE has us do it the way we do? Is it a relic of a pre-CSS approach to making an entry's heading look good? DCDuring TALK 23:10, 9 April 2013 (UTC)

I think it’s an information-organization problem at its root. Our page/heading structure is term/language/etymology/p.o.s, e.g., Rat/English/Etymology/Noun. But we omit the Etymology 1 subheading when there is only one. There’s nothing really wrong with this, although it must add a layer of complication to some bots that need to find the subheadings. I think we could style the subheadings consistently by selecting on the IDs of etymology headings, if we can pick a reasonable style for the extra etymology heading itself.

HTML5 adds new elements (<article>, etc) and a new document structure model that could help make sense of this, but MediaWiki doesn’t support this yet. —Michael Z. 2013-04-10 01:45 z

And then there are the 1,827 members of Category:Entries_with_Pronunciation_n_headers, which don't conform to WT:ELE and can't be reconciled with it, at least in EP's opinion. DCDuring TALK 01:50, 10 April 2013 (UTC)

I oppose splitting entries into subpages for the same reasons I opposed it the last time it was proposed. - -sche (discuss) 04:17, 9 April 2013 (UTC)

• Reading that link, it sounds like you would not be opposed to changes provided the reader sees no difference. Is that still the case?

It also sounds like your opposition was partly based on different ideas to what I'm proposing here -- splitting into subpages as I'm imagining it would be based purely on language, and not have anything to do with page size. This is based more on my understanding of how our infrastructure works with terms on a by-language basis, and the kinds of workarounds required because finding out which languages have entries for any given term is more complicated than just looking at the existing URLs. -- Eiríkr Útlendi │ Tala við mig 06:26, 9 April 2013 (UTC)

I wouldn't like it as I would like to read the wikitext of all the entries in one go, and use the auto-formatting properties of User:Mglovesfun/vector.js. However, if there were a majority in favor of it, I'm sure I'd get used to it. Mglovesfun (talk) 12:08, 9 April 2013 (UTC)

I vehemently oppose the change; I think it would be an all-around bad move. It would not only make it more difficult for editors like me and Mg and Meta, who often edit all language sections in one go, it would make it more difficult for newcomers to start editing Wiktionary: they'd click the 'edit' link at the top of the page and see nothing but a few lines encased in curly brackets.

Furthermore, you propose to avoid changing how entries like [[foo]] look. That is good, inasmuch as fragmenting the displayed content would cause major problems separate from those that fragmenting the actual content/wikitext would cause. But ensuring that the display does not change requires double effort on the part of editors, to always edit foo after creating foo/bar, and requires constant vigilance on the part of other editors to ensure no-one forgets to transclude a foo/bar into a foo.

If any part of that vigilance is entrusted to a bot, the bot will have to be reliable enough that nothing slips through the cracks while the bot is down, and smart enough that it can handle or flag creations of [[foo/not-a-real-code]] and not mis-handle naming conflicts...

...because, as Liliana mentioned in the previous discussion, enough words are spelt with slashes that naming conflicts are inevitable. For example, s/he would seem (to a bot) to be a Hebrew entry (missing a Hebrew L2, no less!) that should be transcluded into s; it would also conflict with any real Hebrew entry [[s]], if one ever needed to be created.

This proposal would duplicate every main-namespace page, even that supermajority of NS:0 pages which have only one language section. It would move the first-person plural imperfect active indicative of fugio to fugiebamus/la, but leave a shell at fugiebamus to contain it; likewise it would have arrodillasen/es transcluded into an otherwise empty arrodillasen, with the aforementioned constant effort required to ensure that if [[arrodillasen/foo]] ever were created, it would be transcluded. It would be easier and IMO better to leave the content at fugiebamus and arrodillasen. - -sche (discuss) 03:58, 10 April 2013 (UTC)

Strongly oppose. It's unhelpful technically (as Yair explained above), it doesn't benefit the readers, and it's worse for editors like me who work with several related languages at a time. Looks like a classic lose-lose, and this format is one of the reasons why I don't edit on wiktionaries in other languages I speak. —Μετάknowledge^{discuss/deeds} 23:39, 9 April 2013 (UTC)

Why doesn't it benefit the readers? When we used to hear from normal users, one common complaint was that they found the presence of many languages on the page confusing. Another common complaint was about the incredible length of the table contents. Do you have anything to support your assertion? DCDuring TALK 00:03, 10 April 2013 (UTC)

It seems you misunderstand this. The presentation will still be the same. The page ni will still have all the languages and the long TOC. As for the long TOC, TabbedLanguages solves that, and the sooner it is implemented, the better. —Μετάknowledge^{discuss/deeds} 19:19, 11 April 2013 (UTC)

• @Metaknowledge, one thing that is currently infeasible with our "all languages on one page" organization is linking reliably to any POS header for a given language.

For instance, the Portuguese noun on the [[ni]] page has an ID of Noun_4. If an additional language is added above the Portuguese entry, this now has an ID of Noun_5, and anything that previously pointed to the Portuguese noun that was at Noun_4 is now pointing at who knows what, quite possibly at the Italian noun instead. The link URL, containing only the obscure numbered target [[ni#Noun_4]], wouldn't give editors or savvy readers any clue as to what language was intended.

By splitting languages into their own subpages, we could have much more reliable linking: [[ni/pt#Noun]] will only ever point to the Portuguese noun, and will never inadvertently point to the Italian noun. Editors and savvy readers can also tell from the target URL what language the link points at.

But this technical benefit is only possible when we don't throw all the data into one undifferentiated bucket. -- Eiríkr Útlendi │ Tala við mig 02:20, 10 April 2013 (UTC)

Why would we want to link to POS sections? I understand wanting to link to specific senses, which we can do with {{senseid}}, but where would it be useful to link specifically to a POS header? --Yair rand (talk) 02:42, 10 April 2013 (UTC)

There is {{anchor}}, which can be used to allow links like foo#Dutch_noun to specific sections in those entries—that relatively minuscule minority of our 3,3 million entries—which have two Noun (or Verb, etc) sections. - -sche (discuss) 04:04, 10 April 2013 (UTC)

Also, e.g., the Swedish word en (meaning “juniper”, not en meaning “one”) is defined at en#Etymology_2_3. —Michael Z. 2013-04-10 03:16 z

Eirikr, it seems that the big advantage you are advertising already exists by means of {{anchor}}. Do you have any convincing argument that we don't already have the capabilities for? —Μετάknowledge^{discuss/deeds} 19:19, 11 April 2013 (UTC)

Etymtree

See Template:etymtree/Module:etymtree (which is horribly written at the moment, but ignoring that for a minute...), as used in Appendix:Proto-Indo-European/wódr̥ and Appendix:Proto-Germanic/watōr. The full tree is stored at Template:etymtree/ine-pro/wódr̥, but the relevant branches are pulled out by the template. Are there any serious downsides to using this system instead of the current system where trees are either duplicated across entries or missing some parts? --Yair rand (talk) 09:03, 9 April 2013 (UTC)

The main problem I see with your naming scheme is that words might have multiple sets of descendants, like *aljaną. How do you keep them apart? —CodeCat 13:05, 9 April 2013 (UTC)

If they're both roots of separate trees, then they could just be called Template:etymtree/gem-pro/aljaną/1 and Template:etymtree/gem-pro/aljaną/2 (or something like that), I guess, and that wouldn't really cause any additional problems.

If there are multiple words in one language with the same spelling on the same etymology tree, however... yeah, I have no idea how to deal with that. Hm... --Yair rand (talk) 22:42, 9 April 2013 (UTC)

Portuguese verb oddity

In the conjugation table for Portuguese -erir verbs (see ferir as an example) it says that investir, revestir and vestir have this conjugation. This is false, but the templates are so convoluted that I can't figure out how to fix it. SemperBlotto (talk) 15:36, 11 April 2013 (UTC)

They do. They are third-conjugation verbs where the e preceding the thematic vowel becomes i in some forms. — Ungoliant ^(Falai) 16:05, 11 April 2013 (UTC)

• • But they use {{pt-conj|xyz|vestir}}, not {{pt-conj|xyz|erir}}. SemperBlotto (talk) 16:08, 11 April 2013 (UTC)

Ok. I changed them. — Ungoliant ^(Falai) 18:53, 11 April 2013 (UTC)

A Question on Modules

I've been seeing contributions on modules lately. Could they replace templates, or could they both stay? Besides, I'm wondering, what are modules, and how are they used? --Lo Ximiendo (talk) 08:03, 12 April 2013 (UTC)

See WT:LUA, w:WP:LUA --Z 09:05, 12 April 2013 (UTC)

Short answer: Modules do not replace Templates, but they complement them when complex operations (such as string manipulations) are required. Dakdada (talk) 13:40, 12 April 2013 (UTC)

Double references

In the page herre, why does footnote 1 appear in two places? Isn't each <references/> supposed to list only those footnotes that were added since the last appearance of that tag? Has this changed and what is the cure? --LA2 (talk) 22:38, 12 April 2013 (UTC)

The page mw:Extension:Cite/Cite.php says "In the case of multiple references-tags on a page, each gives the references defined in the ref-tags from the previous references-tag", which is how I remember it used to function. --LA2 (talk) 22:51, 12 April 2013 (UTC)

Oh, my fault, the same <ref>...</ref> tag is indeed repeated in the next section. --LA2 (talk) 22:53, 12 April 2013 (UTC)

GSOC Proposal - DICT api to Wiktionary

There is now a project idea for the 2013 Google Summer of Code to make Wiktionary content available via the DICT protocol. This is in part due to bugzilla #36881.

There are currently more than 15 apps with a couple million downloads between them which use Wiktionary content for dictionary reference, but as far as I am aware each uses old data dumps which have been processed by a 3rd party, some many years ago. If this project is accepted and implemented in MediaWiki, we can expect our content reuse to climb dramatically as apps would be able to retrieve our latest data.

The WMF is looking for a community liaison for this project, just in case a student comes along looking to pick this one up. (This suggests to me there is interest at the foundation to see this implemented in the MediaWiki api, though that is plainly speculation on my part.) So, the first discussion point is: who would be interested in being the go-between with the developers?

- Amgine/ ^t·e 15:36, 16 April 2013 (UTC)

English category bug

Was just browsing Category:English words prefixed with cyno-. If you hover over the individual entries, they are linked to with an invalid hash anchor {{{{{lang}}}}}. I suppose this is from using {{prefix}} with no language. Mglovesfun (talk) 22:43, 16 April 2013 (UTC)

I've fixed that. But problems like that could probably be prevented in the future by changing this template. The language code should really be the first parameter, so that it's clear that it's mandatory. —CodeCat 23:01, 16 April 2013 (UTC)

Or made to be not mandatory at all, which is hypothetically at least what it does now. Mglovesfun (talk) 23:10, 16 April 2013 (UTC)

I firmly believe that using English as the default is a bad practice, so I can't agree with that. Furthermore, all our other category templates already take the language code as their first parameter. —CodeCat 23:16, 16 April 2013 (UTC)

Documentation tab of templates and modules

We've been slowly moving template documentation from /doc to /documentation. Currently, though, the "documentation" tab at the top of the page still links to /doc. How can this be changed? Also, modules should also have such a tab. —CodeCat 16:44, 18 April 2013 (UTC)

It's in Mediawiki:Common.js, under "Make tabs for citations-pages and template-documentation-pages". --Yair rand (talk) 16:45, 18 April 2013 (UTC)

Using a function in the same module

It may sound like a rather dumb question but how can I achieve this? Say the code is

p = {}
function p.a(f)
 text = mw.ustring.gsub(f.args[1],'.','a')
 return text
end

function p.b(f)
 text = p.a(f.args[1])
 return text
end

return p

Thanks. Wyang (talk) 23:12, 18 April 2013 (UTC)

I'm not sure what you're trying to achieve, but calling p.b won't work because f.args[1].args[1] probably doesn't exist. By passing the specific argument to p.a, the new f is set to the previous f.args[1], and since it doesn't itself have a args[1], it will break. Is text = p.a( f ) what you want to have? (Note that this would be basically basically the same thing as just setting p.b = p.a.) --Yair rand (talk) 00:19, 19 April 2013 (UTC)

I see. Should be text = p.a(f) in p.b(f). Thanks. Wyang (talk) 00:27, 19 April 2013 (UTC)

Adding a template to a category

I've added Template:ru-noun-anim-1-unc (will add other templates with -unc suffix) to Category:Russian uncountable nouns. Terms that use the template now show that they belong to Category:Russian uncountable nouns, e.g. Нептун. When I open the category, it just shows 8 terms! What is wrong? Is there a DB delay or something? --Anatoli ^{(обсудить}/^вклад) 23:46, 18 April 2013 (UTC)

Yes it was a database delay. Problem is, there are some singular-only entries in that category now, like Иисус which isn't uncountable, just singular-only. Unless Russian grammar doesn't make any distinction between these two. Mglovesfun (talk) 14:42, 19 April 2013 (UTC)

Does any grammar make that distinction? —CodeCat 15:21, 19 April 2013 (UTC)

Well English does; you can't some "some Jesus" in the same way you can say "some grain" or "some water". French does too. Mglovesfun (talk) 15:31, 19 April 2013 (UTC)

"Yesterday I met some Jesus who was trying to sell me a watch." —CodeCat 15:43, 19 April 2013 (UTC)

MG said "in the same way you can say 'some grain' or 'some water'". That's a different sense of "some". Chuck Entz (talk) 19:13, 19 April 2013 (UTC)

Is the suggestion that "uncountable" means the same as "something you can have a quantity of"? To me, uncountable means that it can't consist of multiple individual instances. —CodeCat 19:24, 19 April 2013 (UTC)

Thanks for addressing this, guys. I'm having second thoughts about this categorisation, though. The templates with "-unc" suffix are used when there are no plurals. Theoretically, personal names, names of cities, gods, etc. all can have plurals. --Anatoli ^{(обсудить}/^вклад) 09:49, 20 April 2013 (UTC)

Lua

{{#invoke:a|function|text||}} seems to be treated differently from {{#invoke:a|function|text|}}, as

if f.args[3] == '' then

or

if f.args[3] == nil then

treats the former code as false but the latter as true. Is there a way to solve this? Thanks. Wyang (talk) 05:16, 20 April 2013 (UTC)

It's not a bug, an empty string is not just not the same as a nil value. Just write

if f.args[3] == nil or f.args[3] == '' then

in your code. Dakdada (talk) 12:01, 20 April 2013 (UTC)

I usually write something like this: local param = args[3]; if param == "" then param = nil end —CodeCat 12:37, 20 April 2013 (UTC)

Ugly font in taxonomic name inflection line

What template or other change led to the use of a hideous, too-small serif font for taxonomic name entries? See [[Datura]] or any other such entry. Who makes such decisions? DCDuring TALK 14:50, 21 April 2013 (UTC)

Looks the same as ever to me... sure it isn't on your end? —Μετάknowledge^{discuss/deeds} 15:03, 21 April 2013 (UTC)

Could be. Where would I look?

It seems to effect Translingual inflection lines, various other language inflection lines (eg. Greek), certain uses of {{term}}, and various template-sourced text such as the content of a show/hide bar for Greek declension. It appears using both Vector and Monobook skins. DCDuring TALK 15:29, 21 April 2013 (UTC)

Looks normal to me (Monobook under Chrome). SemperBlotto (talk) 15:34, 21 April 2013 (UTC)

I disabled Webfonts. Is that a possibility? [Apparently not].

It occurs with all my per-browser choices at default. I haven't noticed anything different at other websites. DCDuring TALK 15:36, 21 April 2013 (UTC)

It appears whenever I use Template:head in principal namespace or {{term}}: gratis

but not

1. {{l/en}}: gratis
2. {{t}}: gratis (en).

Does it have to do with the font selection used by Template:head and {{term}}? A CSS solution to fix my problem for me would help me, but would not be wise in case I am functioning as a miner's canary or the idiot in idiot-proofing. DCDuring TALK 15:59, 21 April 2013 (UTC)

I don’t see the problem in Safari/Mac or Firefox/Mac. Does it affect any of these lines?:

1. lang="mul"
2. class="mention-latin"

What browser/version are you using? If Firefox, check your Preferences > Content > Languages > Fonts & Colors > Default Font > Advanced > Fonts for. Make sure that under both “Western” and “Other Languages” you have “Sans-Serif” set to a sans-serif font, preferably the same one. —Michael Z. 2013-04-21 16:17 z

Bingo! Thank you very much, MZ. I didn't remember making that change, though I remember visiting the page.

What advantage do we get from letting that kind of user preference affect the display of this website? No other site that I visited seemed to be affected by that mistaken selection, so they must exercise more control over fonts - and do so uniformly. DCDuring TALK 21:17, 21 April 2013 (UTC)

Lucky guess. 🐰

Few users ever touch those settings, especially now that browser support for UTF-8 has obsoleted separate code pages for each language or script. Safari only ever had default and monospace font settings, and has done away with those completely, although it does have a user style sheet. Firefox probably has a hard time dropping archaic features because of workflow.

I think few sites use lang attributes at all, except perhaps on the root html element, and a tiny proportion even have reason to use things like lang="mul" or lang="und". We are simply more langed up than any other website

But because we are trying to keep our lang codes correct, the few readers who want control will be able to use their browser’s language preferences and user style sheets. I anticipate browser makers will continue to improve tagged language support. —Michael Z. 2013-04-21 22:55 z

Can Lua determine if a template is called from another template?

Lua uses the getParentFrame function to find out the parameters that were passed to the templated that invoked it. So, for example, say that {{term}} contains {{#invoke:term cleanup|cleanup}}. Then if {{term}} is called like {{term|word}}, then within Module:term cleanup, frame.getParentFrame().args[1] will equal "word". What I would like to know is... is it possible for the module to determine, in some way, which namespace {{term}} was called from, so that it can tell the difference between, for example, {{term}} being directly in a mainspace entry, and being called from another template. —CodeCat 15:21, 21 April 2013 (UTC)

I don't believe so, no. They don't want us inspecting the whole stack, just the topmost frame. (And TBH, I think that's a good thing. If I write a usage-note template that invokes {{term}}, I should be able to expect that it will behave the same way as if I'd put the usage-note directly in the entry.) —Ruakh_TALK 17:02, 21 April 2013 (UTC)

I understand that, but it would be very useful (for clearing out erroneous template uses) to be able to find which are being called through another template. Because fixing that template would probably fix many entries at the same time. It's a shame we can't use it... —CodeCat 17:08, 21 April 2013 (UTC)

Kassadbot not running?

There are over 4,000 entries in Category:Requests for autoformat. SemperBlotto (talk) 11:12, 23 April 2013 (UTC)

It was blocked due to a dispute regarding Japanese entries. So yeah. -- Liliana • 19:56, 23 April 2013 (UTC)

There are some allegations that you, Liliana-60, deliberately changed the KassadBot's code to pick up entries Category:Japanese romaji after a consensus was reached on how to format romaji entries - a strict format, which definition lines are generated by the template, see kochira:

==Japanese==

===Romanization===
{{ja-romaji|こちら}}

Which produces:

Japanese

kochira

1. See こちら

KassadBot didn't pick up any single romaji entry before that between 16 March and 7 April (after my edit to add # on a new line in Template:ja-romaji see diff). KassadBot started flagging romaji and adding them to Category:Japanese definitions needed after the 7th of April.

If you're not going to start working on Japanese entries, please consider changing the code back to what it was before 7th April or make an exception for Japanese and Gothic romanisation entries. It's possible and you know it. Editors working with Japanese have already expressed their strong opinion on this and converted all (nearly 7,000) romaji entries to a new style. I apologize in advance if you didn't do anything deliberately but you didn't sound very convincing when you denied changing KassadBot's code. --Anatoli ^{(обсудить}/^вклад) 22:53, 23 April 2013 (UTC)

That's kind of the problem with negative proof; it's almost impossible to prove that one didn't do a certain thing. I could show the application's timestamp (with a last-modified date sometime in December 2012) but then people would say it's faked. I could say that anyone who runs the bot with the code I provided on this wiki (for a good reason!) would see it perform the same changes, but nobody would try and people would still not believe me. See what a difficult situation this is? -- Liliana • 05:59, 24 April 2013 (UTC)

OK, I believe you. We have to move forward but I don't know what we'll do. --Anatoli ^{(обсудить}/^вклад) 06:19, 24 April 2013 (UTC)

There are now over 7,000 entries in Category:Requests for autoformat. This needs to run. SemperBlotto (talk) 11:01, 1 May 2013 (UTC)

Now over 10,000 such entries. SemperBlotto (talk) 19:16, 16 May 2013 (UTC)

I have left a message at Talk:Buchmeierbot, as many of the entries in the category stem from the bot inserting Portuguese L2 sections at the very end of the entries, even after interwikis. DCDuring TALK 20:19, 16 May 2013 (UTC)

MewBot does that as well, so it will be generating a lot more of them next time it runs. —CodeCat 21:30, 16 May 2013 (UTC)

Yes, this is expected behaviour. KassadBot is not blocked by Liliana-60 isn't running the autoformat code - just the German verb form code. Mglovesfun (talk) 21:34, 16 May 2013 (UTC)

I could try to make MewBot insert the sections in the correct place, but that would be a lot of work and there'd be a higher chance of errors too. Autoformat is tried-and-true code. —CodeCat 21:36, 16 May 2013 (UTC)

Is Kassadbot running? If not, can someone convince Liliana to fix the code for Japanese / Gothic romanisation entries and restart Kassadbot? --Anatoli ^{(обсудить}/^вклад) 23:43, 16 May 2013 (UTC)

Since when are we changing Gothic entries? —CodeCat 23:46, 16 May 2013 (UTC)

The topic is here: Wiktionary:Beer_parlour/2013/April#Gothic_romanisation_template. The proposed template is {{got-romanization}}. --Anatoli ^{(обсудить}/^вклад) 00:11, 17 May 2013 (UTC)

I'm really not very happy with this new practice of leaving out the # in the wikitext. It makes things harder for bots and even for me visually I find it hard to figure out. —CodeCat 00:16, 17 May 2013 (UTC)

But that was meant to make the structure rigid, so that no extra definition were added, just what was generated by the template. If I understand correctly, bots can look at expanded definitions, if they need to be looked at at all. User:Eirikr has replied to your concern in Wiktionary_talk:Votes/pl-2013-03/Romanization_and_definition_line#KassadBot_and_romaji_entries.

With Gothic it's just a proposal but with Japanese romaji I don't know if anyone would be happy to change them to a different style, again, including the opponents of the proposal. Many thousands entries were converted manually. Contributors may just abandon editing romaji entries altogether. --Anatoli ^{(обсудить}/^вклад) 00:38, 17 May 2013 (UTC)

Bots can expand templates, but it makes them quite a bit slower because it basically means sending a second request for each page. Another problem is that they cannot expand just one level, so the end result will look like this and not contain any templates anymore. —CodeCat 00:49, 17 May 2013 (UTC)

If performance is the issue, then perhaps bots should have a list of exceptions. The quality of the romaji entries is maintained by editors and the structure of the template itself. --Anatoli ^{(обсудить}/^вклад) 08:36, 17 May 2013 (UTC)

Now over 12,500 entries in Category:Requests for autoformat. SemperBlotto (talk) 07:25, 2 June 2013 (UTC)

Returning the number of items under a Category

Hello. I'm an administrator in the Spanish Wikcionario and they're trying to create a template for a "language of the month" feature. A user is asking if we could display a sentence like "We currently have X number of entries in" (the language of the month). Does anybody here know if there is a magic word or parameter I can use to return the number of entries in a Category? (That way the template would show the number of items in the Languageofthemonth-Español Category). Thanks in advance for your help. If you could answer in my User talk:Edgefield page here, that would be even better. Best, --Edgefield (talk) 22:41, 23 April 2013 (UTC)

Ah, I just saw this {{PAGESINCATEGORY:categoryname}} word; I'll give it a try. Thanks, --Edgefield (talk) 22:42, 23 April 2013 (UTC)

MediaWiki:Gadget-RegexMenuFramework.js and MediaWiki:Gadget-HotCat.js

My browser refuses to load these two gadgets when browsing through HTTPS. Please copy the code from w:MediaWiki:Gadget-RegexMenuFramework.js and w:MediaWiki:Gadget-HotCat.js. Keφr (talk) 07:44, 24 April 2013 (UTC)

Module:headword

I have created this module as a replacement for {{head}}. Not all of it works yet, only the categories at the moment. I've moved that part over from the template to the module, and things seem to work. —CodeCat 14:14, 25 April 2013 (UTC)

On a side note, please don't forget to add comments in the code. There are already too many uncommented modules out there. Dakdada (talk) 14:36, 25 April 2013 (UTC)

Was this discussed anywhere before it was implemented? --Yair rand (talk) 15:47, 25 April 2013 (UTC)

Yes, here. —CodeCat 15:51, 25 April 2013 (UTC)

New idea about translations

The translation sections currently look like this:

{{trans-top|furniture}}
* Armenian: {{t-|hy|պահարան|tr=paharan}}
* Dutch: {{t+|nl|kast|m|f}}
{{trans-mid}}
* Greek: {{t+|el|ντουλάπι|n|tr=ntoulápi|sc=Grek}}
* Persian: {{t|fa|کمد|tr=komod|sc=fa-Arab}}
{{trans-bottom}}

It is possible to change it to something like this, with Lua (compare this):

{{trans|furniture|
* Armenian: պահարան [-]
* Dutch: kast mf [+]
* Greek: ντουλάπι n [+]
* Persian: کمد (komod)
}}

I want to know if this is considered helpful by the community and is worth it. The code is more readable and is easier to edit for newbies, and the users won't have to know the ISO code of languages to edit. --Z 16:07, 26 April 2013 (UTC)

Are you saying that the translation should not be wikilinked? You realise that we would lose the link to the translated word in the "foreign" Wiktionary. SemperBlotto (talk) 16:15, 26 April 2013 (UTC)

No, read it again. --Z 16:36, 26 April 2013 (UTC)

It is possible, but would it actually be more efficient? This effectively turns Lua into a parser, which may slow things down rather than speed them up. —CodeCat 16:16, 26 April 2013 (UTC)

That may be correct, we need to test it and see it in practice. I've compared {{l}} to {{l-list}}, l-list was not slower, but a bit faster; but my current Internet connection is too slow unfortunately, so my test may be inaccurate, I would be thankful if someone else test it too. We can generalize the result to {{t}} vs. Lua method. --Z 16:36, 26 April 2013 (UTC)

I see lots of potential for problems from different versions (including misspellings) of the language names, varying order of arguments, varying punctuation, etc. It looks simpler than it is: although there's no obvious inline code, everything has to be set up the way the module expects it, or you'll need complex, time-consuming code to allow for all the possibilities. We have bots doing this kind of parsing, but we don't have site visitors waiting for the bots to finish every time they view an entry. There's also the matter of coordinating with changes to the translation-adder and to bots, though that's secondary. Chuck Entz (talk) 17:20, 26 April 2013 (UTC)

Some of these problems like versions of language links are really easy to fix without making the code that complex and slow. Regarding order of arguments, that's true, making things easier to work with are usually at the cost of increasing risks of using it -- the easier you can edit and change, the more things will be unintentionally messed up (although fixed order for arguments has advantage too: the code will be more similar to the output). The question is do you think it is worth it overall? --Z 18:12, 26 April 2013 (UTC)

Never mind guys, I'm disappointed. This will, at best, become something like #Module:links which eventually went nowhere, even though it was nothing but improvement. Trying to improve things by changing older ways is just a waste of time here. --Z 18:22, 26 April 2013 (UTC)

Yea, my two cents on it here, it's surely a lot more trouble than it's worth. :/ Certainly I don't think it's worth fiddling around to change stuff that much just to be a little more newbie friendly...the translation adder built in trans tables is pretty good for that IMO. As for having to know ISO codes, people (specifically newbies) should just learn to search ethnologue or whatever it is, or even search on wiktionary for

1. the entry for the language
2. a safer bet "Category:X language".

User: PalkiaX50 ^{talk to meh} 18:38, 26 April 2013 (UTC)

I support it. Semper's comment doesn't make sense, CodeCat has raised a concern without testing it, and Chuck said the code will be "complex" without giving any real examples of why it will be any more complex than what we already have. Why don't you guys give it a chance or at least bring up a real, concrete problem with it? —Μετάknowledge^{discuss/deeds} 23:09, 26 April 2013 (UTC)

The complexity and the speed problems will happen because we will have to write a lot of code just to make a Lua module "understand" this new programming language that we will be creating. Essentially, we will be implementing a language within another language. So why should we reinvent the wheel when we already have a language that works and that everyone is familiar with: template code? The presence of the translation editor makes this even more redundant, because users won't even need to interact with the code. As long as there is no guarantee that this will not make things worse, I don't see how you could support it unless you do not actually have a full grasp of the implications of such a project. —CodeCat 23:24, 26 April 2013 (UTC)

"This will, at best, become something like #Module:links which eventually went nowhere" oh come on Lua is really, really new, it's way too early to say 'eventually went nowhere'. Mglovesfun (talk) 23:42, 26 April 2013 (UTC)

I did a quick search for names of languages indigenous to the British Isles to give a very rough idea of the complexity involved:

• Irish, Erse, Irish Gaelic, Hibernian Gaelic, Gaeilge, Gaelige, Gaedhlag, Gaedhilge, Gaedhilic, Gaeilic, Gaeilig, Gaelic
• Manx, Manks, Manx Gaelic, Gaelg, Gailck
• Scots Gaelic, Scotch Gaelic, Scots-Gaelic, Scotch-Gaelic, Caledonian Gaelic, Erse, Gàidhlig, Gaelic
• Welsh, Welch, Cambrian, Cambric, Cymric, Cymraeg
• Cornish, Kernowek, Kernewek
• Old English, Anglo-Saxon, Anglo Saxon, Anglosaxon, Englisc
• Scots, Scotch, Inglis

True, more than half of these are obscure, and unlikely to be used here- though there are enough works with odd or old usage in places like Google Books that it's hard to be categorical. It's also true there are probably other names I missed, and variants in the Celtic languages due to consonant mutation.

What does the code do when someone puts "Gaelic", or "Scottish", or uses some misspelling that could be interpreted as more than one of the names for the Goidelic language- which all look very similar. There are several other cases where the same name is used for more than one language. It's true that template code has problems with people using se for sv, lt for lv or la, and so on- but at least, template code looks tricky, so people are more likely to look up the correct code. The new format looks like you can put just any old thing and the system will figure it out: in effect, it appears as if it's offering to do the nitpicky part for you. In reality, though, it will probably have its own set of constraints. It kind of reminds me of w:COBOL, and all the talk of how it was going to make coding just like writing English, and make it possible for computer-illiterates to understand it.

All of this can be dealt with, but it will take lots of work to educate both the system and the editors. Even if we keep both old and new going side-by-side to space out the conversion work, there's still going to be cleanup categories with the stuff the module hasn't figured out yet, and someone's going to have to go through them. It would have to be a pretty big improvement to justify the extra work. Chuck Entz (talk) 01:50, 27 April 2013 (UTC)

The part I think you don't get is that this is already a problem, and we already have a solution, just one that isn't utilised enough. Create Template:langrev/Welch and type cy into it (for example), and you will have found out how to solve this. Conrad's tool already relies on this infrastructure (which btw should likely be Luacised, but I have no idea how to do it), and I assume Z's would as well. —Μετάknowledge^{discuss/deeds} 05:34, 27 April 2013 (UTC)

My opinion is that it's not a terrible idea, but Conrad's translation adder already has it beat in terms of editor friendliness. Because of this, it seems to me like we would be doing a lot of work for no gain. Also, correct me if I'm wrong, as Lua is still very new to me and I don't fully understand it, but wouldn't Lua have to essentially recompile the whole thing every time someone adds a translation? Conrad's approach has the advantage of once and done, that is, the computation is done once and then hard-coded into the entry, and does not have to figured out again. -Atelaes λάλει ἐμοί 23:56, 26 April 2013 (UTC)

Every page is reprocessed from scratch whenever it's viewed and the cache is "old". Editing and saving a page forces a refresh, but it's also refreshed after a short time (maybe less than a day but I don't know for sure). —CodeCat 00:00, 27 April 2013 (UTC)

I think he was looking at the creation of the template code as sort of a precompiling into a more machine-friendly format which wouldn't have to go through all the trouble of parsing every time. Of course, the template code has its own overhead, so it probably wouldn't make that much of a difference. Chuck Entz (talk) 01:01, 27 April 2013 (UTC)

For the record, I oppose this proposal. The easiest way for humans to add translations is via Conrad's translation adding tool. The tool requires the editor to enter the language code, but that is a thing easy to pick by an editor in a single language, and the tool can be adjusted to help the user find the langauge code based on the language name. Furthermore, the current markup is unambiguous and well structured. A human can grasp it just from looking at examples of using the {{t}} template. The markup is machine-friendly for all the existing and future reusers of Wiktionary data. Going from a clear and unambiguous template markup to some sort of arbitrary syntax that does not make it clear what is going on is making things worse, IMHO. --Dan Polansky (talk) 09:09, 27 April 2013 (UTC)

I tested something similar on fr.wikt : compare fr:Utilisateur:Pamputt/eau and fr:Utilisateur:Darkdadaah/eau (~3000 translations). The second page is much faster than the first one to generate. Granted, the second one is simplified (and it uses parameters, so less parsing is needed), but there is still a big difference. This is worth considering for template-heavy pages. Dakdada (talk) 16:26, 27 April 2013 (UTC)

This is a very exciting possibility: using Lua to extend wikitext for our very specific requirements.

I think this method has much better potential than the translation adder – that is excellent for drive-by transliteration, but a dead end for real editing.

Since the total template code is reduced, why not make it clearer with the full word?:

{{translation|furniture

I wonder if it would be helpful if the template tags had some kind of indication that the contents supports extended wikitext, especially if we use this method for other applications. Maybe a standardized naming scheme:

{{translation-EXTCODE|furniture|

Or a standard comment:

{{trans-|furniture|<!-- See [[Help:Translation]] for extended wikitext -->

 —Michael Z. 2013-05-31 15:54 z

Help test the new account creation and login

Hi all,

After many weeks of testing, We (the editor engagement experiments team) are is getting close to enabling redesigns of the account creation and login pages. (There's more background about how we got here and why ‎our blog post.)

Right now are trying to identify any final bugs before we enable new defaults. This is where we really need your help: for now, we don't want to disrupt these critical functions if there are outstanding bugs or mistranslated interface messages. So for about a week, the new designs are opt-in only for testing purposes, and it would be wonderful if you could give them a try. Here's how:

• Go to account creation and add &useNew=1 to the URL, or just use this link
• Go to login and add &useNew=1 to the URL, or just use this link

If you have questions about how to test this or why something might be the way it is, I'd definitely check out our step-by-step testing guide and the general documentation.

Many thanks, Steven (WMF) (talk) 19:48, 26 April 2013 (UTC)

Wiktionary editors! This is a quick heads up that this is being enabled today. Steven (WMF) (talk)

I suspect that this is out of your scope, but <meta name="ResourceLoaderDynamicStyles" content="" /> breaks HTML5 validation. —Michael Z. 2013-05-31 15:30 z

Template:ga-proper noun

Why did this edit result in codespill? I still can't see what stupid little thing I did wrong. —Μετάknowledge^{discuss/deeds} 23:30, 27 April 2013 (UTC)

The second #invoke is missing its closing brackets. —CodeCat 23:35, 27 April 2013 (UTC)

True, but when you preview it on a page (e.g. Gaeilge) it still produces headword-line codespill even after I add the forgotten curly brackets. —Μετάknowledge^{discuss/deeds} 23:39, 27 April 2013 (UTC)

Do you have a text editing program? Most higher-end editors (like Notepad++ for Windows or just about anything for Linux) will highlight matching brackets. You can use that feature to find which brackets are missing their counterpart as well. I did that and found the problem right away. —CodeCat 23:48, 27 April 2013 (UTC)

OK, will do next time. I usually don't think to use it for wiki markup. Thank you! —Μετάknowledge^{discuss/deeds} 00:30, 28 April 2013 (UTC)

Bot request for Ancient Greek edits

I need to make a series of minor edits to a number of Ancient Greek entries (somewhere between 100 and 250 of them). I would be quite grateful if someone who has a general purpose bot and some time could help me avoid a large number of very tedious edits. All the entries listed here need to have the 7th parameter of {{grc-conj-aorist-1}} removed, such that the eight parameter becomes the seventh, the ninth becomes the eighth, and so on. As close to concurrently as possible, {{grc-conj-aorist-1}} needs to be changed. If someone can do this while I'm online, I'd be quite happy to edit the template while the entry edits are taking place. Otherwise, I could do it beforehand, and then undo it, so that a simple further undo will make it right. Thanks very much. -Atelaes λάλει ἐμοί 22:46, 28 April 2013 (UTC)

Sure, I'll do it. Barring any problems, it should be done within the hour. —Ruakh_TALK 00:25, 29 April 2013 (UTC)

I've made the changes to the template, and sampled some of your bot's changes, all of which look correct. Thank you so much for your help with this! -Atelaes λάλει ἐμοί 01:09, 29 April 2013 (UTC)

 Done. But for future reference — this turned out to be a really terrible way to do this. I ended up having to make a large number of error-prone manual edits. The problem is that the only safe way to run this sort of bot is to make successive conservative passes — you don't want to risk breaking things that don't meet your initial assumptions, so what you do is, you write the bot to validate its assumptions, and only make an edit if its assumptions are satisfied. (For example, in my initial pass I wasn't aware that there were instances of {{grc-conj-aorist-1|7=...|8=...|9=...|...}}, where all the numbers would need to be fixed.) You then examine cases that the bot skipped due to failed validations, and you increase the scope of cases it supports, and you run it again. Except that in this case, there was no straightforward way to distinguish between a template that had already been edited, and one that hadn't, so I had to do a lot of manual bookkeeping, which is naturally error-prone. And the cases where the template occurred multiple times on a page — it's just good luck that I happened to notice, before running the bot, that this was even a possibility. I didn't bother trying to run the bot on those, it would never have worked out right. But manual edits were error-prone, and it's quite likely that I missed a few instances. More generally — chances are very good that there are a few entries that are now broken, and there is simply no way to find them. (If this bothers you, feel free to go through the relevant edits of Ruakh (talk • contribs) and Rukhabot (talk • contribs) and click "rollback" on all of them, and we can try this again, with a more robust migration strategy.) —Ruakh_TALK 02:06, 29 April 2013 (UTC)

No, that's ok. I'm sure there were plenty of mistakes to begin with. Ancient Greek verb conjugation is hideously complex, and while I try very hard to get them all right, I know that I don't. Fortunately, I'm working on something to validate all of the forms, which will find any relevant errors. It's difficult to say exactly how long it'll take me with my phrenetic, off and on approach to Wiktionary, but I think it should happen eventually. Thanks again and sorry that it ended up requiring a lot of manual work. -Atelaes λάλει ἐμοί 02:16, 29 April 2013 (UTC)

Template:af-personal pronouns

Stupid question, but how do I make the cells for u and dit take up two rows in height, so they don't have to be repeated? —Μετάknowledge^{discuss/deeds} 04:50, 29 April 2013 (UTC)

 Done. I also increased the collapsible box’s width, so it doesn’t require scrolling (feel free to revert). Also, consider using {{l-self}}. — Ungoliant ^(Falai) 10:29, 29 April 2013 (UTC)

Ah, width-fixing. That's what I forgot. Thank you! —Μετάknowledge^{discuss/deeds} 01:30, 30 April 2013 (UTC)

Main page spacing oddities

On the main page (using Firefox 18.0.2 on OSX; see screenshot to the right):

• The vertical space above "Behind the scenes" doesn't match the vertical space above the WOTD and FWOTD headers.
• There's too little horizontal space to the left of "Community Portal" and "Discussion rooms".
• There's more space between "Community Portal" (respectively "Discussion rooms") and the line beneath it than between Community Portal's description and "Discussion rooms", which visually associates things with each other incorrectly.

Does anyone know where/how these can be fixed?​—msh210℠ (talk) 17:46, 30 April 2013 (UTC)

These are caused by the border-collapse:collapse; CSS in the table. --Yair rand (talk) 18:29, 30 April 2013 (UTC)

Pages appearing empty

A few times now I've gone to an entry only to find the entire page empty. The page header would display, as well as the categories, but no actual content. The page source does contain everything, so this seems like a Javascript issue that is hiding everything. —CodeCat 21:58, 30 April 2013 (UTC)

This has happened to me too recently. Reloading the page has always restored the content. —Angr 10:24, 1 May 2013 (UTC)

Yes, reloading does bring it back. I've noticed it also happens on non-content pages like history pages. —CodeCat 15:51, 1 May 2013 (UTC)

It doesn't in Opera. When you reload the contents only appears for a split second, then it's back to headword+categories only. You have to go to the editing window to see what's there. --Thrissel (talk) 11:42, 5 May 2013 (UTC)

Has it ever happened outside the main namespace? --Yair rand (talk) 19:25, 1 May 2013 (UTC)

I haven't noticed it outside the main namespace (including page histories) yet; I'll keep an eye out for that. —Angr 19:36, 1 May 2013 (UTC)

bugzilla:47457 came to my mind (though that's about User pages on Commons), but unfortunately the comment so far is not yet very useful because it does not describe the problem well, e.g. mentioning the used browser and its version, and an example page to reproduce. --AKlapper (WMF) (talk) 10:55, 3 May 2013 (UTC)

I've only seen it happen on en.wiktionary though. Dakdada (talk) 13:03, 3 May 2013 (UTC)

I've also noticed on a few occasions that, if I load more than one page at a time and if one of the loaded pages appears empty, there is a high chance that the others will be empty as well. So there may be some connection there. —CodeCat 19:42, 3 May 2013 (UTC)

In the past ten days I've been keeping track of what namespace it happens in, and it has only been in the mainspace, including viewing diffs and previews in mainspace. I haven't seen it happen in any other namespace. —Angr 14:30, 11 May 2013 (UTC)

Happens to me as well. --Dan Polansky (talk) 19:28, 3 May 2013 (UTC)

This is still happening for me and it's quite annoying. Has anyone been able to find out more? —CodeCat 13:43, 11 May 2013 (UTC)

If someone technically adept could give an analysis of precisely how it's hidden, i.e. what item has been given the CSS property of display=none, that would likely help in figuring this out. As with Codecat, this is occasionally still happening to me as well, and it is damned annoying. I will, of course, post my findings the next time I see it, as I didn't think to do such an analysis previously. -Atelaes λάλει ἐμοί 14:04, 11 May 2013 (UTC)

Using the web console of Firefox, I have found that the empty pages contain the following error: "Exception thrown by ext.gadget.TabbedLanguages: newNode is not defined". I have the tabbed languages gadget enabled. I am using Firefox 20.0.1. --Dan Polansky (talk) 14:36, 11 May 2013 (UTC)

Ah ha! I had a feeling it might be tabbed languages. Whoever thought of that idea should be shot in the face. I'll take a look at the code, and see if I can figure out. I suspect Yair will do the same when they see this, as might some of our other JS ninjas. Thanks Dan. -Atelaes λάλει ἐμοί 14:46, 11 May 2013 (UTC)

Apparently Common.js isn't always loading. Or perhaps it just loads after it's supposed to. If the former, this is going to cause huge problems regardless of the TL situation, as parts of the content (translations, quotations, etc.) are only accessible after Common.js runs. Either way, I suppose we can't rely on newNode being available everywhere, so I've copied the whole thing into the tabbed languages script. This should fix the page blanking, but not the other issues. Is anyone experiencing broken expandable tables? --Yair rand (talk) 17:36, 12 May 2013 (UTC)

I haven't experienced any, even while I was experiencing empty pages. —Angr 18:38, 12 May 2013 (UTC)

May 2013

Plural gender in User:Conrad.Irwin/creation.js

Currently, when a word is plural and also has a gender, this script generates things like {{head|xx|yyy|g=f|g2=p}}. In other words, it splits the gender in two, treating plural as a gender of its own. This has always been the normal behaviour and normal practice, but now there are also dedicated templates for this, {{f-p}} and so on. I created them in anticipation to the adoption of the replacement, Module:gender and number, which indicates genders in this fashion to avoid ambiguity (Specifically: Does f|p mean feminine and/or plural, or feminine plural? If we use f-p to mean the latter, then f|p is unambiguous.). However, although I was able to fix the translation editor, this script still creates entries the "old" way. And I'm not sure what to do to change it, because it still really confuses me every time I try to change anything. Can someone else help out please? —CodeCat 23:12, 3 May 2013 (UTC)

Adding Template:delink to Template:trans-top

Am rather sick of removing links from {{trans-top}}, can we implement delink to it? It's Lua-based so I guess it should be quick, right? Mglovesfun (talk) 20:39, 4 May 2013 (UTC)

 Done. See User:Mglovesfun/sandbox, code seems to work for all link generating templates and not just square brackets. Mglovesfun (talk) 09:42, 7 May 2013 (UTC)

Module:si-translit - Sinhalese (Sinhala) transliterator

I've made a simple Sinhalese (Sinhala) transliterator. It does a very simple conversion but not too accurate. E.g. transliteration of සිංහල (siṁhala): {{#invoke:si-translit|tr|සිංහල}}: (currently produces "si ̃hl")

It ignores the inherent vowel "a", which is attached to every consonant (like Hindi and other abugida Indic languages). I have asked User:ZxxZxxZ, who has kindly fixed the module for Hindi Module:hi-translit (it still has some flaws, it uses too many "a"'s) but he is unavailable. User:CodeCat is also busy at the moment.

The transliteration rule is simpler in Sinhalese: consonants are transliterated as they are in the table but add an "a" if they are not followed by a diacritic or the the inherent vowel "a" is "killed" by "hal kirīma". So final consonants (unlike e.g. Hindi) still have an "a".

Could someone with a knowledge of Lua fix the module, so that all consonants have an "a" when not followed by a diacritic or "hal kirīma", please? You don't need to understand the Sinhalese script. Diacritics are a bit hard to work with, though. I used SC Unipad (free download) to work with diacritics - it breaks any string into components.

It's not urgent but would be great if someone could make it work, hopefully in a way so that the logic could be reused for other abugida scripts. Even Google Translate can't handle Sinhalese. A minor issue is anusvara, which marks nasalisation, which works similar to Hindi, see Wiktionary:Hindi_transliteration#Nasalisation. I used ̃ as a temporary solution. --Anatoli ^{(обсудить}/^вклад) 06:24, 7 May 2013 (UTC)

Merging existing Wiktionary with imported entries

An existing dictionary is being made freely available, and now we need to import its entries into Wiktionary. But how? An example of an entry in XML format is shown at sv:Wiktionary:Teknikvinden#En tillgänglig ordlista i XML-format. It is easy enough to convert that XML to wiki markup. If there is no article, it can just be created. But when Wiktionary already has an article, the result needs to be merged with the existing Wiktionary entry. Are there any good tools or best practices for that? --LA2 (talk) 11:59, 8 May 2013 (UTC)

Probably bots. — Ungoliant ^(Falai) 14:55, 8 May 2013 (UTC)

Are you proposing adding these to the English wiktionary? I can take a look at it. DTLHS (talk) 02:10, 13 May 2013 (UTC)

In this case, all definitions are given in Swedish, so an import to Swedish Wiktionary is the primary goal. What I'm looking for is experience of merging such databases into Wiktionary. It might be easy to translate all definitions to English, for import here, and then we'd have the problem of merging the resulting list into English Wiktionary. But if nobody has ever done such a thing before, I'll have to develop my own methods from scratch. --LA2 (talk) 20:56, 14 May 2013 (UTC)

template:etyl black links

Why does {{etyl|kld|-}} generate Gamilaraay, a black link, instead of a link to w:Gamilaraay language? It certainly is not a well-known language. DCDuring TALK 20:31, 8 May 2013 (UTC)

A "black link"? You mean just a word written in black with no link at all? Because a while back the decision was made never to link language names regardless of how well known the language is deemed to be. —Angr 21:33, 8 May 2013 (UTC)

I'm actually wondering whether we shouldn't link the language all the time. I have occasionally come across etymologies that feature a language I haven't heard of, and a link to its definition would have been convenient. —CodeCat 21:46, 8 May 2013 (UTC)

I stole a line of code from Ruakh (I think from User:Ruakh/common.css) to always make them linked. I'd happily have that code work for everyone. Mglovesfun (talk) 13:57, 9 May 2013 (UTC)

I don't think CSS can make links out of nowhere, though. It must have been a JavaScript, but that doesn't seem like a proper solution to apply to the whole wiki. —CodeCat 14:11, 9 May 2013 (UTC)

It's in Wiktionary:Per-browser preferences, and yes, it depends on JavaScript. I've previously raised the possibility of turning it on for everyone (which wouldn't depend on JavaScript), and no one objected, but then I never actually got around to making the change. (Mea culpa.) If you are inclined to do so, please do! —Ruakh_TALK 05:19, 13 May 2013 (UTC)

it seems there is a bug

I am not a programmer, so I do not know if it is a bug. In thermos, the translation section is strange. When I entered a Uyghur word, instead of the correct چايدان (ug) (chaydan), it shows چايدان (ug) (chaydan){{#switch:ug|ru= ({Turkish --Hahahaha哈 (talk) 14:57, 10 May 2013 (UTC)

I suspect it was this edit to {{t}} that has caused the trouble. —Angr 15:09, 10 May 2013 (UTC)

I seem to have fixed it, but would appreciate a double-check from people who are better at templates than I am. —Angr 15:15, 10 May 2013 (UTC)

User:Hippietrail's recent additions to Template:l

I'm not really sure what motivated this sudden addition of even more parameters to this template. Their explanation was "it's to solve the long-standing problem where you can't associate several orthogonal chinese/japanese/korean variants to the same transliteration in a single entry" but I never considered that to be a problem. Has it been a problem for anyone else? And in any case, I really don't agree with their solution - two more parameters. Especially with Lua, we don't need these kinds of solutions at all, we can do better. —CodeCat 01:20, 13 May 2013 (UTC)

All additions are sudden. I've been annoyed by this missing functionality for a decade. Are you suggesting non-sudden additions such as submitting single character changes one by one? Or is "sudden" some kind of rhetoric or weasel word?

When you say you never considered the ugly workarounds for using {{l}} with Chinese, Japanese, and Korean a problem, does this mean that you have been using {{l}} with these languages at all?

In my talk page you used the terminology "does more harm than good" but you haven't touched on that topic here.

At last some sensible talk. I'm very much in favour of Lua solutions but I haven't started Lua hacking yet. As a programmer, I consider a lot of template stuff to be ugly hacks that could be elegantly solved in Lua, though I am a bit worried about people that want to parse our dump files to use our data in their own projects.

Is there a general consensus to halt all development on templates and move to Lua? I'd love to hear about it.

By the way I'm very keen to have a much less "turn taking" chat about all this stuff in the IRC cannel, #wiktionary on irc.freenode.net — hippietrail (talk) 01:31, 13 May 2013 (UTC)

It’s not sudden when you discuss the change with the community. — Ungoliant ^(Falai) 01:37, 13 May 2013 (UTC)

What I mean is that nobody else has ever had this problem, or at least not that I am aware. The current solution is to use two instances of the template; has that given any problems at all? What I meant by "more harm than good" is that it's better to discuss possible approaches to the problem rather than just picking one that might in the end not be very workable at all. The last thing {{l}} needs is more parameters; it and many other templates are already rather complex because they seem to be designed to cater to every possible situation. {{l}} isn't even the worst case, {{term}} is far worse with its lit= and pos= parameters. There is a general tendency to be like "this template doesn't do quite what I need... let's add another parameter!", but without much regard for whether it makes sense. Short term goals give long term problems. —CodeCat 01:37, 13 May 2013 (UTC)

I consider using two instances of the template to be a problem. I'm sure I'm not the only one that's been annoyed by that though I'm not sure why you might expect to be aware of it. Two instances of the template mean neither the wikitext, the HTML, nor the DOM associate the text as a cohesive unit for anybody trying to use our data. For human users there is confusion over whether to add the transliteration or other parameters to each instance, just the first, just the last, whether to put one inside parentheses, etc. At least one alternative template has been created to work around this for the Korean language, {{ko-inline}}. I'm not sure if you were or should've been aware of that template. I'm personally not sure whether there are other such workaround templates for Chinese, Japanese, or any other language. I wouldn't be surprised and I wouldn't be surprised if they all work differently and render differently and that the same people rarely use more than one of them. A consistent solution would be best.

I also dislike that we have these complex templates. In the early days I argues against using more of them but I lost the argument and became one of the ones implementing templates, way back when, though I haven't hacked them for some time now. Where they have been put into long-standing use though it's better to have capable templates.

I think you have to justify your stance that more parameters is inherently bad. Why is having more "the last thing it needs"? I actually don't find this template very complex, it's mostly inline where many other templates suffer from deep nesting.

I've already mentioned several times that I've been annoyed by this missing functionality for a decade so I find your use of the terminology "short term goals" to be quite ingenuous and you haven't elucidated what these "long term problems" are.

So let me put it to you: are you aiming to simplify templates by removing parameters that have "too many"? or are you advocating halting any further development of templates? Or do you have a Lua proposal to replace this template?

One more important question: Do you believe templates are to give editors less typing, or to bring uniformity to Wiktionary, or both? I personally feel that standardization is best for templates and I've seen them move that way. Parameters with the same name and same function have spread though there are still exceptions for instance.

irc://irc.freenode.net/wiktionary / irc://#wiktionary@irc.freenode.net — hippietrail (talk) 02:01, 13 May 2013 (UTC)

• @Hippitrail, might I suggest that you use / tweak {{ja-l}}, if your concerns are specific to Japanese? This offloads much of the problem from the much-used (and thus somewhat more complicated-to-change) {{l}}.

If you're looking for something that could be used for Chinese and / or Korean as well, perhaps use the code from {{ja-l}} to create {{cmn-l}} and {{ko-l}}? Cheers, -- Eiríkr Útlendi │ Tala við mig 03:31, 13 May 2013 (UTC)

As I mentioned there is already {{ko-inline}}. Are you really saying that having one template per language with unrelated names and dissimilar usage is a good thing? They certainly impair discoverability. Would you advocate that general purpose templates generally should be avoided in favour of developing separate templates for each language that users must learn? Surely uniform template names, uniform template parameters, uniform template use across languages is going to lower the barrier to entry. Does anybody know if there is a Chinese-specific equivalent to {{l}}, {{ko-inline}}, and {{ja-l}} - or for any other language for that matter? If disparate template names for individual attempts at solving the same problem is a good thing, how do we find those templates for the language we are not familiar with? — hippietrail (talk) 06:44, 13 May 2013 (UTC)

There seems to be a category for templates such as these, Category:Internal link templates - I've gone ahead and added the Korean and Japanese templates to it, I encourage anybody else to add such templates to the category that they know of or discover. — hippietrail (talk) 06:52, 13 May 2013 (UTC)

For consistency with all the other language-specific {{l}} templates, shouldn't {{ko-inline}} and {{ja-l}} be renamed {{l/ko}} and {{l/ja}}, or at least have redirect from those titles? Actually, upon preview I see we already have {{l/ja/Jpan}}; do we really need both that and {{ja-l}}? —Angr 12:15, 13 May 2013 (UTC)

The {{l/ja}} template should be a subset of {{l}}. Specifically, it should be possible to replace {{l/ja}} with {{l}} at any time without breaking anything. —CodeCat 14:17, 13 May 2013 (UTC)

• @Hippietrail, the issues you're dealing with (as best I understand them) involve special considerations required for CJK languages, and not for any others. Rather that your changes to {{l}} in an attempt to code in these considerations have apparently caused some kind of problem, it might make sense to instead have some other related template that builds in these considerations. If you can code something that plays well for all CJK languages, then great; if C or J or K has some specific coding need that makes things difficult, then create something specific for that one. I'm not a big fan of one-size-fits-all, because invariably it doesn't.

{{l}} is complex, and used far and wide, so any changes made to that must not adversely affect those entries using {{l}}. Moreover, perusing the source for {{l}}, it looks like this template would be significantly more processor-intensive than {{ja-l}}. There are various reasons that could warrant creating a different template to handle different specific needs.

Whether that template is called {{ja-l}} or {{l/ja}} or {{cjk-inline}} or what have you, is a different matter entirely, and not one I have any strong opinions about. (Though CodeCat's point about {{l/ja}} certainly makes sense.) Cheers, -- Eiríkr Útlendi │ Tala við mig 20:56, 13 May 2013 (UTC)

Beta Code, Anyone?

I've accumulated a text file with all the character sequences necessary to generate all possible lemma forms used by Perseus for their Liddell, Scott & Jones Greek Lexicon. Eventually I plan to try my hand at Lua programming with a module to replace most of the innards of the {{R:LSJ}} with code that translates the headword of a Greek entry directly to the format Perseus expects, without requiring editors type the sequence in by hand.

In the meanwhile, though, it occurred to me that the encoding they use, w:Beta Code, would make a very handy alternative input method. Beta code was designed to represent all the characters in the Greek polytonic script- including accents, breathings, iota-subscripts, macrons, breves, and other diacritics, in any combination- using only sequences of characters found on every standard keyboard. It's used by the w:Thesaurus Linguae Graecae project, so you know it has to be pretty complete.

For example, the Ancient Greek noun εἰδωλολάτρης (eidōlolátrēs, “idol-worshipper”) can be entered using "ei)dwlola/trhs", and Ἑβραῖος (hebraîos) using "*(ebrai=os" Once you learn the conventions, it's relatively easy to type in any Greek word without using menus, palettes, etc. Many of the characters used overlap with wiki syntax, but it shouldn't be hard to keep the Beta Code input from contaminating the wikitext. There are also Beta Code versions for other scripts such as Hebrew, but I haven't used them and can't vouch for their usefulness.

I don't have the necessary knowledge of Javascript or of our user interface to create it myself, but I thought I would mention it in case anyone who does might feel so inclined. There's a pretty comprehensive manual linked to from the WP page which should have all the information you need. Thanks! Chuck Entz (talk) 02:15, 13 May 2013 (UTC)

You might want to mention this to the developers of the jQuery IME (mw:Milkshake). --Yair rand (talk) 03:03, 13 May 2013 (UTC)

For starters, I applaud this effort. It would be nice to not have to figure out the code. For what it's worth, if I were to take on this project, I would use javascript, and have it pull up the pagetitle, convert it into beta code, find the edit window, find the empty template, and insert the code into it. This is probably because I'm comfortable with JS, and have no experience with Lua. In any case, I support whatever approach works, and am happy to provide any assistance that I can. -Atelaes λάλει ἐμοί 01:02, 15 May 2013 (UTC)

Transwiki from Wikipedia

Hi there. Way back in October I nominated w:A leopard doesn't change its spots article for deletion, and the result of the discussion was transwiki to Wiktionary. The problem is that the transwiki tag (This page will be copied to Wiktionary using the automated transwiki process) has been on the article ever since, and no transwiki has taken place. I was told at the Village Pump that it is in fact not an automated process, and that it needs to be imported by admins over here. Although there is already a page for it over here, what happens next? Richard BB (talk) 08:50, 14 May 2013 (UTC)

I'd say replace it with w:Template:Wiktionary redirect. Since Wiktionary already has a page for it, we don't need the transwiki. I really wish people at Wikipedia would check whether something is present at Wiktionary before knee-jerk-reacting "Transwiki to Wiktionary" at AFD discussions. Wiktionary isn't Wikipedia's trashcan. —Angr 12:29, 14 May 2013 (UTC)

Of course Wiktionary isn't bound by the result of a Wikipedia AFD. Given the poor quality of the page in question and that we already have it under a more correct title, either delete it or soft redirect. Mglovesfun (talk) 08:30, 15 May 2013 (UTC)

Any MediaWiki hackers here?

I'm trying to help a dictionary project find some technical help in adapting MediaWiki for their use. They specifically asked if I knew anyone with experience on Wiktionary. I know that User:Conrad.Irwin has some knowledge, but instead of spamming him (and a few other likely looking candidates here), I thought I would just ask: Is anyone interested in a small gig like this? (Appologies if this is inappropriate for here.) -- ☠MarkAHershberger☢(talk)☣ 00:33, 15 May 2013 (UTC)

Lua - help required

I've programmed as a sideline for 35 years (Fortran, BASIC, C (not C++), Turbo Pascal) - but I'll still have the odd syntax problem with Lua! Please can someone tell me why function p.test1 in Module:User:Saltmarsh doesn't work. thanks — Saltmarsh^{απάντηση} 05:46, 15 May 2013 (UTC)

What about it doesn't work exactly? —CodeCat 10:27, 15 May 2013 (UTC)

I received a "script error" message. — Saltmarsh^{απάντηση} 15:58, 15 May 2013 (UTC)

el-translit’s tr function receives a frame as a parameter, not a string. — Ungoliant ^(Falai) 11:46, 15 May 2013 (UTC)

Thanks - onwards and upwards! — Saltmarsh^{απάντηση} 15:58, 15 May 2013 (UTC)

Special redirects

I created a couple of special redirects that were deleted. It was suggested on my talkpage that I come here to see what folks thought about their utility. You can read about the issue on my talkpage, but essentially, the idea is to track usage of links from Wikipedia to Wiktionary. Currently, most links from WP to WT are via template, and there seems to be no direct way to track number of clicks on that kind of interwiki template. My solution was to create special redirects on WT: i.e., have "brand new (redirect)" redirect to "brand new", and then create a link from the Wikipedia page to the special redirect. In a month, we could look at the traffic stats for "brand new (redirect)", compare it to the stats for "brand new", and know how many people looked up "brand new" via Wikipedia versus other sources. The special redirects are designed to be few in number, temporary in nature (no more than a couple of months just to get the needed data), and essentially invisible to the reader. I know that redirects are highly unfavored at WT, but I thought this might be a worthwhile use of them. Thoughts? Dohn joe (talk) 17:58, 15 May 2013 (UTC)

Does MediaWiki not have web traffic statistics with referrer info? —Michael Z. 2013-05-15 18:46 z

Good question. I've never dealt directly with MediaWiki. How would I go about doing so? Dohn joe (talk) 19:05, 15 May 2013 (UTC)

I would certainly like to know about the results of such research for a goodly sample of entries. DCDuring TALK 19:12, 15 May 2013 (UTC)

Here are some links, but I can’t figure out where the logs are:

• http://stats.wikimedia.org/
• mw:Analytics/Wikistats
• mw:Analytics/Wikistats/TrafficReports

 —Michael Z. 2013-05-15 20:16 z

Even if the logs were available, they don't track every hit. Only about one per 1000 hits are logged. -- 24.229.66.193 23:31, 15 May 2013 (UTC)

I see no harm in creating a limited number (which could be as high as a hundred, IMO) of such special redirects. I also see little benefit, but since others do see benefit, I say: sure, go ahead. - -sche (discuss) 03:15, 16 May 2013 (UTC)

Merge {{trans-top}}, {{trans-mid}}, {{trans-bottom}}

With Lua it seems like it should be possible to merge these templates into a single template: {{temp|trans-table|(translations go here)}}. This would allow us to automatically do various kinds of validation (language matching, nesting, etc) and cleanup, and it would eliminate the need to manually balance the columns. Thoughts? DTLHS (talk) 20:07, 15 May 2013 (UTC)

If this is being revised, why not use CSS column-width, and dispense with all of the unnecessary tables and brute-force column balancing? —Michael Z. 2013-05-15 20:19 z

That seems like the right tool for the job. DCDuring TALK 20:08, 16 May 2013 (UTC)

See {{trans-table}}. This still requires (a) the correct styles / classes (common.css) to be added, (b) Conrad Irwin's auto translation script to be modified, and (c) bot conversion if we want to switch to this. Alternatively we could just apply the new style to {{trans-top}} and blank {{trans-mid}}, which would require no bot edits. The advantage of having everything in a single template are the eventual Lua parsing capabilities, as described above. DTLHS (talk) 02:02, 17 May 2013 (UTC)

You can see an example at User:DTLHS/sandbox (with User:DTLHS/common.css). Unfortunately I don't know how you would prevent nested translations from being split across columns, which seems like a deal breaker. DTLHS (talk) 21:02, 18 May 2013 (UTC)

Cannot get this to work- the column-break-inside property isn't supported by most browsers. Using display: table; fixes the column breaks but makes it impossible to use bullets. Anyone have any other work arounds? DTLHS (talk) 23:44, 18 May 2013 (UTC)

Is the problem with translations like Mandarin and Hungarian in your example, where there is a dl inside a ul? We could use proper markup instead of this nonsense.—Michael Z. 2013-05-19 21:30 z

Thanks. What would be the proper markup? This is what is used in all entries to nest translations, so it would take some work to fix. DTLHS (talk) 21:50, 19 May 2013 (UTC)

Well, just an asterisk for nested UL is probably better than the fake DL, and more consistent for editors. Presentation could remain the same with .translationcolumns li li { list-style-type: none; }

Better markup might be a real DL, which could also be styled to look exactly like the current version. I suspect editors may be uncomfortable with the unconventionally correct use of wikitext to create markup, though:

; Armenian
 : նախ (hy) (nax)
 : սկզբում (hy) (skzbum) 
; Chinese
 :; Mandarin
  :;: 起初 (cmn) (qǐchū)
; Czech
 : zpočátku (cs)
 : nejprve (cs)

 —Michael Z. 2013-05-19 22:04 z

It works for me in Safari/Mac and Chrome/Mac. It looks like adding page-break-inside: avoid; makes it work right in Firefox 20.0. I guess the problem is in MSIE <10[2] and Mozilla<20.[3] Dunno about Opera.

The way it breaks with your CSS is not a showstopper – the content is still perfectly understandable in cases where the break appears in the wrong place. So I don’t have a problem with using this, since it should be able to work in all current browsers. —Michael Z. 2013-05-19 21:30 z

Strange edit..?

I'm confused... what did I change in this edit? diff —CodeCat 18:08, 16 May 2013 (UTC)

Investegating in Python, it seems that you removed the symbol u'\u200e', which supposedly is the left-to-right mark, which I also identified another one of. --Njardarlogar (talk) 18:18, 16 May 2013 (UTC)

It seems that SemberBlottoBot has created that entry. I wonder why it is inserting such invisible characters... —CodeCat 18:22, 16 May 2013 (UTC)

I can't see the change that the edit made. Where exactly is the strange character (between what other characters)? SemperBlotto (talk) 07:14, 17 May 2013 (UTC)

Use keyboard cursor to find it. They are after "e" in "piquenique". --Z 07:32, 17 May 2013 (UTC)

How strange. Nothing obvious in the code, and it doesn't seem to be happening now. See amabilidades for a similar entry just created. SemperBlotto (talk) 07:46, 17 May 2013 (UTC)

How is the input handled? I'd guess that the character entered that way. No, it doesn't seem to be happening any longer; I've checked a lot of random entries. --Njardarlogar (talk) 14:12, 17 May 2013 (UTC)

I've compiled a list of 2004 (!) entries with this character in the text. Easy enough to fix but we should really figure out where these are coming from. Is there any circumstance in which this is valid? DTLHS (talk) 21:10, 20 May 2013 (UTC)

As per the section somewhere below this one, Prosfilaes introduced a symbol with this new page, using User:Yair rand/newentrywiz.js. Checking the source code of the active version at that point in time reveals no such symbol, and I don't find it in quinceañera, either. --Njardarlogar (talk) 17:41, 21 May 2013 (UTC)

Strange. We need Sherlock Holmes to sort it out for us. --Z 18:31, 21 May 2013 (UTC)

I don't think there is, there are preferable, higher-level ways to deal with text direction, in HTML. One should not put those unicode characters in page's code, unless when we need to change the direction in edit mode as well (using the characters is the only way to do this, in this case). --Z 18:25, 21 May 2013 (UTC)

Agreed, but the LRM shouldn't always be removed: often it should be converted to ‎ until our templates actually use the "higher-level ways". (One example is that I insert ‎ between anagrams in a comma-separate anagram list in a RTL language's entry. There are other examples also where the LRM should be included by some means.)​—msh210℠ (talk) 18:24, 22 May 2013 (UTC)

Another strange edit: diff. Any idea what happened? —CodeCat 13:32, 22 May 2013 (UTC)

Apparently the same thing. Before:

character  byte       UTF-32   encoded as     glyph   name
        0          0  000061   61             a      LATIN SMALL LETTER A
        1          1  000072   72             r      LATIN SMALL LETTER R
        2          2  00006B   6B             k      LATIN SMALL LETTER K
        3          3  00200E   E2 80 8E               LEFT-TO-RIGHT MARK
        4          6  00007C   7C             |      VERTICAL LINE
        5          7  00006C   6C             l      LATIN SMALL LETTER L
        6          8  000061   61             a      LATIN SMALL LETTER A
        7          9  00006E   6E             n      LATIN SMALL LETTER N
        8         10  000067   67             g      LATIN SMALL LETTER G
        9         11  00003D   3D             =      EQUALS SIGN
       10         12  00200E   E2 80 8E               LEFT-TO-RIGHT MARK
       11         15  000065   65             e      LATIN SMALL LETTER E
       12         16  00006E   6E             n      LATIN SMALL LETTER N
       13         17  00007D   7D             }      RIGHT CURLY BRACKET
       14         18  00007D   7D             }      RIGHT CURLY BRACKET
       15         19  000020   20                     SPACE
       16         20  000061   61             a      LATIN SMALL LETTER A
       17         21  00006E   6E             n      LATIN SMALL LETTER N
       18         22  000064   64             d      LATIN SMALL LETTER D

After:

        0          0  000072   72             r      LATIN SMALL LETTER R
        1          1  00006B   6B             k      LATIN SMALL LETTER K
        2          2  00200E   E2 80 8E               LEFT-TO-RIGHT MARK
        3          5  00007C   7C             |      VERTICAL LINE
        4          6  00006C   6C             l      LATIN SMALL LETTER L
        5          7  000061   61             a      LATIN SMALL LETTER A
        6          8  00006E   6E             n      LATIN SMALL LETTER N
        7          9  000067   67             g      LATIN SMALL LETTER G
        8         10  00003D   3D             =      EQUALS SIGN
        9         11  000065   65             e      LATIN SMALL LETTER E
       10         12  00006E   6E             n      LATIN SMALL LETTER N
       11         13  00007D   7D             }      RIGHT CURLY BRACKET
       12         14  00007D   7D             }      RIGHT CURLY BRACKET
       13         15  000020   20                     SPACE
       14         16  000061   61             a      LATIN SMALL LETTER A
       15         17  00006E   6E             n      LATIN SMALL LETTER N
       16         18  000064   64             d      LATIN SMALL LETTER D

(could not find a sensible way to make this take less space.) Keφr 14:23, 22 May 2013 (UTC)

How did you generate that information? —CodeCat 14:25, 22 May 2013 (UTC)

I use uniname. Keφr 14:30, 22 May 2013 (UTC)

An easier way is using a unicode to HTML convertor like this, the character is encoded as &#8206; and &lrm; in HTML. For example {{term|percontation mark‎|lang=‎en}} (from diff) gives {{term|percontation mark‎|lang=‎en}}. --Z 14:40, 22 May 2013 (UTC)

Here's what it looks like in Python, by the way (the first \ufeff stems from UTF file encoding): u'\ufeff====Usage notes====\n* Possible {{l|en|calque|calques}} of {{term||punctus percontativus|lang=en}} include {{term|percontation mark\u200e|lang=\u200een}} and {{term|percontation point|lang=en}}; both are attested in isolated uses (2005, 2010), but neither has gained any currency.' (using a simple .__repr__()) --Njardarlogar (talk) 16:34, 22 May 2013 (UTC)

• The invisible character seems to appear near special characters like | } ] '. Could making a typo result in a keyboard shortcut for this invisible character? E.g. Ctrl-LeftShift / Ctrl-RightShift seem to change the text direction in some programs/browsers/platforms. -- Curious (talk) 21:01, 22 May 2013 (UTC)

  That was my first thought but... There are many shortcuts for LRM, they vary depend on the OS, software, and configuration. (BTW, Ctrl + Left/Right Shift does change text direction of input, but putting LRM/RLM characters is another thing) Including Shift (don't remember if there was L Alt or Ctrl, too) + Backspace, a key near | and }. But this shortcut (as well as many others) works in bidi keyboards, while many of these LRMs are the result of edits of people who speak/write in LTR languages. Moreover, this case was bot's edit (the code must be OK since it works fine in other entries), and in the case Njardarlogar mentioned above, no keyboard was involved. It's weird. --Z 06:51, 23 May 2013 (UTC)

Is there a "standard" way to make new {{xx-noun}} type templates?

Lately I've been interested in a group of less common languages written in the Cyrillic script from the Caucasus and around Mongolia.

I've noticed that some of them have {{xx-noun}} templates but some of them do not.

I'm interested in making the missing templates but since all of the languages seem to have different "source code" I'm wondering if there's a model I should copy. I don't mind even standardizing the existing ones. Do we have a policy on this?

... or are we planning to move more towards Lua? — hippietrail (talk) 06:27, 17 May 2013 (UTC)

Lua is definitely recommended, if you're able to do it. You can look at Module:nl-headword or Module:ca-headword for some examples. —CodeCat 14:27, 17 May 2013 (UTC)

But be sure to add in automatic transliteration. Take a look at Category:Transliteration modules and if none of the languages there have the same transliteration system, make a new one with the same format. —Μετάknowledge^{discuss/deeds} 00:05, 18 May 2013 (UTC)

Thanks. I'll start looking into it in a few hours. — hippietrail (talk) 02:48, 18 May 2013 (UTC)

Not necessarily a standard way as languages vary. I'd consider Template:tyv-noun a very good place to start, changing the language name and codes where necessary, and adding anything that's needed (gender, plural, genitive, etc.). Mglovesfun (talk) 10:48, 18 May 2013 (UTC)

I would at least change the headword line to use <strong class="headword"> and remove the deprecated sg= parameter. —CodeCat 12:21, 18 May 2013 (UTC)

Bot request: stroke order

I have recently been trying to add stroke orders to pages such as 岁. The conclusion I must draw from the number of stroke order-free pages I have come across is that there are a lot of Commons Bw.png stroke order images that are not being used on Wiktionary, whereas they could be.

Since the Commons files all have a standard naming format, would it be possible for someone to create a bot that would do the following for each member of Category:Han_characters?

1. Check whether it had a ==Translingual== header.
2. Check whether it had a Bw.png stroke order file on Commons (the files' names are all made according to a particular pattern; see e.g. 乙 and File:乙-bw.png).
3. If it exists, check whether said Bw.png file is already used on the Wiktionary page (possibly via {{stroke order}}).
4. If the Wiktionary page already uses a Bw.png file, do nothing.
5. If there is no Commons Bw.png file to speak of, do nothing.
6. If there is a file on Commons, it isn't yet being used on Wiktionary, and there isn't a Translingual header, create the header and put {{Stroke order}} underneath it.
7. If there is a file, it isn't yet being used, and there is a Translingual header, check whether the header is already using some other stroke order image (as at 乙).
8. If it is, do nothing.
9. If it isn't, add the Bw.png file to the Translingual section.

Thanks. It Is Me Here ^{t / c} 16:02, 17 May 2013 (UTC)

Any suggestions on how the bot can recognize "whether the header is already using some other stroke order image"?​—msh210℠ (talk) 18:28, 22 May 2013 (UTC)

Maybe the bot could check whether the page's Translingual section contains an image that's a member of commons:Category:Order.gif stroke order images or commons:Category:Red.png stroke order images? It Is Me Here ^{t / c} 21:03, 23 May 2013 (UTC)

How can I find hard links to other projects?

My specific interest is in finding instances of species: and wikispecies: in principal namespace (and secondarily Appendix space) for the purpose of replacing such links with {{taxlink}} so the taxonomic names became candidates for entry. Is there a way to do this from a search screen whenever I need it or does this need to be done by processing the dump? DCDuring TALK 23:46, 19 May 2013 (UTC)

There may be a way to do it from the search screen, but processing the dump periodically is easy enough. I've created Wiktionary:Todo/Direct links to Wikispecies. I note that if I just search the site (not the dump) for "wikispecies" using the normal search screen, I find a lot of entries which say "see wikispecies" without any link at all, which seems pointless... see e.g. Zygaeninae, where the "see wikispecies" is redundant to the {{wikispecies}} box. - -sche (discuss) 20:00, 29 May 2013 (UTC)

I use various searches to try to locate references to taxonomic names in entries and clean other things up as I go, at least when I have the energy for it. Yes, I guess I should clean those "See wikispecies" things up systematically. But the "See also" sections that have those words often should be reheaded as "Hyponyms", ie, species in a genus entry. The See is intended to direct the user to a project that has a good list of species. A really good job would make a determination whether we should have our own Hyponyms listing of species or a link to WP or Wikispecies based on the relative quality and quantity of their species listing. This is a little time-consuming but we only have about 9,000 taxonomic name entries, so it is not too hard to imagine cleaning them all up. It is a great deal harder to find all the uses of taxonomic names in all entries in all languages. So far I've found about 5,000, mostly using ordinary search and "what links here". The only language that has been rather easy is Finnish (tip of the hat to Hekaheka). DCDuring TALK 00:13, 30 May 2013 (UTC)

I have edited [[Zygaeninae]] as best I can, with all the features I sometimes include. Note that I have retained a duplicate link to Wikispecies under Hyponyms. DCDuring TALK 00:32, 30 May 2013 (UTC)

•  Done Thanks. DCDuring TALK 13:27, 30 May 2013 (UTC)

Why doesn't this work?

I'm trying to create a module to return the definitions of a page from the title (Template:defs, Module:defs). Note the output:

{{defs|supporteuses}}:

1. plural of|supporteuse|lang=fr

I assume that {{:{{{1}}}}} isn't getting evaluated for some reason- any way to fix this? DTLHS (talk) 00:16, 20 May 2013 (UTC)

I'm not sure why it's not working, but it's probably not the best way of going about it anyway. Rather than transcluding a page and passing it as an argument, Lua can just retrieve the page content using mw.title. --Yair rand (talk) 00:27, 20 May 2013 (UTC)

Right, that works but unfortunately templates aren't being evaluated (probably some kind of recursion protection). Oh well. DTLHS (talk) 00:43, 20 May 2013 (UTC)

FWIW, the first time I looked at this page, the bit after the colon was supporteuses. Now, it's a red Script error. - -sche (discuss) 00:33, 20 May 2013 (UTC)

HTML in {{cmn-hanzi}}

This template contains <font style="font-size:125%">, which breaks the page’s HTML because it is obsolete, and should be removed or replaced. I don’t know enough about the template to fix it.

Doesn’t the script template {{Hans}} already enlarge the font (via a declaration in MediaWiki:Common.css)? Or if this is supposed to replace the headwords’ usual bold emphasis, then we should replace it with a <strong> element, and style it appropriately in the style sheet:

strong:lang(cmn) { font-weight: normal; font-size:125%; }

 —Michael Z. 2013-05-20 01:52 z

• I just commented out the offending <font> tag pair. If that doesn't break anything, we can remove it entirely. If it does break anything, we should just change the tag text from font to span, no? -- Eiríkr Útlendi │ Tala við mig 17:06, 21 May 2013 (UTC)

Well, if this is, as I suspect, being enlarged as a substitute for the usual headword bolding, then a better way to do it would be to simply make it <strong lang=zh-Hani> and handle the styling in the style sheet with strong:lang(zh) { font-weight: normal; font-size: larger; }. There are other headword templates that should be treated the same. This would allow standardization of the HTML, central control by the style sheet, and overriding in user style sheets. —Michael Z. 2013-05-21 17:42 z

Why aren't we using dfn? strong doesn't make sense to me... we are not emphasising on anything. --Z 18:12, 21 May 2013 (UTC)

Depends on where this style applies. If it applies to the headword line, as Michael suspects, then it is being emphasised, much like Latin-script headwords are emphasised by bolding. (dfn wouldn't make sense applied to the headword line, IMO.) If it applies to definitions, then dfn would seem better... - -sche (discuss) 19:47, 21 May 2013 (UTC)

dfn would be ideal, but we aren’t using it because our combination of templates and their resulting markup doesn’t allow us to meet the requirement that “The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element.”[4] It is not unreasonable that a headword “represents strong importance for its contents.”[5] —Michael Z. 2013-05-22 02:36 z

Script detection module

Would it be possible to write a module that detects script? I wonder if it could just check the first character of a string, and then use Latn as a default for anything like 1 or !. Mglovesfun (talk) 08:30, 20 May 2013 (UTC)

It's already written. It's unused, though. --Z 08:33, 20 May 2013 (UTC)

What exactly would it be needed for? —CodeCat 12:16, 20 May 2013 (UTC)

It is needed for terms in languages which are written in more than one script. --Z 14:37, 20 May 2013 (UTC)

But for such languages, we can do a little better. After all, we already store a list of possible scripts, so a detection function wouldn't need to try all possibilities, only those that are used for that language. For example, a detection script for Serbo-Croatian would only need to try Latin and Cyrillic. —CodeCat 14:39, 20 May 2013 (UTC)

That's what the current code is doing, see lines 50-56. --Z 14:43, 20 May 2013 (UTC)

What does your script do if there are characters in the word that don't belong to any script? Like spaces, punctuation or even combining diacritics? And what if it finds more than one script? —CodeCat 14:45, 20 May 2013 (UTC)

Spaces, punctuation, and Latin 0-9 digits (since they are used in several other scripts as well) are ignored. It detects based on the first characters, i.e. for "abcابپت" it returns "Latn". For anything else returns nil. --Z 14:51, 20 May 2013 (UTC)

I've added a few scripts I felt like adding - Armenian, Bengali, Burmese, Devaganari, Georgian, Greek, Khmer, Lao, Sinhalese, Thai (using SC Unipad word processor). Not sure what it's going to be used for but would like to add CJK script detection, not sure if it's possible. The codes are obviously shared by these scripts. For Korean individual jamo the range is "ᄀ-ᇹ", for hangeul it's U+AC00–U+D7AF. --Anatoli ^{(обсудить}/^вклад) 03:11, 22 May 2013 (UTC)

This could be very helpful for a language like Sanskrit, which is written in more scripts than {{choose}} allows us to specify at {{sa/script}}. —Angr 14:32, 22 May 2013 (UTC)

The /script templates will soon be deleted anyway. Lua doesn't have a limit. —CodeCat 16:40, 22 May 2013 (UTC)

quinceanera

What is wrong with the formatting of this entry? The linked-to word exists here, but is shown in black with no wikilink. SemperBlotto (talk) 15:22, 20 May 2013 (UTC)

Needed lang=en. — Ungoliant ^(Falai) 15:32, 20 May 2013 (UTC)

Weird. I tried that (look at the history) and got a red script error. SemperBlotto (talk) 15:35, 20 May 2013 (UTC)

It wasn't the missing language. It was another one of those invisible characters. —CodeCat 15:36, 20 May 2013 (UTC)

Quotations and Examples

I've recently started adding quotations to Wiktionary that I extract from whatever I happen to be reading when the impulse to contribute strikes. It's an interesting learning experience.

With quotations being displayed to the reader as an option, their use to confirm a meaning and to demonstrate its possibly changing use over time seems to me to have very great potential attraction for readers. Also, quotations can and usually do offer readers a link to the document or article they come from. This is an added attraction, and the overall attraction will increase as quotations accumulate, provided they don't bloat within any single meaning.

In adding quotations, though, I've noticed that the treatment of examples varies widely. Sometimes they are included as part of the meaning, sometimes as following lines of text (usually in italics), and sometimes as brief quotations without or without attribution.

I would suggest that examples be coded in a fashion similar to that of quotations (maybe prefixed by #=), and that their display be made optional in the same fashion that quotations are. One great advantage of this (once the majority of current examples are converted) is that more meanings will be visible at the same time for readers with both examples and quotations hidden. Then a reader can get at examples and/or quotations for an individual meaning of particular interest.

#= doesn't mean anything in MediaWiki markup as #* (currently used for quotes) and #: (currently used for examples) do. —Angr 15:32, 21 May 2013 (UTC)

Automatically expand language section in mobile view

Is it possible to have the Finnish language section automatically expanded in the mobile view? ~ heyzeuss 18:55, 21 May 2013 (UTC)

What do you mean by expand exactly? —CodeCat 18:57, 21 May 2013 (UTC)

In mobile view, all sections of wiki pages are collapsed by default. --Z 19:10, 21 May 2013 (UTC)

Hm, do personal user scripts and styles exist for mobile? I don't think so. --Yair rand (talk) 19:32, 21 May 2013 (UTC)

Lua and JSON

Can we add a JSON module for lua on en.wiktionary? There are a bunch of free modules here but I'm not sure which have compatible licenses. DTLHS (talk) 23:54, 22 May 2013 (UTC)

What would that do exactly? —CodeCat 00:04, 23 May 2013 (UTC)

It would parse JSON strings. I guess it can wait until I have a complete example of what I want to do up. DTLHS (talk) 00:46, 23 May 2013 (UTC)

See bugzilla:45470. No "I want this too!" comments please, but feel free to CC yourself on that bug report. :) --AKlapper (WMF) (talk) 11:29, 30 May 2013 (UTC)

Wiktionary:Todo/needed trans templates

Could someone please update this? Cheers. Mglovesfun (talk) 10:41, 23 May 2013 (UTC)

Done. DTLHS (talk) 20:57, 23 May 2013 (UTC)

Category:Greek entries which need Greek script

I just noticed this category on fshij. I'm guessing it's an unintended side effect of edits to {{rfscript}}... - -sche (discuss) 20:21, 23 May 2013 (UTC)

I think it is a result of a relatively recent change to {{term}} and a bad category name in {{term}} or something called by it. DCDuring TALK 20:51, 23 May 2013 (UTC)

se

The entry se is not showing the first 30 language sections, even though they are listed at the top. ~ heyzeuss 08:10, 24 May 2013 (UTC)

They all show up for me. Do you use Tabbed Languages? (I don't.) - -sche (discuss) 08:24, 24 May 2013 (UTC)

I use tabbed languages, and they all show up for me. Try hitting http://en.wiktionary.org/w/index.php?title=se&action=purge and see if that helps. —Angr 09:14, 24 May 2013 (UTC)

Bot request: fix full-URL links to Wikipedia

Could someone fix these entries (or an updated list of entries which link to Wikipedia the way Volkshochschule does) by bot? Remember that there are a few variations ([https://en.wikipedia.org/, [http://en.wikipedia.org/, [//en.wikipedia.org/). Full-URL links to WP should be replaced by [[w:foo|and-optionally-bar]] or {{w|foo|and-optionally-bar}}. - -sche (discuss) 18:42, 24 May 2013 (UTC)

Also, is there any reason not to use an edit filter to block the edition of such full-URL links to 'pedia? - -sche (discuss) 18:46, 24 May 2013 (UTC)

Bot request: Latvian adjective homographs missing second headers

There are currently about three thousand Latvian adjective entries (listed here) which look like this, that is, which conflate two homographs under the same header. This is bad form. Could a bot replace

|adj}}\n\n\{{head|lv|adjective

with

|adj}}\n\n===Adjective===\n{{head|lv|adjective

on all those pages? - -sche (discuss) 18:29, 25 May 2013 (UTC)

There are a few Italian ones like capobanda as well. —CodeCat 18:32, 25 May 2013 (UTC)

The Italian example looks fine to me. The masculine form of the noun has a plural and the feminine form of the same noun is invariant. The Latvian examples refer to forms of different adjectives conflated together.SemperBlotto (talk) 18:37, 25 May 2013 (UTC)

But the feminine noun has a different meaning from the masculine noun. —CodeCat 18:40, 25 May 2013 (UTC)

Um, no. SemperBlotto (talk) 18:49, 25 May 2013 (UTC)

Are you saying they are interchangeable synonyms? —CodeCat 19:01, 25 May 2013 (UTC)

capobanda has two definitions - bandmaster or ringleader. Either may be masculine or feminine. It's a single word and the entry has a single headword. What's the problem? SemperBlotto (talk) 07:03, 26 May 2013 (UTC)

What you seem to imply is that the word has different inflections depending on whether the meaning is a male or a female. So they are two headwords, not one, with distinct meanings. —CodeCat 12:36, 26 May 2013 (UTC)

I think it's problematic as I don't know what the inflection is. Is it either masculine or feminine, and either plural the same or capibanda (irrespective of gender for both plurals)? Mglovesfun (talk) 17:41, 27 May 2013 (UTC)

Initialism template out of whack

Something's wrong with the initialism template, IMHO; see the PMB page for example, it displays with errors in my browser (red "script error" signs; brackets and stuff visible etc.) ---CopperKettle (talk) 02:37, 26 May 2013 (UTC)

See {{initialism}}. Apparently, it's deprecated. User: PalkiaX50 ^{talk to meh} 02:40, 26 May 2013 (UTC)

I made it default to English again. Fixed the problem for me. — Ungoliant ^(Falai) 02:46, 26 May 2013 (UTC)

I noticed the problem in a Spanish entry (which even specified {{initialism|lang=es}} and was still failing messily), though I can't recall which one. It is just another reason to replace that template with an actual part of speech whenever you see it... - -sche (discuss) 03:04, 26 May 2013 (UTC)

I've been fixing these steadily as they appear in Category:Pages with script errors. A lot of entries had missing language codes or used names instead of codes. —CodeCat 12:33, 26 May 2013 (UTC)

I noticed that some, like CN, are using the template as a usage context instead. I'm not sure what to do but we can't support both types of usage at the same time. Either {{initialism}} is a context template, or it isn't. So this might be a good time to orphan all the deprecated uses. —CodeCat 13:21, 26 May 2013 (UTC)

I've decided to move the template to {{initialism-old}} so that it no longer conflicts with usage as a context label. I'm updating the uses now. —CodeCat 14:12, 26 May 2013 (UTC)

PMB as a specific example is a noun and should be formatted as such. Initialism is really its etymology, though since the etymology and definition would then be the same, this is (in my opinion) a good case for {{context|initialism}}. Mglovesfun (talk) 21:05, 26 May 2013 (UTC)

I just fixed a bunch of the same problems with {{acronym}} and {{abbreviation}}. The problem seems to be that there's no flexibility: the language code has to be a positional parameter (lang= doesn't work), but wrapper templates such as {{informal|acronym}} may need the positional parameter so they can pass it on to the other template, presumably as a positional parameter. There were a couple of cases with wrapper templates where it seemed to be fixed (at least it wasn't puking its guts out in technicolor, as before), but it still put itself in the Script Errors category. Chuck Entz (talk) 05:51, 27 May 2013 (UTC)

we need acronym-old and abbreviation-old then. Mglovesfun (talk) 10:20, 27 May 2013 (UTC)

Even if the templates did accept lang= as a parameter, they would still not work as context templates. So if someone were to type {{context|abbreviation|Internet}} it would not show "Internet". Templates need to work in a special way in order to be usable as context templates. —CodeCat 12:15, 27 May 2013 (UTC)

I've moved them; now no uses of abbreviation, acronym or initialisms in headers. Still used under the new name initialism-old (and so on), and those should be eventually orphaned but there are so many of them and they are still being used, it may never happen. Mglovesfun (talk) 14:29, 27 May 2013 (UTC)

Reforming Template:fr-noun and Template:fr-adj

I'm going to implement the reforms I first proposed in 2010 (looking at the template's talk pages) perhaps as early as tomorrow. But since I can't write modules they will be in the 'template' language. If anyone would rather write a module (or expand an existing one) then go ahead. The idea is to unify all the functions {{fr-noun}}, {{fr-noun-unc}} and {{fr-noun-inv}} into fr-noun, and {{fr-adj-mf}} into {{fr-adj}}. So fr-noun will have a switch for gender then one for type (- for uncountable, inv for invariable, otherwise display a plural, plural code to remain unchanged) and for fr-adj, I would suggest {{fr-adj|mf}} for masculine and feminine adjectives. It's what {{frm-adj}} does, but {{ca-adj}} use {{ca-adj|type=mf}}, which in my mind at least uses extra keystrokes with no overall benefit. Mglovesfun (talk) 16:51, 27 May 2013 (UTC)

Actually, {{ca-adj}} uses Lua now and it's {{ca-adj|mf}}. —CodeCat 17:01, 27 May 2013 (UTC)

Well, do you fancy it? Frankly I have more confidence in you doing a good job than I do in me. Mglovesfun (talk) 17:38, 27 May 2013 (UTC)

Learning Lua is a good skill especially as we begin to use it more and more. Module:ca-headword is a good start for Module:fr-headword, and you might be able to figure out what it does, and adapt it to French (which shouldn't be too hard, as they have similar grammar). If anything is unclear or if you want to make sure something is ok, you can ask me or others for help. —CodeCat 12:19, 28 May 2013 (UTC)

templates broken?

{{abbreviation-old}} does not accept "|lang=", and a bot went around replacing {{abbreviation}}; several other templates as well (such as {{initialism}} pointed out above) why are the templates incompatible with "|lang=" ? Shouldn't all the single-language templates be compatible with "|lang=" ? -- 65.94.76.126 07:37, 28 May 2013 (UTC)

My guess is that there's aren't 'broken' but CodeCat removed the lang function, as she's into that. Mglovesfun (talk) 10:51, 28 May 2013 (UTC)

The templates always supported the first parameter in addition to lang=, and most uses already used that parameter. I just converted the remaining few. I can add it back if you really want to, but I think it's ok as it is. —CodeCat 12:16, 28 May 2013 (UTC)

There's an agreement not to use these templates anyway; just orphaning them will take years, as a bot can't work out the part of speech and therefore the appropriate template; it has to be done by hand. Mglovesfun (talk) 12:33, 28 May 2013 (UTC)

On the one hand, it could be good for them to (re-)support a lang= parameter until they can be orphaned. It's intuitive to add lang= to things to declare their languages. I don't recall ever seeing a use that wasn't bare {{abbreviation}} (i.e., I never saw lang= or the first parameter used to declare a language), but when I noticed they had started throwing script errors, my first thought was to try adding lang=.

On the other hand, because the goal is to orphan and delete them, it may be good to make them hard to use. - -sche (discuss) 18:37, 28 May 2013 (UTC)

Language specific l templates

There was some talk that templates like {{l/en}} might be deprecated already in favor of a faster Lua version of {{l}}. I've stopped adding language specific l templates. Should I have? Mglovesfun (talk) 14:35, 28 May 2013 (UTC)

There is no problem in adding them, as long as they remain backwards compatible with {{l}}. We can always replace them back again when it comes to it. —CodeCat 14:49, 28 May 2013 (UTC)

Is it possible at all to make a Lua version of {{l}} that is faster than the language specific ls? They are pretty optimised, having only one operation and not transcluding anything. — Ungoliant ^(Falai) 15:01, 28 May 2013 (UTC)

I doubt it, mainly because there'd always be a need to import the module as well. —CodeCat 15:05, 28 May 2013 (UTC)

With language-specific l templates each template must be loaded separately, as opposed to a unified l template which only needs to load once, and the language module also only needs to load once, I think. So, maybe? --Yair rand (talk) 16:46, 28 May 2013 (UTC)

Aren't the "ifexist" tests the source of the performance problem rather than the loading? DCDuring TALK 19:33, 28 May 2013 (UTC)

Is there an actual need for language-specific l templates? -- Liliana • 16:12, 28 May 2013 (UTC)

I seem to think there was one appendix that many users couldn't load until it switched from l to a language specific template. Mglovesfun (talk) 16:32, 28 May 2013 (UTC)

Yes; Appendix:Swadesh lists for Slavic languages was difficult or impossible to edit until it started using the language-specific templates. Most pages don't transclude {{l}} hundreds or thousands of times, but the ones that do are much more usable when they use the language-specific daughters of {{l}}. —Angr 16:43, 28 May 2013 (UTC)

Evidently, our Module:languages isn't optimal yet. For one, the language family information could be outsourced to another module, as that doesn't actually seem to be needed in very many cases (mostly only in categories, I think?). This would allow pages to load a bit faster. -- Liliana • 16:46, 28 May 2013 (UTC)

Module:languages really isn't a problem in this case. It's only loaded once per page, so its efficiency is not relevant for how many calls to {{l}} there are on the page. —CodeCat 16:48, 28 May 2013 (UTC)

Loading doesn't take long, yes, but it still needs to be parsed for every invocation, and that takes a while. -- Liliana • 17:01, 28 May 2013 (UTC)

As far as I know, it's only parsed once as well; the data is kept in memory. —CodeCat 17:02, 28 May 2013 (UTC)

As long as it is loaded by mw.loadData, that should be correct. —Michael Z. 2013-05-28 17:31 z

Audio files not playing

I've noticed over the past couple of weeks that audio files are no longer playing for me, whether here or on Commons. Has there been a change to the audio player in this time, and has anyone else had problems? I'm having the same problems whether I use Safari/Mac or Firefox/PC. The files won't start playing at all. --EncycloPetey (talk) 13:22, 29 May 2013 (UTC)

How did you ever get the audio working in Safari/Mac at all? The Xiph QuickTime component (updated in 2009) just plays silence. —Michael Z. 2013-05-29 17:37 z

No idea. It all worked fine up until recently. Now, the files won't even begin to play for me. And, as I said, the problem is not limited to my Mac. --EncycloPetey (talk) 04:24, 30 May 2013 (UTC)

I have no trouble playing audio files on Firefox on Windows 7. —Angr 09:30, 30 May 2013 (UTC)

Exact version info for tested browsers would be welcome, plus operating systems. --AKlapper (WMF) (talk) 11:30, 30 May 2013 (UTC)

I'm using Safari 6.0.3 in Mac OS X (10.8.3).

I was able today to get a single Audio file to play (the US pronunciation of hello), but it took about 30 seconds of waiting for the little spinning color wheel, then I got a warning about allowing the application to run and had to accept the risk, at which point the latter half of the file played. I had to replay the file to hear the whole thing. After finishing play, the player image did not reset, so it had to be clicked twice to play the file again. I then tried to play the UK version of the same word, and my browser locked up. After a minute, I had to force my browser to close. --EncycloPetey (talk) 22:29, 5 June 2013 (UTC)

Safari 6.0.4/Mac OS X 10.8.3, no Flash – until recently, these used to act like they were playing through, but no sound would come out. As of today, I notice that the interface looks slightly different, lacking the volume bars. Now the play triangle changes to a pause symbol, but the timer does not advance and “playing” never finishes. Still no sound. —Michael Z. 2013-06-05 22:54 z

Firefox 21/Windows7: No real problem, though the UK pronunciations are significantly less audible. DCDuring TALK 00:27, 6 June 2013 (UTC)

After updating to the 25th version of Java and the latest Safari/Mas OS version, I finally was able to get audio files to play, although not without additional headaches. I had to "Allow" the Java applet, which took a couple of minutes' wait while the little color wheel span, and then had to agree to permit play again after a second dialogue box gave we a security warning. Not a very friendly approach, but at least I can play audio files again. I just wonder whether I'll have to go through that process every month when I have to log in again fresh. --EncycloPetey (talk) 01:25, 20 June 2013 (UTC)

Block links on user pages?

Quite a bit of spam is in the form of sneaky links that are added to user pages. I wonder if we can block them by simply disallowing any edits by non-admins from containing "http://" on a user page? —CodeCat 01:05, 30 May 2013 (UTC)

That's too general. There are legitimate external links of that sort, such as external links to useful resources for editing. --EncycloPetey (talk) 04:25, 30 May 2013 (UTC)

I think it would be reasonable to block a new user's first edit if it contains an external link. Equinox ◑ 04:33, 30 May 2013 (UTC)

That would be possible to do with the abusefilter, but I suspect that first edits containing external links on user pages might sometimes be innocent. --Yair rand (talk) 04:37, 30 May 2013 (UTC)

Well, we can tag them and see, and block them if your suspicion doesn't hold up (though I, too, think it will hold up).​—msh210℠ (talk) 18:31, 31 May 2013 (UTC)

A lot of these have very similar structure. A number of lines separated by "br" html tags (describing the person), then a line asking you to visit their blog etc. It looks like they are being generated semi-automatically. I have done a quick search for anyone offering a service to promote blogs on Wiktionary, but have not found such a thing as yet. SemperBlotto (talk) 07:50, 30 May 2013 (UTC)

Those are all created by spambots. They're strictly for putting the links where Google will see them and camouflaging them so they won't get deleted as fast. The other elements are assembled randomly by an algorithm and the "blog" or "home page" is some random web site that the spammer is trying to move up in Google's page ranking. Chuck Entz (talk) 13:24, 30 May 2013 (UTC)

OK, here's an example. User:Viennea's first edit was the creation of their userpage, which includes a link to youtube. I haven't clicked the link so I don't know what's there, but in general how do I tell the spam from the good-faith links without clicking on the links? (Obviously I don't want to click on a spam link.) —Angr 14:26, 30 May 2013 (UTC)

That was User:Viennea's only edit, as far as I can see. The user page should be deleted as spam or self-promotion. SemperBlotto (talk) 14:34, 30 May 2013 (UTC)

But should Viennea be indef blocked? An obvious spammer would be. —Angr 15:01, 30 May 2013 (UTC)

I don't think so. He has made nearly 800 edits on German Wikipedia. Perhaps me means to edit here some time. Who knows? SemperBlotto (talk) 15:08, 30 May 2013 (UTC)

Thanks for looking on other projects. Since the youtube link is the same one as at her German Wikipedia userpage, I was so bold as to click it. It's just José Feliciano singing about Vienna, no spam. So I don't feel inclined to delete the userpage myself, but rather to take this an example of a new user whose first edit is to create their own user page with an external link on it, and who nevertheless is acting in good faith. —Angr 15:27, 30 May 2013 (UTC)

It is still reasonable to block a new user's first edit, if it has an external link. We can put up an apologetic message, saying that this is to stop spambots (just like a CAPTCHA at signup); they would understand. A real user could wait and add their link later. A bot would not know. Equinox ◑ 17:09, 30 May 2013 (UTC)

Given the unflagging volume of these foul bots I would like to re-urge this issue. Equinox ◑ 14:50, 17 June 2013 (UTC)

The last recommendation seems reasonable. How does it get implemented, ie, who? DCDuring TALK 14:59, 17 June 2013 (UTC)

Any admin, by using Special:AbuseFilter. --Yair rand (talk) 16:35, 17 June 2013 (UTC)

This Equinox quote sounds reasonable to me: "It is still reasonable to block a new user's first edit, if it has an external link." --Dan Polansky (talk) 19:03, 17 June 2013 (UTC)

I'd like to qualify that and say that it has to be an edit to their user space (user or user talk), and not necessarily just the first edit but maybe the first five? —CodeCat 19:21, 17 June 2013 (UTC)

Re the original proposal: rather than blocking non-admins, block users who haven't been autoconfirmed. Re this proposal (block adding a link in the first five edits): sure, if that's doable. - -sche (discuss) 20:21, 17 June 2013 (UTC)

June 2013

One-click patrolling gone away

For a couple of days now, the ability to patrol an edit with a single click has gone away. I can't remember who created the system. Any ideas? SemperBlotto (talk) 06:58, 2 June 2013 (UTC)

Ruakh I think. Mglovesfun (talk) 08:57, 2 June 2013 (UTC)

Yeah, Ruakh. The script in question is [[MediaWiki:Gadget-PatrollingEnhancements.js]], I think. I assume an update to the MediaWiki software is to blame. - -sche (discuss) 17:42, 2 June 2013 (UTC)

Indeed. The problem is that unpatrolled "diff" links in the UI no longer include the recent-changes ID (&rcid=...), which the gadget needs in order to mark the edit as patrolled (since that's how the API identifies the edit). The good news is, I added support a long time ago for Special:Contributions, which never included the recent-changes ID in the "diff" links, so that support should be mostly transferable to other pages. I'll give it a shot . . . —Ruakh_TALK 18:13, 2 June 2013 (UTC)

 Fixed, I think, but it won't surprise me if there are some cases that used to work and no longer do, or that used to work perfectly and now work less-than-perfectly. If you encounter any, please let me know. —Ruakh_TALK 04:11, 3 June 2013 (UTC)

Oh, one harmed case is Special:Watchlist. The API's list=recentchanges feature doesn't let you filter by whether a page is watched, and its list=watchlist feature doesn't offer a way to retrieve the RCID, so there doesn't seem to be a good way to handle it. This is pretty unfortunate, IMHO, since I think the watchlist is a good way to nudge admins to do a little bit of "easy" patrolling. I'll have to think about this . . . —Ruakh_TALK 04:33, 3 June 2013 (UTC)

Still not working for me. Is there anything I have to do? (I use monobook, with no customization - but "patrolling enhancements" ticked) SemperBlotto (talk) 07:21, 3 June 2013 (UTC)

Ugh, sorry, I made another change after commenting above, and apparently I failed to re-test afterward. It should be good now. —Ruakh_TALK 14:11, 3 June 2013 (UTC)

Thanks. Works a treat now. SemperBlotto (talk) 14:12, 3 June 2013 (UTC)

Missing toolbox in IP contrib pages

I seem to no longer have that little toolbox on IP contrib pages :/ Y'know the one with links for Geolocate and all that. User: PalkiaX50 ^{talk to meh} 18:17, 2 June 2013 (UTC)

I still have it. —Angr 06:42, 3 June 2013 (UTC)

I can’t add a Galician translation.

I could put in Portugese mercado negro as a translation for black market if I wanted, but for some magical reason I can’t use the same box to put in Galician mercado negro. Explain this shit. --Æ&Œ (talk) 03:02, 4 June 2013 (UTC)

Having a {{trreq}} preceding or following the position of where the translation would be placed causes this bug. — Ungoliant ^(Falai) 03:06, 4 June 2013 (UTC)

Wiktionary:Todo/separated context labels

I believe MewBot has fixed a load of these; could someone update it so I don't end up trying to fix a load of entries that have already been fixed. Mglovesfun (talk) 10:43, 7 June 2013 (UTC)

MewBot is still running and will be for about a week I predict, there are a lot of entries to be done still (currently 120 thousand). However, I told it to add Category:Context label misused to some of the entries (particularly Romance verbs) so they can still be found. —CodeCat 11:59, 7 June 2013 (UTC)

Once the bot finishes putting {{context}} in front of all context labels, it should be possible to make a list of misused context labels by looking for uses of {{context}} not immediately preceded by (# |#). - -sche (discuss) 18:47, 7 June 2013 (UTC)

senseid

Recently {{senseid}} was mentioned in the BP, which brought it to my attention for the first time. It looks like it was made a couple of years ago and hasn't been widely adopted. I like the idea behind it myself so I tried to use it for the senses at field and linked them to those at フィールド. It took quite a long time and added a lot of clutter to the entry. In particular I noticed that it becomes very cumbersome to use when the sense IDs are long, as they were because I was using the translation headers verbatim, as implied (but not stated) in the documentation. So I was wondering:

1. Is the use of this template still encouraged?
2. If so, are shorter sense IDs preferred? I think one-word IDs would be ideal, being perhaps the context when it is present. Putting underscores between each word is very time-consuming.

Perhaps this would be difficult, but would it be possible to add an option to select the sense ID from the wikilink pop-up? --Haplology (talk) 16:21, 7 June 2013 (UTC)

It's not necessary to replace blank spaces with underlines; MediaWiki will do that. You can use {{l/beta}} which has a parameter for senseid BTW. --Z 17:08, 7 June 2013 (UTC)

I have long thought of the senseid as an experiment. It seems incomplete and possibly abandoned. Would the widespread deployment of it make it even more difficult to contribute to polysemic English entries? Would the senseid structure be frequently broken by bad edits? Is those non-issues because those entries are now complete or because only a few experienced contributors are willing to tackle these entries and they can deal with senseid? DCDuring TALK 18:38, 7 June 2013 (UTC)

You can/should use shorter glosses, IMO. - -sche (discuss) 18:40, 7 June 2013 (UTC)

Why? Abbreviating the glosses increases the danger of adding a duplicate ID, which invalidates the page’s HTML and breaks a link. —Michael Z. 2013-06-07 19:02 z

The reason to abbreviate glosses is that a long sense ID adds a lot of clutter for the editor working on it. Take the first sense:

#{{senseid|en|land area free of woodland, cities, and towns; open country}}A land area free of [[woodland]], cities, and towns; open country.

I suspect that if I were not an autopatroller, my edit to field would be reverted immediately. That's partly why I brought this up here--I thought adding a whole lot of sense IDs would irritate some people. It's hard to say how much risk there would be of broken links. In "field", I don't think that field#English-geology would ever break, but others might be harder to reduce to 3 or fewer words without ambiguity. Am I right in understanding that there is no "What links here" function for these?

I see. I see that you can’t even put a space after the trailing braces }} without it showing up on the page. What if the entire first sentence of the definition was in the braces, so there was no redundant text at all? —Michael Z. 2013-06-08 01:49 z

# {{senseid|en|A land area free of [[woodland]], cities, and towns; open country.}}

You mean it isn't a template for telling different 先生s apart?. Seriously, though, "what links here" works, but it includes both these, and every other kind of link, and doesn't show which is which. As for the "whole sentence" suggestion: any rewording of the definition would break the links. The link should be free of content that future editors will feel compelled to change. Even using "sense1","sense2", etc., would lead to editors changing the numbers if they reordered the definitions. Chuck Entz (talk) 02:18, 8 June 2013 (UTC)

Quite right. There may be an advantage to going the other way, and giving the ID no meaning at all. Just a random alphanumeric like “LTas2jzH”. —Michael Z. 2013-06-08 03:28 z

There is also {{anchor}}. - -sche (discuss) 18:40, 7 June 2013 (UTC)

I would prefer keeping Sensei D friendly to humans, meaning both that it has the meaning in English and that it's as short as possible to avoid clutter and save typing. I think context labels should be used instead of glosses when possible. I added this one to isolate:

#{{senseid|en|chemistry}}{{context|transitive|chemistry}} To [[separate]] a [[substance]] in [[pure]] [[form]] from a [[mixture]].

...which is linked to by 遊離, by the way.　--Haplology (talk) 05:20, 8 June 2013 (UTC)

Each sense is a unique sense, while several can have the same usage or grammatical label. Using the label would be a bad habit for editors, and a bad example for newbs. —Michael Z. 2013-06-08 05:41 z

Underscores aren't an issue after all and the assisted gloss addition tool selects suggests senses as you type, so using the full sense would be easy, and much easier than I thought earlier. The only worry I have is people complaining about a situation like this:

#{{senseid|en|chemistry: separation of a component from a mixture}}{{context|chemistry}} The obtaining of an [[element]] from one of its [[compound]]s, or of a compound from a [[mixture]]

But if that's acceptable then using the translation header as a sense ID is fine with me. Yet I don't see why using the context as a means of disambiguation is a bad practice. Sometimes there are multiple senses in with the same context, but often not. The wording of the geological sense of field is more likely to change than the number of geological senses. I doubt it would be a problem in practice.

As for broken links, would there be an easy way to find those if links were made using {{l/beta}}? I assume there would be but I have no idea how it would be done. --Haplology (talk) 13:08, 8 June 2013 (UTC)

Using a label instead of a gloss for an ID means:

• Teaching editors to make a unique sense ID out of a label.
• Teaching them what to do when there is no label (what is that? Use a gloss, I presume.)
• Teaching them what to do when there is a duplicate label (Use a gloss for one, or both?).
• Teaching them not to add a label just to serve as the source of an ID.
• Teaching them to check the IDs when they add a sense with a label, in case it is a duplicate.
• Dealing with the mess when they add labels for IDs.
• Dealing with the mess when they add conflicting IDs for identical labels.
• Living with a system that will break HTML validation predictably, based on the content of the page.

The best way to deal with broken links is to not make broken links. Creating a unique ID from a unique gloss makes sense. Creating a unique ID from a label which may be absent or duplicated does not. —Michael Z. 2013-06-09 20:25 z

• Help:Glosses gives a pretty good description of how glosses should be made.
• Using glosses in senseids is recommended, by me at least :) . The senseid adding tool in the definition editing options gadget autocompletes to the existing glosses on the page (from translation boxes, synonyms sections, etc.) to make things easier. One significant benefit of using glosses is that it allows machines to identify other areas that have glosses as being associated with a particular definition.
• The standard linking template, {{l}}, does not yet support an id= parameter for linking to senseids, though I hope it will at some point. Once it is added, I would be glad to add an equivalent of the wikilink pop-up that would allow selecting senseids from a list. --Yair rand (talk) 14:59, 9 June 2013 (UTC)
• I have considerable doubts about senseid. It is likely to make things more complicated, the wiki markup more busy, with not much benefit. If this is to become more widespread, the supporters should better write up how that is supposed to work, what the benefits are, and admit the disadvatanges to the extent to which they are aware of them. Such a write-up does not seem available from {{senseid}} documentation page, nor is it linked from the documentation page. Therefore, I asumme that the benefits are as unclear and as poorly articulated or even unarticulated as they were years ago when senseid was discussed in Beer parlour. --Dan Polansky (talk) 18:02, 9 June 2013 (UTC)
  • One way we could lessen the clutter is by integrating it into {{context}}. That way, a context tag would automatically become a sense id. Would that work? —CodeCat 20:33, 9 June 2013 (UTC)

    A multi-functional template meant for every sense. I would call it {{sense}}, or {{s}}. Each line could look like this:

# {{s|gloss=A gloss of this sense|labels=history, intransitive|lang=en}} The definition of this sense.

• • Is lang useful? —Michael Z. 2013-06-09 20:52 z

    • The language would be necessary for the same reason it's currently needed on {{context}} and {{senseid}}. It specifies the anchor (in case several languages have the same sense id) and it sets the category language for the labels. —CodeCat 21:05, 9 June 2013 (UTC)

    Could also be {{definition}} or {{d}}. What about capitalizing some important class of template as {{S}} or {{D}}?  —Michael Z. 2013-06-09 23:33 z

Thanks for the explanations, I see now why it's better to use glosses than unique labels for sense IDs. I'll look at Help:Glosses carefully soon.

Adding a gloss field to a sense template sounds like a good idea to me. I think human eyes can easily look past a single bracketed blurb, even if it is long. Currently with {{senseid}} you have to delete a space between the hash # and the start of the definition, and it would be nice to avoid that.

For me the appeal of sense IDs is hard to explain, but when writing definitions it always feels like a struggle to get the reader to understand exactly what sense is meant. Usually I do this by lumping glosses together and hoping that the reader sees the senses that they all share, or by putting the usually associated words in parenthesis, but there's something about a linked sense ID that gives it an exact, "snap-in" feel that is very satisfying.

I notice that usually the translations are in the same order as the definitions that they correspond to, but not always: should they always be? --Haplology (talk) 06:30, 10 June 2013 (UTC)

Perhaps one contributor to the lack of use of {{senseid}} is that it doesn't really play well with things like redirects, AFAICT. It would be very handy to be able to use redirects to get people from an expression like "our butts" to butt#English-body, self. I thought it could be done, but I tried several approaches that didn't work at one's butt. Many of the entries for highly polysemic English terms are very hard to sift through without something better than the very poor section-level granularity that we can achieve. We know what definition would help a user interested in a given SoP expression, but can't direct her to it, AFAICT. (I hope I'm wrong about this.)

New usage pages with br

There are a lot of spambot using the code <br> (for break, linebreak). Can we block these edits to save time? I'm spending more and more of my time deleting spam. Mglovesfun (talk) 20:31, 7 June 2013 (UTC)

I wish there were a way to block user-page creation by accounts with no mainspace edits- though it might just encourage garbage edits. Chuck Entz (talk) 02:27, 8 June 2013 (UTC)

Suffix search?

Although the prefix search (Special:PrefixIndex) comes in handy at times, I would dearly love to have the equivalent for search words with a common ending string, like what Perseus has for its "Dictionary Entry Lookup" tool. Is there any way to do that here? Chuck Entz (talk) 03:51, 8 June 2013 (UTC)

I just use, as an example, *ization in the Search box. You just get unformatted search results, but that's often what you want. SemperBlotto (talk) 07:01, 8 June 2013 (UTC)

Script errors

Do we really need to have script errors for using {{term}} with a language family name? See chigoe. DCDuring TALK 16:07, 8 June 2013 (UTC)

What alternative do you suggest? —CodeCat 16:17, 8 June 2013 (UTC)

How would I know what's possible? Can I insert sc=Latn? DCDuring TALK 16:49, 8 June 2013 (UTC)

Apparently, I can. The error message is somewhat less dramatically ugly. Good enough for me. DCDuring TALK 16:50, 8 June 2013 (UTC)

As far as I know we don't have entries for entire language families, so I don't know why it should be linked. DTLHS (talk) 16:52, 8 June 2013 (UTC)

That's why I asked. Such terms shouldn't actually exist, neither in a dictionary, nor in real life. So they don't actually meet CFI and should probably use {{recons}} instead. —CodeCat 16:57, 8 June 2013 (UTC)

The term is from an unknown member of the family, probably from a time when those in contact were not particularly interested, probably from a language that was and remains little attested. I guess that makes it a nonword. It is obviously not reconstructed by linguists. DCDuring TALK 17:42, 8 June 2013 (UTC)

But if it's not reconstructed then it must be attested, right? And if it's attested, wouldn't we also know the language? Or is there a kind of "gap" in CFI in this case? —CodeCat 18:12, 8 June 2013 (UTC)

Of course there's a gap. In the real world there can be terms that are not attested and not "reconstructed". The reporting is simply not sufficient to merit inclusion as far as we know. I can't say for sure whether this term is attested in one of the five language that are recognized members of the family. I can say that we will be slow to find out if we make it hard for an interested person to find references to the putative term. Taxonomic names are chock full of names that provide some early evidence of words from native languages. I don't understand whey we don't use term to generate lists of missing words in each language. Such lists would be at least as good as the pages at WT:RE. DCDuring TALK 19:38, 8 June 2013 (UTC)

(edit conflict) I've run into this kind of thing with California Indian languages: early sources may be the only record of extinct languages, but the missionaries, explorers, etc. who wrote these things down didn't know/say what language they were recording (at least not with the kind of precision suggested by use of a language code). Evidence from related lects and comparative work may narrow it down to a given group of languages, but that's it. The terms are definitely attested, but their exact language isn't known. In some cases, it's different enough to assign its own language name (Crimean Gothic may be an example of this, for instance), but often the evidence is too fragmentary to be sure it's not a variety of something already known. While linguists are debating back and forth over the decades about the identity of such fragments, you can't pin a language name on it, but it's not a reconstruction, either. Chuck Entz (talk) 20:03, 8 June 2013 (UTC)

I suppose we could allow {{term}} to use family names then, but only on the condition that the first parameter is blank (no link)? —CodeCat 20:10, 8 June 2013 (UTC)

Alternatively, what I had started doing was writing {{etyl|afa|en}} {{term|foo|lang=und}}. - -sche (discuss) 20:48, 8 June 2013 (UTC)

Both solutions lose the possibility for using term to generate categories of missing terms by language/language family in the way that {{taxlink}} does for taxonomic names. DCDuring TALK 22:04, 8 June 2013 (UTC)

What exactly do you mean by "missing term"? Do you mean that the template should check if the link target page exists? —CodeCat 22:05, 8 June 2013 (UTC)

NadandoBot to upload remainder of CJK Unified Ideographs Extension A (U+3400 through U+4DB5)

Requesting permission for these edits. This is at the request of User:Bumm13. The bot will upload approximately 4557 pages (skipping any pages that already exist). It will also skip any characters without definitions. Test / example edits: 㔫, 㨀, 㨁. I can also provide a file with all of the pages I intend to create upon request. DTLHS (talk) 22:02, 8 June 2013 (UTC)

Would it make more sense to put the definitions in the Mandarin section? (See this short discussion of 佦.) - -sche (discuss) 04:14, 10 June 2013 (UTC)

Not necessarily, some characters simply don't exist in Mandarin, and certain meanings may be restricted to certain languages (e. g. Cantonese), so just putting everything in Mandarin doesn't work. -- Liliana • 04:28, 10 June 2013 (UTC)

Researcher looking for info

See WT:Information_desk#PhD_research_-_inclusion_dates.

She seems to looking for the date when entries were first created - for all entries - or is that all L2 sections? DCDuring TALK 16:38, 11 June 2013 (UTC)

Context label redirects

Is anyone able to make an inventory of all redirects that point to a context label template, along with the template they point to? A list of pairs, in other words, like: Template:UK - Template:British. Alternatively (perhaps better), could a category be added to them instead, like Category:Context label redirects (yes, you can categorise redirects!)? That would be very helpful in converting them to a module at some point, and it would also give us an idea of which labels actually exist (in case we want to weed some of them out). —CodeCat 17:03, 11 June 2013 (UTC)

User:Robert Ullmann/Context labels covers this, just it hasn't been updated for a long time. Mglovesfun (talk) 17:21, 11 June 2013 (UTC)

Template:rel-top

{{rel-top}} does not seem to function outside of principal namespace, eg, in Appendix space and User space. This seems like yet another regression. Can it be fixed? DCDuring TALK 18:11, 11 June 2013 (UTC)

I can't see anything about it that would make it not work. It should just be fine... —CodeCat 18:13, 11 June 2013 (UTC)

I know that it should be. Have you tested it in any space other than principal namespace? Try User:DCDuring#Taxonomy. On my PC (Win 7, FF 21) the all-important unhiding icon is not visible and the unhiding functionality is absent on that page and on a test I ran in Appendix space. DCDuring TALK 18:20, 11 June 2013 (UTC)

Also, as my computer is rarely off and keeps several windows open continuously, including to my main user page, this behavior need not have been caused by a recent change, but could have been caused by something days or even weeks ago. As I am neither a CSS nor a template maven, I have no idea of what the cascading consequences of changes to classes might be or even where to find the various class definitions. DCDuring TALK 18:25, 11 June 2013 (UTC)

The "show" button is visible for me and works as normal. I think it must be on your end? —CodeCat 18:28, 11 June 2013 (UTC)

Aarrgghhh. I have not changed by CSS or JS in a long time. What could make a difference in any of the preferences (though I don't remember making a change there either)? DCDuring TALK 18:31, 11 June 2013 (UTC)

test

I can't get to this.

I can't unhide the above. DCDuring TALK 18:34, 11 June 2013 (UTC)

And can make trans and rel unhiding work as normal in principal namespace. DCDuring TALK 18:37, 11 June 2013 (UTC)

I'd always wondered what kind of thing would finally get me to stop spending time here. This would be an example. DCDuring TALK 18:58, 11 June 2013 (UTC)

In both Firefox and Opera, on a PC running Windows 7, the above rel-box works for me. :/ A while ago, some users complained that the "show quotations" button was missing, and I found that it was indeed taking a while longer than usual to load. That problem seems to have cleared up, but perhaps some of the elves/hamsters that run javascript call in sick from time to time? Because it's javascript that collapses the boxes in the first place, you could temporarily disable javascript, which would have the effect of making the boxes display open (and uncollapsible). - -sche (discuss) 19:15, 11 June 2013 (UTC)

What's strange top me is that in principal namespace it works fine, but not in User, Appendix, and Wiktionary spaces. How would JS become inoperable, 1., by mistake, and/or 2., only in some namespaces? DCDuring TALK 19:57, 11 June 2013 (UTC)

It happens to me on Chrome to, but only when I am logged in, not as an anon. That seems to be a diagnostic help. DCDuring TALK 20:02, 11 June 2013 (UTC)

"Doctor, whenever I use the monobook skin (both in Firefox and Chrome), I can't use rel-top. What should I do?"

"Stop using monobook."

It's an old joke. Was I the last one using monobook? DCDuring TALK 20:25, 11 June 2013 (UTC)

For the purposes of this thread, I just switched to Monobook, and I am still able to open the rel-top in this thread. You and I seem to be using the same system (Monobook, Firefox 21, Windows 7). I'm stumped. - -sche (discuss) 00:08, 13 June 2013 (UTC)

I still have the problem in Monobook, not Vector. I have no skin-specific JS. I assume that the problems is somewhere in the JS created by the selection of preferences for gadgets, in the interaction with some feature of the Monobook skin, which may not have been as thoroughly tested. DCDuring TALK 01:31, 13 June 2013 (UTC)

It seems to have had to do with selecting "translate sidebar interwiki links into English" in gadgets for Monobook, but not Vector. I really do prefer Monobook. DCDuring TALK 02:57, 13 June 2013 (UTC)

Watchlist not working

My watchlist seems to be now permanently broken: it always times out (since several weeks ago). Perhaps this is because of a large number of bot edits recently? What can I do about it? I would even consider wiping the entire list back to nothing, if this can be done. Please respond by talk page since I cannot watch this page. Equinox ◑ 12:09, 12 June 2013 (UTC)

Okay, hiding bot edits seems to have fixed it (for now?). Equinox ◑ 12:40, 12 June 2013 (UTC)

If you ever do want to wipe your watchlist clean, the quickest way to do it is to go to Special:EditWatchlist/raw, select all, and delete. —Angr 12:54, 12 June 2013 (UTC)

Actually, that page times out too, and did so long before my actual watchlist started timing out. Equinox ◑ 12:57, 12 June 2013 (UTC)

Well, that sucks. How many pages you got on there? Does the nonraw Special:EditWatchlist work? 'Cause if you can't access either of those pages, the only way I know of to reduce the number of pages on your watchlist is one by one (slightly faster if you're using pop-ups than if you open each page separately). —Angr 13:02, 12 June 2013 (UTC)

Is this worth a bug report? I find the watchlist to be hard to manage in a way that enables me to keep track of what I'd like to and not too much else. It is easy to forget to watch individual pages and watching every page one edits by default leads to glut. If high-volume contributors don't watch pages, that places even more burden on recent-change patrollers.

Also, doesn't this connect to #One-click patrolling gone away? Ruakh made changes and refers to Special:Watchlist as possibly being adversely affected. DCDuring TALK 13:10, 12 June 2013 (UTC)

No — I meant only that the use-case of one-click patrolling at Special:Watchlist is adversely affected by recent MediaWiki changes, in that even after my compensatory changes to the Gadget, some unpatrolled edits on Special:Watchlist will continue to have the red exclamation point instead of the blue button. —Ruakh_TALK 14:43, 12 June 2013 (UTC)

[6] — does this page time out too? If not, there is a possibility you can wipe your watchlist with mw:API:Watch. Keφr 18:15, 12 June 2013 (UTC)

Vote for this bug at bugzilla. DCDuring TALK 22:55, 12 June 2013 (UTC)

template for 'approbative'?

Hi, I don't know if a discussion has already been had on this, but I think we need a template for approbative. We already have {{pejorative}}, but not its antonym. I'm happy to make the template if one doesn't already exist under some name that I haven't already looked for. Thanks! --Person12 (talk) 23:38, 14 June 2013 (UTC)

What kind of words would it be used for? There is {{politically correct}}. — Ungoliant ^(Falai) 23:58, 14 June 2013 (UTC)

E.g. awesome (adj) sense 2, cool (adj) senses 6&7, hot (adj) senses 6&10, positive (adj) sense 18, and many others. "Politically correct" wouldn't work at all: for one thing, it's such a subjective and loaded term, and for another, it's not the grammatical opposite of pejorative, which, I believe, is "approbative".--Person12 (talk) 00:26, 15 June 2013 (UTC)

I see. In that case, would an approbative label really be necessary? Isn’t the fact that the relevant definitions of awesome, cool, etc. are approbative made clear by the definition (unlike pejorative, which is not obvious in cases like gringo)? — Ungoliant ^(Falai) 00:42, 15 June 2013 (UTC)

I think an approbative label would still be really helpful. I don't think the definitions necessarily make it clear enough for all possible readers, and I think it would be worth having the associated category/list (I'm assuming a category is automatically created when a label is used - is that right?). --Person12 (talk) 10:07, 15 June 2013 (UTC)

Yes, as long as you create the template and it has poscat= parameter. — Ungoliant ^(Falai) 11:19, 15 June 2013 (UTC)

We do not label words like bad or evil as "pejorative". Why would we label good as "approbative"? Why would we label any adjective more-or-less synonymous with good as "approbative"?

Furthermore, approbative is not a word I would want to be subjecting our users to. Many would probably have some trouble with pejorative. Approbative is used less than 0.5% as often as pejorative in BNC+COCA.

If we are going to do something like this, we should probably start with an Appendix of such terms to iron out the conceptual problems before rolling it out. DCDuring TALK 14:22, 15 June 2013 (UTC)

Great, the Appendix idea sounds fine.

Labelling certain words 'approbative' would make it clear that the word is being used to express approval when that might not be sufficiently clear otherwise. E.g. the (New Age jargon sense) of positive could (in my opinion) benefit from another label to further distinguish its (much more subjective) usage from the (much more objective) scientific senses/usages.

As for those who personally dislike the words 'approbative' and 'pejorative', they are more than free to express their opposition. In the case of the latter, though, wouldn't that suggest starting a discussion here?

(p.s. You ask "why would we label good as "approbative"?" I actually didn't suggest labelling 'good' as 'approbative', or 'bad' and 'evil' as 'pejorative', for that matter. Just for the record.)--Person12 (talk) 03:47, 16 June 2013 (UTC)

I don't intend for the Appendix to necessarily be the exclusive home for these permanently. Marshall some examples, spanning the range of possibilities. Provide some rationale for selection or for exclusion of words that a naive observer might believe should be so labeled, eg, like good, youthful, energetic. As far as I'm concerned, give a month for objections or a week after comments negative or qualifying comments stop flowing in and start rolling it out into entries.

An additional question is whether these words should be categorized. I believe not, at least if you do not intend to include in the category all words that are "approbative", which would at least arguably include good. To me categories always imply that the goal is to include all terms that have meet the criteria or have the attribute. DCDuring TALK 08:27, 16 June 2013 (UTC)

Script errors on alin, duwin, kuro

These three entries have errors because the language uses a script code that we don't actually have, Jurc and Lina. This should probably be fixed somehow, either by creating these codes or by changing the script for these languages. —CodeCat 23:39, 14 June 2013 (UTC)

The entries are in Latin script, so I guess their languages’ script should be changed to Latn until the actual script is included in Unicode. — Ungoliant ^(Falai) 23:56, 14 June 2013 (UTC)

Indeed. Mglovesfun (talk) 10:58, 15 June 2013 (UTC)

rebut and סקיני ג׳ינס

I'm not able to edit these entries. I can view them, but when I make an edit, I get a wikimedia error when I save it. Is anyone else able to? —CodeCat 21:24, 15 June 2013 (UTC)

I can't either. Is your bot able to edit them? DTLHS (talk) 21:26, 15 June 2013 (UTC)

Both pages begin with U+FEFF (ZERO WIDTH NO-BREAK SPACE). Unfortunately even if I remove this character in a text editor I still can't save the pages. DTLHS (talk) 21:34, 15 June 2013 (UTC)

My bot isn't able to either, it gets an error. —CodeCat 21:52, 15 June 2013 (UTC)

I tried moving it around, didn’t fix the problem. Oddly enough, I got the error message when moving, but the page was moved anyway. — Ungoliant ^(Falai) 22:06, 15 June 2013 (UTC)

I was able to revert to a version from 2008 (the latest I could view in the history). I still can't view any of the diffs from then until now. DTLHS (talk) 22:06, 15 June 2013 (UTC)

These entries working fine in my mirror (from the latest dump). — Ungoliant ^(Falai) 22:11, 15 June 2013 (UTC)

Actually no. I added one character and the diff says +1,761 bytes! — Ungoliant ^(Falai) 22:14, 15 June 2013 (UTC)

If I copy the content of [[rebut]] as it was at 03:07, 10 February 2013 into another page, I can edit that page, and save it, and edit it some more... but I can't edit [[rebut]] itself. - -sche (discuss) 22:56, 15 June 2013 (UTC)

OK, I just updated the page. If you compare these diffs, you'll notice the dismal nesting of {{term}} that I fixed (thanks to Ungoliant for the assist). - -sche (discuss) 23:08, 15 June 2013 (UTC)

Nesting of another template inside {{term}} seems to have also been responsible for breaking the Hebrew page. - -sche (discuss) 23:09, 15 June 2013 (UTC)

The bad formatting was introduced by Doremítzwr in this diff (you can view the diff if you turn "do not show page content below diffs" on in your preferences), but the page was often edited after that, so it must be only a recent change to {{term}} or to MediaWiki software that causes such bad formatting / nesting to actually break the page. - -sche (discuss) 23:24, 15 June 2013 (UTC)

Is all nesting inside {{term}} a problem? I may have inserted some instances of {{taxlink}} in {{term}}.

Is the problem due to recent changes in {{term}} or something {{term}} uses? DCDuring TALK 23:27, 15 June 2013 (UTC)

Might be a result of Luaisation. My mirror has the latest MediaWiki and no Scribunto, and these entries are working fine (the byte amount bug was unrelated.) — Ungoliant ^(Falai) 23:34, 15 June 2013 (UTC)

This apparently depends on namespace- I can't reproduce the bug on my own sandbox. DTLHS (talk) 00:07, 16 June 2013 (UTC)

So one minimal way to reproduce the error is {{term||{{various templates}}}}. Templates that fail in this context include {{asdfg}}, {{test}}, {{term}}, {{soplink}}, {{lang}}, {{diff}}. Templates that do not fail include {{temp}} and all language templates. DTLHS (talk) 00:32, 16 June 2013 (UTC)

Pretty sure it fails simply if the offending template directly calls any other templates. DTLHS (talk) 00:38, 16 June 2013 (UTC)

Hi all. I saw this earlier today and didn't respond then because you all were able to work around it. But now that I'm back on my computer, could I ask one of you to report this as a bug so we can take a look at it? Our bugtracker and mw:How to report a bug. Thanks! Greg (WMF) (talk) 05:04, 16 June 2013 (UTC)

Bug reported here. DTLHS (talk) 19:28, 16 June 2013 (UTC)

The problem lies with Module:term cleanup, probably specifically to the containsRange function and with mw.ustring.gcodepoint. DTLHS (talk) 17:50, 16 June 2013 (UTC)

{{taxlink}}, probably because it is extremely simple-minded, apparently does not have a problem when used in the second parameter of {{term}}. Of course, it conspicuously fails in the first parameter. DCDuring TALK 18:35, 16 June 2013 (UTC)

Language section linking for requests

As we specify language for templates like {{rfv}} and {{rfv-sense}}, can we not have the section header on WT:RFV link back to the right language section on the entry? Or, better, the location of the RfV tag (or the first RfV tag) with the right language? DCDuring TALK 01:15, 18 June 2013 (UTC)

BTW, it wouldn't hurt to display the language of the RfV in the header, especially for non-English terms. DCDuring TALK 01:17, 18 June 2013 (UTC)

Sure, though I'm not strongly in favor of it either. Mglovesfun (talk) 10:21, 18 June 2013 (UTC)

Done for {{rfv}}. Is there a specific reason you requested that and {{rfv-sense}} but not the other templates ({{rfd}}, {{rfd-sense}}, {{rfd-redundant}}, {{rfc}}, {{rfc-sense}}, {{rft}}, {{rft-sense}}, {{rfv-etymology}}, any others I've missed)?​—msh210℠ (talk) 17:28, 18 June 2013 (UTC)

Oh, you said "templates like". Sorry.​—msh210℠ (talk) 17:29, 18 June 2013 (UTC)

Done for {{rfv}}, {{rfv-sense}}, {{rfv-etymology}}, {{rfd}}, {{rfd-sense}}, and {{rfd-redundant}}.​—msh210℠ (talk) 18:03, 18 June 2013 (UTC)

Conrad.Bot not building indexes

I see that Conrad.Bot hasn't run to rebuild language indexes for over a year. Does anyone have the time/expertise to take over this really useful task? SemperBlotto (talk) 14:53, 18 June 2013 (UTC)