FlightGear wiki:Village pump/Archive 2015

From FlightGear wiki
Jump to navigation Jump to search
Replacement filing cabinet.png 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.


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 mw: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 (perm), 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:

Airbus aircraft
Civilian aircraft

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

Regarding the new article FlightGear wiki: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 mw: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)

10/2015: Live preview feature does not enable Save page button

Since the introduction of the "live preview" feature on the wiki, clicking on the Show preview button only shows the live preview at the top of the page - the Save page button remains disabled. This makes saving pages impossible (unless the user has the appropriate privilege on the wiki or the button is enabled manually e.g. via Firebug). -- ElGaton (Contact me) 14:11, 10 October 2015 (EDT)

Thanks for the report! Live Preview was disabled by default, so most users will not have run into this problem. I've now disabled the forced preview, so you can use Live Preview if you like.
Gijs (talk) 08:42, 11 October 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)
I have noted that {{flightgear file}}, {{simgear file}} and {{fgdata file}} all have gotten a line parameter now, which is needed.
Though looking at Special:LinkSearch/http://sourceforge.net I see that links most often go to a path (duh!), then to a path and a line, and then to a path using a label (this I know from looking at a few articles, in particular Canvas MapStructure Layers), but not to a line. Links to commit references currently only are used in the template examples. Note that this is for all links to SourceForge, not just from these templates.
From that I think it would be more user friendly (as in less typing) and still safe to change the parameter order from {{x file|path|reference|line}} to either one of these:
  1. {{x file|path|line|label|reference}}
This would require having to add || fur unused parameters once in a while.
  1. {{x file|path|l=<line>|t=<text>|r=<commit reference>}}.
For ease of template and possibly also article maintenance, but needing a little bit more typing (but no || for unused unnamed parameters).
I think I actually like the second one more.
—Johan G (Talk | contribs) 14:48, 25 September 2015 (EDT)
An article specific improvement suggestion was moved to Talk:FGAddon#Templates instead of explicit URLs (perm).
I have added templates for linking to revision/commit summaries, {{fgaddon revision|revision|t=}}, {{fgdata commit|commit|t=}}, {{simgear commit|commit|t=}} and {{flightgear commit|commit|t=}}.
—Johan G (Talk | contribs) 01:37, 27 October 2015 (EDT)

GitLab and GitHub templates

Hi Johan G,

I suggest we add one or two new templates to link to GitLab and GitHub repositories. I think that they should be similar to {{fgaddon url}}, because they are likely to be used in infoboxes. How about {{gitlab link|project|path|l=<line>|r=<commit reference>}} and {{github link|project|path|l=<line>|r=<commit reference>}}? What do you think about this?

Regards,

Red Leader (Talk, contribs) 15:58, 15 November 2015 (EST)

Sounds like a good idea. Had they returned URLs {{* url}} would have been more fitting. They seem to return a link as you can set a label (t=<text>), so your {{* link}} (or perhaps {{* file}}, for consistency) is more fitting.
—Johan G (Talk | contribs) 21:29, 16 November 2015 (EST)

Shortcuts

I got tired of typing some of the longer names of pages in some of namespaces and looked into how shortcuts are done on Wikipedia (see Wikipedia:Shortcut This is a link to a Wikipedia article). The implementation here is of course a bit less complicated. ;-)

For example you can now get to this page by typing only FGW:VP in the search box instead of FlightGear wiki:Village pump.

For details on how this work see Help:Shortcuts and the {{shortcut}} template.

—Johan G (Talk | contribs) 08:57, 3 October 2015 (EDT)

I think that we should add shortcuts for the newsletters, something like [[FGN Nov 2015]]. What do you think Johan?
Regards
Red Leader (Talk, contribs) 15:58, 15 November 2015 (EST)

Template translations

Moved here from Help talk:Templates#Template localisation (perm), as the part of the discussion begun refer to more than just that page.

Awesome, the {{WIP}} translation as seen on Fr/FGAddon works beautifully :) I hope I don't break things! Unfortunately I cannot edit and translate {{Note}}. It says: "You do not have permission to edit this page, for the following reason: This page has been protected from editing because it is included in the following page, which is protected with the "cascading" option turned on: FlightGear Newsletter April 2015". Is there a way to unlock it? For French it doesn't need changing, but translations are needed for other languages. Bugman (talk) 08:25, 8 October 2015 (EDT)

