User talk:Bugman
Jump to navigation
Jump to search
The collapsible script template
Noticed the {{collapsible script}} template. That will probably come in handy in many places.
I had no idea that there was such a thing as {{#tag: }}
. That may be useful later when I have played around with it.
Hmm, I see the template defaults to Dec Vadic's Imperial Arem Star. lol ;-)
—Johan G (Talk | contribs) 18:12, 16 October 2015 (EDT)
- There are quite a few places in the wiki cluttered up by long scripts or code segments. I guess it is mainly Nasal, though some other parts could benefit from other templates using collapsible NavFrame elements. The
{{#tag: }}
concept is quite useful for programmatically adding tags in templates, avoiding the initial HTML parsing, but it isn't perfect. Anyway, I can see it spreading on the wiki already :) As for the template default, I hope no one is curious and tries it out!
- Let me add that
{{#tag: }}
allows for transclusion within any HTML tag, which is normally not possible.
- 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.
- 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)