Gentoo Wiki:Suggestions/Archive 2

From Gentoo Wiki
Jump to:navigation Jump to:search

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current Suggestions page.

CSS Menus for Navigation Bar

Navigation to all functions and features of this wiki could be much better with CSS menus. The xmas egg using javascript for navigation is a pain. We were having this discussion in the forums but nothing happened since. --Charles17 (talk) 14:33, 25 February 2015 (UTC)

I am baffled how you expect a discussion in a rather secluded area of the forums to trigger anything. At any rate, if you can provide menus that integrate into bootstrap perfectly and work on all screen sizes (especially integrate with the menu on smartphone screens), I'm all ears; otherwise, I'm not supporting your agenda. —a3li 19:22, 27 February 2015 (UTC)

CSS classes .glyphicon-ok:before and .glyphicon-remove:before

Browsers with fontface disabled display meaningless 3 instead of ✔ in tables and 4 instead of ✖. I am aware that allowing fontfaces to my browser could help working around but I dislike. Putting correct values ✔ (U+2714) and ✖ (U+2716) in css classes .glyphicon-ok:before and .glyphicon-remove:before could help avoiding the need of allowing fontface. --Charles17 (talk) 15:15, 25 February 2015 (UTC)

We finally have the luxury of scaling, nice, standardized iconography, I'm not falling back to different glyphsets just because you 'dislike'. Unicode glyphs also don't always render properly in text-mode browsers whereas you can feel free to apply userstyles to hide the webfont icons; you get to keep the pieces though. —a3li 19:22, 27 February 2015 (UTC)

Enable copy & paste of multi-command RootCmd template

I just realized that I often need to read a couple of commands to see what they're doing but then copy the list of commands and paste them to apply them immediately. That's impossible due to the text before each line. Very often it's a list of commands I publish and in that case the current way discourages me from using RootCmd and encourages me to use CodeBox instead. I believe it would be a great improvement to make RootCmd behave more like a CodeBox in this respect so that I can copy the commands directly.

In many cases I split the data from the commands in that the first block of commands is just shell variable assignments. Those I typically don't copy and instead I do the assignments manually, but then I want to apply the generic commands that use the manually assigned variables. --Pavlix (talk) 11:31, 10 February 2015 (UTC)

I fear that's not doable. I can think of one way, but that would take away the ability to have custom prompts.
One thing that already is in place is that each of the lines are triple-click-friendly. Maybe that can work this around sufficiently for you? —a3li 18:29, 10 February 2015 (UTC)
The very fact that I'm using CodeBox instead confirms that it is doable to have multiple lines of code selectable, even if not with the same decorations. I'm not talking about individual lines and so there is no work around except avoiding RootCmd altogether. But that may even result in putting the stuff in my personal subpages instead of public space so that it's not “fixed” by some active person. --Pavlix (talk) 19:30, 10 February 2015 (UTC)
I think it would also be possible even with the current graphical layout, just the "root #" text would have to be turned into a left-aligned background image for each line. I know it is not as nice as a couple of text characters, but I also don't think it's nice to leave it as is, where the decorator is selected with the actual command line. --Pavlix (talk) 19:36, 11 February 2015 (UTC)
*Box and *Cmd are serving different purposes. With no workable alternative that does not bring any disadvantages, that's a WONTFIX. And no, backgrounds are out of question. —a3li 13:10, 12 February 2015 (UTC)
I understand. Although as I said, it makes *Box a viable alternative to *Cmd for me even if I wouldn't consider it otherwise. I think I will use *Box to create scripts instead of a bunch of commands in the public space and possibly *Box even for a bunch of commands in the private space. Feel free to retire this suggestion given the circumstances. —Pavlix (talk) 13:15, 12 February 2015 (UTC)


Make the Wiki downloadable

