Xyne-related page edits after Powerpill, Bauerbill... discontinuation

Where should translations go?

Hi! I'm wondering where the Archwiki team wants new translations to go? On the page ArchWiki Translation Team I get the feeling that translations should be placed under archlinux.org. At the same time there are national wikis as well, at different stages of development. In my case this is archlinux.se, which only contains a few articles, and is generally lacking links to the main Wiki from what I can see. What is the policy on where to put translations?

Hi and welcome! I'm glad to know that the Swedish website has come back to life :) Since MediaWiki is _not_ designed to handle internationalization (it requires resorting to workarounds like the suffix one we're using here) the ideal goal would be to move each language to its own separate wiki, for ease of maintenance. So, in your case, all Swedish articles should now be moved to wiki.archlinux.se and replaced with interwiki links on at least the English page, e.g. [[sv:Huvudsida]]. -- Kynikos (talk) 15:23, 4 May 2012 (UTC)

Ah, I forgot to mention that if you want to add an interlanguage link to a protected English page, you can just ask on its talk page, and it will be added by one of us admins as soon as possible! -- Kynikos (talk) 15:28, 4 May 2012 (UTC)

On a secondary note - poorly developed regional wikis might work as a black hole for new users (turned off from arch due to lack of documentation) if they do not link to the main wiki for untranslated topics. Ideally they should cover the entire topic tree, and link to the anglish main wiki for untranslated articles. Granted, most potential new users that find a poor regional wiki probably continue searching and eventually find wiki.archlinux.org, but not necessarily all of them.

That's why we must exploit as much as we can the native tool that MediaWiki offers for keeping the various local wikis linked with each other: interlanguage links (example above).

Until the Swedish wiki lacks important articles, at least its Main Page if not also other important articles should instruct Swedish users to search for missing content on the English wiki.

Text shift in discussion answers

