FlightGear wiki:Village pump: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎Repository link templates: Moving large part of discussion here from http://wiki.flightgear.org/index.php?title=Template_talk:Repo_link&oldid=87147#Todo_list)
Line 560: Line 560:
:::::::: In summary there seem to be a few things we have not thought of yet.
:::::::: In summary there seem to be a few things we have not thought of yet.
:::::::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 07:01, 16 September 2015 (EDT)
:::::::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 07:01, 16 September 2015 (EDT)
:: The [[FGAddon]] article could greatly benefit from being reviewed with a focus on getting rid of/generalizing explicit URLs (or even git instructions) in favor of using templates that encapsulate any URL/git specifics, so that things can be more easily updated in the future. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 03:01, 20 September 2015 (EDT)

Revision as of 07:01, 20 September 2015


Archives
2012, 2013, 2014

Welcome to the Village Pump. This page is used to discuss the technical issues, operations and guidelines of the FlightGear wiki.

Please add new topics to the bottom of this page.
Old discussion should be moved to a FlightGear wiki:Village pump/Archive YEAR. These discussions can then be moved to a relevant talk page if appropriate.

Navigation links added to FlightGear Newsletter header

As per request by Michat on the forum I have now managed to add navigation links to the FlightGear Newsletter header, {{Newsletter-header}}, pointing to the previous and next months newsletter.

So far I have only added it to the latest header though.

Happy browsing! :-)

Johan G (Talk | contribs) 19:48, 13 January 2015 (UTC)


Looking into the older template, {{Newsletter}}, I have seen a fundamental difference. The new one, {{Newsletter-header}}, uses a parameter, edition, that I have used to get working links to the previous and following editions.
It seems that a similar behavior can not be added to the older template without adding a similar parameter to it and all older editions of the newsletter. I simply can not figure out a way to parse the page name into a date. :-\

Johan G (Talk | contribs) 10:05, 23 May 2015 (EDT)

MediaWiki updated to 1.24.1

I've updated MediaWiki to the latest stable release (1.24.1) today. There is a small issue with some of the extensions not displaying icons, so some of them have been disabled for the moment. I hope to have them re-enabled later today. Please report bugs if you find any. For a list of changes, see https://www.mediawiki.org/wiki/Release_notes/1.24

Gijs (talk) 12:00, 1 February 2015 (EST)

It seems that Nasal syntax highlighting via Geshi is no longer working (I think it was Philosopher who came up with the module...)?
--Hooray (talk) 15:58, 1 February 2015 (EST)
Ah, didn't move that one over. Should be fixed now.
Gijs (talk) 16:19, 1 February 2015 (EST)
Confirmed fixed. Thank you for the quick fix.  :-D
Johan G (Talk | contribs) 16:49, 1 February 2015 (EST)

Support SVG file

