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.

Use of metadata abstract versus article description

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.

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).

Translated redirects?

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.

Gentoo-wiki ends in 2016 year?

Anarchist (Talkcontribs)

Copyright string in the bottom of page still is:

«© 2001–2016 Gentoo Foundation, Inc.»

Cronolio (Talkcontribs)

Impossible to fix it via wiki web interface. I am ctrate new bug #611496

New test case template

Dcljr (Talkcontribs)

Because of the behavior of {{!}} in tables, as alluded to in the thread "Template:!", I have created a new {{test case}} template (to replace {{testcase}}) that renders the test cases in <div> elements instead of table cells. This fixes an annoying issue where examples using {{!}} didn't work in the test cases when they actually would work in normal use (unless, of course, that use was inside of a table cell).

(The workaround was to use a different template, {{!!}}, in the "live" examples where {{!}} was used in the displayed wiki code — an approach that I judged unnecessarily confusing for template editors. See this diff for an example of the "workaround" method being abandoned in favor of using the new template. An alternative workaround can be seen in this other diff.)

The only thing that's lost with the new template is being able to collapse the test cases. Personally, I've never taken advantage of this ability, and I'm not sure anyone really needs it. (ISTR there's some problem with making divs collapsible in MediaWiki, so I didn't try. But maybe it's possible.)

To see the difference between the two test-case templates, compare [1] and [2] (for example).

Note that the new template emulates "definition list" formatting (bold term followed by indented definition) instead of the "table" formatting of the old one. This is largely for convenience sake, since I didn't want to take the time to try to reproduce the table formatting with <div> elements. (BTW, literally using definition-list wiki markup is out of the question, since that wouldn't display properly with many of our templates.)

So… any objections to converting all of the /testcases subpages to use this new template? (My plan is to slowly replace all the template calls, making sure everything works with the new one, then eventually redirect the old template name to the new one, assuming everything works.)

Edit: Struck out the part about not being able to collapse.

Dcljr (Talkcontribs)

I've given the new template the ability to collapse a test case (it was much easier than I thought), so it now does everything the old template did, and more. I've converted all the templates I created to use the new {test case} template, and will soon start converting all the rest of the templates.

Summary by Maffblaster

No, translations are not possible this Feedback page.

YKLA (Talkcontribs)

Is it possible to provide multi-language support and increase the translation options for this page?

Dcljr (Talkcontribs)

I don't think so, but I'm no expert. This page is implemented by the "Flow" extension to MediaWiki. If that page doesn't point you to relevant information, you can try asking on the corresponding talk page.

edit: Whoops, I always link to the wrong page: try mw:Help:Flow. It's much more user-friendly.

Maffblaster (Talkcontribs)

No. It is not possible to translate this page now. Like Dcljr mentioned above, perhaps the Flow extension will support this in the future.

Besides, like most open source projects, all development for Gentoo is performed in the English language.

Summary by Maffblaster

New template Confused to make Wikipedia-like "Not to be confused with" recommendations.

Dcljr (Talkcontribs)

I've created Template:Confused (but not added it to any articles yet) to allow for simple disambiguation of easily confused topics (for cases where the names are similar but not the underlying concepts). See the template itself for further explanation. Comments? Objections? (These can go on the template's talk page; I'm watching it.)

Charles17 (Talkcontribs)

Maybe useful also for ebuild, the portage command and the file format?

Dcljr (Talkcontribs)

Hmm. Those two might be too closely related to simply tag with {Confused}. It would probably be better to explain the difference explicitly in the lead section(s). (In fact, ebuild already does this.)

Maffblaster (Talkcontribs)

Works for me. I imagine this template will be helpful as the wiki grows. Good work!

Dcljr (Talkcontribs)

I've now placed this template on all the articles that I think can (possibly) use it. I've been a bit "generous" (some may think too generous in some cases) in my choices. Keep in mind that this is for the benefit of readers who don't have a lot of experience with Gentoo or Linux in general.

I wasn't sure how best to make this work with the Translate extension, so someone more familiar with that extension might want to check my placement of the template in articles (like GPM) that are marked for translation.

Maffblaster (Talkcontribs)

I think it is working well. Thanks for your efforts here!

New version of Template:Tl

Summary last edited by Dcljr 23:21, 21 February 2017 21 February

New version of Template:Tl at Template:Tl/sandbox. Admin can copy it over the old Tl template if desired.

Dcljr (Talkcontribs)

I've made a new version of {{Tl}} in its sandbox that is more flexible than the current one. If we decide we want to use it, an admin will have to copy it over to Template:Tl because that page is edit-protected. Interested parties, please see Template talk:Tl for details, and comment there, if desired.

Maffblaster (Talkcontribs)

Great. Thank you!

Summary by Dcljr

This template (now a built-in magic word) is indeed working properly

Dcljr (Talkcontribs)

Template:! is well and truly broken (see its testcases). More precisely, it has (apparently) been rendered moot by the built-in magic word {{!}}, which was introduced in MediaWiki version 1.24 (we are running 1.26.2-gentoo).

You can see the various ways I've tried to fix the template in its page history. Nothing has worked — and in fact even trying to make it output the simple word HELLO? didn't work. So clearly the template is not going to work under that title.

I propose we delete the template and see if the magic word starts working in its place (it obviously isn't at the moment). If that doesn't work, then we can just create a new template under a different name. (That the latter approach will work is attested by the fact that Template:!/sandbox works, even though its transcluded content is identical to Template:!.)

BTW, I started to discuss this on the template's talk page, but no one noticed, apparently.

Maffblaster (Talkcontribs)

I've suggested you use IRC to ping people in order to help wiki admins notice things... :)

I'll look into this when I get some time.

Dcljr (Talkcontribs)

Sorry, I don't use IRC.

Dcljr (Talkcontribs)

OK, upon further investigation, I see that the "magic word" {{!}} is indeed working as it should. I thought it was not working properly because I neglected to take into account that template testcases are rendered inside of tables, which is the very context where {{!}} behaves like wiki markup (not "escaped" or "nowiki'd" text). (Duh.)

I'm now creating alternative templates to allow for displaying a "visible pipe" that will (hopefully) never be parsed as wiki markup, for use in cases where that is the desired behavior.

Because nothing on the page Template:! has any effect on the results obtained when using {{!}}, that page can either be deleted or not — or even redirected, as done on some Wikimedia wikis. My current recommendation, however, would be to leave it alone and simply explain the situation in it's documentation (something I have started to do).

So, in the immortal words of Emily Litella… Nevermind.

French handbook: the "bookmarks" bar is no longer displayed!

Summary by Feng

The page should be refreshed!

Feng (Talkcontribs)

We can see at this URL: that the bar is no longer displayed! I noticed this one after a few editions. Unfortunately, I don't understand why the bar is not displayed correctly?

Feng (Talkcontribs)

Problem solved!

Feng (Talkcontribs)

The problem can be solved by refreshing the page after a translation. Go to the "Page Tabs": click the button "more" and finally click the button "Refresh".