Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Template talk:Project infrastructure

From FlightGear wiki
Jump to: navigation, search


@Hooray: This idea is too useful, so I might hijack it ;) I'll move this from {{Project URL}} to {{project infrastructure}}. Then the default option can be mode=url. I would like to have a mode=name returning SourceForge, and mode=abbrev returning sf. I will then use this in the {{repo link}} family of templates to make the subtemplates 100% independent of the current infrastructure, so that the links will be timeless :) This single template could end up being the sole reference to SourceForge and other infrastructure on the whole wiki.

Bugman (talk) 02:08, 26 February 2016 (EST)

yes, that was the idea - I was just expecting to spend a few weeks doing this, and not to come back realizing that you finished the whole thing in a few hours. So, thank you very much for doing this. It is good for us to learn from the sourceforge transition and try to prevent certain issues in the future.--Hooray (talk) 06:43, 26 February 2016 (EST)


probably need to extend the template a little to support this use-case: http://wiki.flightgear.org/index.php?title=Template:Forum&action=history

--Hooray (talk) 06:28, 26 February 2016 (EST)

I guess an optional 'urn' parameter for appending to the URL, as well as a 'text' parameter to change the name of the link would do. Then {{forum}} could transclude this template.
Bugman (talk) 06:56, 26 February 2016 (EST)
Bugman (talk) 08:38, 26 February 2016 (EST)
Thank you, I just used this to implement this Template_talk:Project_infrastructure#Unified_search_handling --Hooray (talk) 11:13, 17 April 2016 (EDT)

Other URLs

  • mumble servers, also to help us deal with incidents like [1]
  • scenemodels.flightgear.org
  • scenery.flightgear.org
  • liveries.flightgear.org
  • multiplayer map
  • add ticket/issue tracker template here ?
  • FGCom server
  • Lenny's ATC website

Some suggestions

First off, implement this step by step, and think the architecture through during the process. Do not lock yourself in early.

I still have frustrations with annoying inconsistencies and non user friendly naming schemes in the FlightGear screenshot categories due to "flash-implementing" early ideas before thinking them through thoroughly.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

just for the record, I do agree with this, but on the other hand, had bugman not taken my original idea and developed it much further, I would still be dabbling that - so, basically within a few hours, bugman went through several iterations of this, without needing much in terms of feedback, and I am pretty satisfied with it personally. I do get your point though, so I would suggest to document "best practices" - I am not much a wiki guru myself, I really only use a tiny fraction of its markup/features, and I am always glad for your contributions to my templates, because it's not something that I am very good at/interested in - I would rather write php/javascript code than having to memorize wikimedia templates myself. But if there is anything that we/I can do better to lighten your workload (Johan, Red Leader, Gijs), please just document your suggestions somewhere. In terms of the overall idea here, I believe it is the right thing to do, and while it my not address all your concerns, it is certainly better than the existing practice - and had we done this a few years ago, we would not be having certain problems now. So I would politely suggest that "we should not let the perfect be the enemy of the good" here, this isn't core development after all - it's just a wiki, and anything that helps reduce our workload is a good thing, until someone comes up with something better somewhere down the road. All in all, let's also keep this in mind (which may have no immediate repercussions at all, or which may have unfortunate side effects in a few years/months. So, thanks again bugman for all you have handled so far - it's certainly much better, and much faster, than anything that I could have come up with in this timeframe, and I am very impressed with the quality of your wiki involvement - then again, thanks also to Johan for providing the kind of feedback that bugman asked for - but please let's not overthink this... Talking about the "architecture of a template" is a bit too much for my own taste --Hooray (talk) 19:53, 27 February 2016 (EST)

The mode parameter

I think the mode parameter is slightly ambiguous and maybe misleading. I would expect it to be something like for example type or infrastructure rather than mode.

As this is an unnamed parameter this is merely a change in the documentation.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

I agree. This was just a quick and random choice, as I've been generating a lot of template content very quickly recently with the aim of having practical and functional implementations. So no real thought has gone into this. I'd suggest type to allow this template to be a universal resource.
Bugman (talk) 16:37, 27 February 2016 (EST)

The name value of the mode parameter

I would say that even though it is an important part of the project infrastructure SourceForge is merely the host of the main repositories.

Here I would probably rather expect something like for example host or main-repo rather than name.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

Again a random and quick choice :) What about provider? Though SF is not the provider of everything FG related, so something along the lines of main... might be good. I have no real preference - this is the default value of the ex-mode parameter, so you wouldn't normally use it when transcluding anyway.
Bugman (talk) 16:44, 27 February 2016 (EST)