Hooray accidentally enabled "cascading" there, I've disabled it now, so please try again.
Gijs (talk) 10:48, 8 October 2015 (EDT)
Cheers, that worked. I have now translated {{WIP}}, {{note}}, {{caution}}, {{warning}}, and {{BeingTranslated}} to be available in English, French, and German. Not being a French or German native speaker, there is room for improvement here.
Bugman (talk) 11:00, 8 October 2015 (EDT)
I've now also translated the {{tip}} template into French and German. Are there any more from the {{tip}}, {{note}}, {{caution}}, {{warning}}, {{BeingTranslated}} series? I'd like to add an example section in Help:Templates to help reveal the colourful existence of this useful set of related templates.
Bugman (talk) 06:40, 9 October 2015 (EDT)
Something like:
This article is currently being translated.
Tip  If you do it this way, your life will be easier.
Note  Do not forget to run this command.
Caution  If you run this command incorrectly, your harddrive will be erased.
Warning  Do not delete all FGAddon aircraft.
Bugman (talk) 06:49, 9 October 2015 (EDT)
There is a gallery with templates, Help:Gallery of messagebox templates, showing examples of (hopefully) all the messagebox templates. See also the note on its discussion page. I guess the galleries can be advertised more. ;-)
Regarding the very varying style of all of them, I was at one time working on improving that, see User:Johan G/Messagebox style sandbox, but I somehow got discouraged and/or distracted...
—Johan G (Talk | contribs) 11:54, 9 October 2015 (EDT)
I just made the galleries a tiny bit easier to find on the Help page (http://wiki.flightgear.org/index.php?title=Help:Templates&diff=88101&oldid=88044). These galleries are prefect for creating translated galleries, to help with the translation process. All new wiki contributors should be pointed to them. Keep up the brilliant work with these things, they are really useful!
Bugman (talk) 12:33, 9 October 2015 (EDT)
That is great. Those "translated" galleries would indeed be perfect for that.
When translating the templates though, could you add the lang= parameter to them as well, by adding | lang = {{{lang|}}} to the end of them (see {{LangSwitch}}). That way you could simply add for example | lang = {{{lang|fr}}} to the end of a template in order to review the French translation while working on it. Just remember to remove the fr before saving though. ;-)
—Johan G (Talk | contribs) 14:33, 9 October 2015 (EDT)
Sorry, that was a bit more complicated than needed. To see the translation directly when previewing, adding for example | lang = fr to the LangSwitch template portion of the template you are translating would be enough.
—Johan G (Talk | contribs) 02:22, 21 October 2015 (EDT)

Newsletter templates

Moved here from User talk:Bugman#The collapsible script template (perm).

maybe, we could come up with something similar to this to help clean up the newsletter template ? At some point, core developers were also contemplating to use newsletter contents as templates for some kind of FSWeekend/LinuxTag handout - I guess, a few templates could be used to mark relevant additions in each newsletter and automatically "nominate" those for inclusion in some kind of FSWeekend/LinuxTag handout? The same thing could then also be used for helping come up with a semi-automated ChangeLog/Release announcement, too.--Hooray (talk) 06:52, 20 October 2015 (EDT)

