Wealth Maker: Wiktionary - Recent changes [en]: Wiktionary:Grease pit/2013/August

Wiktionary - Recent changes [en]

Track the most recent changes to the wiki in this feed. // via fulltextrssfeed.com

Curious about the benefits of meditation?

In just a few minutes daily, this course will teach you how to relax and relieve stress. Even with a full schedule, you will want to make time for this!

From our sponsors

Wiktionary:Grease pit/2013/August

Aug 10th 2013, 02:53, by Haplology

Revision as of 21:26, 9 August 2013 (edit) ZxxZxxZ (Talk \| contribs)		Latest revision as of 02:53, 10 August 2013 (edit) (undo) Haplology (Talk \| contribs)
Line 226:		Line 226:
	: I looked at the module, but there is no documentation of how it works anywhere, or even any comments in the code to describe the purpose of each part. That makes it very hard for me to understand what's going on, let alone what's going wrong. Someone would need to know what each part is supposed to do, first, before they can figure out where/why it's not doing what it's supposed to. {{User:CodeCat/signature}} 16:11, 9 August 2013 (UTC)		: I looked at the module, but there is no documentation of how it works anywhere, or even any comments in the code to describe the purpose of each part. That makes it very hard for me to understand what's going on, let alone what's going wrong. Someone would need to know what each part is supposed to do, first, before they can figure out where/why it's not doing what it's supposed to. {{User:CodeCat/signature}} 16:11, 9 August 2013 (UTC)
	: Fixed I think. --[[User:ZxxZxxZ\|'''Z''']] 21:26, 9 August 2013 (UTC)		: Fixed I think. --[[User:ZxxZxxZ\|'''Z''']] 21:26, 9 August 2013 (UTC)
		+	:: Thanks! I decided to keep the existing function for the case of when the ッ character came first, and commented out the line that (I think) does that. Sorry I misspoke before. When it comes last, it should definitely be dropped and now it does that correctly. Thanks for the help! --[[User:Haplology\|Haplology]] ([[User talk:Haplology\|talk]]) 02:53, 10 August 2013 (UTC)

Latest revision as of 02:53, 10 August 2013

<references> is blotting out the Lojban entry! Is this supposed to happen? Hyarmendacil (talk) 09:33, 1 August 2013 (UTC)

My fault. Sorry. — Ungoliant ^(Falai) 09:53, 1 August 2013 (UTC)

Someone with Wiktionary superpowers to do GREP on all Chinese-character entry pages?[edit]

Over in the Beer Parlour we have been discussing a situation where an editor has been systematically adding inappropriate blocks of content -- consisting of his own hypothetical work -- to a large number of Han (Chinese) character entry pages:

The conclusion is that all of these blocks should be removed -- and the right way to do this is with some kind of automated procedure.

These blocks of content appear on many but not all Han character pages, as a subsection of the section "Translingual". They start with a section title "Phonosemantic interpretation" and end with an off-site link. This regularity should make them fairly easy to delete with GREP.

Alternately, perhaps the content management system for Wiktionary is so sophisticated, that it is aware of classes of Wiktionary-wide section titles, and can "turn off" all of these sections based on the section title "Phonosemantic interpretation"? Or something like that?

Here are two examples:

Note for GREP that the off-site URL at the end ("Source: Howell & Morimoto") will be slightly different for each entry -- linking to a different page on that off-site web site. Also note that you cannot depend on what section will come next on the page as a delimiter -- this varies.

Thanks! HanEditor (talk) 06:45, 2 August 2013 (UTC) hanEditor

I don't know if GREP is even possible, since around here such things tend to be done by bots. Chuck Entz (talk) 22:20, 2 August 2013 (UTC)

Actually you're on the right track here. Where do I find the kind of people who write bots for Wiktionary?

Thanks HanEditor (talk) 04:02, 3 August 2013 (UTC) hanEditor

Some hard-working Wiktionarians have manually deleted all of the sections I discuss here, so this specific issue is resolved. But below in "Who's Flying This Plane?" I rehash it in its more general form, as there are a number of other cross-article edits I'm finding a need for. The GREP concept here also generally applies. HanEditor (talk) 10:41, 9 August 2013 (UTC)

A problem with the translation fixing gadget[edit]

