Difference between revisions of "User talk:Kynikos"

From ArchWiki
Jump to: navigation, search
(Test: /test)
(Crazy idea about interlanguage links: new section)
Line 77: Line 77:
  
 
: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 [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/ 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. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:18, 5 December 2013 (UTC)
 
: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 [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/ 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. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:18, 5 December 2013 (UTC)
 +
 +
== Crazy idea about interlanguage links ==
 +
 +
If [https://www.mediawiki.org/wiki/Extension:ParserFunctions 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: [https://www.mediawiki.org/wiki/Template:Languages], [https://www.mediawiki.org/wiki/Template:Languages/Lang]. 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 {{ic|<nowiki>[[subtag:Page Name]]</nowiki>}} links for all languages. There would also be checking if the localized page exists (using the {{ic|#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
 +
* the localized article has different base name than the English page ([[Network Configuration]] vs. [[Configuring Network (Italiano)]]) - best solution would be moving the localized pages to match the English page (this would be good anyway)
 +
* there are possible problems with redirects, I did not think of it yet
 +
 +
Disadvantages:
 +
* slower rendering of pages, higher server load ({{ic|#ifexist}} is considered an "expensive parser function" [https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#ifexist_limits])
 +
 +
Anyway, what do you think of it? Is it a viable solution?
 +
 +
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:53, 8 December 2013 (UTC)

Revision as of 13:53, 8 December 2013

Feel free to leave here your comments on my edits or anything else you want to talk about: I'll reply as soon as I can!

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

See 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.
-- Kynikos (talk) 15:23, 4 May 2012 (UTC)

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)

Well, about indentation we're just following Wikipedia's standards: Wikipedia:Help:Using_talk_pages#Indentation, Wikipedia:Wikipedia:Indentation.
About long discussions, outdenting can be used, Wikipedia:Wikipedia:Indentation#Outdenting.
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 ^^
-- Kynikos (talk) 13:41, 6 August 2013 (UTC)

VirtualBox article rewrite

Hi Kynikos!

I'm currently rewriting the VirtualBox article and I've some question about the latter.

In the Related section of that article, there is currently two different articles which are looking exactly the same regarding the subject they are dealing with:

  • Installing Arch Linux from VirtualBox: this one is really outdated and has been marked as is for ages. I think it could be removed. If you agree, could you request its deletion or do it by yourself (I think I haven't the required right to achieve that).

Also I've found a page dedicated to systemd services which are completely unrelated. I've found a service related to VirtualBox, I think the later should be removed from that section and integrated to the main VirtualBox article (this is what I'll do).

Also I wonder why even this systemd/Services section has ever been created. It has unrelated stuffs and each of them should be located to its related article. The problem is similar with sections of the systemd main article.

Regards. Wget

Hi Wget, thank you for your will to take on this task! After having a look at the current status of those articles, I agree that there are indeed many improvements that can be done:
  • I confirm that Installing Arch Linux from VirtualBox and VirtualBox Arch Linux Guest On Physical Drive practically cover the same topic, however they do it for two different purposes: the former allows installing Arch Linux on a physical drive from VB, the latter allows booting an already existing "physical" system from VB; IMO the best thing to do in this case would be to merge the two articles while keeping intact and clear the distinction of the two scenarios (i.e., some rewording would be required on VirtualBox Arch Linux Guest On Physical Drive); maybe a new title could be created for the merged article, and the old ones should be redirected there, not deleted.
  • About systemd/Services I think you're right, those units should be moved to the respective articles, if existing: if a list of services not provided upstream is required to keep track of the status of the respective packages, systemd/Services should be moved to the DeveloperWiki namespace and it should contain only a list of links to the articles where the services have been moved. It would be great if you could start a discussion on Talk:systemd/Services about this. Regarding the VB service you can safely move it to VirtualBox.
  • About Systemd#Running DMs under systemd, both it and Systemd#Native configuration are already properly marked for merging/moving/deleting, they're just waiting for somebody to give them a bit of love ^^
-- Kynikos (talk) 02:16, 30 September 2013 (UTC)
Hi Kynikos,
Thanks for your fast reply. I've just begun to make the adaptation, articles merge, we agreed on. But after spending some times to the article, I realized that the Wiki's style rules don't explicitly define how parts of commands that have to be adapted must be formated (or maybe I haven't found it yet ;-) ). An example is worth a thousand of words:
# dkms install vboxhost/<virtualbox-host-source version> -k <your custom kernel's version>/<your architecture>
In which format do I have to put <the strings that must be replaced/adapted>. I don't even know if we have to surround them with angle brackets < >.
Wget (talk) 22:00, 30 September 2013 (UTC)
Help:Style/Formatting and Punctuation will give you all the answers you need, in particular Help:Style/Formatting and Punctuation#Pseudo-variables in file/command line contents deals with your example.
Sorry if I can't give you feedback for your edits now, but I'm incredibly busy, I'll get there in the next days! Meanwhile if you have more questions don't hesitate to ask :)
-- Kynikos (talk) 14:54, 1 October 2013 (UTC)

Hi Kynikos, Just to bring to you some updates. I'm still on this rewrite. It is longer that expected as I need to recheck all assumptions written in the documentation (and I needed to wait for the 4.3 release). I'm gonna make some subpages, as proposed in the discussion page of VirtualBox Extras. Do you know if some warning templates are available to indicate that the page is currently being rewritten? -- wget (talk) 19:59, 6 November 2013 (UTC)

Hey wget, thanks for the update, I think just using Template:Stub with a proper description will serve the purpose. -- Kynikos (talk) 08:50, 7 November 2013 (UTC)

Kynikos, The rewrite makes some progress, but I'm still spending a huge time at verification and tests. I put the content from VirtualBox Extras to the main VirtualBox article. Could you proceed to deletion of VirtualBox_Extras? Thanks! (The main VirtualBox article will be clearer when I will have finished the rewrite and a dedicated subpage might be unneeded) -- wget (talk) 20:47, 12 November 2013 (UTC)

Done, it's always preferable to redirect instead of deleting when possible :) I'm trying to follow your changes, I think you're doing a great job, keep up the good work!! -- Kynikos (talk) 08:48, 13 November 2013 (UTC)

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.

-- Jstjohn (talk) 00:15, 5 December 2013 (UTC)

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
  • the localized article has different base name than the English page (Network Configuration vs. Configuring Network (Italiano)) - best solution would be moving the localized pages to match the English page (this would be good anyway)
  • there are possible problems with redirects, I did not think of it yet

Disadvantages:

  • slower rendering of pages, higher server load (#ifexist is considered an "expensive parser function" [5])

Anyway, what do you think of it? Is it a viable solution?

-- Lahwaacz (talk) 13:53, 8 December 2013 (UTC)