Is there some securty issues/software limitations (no plugin's installed) why the wiki don't support uploads of SVG images?

Www2 (talk) 21:02, 4 February 2015 (EST)

If you find missing images

In case you find missing images have a look at this page: FlightGear wiki:Missing images.

Johan G (Talk | contribs) 23:51, 7 February 2015 (EST)

Additional Portals

Given the recent interest in doing embedded development related to FlightGear (Arduino/Rasberry PI), I was thinking that we might want to introduce dedicated portals for such use-cases, to keep things neatly organized, but also to provide a place to grow this further - e.g. depending on how this goes, we could have portals covering:

  • Embedded/Hardware (including cockpit building)
  • UAVs

Equally, we may want to provide sub-forums for these two topics, which should help clean up the offtopic/development forum, too. Currently, the SUPPORT/HARDWARE forum is being used for many of these topics, even though that was originally intended for joysticks/yokes and pedals related stuff - not custom hardware, which would fit better under DEVELOPMENT in my opinon.

As far as I can tell there are roughly 10-15 contributors actively exploring embedded development including UAV stuff - so I guess it would be a good idea for the project (i.e. the forum and the wiki) to provide some structure to "house" such efforts.

thoughts/ideas ? --Hooray (talk) 06:17, 10 February 2015 (EST)

Wiki extensions observations

Hi all,

Recently I was looking at the installed extensions, and noticed the below:

SmoothGallery
It appears that it doesn't work anymore on this wiki. For instance, the below code …
<sgallery>
Glass01.jpg
Glass07.jpg
Glass11.jpg
</sgallery>
… causes the following error:
Notice: Undefined variable: args in /home/wiki/wiki/extensions/SmoothGallery/SmoothGallery.php on line 113 Fatal error: Call to undefined method LocalFile::getThumbnail() in /home/wiki/wiki/extensions/SmoothGallery/SmoothGalleryParser.php on line 208
This could be related to extension's bugs.
I suggest this extension be removed because
  1. As far as I know, it's not used on any of the wiki's pages.
  2. Is it needed?
  3. Its unstable as of 22 March, 2015, which means it's broken and shouldn't be used (link).
EmbedVideo
According to the page revision as of 16 March 2015, there were XSS flaws in version 2.2.4 and earlier of the extension. It should probably be updated to the latest revision.

Red Leader (Talk, contribs) 14:08, 22 March 2015 (EDT)

Both are done. Thanks for reporting!
Gijs (talk) 17:21, 24 March 2015 (EDT)

Boeing 777 Cleanup

Just wrapping up cleaning up Boeing 777 articles that I discussed a full year ago. All now redirect centrally to that page. This makes for a lot less segregated wiki. Looking at it, it would appear that very little happens on the individual pages and the content on them is relatively insignificant. The stuff that is needed I copied over to the main page. Will try to add some pictures as well.

If anybody has any objections, speak up :)


It would be really useful to merge the pages if the aircraft are similar in many ways, for example:
  • All part of the same aircraft package
  • Same or similar usage, for example
    • Keyboard shortcuts
    • Custom dialogs
    • Clickable cockpit interfaces
  • Same levels of system modeling
If they could be handled pretty much the same way and was part of the same aircraft package I don't think I would have any objections.
However, if they differ a lot in the areas mentioned above I think it would not be a good idea to merge the pages; the aircraft would be dissimilar enough that the page would have to be uncomfortably long and possibly confusing if it were to describe the different workings.
If they are not part of the same aircraft package, looking into the similarities and differences and slowly work towards integrating them into the same aircraft package could also bee a good idea.
Johan G (Talk | contribs) 07:48, 5 May 2015 (EDT)

Aircraft Page Organization

I just started a topic over on the forum on how posts are organized if somebody has input.

This unsigned comment was added by Manfred (Talk | contribs) 11:45, 5 May 2015 (UTC)


I think it would probably be better to discuss the quality and organization of the wiki right here (on this very page) than on the forum.
The main two reasons for that is (1) to keep the wiki quality discussions here and (2) that it would be a bit more transparent to do it that way.
The transparency is important in that it would make it easier to later look into why things were decided to be in a certain way and who said what and when.
Johan G (Talk | contribs) 08:07, 5 May 2015 (EDT)

Alright, so here goes:

By the nature of FlightGear, multiple people might work on different projects covering the same areas. For instance, there are 2 different projects covering the Boeing 787. This makes overview and indexing very difficult. Wikipedia is designed to only really have one article on a topic (i.e. aircraft) that can be extended.

For instance:

It is dreadfully unclear on the overview of aircraft. In my opinion, it would make more sense to get an disambiguation page on the various 'packages' that contain the A319 for instance. The multiple entries greatly diminishes the value of the list.

Here are a few ideas:

  • Give aircraft a codeword or project name. For instance, the Boeing 787 (Dream Project) or Boeing 787 (GPL Project) to distinguish between them. Then list them like that in the index as well. When you both have a --aircraft= A319 and A319-131, what are you going to do when the next person comes around and wants to design an A319? It would make more sense to migrate to a structure of say B787-8-Dream and B787-8-GPL. If you make a piece of software, you're not going to go calling your software 'Conference Manager', with the next person making the similar stuff calling it 'Conference Manager 2', but rather ConferenceTime and and ConferenceMaster. Naming your work after aircraft in the current way gets bloody confusing.
  • I imagine that perhaps as a bit of a continuation of the above, people try to distinguish between their models by giving them very specific names, such as Boeing 707-338. I realize that people want to work on it themselves, but from a broader perspective, how much technical difference is there really between these? The A319 should also work with the corresponding changes as a A320- it is an identical cockpit and much the same fuselage. IMHO, it should have been filed as an A320 instead with only one model, an A319. As for the Boeing, give it a codeword, such as Boeing 707 (Qantas Project). It even makes it more marketable.
  • Clearly distinguish between current and past development in the template, i.e. add a new index on the left that contains both categories. I find that not doing any work on the model in five years qualifies for past development.

