User talk:Anton Latukha

From ArchWiki
(Redirected from User talk:PiroXiline)
Jump to: navigation, search

Bots

Hi,

if you are interested in bots, have a look at User:Lahwaacz/ArchWiki:Bots (a draft for the future ArchWiki:Bots page). There is not much content yet, but the links might be interesting for you.

To answer some questions on your user page:

  • There is no server-side bot on ArchWiki, all bots are started manually in random intervals. Wikipedia has some continuously running bots, so the idea is not crazy. -- Lahwaacz (talk) 15:37, 12 September 2016 (UTC)
Yes, I just thought there are many style points, and handy ideas that can be automatically parsed on server side. Just create a parsing rules. There is only one problem of the unknown innerworks of MediaWiki (for me). Start with simple and dumb things, and as process goes, everyone going to understand and become confident, and writing new rules can become standard process. Testing, and then applying. You have some sort of test server? Testing can be done simply on parsing some closed test filled section of running wiki. PiroXiline (talk) 18:39, 12 September 2016 (UTC)
I have a MediaWiki instance installed on localhost for testing, see User:Lahwaacz/LocalArchWiki if you are interested in details. As for the style rules checking, there is an open issue for which I have too little time. -- Lahwaacz (talk) 19:07, 12 September 2016 (UTC)
  • The <br> tags cannot be replaced automatically because there is no way to tell if it was added intentionally or not. Even if the lists were the only problem, it would be hard because parsing lists and tags correctly is very difficult. -- Lahwaacz (talk) 15:37, 12 September 2016 (UTC)
Thanks. I can live without that br idea )) PiroXiline (talk) 18:39, 12 September 2016 (UTC)
But really, I thought. Kate accomplished highlight very precisely. {{Tags work right, any lists right, any mix I saw was right. Even your "The <br>" it highlights <<nowiki> : I tried to find their highlighting sources already, while researching colouring of output (wanted to see what and how they use in such great highlight for everything), but not saw at first glance. They changed old process of committing highlights that googles well. Somewhere today I found a page where they pointed how to do it. But I went off. : I mean to highlight, they need to parse it in the first place. - ~~~~ : As I said, other way, Atom package translation from Mac - not worked completely. But it is on github. - ~~~~ * [[Help:Style#Code formatting]] says that "^ " is for simple one-liners and <nowiki>{{bc}} for multi-line code blocks.

I hope you find the other answers soon!

-- Lahwaacz (talk) 15:37, 12 September 2016 (UTC)

Thank you.
  • No need to correct my userpage Notes section typos, there can be complete scrambles, not covered with tags and very messy. From today I use that section to not to forget things, ideas as I go.
  • I do not know innerworks of ArchWiki workflow on level needed now, in what pages what suggestions proper to post (because I do not know what pages exist for that), what you, admins track.
For now I see many fit in /Style
<Offtopic>
I learn to use best tools that do proper one thing. Bookmarks are to store permanently interesting sites. Onetab extension to temporarily offload interesting to process sites, pocket to read it later and so on. Extensive folder structure to sort thing. And so on.
And also then I gradually going to formulate/research questions, iterating and evolution create shapes.
And then make all the prettiness.
And then post to proper section.
  • Now I moved to Kate anyway, there is very pretty highlighting. And not to flood with commits. And to go underwater ))
  • If there was inline editor with MediaWiki markup (so you simultaneously see all the text with the markup in dynamic HTML mode, see Abricotine for Markdown to understand).
It going to be waay better for all world. It would speed-up writing and make cozy to work with markup of any wiki articles dramatically.
And there is no such now. I looked. There are wikED, and in Atom some port from Mac of MediaWiki markup, which not work properly and abandoned (3 commits) long time ago. PiroXiline (talk) 18:39, 12 September 2016 (UTC)
As you will maybe find out, the MediaWiki markup language is very difficult and anoying to work with from programs. That's why there are so few visual editors, and most of them have many bugs or even conflict with ArchWiki's style guidelines. We also cannot hope in any development of the language, by now it is practically a dead language. It was developed for Wikipedia and aims for maximum backwards compatibility. Wikipedia has about 15 years of history, which is many hundreds of terabytes of data, so the language cannot be changed easily. For now you can enable "Use live preview" in the preferences, and there are probably some userscripts to have syntax highlighting in the browser. -- Lahwaacz (talk) 19:21, 12 September 2016 (UTC)
Yeah. It has it's limits. But it is not true that all dead. Maybe current language is dead.
But wikis is too important to the world.
There going to be a raise of questions, problems arise.
Someone creates new language. New concepts.
And of course they are going to be convertion, translators to new language or platform.
The main thing is, the info is here.
Than tool going to be developed to translate everything to new stage. Maybe in one solid snapshot. There is no other way. Noone going to start from scratch to gather all that info that was done worldwide by all people. - PiroXiline (talk) 20:10, 12 September 2016 (UTC)
  • Dressed ArchWiki in dark mode using your user script feature. In most popular "Archlinux and ArchAssault Dark" official homepage everything works very smoothly. I do not know why there no single official ArchWiki dark skin. So pleasant to look and work here in dark mode. Or at least suggest one for everyone )
And as wiki-side script - uniplatform. My Arch, Chrome, Fox, Android, everything ticks as a clock.
But wikED edit window looks crazy white now. Kate better anyway for me. Emacs, still lose myself there.
In skin all works, I only nitpick that Show Changes mark text of changes in grey on light blue, not very contrasting colors. But it must be one touch to script.
But I deliberately chose very hard, almost impossible topic. I make research on my own.
I figured-out how everything works together, and how properly divide all terms from each other.
But there is Xresourses, VT types, ncurses library, TERMCAP, escape codes. Is where I need to dig in. Started a little on theory today, offline.
  • I going to go full freelance on some nearest day, so my work on wiki going to slow.
  • Thinking in what way to contribute not only with ideas.
But building new references, style guide references. Nitpicking of contradictions also helps.
The main point I understand. Only some of my style ideas need really to be forced in rules on users. There is too much of everything already. We need try to ease start even more. There is around 10 long articles you need to read to make something good and to understand things.
I understand that my language need to be in the Wu wei manner. To introduce and to explain why doing this way is great. Like RFC-s work in the Wu wei manner. To explain, to recommend. And to start a trends.
  • I installed Wiki Monkey today, but not understanded it for now. Because not used.
  • I want to create messy and less messy notes and then say Butt! to him. And look what he do, and what I can do ))
