Gentoo Wiki:Feedback

From Gentoo Wiki
Jump to: navigation, search

About this board

Got feedback for the wiki overall?

You have found the right place to share it!

We're beta-testing a new way to discuss wiki feedback on this page. Please feel free to leave (meta-)feedback about this page as well.

Related Pages

By clicking "Add topic", you agree to the terms of use for this wiki.

News Item: July 28, 2017: Word crimes

Summary by Maffblaster

The message titled "Word crimes" is satire. We try to keep things fun.

Lanodan (Talkcontribs)

Seriously, a crime?

We have talks, conferences and whatever on how tech is marginalising people, and BAM this video on the homepage.

Let me summarise the first minutes of the minutes of the video (could not watch more than that without being seriously angry) from my point of view.

> Your grammar sucks, people are making fun of you (and it’s excepted), got eat a dictionary your retard

But actually the message could be more phrased like:

> Hey, if you see mistakes (everyone does make some) like grammar or spelling errors, please edit the page.

And maybe something like "Common Mistakes" link(s), not something that is:

  • non-reusable (it’s not text, it’s a video, you can’t search in it and it’s terribly not accessible)
  • terribly offending

Also, I have dyslexia amongs other things, English is not my native language like most people in the gentoo community. But it doesn’t mean I can’t choose my words and not be rude.


It’s completely disproductive by being rude, non-useable and maybe even other things.

PS: "Preview the result" is broken

Maffblaster (Talkcontribs)

Hi Lanodan,

I hope this message finds you in good spirits.

The message titled "Word crimes" is satire. It is supposed to be not taken seriously because of it's satirical nature. Perhaps if it was written on April 1st it would have been more timely. It is all right to lighten up and have a little fun around the Gentoo webspace (in fact we've been doing it for years).

Laughter is good medicine for the soul.

Summary by Maffblaster is offline now.

Charles17 (Talkcontribs)

An outdated copy of Gentoo Wiki is found on which is causing confusion.

Maffblaster (Talkcontribs)

Not sure what we here at the wiki can do about that. I do not believe it's ran by any Gentoo developers. Perhaps you could send an e-mail to the Foundation?

A3li (Talkcontribs)

Nothing we can do.

Charles17 (Talkcontribs)

Finally kind of solved by itself: »ping: unknown host«

Maffblaster (Talkcontribs)

Okay. We can close this discussion then.

Charles17 (Talkcontribs)

Inspired by and the InfoBox manpage template, would it be possible to have Gentoo itself provide packages' manpages? Could be useful for the InfoBox manpage template and also maybe as an additional "Resources" item in

Project:Android/build - Error in rt-sysroot script

Summary by Maffblaster

User asking for support; left instructions to use support venues for Gentoo support.

X48rph (Talkcontribs)

In the rt-sysroot script there is a sed error, need to change [:digit:] to [[:digit:]] in the line : -e "s,[^:]*(/lib/ld-linux[^.]*\.so(.[:digit:]+)?),${EPREFIX}\1,g" \

Otherwise it gives a sed error and creates an empty specs file

Maffblaster (Talkcontribs)

Hi X48rph . This is not the place to ask for support. Try the Forums or #gentoo IRC instead.

"Ebuild repository"

Feng (Talkcontribs)

The term "overlay" is deprecated and is replaced by the term "ebuild repository"! The "Overlay" and "Overlay Talk" namespaces should be modified accordingly.

N.B: I think we should also choose a diminutive for "ebuild repository". The term "repository" has been reduced to "repos" as in "/etc/portage/repos.conf". Maybe, we could choose "ebd-repos", "e-repos", or "e_repos", ...

Maffblaster (Talkcontribs)

The Gentoo developers still need to discuss this change on a project wide basis, so I am hesitant to make this change until we get the terms solidified and agreed upon. Some developers still like the term 'overlay' to be used for everything except the Gentoo ebuild repository.

Gerdesj (Talkcontribs)

(TEST: Hmm - rubbish formatting here, what triggers noticing a new para ...)

The Gentoo wiki is very good as a MW site. The presentation is fantastic and very approachable - ie someone(s) really know their stuff about design. I run several MW sites myself and contribute in a very minor way to MW's docs and use several other people's/project's MWs, so I feel I have a fair grasp about wikis running on MW.

