User talk:Svippong

 Dear, Welcome to MediaWiki.org !

Yes, Welcome! This site is dedicated to the documentation of the MediaWiki software, the software behind many wikis, including that of Wikipedia and the Wikimedia Foundation projects.

Please, take a look at the following pages. They might prove useful to you as a newcomer here:
 * Project:About
 * How does MediaWiki work?
 * Help:Editing pages
 * Help:Navigation
 * Manual:FAQ

If you have any questions, please ask me on my talk page. Once again, welcome, and I hope you quickly feel comfortable here, and find this site a beneficial documentation of the MediaWiki software. Thanks, and regards, --Jack Phoenix (Contact) 21:41, 22 March 2010 (UTC)

NaturalLanguageList ideas
Options are still slightly confusing, ideas: Feel free to ignore me completely or partly, I always waste too much time on trivial choices. Conrad.Irwin 03:09, 24 March 2010 (UTC)
 * rename itemcover=/itemoutput= to format= - easier to remember.
 * calculate fieldsperitem from format= - one less thing for the user to type. (should be possible to count the $i's)
 * make duplicates default to false, that way any value passed to duplicates=/blanks= can be treated as true (saves having to parse a boolean option in all languages)
 * (possibly: change separator= to comma= and lastseparator= to and= - easier to type and more fun :)
 * change #data: to data=, and #ignore: to ignore= (i.e. the user has to say |ignore=a|ignore=b) easier for us to process and less surprising than "magic" syntax (maybe also less pretty though).


 * Let me comment on your suggestions in the same order.
 * I agree, it is a better choice. Even as just 'format' (rather than perhaps 'itemformat'), it is less ambiguous than say 'output'.
 * Good idea, but keep the fieldsperitem option in case some users want to force it through (say, if a template returns the $n characters to be parsed on later).
 * See, originally duplicates and blanks defaulted to true, but I realised that in more cases than not would people prefer duplicates set to true rather than false. In addition, I am still not convinced that translation of the options is what we need (certainly not the case for many other extension's hooks and parser functions).
 * Maybe as extra names, I like the others as internal representation.
 * Hmmm... the jury is still out on that one. It has its arguments - yes, but the original reason to use a different syntax was to highlight their difference, but if one for each field is not required, then perhaps it makes sense.  As an additional suggestion; when used with , perhaps it should be possible to use |ignore= in the same manner (i.e. with a separator like the input data), in case they have a template that actually returns the ignore data as well.
 * They are not all bad suggestions, actually, but I am feeling a middle ground can be found several places. --Svippong 07:13, 24 March 2010 (UTC)

And here is your diff.

As you will notice, I did not attend bullet 3 and 5. Not because I am fundamentally against them, I just feel they are big changes. Though, given its lessen distribution as of now, we should perform the big changes for now. Your fieldsperitem/format idea was cool though. --Svippong 09:49, 24 March 2010 (UTC)

AdditionalTabs
In your page/code: AdditionalTabs I attempted the modification to SkinTemplate.php, and it did not work. I am running the latest version of mediawiki, and i think that may be why but wanted to be sure and ask the pro who came up with it. Does that portion still work or does it need to be edited for newer release of mediawiki?
 * It needs to be updated, yes. I have not been looking at it for almost a year, due to lack of interest, but maybe now I might look into it. --Svippong 23:23, 25 February 2011 (UTC)