FlightGear wiki:Village pump/Archive 2013

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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

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

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.