Each site has many templates, styles and so on that are idiosyncratic to that site. For example I created the original WIP template here and it has sprouted an author tag - cool: that's collaboration in process which is exactly what MW is all about. I was presented with a link to the template help - great: and I fixed my error.

However, most people are not particularly familiar with MW but may want to do docs because that is what they can do. These potential contributors may not be programmers or l33t sysadmins (well they are - they are Gentooers!) or whatever but can string one or two words together. These are the folk we need to enroll and encourage.

There is a link to the Help page on the front page but it is only a Category and a bit rubbish. The front page is very dense and needs weeding.

On my work wiki I put a bloody great link to a simple howto create and edit a page. I found that the shorter I made it the more people contributed. I gradually added links to more advanced stuff at the bottom as References - always in a new tab and people use them.

A handy experiment for user testing is to point, say, your (ideally non technical and non wiki focussed) partner at your wiki and ask them to contribute something with a few minimal pointers and see what they do. You will be amazed at how fast you realize how crap your carefully crafted wiki organisation really is.

I'll happily do the above - a simple set of editor docs - but it is a task that belongs to the owners of the site and I'm not one of those. I'll also drop that since I've added Visual Editor on my sites, I've seen a dramatic increase in contributions.

Cheers Jon

Veremit (Talkcontribs)

Perhaps you can swing by Freenode IRC #gentoo-wiki and it might be possible to discuss some of your ideas with the Wiki admins. Tia.

MalakymR (Talkcontribs)

I'm a new editor and whilst I know about some of the template: pages, it's not always easy for me to find my way there.

I'd guess a link next to the Help link at the top of the Editing page with an overview of options with links to the more detailed pages ie.

Gerdesj (Talkcontribs)

@MalakymR: Bugger that mate. You should not have to fight your way around docs. You probably have something useful to explain to other people, but the last thing you need is trying to fight your way through weird and odd MW related stuff.

You are probably not daft and must have some skills because you are a Gentoo user AND you want to help out other Gentoo users (actually, you'd be surprised how many other Linux users copy our wiki pages or use it as the source for info. and as far as I am concerned - all are welcome here: we are all brothers and sisters)

I mentioned my acid test earlier: get a disinterested user to interact with the site - you learn a lot from that.



MalakymR (Talkcontribs)

You can't have all the detail immediately there though. Which is why the split summary to at least get someone started should work. It's there already in the Help for formatting, a bit more for other objects like RootCmd would be helpful.

I generally agree though - people in the know/developers etc know it so well sometimes they don't see how hard it can be for a newbie to read 50+ pages of docs before getting started.

Though, a barrier to entry isn't the worst thing in some cases, need not be so big though.

Cant find bash file

Summary by Maffblaster

Instructed the user to get support on the support sites.

Amitbaba (Talkcontribs)

hi:) can't find ant bash files: bash_profile , bashrc etc.. any idea?

Maffblaster (Talkcontribs)

Hi Amitbaba, this is not the place to ask for support. This place is to leave feedback for the wiki. Please go to the forums or #gentoo on IRC.

Use of metadata abstract versus article description

Summary by Maffblaster

Article description property to be used over metadata abstract.

SwifT (Talkcontribs)

Maffblaster and I had a small talk on it on IRC, but didn't finish it yet. Right now, Maffblaster is looking into a more flexible way of referring to other articles on the wiki (through the See Also sections). This method takes an article-provided paragraph as part of this source.

Now, the suggested paragraph is a new parameter (Article description) which provides a single-sentence description of the article. However, we already have the means to provide this (through the metadata abstract).

I would rather not introduce another parameter, but instead use the abstract one (which has existed for a longer time). The feedback Maffblaster (correctly) gave was that the abstract one often uses longer paragraphs, whereas the suggested parameter would use a single sentence.

I don't think there is really a need to differentiate on this. We can easily update the abstracts of articles to have smaller paragraphs, nor can we enforce that the other parameter would use a single sentence.

The reason why I prefer to keep it to a single one is to ensure that the number of non-visible parameter fields that we want to put in the article is properly managed, and that editors don't get the impression they have to provide the same information twice, trice, etc.

