FlightGear wiki:Village pump

From FlightGear wiki
Jump to navigation Jump to search

2012, 2013

Welcome to the Village Pump. This page is used to discuss the technical issues, operations and guidelines of the FlightGear wiki.

Please add new topics to the bottom of this page.
Old discussion should be moved to a FlightGear wiki:Village pump/Archive YEAR. These discussions can then be moved to a relevant talk page if appropriate.

MediaWiki updated to 1.22.0

I've updated MediaWiki to the latest stable, 1.22.0 today. Please report bugs if you find any. For a list of changes, see https://www.mediawiki.org/wiki/Release_notes/1.22

Gijs (talk) 15:00, 26 December 2013 (UTC)

Found bugs

  • Clicking the category link at the bottom of some articles will give a fatal error. For clicking the Category:FlightGear at FlightGear will give the error message: Fatal error: Class 'Services_JSON' not found in /home/wiki/wiki/extensions/CategoryTree/CategoryTreeFunctions.php on line 224.
Johan G (Talk | contribs) 03:44, 28 December 2013 (UTC)
The CategoryTree extension relies on a function that was removed as of 1.22.0, so the extensions needs some fixing. I've disabled it for now.
Gijs (talk) 13:01, 28 December 2013 (UTC)
Yay, CategoryTree is back. Thanks Gijs!
Johan G (Talk | contribs) 19:50, 6 May 2014 (UTC)
  • Also, the mobile theme results in an error: Fatal error: Call to undefined method MobileFormatter::setHtmlMode() in /home/wiki/wiki/extensions/MobileFrontend/includes/MobileFormatter.php on line 62 (works fine after selecting desktop mode).
—Philosopher (talk) 03:59, 28 December 2013 (UTC)
I forgot to update the mobile extension. Works again ;-)
Gijs (talk) 13:01, 28 December 2013 (UTC)
--Bigstones (talk) 00:27, 11 May 2014 (UTC)
Unfortunately that doesn't seem to help...
Gijs (talk) 11:11, 11 May 2014 (UTC)

Got any ideas for a better name for this page?

As this is for this page in particular, see the talk page.

Johan G (Talk | contribs) 15:44, 5 March 2014 (UTC)

Template for announcement of changes and new features

From a forum PM from Hooray (posted here with his permission):

hi, whenever we announce a new feature, we typically need to do this in three places:

  • newsletter
  • changelog
  • the docs (corresponding wiki articles)

so far, we have always copied & pasted things, I would prefer to have a single template for this instead, something like {{Announce|version|description}}

This could add announcements to each release cycle (i.e. 3.2 currently), and we could maybe automatically add things to the newsletter and the release changelog.

Like I said, I would like to avoid redundant efforts, i.e. less copy & paste

Do you have any ideas on how to implement this using existing wiki means ?

Ideally, we would create a new announcement, like for example "canvas mouse button support", and could then use this announcement in all 3 places by calling the corresponding template.


My take is that to use a separate template for each new feature is not a good idea, but if I understand him correctly his intention is to gather up each months new features in one template.

Any thoughts on this?

Johan G (Talk | contribs) 17:14, 5 March 2014 (UTC)

WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.
I am thinking of restructuring the way we're writing our newsletter by focusing on our "ugly stepchild", namely the "changelog" - as others like Torsten have pointed out, we should ideally be writing the changelog as early as possible - but the truth is, it's mostly forum people contributing to it, and it's not seen too many edits. The newsletter is working a bit better for us. So I was thinking of how to unify both worlds - especially keeping in mind that our changelog encompasses basically 6 months, i.e. 6 newsletter editions. 

So I am considering to split up our newsletter into a handful of building blocks and use a few templates, so that additions are added through a few custom templates, that would automatically add things to the changelog.

The changelog would then be written by contributing to the newsletter  and using the proper templates, such as e.g.:

{{changelog|version=3.2|category:aircraft|type=updated|announcement=The 747-400 and 777-200 have received extensive updates, and are now both using the new MapStructure-based NavDisplay framework|screenshots=|videos=}}

The changelog would then  be procedurally assembled by processing all templates for the corresponding release cycle.

I would even consider locking the changelog itself, and making it just a template that references the stuff included via templates.

We may however benefit from a few additional mediawiki extensions. But otherwise, I am hoping that the changelog is going to be more comprehensive, while the wiki would become more "formal" - we could obviously still support additions without using changelog-templates, i.e. those would be excluded.

