FlightGear wiki:Village pump
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.
So far I have only added it to the latest header though.
Happy browsing! :-)
MediaWiki updated to 1.24.1
I've updated MediaWiki to the latest stable release (1.24.1) today. There is a small issue with some of the extensions not displaying icons, so some of them have been disabled for the moment. I hope to have them re-enabled later today. Please report bugs if you find any. For a list of changes, see https://www.mediawiki.org/wiki/Release_notes/1.24
- It seems that Nasal syntax highlighting via Geshi is no longer working (I think it was Philosopher who came up with the module...)?
- --Hooray (talk) 15:58, 1 February 2015 (EST)
Support SVG file
Is there some securty issues/software limitations (no plugin's installed) why the wiki don't support uploads of SVG images?
If you find missing images
In case you find missing images have a look at this page: FlightGear wiki:Missing images.
Given the recent interest in doing embedded development related to FlightGear (Arduino/Rasberry PI), I was thinking that we might want to introduce dedicated portals for such use-cases, to keep things neatly organized, but also to provide a place to grow this further - e.g. depending on how this goes, we could have portals covering:
- Embedded/Hardware (including cockpit building)
Equally, we may want to provide sub-forums for these two topics, which should help clean up the offtopic/development forum, too. Currently, the SUPPORT/HARDWARE forum is being used for many of these topics, even though that was originally intended for joysticks/yokes and pedals related stuff - not custom hardware, which would fit better under DEVELOPMENT in my opinon.
As far as I can tell there are roughly 10-15 contributors actively exploring embedded development including UAV stuff - so I guess it would be a good idea for the project (i.e. the forum and the wiki) to provide some structure to "house" such efforts.
Wiki extensions observations
Recently I was looking at the installed extensions, and noticed the below:
- It appears that it doesn't work anymore on this wiki. For instance, the below code …
<sgallery> Glass01.jpg Glass07.jpg Glass11.jpg </sgallery>
- … causes the following error:
- Notice: Undefined variable: args in /home/wiki/wiki/extensions/SmoothGallery/SmoothGallery.php on line 113 Fatal error: Call to undefined method LocalFile::getThumbnail() in /home/wiki/wiki/extensions/SmoothGallery/SmoothGalleryParser.php on line 208
- This could be related to extension's bugs.
- I suggest this extension be removed because
- As far as I know, it's not used on any of the wiki's pages.
- Is it needed?
- Its unstable as of 22 March, 2015, which means it's broken and shouldn't be used (link).
- According to the page revision as of 16 March 2015, there were XSS flaws in version 2.2.4 and earlier of the extension. It should probably be updated to the latest revision.
Boeing 777 Cleanup
Just wrapping up cleaning up Boeing 777 articles that I discussed a full year ago. All now redirect centrally to that page. This makes for a lot less segregated wiki. Looking at it, it would appear that very little happens on the individual pages and the content on them is relatively insignificant. The stuff that is needed I copied over to the main page. Will try to add some pictures as well.
If anybody has any objections, speak up :)
- It would be really useful to merge the pages if the aircraft are similar in many ways, for example:
- All part of the same aircraft package
- Same or similar usage, for example
- Keyboard shortcuts
- Custom dialogs
- Clickable cockpit interfaces
- Same levels of system modeling
- If they could be handled pretty much the same way and was part of the same aircraft package I don't think I would have any objections.
- However, if they differ a lot in the areas mentioned above I think it would not be a good idea to merge the pages; the aircraft would be dissimilar enough that the page would have to be uncomfortably long and possibly confusing if it were to describe the different workings.
- If they are not part of the same aircraft package, looking into the similarities and differences and slowly work towards integrating them into the same aircraft package could also bee a good idea.
Aircraft Page Organization
I just started a topic over on the forum on how posts are organized if somebody has input.
- I think it would probably be better to discuss the quality and organization of the wiki right here (on this very page) than on the forum.
- The main two reasons for that is (1) to keep the wiki quality discussions here and (2) that it would be a bit more transparent to do it that way.
- The transparency is important in that it would make it easier to later look into why things were decided to be in a certain way and who said what and when.
Alright, so here goes:
By the nature of FlightGear, multiple people might work on different projects covering the same areas. For instance, there are 2 different projects covering the Boeing 787. This makes overview and indexing very difficult. Wikipedia is designed to only really have one article on a topic (i.e. aircraft) that can be extended.
It is dreadfully unclear on the overview of aircraft. In my opinion, it would make more sense to get an disambiguation page on the various 'packages' that contain the A319 for instance. The multiple entries greatly diminishes the value of the list.
Here are a few ideas:
- Give aircraft a codeword or project name. For instance, the Boeing 787 (Dream Project) or Boeing 787 (GPL Project) to distinguish between them. Then list them like that in the index as well. When you both have a --aircraft= A319 and A319-131, what are you going to do when the next person comes around and wants to design an A319? It would make more sense to migrate to a structure of say B787-8-Dream and B787-8-GPL. If you make a piece of software, you're not going to go calling your software 'Conference Manager', with the next person making the similar stuff calling it 'Conference Manager 2', but rather ConferenceTime and and ConferenceMaster. It's easier to do with aircraft but it gets bloody confusing.
- I imagine that perhaps as a bit of a continuation of the above, people try to distinguish between their models by giving them very specific names, such as Boeing 707-338. I realize that people want to work on it themselves, but from a broader perspective, how much technical difference is there really between these? The A319 should also work with the corresponding changes as a A320- it is an identical cockpit and much the same fuselage. IMHO, it should have been filed as an A320 instead with only one model, an A319. As for the Boeing, give it a codeword, such as Boeing 707 (Qantas Project). It even makes it more marketable.
- Clearly distinguish between current and past development in the template, i.e. add a new index on the left that contains both categories. I find that not doing any work on the model in five years qualifies for past development.
The ability to grow is proportional to the ability to handle the increase in information. While this perhaps happens mostly on aircraft articles, what happens if somebody wants a fresh start on that airport scenery? How does he name the page and organize it in relation to the current one? It would have been easier to name both after some town landmark so one the second one came around, you could easily categorise them.