The ability to grow is proportional to the ability to handle the increase in information. While this perhaps happens mostly on aircraft articles, what happens if somebody wants a fresh start on that airport scenery? How does he name the page and organize it in relation to the current one? It would have been easier to name both after some town landmark so one the second one came around, you could easily categorise them.

In a nutshell:

  • Give all aircraft projects a name after the aircraft type ("Boeing 787"+ Phoenix, Dream, Toulouse...+ Project) to distinguish between individual development.
  • Sort all aircraft by model type (i.e. A320) rather than the sub-model being worked on (i.e. A319).

Manfred (talk) 11:56, 5 May 2015 (EDT)


You have several good points there. I have some thoughts on them (note that this this is only my opinions).
Disambiguation pages
This could probably be used on an aircraft type level basis. For example describing the Boeing 777 in general and short descriptions of the 'subtypes' and links to pages with them and any different variants. To some extent this could be given a standardized look by using templates.
I think these could be very useful, and I wish there was some of them.
The navigation template
Dreadful at least to some extent. I have more than once found them a bit inconsistent and confusing (in particular when looking like the one you showed here). Could probably be remade quite a bit, possibly following the structure I outlined in the point above.
Project names
I have noted that a few projects have had names, for example the Lake of Constance Boeing 707 or the Seattle (though I embarrassingly do not remember what aircraft type that was).
Distinguish between past and current development
Probably a good idea. Could possibly be done with color coded backgrounds for the aircraft type text and color coding of the development state field in the aircraft infobox.
Some additional thoughts:
  • I guess the navigation templates could also be link to the aircraft disambiguation pages when needed.
  • Setting up a style manual for the disambiguation pages and navigation templates would probably be a good idea. It should not be done before some time of experimentation though.
Johan G (Talk | contribs) 12:40, 5 May 2015 (EDT)

Action Plan

It's good to see that we are on the same page. To complete this:

  • I propose that we start with the Boeing aircraft as a model project.
  • We need a name structure for all aircraft that is universal and unique. Otherwise the reorganization will be in vain. As suggested earlier, along the lines of [Manufacturer, Model, Project Name]. The problem is that last one. I called the 787 'GPL' and 'Dreamliner' but I don't like any of those and would much rather give them something that is really not connected to any other aircraft of the name it itself. I'd propose 'Seattle' and 'Firebird' but I don't want to go renaming all the aircraft myself. I think it's something the developers should come up with. The aircraft would not be renamed A319 Toulouse Project, because the fact that it is an A319 is insignificant in that it uses much the same fuselage and identical cockpit as the A320. Only a significant model code should be included. Less of a problem with Boeing but this has to work everywhere.
  • I am really not sure about putting the background history on a separate page and I'm tempted to say we should leave that to Wikipedia. I think it would be better just to make it to a disambiguation page.

Manfred (talk) 16:38, 5 May 2015 (EDT)


For the disambiguation pages I was more thinking along the lines of for example Boeing 707 (permalink) and Boeing 747 (permalink), but with maybe shorter general descriptions and a one-liner or short paragraph describing each variant. An early draft of one possible way to do it have been added to my sandbox.
To my slight frustration the {{Boeing}} template is more consistent and logical than the {{Airbus}} template (in essence less 'messy'). Some of my thoughts on how to improve it (and probably other ones as well) turned into a puff of smoke when I saw it.
Johan G (Talk | contribs) 09:53, 6 May 2015 (EDT)
While I do agree that disambiguation pages are an important step on the way, they are not the solution to the problem. People working on very similar aircraft differentiate their by minimalistic changes in their model name, but this is subject to change as people add different variations of that aircraft based off the same cockpit for instance. It has to be 'robust' in that regard. That is why the unique identifier in the form of a 'project name' or an equivalent solution is necessary, especially for the Airbus aircraft as can be seen. Even if there's only one model at the moment, since there's no harm in doing so because somebody might come along and start some new work. But giving them a name only here won't be very clear and would ideally occur for all use 'globally' in FlightGear.
Manfred (talk) 12:18, 6 May 2015 (EDT)