Your answers are very helpful. They shorten the circuit of research. -- PiroXiline (talk)

Idea about interlinks

Listen everyone. I have an idea. ))

I know I am not the first one. I remember when nonexistent titles was broadly used.

It was a long-long time ago. Maybe technology, wiki engine and critical mass of IT professionals ready to make quantum leap again.

Distributed version control and all open source with it did a great step with changing to Github concept.

But really, with little automation by templates we can exploit MediaWiki in our favor. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

Algorithm

  1. It is sane to forbid creation of links to non-existent titles. Because it is like winning a lottery, probability to shoot a target in the future is tiny.
  2. If you want to reference or show something:
    1. Find and make a link to the Archwiki subsection if it illustrates topic.
    2. Find other source of information.
      1. Try to search authoritative source.
        1. For basic information
          1. Official site. Make external link.
          2. Wiki in the project Github repository. Make external link.
        2. For detailed technical information
          1. Special wiki. Make MW:Help:Interwiki_linking.
          2. Special Wikipedia articles. Make MW:Interwiki_linking
        3. Other very-very great source:
          1. Great forum post
          2. Bug report on Arch Bug or Github, or on official Bug tracker. Relatively to scope.
      2. And add short main info to where you write (like name of package pacman).

- PiroXiline (talk) 18:58, 10 September 2016 (UTC)

Maybe we can put this checklist in one of our existing articles? — Kynikos (talk) 02:43, 11 September 2016 (UTC)
That is why I try to write sections in this structured manner.
I clearly see that link posting can be described in one algorithm.
But it better be placed as help, guidence, reference. Not rule. ArchWiki overburden with rule threshold to newcomer. Anyway people going to love to use a good help-checklist.
I think checklist needs more thought, research and incremental work before placing. -- PiroXiline (talk) 18:07, 22 September 2016 (UTC)

