Difference between revisions of "Help talk:Style"

From ArchWiki
Jump to: navigation, search
(Style vs. Usability)
Line 10: Line 10:
 
* a large block of text requiring separate attention
 
* a large block of text requiring separate attention
  
but these actions are system critical. We don't want to create confusion in guide-nature articles.
+
but these actions are system critical. We don't want to create confusion in guide-nature articles. --[[User:Stefanwilkens|stefanwilkens]] 18:18, 10 January 2012 (EST)
  
 
==Edit summary==
 
==Edit summary==

Revision as of 23:18, 10 January 2012

Style vs. Usability

Commenting on: Help:Style#Daemon_operations

Deprecating installation instructions and the method of adding deamons to the DAEMON array is causing a higher than normal amount of questions on how to do this in the IRC channel. Perhaps this can be reconsidered, or at least be reconsidered for critical articles like the beginner's guide, the dbus article, the official installation guide, the various graphics driver pages (ATI /NVIDIA) etc etc. These are often browsed from CLI during installation and should thus be as complete as possible, having to follow links around and back from a CLI browser is no fun.

And in general: Having to look up the method of applying a change mid-article kills the flow of the article, users have to browse around to find a system-critical method on a different page.

This would be fine if the action involved wasn't so important, or if the linked information was either:

  • a small non-critical note
  • a large block of text requiring separate attention

but these actions are system critical. We don't want to create confusion in guide-nature articles. --stefanwilkens 18:18, 10 January 2012 (EST)

Edit summary

See Help talk:Style/Edit summary.

Package installation

See Help talk:Style/Package installation.

Article summary templates

See Help talk:Style/Article summary templates.

Migration to new Code formatting templates

See Help talk:Style/Migration to new Code formatting templates.

Category pages - tree or otherwise?

The ArchWiki category tree was originally designed as just that: a tree. I disagree with the point: A category can be categorized under more than one category, provided one is not ancestor of the others. I believe that categories should themselves be categorized under only a single category. Non-overlapping categories should be devised in cases where one category could belong to many. Related categories can be listed on the category page itself. -- pointone 10:39, 23 September 2011 (EDT)

As noted at the top of Table of Contents, Category:Secure Shell (English) is a good example: if we can solve it we can really try to avoid categories with multiple parents in general, which is something that I don't like either. The problem is that Security could hardly be child of Networking, and vice versa, so either we put Secure Shell only under one of them, or for example we split Security in two categories, one under Networking, the other not, and put Secure Shell under Networking->Security. Of course we could also split Networking instead, but it would probably be less natural. -- Kynikos 11:43, 23 September 2011 (EDT)
Is there any decision on this? I would like to add Category:Package development (English) as a subcategory of Category:Package management (English). Currently it is only a subcategory of Category:Arch development (English). But there is no point in me doing that if it is just going to be undone. Otherwise I would add a manual link from Package management (which may have helped me find what I was originally looking for) and probably a reciprocal one back the other way. But I feel that is more work than necessary and when looking for information on the wiki I expect the categories to work this way instead.
 Why were the Arch wiki’s categories originally designed as a tree? Why do you prefer that categories only have a single parent category, especially when article pages do not have to? Vadmium 10:52, 26 October 2011 (EDT).
No decision yet, the current style rules allow multiple parents also for categories, so you can implement your idea, don't worry now whether it will be undone or not in the future. Just remember to update Table of Contents or Talk:Table of Contents (I don't remember which one is the most up-to-date) and to link to this discussion from the Edit Summary.
In general, a tree-like structure is the "ideal goal" because it looks simpler and tidier than having "converging branches", thus helping organizing the articles in a more natural way and also making maintenance easier. However it may be hard to put into practice indeed, so this discussion is probably going to last long...
-- Kynikos 12:59, 27 October 2011 (EDT)

i18n

This is a bit off-topic, so move this to its own section if appropriate, please.