I can only agree to that the disambiguation pages are not the solution. Regarding those I am rather thinking of consistent style and intuitive navigation (as in more effortless for the reader).
Ideally (as in an utopia) aircraft should be merged or better ones replace older ones, at least in regard to the official aircraft (in essence those available from the download page). But waiting for the utopia differentiating between them using project names is probably the best way.
Maybe we  could  should encourage people to use project names in those cases when they can not merge aircraft (for example due to licenses etc). Using project names consistently, as you seem to suggest, is would probably work well. Also, people tend to copy other peoples way of doing things.
Johan G (Talk | contribs) 12:52, 6 May 2015 (EDT)

Bug report specific article(s)

To my surprise there is no Submitting bug reports article (or Responding to bug reports for that matter), and I remind myself that the relevant information is spread throughout the wiki instead of being summed up in one place.

Some things to consider when writing it (kind of a 'note to self' for now):

  • The bug reports themselves:
    • What bugs should be reported where?
      • FlightGear itself
      • Aircraft, vehicles etc.
      • Airports
      • Scenery
    • What information might be needed?
    • What kind of responses should be expected?
  • Target groups?
    • Non-native English speaking computer novices?
    • Regular FlightGear users?
    • FlightGear developers?
  • Last, but not least: What formal and informal guidelines, rules and procedures do we actually have?

It would be quite preferable from a maintenance perspective to have that information gathered to only a few places and only describe the concepts briefly before linking to those articles, also from the forum and mailing list (in essence DRY – Don't Repeat Yourself).

Johan G (Talk | contribs) 18:23, 10 May 2015 (EDT)

Most helicopter screenshots are now categorized

With some few exceptions all helicopter screenshots are now categorized in Category:Screenshots of helicopters and its subcategories. Tip: Test clicking the blue triangles.  ;-)

What I am trying to achieve is to separate files and articles and to put the files into a browseable category structure (sort of like a tree with some spider webs here and there between the branches). That way they should be easier to find for example when looking for the next picture of the week or a good illustration for an article.

The exception is the files that have gotten a license category, but is not categorized in any other relevant category, are not used in an article and/or does not have a descriptive file name.

See also FlightGear wiki:Village pump/Archive 2014#Having separate image categories or not? (permalink)

I am very slowly working on adding {{file information}} templates, descriptions, links and categories to uncategorized files, with the long term goal of not having any files that not can be found by browsing logical and consistent categories.

Good file names, descriptions, categories and internal linking are all four good 'white hat' search engine optimization (SEO) strategies, in essence making it easier to find what you are looking for. Be that using the wiki's search engine or an external one such as Google search.

Johan G (Talk | contribs) 07:00, 14 May 2015 (EDT)

Disambiguating the two Space Shuttle pages

I would like to hear some ideas of how to disambiguate the two Space Shuttle articles, Space Shuttle originally about the 3D model-less FGData Space Shuttle re-entry FDM but now about the shuttle by the FlightGear space program, and SpaceShuttle - Project Overview‎ modified from that one.

Preferably they could be differentiated by different project names or something like that.

Johan G (Talk | contribs) 12:22, 19 May 2015 (EDT)

Hi Johan,
My two cents are as follows (HW = HerbyW Space Shuttle, TH = Thorsten Space Shuttle):
Shuttle variant Suggestion Comments
HW Space Shuttle (FlightGear Space Program) Too long?
HW Space Shuttle (FG Space Program) Again, too long?
HW Space Shuttle (Space Program) Would make people think that the Space Shuttle is the name of a space program.
TH Space Shuttle (official) Don't like this one myself. Also, might be too controversial.
Favoured by me
HW Space Shuttle (FGSP) None
TH Space Shuttle None
Also, idea for disambiguation text (assuming my favoured suggestions above):
The Space Shuttle could either refer to …
* The [[Space Shuttle (FGSP)|Space Shuttle]] developed from the original Shuttle by {{usr|HerbW}} ''et al'' for the [[FlightGear Space Program]].
* The [[Space Shuttle]] further developed from the above by {{usr|Thorsten}} ''et al'' with new, more realistic [[FDM]]. This is the Space Shuttle that is included in the [[FGAddon]] repository.
I hope these suggestions are helpful.
Red Leader (Talk, contribs) 15:50, 19 May 2015 (EDT)


