User talk:Yair rand/LQT archive

This talk page uses the LiquidThreads discussion system.

Archive

Namespace listing on search page

Hi, is there any chance you could have look at [[WT:GP#Namespaces listing on search page]], please? Your expertise is needed.​—msh210℠ (talk) 18:50, 15 January 2012 (UTC)

Proposal to de-sysop/de-checkuser Connel MacKenzie

Since you participated in the the 2012 vote to de-sysop and de-checkuser Connel MacKenzie, you may wish to participate in the current discussion of this proposal. Cheers! bd2412 T 17:01, 7 April 2015 (UTC)

Hi,

I'm investigating a series of PHP errors that appear to have been triggered during one or more attempts to upload commons:Data:Requests_for_WMF_user_data.tab. It seems that you ran into a data format validation bug in the JsonConfig extension, but I'm not sure precisely how to reproduce it. Did you need to make any adjustments to the data blob in order to get the data uploaded? If so, can you tell me what they were?

Thank you!

I was trying to add this to my watchlist, User:Yair_rand/interwikiwatchlist.js does it still work/am I doing something wrong w/ respect to enabling it? thanks--Ozzie10aaaa (talk) 17:01, 26 March 2018 (UTC)

As you can see in the history, I tried adding a pronunciation at turboloads several times and altho the audio recorded, it did not end up uploading to Commons and actually saving the .ogg file anywhere. I'm using Firefox 57. Do you have any suggestions?

Hm, looks like something's broken with the uploading system. I'll try and see what's up.

Thanks man. Let me know--I'm very excited about this feature. This is honestly a game-changing script.

Hi, Can you explain how to use User:Yair_rand/AddAudio.js ? I copied it to my common.js , and I get an error:

  (unknown) JavaScript parse error: Parse error: Unexpected token; token 3 expected in file 'User:Shavtay/common.js' on line 344

Looking at the code , it is the line:

 document.body.style.cursor = ;

Thanks a lot.

Hm, maybe try using it via WT:PREFS? It's the fourth option from the bottom in the experimental section.

Hello, I have exported the Conrad.Irwin/editor.js to the bg.wiktionary.org. Unfortunately I have a problem with the "Translation table header lacks gloss". If I add a gloss to the template, the whole templatebecomes smaller like that and I can't reedit it by clicking on the + (its says no translations table found). I can't figure it out what the problem might be. Can you please help me solve this.

As a participant in an associated discussion, you are invited to contribute to the list of terms and criteria at Appendix:Terms considered difficult or impossible to translate into English.

Cheers,

I had an idea for tabbed languages and was wondering what you'd think. What if made the TOC two columns. The languages would be listed on left and the subsections of the selected language would be displayed on the right (changing when someone selected a different language from the left). This would utilize some blank space and shift content up a bit on some pages. Thoughts?

I'm not really sure what you mean. Would the tabs still exist? Would the TOC be in the same style it is now, non-floating top-left position?

I was thinking something like User:Bequw/template. The languages would be "tabs" in the ToC. In this setup, yes the ToC is probably best top-left non-floating.

Hmmm... It might be an improvement over the existing system, but it doesn't save all that much space. One still has to scroll down a bunch just to see the first definitions, and there's no easy way to switch from language to language mid page. Also, would the language links in the ToC scroll to the section? If so, I'm not sure how the changing of the "tabs" would be much help. Stacking the language sections in general seems unhelpful.

I've been working on User:Yair rand/TabbedLanguages.js, a modified version of Atelaes's User:Atelaes/TabbedLanguages.js (available in prefs right under the original), and I think that it would work better than a simple section stacking system.

Here is my two cents. Look at [1] this is a template which supports wiki content localization and therefore offers language selection. Although it is unsuitable the UI could be useful as a basis for tabbed navigation.

Also what I think is missing from most implementations is the ability to select/deselect and remember a user language view preferences. Which works nicely in the translation editor.

"let's roll" is a bit mangled with the TabbedLanguages gadget enabled. Maybe it's because of the apostrophe? Also, in case you haven't seen it, I posted some feature ideas based on an independent implementation I wrote for the Vietnamese Wiktionary.

Not sure what's up with that entry, but it wasn't an issue with TabbedLanguages. Turning off TL resulted in the same malformed page. Purging the page seems to have fixed whatever was wrong.

Ah, thanks!

Are there any still-functional scripts that keep using them? I already switched WT:EDIT to use Module:JSON data. It seems to work, although it feels kind of sluggish. Any suggestions for improvements?

Using JSON_data, it's slow enough as to be no longer helpful, and I can't think of any way to sufficiently speed it up. Lua simply doesn't have the ability to conduct that kind of search on a large collection of strings efficiently. (Also, something tells me that some people might not be so enthusiastic about the possibility of such a heavy module being parsed on every keystroke.)

My recommendation is to give up on transitioning WT:EDIT's autocomplete away from the otherwise-obsolete langrev templates, despite the issues regarding the data becoming out of date.

Oh, and to answer the first question: User:Yair rand/TabbedLanguages2.js, which is loaded for some users by a button setup in MediaWiki:Gadget-legacy.js, uses the langrev subpages for language name autocomplete in a little-used and buggy feature used to add new language sections. That version of TabbedLanguages is going to be replaced with the gadget code as soon as I get around to it, and eventually deleted entirely if we ever get the gadget enabled by default, so I wouldn't consider that an obstacle.

Well, I do not want to give up so easily.

I managed to speed it up a bit by adding some simple caching. The subjective responsiveness was comparable, despite the requests taking three times as long (with the majority of the time apparently spent executing the Lua code). Not sure if it helps. I think some caching on the server side would.

(I have also tried the scribunto-console API just out of curiosity; the overhead seems comparable, and often worse.)

I also thought about creating a JS library which would manage a much more sophisticated cache of language data and various code-name mappings. It would be a longer-term project, though.

We encountered a problem in the german wiktionary. It seems to be related to the new mediawiki softwareversion installed tonight. The problem is, that if you enter a non existing pagename in a rhyme page using your rhymeeditor this pagename is created as an empty page. I just tested if this also happens in the english wiktionary, because we ported the rhymeeditor from here. I found you have the same problems. It might be a change in the api, so that the rhymeeditor has to be fixed. But i didnt figured this out yet.

I fixed this in the german wiktionary by inserting some code to test if a page exists.

... JsMwApi().page(values.rhyme).edit(
 function(text, saveFunction, editRes){

  if(editRes.query.pages.hasOwnProperty("-1")) {
   document.body.style.cursor= --numberOfRhymesAdded ? 'wait' : '';
   return;
  }

 var langcode = setUpRhymeAdder.langCode || (new LangMetadata()).cleanLangCode(langname), ...
--Formatierer (talk) 17:29, 13 August 2014 (UTC)

Should be fixed now, but I haven't tested it. Thank you for pointing out the bug.

Just for your interest: this change brought the bug into effect.

Are you still intending to use this, or can it be deleted?

Deleted.

hello
could you help us to creat the[1] as like as the template that exists in this page[2] I mean the box that name is جمهوری اسلامی ایران me and my other lur friends with your help want to make this tempalate in luri language please help us we translate the words of this template in luri lrc
and these changes are made: to your wiki. For this, make these changes:

w:fa:MediaWiki:Common.css → MediaWiki:Wp/lrc/Common.css

w:fa:MediaWiki:Common.js → MediaWiki:Wp/lrc/Common.js

w:fa:MediaWiki:Vector.css → MediaWiki:Wp/lrc/Vector.css

please help use to create this template in luri language
best regards

I'm sorry, I'm not an admin at the Incubator, so I'm not able to make these changes. I recommend asking for help at the Incubator Community Portal.

For some reason, at [[γ]] the Translingual categories still show up in the Greek tab. Can you investigate why? Also, the gadget tends to interact funnily with AJAX preview (I think it sometimes even prevents it from working altogether; it often falls back to plain preview)

I also thought about fixing up section links in definitions to point to English inside TL (since this is an issue primarily for TL users anyway).

Also, you might want to have a look at MutationObserver. I used it in User:Kephir/gadgets/nectie.js, which may also interest you.

[[γ]] is broken because it is miscategorized. Letters of a script are supposed to have "Category:X script characters", not "Category:X script". Apparently all the Greek characters are similarly miscategorized. This isn't related to the rewrite; those entries were having their categories misplaced before as well.

Regarding AJAX preview: I've fixed the issue that was causing the language tab buttons to malfunction. I haven't noticed any other issues.

I've actually used MutationObservers before, but I didn't know that they could be used to detect when new elements are loaded onto the page. Fascinating. I've changed the script to use those instead. Thanks.

I notice that you changed MediaWiki:Gadgets-definition so that TL isn't loaded from the top, with the summary "seems to cause problems". Which problems specifically are you referring to? As you probably gathered, having the script run before/while the content loads was the entire point of the rewrite, so fixing the issues blocking top-position deployment are high priority for this script.

"TypeError: bodyContent is undefined". I think you might have already fixed it, though.

As for categories… I looked at the script and I cannot gather why sortCats() is supposed to work in the first place. Can you explain the intent behind it to me?

The miscategorisation was done by {{Greek character info}} and ultimately {{character info}}, of which I just edited the former; I could also "fix" it by replacing it with {{character info/new}} which currently does not apply any categories at all. Not sure what should be done about it, really.

I'm not sure what you mean by the intent regarding sortCats... The function goes through the categories placing them into language sections, moving on to the next language section if the category name begins with the name of the next section's language, except if the category also matches /letter\snames$|script\scharacters$|mythology$/, which, afaik, covers all the exception categories that start with language names without being related to the language. (Example: "Category:Greek script characters" begins with "Greek" but doesn't indicate the start of a Greek section.)

…and the categories are guaranteed to be in the order in which they are rendered on the page? In that case, I need no further explanation.

I fixed one bug that was causing a "TypeError: bodyContent is undefined" within ten minutes of the original deployment. Is it possible that this was the bug you saw? If so, any objections to re-adding [top]?

No, I think we can re-enable it now.

Hmm, there still seem to be some funky interactions between this rewrite and live preview. It looks like the JavaScript does not even run sometimes.

I suggest you better revert to the old version, develop the rewrite in WT:JSSAND (install w:User:Kephir/gadgets/jssand.js beforehand) or as a browser user script, test it thoroughly and then deploy.

Hi,

Can this be added? Could you help me please?

   noun:ru-noun (genders: m-an, m-in, f-an, f-in, n-an, n-in, m-an-p, m-in-p, , f-an-p, f-in-p, n-an-p, n-in-p, p;
   adjective: ru-adj
   verb: ru-verb
   verb: ru-adv

What should the text displayed in the buttons for the noun genders be, and what wikicode should each of them output?

Oops, sorry, I missed your answer (never got used to liquid threads :) ) I don't understand your question.

Let me try:

m-an - masculine animate f-in - feminine inanimate, etc.

The rest must be straightforward.

So, there would be one button saying "masculine animate" which would produce the wikitext "|2=m-an"? Or "||m-an"?

Also, is "n" neuter? And what would be the text for the "-p" options?

I don't quite understand the usage of numbers here but m stands for masculine, f for feminine, n for neuter, an for animate, in for inanimate, p for plural (with nothing else). They can be used in any combination (like with other languages). p may appear on its own when gender or animacy is not known or not important. There can be nouns with more than one gender in the header.

Verbs can be impf - "imperfective", pf - "perfective", the other equivalent is usually provided, e.g. скрести. These two parameters and all genders are valid to all Slavic languages, although animacy may not be important for some genders in some Slavic languages, it is used for consistency and doesn't cause errors in Slavic languages. @CodeCat may give you some hints on gender handling modules. So, if you make it for Russian it can be copy-pasted for all Slavic languages but Serbo-Croatian uses different formats for imperfective/perfective.

Now, an important question, how do I enable it (apart from having it in User:Atitarev/common.js and hard-refreshing) and use this tool. Say, I want to create аадсфсдфзфздффгд?

User:Clyde is developing a template for Uralic that seems to fulfill the same purpose as this. As they're new to Wiktionary, could you show them how to use Template:etymtree instead?

It might also be good to add more documentation on how to create new trees. Currently it only tells you how to use information from an existing tree.

How does changing ".innerHTML = .innerHTML + ..." to ".innerHTML += ..." fix anything? For all I know, JavaScript treats these two as equivalent (and if it does not, this language is even more fucked up than I thought): the DOM is still being thrashed, and event handlers forgotten (which is why the radio buttons do not disappear and reappear properly after that script fires). You should probably avoid innerHTML entirely, and just use document.createElement/.createTextNode and appendChild. (Though there is also insertAdjacentHTML, but I am not sure how widely it is supported.)

Also, I have read somewhere that addOnloadHook is deprecated, but I am not sure what the replacement should be.

You're completely right on all points. I've changed the script to use the normal DOM methods instead of modifying innerHTML.

The replacement for addOnloadHook is $(document).ready.

Why not use it, then? We never know what is going to bite us next.

Hello Yair, your input is needed at WT:GP#Diff radio buttons on history pages. Any help would be appreciated!

Thanks for asking. I have deleted the custom JS and CSS that I had in the vain hope that it would help.

I have the following gadgets selected:

1. *** Navigation popups
2. ** ToC right
3. Box for blocked users
4. Sidebar wikis to English
5. Disable targeted translations
6. Regular expressions
7. * Accelerated creation of inflected forms
8. Disable rhymes editor
9. ** Patrolling enhancements

The *s indicate items that I value highly.

The regex gadget has never worked for me.

Other problems I have include the non-display of the controls that allow display of quotations, translations, rel-top items.

I should also check my per-browser items.

On per-browser preferences (not relevant for library problem) I have selected:

1. X Special character input for search
2. X Links to previous and next entries
3. Language to ISO converter
4. Archive links to BP
5. Orange translation links
6. Orange language section links
7. others

Another non-functioning thing is the set of special characters appearing under the edit box. Several character sets appear, but I have to copy and paste rather than just click as formerly.

The hypothesis I've heard is that all of this is do to a "race condition", but that can't be right as some of my best friends are non-Caucasian ;-|}.

Please ask me whatever questions would help in diagnosis. My problems in principal namespace are quite intermittent. I can hope that fixing the persistent problem will fix or improve the harder-to-diagnose intermittent problems.

Persistent problems are:

1. The non-display of the {{rel-top}} "show" control on User:DCDuring.
2. The failure of the special character functionality under my edit window.
3. The non-appearance of the regex option.
4. The non-appearance of the special character option under the search box.

Okay, two bugs fixed:

• The "Show a special character input (like the one beneath the edit field) for the search field" pref hadn't been switched to use protocol-relative urls, so the recent-ish switch to https:// broke it.
• The sidebar wikis to English gadget wasn't working well with some of the slight changes in monobook that happened a while ago. This is probably what was breaking the main JS.

Some of the gadgets are in serious need of cleanup...

How many of the problems you listed are still occurring?

The most annoying persistent problems were on my user page. I think they are fixed. I guessed that nested {{rel-top}} was a possible problem and that few others have used it on a large page so such a problem might be peculiar to me. I eliminated that and eliminated some other things and the problem went away. I will trying adding back the other things to see whether they might have been the cause.

[I just realized that it may have been your changes not mine that fixed my user page.]

The special characters below both the edit and search windows and the regex are back.

Thanks for giving this your attention and for actually succeeding in fixing it (at least apparently !!!).

I will let you know if I come across any of the other problems or if anything recurs.

I guess rarely selected and used options are somewhat likely to become problems as things change.

Everything important seems fine. But I don't think that the next-/previous-entry link thing ever worked for me. What is supposed to appear where on the screen?

Some users have suggested minor improvements to FindTrans.js here which you might want to look at. Thanks

Thanks for pointing this out.

Instead of showing all the descendants in one big tree, would it be possible to hide descendants of each branch like we do now, but show a button (like for quotations) that lets the user view the descendants of that branch? Perhaps it should only be hidden once the number passes a certain limit, like say 4.

Certainly possible, but why would that be useful?

It would make the list a bit shorter and easier to oversee. Someone who is interested in Latin won't need to scroll past Germanic first.