Template talk:Project infrastructure
Hijack
@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)
Forum
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.
- Done.
Other URLs
- scenemodels.flightgear.org
- liveries.flightgear.org
- multiplayer map
- add ticket/issue tracker template here ?
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)
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.
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.
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.
- infrastructure
- Name of the infrastucture, e.g. forum, wiki, main-repo, scenedb or website. Could e.g. default to main-repo
- attribute
- 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?