First off I will apologize for the late reply.
I think I consider it a good idea to move the current Space Shuttle article to Space Shuttle (FG Space Program), moving Space Shuttle - Project overview there instead, and keep the Space Shuttle (disambiguation) page describing both in a few lines. I think that "FGSP" would be a bit too cryptic for the "uninitiated", but that most users would be able to figure out "FG".
The new Space Shuttle and Space Shuttle (FG Space Program) should most probably point to the disambiguation page rather than each other.
Though not really a part of the reply, it is for the record perhaps worth repeating that the current Space Shuttle article previously described the fgdata (later FGAddons) one, but was changed to describe the FlightGear space program/HerbieW/FGMEMBERS one (see diff).
Johan G (Talk | contribs) 18:03, 21 July 2015 (EDT)


Hi.
Personally, I think if we just called Thorsten's (alright, Thorsten, just to eliminate confusion) shuttle's article "Space Shuttle", then did a blurb at the top such as,"For Jon Berndt's model-less fdm and HerbyW's early model, see HERE and HERE".
Just another two pennies towards a dollar
Adam (talk) 18:28, 21 July 2015 (EDT)


Psst, that Red Leader and I mention one as related to the FlightGear Space Program is that both at least was based on Jon Bernt's atmospheric entry FDM and HerbyW's 3D model. ;-)
Johan G (Talk | contribs) 18:59, 21 July 2015 (EDT)
Well, of course, ideally we want SpaceShuttle - Project Overview To just be called Space Shuttle (for purposes of putting best foot--or wing, as the case may be--forward.) Then perhaps we could call Herby's shuttle "Space Shuttle--Model", and the FDM "Space Shuttle-FDM". That makes four cents so far.Adam (talk) 11:03, 22 July 2015 (EDT)
Done Done I have now moved the Space Shuttle articles.
I settled for Space Shuttle and Space Shuttle (FG Space Program).
I have also changed links here and there so they point to each or the other variant to avoid confusion.
Johan G (Talk | contribs) 07:52, 16 August 2015 (EDT)

How do I load Cessna 152 on to FSX (2015) on OS X macbook

Hi I hope you can help. I'm a new user of FlightGear and training for my PPL. I have software loaded on my macbook and have tried out the C172 but I want the Cessna 152 that I'm doing lessons in. I've tried to download from disc but I can't do it. I searched online and can only find an add on for PCs.

Could you tell me where I can find it to download and step by step instructions please?

Z

This unsigned comment was added by Zedbee (Talk | contribs) 19:51, 14 June 2015 (UTC)


You would probably get good answers if you register to the forum and ask in the Mac subforum.
P.S. You can not use FSX aircraft directly in FlightGear, at the other hand there is probably at least one available for FlightGear.
Johan G (Talk | contribs) 16:36, 14 June 2015 (EDT)

Rename Template

Do we have a template which alerts admins to a rename request? Avoiding Multiple Downloads of FGData could have on Linux tagged on, while the EDDK article needs rename to Flüghafen Koln / Bonn (EDDK) and the "AV8R 2nd Throttle as Pan Speed" AV8R Should be Aviator... Legoboyvdlp (talk) 15:42, 7 July 2015 (EDT)

There is no need to call in admins for "renaming" or rather moving articles. ;-)
If you hover over or click on the down arrow between the "More" label and the search box to the top right of the page you will see the option "Move", which is wiki jargon for "rename". Before starting to move pages, have a peek at FlightGear wiki:Manual of Style#Article titles (it is a short section).
Note Please leave a redirect behind even if there is no wiki pages linking to that article. There may be links to that page outside the wiki.
Slightly off topic now, but maybe useful later: To move a category you would have to move the category page and edit all the pages in that category so the category link points to the new category. See also Help:Categories.
You can see the difference in what regular users and admins can do at Special:ListGroupRights.
Johan G (Talk | contribs) 13:15, 9 July 2015 (EDT)
Questions like these are probably also a good reason to improve the help pages in regard to using the wiki.
Johan G (Talk | contribs) 07:02, 16 August 2015 (EDT)