Exception

  1. If you saw resources and now see that topic needs as a more technical explanation, Archlinux scope, like ghb:
    1. Only one exception here is real and be practical.
      1. If the name of a link to non-existent article is one strict word like "Kate" (remark: most (95%) of List_of_applications are one word names). (maybe someday ease restriction on strict well-known or popular names like Open Shot, KDE Connect)
      2. Than make a link named Name of article to non-existent article.

This can be automatically controlled by bot. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

How do you define "strict well-known or popular names" without generating controversy? – Kynikos (talk) 02:51, 11 September 2016 (UTC)
Here is my thoughts about that:

Strict well-known or popular names, acronyms

  1. Names of core utilities, GNU projects.
  2. Acronyms of protocols, standards widely adopted in their fields.
  3. If name is literal name of man page. Or man(1) redirects name as alias to another man.
  4. If name is literal name of package (or meta) in Core, Extra, Community package in Arch Linux. (as you know Core, Extra and Community have one shared namespace)
Also maybe:
Acronyms overall.
With checklist from comment points:
Comments:
Acronyms & single-word names.
Acronyms have plural meaning over the world.
But almost absolutely all acronyms have one meaning on ArchWiki:
  1. People understand scope, context and filter-out what is meant. So, say people can filter-out 1/10 of acronym meaning here.
  2. Roughly half if not greater of what's left is software development related (not ArchWiki scope).
    1. Devs world love invent bicycles in the first place.
    2. Than goes love to loudly Name every sneeze now.
      1. Because of branding. To serve food on the table, and some want huge money. Every new small is called 'technology' (like in Microsoft) and have name. Frameworks. Development concepts, patterns. Languages with their different and excessive terminology to everything.
        All that mostly not touch ArchWiki.
    3. ArchWiki is really not a place where devs would post software development in detail articles. It is not a place. It is a place for ArchWiki admins, and maybe Arch devs.
      In other words: only major dev acronyms used and all other are relatively very rarely and specifically used on ArchWiki.
    4. StackOverflow launched technical documentation initiative.
      So that all goes out of the way. (1/2)
  3. Most of acronyms, thank God, have one sense in Open Source perspective. Proprietary terms used rarely on ArchWiki. (1/2 of acronyms)
  4. Than this all, in our case, is filtered by *nix perspective (Win, Mac, IOS, Android is important topics on ArchWiki, but I point out - that not excessively and majorly used, covered). (1/2)
  5. Half of what left is Linux related. Portion of Mac OS X and BSD goes away (say 3/4 of acronyms stays).
  6. ArchWiki is a narrow platform for more administration, architecture Linux topics. Revolving around Arch. If I can say Arch Linux 'management' wiki. And then many acronyms (example, of other distributions, many of kernel insides related) fall-off in Arch Linux perspective. (say 4/5 of acronyms left)
  7. Let also remember, not every acronym really need ArchWiki reference page. Many of acronyms are too small in info or scope that they does not sanely require any reference to other ArchWiki place, many discussed internally and mostly in specific-to them articles. (like java terms). So if needed, contributer can provide direct link to that ArchWiki article section (as all works now), or person going to search related article by himself. (say, 3/4 of terms stay)
