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.
- Discussions older than seven days (the date of last made comment) should be moved to Village Pump/Archive. These discussions can then be moved to a relevant talk page if appropriate.
A wiki newborn
I'm excited to see the new portal layouts and this central discussion place I have been awaiting quite some time. I'm looking forward to see this page in full action in the future, and I hope it will bring many insights and meaningful and creative discussions.
I'm also hoping that the new layout will attract new editors, and help them gain confidence while editing and enhancing the wiki.
Welcome, new and seasoned, enjoy you time here, and may your time be well spent. :-)
—Johan G (Talk | contribs) 07:04, 4 May 2012 (EDT)
Scenery screenshots category
Hi,
I'm not so sure about the scenery screenshots category. Looks like the idea was to include all images that show some scenery. To me, it would be more logic to include only screenshots that show a significant amount of area, or that are really focused at the scenery. Just some examples of screenshots that aren't "scenery screenshots" in my opinion:
What do you think? All of these are already included in Category:FlightGear exterior screenshots, which is be sufficient IMO.
Gijs 16:41, 16 May 2012 (EDT)
- I have sometimes been thinking about that, mostly due to the scenery being completely dominated by an aircraft. The same goes with the weather screenshots category as well. Maybe I should limit myself to the images that shows significant scenery, like e.g. an airport behind a climbing aircraft when the aircraft is rather small in comparison to the airport. The same goes for weather.
- Maybe we should add some guidelines to those category pages and try follow them; stricly speaking pretty much all screenshots, cockpit and external, show either wheather phenomena, scenery or both. ;-)
- I have now removed some of the more misplaced images from the weather and scenery categories.
Modifying Aircraft
Need to add "Modifying existing aircraft" this can cover tire smoke, adding instruments etc etc Also link to the list of How Tos ?
Openflight 04:32, 22 May 2012 (EDT)
- I'm not quite sure that I understand what you mean. The tyre smoke article etc. are listed in Portal:Developer/Aircraft...
- Gijs 08:12, 25 May 2012 (EDT)
As usual I need to clarify: OK I have been looking at the new improved Wiki home page several times now, and, although there are many improvements, it still seems to me that it might be better to have two separate sections, in the view of the comment "We encourage new aircraft developers to start their 'career' by modifying and enhancing existing aircraft. ": that is, two separate links to two sections on the main page http://wiki.flightgear.org/Main_Page
Modifying existing aircraft
Creating new aircraft
from the main page.
Many of the how tos etc can go into one or both categories. My concern is that a new user will see the link "Developing Aircraft" and think " I don't have the skills to develop aircraft so forget it"
Instead there could be two links - "Developing new aircraft" and "Modifying existing aircraft" which would encourage the new user to dabble a bit. Maybe two separate portals?
This may involve a lot of work and editing? I am willing to help. Actually I would love to help.
Openflight 01:40, 7 June 2012 (EDT)
Reviews at the wiki?
In a topic on the forum Your joystick(s) and how well they work with FlightGear Stuart suggested that such reviews would be worthwhile to have on the wiki. What do you other editors think about that? Should they be placed in [Hardware ]Review: <insert product name here>, or, should they be here at all? A Hardware review category should be great if we would have such reviews.
Anyway, I have added a review of my setup on my user page.
—Johan G (Talk | contribs) 01:01, 24 June 2012 (EDT)
- This a great idea for the wiki. As I suggested in forums, I think also is a good point to create a pilot hardware partnerships with FG. For example www shops that can offers discount for the FG users, maybe with a bundle - customer buy a yoke and can download FG, maybe including a CD. I think FG has the best ratio of teenagers entry. While MSFS people is getting older FG is getting younger. The future is FG. Thanks to FG, new users can use mouse, but soon they want a yoke. That is what I experimented with new FG users. Without to know, FG is moving market. I thinks is a good opportunity to give money to the project independent of brands,. In fact my "buy a yoke daddy" slogan is based in that experience. More than 20 pilots that I know were searching for a joystick around 15-30 days after meet FG for first time.
- Also I always though to focus in the free hardware joystick companies. If they exist. Improving free ecosystem.
- —Aepcam (Talk | contribs) 04:34, 24 January 2013 (UTC)
Help needed with Howto:Edit a livery
See Howto talk:Edit a livery#Help needed with xml etc. —Johan G (Talk | contribs) 21:12, 4 March 2013 (UTC)
Semantic MediaWiki
Just a possible suggestion for the FlightGear wiki. It's called Semantic MediaWiki, it's a fairly easy to install extension that will bring more semantic data to the wiki. For example, you could organize Aircraft with more than just categories. You could define an Aircraft term and any time it's tagged or referenced to it's term you begin gettin stats you don't get with normal mediawiki. I use it on a private wiki to where I am constantly referencing a question term in the content. Something like [Question:What is Sematic MediaWiki?]. What I end up with are stats that tell me that I've asked 642 questions etc. It's just a way to bring more meaning to the wiki. If you understand what Semantic Web is you should understand the value this could bring.
Anyway, here is a link: http://en.wikipedia.org/wiki/Semantic_MediaWiki --Kaleblex 16:32, 29 March 2013 (UTC)
Keyboard shortcut conventions
To better illustrate keyboard shortcuts and key combinations, and to make them easier to find on a page, I have recently created the {{key press}} template. I am worrying about a potential problem related to conventions regarding how keyboard shortcuts are written.
In the FlightGear community the use of the shift key has often just been signified by using a upper-case letter and otherwise using lower-case letters. My template was meant to mimic key caps, so I had the intention to only use upper-case letters and signify the use of the shift key by showing it instead, in essence g and G would become G and ⇧ Shift+G, which in my eyes was the only convention out there. However, only hours had passed since I implemented it in all places i could find before some of them was changed to g and ⇧ Shift+G. That considered, it might be better to only use lower-case letters as i see less risk of confusion because I am sure someone will write G instead of ⇧ Shift+G.
Finally, I am a strong believer in that consistency will make things intuitive, so my question is: What convention should we insist on in documentation, always use and persistently change to (preferably not 1.):
- g, ⇧ Shift+G, Ctrl+g and Alt+g
- g, ⇧ Shift+g, Ctrl+g and Alt+g
- G, ⇧ Shift+G, Ctrl+G and Alt+G
I am leaning towards 2, but could probably be persuaded given good enough arguments.
—Johan G (Talk | contribs) 19:53, 29 April 2013 (UTC)
Default search should include the Howto namespace
Default search namespaces should include both the article namespace and the Howto namespace. Currently the Howto namespace (in essence all articles beginning with the namespace prefix Howto:) is slightly hidden unless you know what to look for, and even then you forget that at times.
For registered users this is easily fixed by setting the search options on the the preferences page to include the Howto namespace in searches. For unregistered users this is yet another reason they sometimes wont find what they are looking for (unless the Howto page is linked from another page).
—Johan G (Talk | contribs) 15:43, 16 May 2013 (UTC)
- Ouch, that's pretty stupid. I've asked Simon to fix this. Please remind us if it isn't fixed by the end of the week.
- Gijs 12:08, 20 May 2013 (UTC)
- Done! Sorry for the delay.
- Gijs 12:44, 2 July 2013 (UTC)
- Oops, fixed now ;-)
- Gijs 14:21, 21 July 2013 (UTC)
iPod compatibility?
I use my iPod a LOT and have noticed since registering that the box for editing is rather incompatible with the iPod. It's slow, heavy, and inefficient. Now the one over at the forums works better and crashes Chrome a lot less -- is there a way to improve this or copy it from there? I'm not a web developer, so I don't know, but it would really help and would increase the number of my contributions. Thanks!
Philosopher 21:42, 19 May 2013 (UTC)
- According to wikimedia, there's a "mobile theme" available which also provides IPod support:[1]. To check if the theme works for you, go to http://en.m.wikipedia.org/ Probably something for Gijs to look into. --Hooray 00:34, 20 May 2013 (UTC)
- Lol, that's the same but worse: when you go to preview changes it take you to the current site in the mobile theme! (instead of a previews either the desktop or mobile themes – it doesn't have a mobile theme for history or edits.) Anyways, just having a different text box would be O.K., no need for full-blown theming. Philosopher 01:28, 20 May 2013 (UTC)
- The MediaWiki people are working on built-in mobile support. I prefer to wait for that, so we'll get it in our normal updates.
- Gijs 09:59, 20 May 2013 (UTC)
FlightGear Newsletter
As of now it seems that the list of latest articles, using <DynamicArticleList> tags is broken and none of the list are rendered. Which brings me to the next topic: I was going to comment that on the talk page, but as of now the talk page is sort of a template for the next newsletter.
Maybe it would be better to have the next newsletter as a pure template which could be substituted, like {{subst:name of template}}, or maybe only needing a mouse click to get started like:
[{{fullurl:FlightGear Newsletter {{CURRENTMONTHNAME}} {{CURRENTYEAR}}|action=edit&preload=Talk:Next_newsletter}} Create next newsletter].
The caveat of the last solution is that there must only be the text to be included on that page, so it would have to be on a subpage to the template page which in itself would only have the documentation.
—Johan G (Talk | contribs) 15:30, 23 July 2013 (UTC)
- The dyanmiclist issue is caused by our update of MediaWiki yesterday. Takes a while to update and re-configure all the extensions accordingly.
- I don't understand your Newsletter template suggestion(s) though. There are various places that link to the next newsletter, so adding a creation link to a template on one of them isn't going to do much. I would say it isn't worth the hassle, but feel free to code something :-) To prevent stuff from being included in a template, use
<noinclude>. - Gijs (talk) 15:37, 23 July 2013 (UTC)
- If you can come up with a flexible template that helps us to implement the newsletter more easily, I will surely help adopt it - my wikimedia template skills are just pretty basic, as Gijs can confirm ... so I haven't bothered to look into it, but even just having an automated way to lock newsletters at the end of the month and create new ones automatically would be helpful.--Hooray (talk) 17:01, 23 July 2013 (UTC)
Unification and improvement of maintenance templates
I feel that there is a bit of a need to unify the maintenance templates. I am thinking in the direction of:
- Having a main template for their layout, a few classes of them depending on their importance. For example is speedy deletion, {{Delete-sp}}, more important than work in progress, {{WIP}}.
- All of them should have parameter for time stamping, probably mith month and year, and be added to a dated category, like Category:Articles considered for deletion as of February 2013. Knowing that something has been amiss for a long time is probably a good incitement.
- All of them should have a parameter with a link to a talk page if needed, since there might be sometime before someone else will try fix the reason for the template. Also what is obvious to one may be anything but obvious for someone else.
- Named parameters should only be used when needed (though using named parameters would for example probably be very helpful when using a bot for time stamping). This to speed up filling in parameters.
- There should be a copy-pastble example with as much as possible already filled in in the templates documentation.
- I think it could be nice to have a slight bit of humour and self distance, in that the icons and texts could be a bit into flying terms, though not more than that someone not into that would understand what they are about.
In some cases there seem to be some need for a style guide. What is for example "the wiki's quality standards", as mentioned in {{cleanup}}? However, that is another discussion altogether.
Comments, questions and suggestions are welcome!