I tried to change it so that it would add {{tø}} to entries instead of {{t-SOP}}. I think that worked, but the gadget is not always putting links [[ ]] around the individual parts of a SOP term. This is a feature that {{t-SOP}} supported; it would automatically link the words itself. But {{tø}} can't do the same, so the end result is wrong. I have tried to understand why the gadget is not always adding links to the words, but as seems usual with our JavaScripts, they're not documented or even commented so I really have no idea what I'm doing and I don't know how to fix it without possibly breaking something else. Is anyone else knowledgeable enough to have a look? —CodeCa t 21:58, 2 August 2013 (UTC)

Dynamic loading of content?[edit]

A problem with large pages is that they are basically all-or-nothing. The content all has to be downloaded even if a user is only interested in a small part of it. For Wiktionary:List of languages I added section ids so that you can easily look up a language with WT:LL#en (for English). This is just as easy as looking up the language template used to be. However, this approach has obvious drawbacks because of the page size; it takes long to load it all. So I wonder if there is a way to specify what you are looking for, and load only that and nothing else. Many websites implement this through JavaScript, by loading content only when you request it. Can we do this on Wiktionary too? —CodeCa t 22:48, 2 August 2013 (UTC)

Abuse Filters 25 and 26[edit]

I tried to write a filter that would catch instances of new users adding external links, but the filters I wrote seem to tag anything and everything, whether it contains a link or not. Can someone more familiar with the language of abuse filters have a look? Blocking external links would stop spambots without preventing colleagues from other wikis from introducing themselves like Filter 21 so controversially did. - -sche (discuss) 02:53, 4 August 2013 (UTC)

You should have used added_lines, because new_wikitext means all of the text of source code of the page after edit. I made a change to Special:AbuseFilter/26, but used a more accurate variable there. --Z 18:18, 5 August 2013 (UTC)

I'm not sure if it's your change that did it, but user-page spam has started getting through the filters. Please fix it. Thanks. Chuck Entz (talk) 14:37, 6 August 2013 (UTC)

If the pick-up in spam started about the 26th of July, it's because that's when I deactivated filter 21 pursuant to this; if it happened more recently, I don't know what caused it. Z's change to Filter 26 should stop the spam, though... thanks Z! The filter also blocks some non-spam edits, like this one where someone formatted a link to Wikipedia like an external link, but it's a lot less sloppy than filter 21 and shouldn't block colleagues from other wikis. - -sche (discuss) 16:47, 6 August 2013 (UTC)

This hasn't been updated since May (except to quibble over a comma). Can someone update it? If it'd be too hard to separate form-of defs from non-form-of defs, just a list of how many times each L2 occurs would be nice. - -sche (discuss) 15:34, 4 August 2013 (UTC)

The comma has now been updated, but not the data, which some would argue is the more important part of the page. - -sche (discuss) 14:51, 5 August 2013 (UTC)

Data shmata. DCDuring TALK 15:34, 5 August 2013 (UTC)

Why does this have no rs= parameter to pass to {{liushu}}? Currently we have over a thousand characters in Category:Chinese terms needing attention and most of them are characters using this etymology template. -- Liliana • 20:58, 4 August 2013 (UTC)

Russian noun declension table (width) and verb conjugation (colour of missing forms)[edit]

Two requests/questions:

Could someone please suggest a way to adjust the width of Russian declension tables - {{ru-decl-noun}}. Now, with automatic transliteration, it's probably better to make them wider (the external and internal frame) or automatically adjustable to the width of a form + transliteration. The transliteration appears in a different colour (gray) and in round brackets, so it would be nice if forms and transliteration would appear on the same line (where practical). Example: взаимопонимание. Multipart words should eventually be converted to use {{ru-decl-noun-see}}, no need to worry about superlong words.
Verbs using Module:ru-verb use template, which makes missing forms appear in red, e.g. делать. What should be changed to the module to make them appear in black as with nouns? --Anatoli ^{(обсудить}/^вклад) 01:40, 5 August 2013 (UTC)

You can put the "inflection-table" CSS class on the table, that will make red links black. —CodeCa t 01:43, 5 August 2013 (UTC)