Template:Dmbox and the disambiguation categories

It seems {{dmbox}} adds several categories to each disambiguation page it is used on. In addition {{disambiguation}}, which uses that template, add one category further.

I would say that the "All ..." is superfluous as well. Also, currently none of the categories have a parent category.

Johan G (Talk | contribs) 17:26, 12 July 2015 (EDT)

Description of the FlightGear screenshot categories

I have now written together a description of how I have organized the FlightGear screenshot categories (tree) and the rationale behind them. I think I have been working on categorizing the images and in particular the screenshots uploaded to this wiki since even before the village pump was here, but I have never really tried to explain what it was all about.

I would encourage everyone to have a look at it, in particular if you more or less regularly upload screenshots to the wiki.

I do encourage leaving feedback on the discussion page. However, I also want to point out that this is a de facto description and that some aspects of how the screenshots actually are organized probably cannot be changed without requiring literally man-months of work, even if some things can be done by robot.

Johan G (Talk | contribs) 17:18, 19 July 2015 (EDT)

MediaWiki updated to 1.25.1

I've updated MediaWiki to the latest stable release (1.25.1) today. Please report bugs if you find any. For a list of changes, see https://www.mediawiki.org/wiki/Release_notes/1.25

Gijs (talk) 07:10, 10 August 2015 (EDT)

08/2015: Nasal syntax highlighting no longer working since update

I don't think any of us mere mortals can do anything about that, but you literally need to have superuser powers (Gijs, Simon, Curt) ?

if(var foo = 1 or die(nil) ) {
nil;
}

--Hooray (talk) 07:12, 25 August 2015 (EDT)

From some research, it appears that this was broken due to the SyntaxHighlight_GeSHi extension switching from GeSHi to Pygments, reason being that Pygments is better maintained (see diff summary).
Hope this helps,
Red Leader (Talk, contribs) 16:02, 13 September 2015 (EDT)
Sorry, I simply forgot to re-include our custom Nasal config after the update, just like last time :(
Gijs (talk) 08:59, 15 September 2015 (EDT)

Repository link templates

Moved here from Template talk:Repo link#Todo list (perm), since discussion got more general.

To do

  • {{Repo link}}
    • Protocols (e.g., git://, see above)
    • Add Mercurial to repo types
    • GitLab option
    • Standardize label style (when label is not customized).
    • Download links

Started by Red Leader (Talk, contribs)

I think those are all good ideas. I added {{readme file}} the other day. As I was just looking at {{repo link}} to add links to relevant source code files related to the Conditions article I got reminded by the beauty of less typing. ;-)
In addition I was also reminded about that a more specific template is easier to update when a repository move. Consider for example if {{repo link}} would be used as I mentioned above, linking to a source code file related to an article. If that repository would be moved again or get another URL structure all links to that repository would have to be updated.
A more specific link at the other hand, say {{simgear file}} would only require that specific template to be changed. In addition all links to any of those source files would have the same style, which to some extent will making them more intuitive.
In essence, more specific link templates should:
  • Require less typing
  • Require less maintenance
  • Give a more consistent style
Johan G (Talk | contribs) 17:06, 20 May 2015 (EDT)


Some more thoughts on the sub-templates for links to source files in the git repos, and one for the FGAddon svn repo.
  • Source file/directory templates:
    • Should we use one more or an entirely different meta template, say {{source file}}, to give them a consistent style, for example prefix (FlightGear, SimGear, FGData, etc), showing/not showing full path, etc), instead of doing that in each template?
    • Always or often used parameters should probably not be named parameters
      • I guess always and often used parameters are path and commit
      • Other parameters?
    • Template names, how about:
      • {{flightgear source}}
      • {{simgear source}}
      • {{fgdata source}}
    • Should default to root directory of repo rather than throw an error.
  • Aircraft repo template(s) (slightly off topic):
    • How about {{fgaddon aircraft}}
    • Should default to ..trunk/aircraft/ rather than throw an error.
  • Aircraft URL templates:
    • Needed for a completely different purpose than source links, namely URLs in infoboxes.
    • Would lessen maintenance considerably if a repo/hangar moves.
    • How about {{fgaddon aircraft url|aircraft|revision}}
    • I guess in the same way link templates for other common repos/hangars are added, for example:
      • {{fgmembers aircraft url}}
      • {{helijah aircraft url}}
      • {{fguk aircraft url}}
    • Big question: Download URL or info page URL?
    • When given no params: Link to root directory/hangar main page or throw an error?
  • A category for the templates say Category:Repository link templates with templates and meta templates could be a good idea.
