FlightGear wiki:Village pump: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 223: Line 223:


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 :)
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 :)
--[[User:Manfred|Manfred]] ([[User talk:Manfred|talk]]) 11:55, 25 March 2014 (UTC)

Revision as of 11:55, 25 March 2014


Archives
2012

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
Cquote2.png

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)
  • 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).
Thanks,
—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)

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.


Thanks

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)

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)