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)