Why do I argue for always or often used parameters to be unnamed parameters? And only lowercase names for the templates? Quicker typing. Simple as that. At least with these templates.
If you guys think this would be ok I could start adding templates right away, probably starting with aircraft URL templates.
Johan G (Talk | contribs) 06:27, 26 May 2015 (EDT)
Hi Johan,
Sorry for the delayed reply.
Just checking, am I right in saying that you're suggesting that there should be a template for Git repos and a separate one for FGAddon (an SVN repo)? It's just a bit hard to read what you mean above. Anyway, apart from that, here's my feedback:
  • Oft used parameters: Using unnamed parameters is good idea. The parameters that would commonly be used would be site, proj, and path. I don't think commit is used as much, though.
  • Defaulting: Where possible, it's probably best to use defaulting, rather than throwing errors.
  • Aircraft URL templates: Another good idea.
  • New category: Agree.
  • Upper/lowercase names: Yeah, we should use lowercase names, especially in the documentation.
  • Name suggestions I think repo instead of source should be used. It's less typing and a bit more descriptive. Also, {{fgaddon repo}}? URL template names are fine to me, though.
Also, do you have any suggestions for link styling above?
Regards,
Red Leader (Talk, contribs) 06:03, 31 May 2015 (EDT)
Sorry for the even later reply.
Often used parameters and name suggestions
I think that site and path parameters would be superfluous, also how about using file instead of repo. Instead of pointing to the whole of the repo usually will point to a specific file or directory within a repo. As you say the commit parameter would only be used sparsely, though I think it might be good to have at times.
In essence I am suggesting {{flightgear file|path|commit}}, {{simgear file|path|commit}} and {{fgdata file|path|commit}} for links to source files (and directories). The path parameter would be what follow after flightgear/src/, simgear/simgear/ or fgdata/.
Defaulting
Yep, it is definitively better to default than trow an error.
Aircraft URL templates
Good point about automatic downloading. I did not think of that. Better link to the info pages.
Link styling
Interesting problem. I have considered both something resembling the path in a local file system or some abbreviated variant, like flightgear/src/Time/TimeManager.cxx, simgear/simgear/magvar/coremag.cxx and fgdata/Nasal/view.nas, or flightgear/Time/TimeManager.cxx, simgear/magvar/coremag.cxx and fgdata/Nasal/view.nas. The advantage with having them look like a file path is to help those using Git to find the file in their local clone faster. Then there is also the issues of whether only the path parameter should be used for the link to the file while there could be an explanatory link preceding it, for example like SimGear/magvar/coremag.cxx, and whether or not to use mostly lowercase the file path like label or the case used sometimes otherwise, in essence flightgear, fgdata and simgear, or FlightGear, FGData and SimGear.
I am going to suggest abbreviated paths but camel case repo names, like SimGear/magvar/coremag.cxx, though I am not convinced it is the best way.
Johan G (Talk | contribs) 17:34, 10 September 2015 (EDT)
Personally, I would prefer all-lowercase, abbreviated links. Camel-case repo names doesn't look quite right in the context to me. However, I agree with everything else you've said. I think that having a central template ({{repo link}}) is not required now. If ever the location of fgdata, FGAddon, etc. changes again, it still wouldn't be too hard to change the location in a handful of templates instead of one central template. Separate templates would also be much simpler than a central one and therefore easier to maintain.
So, apart from link styling, I think we can start implementing these new templates:
  • {{flightgear file}}
  • {{simgear file}}
  • {{fgdata file}}
  • {{fgaddon aircraft}} (right name?)