Note: All that also goes to single-word names. Maybe change word acronym to single-word name and include acronym term into single-word name.
So we have estimation:
1*(1/10)*(1/2)*(1/2)*(1/2)*(3/4)*(4/5)*(3/4) = 0.005625
Probability that acronym going to really, seriously coincide is 0.006 in an reference article. I think we can live with 0.6% references not showing us to proper place. But in return we have a huge gain of cross-referencing and condensing of information.
From the top of the head example: DRM - Digital Rights Management and Direct Rendering Manager. What you think is going to be pointed on ArchWiki reference page? There is no sense to create Digital Rights Management info stash in ArchWiki it is very fragmented theme in ArchWiki scope. And then DRM is logically always points to external link, or proper place on ArchWiki for that product/format. So obviously we discuss Direct Rendering Manager here. And reference [[DRM]] is also a bad reference page now. Because it covered in ATI, NVIDIA, Intel. And that is why [[DRM]] if become, will become a sort of for term reference and disambiguation page.
So we can safely adopt acronyms in Arch Linux always have one meaning. -- PiroXiline (talk) 16:58, 22 September 2016 (UTC)
I'm lost, this all started because you were proposing to allow red links in some cases, right? Then I asked you to define "strict well-known or popular names" objectively (especially the emphasized adjectives), and you wrote another essay on the meaning of "acronym"? How did we even get there? You seem to have very elaborate ideas, but you should focus on explaining them in a more exact way, getting to the point without digressing to loosely related matters...
Kynikos (talk) 14:20, 23 September 2016 (UTC)
Yes. First list says what safely can be allowed.
Than I go into thought estimation details. Looking at a question, how many same acronyms (or single-word names), but with different meaning, collide on ArchWiki. Like DRM example.
-- PiroXiline (talk) 23:45, 23 September 2016 (UTC)
Please note that Simplicity is one of the founding philosophies of our community: this usually also means that if something is very complicated to implement, with many exceptions and special cases, then maybe it's the implementation itself that should be rethought; in this case you would like red links allowed for some cases, but defining these cases requires paragraphs over paragraphs of rules apparently... Maybe this Simply means that disallowing red links altogether as it is now is the best idea after all?
Kynikos (talk) 14:20, 23 September 2016 (UTC)
Yeah. I proposed and wrote a lot of stuff. This is the biggest complex idea. That is why I'm proposing to move all of this idea to my talk page. It is very multipart. Maybe I can chip-out simple and useful thing, and propose them one by one.
I also agree sometimes I go into very details of explanation. Because I want to be sure that what I wrote is explained, understandable and has some ground.
You have a point about complexity and rethought process. I thought to leverage a community, so ideas start to evolve and take shape. And forbidding red links is a simple and effective solution now.
-- PiroXiline (talk)

Automatic control of exception by Bot

  1. If new commit was done
    1. Check if in additional content is a link to nonexistent article
      1. If name of that article is more that one word
        1. Strip linkage. Add quotes. If before link word 'see' or 'look' or 'look at' was used - change that to 'search for'.

So any new links to nonexistent articles going to be stripped. And we require them be in Name of article. So text leaved untouched. Example: For troubleshooting this, see Extensive debugging, converts to, For troubleshooting this, search for Extensive debugging. You make a troubleshooting research and search word encourage you to search for that term and also leaves a feeling that you need to make a link to useful information there for other people after you. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

Change Template for empty page

If human opens an empty page, today template says to him:

There is currently no text in this page. You can search for this page title in other pages, search the related logs, or edit this page.

If we can change massage of that template:

Here is currently no such article.

You can:

Logs in last place, because average user does not know what is that. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

I get a different message when opening a non-existing page, specifically MediaWiki:Newarticletext. Anyway expanding it could be a good idea. – Kynikos (talk) 02:50, 11 September 2016 (UTC)

Automation and process of one-word article redirect creation

If Create a redirect is hit - edit opens automatically with Redirect template, search title already placed inside. There an example stub link that introduces to place a proper redirect link to internal Archwiki page.

Individual leaves this tab open. He found no information there, and he is ready to contribute, because he researching this topic now anyway.

He continue his searches on wiki (maybe he already know where to find, because he researching topic now, or he know wiki well, and just checked, maybe article exists).

If he finds a source, it places link. He needs to make a preview of all that and make submit.

Comment section can be generated automatically or filled with standard message. If decided Going Commando auto-interlinking. Or individual needs to write a message. This is more protection-wise approach.

So many referencing articles going to be created. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