Maffblaster (Talkcontribs)

Another point I would make is the naming terminology used for {{Metadata}}. It is non-descriptive of its exact purpose, which is why I was motivated in creating the new {{Article description}} template (and associated Property:Article_description text property).

The term "Metadata" could mean a variety of things based on the context. There are a lot more potential data points (that I would eventually, potentially like to harness) in our articles, and they will need additional templates and properties in order to make it possible for automation and flexibility.

I certainly agree that it is good to open a discussion about this, as my experiments in this area have opened my eyes to the possibility of connecting (a lot) more data directly from the Portage API. The list of available software in Display manager is a good example. It would be nice to have a Package template/property and potentially a homepage template/property (linked to InfoBox homepage data?). This data would be called in the Meta articles to list the instructional articles presently available for each software package.

There are a lot of possibilities here, and it is definitely a dream of mine to have our wiki automatically associating our (excellent and always improving) documentation directly with packages and then exposing this to the end-users in a viable way (presently some ebuilds provide the URLs to the appropriate articles here on the wiki.

As far as I tell, the intended purpose of SMW is to make adjusting lists, generating charts, and graphics automated and maintainable.. I'm totally fine with adding additional data points to the wiki (such as semi-automagic generation of the Meta style articles)., as it would ease the burden on our editors and allow to have a standard of consistency across the wiki (for things like the See also sections of articles).

Another (somewhat weak) point: SMW (upstream) uses a property named "Description" for the same purpose I'm using "Article description." Only difference here is that "Article description" is more exact.

Please also review this SMW example of data point being defined and exposed for references in other articles:

SwifT (Talkcontribs)

Given that there's no other feedback of yet, I'll go with the suggested article description (especially since Maffblaster is much more active than me ;-) and approve those changes for translation as well then.

Translated redirects?

Summary by Dcljr

The use of redirects on this wiki and the possibility of incorporating them into the translation process was discussed, but no agreement was reached.

Dcljr (Talkcontribs)

When articles are translated into other languages, they are named as subpages of the original title using ISO language codes. For example, Sudo is translated as Sudo/es (Spanish), Sudo/fr (French), etc.

Some titles are redirects to articles (or sections within articles), for example emerge redirects to Portage, euse redirects to Gentoolkit#euse, and so forth. These redirects are useful because they simplify both article writing and wiki maintenance. (When writing an article, it is natural to refer to, and link to, "euse" when it comes up, not "Genkernel#euse". Plus, if we ever decide to have actual articles [not redirects] titled "emerge" or "euse", no links would have to be changed on the wiki to accomplish this: the redirects would simply be converted into articles.)

My question here has to do with the proper handling of redirects as articles get translated.

To be specific, let's consider the fact that Gentoolkit has been translated (more or less) into German, Spanish, French, Japanese, Korean, and Russian.

Since euse redirects to Gentoolkit#euse, it seems logical to me that euse/de should (be created to) redirect to Gentoolkit/de#euse, and so forth. That way, an English–German translator encountering the link [[euse]] in an English article can "assume" that a link to [[euse/de|euse]] is called for (of course, they would need to check that it actually works). Presumably, this is already what happens in the case of non-redirects. (For example, [[gentoolkit]] would get "translated" into [[gentoolkit/de|gentoolkit]].)

(BTW, if euse ever becomes an article, then euse/de, etc., would simply be deleted to make way for proper translations.)

Not being a translator myself, I can't say whether this approach would create any unique problems for translators. On the face of it, it seems like it shouldn't make any difference whether the link target is an article or a redirect to an article. Am I wrong?

Note that alternative approaches to what I'm suggesting include (1) not using redirects in the first place (i.e., preferring links like [[gentoolkit#euse|euse]] over [[euse]] in all articles), or (2) keeping redirects in our English articles but changing them into links like [[gentoolkit/de#euse|euse]] in translations.

I would reject the first alternative almost out of principle, since I see redirects as a fundamental wiki feature that we should take full advantage of. The second alternative seems unnecessarily confusing and inconvenient.

So… opinions? Am I missing something important about how translation works?

For a little background about why I'm posting this — including the views of one translator who sees things differently — see User talk:Cronolio#Bypassing a redirect. Note that euse/ru has been (grudgingly) created in line with what I'm proposing. I still don't see why this is a bad idea, which is why I'm asking for other people's opinions.

SwifT (Talkcontribs)

I've seen (and made) quite a few edits to remove redirects. In other words, change links from pointing to a redirect page to the actual article. I understand your suggestion to keep the redirect pages "active" even in articles, but as you found out, it has other consequences.

Polluting the wiki with "wrong" pages seems wrong to me.

Perhaps we can adjust those redirect pages to become small pages (containing little more than a simple paragraph of explanation) with a link to the article that contains more information? This has the benefit that this page can act as a transclusion source.

Dcljr (Talkcontribs)

What are these "other consequences"? The only downside I see is some users don't like them. What's the actual argument against them?

BTW, contrary to redirects being "wrong" pages, they are actually the complete opposite: they lead users to the "right" target for the link text or search term.

SwifT (Talkcontribs)

The translation issue is this other consequence that I was referring to.

The redirect pages themselves are of course useful, because they indeed lead users to the right target. But if we fix the links towards these pages in the wiki, then users don't come across those redirect pages anymore through browsing the wiki - of course, they can still come across then through direct visits or cached links outside the wiki.

What do you think of the idea of creating a small article for the page instead, and point the users to the right page? Like a soft redirect but with the focus towards the right page on the same wiki rather than towards an external site?

Such smaller article can perfectly be translated (and thus linked to). Main articles that suffice with linking to this smaller article can do so, while others can directly link to the actual target?

Dcljr (Talkcontribs)

The translation issue is this other consequence — OK, and I've suggested a workaround for that issue. Of course, if no translators want to use my suggestion then it won't be done. (I am not a translator, nor should I be.)

The "short articles" you speak of sound a lot like redirects but with the added inconvenience of having to read text and follow another link to get where you want to go. IMO, this is going backwards: putting more of a burden on readers for no good reason.

The only benefit I can think of for creating that kind of short "intervening" article would be to allow for multiple targets. But then we're talking about a disambiguation page rather than a redirect. Now, the convention with disambiguation pages (at English Wikimedia projects, anyway) is indeed to replace incoming links to them with more specific links to appropriate final target pages, but that's because of the inherent ambiguity in those pages' titles. The pages I'm talking about are not ambiguous, they are specific titles we happen not to have articles at (or they're variants on existing page titles, or things that are discussed in sections within other pages).

I haven't researched how redirects are handled on other MediaWiki wikis using the Translate extension. That would be nice to know…

Unless someone else has something to say about this, I'll just leave it at this:

  1. Redirects are useful in some contexts, so we should not discourage their existence per se.
  2. Redirects could be incorporated into the translation process (in the way I suggested) if translators wanted to do this.
  3. If translators do not want to do this, then obviously it won't be done.
  4. I won't create any "translated redirects" myself, but I will continue to create redirects to our English articles when I think they are needed.

Project: Wiki Translation

Feng (Talkcontribs)

The translation of the articles of the wiki is not an exclusive activity and is necessarily collective because of the number of articles to translate. Cooperation should be developed in order to obtain and give coherence to the translation activity. Thus, contributions could be more important because of the quality of the translation; the foundation of the translation activity having been defined. The personal contribution will be obvious and more importantly, will not be absurd (a phenomenal work in constant evolution realized virtually with difficult translations). Ideally, progress could be made, indeed, some good translation projects have been abandoned due to lack of support. I'll suggest that we search on the web how to define an organization for the translation (for example, look at how Wikipedia manages the translation).

Feng (Talkcontribs)

I suggest that we create a common page for translators of a language. For example, Gentoo Traduction for the french language (Gentoo Translation).

Feng (Talkcontribs)

I suggest that we bundle information about the translation in Gentoo packages (a package per language). Thus, the users will get the information on their system, locally. Maybe, some users will have more willingness to make a contribution (send their work by email to the translation team or performing defined tasks). We can open an overlay for each translation team or translators and see what we can get!

N.B: The information should be stored into XML files using English tags. The glossary (for example) could have <word> </word> tags.