It would be nice to have a dump of the wiki's database available for download so that users could access the content without an active internet connection. Wikipedia has this feature. I would definitely make use of this feature if it was implemented. The dump does not have to be daily or weekly; it could be monthly or quarterly. --Maffblaster (talk) 20:15, 3 February 2015 (UTC)

Would be fun to have a package that would help you read the wiki both online and offline on the command line. Even if it only did a bit of automation and then started links or better user's preferred browser. --Pavlix (talk) 11:42, 10 February 2015 (UTC)
Pavlix, I agree, this would be a great enhancement for anyone with intermittent internet access. It would be nice if a user could simply emerge the most recent wiki dump onto a system. Maybe it could create a simple script called "gentoo-wiki" in /usr/bin/ that would open the wiki in a preferred web browser or wiki reading software. Arguments could be passed to the script to tell it which page to open first. Example: gentoo-wiki Firefox would open the Firefox page.
Sorry, no dumps. We have enough problems as is with stale documentation and zombie clones of long-gone Community wikis. —a3li 18:24, 10 February 2015 (UTC)

Cannot upload and link to ASCII/Text files

Seems only JPEG, PNG, ... image files can be uploaded and linked to within Wiki articles here. It would be nice to allow ASCII/Text files to be uploaded as well. --Roger 09:51, 17 October 2012 (UTC)

Bug #451074 (which I filed being unaware of this page) is related to this. --ulm (talk) 12:20, 19 January 2013 (UTC)
This will not be enabled due to security concerns. Gentoo projects can use project hosting in due time instead. —a3li 13:22, 12 February 2015 (UTC)

Recent changes in English

I recently :) started to use Special:RecentChanges but there seems to be no way to just see pages that I will understand, let's say just English written pages. Filtering language for English gives empty result. Filter out translations is selected by default but I still see non-English pages in the list. I'm afraid there must be some conflict between how Gentoo Wiki is maintained and how MediaWiki expects to detect language and translations. —Pavlix (talk)

Moreover, output only changes on Russian (for example) pages also don't possible. And link to previous changes (page with older changes) also broken.
—Totktonada (talk) 10:27, 12 February 2015 (UTC)
Filtering only works when you use the 'new' recent changes (that btw need JavaScript). To enable that feature, set 'Group changes by page in recent changes and watchlist' in your Preferences. —a3li 10:48, 12 February 2015 (UTC)
It works, thanks! But question about old changes still there. Must link “Show new changes starting from 11:13, 12 February 2015” point to somewhere in past, not to current date/time?
—Totktonada (talk) 11:16, 12 February 2015 (UTC)
It helps in that I can now at least see something, but technically it doesn't fix the issue that causes that I have translations and non-English pages in the results. I must say that I still prefer the non-grouped view that works as a simple log. I don't say we need to fix it now, but I would be happy to get it fixed at some point of time. --Pavlix (talk) 11:59, 12 February 2015 (UTC)
The Translate extension interfering with Recent changes is a known thing. With the exception of filtering for English, everything should work with the JS-enabled changes. The one problem is in my book not grave enough for me to work on this immediately. If anyone wants to talk to Translate's upstream to get it resolved, feel free to. —a3li 13:12, 12 February 2015 (UTC)

Questions about translating process

Some details of translating process not be clear for me. I made this discussion public, because answers can be helpful for other users, not only for me. Maybe this page not ideal place for such public questions, but I wasn't found any kind of 'common wiki discussions'.