thoughts / ideas ?

(CC'ing Philosopher, because he's been doing some template stuff, too)

Need to come up with a template that handles announcements, primarily for the changelog and the newsletter. There's a mutual relationship here, but the newsletter is much more popular, i.e. sees more contributions and more activity overall. Changelog writing is still a chore. But basically 6 months worth of newsletters are equivalent to a single changelog, we only need to establish some framework around this - and then the whole changelog could be mostly based on newsletter contributions. It would greatly help to request people to make announcements ALWAYS using 3rd person speech, so that things can be directly copied from the forum/devel list to the newsletter/changelog. That's kinda the idea here. It would reduce our workload quite significantly
  • Changelog
  • Newsletter
  • Devel List
  • Forum
  • Website
This unsigned comment was added by Hooray (Talk | contribs) 21:25, 24 April 2014‎ (UTC)
I will probably have to take a look at this now and again to think about if and how this could be done. I assume Hooray is aiming at having each newsletter and change log built up mostly from "instances" of a template like in the above comments.
There are pros and cons with this approach, as with any. I think that one of the cons is that even the slightest overhead and/or complication might scare away a few contributors. But at the other hand I fully understand that reading through six months of newsletters + forum posts + devel list posts are not that fun either (though I would guess that is not how things are done ;-).

Slightly off topic is that I would like to see a section in the change log mentioning changes that will break backwards compatibility. I first saw such a section, "Breaking changes", in the change log of MedeiaWiki 1.22 when the software of this wiki was updated, and figured it would be a good idea. This could be useful for things like for example figuring out whether FlightGear x.x can use World Scenery y.y.
Even more off topic I think that the wiki/newsletter/devel list/etc are rather blunt tools for keeping an up to date change log. My gut feeling is that there are tools for that around, and even if we do not use them we might borrow some ideas from them, hopefully without bringing a lot of red tape(!).
Johan G (Talk | contribs) 20:14, 27 April 2014 (UTC)
Interesting subject! I think going through just 6 newsletters by hand is more rewarding than coming up with complex templates that will increase the entry barrier of the newsletter and still require summarising/rewordings afterwards to fit the concise format of a changelog. Introducing a template on the wiki won't take away the forum/devel list scanning that's required as not everyone contributes to the wiki.
I do support the "breaking changes" idea though ;-)
Gijs (talk) 19:18, 1 May 2014 (UTC)

Very dispersed Boeing 777 articles!

Hi, I got interested in Flightgear and was taking a look at the Boeing 777 articles and noticed that it was incredibly spread out.

Each aircraft has it's own page with information to varying degrees of completeness. Having a look at the A330 articles, they are much more 'aligned' and it's a lot easier to find stuff. Maybe this could be something that could be done with the Boeing. Since both seem to be very similar, I'm thinking that there could be a common page on help and tutorials respectively, with the individual type pages catering to unique information. I started on some stuff but pretty quickly figured out it was a better idea to check here first :)

--Manfred (talk) 11:55, 25 March 2014 (UTC)

