FlightGear wiki:Village pump/Archive 2016

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.

Welcome template?

I have been thinking about suggesting a welcome template, for example named {{welcome}}, to place on top of (at least) new users user discussion pages.

It should welcome the (new) user

In addition, it should probably mention and/or link to pages mentioning:

The introduction page/tutorial (Hmm, I do not think I did finish that one. See Help talk:Tutorial (perm)).
Help pages
How to use categories (in particular not like #tags, ;-) but also that image and article categories should be separate, but link to each other)
The portals
The style manual
Discussion pages and where to discuss what:
- How to use discussion pages
- The wiki in general: The village pump (this page)
- Wiki articles: Article discussion pages
- Wiki user actions: User discussion pages

Maybe it should also mention that FGAddon aircraft, effects, other features etc. (except for their articles) and their bugs should be discussed on the forum, unless developers say otherwise, and that core features should be discussed on the developer mailing list and core bugs on the bug tracker.

—Johan G (Talk | contribs) 20:31, 30 January 2016 (EST)

I think this is a great idea. A nice concise summary with links to help a new user navigate the FlightGear jungle would be a great addition. It should however remain very short with simple sentences - while being complete - as many users are not native speakers. So maybe there should be translations of the template with manually added links at the bottom for easy access to all the translations?

Bugman (talk) 03:35, 12 February 2016 (EST)

Regarding an introduction article, I have come to the conclusion that a complete but long article is probably not as helpful as short but specific help pages. In essence the latter would be easier to navigate and absorb. I have therefore started to slowly split up some of the help pages and have added one more section to Help:Contents.

I think that a welcome phrase, a link to that page and the style manual might actually suffice for a welcome template for now. It is at least better than what we currently have (i.e. more or less nothing).

—Johan G (Talk | contribs) 14:47, 4 March 2016 (EST)

I now consider

A Welcome message
A link to this page
A link to the help pages
A link to the manual of style
Some final welcoming words

A welcome template should probably also very briefly mention a pet peeve of mine: the categories.

Many (if not most) image uploaders seem to treat them like tags, but if say all screenshots of aircraft (probably >2000) would end up at Category:Aircraft (instead of under a subcategory to Category:Screenshots of aircraft), of what use would that page be when looking for a specific one? If people would like to be able to search for an aircraft, a concise but comprehensive image description is very hard to beat.

How do I convey all that in a way that is, short, to the point and easy to absorb (and act by)? And where is the best place?

—Johan G (Talk | contribs) 02:46, 8 March 2016 (EST)

An early draft is now at User:Johan G/Template:Welcome to the wiki

—Johan G (Talk | contribs) 02:52, 18 April 2016 (EDT)

Some comments on the draft:

* I'm not fully sure about using a prominent box - I think it stands out a bit too much. Wikipedia uses a simple thread on the Talk page

; as an alternative, we could use lighter colors.

* I've also expanded the text a bit. My proposal would be (I've put it in a box, but I'm for the "thread" solution):

File:Example.png

Welcome to the FlightGear wiki, Village pump! We hope you will enjoy your stay!

See Reading to learn how wikis work. You can also browse the existing page categories.

Should you wish to create or edit some articles, do so! Here are some resources to get you started:

How to edit pages
Discussion pages, where we discuss and agree on potential improvements
The Manual of Style, a set of guidelines to help editors maintain a consistent style and formatting (please follow them)
Wiki help page

If you have any questions, just start a topic on the Discuss! page. Again, welcome!

...where the image on the left is an appropriately chosen icon.

Finally, we could use the NewUserMessage extension to have the wiki software automatically post the message to the new user's talk page.

---- ElGaton (talk to me) 17:30, 1 May 2016 (EDT)

Permanently removing spam bots

For permanently removing spam bots, has the UserMerge Mediawiki extension been considered? I use that regularly on my own wiki, though there we have also reverted to communicating to the person via email before manually granting access (probably not an option here), as all of the Mediawiki captcha methods were recently cracked.

Bugman (talk) 03:15, 12 February 2016 (EST)

Oh, for the extension, we simply have a user called 'Spam bot' in a blocked state, and merge the spam bot accounts into this one, deleting the old account.

Bugman (talk) 03:20, 12 February 2016 (EST)

I'd use the abuse filter extension instead (much more powerful and automated) - other users have also proposed different remedies, see this forum thread. Anyway, Gijs is going to upgrade MediaWiki shortly and review the current anti-spam measures.

-- ElGaton (talk to me) 06:26, 13 February 2016 (EST)

A lot of the spam bots are using their name as advertising nowadays, so the UserMerge extension is the only one I know which will allow a user and associated name to be permanently deleted.

Bugman (talk) 12:04, 14 February 2016 (EST)

The problem now is that they're also adding the information to the page title, so that it will still show up in the deletion logs [1] in other words, there's still some SEO juice associated with deleted entries ... Another idea would be to allow admins to temporarily disable wiki registrations/article creation, e.g. if more than 2 admins agree, this could be done to protect the wiki from spam attacks.

Hooray, you should sign your posts ;) The bots don't target the deletion logs, as that's a little pointless. It's a Special:* page, and the default Mediawiki robots.txt file tells all search engines to not index these pages. User pages, page histories, etc. are however normally indexed.

