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.
- 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.
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?
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
Unified search handling
- Idea: Template:Search
- Motvation: Skydiving#Related
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}}:
- {{project infrastructure/code}}
- {{forum}}
- 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.
Related mailing list templates
See:
- http://wiki.flightgear.org/Template:Mailing_list_e-mail_address
- http://wiki.flightgear.org/Template:Mailing_list_subscription_link
- http://wiki.flightgear.org/Template:Mailing_list_archive
- Template:Gmaneref
--Hooray (talk) 12:12, 5 May 2016 (EDT)
integration with wiki editor / ArticleSave hooks ?
Any chance to integrate this template with the editor or the backend script to parse edited articles for plain URLs and instead provide an option to migrate those to use the template instead ? I would volunteer with the php/JavaScript portion of this, but first of all we should probably discuss if it's feasible integrating the template with the editor and/or the script that parses articles before saving ?
The idea would be to hook into the script using something like this: https://www.mediawiki.org/wiki/Manual:Hooks/MultiContentSave
--Hooray (talk) 15:27, 19 March 2021 (UTC)
- Hi!
- Hm, looks interesting. But also quite sparsely documented and in flux (this hook was apparently only added in the current MediaWiki version and doesn't seem to be used broadly).
- If these hooks turn out to be too much of an effort, I think it'd already help immensely if your cquote script could parse urls to templates (it being the biggest source of adding external links). And of course we can run a bot to tidy up existing articles. The latter is something we'd need to do anyway, so maybe time is better spent on writing a proper regex for the bot?
- Gijs (talk) 10:34, 21 March 2021 (UTC)