Gentoo Wiki:Suggestions/Archive 2

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.

Recent changes in English
I recently :) started to use Special:Recent Changes 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 and )? 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  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 [//wiki.gentoo.org/index.php?title=Template:Yes/doc&diff=160652&oldid=9167 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): 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".
 * 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.

Here's the example above rendered the way I did in my edit to Yes: 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.
 * 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.

Here's another possibility that makes the "positional parameters by number" idea more explicit: Here's the same thing marked up a bit more: (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.)
 * 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.
 * (first unnamed/positional parameter) : Add text or an image to the top-left heading box.
 * (second unnamed/positional parameter) : Add text to the main area.
 * (optional) : Border color of the box and background color of the top-left heading box.
 * (optional) : Background color of the box.

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:
 * (first unnamed/positional parameter, required) : text or image to display in top-left heading box
 * (second unnamed/positional parameter, required) : main text
 * (optional) : border color of main box and background color of top-left heading box
 * (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:

(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 (there's currently a typo there which I would minor edit but can't: that "" part ) ? Thanks. --EmanueLczirai (talk) 19:28, 24 December 2014 (UTC)


 * Some locations, such as the  and   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 "" 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 ( ) Tag Extension
When editing articles, I have been using the tags in paragraphs to help illustrate to readers when certian commands need to be run (see the GRUB2 article I modified today for the latest set of examples). I know a 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 tag extention so that writers can have a tag specifically for in-line command examples? For now I can continue using the ("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  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)