Regards,
Red Leader (Talk, contribs) 08:45, 11 September 2015 (EDT)
  • Good point about lowercase vs. camel-case. That was one of the things I was more hesitant about.
  • In retrospect I think {{fgaddon aircraft url}} may be a better name, as it renders only an url. (Though it is an awfully long name, as well as the other aircraft repo URL templates. I wonder if "aircraft" is needed?)
  • While the repo link template might not be needed (at least for official repos), a styling template will help keep the styling consistent and may help related maintenance.
How about something like {{source file|base-url=|base-label=|commit=|commit-label=|path=}}? (I suggest named parameters in that one to aid maintenance. It will rarely if ever be used in any other place that those three templates.)
It does not have to be there from the beginning and can be added at a later point (I guess that is the wiki equivalent of refactoring ;-) ).
Johan G (Talk | contribs) 15:33, 11 September 2015 (EDT)
Went ahead and added {{flightgear file}}.
Johan G (Talk | contribs) 16:51, 11 September 2015 (EDT)
I noted that {{readme file}} have a nopath= parameter stripping off the path in that template if empty. A similar effect can be added to {{flightgear file}} using the {{#tileparts: }} parser function without having to introduce a file parameter. An elegant solution if needed.
An even more elegant way could be to use {{#tileparts: }} to only show the last n elements.
Johan G (Talk | contribs) 17:12, 11 September 2015 (EDT)
  • I think {{fgaddon url}} should be fine as it is about aircraft anyway. However, what if we want to link a certain file in the aircraft's directory, e.g., Scripted AI Objects#Aircraft (this would probably also go for an FGMEMBERS template)?
  • A styling template would be a good idea in future. I have one query though: what would be the difference between base-url= and base-label=, and between commit= and commit-label=?
  • nopath= is also a good idea.
Regards,
Red Leader (Talk, contribs) 16:03, 13 September 2015 (EDT)
  • What about doing something similar to the new templates, in essence {{fgaddon url|aircraft|path|commitrevision}}. Of course for example FGUK's and Helijah's hangars will not handle path and commit as those are not repos.
The aircraft repo/hangar templates will probably differ somewhat in implementation, but hopefully for a wiki editor they will be rather "orthogonal" (in the sense that they would be usable in a way consistent with similar templates).
I guess for aircraft repos, as opposed to hangars, the template with only the aircraft parameter given should point to that aircraft directory or submodule. It would also seem reasonable that a template with no parameters given should point to the repo or hangar top directory, info page or something similar.
  • The way I recall having the base-url= thought up would be as the part of the URL preceding the path given in path=. Similarly base-label= would be the part of the label preceding the path.
I am not really sure how (and why) I imagined that the commit reference would be different in URL and label. That would probably not (ever) be needed and only confusing if used.
Johan G (Talk | contribs) 15:50, 15 September 2015 (EDT)
I have noted that there is a need to be able to link to the tarballs. I suggest adding a tarball= property that when not empty will link to the tarball download. (Also mentioned on Template talk:Fgaddon url).
Johan G (Talk | contribs) 07:01, 16 September 2015 (EDT)
{{simgear file}} done. Done Done
Red Leader (Talk, contribs) 08:04, 14 September 2015 (EDT)
{{fgdata file}} done. Done Done
Red Leader (Talk, contribs) 09:13, 14 September 2015 (EDT)
Just remembered a somewhat useful tool when looking for external links to repos to replace with these templates: Special:LinkSearch. Its main drawback is a large one though: It only look for domain names, not paths on a web site. *sigh* At least there is less than 2000 links to SourceForge, which by far have most links (though most of them developer mailing list posts).
Johan G (Talk | contribs) 16:35, 15 September 2015 (EDT)
I have noted that the repository templates also may need a line= and probably also a label= parameter. Many articles have links to particular line in a source file and some have links where even a nopath=1 would currently take up too much space (in particular Canvas MapStructure Layers).
In summary there seem to be a few things we have not thought of yet.
Johan G (Talk | contribs) 07:01, 16 September 2015 (EDT)
The FGAddon article could greatly benefit from being reviewed with a focus on getting rid of/generalizing explicit URLs (or even git instructions) in favor of using templates that encapsulate any URL/git specifics, so that things can be more easily updated in the future. --Hooray (talk) 03:01, 20 September 2015 (EDT)