Doing a simple search for pages containing "777" (see this link) I quickly see what you mean.
I assume that the different versions may have different authors and thus probably are slightly different from each other when it comes to handling and completeness. It might be a good idea to start by going through each of the help pages and tutorials (preferably while playing with the different aircraft at the same time), as well as having a look at help dialogues and any readmes in the aircraft packages.
Making a common page, while highlighting differences between the different versions, could probably help other users a lot and may perhaps be a help for aircraft developers to use features from more complete versions to improve the other ones as well as help motivate harmonizing handling like for example key bindings.
If I understand your intention I can not see why anyone would do anything but trying to give you helpful hints, after all this is a wiki. :-)
One hint for starters is to begin working on a page as a subpage to your user page, like for example User:Manfred/Boeing 777 Autopilot (I just moved it) and then moving it to the article namespace when you feel it has reached the level where you are comfortable with it (though this is not by any means necessary, it's just that I like doing so myself).
Johan G (Talk | contribs) 16:40, 28 March 2014 (UTC)
I am interested to help, this page could be a model of what we could offer : 777-8 Dreamliner
-- F-JYL 21 April 2014 09:32

Bash and DOS syntax highlighting

Daemonburrito found that we can use syntax highlighting for Bash. I guess that means that we could use syntax highlighting for most Linux (and possibly also Mac) command lines. Looking at mediawikiwiki:Extension:SyntaxHighlight_GeSHi I find that we also also probably can use that for DOS prompts.

Johan G (Talk | contribs) 07:24, 5 May 2014 (UTC)

We've had that extension installed for a while now. Everything that's listed at Supported languages is supported, plus Nasal.
Gijs (talk) 11:23, 5 May 2014 (UTC)
I'm aware of the list, but was not aware that syntax highlighting could be used for shell programming (and hence shell promts) and guessed I was not alone.
Basically added the topic to highlight (pun intended) the possibility to do so. I should probably also mention it in Help:Formatting#Syntax highlighting.
Johan G (Talk | contribs) 13:53, 5 May 2014 (UTC)

A plan for a reorganization of the wiki

There is an ongoing discussion on User:Bigstones/Essay:A plan for a reorganization of the wiki. Please comment on its talk page, to avoid scattering the discussion. This "section" is only intended to inform about it. --Bigstones (talk) 12:53, 7 May 2014 (UTC)

The new progress bar icons

I just changed icons that {{progressbar}} is using and would like some constructive feedback.

Some things I have noted myself is that while I used a blend of the colours used in the old icons and in some of my other icons, these icons have a much larger coloured area and thus might have a little high contrast.

In any way I am going to let this rest for a week or two and follow it up then.

Johan G (Talk | contribs) 01:05, 10 May 2014 (UTC)

After having made them a tiny pixel smaller (from 16 px to 15 px) and having done no other changes I seem to be liking them more and more, so I leave them in their current state.
Johan G (Talk | contribs) 18:13, 24 May 2014 (UTC)


As it seems that support organization is a priority, I created Category:Support. I hope the name is generic enough to avoid misunderstandings... but I thought better to have a bad one, than nothing. I'll try to put there everything on support I find so that it can be better organized (merged/split and then cleaned up). --Bigstones (talk) 13:06, 11 May 2014 (UTC)

I didn't read through all of your ideas yet, but isn't "Support" a rather obscure term? Everything could fit under that branch, so we'll end up with yet another giant category; which you tried to prevent, right? Or maybe I'm just missing the bigger picture...
Gijs (talk) 13:23, 11 May 2014 (UTC)
Hi, I figured out (edit: led to figure out) that support organization is a major problem. There's a lot of "support" related articles, 2-3 articles only on OpenGL. I hoped that this name could indeed be wide enough, and that in case it could just be renamed. Troubleshooting seemed to narrow to me on the other side, but if you think that would be better I can change it now (waiting for response before proceeding).--Bigstones (talk) 13:29, 11 May 2014 (UTC)
Take Settings for slower graphics cards for example. It's categorised under Category:Performance tuning. I would expect that to be a sub of Category:Support. Anyone looking for articles on how to improve performance can check that category then. I don't expect anyone to go through a very broad category with 100s of articles to find info on a rather specific subject.
Or maybe I should reword my comment into a question: What would be the use case of Category:Support?
Gijs (talk) 13:39, 11 May 2014 (UTC)
PS: I know we have a lot of bloated categories on this wiki, so I'm glad you've brought all this back on the agenda ;-)
With the example: I confess I was probably deceived by the presence of some development related stuff in Category:Performance tuning. I thought it would be better to separate development and usage. Framerate is either a user issue, or a developer's aim. I think the two can be separated. The problem is I moved out the most of it! I should consider the contrary. I'll undo. (I currently have like 20 open browser tabs so it might take me some time).
The use case however is: gather support articles so that a maintainer can split/merge them to make them more organized. Once that's done, there won't probably be more than 10 articles, and if there are, still one can subcategorize. In the above case, I just took the longest path, but given the lack of tools I confess I just wanted to get started.
--Bigstones (talk) 14:00, 11 May 2014 (UTC)
... I must confess also that after undoing, I feel the urge to redo that again. The two non-support related articles, GIT Performance Tests and Howto:Use the system monitor (where btw, the "profiling" section might be directed to core developers?) would have no place if I move this category into support. That's also why I moved it into Development. Let me know what you think, also regarding the Support category name.
--Bigstones (talk) 14:24, 11 May 2014 (UTC)

FlightGear screenshot categories