Bugman (talk) 14:36, 19 February 2016 (EST)

The point was not what the bots are targeting, but what shows up in the logs - i.e. SEO-wise - Gijs' article blacklist stuff should help with that hopefully. PS: I could not find the signature button on the mobile device I am using, and I am not too good at remembering the correct number of tildes ;-) Hooray (talk) 15:04, 19 February 2016 (EST)

WIP vs. Under construction

I have been beginning to miss the under construction template[2] more and more (though I could it definitively could be improved).

I have begun to appreciate the need to differentiate between letting readers that a page is to be considered a yet to be finished construction site (though we in a way have that through the {{incomplete}} template) and letting the reader (and other editors) that a page will receive a large amount of work for some hours or even days, usually the use for {{WIP}}.

In summary i miss templates giving a clear distinction between conditions akin to "Under construction" and "Caution - Wet floors", rather than "being worked on" and "could need more work".

—Johan G (Talk | contribs) 10:11, 17 February 2016 (EST)

Fr/Pilote automatique

Bonjour,

Je viens de créer la page de traduction en français de l'article original en anglais Autopilot. Vu mes faibles compétences en matière de pilotage, vu que je n'ai pas sur ma version téléchargée d'avion avec un pilote automatique, la traduction doit souffrir quelques approximations, si ce n'est des contresens plus ennuyeux. Si quelques bonnes âmes plus qualifiées pouvaient me faire la grâce d'une relecture... merci d'avance.

Cordialement, et Hop ! --F-WTSS (talk) 15:30, 18 February 2016 (EST)

MediaWiki updated to 1.26.2

I've updated MediaWiki to the latest stable release (1.26.2) today. I've still got to update some of the extensions, so there may be regressions for now. Please report bugs if you find any. For a list of changes, see https://www.mediawiki.org/wiki/Release_notes/1.26

Gijs (talk) 10:47, 19 February 2016 (EST)

Cheers! I was hoping that it would solve the uneditable Chinese, Russian, and other non-latin character-based pages (Polish strangely as well), but unfortunately that issue remains.

Bugman (talk) 10:54, 19 February 2016 (EST)

Hm, looks that will require quite some attention indeed. I'm afraid that'll has to wait for now.

Gijs (talk) 12:29, 19 February 2016 (EST)

Nasal Syntaxhighlighting

Thanks for your efforts, btw: Nasal syntax highlighting is gone again.

—This unsigned comment was added by Hooray (Talk | contribs) 17:22, 19 February 2016‎ (UTC)

Unfortunately this time it isn't me forgetting to copy a file. The SyntaxHighlight extension no longer uses GeSHi, but has switched to Pygments. This means our Nasal mapping no longer works and has to be re-written. If anyone is interested, be my guest. See http://pygments.org/docs/lexerdevelopment/

Gijs (talk) 12:29, 19 February 2016 (EST)

Hi Gijs,

I'm interested in making a Pygments Nasal lexer, but unfortunately I won't be able to work on it until the end of March at the earliest.

Red Leader (Talk, contribs) 16:59, 23 February 2016 (EST)

Unless Gijs is facing any problems, I don't think it's necessarily needed, see my comment/suggestion in this revision: [3] Hooray (talk) 17:20, 23 February 2016 (EST)

Hi Gijs,

Here's the code for a Nasal lexer. Be warned, it's thoroughly untested, but has the following features:

Full support for all three string types (backtick, single quote, and double quote), including escapes and formatting strings (e.g., for sprintf() ).
All kinds of numbers, including numbers in scientific notation and octal and hex numbers.
All global functions and variables as of FG v2016.1.1.
Some of the commonly-used props.Node methods.
All the other things that can be expected (keywords, punctuation, etc.).

I have also created a lexer based on the XML lexer for XML with embedded Nasal, which I thought would be useful.

Regards,

Red Leader (Talk, contribs) 16:35, 2 April 2016 (EDT)

http://pygments.org/docs/lexerdevelopment/#adding-and-testing-a-new-lexer

# -*- coding: utf-8 -*-
"""
	Lexer for Nasal.
"""

from pygments.lexer import RegexLexer, words, include, inherit, bygroups, using
from pygments.token import Text, Keyword, Name, String, Number, Operator, Punctuation, Comment
from pygments.lexers.html import XmlLexer

__all__ = ['NasalLexer', 'XMLNasalLexer']