This is not very clear: are you suggesting to pre-populate new pages with some content derived from the title? – Kynikos (talk) 02:56, 11 September 2016 (UTC)
If it happen, it going to be great to pre-populate new page with {{Redirect|Target article|reason}} template.
So Target article is: Place proper internal name to article/section here, like 'Help:Editing#Internal_links' see Help:Editing#Internal_links and Template:Redirect.
And MAYBE reason is: Place a proper explanation why this page internally linked to that place. But I do not think exquisite reason is needed.
Better let contributor provide reason in Summary of commit. Anyway he needs to provide it there. And history of commits of these pages is small and directly show everything. -- PiroXiline (talk) 17:46, 22 September 2016 (UTC)
Why would anyone create a new article and want Template:Redirect put there automatically? And, even if possible to set up, this should happen every time you create a new page? It would be too confusing and complicated, let us close this :) — Kynikos (talk) 14:29, 23 September 2016 (UTC)
I thought we discussed that several weeks ago. It is surprising to see you forgot.
We was talking about creating automatic redirects for simple terms, names of apps, technologies, acronyms, so it is going to focus people attention and effort on sections about that terms.
I suggested. While human goes to new (not created) page to add [[Create redirect to ArchWiki secton], so that ease for people to create a redirect to proper place on wiki. So people after that going to be streamed there.
I not said anywhere that 'this should happen every time you create a new page'. I wrote 'If Create a redirect is hit (on a new page)'. And we discussing that here.
So I do not know why you closed this. And I see, as all others with fresh energy that came and faded-out, I get undermotivated with things like this. -- PiroXiline (talk) 23:25, 23 September 2016 (UTC)

Improved Archwiki interlinkage concept

That going to greatly improve Archwiki interlinkage. People will create interconnects by themselves. And fix broken links by themselves.

But now simply saying Kate. And redirect going to point to List_of_applications/Documents

If someone finds, makes a better description of Kate cheats - link will be switched there by people.

Someone writes KDE Connect. Than he himself or someone goes to that link, and creates a reference to KDE#Integrate_Android subsection. Where is appropriate to explain what is KDE Connect and point package, AUR, to official site.

So now we do not need to every time on every mention explain what is gdb and where information about it, because GDB points to Step-by-step_debugging_guide#Gdb. And we make there a base of GDB knowledge, extensive overwriting make it a bigger section over time, links to external resources emerge, coverage of more cases with gdb. Which improves bug reporting to Archlinux and to all open source.

If someone moves Step-by-step_debugging_guide#Gdb elsewhere, people, or human who moved it going to link it right again, he probably researched and saw that GDB points there.

And when information ob GDB grows - it becomes real GDB article. And individual who creates it going to delete Redirect in GDB. And now, all GDB links points to GDB article. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

This is not very clear: are you suggesting to create more redirects to existing article sections? We are already encouraging that :) — Kynikos (talk) 02:58, 11 September 2016 (UTC)

Conditions

So all this works in conditions:

  1. By protecting all this with strict restrictions on links to non-existent articles with #Algorithm.
  2. #Exception only to one word links.
  3. Automate a bot to strip others.
  4. Adding a redirect feature to template of non-existent pages.
  5. Trend starts automatically.

I need to point out in Help:Editing#Internal_links from main page, nonexistent links encouraged already for a long time and no one goes mad. So this #Algorithm is a clean-up and clearing out and protection. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

Since a system like this, even if approved, would take time to be implemented, I have fixed the inconsistency from #Sentences about non-existent articles contradict each-other for the moment. – Kynikos (talk) 01:53, 11 September 2016 (UTC)

Results

Because now Archwiki ask, and make link it is simple, take a one click. People going to start make links from nonexistent pages to according information on Archwiki.

All this automatically create all single-word links and point them to information.

What needs to be addressed:

  1. Make automation. Tweak templates and bot.
  2. Clearly explain, how to go to edit mode if page is reference. So people can delete reference. Or make this feature.
  3. We have many new little pages and engine makes references.
  4. Articles going to become more atomic. It is very great, but also that mean more linkage and more articles.
  5. If link in reference is not satisfiable - you need go to search page. Big deal.

So these are benefits:

  1. People automatically start creating one-word articles, linking them to proper Archwiki subsections.
  2. People automatically fix broken links.
  3. People see that one-word links is a trend - start generating one word nonexistent links. Which boosts point 1.
  4. All-around interlinkage of wiki improves greatly.
  5. Links focus people effort in one place. So while topic gets critical mass - article spawns.
  6. Every link automatically points to proper article. Both when article created, and people track changes.
  7. Articles going to become more atomic.

What problems do admins see. Archwiki and admins has some experience in this. - PiroXiline (talk) 18:58, 10 September 2016 (UTC)

Idea have a wide spread. Maybe, to we not get lost in miriad of details, I move all that to my talk page. And then find to where is proper to start and publish point-by point. So to build incremental changes and discus them. And point-by point move to the whole picture. -- PiroXiline (talk)

Yes please, it would help a lot if you withdrew this whole discussion to your talk page and only proposed small incremental changes one by one. – Kynikos (talk) 14:31, 23 September 2016 (UTC)