Feel free to add suggestions for our Wiki on this page. To add a new topic, click on the "+" page tab. (This might be hidden under the "more" menu.) Remember to sign your remarks with
~~~~ (4 tildes), or use the "Signature and timestamp" button in the editor toolbar. See also Help:Signatures.
Stalled discussions and Archive
For discussions that have not had contributions in a long time see the Stalled discussions page. For completed discussions see the archive subpages:
Print to PDF and/or Export to EBook File Format?
I prefer reading long articles on my EBook Device (Kindle DXG). Seeing most documents being published in PDF, or some sites even providing EBook formats. Thankfully, my device can handle PDF but some can't. As for the Amazon Kindle's, I've seen really good results using kindlegen on converting EPUB to MOBI, but using kindlegen on HTML with TABLE TAGS produces poor MOBI files. As such, I usually use PDF files for computer technical documents. Also, kindlegen (aka mobigen) is binary only (proprietary). A couple months ago, I mirrored the entire Gentoo Documentation just to convert XML to HTML using gorg, and then kindlegen to convert to MOBI. This is very tedious for EBook users! I manage quite well as I use the console, but avoid Calibre due to it's package bloat and lack of command line only. (Calibre requires X for it's command line tool.) Probably the simple solution for now, for simple articles would be to ensure a 'Print to PDF' option. Lengthy articles such as the Gentoo Handbook and EBuild/EClass documentation, would be nice to have an EBook format. Signed: Roger 19:09, 15 November 2011 (UTC)
- Looks like PDF was already denied in bug bug #565624, which is understandable. The MOBI/EPUB might be still be a good idea. Maffblaster (talk) 20:22, 23 June 2017 (UTC)
Definition of Macros
You should define some macros as soon as possible for things like referencing portage packages, infoboxes for software that autocomplete from portage information, general infoboxes for software that include fields such as 'deprecated by', and create categories for each of the Gentoo projects (Hardened, etc.) so that relevant articles can be grouped together in a way that makes sense for users coming from other sources of documentation.
Voltaire 00:02, 2 August 2012 (UTC)
- We will definitely also need one for man pages. Like 'man 5 corosync.conf' should be possible to define with a quick macro that makes it obviously possible to type at the terminal but also clickable in-wiki to go to a hosted, HTML version of the man page. This should be the latest version auto-built out of portage, or preferably a diffed history of versions. This sort of cross-linking is precisely where a lot of Linux documentation falls down and where the Gentoo community could showcase its pragmatism. Voltaire 00:30, 4 August 2012 (UTC)
A few suggestion
- Display last modify date and last modify editor on each wiki page to let user know about the status of the docs.
- a3li says: Modification date is displayed in the footer; editor on the history page.
- Having Version tag, if the package need some different configuration we can have a version tag there to change the need but not the whole page. Even-thought gentoo are always updated it is still good to kept some history.
- a3li says: "Version tag"? as in <version>? Or as in a git tag for a history item. Either way, not sure how this is beneficial compared to increased efforts required.
- Kernel Template should have a format for kernel version -- it will be easier for other to understand and update.
- a3li says: non sequitur
- Files Template should have some way to indication changes required. Current way is to paste the whole file and looking for changes are not good for users.
- a3li says: This won't work. We don't always know the base file and how it changes. I'd rather have a known-good version than one that would break with changed defaults.
- New Page Template -- There should be a new page template which something like prerequisite, kernel requirement, emerge application files changes blah blah blah until the End to rc-update. This would be good for new and old editor as in future when there are some new things can be added in.
- a3li says: Sure, create one? :)
- maffblaster says: The resources being asked for here already exist in my user space. Feel free to make suggestions to the ones I have created (preferred so that they get finished) or clone mine to create your own. Once the rest of them get finished we could move them to a more official location. Others helping will speed up the process! --Maffblaster (talk) 23:14, 12 May 2015 (UTC)
- a3li says: Sure, create one? :)
- Kernel Template should be easier to use so should have a field like enable or disable and the kernel_module_name/the long name
- a3li says: Already covered elsewhere kernel config could be done better, but that won't happen unless code is contributed.
- Conflict in changes should have diff on top before the editor/content, this is easier to verify.
- a3li says: Order is defined by upstream, file issue with them to get a feature to update this.
- Comments are inline above. —a3li 19:29, 12 May 2015 (UTC)
- ill second the need for version tagging configurations. samba 3 vs samba 4 are radical departures from each other.666threesixes666 (talk) 05:14, 19 February 2014 (UTC)
- Different sections or different subarticles work fine to cover differences. —a3li 19:29, 12 May 2015 (UTC)
- Also for Editor.
- A warning should appear on editing a page section which is a part of an included (transclusion) page. Presently, it is not very obvious that one gets redirected to editing the source of the imported page. To see what I mean, go to Template:File and click on the  link right of Parameters. Now, you are no longer editing the page Template:File, instead you're editing the source from where content has been transcluded. --Charles17 (talk) 12:34, 10 May 2015 (UTC)
- Something for upstream, too. —a3li 19:29, 12 May 2015 (UTC)
Template for well known overlays
It would be nice to have a wiki template to create links to well known overlays pointing to more information about those. I'm typically linking either to gpo.zugaina.org overlay pages, occasionally to the actual repositories. It would be nice to have a unified target, whether it is zugaina, an equivalent, or even a wiki space where more information can be specified.
All-arches handbook sections
Unless I'm missing something, we have per-arch pages for parts and sections of the Handbook (e.g., Handbook:AMD64/Full/Installation and Handbook:AMD64/Installation/Disks), but we don't have pages for parts and sections that could be used for any arch. I don't mean that the pages would contain actual arch-agnostic instructions, but that they would simply link to separate pages for all the different arches (like Wikipedia disambiguation pages, except that [most] incoming links wouldn't be mistakes that need correcting, they would be intentional). That way, in an arch-agnostic article about a piece of hardware or software, for example, we could link to pages like Handbook:Installation or Handbook:Installation/Disks that would then allow users to get to the arch-specific Handbook pages they need. Right now, a lot of links to sections within the handbook seem to link to the X86 version specifically, for no good reason. - dcljr (talk) 00:00, 4 March 2015 (UTC)
- Have a look at Handbook:Parts/Installation/Media. This page is arch-agnostic as are all Handbook:Parts and gets arch-specified in its transclusions listed here. --Charles17 (talk) 08:20, 12 May 2015 (UTC)
- Here's a good example of why this is needed: at Handbook:Main Page#Viewing the handbook, it says, "If you are still not certain which architecture to pick, please read the first section of the Gentoo Handbook's second chapter (Choosing the Right Installation Medium) as this will elaborate on the supported platforms." But it doesn't link to anything, because by definition no particular version of the Handbook would be appropriate to link to. If we had a page Handbook:Installation/Media that linked to every existing arch-specific version of itself, then we could link to that. - dcljr (talk) 20:20, 4 March 2015 (UTC)
- To be specific, we would need (note "Expand" link):
- (I think I got everything there.) And possibly Handbook:Blocks, Handbook:Installation, Handbook:Networking, Handbook:Portage, and Handbook:Working (currently we don't have even arch-specific versions of these pages — e.g., Handbook:X86/Blocks — so I'm not sure they'd be needed). Admins would have to create these pages, of course. Would someone like to see a mockup of what I have in mind, or is that sufficiently obvious? - dcljr (talk) 01:50, 3 April 2015 (UTC)
- Most of the things (referenced) on the main page aren't available in localized versions. Most of them never will be. That and the fact that we'd need consistent translators to keep it up to date in all events doesn't make this worthwile. —a3li 19:24, 12 May 2015 (UTC)
Respect Accept-Language: in HTTP request
Delivery of pages which are available in different languages should respect the Accept-Language parameter from HTTP requests. Presently it does not. With Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 it just sends the english version.
- That won't work with the caching in place for non logged-in users. These don't hit any dynamic page or capability to serve content based on headers. Having a system for logged-in users would a) create different behavior than when not logged in and b) require non-trivial amounts of work to implement. Finally, translations are here to support the English language contents, that was a goal from the get-go of the wiki as translation capabilities are not granted. tl;dr: Won't be implemented. —a3li 19:24, 12 May 2015 (UTC)