class NasalLexer(RegexLexer):

	name = 'Nasal'
	aliases = ['nasal']
	filenames = ['*.nas']

	tokens = {
		'formatters': [
			(r'%[-#0 +]*(?:[0-9]+)?(?:\.[0-9]+)?[dis%couxXeEfFgG]', String.Interpol),
		],
		'backtick': [
			(r'`', String.Backtick, '#pop'),
			(r'[^`\\]+', String.Backtick),
			(r'\\n|\\r|\\t|\\`|\\\\|\\x[0-9a-fA-F]{2}', String.Escape),
		],
		'sqstring': [
			(r"'", String.Single, '#pop'),
			(r"[^'\\%]+", String.Single),
			(r"\\'", String.Escape),
			include('formatters'),
		],
		'dqstring': [
			(r'"', String.Double, '#pop'),
			(r'[^"\\%]+', String.Double),
			(r'\\n|\\r|\\t|\\"|\\\\|\\x[0-9a-fA-F]{2}', String.Escape),
			include('formatters'),
		],
		'root': [
			(r'\s+', Text),
			(r'#.*?$'m, Comment.Single),
			(r':|\?|[!=<>+\-*\/~&|^]=?', Operator),
			(words(('or', 'and'), suffix=r'\b'), Operator.Word),
			(r'[{(\[})\]\.;,]', Punctuation),
			(words(('for', 'foreach', 'forindex', 'while', 'break', 'return', 'continue', 'if', 'else', 'elsif'), suffix=r'\b'), Keyword),
			(words(('var', 'func'), suffix=r'\b'), Keyword.Declaration),
			(words(('nil'), suffix=r'\b'), Keyword.Constant),
			(words(('me', 'arg'), suffix=r'\b'), Name.Builtin.Pseudo),
			(words(('new', 'del', 'getNode', 'getParent', 'getChild', 'getChildren', 'removeChild', 'removeChildren', 'removeAllChildren', 'getName', 'getIndex', 'getType', 'getAttribute', 'setAttribute', 'getValue', 'setValue', 'setIntValue', 'setBoolValue', 'setDoubleValue', 'unalias', 'alias', 'getPath', 'getBoolValue', 'remove', 'setValues', 'getValues', 'initNode'), suffix=r'\b'), Keyword.Pseudo),
			(r'0o[0-7]+', Number.Oct),
			(r'0x[0-9a-fA-F]+', Number.Hex),
			(r'\d*(?:\.\d*)?[eE][+-]?\d+', Number.Float),
			(r'\d*\.\d*', Number.Float),
			(r'\b[0-9]+\b', Number.Integer),
			(words(('D2R', 'R2D', 'FT2M', 'M2FT', 'IN2M', 'M2IN', 'NM2M', 'M2NM', 'KT2MPS', 'MPS2KT', 'FPS2KT', 'KT2FPS', 'LB2KG', 'KG2LB', 'GAL2L', 'L2GAL'), suffix=r'\b'), Name.Variable.Global),
			(words(('abort', 'abs', 'addcommand', 'airportinfo', 'airwaysRoute', 'assert', 'carttogeod', 'cmdarg', 'courseAndDistance', 'createViaTo', 'createDiscontinuity', 'createWP', 'createWPFrom', 'defined', 'directory', 'fgcommand', 'findAirportsByICAO', 'findAirportsWithinRange', 'findFixesByID', 'findNavaidByFrequency', 'findNavaidsByFrequency', 'findNavaidsByID', 'findNavaidsWithinRange', 'finddata', 'flightplan', 'geodinfo', 'geodtocart', 'getprop', 'greatCircleMove', 'interpolate', 'isa', 'logprint', 'magvar', 'maketimer', 'md5', 'navinfo', 'parse_markdown', 'parsexml', 'print', 'printf', 'printlog', 'rand', 'registerFlightPlanDelegate', 'removecommand', 'removelistener', 'resolvepath', 'setlistener', 'setprop', 'settimer', 'srand', 'systime', 'thisfunc', 'tileIndex', 'tilePath', 'values'), suffix=r'\b'), Name.Builtin),
			(words(('append', 'bind', 'call', 'caller', 'chr', 'closure', 'cmp', 'compile', 'contains', 'delete', 'die', 'find', 'ghosttype', 'id', 'int', 'keys', 'left', 'num', 'pop', 'right', 'setsize', 'size', 'sort', 'split', 'sprintf', 'streq', 'substr', 'subvec', 'typeof'), suffix=r'\b'), Name.Builtin),
			(words(('_createCondition', '_fgcommand', '_interpolate', '_setlistener'), suffix=r'\b'), Keyword.Reserved),
			(r'`', String.Backtick, 'backtick'),
			(r"'", String.Single, 'sqstring'),
			(r'"', String.Double 'dqstring'),
			(r'\b_\w*?\b', Keyword.Reserved),
			#(r'\b\w*?\b', Name),
		]
	}