Slight variation of the current architecture

This might make for a slightly more complex template, but consider this:

{{project infrastructure|infrastructure|attribute}}

All parameters would be optional optional. If none is given it could e.g. default to the URL of the project page at SourceForge.

Name of the infrastucture, e.g. forum, wiki, main-repo, scenedb or website. Could e.g. default to main-repo
One of several attributes associated with the infrastructure, e.g. name, abbreviation, url, host etc. Could e.g. default to url

I think the template would be slightly more flexible this way.

It could be implemented with two levels of {{#switch: }} parser functions and use the #default = case to catch most errors. Something like:

{{#switch: {{{1|main-repo}}}
 | wiki = {{#switch: {{{2|url}}}
   | name = FlightGear wiki
   | short-name = wiki
   | url = http://wiki.flightgear.org
   | #default = {{error|Attribute '''{{{2}}}''' invalid for infrastructure '''wiki'''|project infrastructure}}
 | main-repo = {{#switch: {{{2|url}}}
   | name = Main FlightGear repository
   | short-name = main repo
   | host-name = SourceForge
   | host-short-name = SF
   | host-url = http://www.sourceforge.com
   | url = http://sourceforge.net/projects/flightgear/
   | #default = {{error|Attribute '''{{{2}}}''' invalid for infrastructure '''main-repo'''|project infrastructure}}
 | #default = {{error|Invalid '''infrastructure''' parameter|project infrastructure}}

The template documentation should probably be complemented by a table of available infrastructure and attribute combinations.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

Please feel free to change :) This all sounds great. My focus is on recursive transclusion for simply pulling out sf, so we can pragmatically change the behaviour of templates. I can quickly adapt all usage of this template to match. For example {{flightgear source}} uses it to completely avoid the SourceForge reference, to then pass it into the now very powerful {{repo link}} template. The table idea is good as well. It could replace the examples section by absorbing the examples. I just have some suggestions:
  • A code value for the second option (replacing abbrev). This would return sf. This would be used as a simple internal wiki code for programmatically changing template behaviour.
  • Alphabetical ordering of values in the switches, in case this becomes quite big.
  • url return values of [http://wiki.flightgear.org FlightGear wiki].
  • main-repo name as "Main FlightGear infrastructure", as this is a collection of repositories, plus a lot of other FG infrastructure. Maybe main-infrastructure would be better for a value, though it is a little long. What about just main?
Bugman (talk) 17:02, 27 February 2016 (EST)
Is that ok for you? Only after I posted the above I saw how many places this template touches already. Though still I would like to have it done.
  • I am not sure I understand your first point. Is this for a switch in the templates?
  • Good point about alphabetical ordering of the attributes/values of the switches.
  • I would rather expect url to return a clean and somewhat more reusable url like http://wiki.flightgear.org. How about a link attribute to return the external link like [http://wiki.flightgear.org FlightGear wiki].
  • I am ok with main (even though I find it a slight bit ambiguous ;-) ).
Johan G (Talk | contribs) 18:35, 27 February 2016 (EST)
I think I have a better grip on what you and Hooray are aiming for now. You basically want to be able to get a link (with optional custom label), a name and the possibility to add an "URN" (not really an URN per see though ;-) ).
An early draft can be found at User:Johan G/project infrastructure.
Johan G (Talk | contribs) 20:29, 27 February 2016 (EST)
For the first point, it would be a switch. It would be used for auto-content generation within other templates, the {{repo link}} template being the prime example. For such an internal code, an ideal would be for the code to be returned by default, so that {{project infrastructure}} returns sf. These could be two letter codes. I'll make a proper table when I'm not on a mobile device. E.g. sf=SourceForge, gh=GitHub, gl=GitLab, go=Gitorious, gs=Gnu Savannah, ga=Gna!, etc.
Bugman (talk) 05:57, 28 February 2016 (EST)
Something like this, for maybe placing into {{project infrastructure/doc internal codes}} (for transclusion into templates that use the internal codes):
Open source infrastructure Internal code
SourceForge sf
GitHub gh
GitLab gl
Gitorious go
GNU Savannah gs
Gna! ga
Bugman (talk) 07:39, 28 February 2016 (EST)
I intend that switching between these internal codes solely within this template will fully switch the entire wiki from one open source infrastructure to another ;) Obviously this will take a lot of work, and a number references to old Gitorious infrastructure must stay (until the repository is migrated by the original author elsewhere). But I hope that searches for gitorious.org, sourceforge.net, etc. will return only a handful of hits on the wiki in the future. Anyway, I really like the double switch design. That is far more flexible and will allow for far better abstraction of the entire wiki contents. And, from a practical sense, it is very easy to expand on.
Bugman (talk) 12:10, 28 February 2016 (EST)
I agree with bugman's goals - just look at the recently announced sale of Sourceforge/Slashdot and what that may /possibly/ mean for the project (and our wiki) sometime in the future, so it is better to "isolate" ourselves from these kinds of changes (external factors), so that the project can more easily adapt itself under such circumstances, helping lower the amount of work necessary to maintain/update the wiki accordingly is a very good idea in my opinion - and I would prefer that we review other parts of the wiki (and other project infrastructure) accordingly.--Hooray (talk) 15:25, 28 February 2016 (EST)
Having looked through how the template actually is used and what its purpose really is some days ago I noted that (at least as of now) the only real gain from my suggestion is an ever so slight bit more consistency and flexibility and a little less typing, but for the price of touching all the pages the template is used on. I wonder if it would worth it. If not, sorry for the noise.
Johan G (Talk | contribs) 14:33, 4 March 2016 (EST)
This is an illusion from transclusion ;) The number of articles using this is actually quite low. I have used it for all of the {{repo link}} subtemplates, so any page that uses one of these subtemplates will appear in a Special:WhatLinksHere search. I think your idea is great for improving this as a general framework. It allows wiki text to be written in a way that would remain relevant when, in the distant future, another major infrastructure change is required. It would extend its usefulness for abstracting away the infrastructure information so that old wiki pages can remain relevant for the decades to come.
Bugman (talk) 18:23, 4 March 2016 (EST)
Actually, its only used for the FlightGear specific subset. Also, most of those hits correspond to old Gitorious links that had been dead links for over a year now, and that I have recently fixed in the last few days using the {{repo link}} subtemplates.
Bugman (talk) 18:54, 4 March 2016 (EST)
Ok then. :-) How about this (perm)?
Johan G (Talk | contribs) 02:27, 8 March 2016 (EST)
This looks great :) It's much more flexible for extending the template functionality, and much better organised. From my side, only the FlightGear specific templates listed at Template:Repo_link/doc_related would need updating. I think Hooray has a few too.
Bugman (talk) 02:57, 8 March 2016 (EST)
Johan, I think it is time to convert this template to your new design ;) There will be a few breakages, but the {{repo link}} family of templates are safe.
Bugman (talk) 18:57, 14 May 2016 (EDT)

Unified search handling

Depending on what we come up with, this may either be integrated with the main template or refactored to be useful elsewhere. --Hooray (talk) 11:11, 17 April 2016 (EDT)

Abstraction of internal design changes using subtemplates

I was thinking that we could avoid disruptions to the {{repo link}} family of subtemplates and anything else that uses {{project infrastructure}} by using subtemplates. For the internal codes used by other templates to switch between SourceForge, GitHub, GitLab, Gitorious, etc., we could have {{project infrastructure/code}} that simply returns the 2 letter code via {{project infrastructure}}. This could be used as an abstraction mechanism so that all design changes to {{project infrastructure}} would simply require the subtemplates to be updated. Any other wiki pages using the subtemplates will be unaffected.

Bugman (talk) 13:32, 7 March 2016 (EST)

I have created a temporary {{project infrastructure/code}} subtemplate, and all of the {{repo link}} templates now use this instead of {{project infrastructure}} directly. Therefore changing this template will not disrupt any pages that transclude the {{repo link}} subtemplates. The following templates might also need a similar strategy, or they are updated simultaneously. Hooray, could you maybe help complete this list?
Templates and pages directly dependent on {{project infrastructure}}:
Bugman (talk) 11:04, 15 March 2016 (EDT)
Sorry, I completely missed that you asked me to help with something - if that's still an issue, what exactly should I help complete ? --Hooray (talk) 10:38, 17 May 2016 (EDT)
Nope, that was just to help Johan make the transition to the newer and more flexible design. When he makes the change, the {{repo link}} templates will not be affected. Then I'll switch the {{project infrastructure/code}} subtemplate to use this template, or revert {{repo link}} to use it directly.
Bugman (talk) 10:50, 17 May 2016 (EDT)

Related mailing list templates


--Hooray (talk) 12:12, 5 May 2016 (EDT)