I have been thinking about this for quite a while. When I was categorising the images, I gave the categories with the FlightGear screenshots quite cumbersome and long names.

I guess the discussions with Bigstones, in particular my reply here (see second paragraph under 2.) might have stirred up some old dust for me. :-)

The cumbersome and long names has a couple negative effects. Firstly they are way longer to type than should be necessary, secondly, and more important I think, the probability that they show up in the upload wizard probably is rather low as they all begin with "FlightGear..." (what was I thinking, like if someone would upload a bunch of X-Plane screenshots here). I guess that by beginning most if not all screenshot category names with "Screenshots of..." the chances they would be used will increase.

In addition to that some of those categories are way too large and need to be diffused (broken down into smaller categories).

I have noted that a lot of aircraft images have been added to the aircraft article categories. I would prefer if the screenshot categories associated with different kinds of aircraft (e.g. fighters or airliners) would be subcategories to the screenshot categories and that those screenshot categories would be a subcategory to the category for those kinds of aircraft. I have at some point started to try mimic the structure of Category:Aircraft by type in Category:FlightGear screenshots of aircraft by type, but got distracted or forgot about it for a while. Someting similar might be needed for the cockpit screenshots.

The note about intended contents should also mention that these categories are intended only for in-sim screenshots from FlightGear.

In conclusion I suggest, and would like feedback on, the following:

Current category Suggested new category Alternative new category Comment
Category:FlightGear cockpit screenshots‎ Category:Screenshots of cockpits Cockpit screenshots
Category:FlightGear cockpit close-up screenshots‎ Category:Screenshots of cockpit details Cockpit close-up screenshots
Category:FlightGear dialogue screenshots‎ Category:Screenshots of ‎dialogues

Category:Screenshots of dialogs in FlightGear‎

Dialogue dialog box screenshots
Category:FlightGear exterior screenshots Category:Screenshots of aircraft Exterior screenshots
Category:FlightGear interior screenshots Category:Screenshots of cabins Cabin screenshots
Category:FlightGear scenery screenshots Category:Screenshots of scenery Scenery screenshots
Category:FlightGear screenshots of aircraft by type Category:Screenshots of aircraft by type Should only contain categories
Category:FlightGear screenshots of vehicles Category:Screenshots of vehicles Vehicle screenshots
Category:FlightGear weather screenshots Category:Screenshots of weather Weather screenshots

In essence it is a huge bot job, except for the diffusion of the largest screenshot categories.

Johan G (Talk | contribs) 15:57, 12 May 2014 (UTC)

As I might have said already, I'm ok with it and in particular I agree that images would be easier to find if in their own branch. The only thing, I think it's not going to last if the upload wizard doesn't enforce the use of a subcat of "Files", or at least, suggests that area in some handy way (i.e. not a written notice). Maybe the CategoryTree could be included (like with templates) to help finding the right category? It's hard to figure out a good one by typing characters one by one.
--Bigstones (talk) 21:49, 12 May 2014 (UTC)
Created the category pages as above, except for Category:Screenshots of ‎dialogues, which I found a bit ambiguous. I named that one Category:Screenshots of dialogues in FlightGear‎ instead.
I have also added a request at the bot talk page (permalink)
Johan G (Talk | contribs) 17:59, 13 May 2014 (UTC)
Did the move to Category:Screenshots of aircraft by type by hand. Was only a few files.
Johan G (Talk | contribs) 18:46, 13 May 2014 (UTC)
I hope I'm not late, I noticed only now, but dialogue tends to be used more as in "discussion between two", while the GUI elements are usually spelled dialogs. I guess that more than real confusion this distinction would cause just minor hilarity, but... you never know, you might find in there screenshots of radio chat with ATC. (being not a native english speaker, here's my ref.) --Bigstones (talk) 19:20, 13 May 2014 (UTC)
Well spotted, good reference as well and most important not too late. Thank you! I was wondering a bit but guessed that dialog was more or less colloquial as dialogue seemed correct with both my browsers English and American English dictionaries. Swedish schools teaching (very!) British English probably have something to do with my spelling as well.
Changed the request on the bot page from Category:Screenshots of dialogues in FlightGear‎ to Category:Screenshots of dialogs in FlightGear‎.
Johan G (Talk | contribs) 14:06, 14 May 2014 (UTC)

Having separate image categories or not?

