FlightGear wiki:Village pump

From FlightGear wiki
Revision as of 17:03, 13 May 2014 by Johan G (talk | contribs) (→‎Conventions on discussion conclusions: The lack of feedback can be discouraging, but usually the right thing is to go right ahead. If not for else changes are often easy to undo ;-)
Jump to navigation Jump to search


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.

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

  1. g, Shift+G, Ctrl+g and Alt+g
  2. g, Shift+g, Ctrl+g and Alt+g
  3. 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)
Not fixed yet, so here is that gentle reminder. ;-)
Johan G (Talk | contribs) 19:38, 27 May 2013 (UTC)
Done! Sorry for the delay.
Gijs 12:44, 2 July 2013 (UTC)
Sorry Gijs, but try that while not logged in. It still does not worked for visitors not logged in.
Johan G (Talk | contribs) 10:23, 3 July 2013 (UTC)
Oops, fixed now ;-)
Gijs 14:21, 21 July 2013 (UTC)
Confirmed working today. Thanks Gijs (and Simon?)!
Johan G (Talk | contribs) 20:40, 21 July 2013 (UTC)
Hmm, I don't think searching only in the HowTo namespace when not logged in qualifies as working
I4dnf (talk) 18:50, 28 July 2013 (UTC)
Working now, thanks Gijs?
I4dnf (talk) 16:12, 31 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!

Johan G (Talk | contribs) 18:27, 31 October 2013 (UTC)

Some initial thoughts, mostly copied from above, can for now be found at User:Johan G/Unification and improvement of maintenance templates.
Johan G (Talk | contribs) 20:30, 1 November 2013 (UTC)
A list of the very most of the message box templates, which include many of the maintenance templates have been put together in Help:List of messagebox templates.
Johan G (Talk | contribs) 22:11, 6 November 2013 (UTC)

Moving around contents in the help articles

I am considering moving around some stuff in some of the help articles. More or less moving most of the current Help:Your first article] to Help:Tutorial and the current Help:Tutorial to Help:Editing.

First off, the current Help:Editing is a two-edit stub. The current Help:Tutorial though is all about editing, so I would consider it quite ok to delete the current Help:Editing and move Help:Tutorial there. That would leave Help:Tutorial as an empty redirect page which could the be rewritten into a tutorial about what a wiki is and how to efficiently use and contribute to it. The tutorial should probably also mention what this wiki is about, which just so happens is what Help:Your first article is all about (it actually only mentions how to create a new article in a few sentences at the end, and doesn't touch things like selecting a good title or wiki editing at all).

After all this Help:Tutorial would be a tutorial on how to use the wiki's different features such as page histories, discussion pages, categories etc, Help:Editing would be about, well, editing, and Help:Your first article would be about what to write about, what to think of when choosing an article name, the basics of editing, and the advantages of categorisation.

With all that done I think the new users that have been lurking a bit would get a slightly better start as well as give us a better starting point to direct the other ones to.

Any further thoughts or ideas is welcome.

Johan G (Talk | contribs) 18:58, 23 November 2013 (UTC)

I have now deleted the old Help:Edit and moved Help:Tutorial over there. I have also started rewriting it.
Johan G (Talk | contribs) 23:20, 28 November 2013 (UTC)
The rewrite of the new Help:Edit (former Help:Tutorial) is now nearly complete. What is left to do is moving some of the text to more fitting articles, probably the new Help:Tutorial, and probably some rephrasing here and there and fixing a few typos.
Johan G (Talk | contribs) 02:46, 30 November 2013 (UTC)
I have now moved Help:Editing to the more common Help:Formatting, moved the former Help:Your first article to Help:Tutorial, and made a entirely new Help:Your first article which is more to the point.
What is left is rewriting the new Help:Tutorial to be more general about the wiki, and find a way to make all the potential translators aware of the big changes I have done (which probably have made for a big mess).
The next time I do something this big I will probably announce it in the Newsletter as well as here to get a bit more response and opinions (this page is still way to obscure).
Johan G (Talk | contribs) 22:54, 8 December 2013 (UTC)

Style guide

I have begun work on a Help:Style guide and welcomes opinions, thoughts and suggestions on its discussion page and additions on the page itself.

Johan G (Talk | contribs) 01:15, 9 December 2013 (UTC)

Automating Template:Git status

Cquote1.png @Johan_G: it would be AWESOME if you could come up with some template magic to automate the whole GitStatus stuff :-)
— Hooray

I got sort of a request from Hooray on automating {{GitStatus}}. I believe this can be done with parser functions and "magic words" (yes, they are actually called that).

Judging from the release plan there are some fixed dates when the status changes (Open from Jan/Jul 17th, frozen from Dec/Jun 17th and closed for a few hours around 12:00 UTC Jan/Jul 17th).

My question is how long it should be shown as being in the closed status? Could I arbitrarily set it to that status for 12:00 UTC ± 2 hours or even for the entire day (which would be much easier)?

Johan G (Talk | contribs) 06:11, 22 December 2013 (UTC)

sure, why not - let's keep it simple for now. Previously, the template hasn't been updated in months - so being off by a day (or even a week) would still be an improvement - if someone doesn't like it, it can still be improved later on. BTW: thanks for looking into this !--Hooray (talk) 09:03, 22 December 2013 (UTC)
Why would we need to update a status template when the status doesn't change? Remember that there's 5 months between frozen and the next frozen. {{GitStatus:frozen}} isn't supposed to show all states, it only shows the frozen state and should thus only be updated once every 6 months...
Anyhow, automating it is easy-peasy. Done Done The closed state needs to be set by hand, because it doesn't have a fixed time frame.
Gijs (talk) 14:05, 22 December 2013 (UTC)
right, that's better now - but as can be seen in the history of the template, this hadn't been updated in months - of course, these things are fairly trivial, but we only need to look at our duties here to see that "automation is key" - otherwise, we would still need to document everything that cannot be automated and work through all open items - personally, I would even wan to lock the newsletter automatically at the end of each month, after 3-7 days, and copy the new template to current month if it isn't there already. --Hooray (talk) 16:32, 22 December 2013 (UTC)
You keep saying that "it hadn't been updated in months", but why/when did it need an update? The status of the repositories has been "open" ever since July 17, so I didn't expect any updates until December 17, apart from my edit on September 22 to bump the next version number.
Gijs (talk) 16:54, 22 December 2013 (UTC)

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)


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

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)