class XMLNasalLexer(XmlLexer):
	"""
	For Nasal code embedded in XML files.
	"""

	name = 'XML-Nasal'
	aliases = ['xml-nasal', 'xml-ns']

	tokens = {
		'root': [
			(r'(<(?:load|unload|script)>)(<!\[CDATA\[)?(.*?)(]]>)?(</(?:load|unload|script)>)', bygroups(Name.Tag, Comment.Preproc, using(NasalLexer), Comment.Preproc, Name.Tag),
			inherit,
		],
	}

We can use the ECMAScript/JavaScript lexer[4] for now, my suggestion would be to copy that over to a file so that we can work on a custom Nasal lexer (Syntax is almost identical, with a few different keywords, and many others being irrelevant). What is missing/different can be obtained from other lexers that are similar, e.g. [5] Hooray (talk) 15:45, 19 February 2016 (EST)

Okay, here's the better/quick&easy way: We have Nasal support for some fairly popular editors, like [6](originally created by Melchior^[1]), listed at Howto:Syntax_highlighting_for_Nasal - there are various free converters available that will read such a syntaxhighlighting file and convert it to a pygments class, e.g. see: https://github.com/honza/vim2pygments Hooray (talk) 16:00, 19 February 2016 (EST)

References

↑ https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/scripts/syntax/nasal.vim

The repository link templates

Complete overhaul of the repository link templates

I have now performed a complete overhaul of the repository link templates (see {{repo link/doc related}}). This was motivated by the incomplete state of these templates, the lack of standardisation, the lack of SourceForge git repository support for {{repo link}}, web-interface only support, etc. I have used a lot of recursive transclusion for standardisation, so that there is a single point for updating for any FlightGear infrastructure changes. This is the master {{repo link}} template. All the other templates are subtemplates which recursively transclude from this master template. I have also created a number of documentation templates for simplifying template maintenance (see {{repo link/doc related‎}}, {{repo link/doc specific file git‎‎}}, {{repo link/doc git clone‎‎}}, and {{repo link/doc commit}}). The changes were constrained to maintain backwards compatibility as much as possible. However I would like to break this to allow the following templates to be updated to transclude from the master {{repo link}} template:

If no one objects, I would like to completely break these and expand and rename the parameter set to match the other {{* file}} repository templates (e.g. {{terragear file}}). My overhaul currently does not include Hooray's ideas for non command line usages, i.e. different GUIs, but it enables it to be easily added via the master template and the addition of a single parameter to any subtemplates.

Bugman (talk) 15:05, 25 February 2016 (EST)

I don't have any objections myself, I appreciate all the work you are putting into this, and would like to thank you for helping us clean up all that mess by doing such unglamorous work ;-) I also appreciate that your changes would facilitate adding a non-CLI mode to the corresponding templates. However, I would suggest to wait for Gijs' feedback, because he's ultimately the most likely person to veto something around here ;-) Hooray (talk) 17:31, 25 February 2016 (EST)

Johan seems to be the one who did a lot of the initial work on these {{* file}} templates, and Red Leader with the {{repo link}} template. And they were involved in the general discussions ([perm). But I know Gijs was also involved in the design.

For the non-CLI mode, that will need -a lot- more planning. For example a definitive list of all these modes would be useful. Should this use an optional Mediawiki pop up extension showing a link to a general page that describes the action for all different GUIs, CLI, etc.? Should we have a switch box so that the reader can switch in-text between CLI, and the numerous GUIs? Are we going to have a large set of screenshots for each GUI? If so, I would strongly recommend the labelled section transclusion extension for creating a single page for one GUI with everything for that GUI, as a tutorial. Here is an external example where I have used this, to fragment the base release page to create this meta page, as well as many other meta pages.

Bugman (talk) 03:14, 26 February 2016 (EST)

I am also thinking of changing the name of the {{* file}} templates, as I hope to make the scope of the templates far more general. The name {{* source}} or {{* repo}} might be better. For example these will allow the repository commit, tree view, log view (and maybe rss feed), with or without a file/directory path. And I would like to generalise this to handle both the SF web-interface and non-web net protocols (git://, ssh://, svn://, etc.). It will allow for CLI instructions to be built up and embedded in {{#tag:source|<content>|lang=sh}} tags. And I will defer all infrastructure decisions in the subtemplates to the single point of {{project infrastructure}}, so that if there are changes in the future, then only this single template needs to be updated to update the entire wiki.

Bugman (talk) 03:22, 26 February 2016 (EST)

The {{project infrastructure}} template as a single point provider of various project infrastructure names and URL pairs seem like a great idea. If it work out well it will really lessen the maintenance by having less places needing updates, while allowing the various repository templates to be simple to use, in essence by having comprehensible names and no boiler plate parameters for their users.

—Johan G (Talk | contribs) 15:15, 27 February 2016 (EST)

Repository link update

For those following, I have massively expanded the capabilities of the {{repo link}} template:

The SourceForge URLs are now comprehensive.
Full support for the new query-based URLs for the Gitorious archives.
Functional GitLab URLs.
Generic repository support (used to create the {{openscenegraph co}} template).
Detailed documentation and extensive examples for checking the implementation (if you find any non-supported links, please add these as examples).
Isolation of the cmd parameter from the CLI options — this is to enable future support for non-CLI instructions based on the value of cmd.

I have also completed a large set of subtemplates of {{repo link}}, see the list at {{repo link/doc related}}. This includes a full set of {{* source}} templates. I have left the original {{* file}} templates, rather than renaming and modifying them, so these are now redundant. All of the {{* source}}, {{* commit}}, {{* clone}}, and {{* co}} templates transclude from the master {{repo link}} template to do all of the work.

One important template is {{gitorious source}}. The support for the new query-based URLs for the Gitorious archives is now quite comprehensive in {{repo link}}. Therefore I have converted almost every single FlightGear wiki link to https://gitorious.org to use {{gitorious source}} instead. This fixes a lot of broken links and broken git instructions. I have reduced the number of hits for gitorious.org on the wiki (searching just for "gitorious") to 22 hits. This includes 2 very outdated articles (FlightGear Git: aircraft authors, Fr/FlightGear et Git), 15 locked newsletters, 1 with no longer existent Gitorious merge request links, and 4 base URL links for Hangars. This way we can maintain the Gitorious web interface links and git command instructions in a functional state by simply updating the single source of {{repo link}}.

Bugman (talk) 11:38, 29 February 2016 (EST)

I just remembered Special:LinkSearch, so make that 184 broken gitorious.org links remaining. Lots more work to do :)

Bugman (talk) 14:46, 29 February 2016 (EST)

For some of these templates, e.g. {{repo link/doc usage}}, I'm trying to implement some logic for automatic whitespace padding for documentation formatting, but the {{#len:string}} function is not enabled. According to mw:Wikitext_parser/Core_parser_functions#.23len and mw:Extension:StringFunctions, the option $wgPFEnableStringFunctions = true; should be set (in LocalSettings.php). Unless there is a reason for not using this, I was wondering if someone could enable this? Cheers!

Bugman (talk) 09:53, 8 March 2016 (EST)

Archived newsletters and dead links?

Do we have a policy for the dead links in the FlightGear newsletters? It is obviously good to preserve the historic state. But there are many Gitorious links that could be made functional again using the {{gitorious source}} template to point to the historic Gitorious archives (including the official FlightGear repositories, rather than using {{fgdata source}}, for example). The https://gitorious.org links have been converted from URL/path based to query based, so absolutely all of the old links are broken. I am steadily converting all Gitorious links to use the {{repo link}} family of templates, with the exception of the newsletters.

Bugman (talk) 04:52, 8 March 2016 (EST)

I think it could be a good idea to try update old links in those newsletters. I sometimes look back at things and tend to think that I probably are not the only one doing that.

I wonder if the rotten links should be replaced or stricken, but I think they could just as well be replaced. The key thing is that they go to the same resource or content, not weather they have been updated or not (also, the change will be visible in the revision history after all).

—Johan G (Talk | contribs) 07:11, 8 March 2016 (EST)

I should add that I'm using Special:LinkSearch for http://gitorious.org and Special:LinkSearch for https://gitorious.org. And I am also not touching the User* pages, *talk* pages, or pages tagged as out of date or up for deletion. For the newsletters I might look at these later when the broken Gitorious links are fixed in the rest of the wiki but, as these are locked, someone else might have make the switch to {{gitorious source}}, {{gitorious url}}, {{gitorious clone}}, and {{gitorious merge request}}.

Bugman (talk) 02:53, 9 March 2016 (EST)

I will temporarily add a table here for the templates in the newsletters and will slowly fix them one by one together with any other admin.

—Johan G (Talk | contribs) 12:06, 9 March 2016 (EST)

I've added a notes column to help a little.

Bugman (talk) 12:30, 9 March 2016 (EST)

Elimination of the dead Gitorious links

Thanks largely to the diversity and flexibility of the {{repo link}} family of templates, I have now managed to eliminate almost every last dead Gitorious link in the FlightGear wiki! The locked Newsletter articles, user pages, and talk pages are the only exceptions. The page counts from the (Main) namespace are:

Special:LinkSearch for http://gitorious.org — 37. Of these, 17 are for the front page with the news of the Gitorious to SourceForge migration, and the rest are Newsletters.
Special:LinkSearch for https://gitorious.org — 166. Most of these links are valid and created by the {{gitorious *}} subtemplates of {{repo link}}. The remaining broken links are all in the locked Newsletters.

The Howto:* pages are not in the (Main) wiki namespace, but I've knocked those out too.

Bugman (talk) 13:54, 10 March 2016 (EST)

thanks for doing all this unglamorous work - I am sorry that Gijs was apparently too busy to follow up on my suggestion to either provide you with admin access around here, or at least to help you run a Python script to do all this work in an automated, rather than manual, fashion. Hopefully, things will work out better next time. Again, thank you. Like I said, I think you should definitely be given admin access on the wiki, especially given your recent contributions - and I would gladly have my wiki status downgraded accordingly. In fact, if I was able to directly promote accounts accordingly, I would have done so months ago - however, it seems that Gijs is the only one to have those privileges, and he mentioned off-list that he's kinda busy with RL/exams etc, so it is to be expected that he's going to become a bottleneck more often - hopefully, this will be recongized as an actual issue, so that there will be more people able to promote new wiki admins. Sorry that things didn't work out better this time, and thanks so much for doing all this stuff manually. -Hooray (talk) 14:49, 10 March 2016 (EST)

No problems! As for automating this, that would not have been possible. If you look at the changes, you'll see that each one is different ^[7]. I had to check each one, and update the link as required.

Bugman (talk) 16:08, 10 March 2016 (EST)

There's three of us actually (Curt, Simon and myself), no need to wait on me. See http://wiki.flightgear.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=100 (Sek is inactive nowadays) ;-)

Please note that forum pms are really not the best way to contact me. I very much prefer email over forum pms as it's a lot easier to filter out the huge amounts of nonsense I'm receiving from stuff requiring actual attention.

Anyhow I've just promoted Bugman so he can edit locked articles.

Gijs (talk) 05:06, 11 March 2016 (EST)

Thank you. I'll try to preserve the original intent of the Newsletters while fixing the broken links (maybe even preserving any original URLs as Mediawiki link text, while pointing to the new URL). I will use the {{gitorious *}} templates to point to the historical sources, and will probably use this for all of the Gitorious URLs so that we have full control over any future URL breakages via the single location of {{repo link}}. For example, if they change the gitorious.org domain name to a https://archive.org subdomain (i.e. gitorious.archive.org).

Bugman (talk) 06:40, 11 March 2016 (EST)

Regex parsing of template parameters?

For the {{repo link}} template, I am currently trying to work out what to do for git branches and tags on the SourceForge infrastructure. The problem is that the presence of the character / within a branch or tag name requires the text /~ to be appended to that name in the URL, for example:

Tag version/2016.1.1: https://sourceforge.net/p/flightgear/simgear/ci/version/2016.1.1/~/tree/simgear/ephemeris/ephemeris.cxx
Branch release/2016.1: https://sourceforge.net/p/flightgear/simgear/ci/release/2016.1/~/tree/simgear/ephemeris/ephemeris.cxx

I haven't found out a way to use regex to parse the tag or branch template parameters to automate this, hence I am thinking of just giving the instruction for the template user to append this text to the tag or branch parameter text themselves. However this is not ideal - a change of this behaviour on the SourceForge side requires end pages with SourceForge URLs to be updated, rather than just updating {{repo link}}. I was wondering about possibility of installing the extension:

Extension:RegexParserFunctions

Though I'm not 100% sure if that will work. Or does someone else know an alternative? Cheers!

Bugman (talk) 12:09, 22 April 2016 (EDT)

not a solution, just a potential workaround would be checking for the most common prefix strings used in tags/branches (e.g. version, release, topic, topics) and explicitly rewrite the URL accordingly to append the /~ suffix -Hooray (talk) 12:59, 22 April 2016 (EDT)

That might be a solution. But I don't know how to do that without regex ;) We really only have #ifeq statements, but that has to match the whole string.

Bugman (talk) 13:44, 22 April 2016 (EDT)

As a temporary workaround, I'll update the SourceForge {{repo link}} template instructions to tell the user to append /~ to the branch or tag name, if the / character is present.

Bugman (talk) 10:31, 20 May 2016 (EDT)

Discussion about quotes on the wiki

Hooray have started a page now at FlightGear wiki:Quoting Guidelines (perm) for a discussion regarding guidelines for the use of quotes on the wiki. Join the discussion.

—Johan G (Talk | contribs) 18:17, 21 March 2016 (EDT)

In slight relation to this I have tried to make the wiki more consistently use the most common spelling and case, "Instant-Cquotes" and have changed the automatic categorization accordingly. All articles using the {{FGCquote}} template can now be found in Category:Articles containing Instant-Cquotes (currently some ~250 articles).

—Johan G (Talk | contribs) 08:21, 23 March 2016 (EDT)

Reorganizing the Git articles

I've noticed that the Git articles suffer from duplication and are in part obsolete (especially with regard to the instructions for running Git on Windows). Thus, I propose the following reorganization:

Development workflow: reorganization to explain how the patch submission process is organized from a high-level point of view (forking the repository from SourceForge, developing, pushing the commits to the personal fork, submitting a merge request/sending a patch to the mailing list);
FlightGear Git: leave as is;
Installing and configuring Git - new article about installing Git and configuring it (setting the username/e-mail address); merge the contents of FlightGear Git on Windows and Resources WRT running git on Win32 here;
FlightGear Git for laymen - make it follow FGW:MOS, merge the contents of Howto:Start using git here;
FlightGear Git: core developers and FlightGear Git: data developers - I'm uncertain about what I should do with them: the only piece information that would not be written in other articles is the list of alternative methods for cloning FGData;
FlightGear Git: gitiquette and FlightGear Git: tips - make them follow FGW:MOS.

Any comments? -- ElGaton (talk to me) 06:11, 13 May 2016 (EDT)

This is sorely needed! For FlightGear Git: core developers and FlightGear Git: data developers, maybe these can be merged into something like FlightGear Git: working with the repositories? The only real difference is the URL, but that is a minor difference with the Category:Repository link templates. This could be generalised into a set of instructions for working with all git repositories for the core infrastructure, including forking and merge requests, with a current focus on the SourceForge web and non-web interfaces.

Bugman (talk) 08:17, 13 May 2016 (EDT)

Yes, I was thinking about a similar solution as well. -- ElGaton (talk to me) 10:16, 13 May 2016 (EDT)

For the reorganisation of the articles, it would be good to make a lot of use of the {{Project infrastructure}} template. This will abstract away the SourceForge infrastructure (well some instructions will be 100% SourceForge specific, so it won't be perfect). I would like to however have Johan's design implemented first, as it would be quite beneficial.

Bugman (talk) 18:43, 14 May 2016 (EDT)

Thanks, didn't know it existed. Right now I'm fixing some last-minute bugs before the release, but I'll have a look at this. -- ElGaton (talk to me) 09:05, 15 May 2016 (EDT)

And while we're at it, we also have a handful of git related templates to abstract away UI-specifics, which would allow us/me to upload screenshots for different interfaces (CLI, tortoisegit etc), so that we only need to update the templates, and not touch any of those articles. OTOH, I cannot seem to find a recent discussion of the idea, only http://wiki.flightgear.org/Talk:Development_workflow and that has not been updated in 3 years. Any opinions ? -Hooray (talk) 20:52, 15 May 2016 (EDT)

I'm not fully sold on this one. I see the point of creating templates (for example, the Git commands mentioned in Talk:Development workflow can be used in aircraft pages to explain how to checkout a development version from a private repository), but, in my opinion, screenshots are a bit "heavy" to be reused in other articles (beside the Git ones). Did you plan to use them in other pages and, if yes, how? -- ElGaton (talk to me) 14:11, 23 May 2016 (EDT)

It was originally intended to document different UIs and workflows - i.e. by parameterizing the templates, so that a matching set of commands, and screenshots, could be shown. The basic idea was that we have a growing number of articles detailing git workflows (clone, checkout, push, branch etc) - and it seemed to make sense to have a single article/template documenting the specifics, so that other articles could merely use that template, while specifiying the "action" and any other variable items (repository, branch etc) - and then use a template to provide the matching command line. However, don't worry - we don't need to do it that way. Originally, it was all inspired by Howto:Build FlightGear with NetBeans using CMake. -Hooray (talk) 14:23, 23 May 2016 (EDT)

UTF-8 language pages cannot be edited

This is a continuation of FlightGear wiki:Village pump/Archive 2015#UTF-8 language pages cannot be edited. I can see that wiki editors are forced to create workarounds, as the Main page in Chinese cannot be edited. I think it is quite important to solve this "A database query error has occurred. This may indicate a bug in the software" issue. As the fix is quite dangerous (see mw:Topic:S1q54kosfdkhz6w1), do we have a backup system? Do we have regular mysql and ftp dumps that can be backed up locally using rsync?

Bugman (talk) 05:16, 15 May 2016 (EDT)

This is quite urgent! We have a new contributor who would like to add Greek translations to our wiki, but he is completely blocked. Here are the steps to reproduce:

Go the the main page.
Click on the "Ελληνικά" language (Greek in Greek).
As the page doesn't exist, create it.
See the error message "A database query error has occurred. This may indicate a bug in the software".

Bugman (talk) 17:30, 19 June 2016 (EDT)

Non-latin characters in the URL

The problem is non-latin characters in the URL. I just ran a test:

Edit Zh/你好 → "A database query error has occurred. This may indicate a bug in the software"
Edit the latin equivalent Zh/nihao → No error.

Let me repeat that fixing this huge bug should be given the highest priority, as it prevents the wiki from being translated into many, many languages.

Bugman (talk) 05:30, 28 June 2016 (EDT)

Making wiki specific templates available via editor ?

We now have an increasing number of wiki specific templates that should be more widely used, so that it would make sense to integrate those with the default mediawiki editor - e.g. the URL encapsulating templates. -Hooray (talk) 10:12, 16 May 2016 (EDT)

Categorizing aircraft infoboxes by hangar

I would like to bring the discussions from Template talk:Infobox aircraft#fgaddon aircraft into here for greater exposure. The idea discussed there was to add hangar and aircraft parameters to automate and categorise the aircraft infoboxes. This is to help readers instantly identify the source of the aircraft and to give greater exposure to 3rd party hangars or independent aircraft. To show off the potential of this automated approach, I have created an example template at User:Bugman/Infobox Aircraft (see the bottom for an example based on the Space Shuttle infobox). Each 3rd party hangar can add one of the following options:

The hangar logo, with a link to the hangar. For example I have created an initial test logo for FGAddon:
Development repository link. An automatically created link, if the development parameter is not supplied.
Download link. An automatically created link, if the download parameter is not supplied.
A hangar category. For example Category:FGAddon hangar.

Feedback would be appreciated. Cheers!

Bugman (talk) 04:53, 25 May 2016 (EDT)

Following from these ideas, I have made a proposal for a new template: Template talk:Infobox aircraft#Proposal for a new aircraft infobox template design (2016/06). The more feedback on this, the better ;) Cheers!

Bugman (talk) 10:17, 1 June 2016 (EDT)

Thanks for your work - looks good, the only change I would make is (as you noted in the template talk page) replacing the repository/download/livery database/forum thread icons with something more suitable and less "brilliant" icons (though I admit I don't have an alternative proposal for this right now). -- ElGaton (talk to me) 04:40, 2 June 2016 (EDT)

Cheers! I used the high quality Oxygen icon set from the git repository at https://quickgit.kde.org/?p=oxygen-icons.git (this used to be at svn://anonsvn.kde.org/home/kde/trunk/kdesupport/oxygen-icons), as these are {{LGPLv3}} licensed, and hence usable on this wiki. I especially liked the gender neutral icon for the forum:

. They are hi-colour and hence match the bright yellow status stars, but they don't match the minimalistic {{ready}} icons. Anyway, we can switch to a different icon set after the template and aircraft infobox collection have been updated, and once a suitable set is found or created and, more importantly, once a FG wiki-wide colour scheme policy has been discussed ;)

— Bugman (talk) 05:21, 2 June 2016 (EDT)

Bermuda Triangle

To allow for the easy management of wiki articles in which the aircraft appears to have been lost, I have created the new Category:Bermuda Triangle aircraft "hangar". If the hangar parameter for the {{infobox aircraft}} is set to bermuda, then the result is: Template:Infobox aircraft#Lost aircraft. Feedback is more than welcome!

Bugman (talk) 06:36, 2 August 2016 (EDT)

Set up a robot to fix all the broken "prettytable" table classes?

After the last Mediawiki update, the "prettytable" class for tables is no longer defined. I believe that it has been merged into the "wikitable" class. Here is a before and after example of fixing the tables:

I suggest automating the conversion of "prettytable" to "wikitable", as this is an absolutely huge job.

Bugman (talk) 14:04, 10 June 2016 (EDT)

For reference, here is what the "prettytable" class formatting was like prior to its disappearance:

https://web.archive.org/web/20150510160626/http://wiki.flightgear.org/List_of_abbreviations

The tables without borders that we now see is not the original format desired by those creating the tables (prior to sometime in 2015).

Bugman (talk) 11:05, 13 June 2016 (EDT)

As a workaround, I have redefined the "prettytable" class in Mediawiki:common.css.

Bugman (talk) 06:23, 22 July 2016 (EDT)

A new "keytable" class

For an improved table formatting which sits well with the {{key press}} template, I have defined the new "keytable" class in Mediawiki:common.css. This is for the elegant formatting of keyboard shortcut tables. It uses high quality typesetting rules: There is no background colour; uses generous margins and padding; only horizontal dividers at the top and bottom and between the header and main content; somewhat indented from the main text. Here is an example (which will change as the "keytable" styles are refined):

Key	Function
`d`	Open/close crew door
`D`	Open/close passenger door

Bugman (talk) 07:49, 21 July 2016 (EDT)

URL change notifications

Referring to controversial URL changes like ^[1], could we discuss setting up some rules, infrastructure/tools to get a notification when certain links (regex) are updated/added ? For now, I have updated http://wiki.flightgear.org/MediaWiki:Spam-blacklist accordingly.-Hooray (talk) 06:23, 12 June 2016 (EDT)

We currently have these situations under control^[2], and I have been able to resolve them in a way that is beneficial to all. So I don't think we need such measures. Education is more productive, as the intent is good. And I believe that both monitoring the recent changes list and a simple search for that keyword are sufficient for now.

Bugman (talk) 11:11, 13 June 2016 (EDT)

SVG graphics support?

I was wondering if we could enable SVG graphics support? Currently we cannot upload svg files^[3]. The purpose would be for high quality graphics at all resolutions for icons, logos, banners, etc., and allowing for low resolution bitmap graphics to be made into higher resolution graphics for future wiki purposes.

Bugman (talk) 10:49, 13 June 2016 (EDT)

Thai language support

Could we please have Thai (th) added to the supported langauges in LocalSettings.php? Cheers!

Bugman (talk) 07:21, 10 August 2016 (EDT)

new portal for cockpit building (hardware) ?

We are now seeing an increasing number of articles relating to hardware/cockpit building -- Hooray (talk) 13:57, 21 August 2016 (EDT)