One thing that keeps nagging me is that all Wikipedias I have been able to read and some I can hardly read (English, Swedish + German and French) have separate categories for files/images. There is probably a reason for that (I am guessing at mainly ease of finding images for articles and possibly also for bandwidth reasons).

The upload wizard is borrowed from Wikimedia Commons (but is it properly attributed?) where pretty much all categories are for files/images. While I am not aware of its technical details I see few if any efficient ways it could be modified to only or primarily suggest image categories. As I see it it would require a fresh and updated list of categories that in one way or another would require some manual intervention.

Two things I have done so far is to re-categorize images and that I have begun trying to link the nodes to the nodes in the branch with the article categories by putting the image categories in the article categories (this is done on a very small scale though).

Questions is though: What is in the best interest of the users? Should I keep on having them separate or should I just let it grow wild(er)? It could be an interesting experiment though it would require a lot of work if it turns out less favourable.

Johan G (Talk | contribs) 22:02, 10 July 2014 (UTC)

I saw you implementing this at some of my airport screen-shots and immediately adopted it on other images. I think your idea of separating those categories would help us puting a link at the end of each article which says: "Media about :XY". Thats why I think all the other wikis provide separated categories. That's the only way to get linkable categories which only contain media.
--August (talk) 22:18, 10 July 2014 (UTC)

Conventions on discussion conclusions

Sometimes proposals don't get the attention the proposer might have hoped for. Of course, everyone's involved in their projects, and following discussions in "recent changes" isn't easy, so nothing personal, my question is very practical.

Sometimes these proposals need help from others (like my "remove redundant categories") so it's pretty clear that one will have to wait and retry/insist for that. Some other times though (like my above "Category:Support" topic - with which btw I did some mess moving messages around) one could easily continue on his/her own. In such cases, I feel that lack/loss of attention means "Ok, I don't mind if you do that, in case, we'll discuss the results" (like for the FAQ update - btw, thanks to the reviewers of my cuts). If this is correct, I'd like to add it to the Help:Maintenance page, because it could help getting more things done and avoid misunderstandings. Oh, and by what I said, if I don't get answers, I'll take it for granted :D

--Bigstones (talk) 12:43, 13 May 2014 (UTC)

I have found the lack of feedback to be discouraging at times, but at other times I have just went ahead and done things the way I would like to have them done, like for example my reorganisation and extension of the help pages, as well as adding the "Discuss!" link to the left side menu.
I would guess that you draw the right conclusion with the statement that "Ok, I don't mind if you do that, in case, we'll discuss the results". The very most of the times that is the way to go. The good thing with a wiki is that it is so easy to revert a change (i.e "View history" tab → Go to topmost edit → Click the "undo" link). If if things go really wrong most things can be salvaged from the page history (though it can be a lot of work at times). ;-)
Johan G (Talk | contribs) 17:03, 13 May 2014 (UTC)

Editing JavaScript files ?

Moved here from Talk:Portal:Wiki#Editing JavaScript files ? (permalink) since this might affect all users.

I think, at some point, I saw someone editing JavaScript files here (Johan_G or Gijs probably) - what is involved to do that ? Any links/pointers ? Okay, found something at MediaWiki:Common.js Is it also possible to create custom JS/plain text files without any wiki markup ? Are my privileges even sufficient ? --Hooray (talk) 21:11, 2 June 2014 (UTC)

Nope, was not me. Javascript files is as far as I know currently limited to MediaWiki:Common.js. It is apparently possible to change some settings so that one can add "user javascript pages" (as well as "user Cascading Style Sheets"), see the WikiMedia Wiki pages Manual:$wgAllowUserJs (and Manual:$wgAllowUserCss).
Both can be useful for testing stuff before including them in the "common" (i.e. site wide) files, as well as for personalizing the look, feel and functionality. I do not know what issues they could cause or if we have the permissions to change it. Maybe Simon and Gijs are the ones who can do it.
Johan G (Talk | contribs) 04:40, 3 June 2014 (UTC)

MediaWiki updated to 1.23.0

I've updated MediaWiki to the latest stable release (1.23.0) today. I'm now updating all extensions, so some things may be broken temporarily. Please report bugs if you find any. For a list of changes, see https://www.mediawiki.org/wiki/Release_notes/1.23

Gijs (talk) 12:04, 8 June 2014 (UTC)