I noticed that the discussion pages of the wiki, in order to indicate that the piece of text written actually answers a comment from a guy above, we are using colon to shift our answer. The problem appears on long discussions page (like the beginner guide, I'm coming from), when we answer to answers answering answers...

I think it would be better to use a @name statement: this indicates we are answering directly to the guy whose name is written. And this avoid left space waste (especially on mobile phones, I couldn't even read the whole thread on mine yesterday, because of the so long shift).
-- Wget (talk) 13:10, 5 August 2013 (UTC)

I admit that the @ method wouldn't be such a silly idea, it would work with short discussions, but it wouldn't allow branching out long discussions. On wide screens the "left space waste" is negligible, and on my phones (Android) the browser correctly manages to fit long discussions to the screen width, I don't understand why your phone can't do that ^^

Integrating Google searches into ArchWiki

Re-reading the discussion on my talk page (User_talk:Jstjohn#Unused_redirects) made me think that we should try improving the search functionality of the ArchWiki. Native MediaWiki search is really awful in my experience, and I'm guessing many others feel the same way.

The easiest way to improve it would be to integrate Google search directly into ArchWiki. A brief search on Google led me to [1] and [2], which are two ways to integrate Google search into MediaWiki. Even if those two aren't ideal solutions—I haven't looked at them in-depth—there are likely to be several other ways of integrating Google search into MediaWiki. So consider this a very nascent proposal for extending/improving search quality on ArchWiki without necessarily proposing a certain implementation.

I don't think that we should completely replace native MediaWiki search (yet?); however, integrated Google search would be a very useful alternative search feature that everyone can use.

I don't have a particular preference for one search engine or the other, however extensions can only be installed by the Devs, who have access to the repo, so a bug report should be opened for these things. In particular User:Pierre is the one who takes care of the wiki, and *IIRC* he tends to be against installing new extensions. -- Kynikos (talk) 09:18, 5 December 2013 (UTC)

Crazy idea about interlanguage links

If ParserFunctions extension was installed on ArchWiki, it would be possible to implement an (almost) fully automatic solution to the problem of interlanguage links, similar to mediawiki.org: [3], [4]. I think it would be possible to adjust it to the layout currently used on ArchWiki, so no mass renaming would be required.

Intended layout is that we would have single central template to be used on all pages, similar to Template:i18n, that would include the [[subtag:Page Name]] links for all languages. There would also be checking if the localized page exists (using the #ifexist function from ParserFunctions) to avoid links to non-existent pages.

Manual intervention would still be required in several cases:

the localized article is on external wiki - the link would have to be added manually

I like automatic solutions, I'm sure there are plenty of extensions that make this possible. The current solution is by no means automatic, even considering the Wiki Monkey bot plugin. We should at least have a solution to automatically check all pages on the wiki (or at least some specific namespace). The current solution relies on lists like Special:MostLinkedPages, which tend to overlap, and also in my opinion the plugin does not cover all cases. I already have several ideas on how to improve the algorithm, it's just the matter of putting it "on paper" - I think I'll open an issue about this on github... -- Lahwaacz (talk) 18:54, 9 December 2013 (UTC)

I have written a quite long post about redesigning the bot algorithm, but unfortunately it seems that I can't post it on github because markdown apparently supports only two levels of bullet lists :( -- Lahwaacz (talk) 07:41, 10 December 2013 (UTC)

No worries, we can easily discuss it here, after all we're doing it for this wiki's sake, it's nothing extraneous. Maybe you (or I) can create a bug report with a link to this discussion, just as a reminder for myself. -- Kynikos (talk) 14:35, 10 December 2013 (UTC)

Weird, Wiki Monkey expects to find a link in those list items, so it was just crashing there. From the next release it won't blindly assume there's a link anymore :)

Maybe a category with an empty title was created with a version of MediaWiki that was still allowing it? It's unlikely that they put it there by default for a mechanism that kind of prevents its creation, because other wikis don't have it, e.g. [8].

About the second question, I think you're talking about deleted Categories, not simple pages, as no pages with 0 backlinks appear in Special:MostLinkedPages. Assuming you're talking about Special:MostLinkedCategories then, most (if not all) of the red links that you see there are former "wanted" (not "deleted") categories, which are likely cached in a special database table for which deletion of entries has never been implemented perhaps for the danger of breaking something else? MostLinkedCategories would then query that table without filtering the results with 0 backlinks: I've got no idea why, there could even be no reason at all and it just happens to have been implemented like that, waiting for somebody to submit a patch ;)

Russian table of contents

As I know, your bot must add new categories in it during auto-updates, but it isn't. I've translated List_of_applications/Science: english article has category Mathematics and science, and I've created page with category Mathematics and science (Русский), there was April, 28. Since then that category wasn't added to our TOC. What should I do? -- Kycok (talk) 17:30, 5 May 2014 (UTC)

Thanks a lot for explanation. I think you can move it to the top for those, who'll be searching that information on your page (as me) -- Kycok (talk) 15:41, 6 May 2014 (UTC)

Sorry to jump in, but there is one more thing Kynikos did not mention - when creating a localized category, it will be necessary to also add the interlanguage links into all pages in the "family", as for regular pages.

Wiki Monkey has a plugin for the synchronization of these links, but (with current implementation) it is necessary to create at least the initial connection manually - meaning at least interlink the newly created category with the English category, the bot can do the rest. Kynikos, we should clarify the guidelines for this... recommend creating a bot request?

I did not look for it before, but since the "translating" of categories is the same as for regular pages, this should be enough...

The current implementation of the interlanguage syncing algorithm is rather unfriendly to recommending it, I don't know how to write "interlink the new page with the original both ways, the bot will do the rest" understandably. We might wait for the improvements (the part about watching Special:NewPages) if it is still planned...

MediaWiki and help pages centralization

MediaWiki tries to centralize help pages, many links in the interface now lead to https://mediawiki.org (using Special:MyLanguage from Extension:Translate to detect the language; btw see also [9]). As we do many things differently, I think that we should keep linking to our pages by overriding the new defaults in MediaWiki: namespace.

Thanks for the heads up, I'm not sure yet what to do here, because we do many things differently indeed style-wise, but relying more on the upstream docs for syntax guidelines and generic instructions on how a wiki works could be taken into consideration. I'll have a deeper look into that, and maybe start a discussion somewhere. -- Kynikos (talk) 05:00, 6 July 2014 (UTC)

This query is cluttered with links to AUR packages, most of which go over templates and still there is only one link to the wiki.

There are many links to wiki that should be matched: links to diffs or history, Template:Out of date etc. use full url to talk pages, and there are even links to articles [10] (I bet there are some even in the main namespace). It seems that MediaWiki treats all external links starting with https://wiki.archlinux.org/api.php or https://wiki.archlinux.org/index.php as internal, which is very unfortunate.

I'd even say that every https://wiki.archlinux.org link is ignored: it could be that, in order to indicize the external links, MediaWiki must first process the wiki markup (internal links, interwiki links, transclusions...), so then it has to ignore the urls that point to the wiki itself, otherwise they would be too many (?!?). The only problem is User talk:Karlswab, I can't really explain why its https link is shown... I've tried to reproduce it on User talk:Kynikos.bot but to no avail, really weird. -- Kynikos (talk) 05:52, 7 July 2014 (UTC)

Found it! See [11] and the linked commit. We could submit a feature request to set $wgRegisterInternalExternals to true, but it has been disabled for a reason (at least on bit Wikimedia projects, the 50GB value is too much for Arch wiki). -- Lahwaacz (talk) 08:20, 7 July 2014 (UTC)

Uh good job! However it's not clear whether setting $wgRegisterInternalExternals to true would only record the internal links formatted as external, or all the internal links regardless of their wikitext form. In the latter case, turning it on would be useless as it wouldn't help fixing the wrong-formatted ones.

Then there's still User talk:Karlswab: $wgRegisterInternalExternals was apparently introduced in 1.16.0, which we installed in 2010, however the link in that talk page was added in 2012, so in theory it should have not been recorded...

What we can do:

Ask about the exact functionality of $wgRegisterInternalExternals

Possibly open a bug report to enable it here (still having FS#35545which from now on I will refer to as simply "The Bug" fixed would help)

I'd say that this would definitely affect only the external links (syntax sense). From the quick look at the code, the addExternalLink method is called only from parts of the parser responsible for formatting the external links; then there is addLink for the internal (and interwiki) links. See also [12] which talks specifically about Special:LinkSearch.

About User talk:Karlswab, it is possible that for Arch wiki the $wgRegisterInternalExternals variable was first set to true and later set to default. We could try to find some older links not being registered to confirm this paradox :P

Yeah, you're right, and these two observations put together would also explain why a link to a search like those has been in my public task list for ages, also allowing me in 2012 to do this series of edits with my bot, which was clearly launched on Special:LinkSearch, actually also fixing some wiki.archlinux.org links (some of which I had to revert then, teaching me that links cannot be converted automatically).

I've removed the section in ArchWiki:Contributing for the moment. We could also open the report for $wgRegisterInternalExternals, but I'm not sure how lucky it could be, considering the age of the other open wiki bugs; maybe this one can wait for the resolution of The Bug, which at a certain point we'll probably have to bump somehow, being a very quick fix in practice. This discussion will also remind to re-add the section in ArchWiki:Contributing then.

PS: I'd also be curious to re-save User talk:Karlswab and see if the link in the search really disappears :P

If you think so... I don't have a particular preference, "rosetta" just didn't seem as part of a proper name. -- Lahwaacz (talk) 17:29, 11 July 2014 (UTC)

Uhm when "Rosetta" refers to the famous Stone or things that have a similar function, I've always seen it used uppercase (it's the name of the city where the Stone was found after all). The lowercase version happens to be an Italian compound word (literally "little rose") that apparently made its way into English as well, and I didn't even know. -- Kynikos (talk) 02:50, 12 July 2014 (UTC)

Redirections are visible in search

Hi Kynikos.

I noticed all pages which are redirections to others are visible in search results. For example, search for Android, and you will get Android-sdk and Android as results where Android-sdk points to the main Android article. The same with the VirtualBox article I'm currently maintaining. Virtualbox --> VirtualBox, Installing Arch Linux in VirtualBox --> VirtualBox, VirtualBox Extras --> VirtualBox,... I think such redirections shouldn't appear in search results, like it is on Wikimedia/Wikipedia.

Also, I wonder if the translation titles are really needed in search results too e.g. VirtualBox (简体中文). Why not provide only English versions as result, then if the user wants the translated (and outdated) content, he can click on the links on the left. -- wget (talk) 19:34, 2 August 2014 (UTC)

Ok. but this checkbox should be unchecked by default. -- wget (talk) 23:06, 2 August 2014 (UTC)

There doesn't seem to be an option in the user preferences, and I don't think it's possible to uncheck it globally, see mw:Manual:Configuration settings#Search (and anyway that would require FS#35545 to be fixed). However I'd be against unchecking it by default because if somebody searches for "android sdk" he has to get the redirect as a result, and this is one of the main reasons why we create redirects in the first place.

Now I'm having some doubts while going through a list of talk pages of redirects. There are many talk pages that redirect coherently with their associated page, simple remnants after moving - should they all be deleted? Or at least the (very) old ones, or when the title is completely off? Redirects in the Main namespace are kept as they can be useful for searching, but deleting the redirect talks would actually clear the "duplicate" titles off the search results.

There are also not so many talk pages of redirects, that are not redirects themselves (sometimes they are even targets for other redircts :/ ). Sometimes they contain just talk about merging/moving the page, sometimes it is tricky.

Any advice appreciated :) If you would prefer to look at the "real data" I could dump the lists here, or just run the scripts.

We don't have a rule about deleting talk pages of redirects, but unless they contain useful history, which can happen if e.g. the redirect was the result of a merge, they have always been systematically deleted when bumped into (no ad-hoc searches have ever been done). If you want to delete such pages, please go ahead.

About the "tricky" cases, I'll be happy to discuss them one by one, I'd rather you list them somewhere because even though your scripts are indeed very useful and easy to use (thank you for that once again), it's good to publish a list that everybody else can use, you may for example start a discussion in ArchWiki:Requests.

Thanks for the reply, I don't have much time lately to work on this, but I have at least deleted the three "archives"... I'll be back one day

Slightly off-topic, but I have also remembered that one of the redirect pages, %s, has an interesting HTML comment justifying the page's existence, but it is relevant only to Firefox 2 users (discovered by browsing the history of wikipedia:%s), so I guess it could be deleted as well.

Yeah, it's time to put that to %sleep. -- Kynikos (talk) 10:36, 11 September 2014 (UTC)

Unused templates

Since every properly created template contains an example of usage, which consists in transcluding itself, every properly created template will be used at least once and thus not listed under Special:UnusedTemplates :(

I forgot about Special:MostLinkedTemplates, it is indeed useful for finding these self-transcluding templates. As I can't think of any other way of showing the templates in action, I will just close this talk. -- Lahwaacz (talk) 16:55, 12 September 2014 (UTC)

Enhance system stability

I need your help with edits' history again :) One good boy (sarcasm) had renamed an article to a localized one. Please rename it back with history saving.

Thanks Kycok for your great help in keeping the wiki clean and tidy! This is fixed, however I've kept the redirect with the language tag because in the future it may become required. Keep up the good work :) -- Kynikos (talk) 04:50, 16 October 2014 (UTC)