This sounds like two solutions:
For re-usability, maybe each part of the newsletter can be placed into its own article such as FlightGear_Newsletter_October_2015/doc ALS dirt runway effect, FlightGear_Newsletter_October_2015/doc PUI2Canvas. Then this can be transcluded into the newsletter, as well as into a document for ultimately creating the handout. So this would be a fragmentation approach. Here is an external example where I have used this to reuse documentation, and where it is transcluded into a template, itself to be used for transclusion: Template:MessageBox/doc.
The second would be to turn the entire newsletter itself into a template. Then people could just add values to parameters. Here is a little mock up:
{{newsletter
 | stage    = draft
 | date     = October 2015
 | date2    = 2015 10    <!-- for the newsletter category -->
 | title1   = ALS dirt runway effect
 | section1 = devel
 | text1    =
 The Atmospheric Light Scattering framework...
 | title2   = PUI2Canvas: parsing PUI/XML using Nasal and Canvas
 | section2 = devel
 | text2    =
 <gallery widths=350>
 Scenarios-via-pui2canvas.xml.png...
}}
Then the newsletter can be constructed entirely using #if #switch and #tag magic words. Or if combining with the fragmentation approach, the result is even more compact:
{{newsletter
 | stage    = draft
 | date     = October 2015
 | date2    = 2015 10    <!-- for the newsletter category -->
 | section1 = devel
 | text1    = {{:FlightGear_Newsletter_October_2015/doc ALS dirt runway effect}}
 | section2 = devel
 | text2    = {{:FlightGear_Newsletter_October_2015/doc PUI2Canvas}}
}}
The only issue is that the result is that old newsletter might change or break as the template is updated (using a version numbering system in the template name itself would solve this). I also suggest that you (Hooray) shift these last two comments somewhere more public, leaving links to the new location.
Bugman (talk) 09:35, 20 October 2015 (EDT)
yes, that sounds good-we may want to provide some filtering options, i.e. for including/excluding certain contents, such as screen shots/youtube videos (which are typically not used on the website)-equally, youtube videos would not be relevant for creating a handout. That would also allow us to exclude certain "stubs" or standard paragraphs of the newsletter, i.e. "call for help", "translations wanted" etc. And we could also have a handful of broad categories (core development, aircraft, scenery etc) to serve as "channels", which would also allow us to transclude contents spanning more than a single newsletter cycle, or even spanning multiple release cycles (e.g. to create a time-line procedurally). But I guess some additional addons may be helpful to simplify creation/addition of contents, i.e. Johan once mentioned a JavaScript-solution for creating semi-dynamic forms to help with the creation of template-based articles (cannot find it atm). Right, I guess this should be moved to the village pump/wiki namespace - but we once did have a similar discussion already (also cannot find that one).--Hooray (talk) 11:24, 20 October 2015 (EDT)
I am not a huge fan of making things more complicated. :-\
I understand that you consider that it would be nice to be able to automate for example selecting parts of the newsletters for purposes like pamphlets and change logs. However, I think there could be some problems with that.
It would be more work and require more maintenance even with templates that when clicked would start a new page or section with preloaded text.
My biggest issue is that there will be more obstacles to contributing to the newsletter and more cleanup/maintenance to be done. This can already be noticed after the changes between the way the previous and current newsletter is compiled, which are much smaller than the ones suggested. I believe that the further contributing to the newsletter get from contributing to a regular wiki article the more those issues will be more pronounced. In addition there is the increased risk that a newsletter more dependent on templates could more easily break in the future.
I kind of feel that the approach are more akin to writing reusable program functions than writing texts for example using LaTeX macros.
This is not an attempt to veto the idea, more like an What and why are we trying to achieve, and is it worth the initial and following effort?
—Johan G (Talk | contribs) 03:26, 21 October 2015 (EDT)
The {{newsletter_vX.Y}} template concept does introduce a lot more fragility into the system. Especially with a dedicated newsletter template and its interdependencies - the more programmable an article becomes, the easier it is to break. Though an advantage is consistency (e.g. see Template:Informative_template and http://wiki.nmr-relax.com/Template:MessageBox). Another slight advantage is that the newsletter source becomes simpler, so maybe that would make it less intimidating. All of the scary header, and everything after the == Contributing == section could be shifted out of the main article and into the template. This would be an extension of the currently used {{Newsletter-*}} templates - so it would just be shifting these out of sight of those who will be adding the newsletter content. I'll make some quick mock up temporary articles based on the Oct. 2015 newsletter, so that a real comparison can be made.
In any case if the goal is to share content, maybe a better approach would be to shift content out of a newsletter, after the fact and when it is needed, into its own <template_name>/doc <doc_name> article. Then it can be transcluded back into the template and used in the handout. If modifications are needed between the newsletter and handout, then copying and pasting and post-modifying would be more reliable then using template parameters passed into <template_name>/doc <doc_name> to modify its behaviour.
Bugman (talk) 04:01, 21 October 2015 (EDT)
Just a quick KISS comment: Do really doc_ contribute anything. Would not for example {{:FlightGear_Newsletter_October_2015/PUI2Canvas}} be descriptive enough already? ;-)
—Johan G (Talk | contribs) 04:16, 21 October 2015 (EDT)
Oh, and if it is of any help, an (untested) example on how to preload text with a template can be found in FlightGear wiki:Village pump/Archive 2013#FlightGear Newsletter (perm).
—Johan G (Talk | contribs) 04:32, 21 October 2015 (EDT)
The doc_ part was more a de-facto convention that I was aware of. It contributes nothing.
Bugman (talk) 04:40, 21 October 2015 (EDT)
Here are the temporary mock ups: Mock_up_Newsletter_Oct_2015 and Template:Newsletter_v0.1. To note - the simplicity of the newsletter source, the complexity of the template (to be expanded), and the newsletter template number versioning. These are very quick rough tests as a demo, for example the TOC is not programmatically created yet, the [edit] links need to be returned using magic words, etc. But it shows how this would look like in the end. Also note that this is for the templated newsletter idea, not for the fragmentation idea.
Bugman (talk) 04:47, 21 October 2015 (EDT)
It should be possible to format the standard MediaWiki TOC simply by using a custom Template:Newsletter_v0.1.css file to automate this and have it looking similar to the current newsletter TOC. For example see http://csswizardry.com/2010/02/mutiple-column-lists-using-one-ul/. The styles for .toc, .ul, .li, .toclevel-1, .toclevel-2, etc. can then be defined.
Bugman (talk) 07:39, 21 October 2015 (EDT)