About process organization, people who part in it and they permissions

  • Who (must || can) mark page for translating (add <language /> and <translate />)? Help:Translating page mention 'editors'. Is his authors of original page or category of wiki participants? If I guess what page ready for translating (I wasn't change original page, but want to translate page), then can I mark page for translating? If answer positive, how about 'Help' namespace, for example Help:Talk_pages?
  • Who (must || can) accept translating request? Help:Translating page mention 'administrator' and 'lead translator', but who is this people, is they active? How long typical time interval between request and accept/decline?

I believe, what open translating process is motivation itself for translators and working under understood process is more pleasantly, in contrast with closed or misunderstood process.

You can find who these people are through the special pages of the wiki (show users that are member of a particular group). Currently, I'm the lead translator in the sense that I'm marking documents for translation when these articles are (in my opinion) sufficiently well written and structured. Everyone who can edit a page can add in the <translate /> tags.

About translating tool and translating process himself

  • Can I translate several chunks of text simultaneously? Motivations of this is desire to keep uniform phrases forms and style of translated text, follow possibly mistakes — all its without write drafts. Lateral reason is more clear changes history.
  • How about translation teams pages (related to some target language)? Example stuff for such page can be found on my personal wiki page: links to dictionary (with indesirable examples!) and common recomendations for Russian Gentoo translators (from old rugentoo.org project). On such team pages experienced participants of corresponding translator team can share they experience with new translators.

Note that such translating team pages must be written on target language due to recomendations on this page related to target language.

Translation teams can work in parallel. Translations are done one paragraph at a time. --SwifT (talk) 19:15, 23 December 2014 (UTC)

--Totktonada (talk) 20:41, 21 March 2014 (UTC)

Template documentation

I just made this change to the documentation of the {{Yes}} template because I thought having the bare text "unnamed" in the list of parameter names was potentially confusing. Then I realized a much larger discussion of template documentation is in order.

I'd like to implement a template-based approach to parameter documentation, so it can be standardized wiki-wide, and that requires some discussion of what format we want to use.

Here are some variations to consider...

This formatting currently seems to be the most common (taken from {{ContentBox/doc}}, but only showing the first 4 parameters):

1. unnamed
Add text or an image to the top-left heading box.
2. unnamed
Add text to the main area.
color (optional)
Border color of the box and background color of the top-left heading box.
bgcol (optional)
Background color of the box.

This is problematic for a couple of reasons. First, "1." is apparently being used to mean "first" and "2." to mean "second". Depending on the mix of parameters being documented, this can look like a numbered list (see File/doc), and it suggests (perhaps) that there are multiple parameters called "unnamed".

Here's the example above rendered the way I did in my edit to {{Yes}}:

unnamed/positional [1]
Add text or an image to the top-left heading box.
unnamed/positional [2]
Add text to the main area.
color (optional)
Border color of the box and background color of the top-left heading box.
bgcol (optional)
Background color of the box.

But I'm not married to that format, by any means. I've seen the term "positional" used a lot for "unnamed" parameters, hence my use of the term above. Help:Templates calls them "anonymous", so maybe we should use that terminonlogy? BTW, the "[1]" and "[2]" are intended to allude to the fact that positional parameters can actually be referred to by number.

Here's another possibility that makes the "positional parameters by number" idea more explicit:

1= (first unnamed/positional parameter)
Add text or an image to the top-left heading box.
2= (second unnamed/positional parameter)
Add text to the main area.
color= (optional)
Border color of the box and background color of the top-left heading box.
bgcol= (optional)
Background color of the box.

Here's the same thing marked up a bit more:

1=  (first unnamed/positional parameter)
Add text or an image to the top-left heading box.
2=  (second unnamed/positional parameter)
Add text to the main area.
color=  (optional)
Border color of the box and background color of the top-left heading box.
bgcol=  (optional)
Background color of the box.

(It might not be obvious that I've wrapped the parameter names in "code" tags and used 2 nonbreaking spaces to further separate the parenthetical text from the names.)

Now, I've completely ignored the formatting of the descriptions, which are currently being rendered as if they were complete sentences, even though most of them are not. I'd actually prefer sentence fragments [phrases] with no ending punctuation. This, along with explicit indications of "required" parameters, gives my final example:

1=  (first unnamed/positional parameter, required)
text or image to display in top-left heading box
2=  (second unnamed/positional parameter, required)
main text
color=  (optional)
border color of main box and background color of top-left heading box
bgcol=  (optional)
background color of main box

Whatever format we decide on, I'd like to use templates so that the last example, say, could be rendered by something like this: 

{{Doc param begin}}
{{Doc param|1|required|text or image to display in top-left heading box}}
{{Doc param|2|required|main text}}
{{Doc param|color|optional|border color of main box and background color of top-left heading box}}
{{Doc param|bgcol|optional|background color of main box}}
{{Doc param end}}

(The "begin" and "end" templates enable further possibilities, such as using bullet-lists instead of definition-lists or wrapping the entire list in a "div" element.)

Opinions? - dcljr (talk) 05:44, 27 August 2014 (UTC)

See {{Template Parameter Table}} and {{Template Parameter}} (and use them, of course!) —a3li 18:17, 28 December 2014 (UTC)

Editing Handbook or protected wiki pages

Would someone add, if appropriate, a section here Help:Editing pages saying either how to edit protected pages or that it's not possible to edit them, such as this one Handbook:AMD64/Working/Initscripts#How_init_works (there's currently a typo there which I would minor edit but can't: that "<c/ode>" part ) ? Thanks. --EmanueLczirai (talk) 19:28, 24 December 2014 (UTC)

Some locations, such as the Project: and Handbook: namespaces, are protected to only have developers and trusted contributors modify it. These namespaces contain resources that are more vital and thus warrant some additional ACLs. However, iirc, the discussion pages for those are still open so you can report fixes there. For the "<c/code>" issue, I've corrected it. --SwifT (talk) 15:31, 27 December 2014 (UTC)
I'll use their discussion pages as suggested. Thank you! --EmanueLczirai (talk) 16:22, 27 December 2014 (UTC)

Request for a Command (<cmd>) Tag Extension

When editing articles, I have been using the <code> </code> tags in paragraphs to help illustrate to readers when certian commands need to be run (see the GRUB article I modified today for the latest set of examples). I know a {{cmd}} template exists, but since it is a template it is not useful for in-paragraph illustrations (since it creates line break). Would it be possible to create a <cmd> tag extention so that writers can have a tag specifically for in-line command examples? For now I can continue using the <code> tag unless instructed otherwise; I just feel like the <code> tag is for code (variables are most of the occasions I use it) more so than in-paragraph commands. Potentially the <cmd> tag would function identically to the <code> tag but use a different default color scheme for readability purposes. I am really enjoying the new Gentoo Wiki theme! Thanks for helping make the Wiki great!

https://www.mediawiki.org/wiki/Manual:Tag_extensions

--Maffblaster (talk) 11:13, 28 December 2014 (UTC)

<kbd> ("something you type") sounds like a good tag for it, and it's even standard HTML: cat /etc/motd —a3li 11:26, 28 December 2014 (UTC)
Excellent, A3li! Thanks for the tip. I'll use the <kbd> tag from on to illustrate things people can type. It will work perfectly for examples within paragraphs. --Maffblaster (talk) 23:40, 28 December 2014 (UTC)

"desc" parameter for templates Code, File, Kernel

The templates {{Code}}, {{File}} and {{Kernel}} are users of {{ContentBox}} and use 1. unnamed parameter to add a description and the 2. unnamed parameter to add the actual content. The problem is, that the 1. unnamed parameter is optional, so you always have to specify an empty parameter.

I suggest to move the description part to a new "desc" parameter and change the content part to the 1. parameter. The 2. unnamed parameter should show an {{Error}}.

I know, this means a lot of changes to existing articles, but IMHO it is the right thing to do in the long run. Astaecker 09:27, 24 August 2012 (UTC)

The three template mentioned are replaced with the {Code,File,Kernel}Box templates that not only have a better name (explicitly noting that they are block elements, but also only have the contents as required parameter. —a3li 17:02, 28 December 2014 (UTC)
Retrieved from "https://wiki.gentoo.org/index.php?title=Gentoo_Wiki:Suggestions/Archive_2&oldid=1195708"