Am I the only one that finds the i18n sections to almost be more trouble than they are worth? The vast majority of the i18n pages I have seen are either months out of date, are missing a lot of formatting (such as Filename, Codeline, etc.), have half of the page in English and the other half in the correct i18n language, and other such nonsense. Would it make more sense to get rid of the i18n sections entirely and to dedicate all of our effort on making sure that the articles we have in English are written in the most "translator friendly" manner possible (e.g. no contractions, no slang, etc.)? I am not familiar with how well free services like Google Translate work when going from English to [insert non-English language here], but it might be worth looking into. It would probably make sense to keep the official installation guides written directly in the non-English languages, but it is simply not feasible to properly maintain i18n pages for every page on the wiki. -- Jstjohn 01:56, 10 October 2011 (EDT)

Also, with the rise of Google Chrome which basically has Google Translate built into the browser, I would guess that doing this would not be as big of an inconvenience to our non-English users as it would have been a couple years ago. In fact, I would bet that using Google Translate via Chrome would be more convenient for our non-English users than having to deal with significantly outdated instructions (and the troubleshooting/damage control that will almost certainly occur from way-out-of-date guides). -- Jstjohn 02:09, 10 October 2011 (EDT)
The idea was that other languages move to their own wikis, like German, French and Polish did.
Another issue: there's currently no way to search within one language only, so you get 5 useful links in twenty. -- Karol 03:32, 10 October 2011 (EDT)
As Karol says, in theory each language should have its separate wiki. But in practice it's not how it works, and for sure we cannot just "get rid" of all the non-English articles, we'd throw away the efforts that many users have done over the years, trying to make the Arch documentation available also to those who can't read English.
Google Translate, although managing to achieve quite impressive results, cannot really handle intricate sentences, or slang, idioms, or technical terms, and anyway it needs correctly-formed English sentences to work well, which is not always the case.
About the search issue, the "language" information of an article is stored only in a standard substring of the title (the _(Language) suffix), AFAIK there's no "Language" field in the database, so there's probably no built-in function to filter a search by language. Asking Arch's web developers to implement one by themselves would rightly result in a "we don't want to maintain such a change, go ask upstream, closed" or something like that.
-- Kynikos 15:53, 10 October 2011 (EDT)
There have been a number of discussions about this over the years: 2006, 2007, 2009, and 2010. In short, there are a number of potential solutions; none are perfect. Currently, the interwiki implementation is considered "best" because it provides non-English users with a fully-localized experience and isolates each language. Other "good" solutions include the creation of language-specific namespaces or migration to a different wiki which provides "better" internationalization options -- but require more effort to implement. In brief: the i18n bar will eventually disappear. -- pointone 17:36, 10 October 2011 (EDT)
Uh right, I didn't think of the namespace solution, it may be the most practical to implement with a relatively little effort!
Another disadvantage of the i18n template is that statistics like Special:LonelyPages and Special:DeadendPages don't work anymore as expected.
-- Kynikos 17:50, 10 October 2011 (EDT)

My favorite quote from the Package management instructions

Do not give examples ...
Why give concrete examples when we can be vague and tell people to RTFM? Maybe we should allow AUR install examples but put them in a template with a red-alert background, and a label making the danger more clear.


Abandon all hope, ye who enter here!

  1. install cower from the AUR
  2. install evil-pkg ...
    1. cower -d -d evil-pkg
    2. cd evil-pkg
    3. makepkg -s
    4. sudo pacman -U evil-pkg.tar.xz
  3. summon your new daemon ... # /etc/rc.d/daemon start


Reminds me of Mordac the Preventer of Information Services. The reason for this is obvious, but the Arch User Repository page barely mentions AUR Helpers (and advocates the use of nano :-)

There are many English translations of this famous line but we're trying to save Archers from damnation, so we won't lead them the way you suggest.
What's the benefit of writing basically the same thing dozens and maybe even hundreds of times? The AUR page gives all the needed info and users will likely be using a script / helper anyway. -- Karol 16:32, 22 November 2011 (EST)
Why give the same example in every single page that mentions an AUR package when we can avoid multiplicating the efforts and tell people to Read The Friendly Manual? The installation procedure for AUR packages is the same for each of them (that's the point of PKGBUILDs after all...), if there are further specific configuration steps to be performed before or after installation, they can be described in detail in the article of course.
If you have serious and constructive ideas on how to improve the Arch User Repository article we'll be glad to hear them :)
-- Kynikos 07:32, 23 November 2011 (EST)
Closed. -- Kynikos 08:27, 18 December 2011 (EST)