Removing a section from the Make nice screenshots howto

Moved here from User talk:Johan G#Removing a section from Make nice screenshots page (perm).

Hi Johan, what do you think about removing altogether the following section of the Make nice screenshots page: http://wiki.flightgear.org/Howto:Make_nice_screenshots#Colors_and_whitebalance IMO, it is a very bad idea to urge users to enhance their screenshots with GIMP or Photoshop in order to "improve" them, as this will result in screenshots that do not reflect what can be achieved in FG. I don't think screenshots are by any standard the same thing as photography, and the only result of these tweaked screenshots will be false advertisement from our part. Nothing against users doing it by themselves if they want to, but "officially" supporting it is a bad idea to me. I also would be careful not to use altered screenshots in our articles the most we can for the same reasons above. See the discussion in our forum starting with this post: http://forum.flightgear.org/viewtopic.php?f=19&t=27674&p=262281#p262271

Cheers, Gsagostinho

While I to a large extent agree with you, in particular with the sentiment that edited screenshots does not portray FlightGear in an honest way, I think it would be a good idea (in the longer term at least) to take it on the village pump rather than here.
Would it be ok to move this topic from here to the village pump?
—Johan G (Talk | contribs) 16:59, 31 October 2015 (EDT)
Maybe I should add that I do understand that some want to take artistic freedoms and that there should be a place for that as well. But the problem of course is, how will someone not familiar to FlightGear know the difference? Preferably without water marks or the like.
—Johan G (Talk | contribs) 17:05, 31 October 2015 (EDT)
It's absolutely okay to move this to village pump. As for the artistic freedoms, I don't think the wiki or the offical website are the place for that, else we will be the single piece of software displaying bogus screenshots on their official channels. My point is: people have all the liberty to do whatever they want, but an official endorsement is another story. That wiki page I linked is basically asking for users to "improve" their images, and if everyone followed it there wouldn't be a single honest screenshot all around. I really believe we need a guideline for this, at least concerning the wiki and official website.
Cheers, Gsagostinho
By the way, I exchanged those screenshots from that page for better ones as the graphics of FG improved a whole lot since they were created, and the whole point of the page is to talk about nice screenshots anyway :) I also fixed some typos.
—Gsagostinho

Introduce newcomers to FG to aircraft details so they can get excited

We are discussing replacement or alternative to Table of Models

Here is the deal: a person new to FG finds FG - Google search for "free flight simulator"

This nets FG as the first result. OK

He is presented with a menu bar saying:

Home | About FlightGear|Download FlightGear|Visit Store|Flying|Posts|Developers|Legacy Site|

Should there not be an extra menu called |View Details of 200+ aircraft models for Flight Gear by category| :)

This will lead to a page very much like the download page with two changes : 2 column table with 2 views of aircraft and 2 views of instrument panel and inside view, plus a short description with 'to do' or aircraft rating status. This way a new user can find the aircraft and download.

I may be willing to test each aircraft in each version - most people are using 3+ I take it.

—This unsigned comment was added by Openflight (Talk | contribs) 06:08, November 3, 2015‎ (UTC)

I think this would be a better discussion for the Forum, rather than the wiki. Adam (else MIG29pilot) (talk) 14:58, 17 November 2015 (EST)