Thank you. Could you do it, please? Or suggest what to change in these lines from Module:ru-verb:

  ...      return [=[<div class="NavFrame" style="width:49.6em;">  <div class="NavHead" style="text-align:left; background:#e0e0ff;">]=] .. title .. [=[</div>  <div class="NavContent">  {| class="inflection inflection-ru inflection-verb"  ...

Where should "inflection-table" class be applied? I haven't found an example. --Anatoli ^{(обсудить}/^вклад) 02:30, 5 August 2013 (UTC)

  ...  {| class="inflection inflection-ru inflection-verb inflection-table"  ...

should do it. That's how you specify multiple classes. –Catsidhe ^{(verba, facta)} 02:38, 5 August 2013 (UTC)

Brilliant! Thank you very much.

The noun declension query remains open. --Anatoli ^{(обсудить}/^вклад) 02:44, 5 August 2013 (UTC)

Well, at the moment, the ru-decl-noun template says

  {| style="background:#F9F9F9;text-align:center;width:30em" class="inflection-table"

So it's saying that the width should be 30em. Whatever you put there, it will make the default width. So to double the width (for all tables from this template), make it 60em. Or else remove the "width=..." part entirely, and the table will be as wide as it needs to be, and no more.

It might be worth trying changing it to "min-width=30em", so that smaller tables won't shrink, but they can grow as necessary. In theory; browser CSS compliance depending.

–Catsidhe ^{(verba, facta)} 03:02, 5 August 2013 (UTC)

I have tried but it didn't work as expected. The table now takes the whole page and there's some internal table, which is still narrow. See [[взаимопонимание]]. --Anatoli ^{(обсудить}/^вклад) 03:11, 5 August 2013 (UTC)

I just deleted both references to width, and it's as wide as it wants to be. Which is probably wider than it needs to be. Give me a sec, I'll have a tweak. –Catsidhe ^{(verba, facta)} 03:18, 5 August 2013 (UTC)

Set the table to 45em min-width (which means it should grow as necessary, but not shrink beyond that: that setting can be tweaked, and can probably be set back down to 30em), and set the first column to 10em, from the 33% it was. Which means the width of that column should remain the same as it was, but the other two columns can grow as needed, and won't affect the first. Please check that it looks OK across Russian nouns of varying lengths. –Catsidhe ^{(verba, facta)} 03:23, 5 August 2013 (UTC)

Thank you but it's not quite right yet. The inner coloured frame stretches alright but the outer frame occupies the whole width of the page (partially white). I don't know if it's possible to make them stretch together. --Anatoli ^{(обсудить}/^вклад) 03:28, 5 August 2013 (UTC)

Try now. (style="display: inline-block;min-width:45em" seems to have been the magic invocation on the outer containing frame.) –Catsidhe ^{(verba, facta)} 03:34, 5 August 2013 (UTC)

Looks great! Thank you very much for your help today! --Anatoli ^{(обсудить}/^вклад) 03:39, 5 August 2013 (UTC)

Positioning transliterations in inflection tables with CSS[edit]

At User talk:Vahagn Petrosyan I suggested modifying {{l-self}} specifically for use in inflection tables (by creating a new {{l-table}} which may or may not replace {{l-self}} altogether, depending on how much it's needed elsewhere - but that's beside the point right now; maybe a new template isn't needed). The problem is automatic transliterations. We definitely want them, but we don't want to tie the way they display into the template, because different tables may want to display the transliteration differently. The Russian verb inflection tables, for example, put the transliteration on the line below the main word and display it in grey text, and without parentheses. To account for all these different styles I figured we could use CSS to do the positioning. But how can this be done? Is there a way to say, in CSS, that the transliterations in one table should not have parentheses and be displayed below, while the transliterations in another table should have them and be displayed beside? —CodeCa t 11:07, 5 August 2013 (UTC)

We should probably use

  span.translit {      display: block;  }

to put transliteration in a new line and use display: none; to remove parentheses. --Z 17:23, 5 August 2013 (UTC)

Isn't it possible to use CSS to put the parentheses in, rather than remove them? —CodeCa t 17:25, 5 August 2013 (UTC)

What do you mean by "to put the parentheses in"? If you mean "Isn't it possible to use CSS to add the parentheses", no, not with CSS... --Z 17:32, 5 August 2013 (UTC)

Help with suffixes, adding line breaks where it shouldn't[edit]

I'm struggling to get {{suffixcat}} working. I made a module function to generate the correct form of the suffix. But the software keeps adding a line break in front of the * that is used for reconstructed terms. So when I type:

  test{{#invoke:compound|make_affix|*atjaną|lang=gem-pro|sc=|suffix=1}}

it comes out as:

test

where the two parts have been broken up by a newline, which turns the * into a list bullet. Does anyone know why it's doing this, and how to prevent this from happening? —CodeCa t 15:16, 5 August 2013 (UTC)

Fixed. --Z 16:59, 5 August 2013 (UTC)

No, I fixed it, and you broke it again in another way... See Category:Proto-Germanic words suffixed with *-atjaną. —CodeCa t 17:13, 5 August 2013 (UTC)

Are you sure? I reverted my edit and test{{#invoke:compound|make_affix|*atjaną|lang=gem-pro|suffix=1}} adds line-break now. --Z 17:19, 5 August 2013 (UTC)

Yes that still happens, but I found a workaround for it. I made {{concat}} which is able to strip off the newline again. It's not nice but it works... let's hope they fix this bug soon. I reported it but it turns out it was reported 5 years ago [1] and never fixed. Kind of sad... —CodeCa t 17:24, 5 August 2013 (UTC)

Who's Flying this Plane?[edit]

When Wiktionary site coding needs to get changed at a deeper level than editors can do, how do editors let someone who can do that, know that it needs to be done?

My deepest probing of the Help pages finds not a trace of "technical administrators" -- let alone the "Wiktionary Web development team".

HanEditor (talk) 09:25, 6 August 2013 (UTC) hanEditor

The Wikimedia Foundation people. Maybe you can get some help here. What needs to be done anyway? — Ungoliant ^(Falai) 09:48, 6 August 2013 (UTC)

If you've noticed a bug, you can report it to Bugzilla. You might also find MediaWiki helpful. - -sche (discuss) 17:20, 6 August 2013 (UTC)

Well I'm trying to find someone who can do some content-alteration batch jobs across hundreds or thousands of pages.

Maybe is there an existing bot that can do this, with customized parameters? Or is there some editor or admin who can easily create a custom bot for specific content-replacement tasks?

Frankly I hope I can't do this as a mere mortal editor (even if I had the vaguest clue how to code a bot), as of course this has the potential to replace content in all articles with vandalism.

But part of the point is that this seems like something fairly normal to do -- some minor formatting issue across articles, missing commas, etc. So I'm kind of bemused and frustrated that there isn't some standing official way to do this, and helpful people in the Grease Pit directing me to get it done quickly and painlessly.

HanEditor (talk) 08:39, 7 August 2013 (UTC) hanEditor

'Kay. So. Anyone volunteering to manually enter an asterisk meaning "reconstructed form" in each of a thousand or more Middle Chinese entries? Crickets... crickets...

HanEditor (talk) 09:40, 9 August 2013 (UTC)

Private Use characters[edit]

Is there a way to find entries which use characters from the Private Use Area (possibly from a dump)? They should never occur in entries, but I've seen them when looking through Chinese characters. -- Liliana • 12:54, 6 August 2013 (UTC)

User:DTLHS/private use DTLHS (talk) 00:27, 7 August 2013 (UTC)

Killer Robots Eating My Alternate Chinese Characters[edit]

I'm trying to discuss the alternate forms of a Chinese character, and something in Wiktionary (basic text handling?, bot?) is physically converting the obscure characters to their more common equivalent. That is, I type the obscure character into the edit form. It's there. Then I click Preview, and the actual character has been replaced -- both in the rendered preview, and in the text editing window.

For one of the obscure characters, I managed to (partly) get around this, by using its Unicode number as an HTML special character (&#x-number-semicolon). I now get the obscure character displayed. But... it won't display as a link.

(I'm not sure if that's because it's an HTML character code not text, or because Wiktionary is "referring" the obscure character to the page for the more common character -- which is the current page, meaning no link.)

For a second obscure character, even using the Unicode HTML code doesn't work. The rendered page converts it to the more common character for display (though the Unicode HTML code remains present in the page source).

The two obscure characters are U+FA5E and U+FA5D, and Wiktionary is trying to convert them to U+8279.

The crime scene: http://en.wiktionary.org/wiki/艹

Thanks, HanEditor (talk) 09:54, 7 August 2013 (UTC) hanEditor

That's due to Wiktionary using NFC conversion which turns the compatibility characters back into unified characters. You can use HTML entities as a workaround to display these, and you can even link them (observe: 艹艹) but they will always link back to the normalized form - and since you are on the link target already, they will display in bold instead. I guess you could abuse {{l}}, as in {{l|mul|艹}} {{l|mul|艹}}, which will always link to itself due to the addition of a section anchor (艹艹), but other than that, there's not much you can do. -- Liliana • 11:12, 7 August 2013 (UTC)

Thanks Liliana. I'm now seeing that it actually is displaying the U+FA5E character, when the Unicode code is used. (It's so tiny the two crosses blur together.)

And I also now see that being able to link the characters is pointless. I had wanted to create stub pages for them, but no one will be able to search for those anyway (they'll get auto-referred to the standard character page).

So resolved enough.

HanEditor (talk) 09:42, 9 August 2013 (UTC)

Could someone please figure out how to grandfather in stuff like nära and make them work as is? —Μετάknowledge^{discuss/deeds} 17:52, 7 August 2013 (UTC)

Fixed I think. --Z 08:30, 8 August 2013 (UTC)

is not linking to the correct circumfixes. For an example, see მესაქონლე. The circumfix is split it into a prefix and a suffix (which don't even seem to exist independently). Can someone please fix this? Ultimateria (talk) 06:09, 9 August 2013 (UTC)

Unicode "Kangxi Radicals" Block Characters Causing Wiktionary Error[edit]

The Unicode "Kangxi Radicals" and "Kangxi Radicals Supplement" blocks —

contains duplicate characters from the main "CKJ Unified Ideographs" block.

Currently, trying to search for them in Wiktionary produces an error:

http://en.wiktionary.org/w/index.php?search=⺒&title=Special%3ASearch

They should at least be getting referred to the main equivalent character (I forget what Unicode calls these equivalency referrals).

But an issue is that — in the interest of being exceedingly detailed-oriented and exactingly Unicode-correct — perhaps Wiktionary should be using these "Radical" characters themselves in articles when discussing a character-as-radical, in contrast to using the main character when discussing the character-as-character. Unless (like some other Unicode blocks) it's been decided, officially or in general best practices, to deprecate the Unicode Radicals blocks (as they lack many of the variant radical forms needed anyway). All that is a discussion for the Beer Parlour not here, but may inform your opinion of what should be happening with the Unicode Radicals informatically.

Thanks HanEditor (talk) 10:11, 9 August 2013 (UTC)

I don't think they should be used at all. Most Chinese fonts do not contain these characters, so all users will see is boxes, which isn't really helpful. We should probably have redirects from the Kangxi Radicals to the equivalent character from the CJK block though.
As for the search, that is a known defect. We will supposedly be getting a better search soon, but who knows when that will be. -- Liliana • 11:59, 9 August 2013 (UTC)

help with lua[edit]

I was wondering if I could bother someone to help me with Module:ja. In the function kana_to_romaji, it fails to transliterate the character ッ properly when it is the first character, e.g. at 物質. I want to know which entries currently do that, perhaps by the module throwing an error whenever it returns text that contains ッ. I tried to do it myself but my code just threw an error in every case. Ideally the ッ character (or its counterpart っ in hiragana) should just be ignored when it is the first or last character, but I was hoping there was some way I could know about when that happened. Any help would be much appreciated. --Haplology (talk) 15:56, 9 August 2013 (UTC)

I looked at the module, but there is no documentation of how it works anywhere, or even any comments in the code to describe the purpose of each part. That makes it very hard for me to understand what's going on, let alone what's going wrong. Someone would need to know what each part is supposed to do, first, before they can figure out where/why it's not doing what it's supposed to. —CodeCa t 16:11, 9 August 2013 (UTC)

Fixed I think. --Z 21:26, 9 August 2013 (UTC)

Thanks! I decided to keep the existing function for the case of when the ッ character came first, and commented out the line that (I think) does that. Sorry I misspoke before. When it comes last, it should definitely be dropped and now it does that correctly. Thanks for the help! --Haplology (talk) 02:53, 10 August 2013 (UTC)

You are receiving this email because you subscribed to this feed at blogtrottr.com.

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

Wealth Maker

Friday, August 9, 2013

Wiktionary - Recent changes [en]: Wiktionary:Grease pit/2013/August