Standardising all the MessageBox templates

I would like to discuss the standardisation of all of the MessageBox templates as shown at Help:Gallery_of_messagebox_templates. Note in this gallery how there is a lack of consistency of the margins, and how each template implements its own style separately. There are also many with a bottom margin set to -0.5em, causing the MessageBoxes to overlap with other elements. This ugliness is often seen in articles, for example at [1]. Is there a reason for this negative margin?

I had the idea of standardising these MessageBox templates all using a common template to implement their style. Specifically by modifying {{MessageBox}} to be a general purpose template to be transcluded into all other MessageBox templates. There could then be different categories of MessageBoxes which use the base {{MessageBox}} template, for example maybe:

Bugman (talk) 14:13, 17 November 2015 (EST)

I looked into that a few years ago. Some of those experiments can be found as subpages to my user page (User:Johan G/Messagebox style sandbox, User:Johan G/Messagebox and User:Johan G/common.css). Those were a mix between how English Wikipedia seem to do it and some ideas related to warning, caution and note boxes and colors as used in flight manuals etc. (see the references in the bottom sections).
Feel free to copy what you like to a subpage to your own user page and work on it from there. I am very sure it can be done in better ways.
—Johan G (Talk | contribs) 17:49, 24 December 2015 (EST)
Here is another article where the margin of -0.5em causes ugly formatting, with the head messagebox partly covering the text of the first paragraph: AI_Systems. If there is a use for the -0.5em margin, I suggest that the bottom margin be a parameter of the {{MessageBox}} template so that it can be set in individual articles as desired. But the default should not be a negative margin. Too much space looks better than a box covering other elements (TOC, text, or other messageboxes).
Bugman (talk) 05:45, 18 November 2015 (EST)
I think some of them originally had that awkward negative margin to make them stack tightly. Something that often is not needed. My workaround when I am too lazy to change the template is to add another blank line before the rest of the content.
I would not be surprised if Wikipedia, from which most templates are blatantly copied (sometimes often without proper attribution; also consider CC-by-sa 3.0 Unported vs. GNU GPLv2), had some mechanisms probably using CSS and/or header and footer templates when stacking messageboxes.
—Johan G (Talk | contribs) 17:49, 24 December 2015 (EST)

Translations

As part of a large overhaul, I would also probably set up all text elements to be within {{LangSwitch}} templates to facilitate the translation process.

It would also be good to have more translations of Help:Gallery_of_messagebox_templates, even it is it just a copy and paste of the English article, as the MessageBoxes will be automatically translated. This just requires an appropriate article name for each language.

Bugman (talk) 14:28, 17 November 2015 (EST)

UTF-8 language pages cannot be edited

I just noticed that when editing a Chinese translation of an article, the following message is seen: "A database query error has occurred. This may indicate a bug in the software". For example http://wiki.flightgear.org/index.php?title=Zh/%E9%A6%96%E9%A1%B5&action=edit or http://wiki.flightgear.org/index.php?title=Zh/FlightGear%E6%96%B0%E6%89%8B&action=edit. This is rather fatal! Any idea what is going on with the MediaWiki settings?

Bugman (talk) 16:43, 17 November 2015 (EST)

Here are some related discussions on the subject: mw:Topic:S1q54kosfdkhz6w1. This looks like a dangerous fix that requires a good back up first!
Bugman (talk) 03:56, 19 November 2015 (EST)
In this link, the user 75.175.9.66 has given some very clear instructions for fixing the broken Chinese pages.
Bugman (talk) 03:59, 19 November 2015 (EST)

This also affects Russian! For example try to edit the main page: http://wiki.flightgear.org/Ru/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0. Something is seriously wrong with the wiki set up!

Bugman (talk) 06:46, 26 November 2015 (EST)

That could explain why I have never been able to recategorize articles in some languages.
I have the impression that the MediaWiki software is not really intended to have multiple languages in one wiki, but rather have separate wikis for different languages. Compare with how there is different Wikipedias for different languages, even using different subdomains. In essence it is quite possible that the current setup is a bit of a hack, though I am in no way sure about that.
—Johan G (Talk | contribs) 17:49, 24 December 2015 (EST)


Replacement filing cabinet.png 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.
Retrieved from "https://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Village_pump/Archive_2015&oldid=94849"