Last modified: 2011-03-13 18:06:23 UTC
Please add {{ic:}} (from: Initial case, or choose another name) which will behave like {{ucfirst:{{lc:<string>}}}} per entire string (icfirst) and per each word (ic). {{ic:lorem ipsum}} = Lorem Ipsum {{ic:LOREM IPSUM}} = Lorem Ipsum {{icfirst:lorem ipsum}} = Lorem ipsum {{icfirst:LOREM IPSUM}} = Lorem ipsum Thanks.
If this is added, the standard term is "titlecase", so "tc".
Well, title case keeps things like "or" and "the" as lowercase-first, unless at the start, so technically not...
Right. But it's closer to the mark than "Initial case".
Hm, interesting. Yet the user making the request seemed to prefer "initial case", so perhaps from a user point of view, it's not. Then again, all users are not alike. Conclusion? Add them as aliases of each other, and be done with it.
I'm willing to take a look at it. Just need to teach myself how to make these colon functions. I'll definitely check with others before committing it, though.
Fixed in r17367, after discussion on IRC with Simetrical.
Reverted in r17375; there's no clear use for this function and it would produce obviously incorrect results for mixed-case or all-caps words. Please avoid feature creep, *especially* in the parser. New functions must be supported forever for compatibility, which we shouldn't have to do for useless things.
Reopening, because: I think at least {{icfirst:}} can be realized with no doubts. As been said in comment #0 {{icfirst:<string>}} = {{ucfirst:{{lc:<string>}}}} so {{icfirst:lOrEm IpSuM}} = {{ucfirst:{{lc:lOrEm IpSuM}}}} = Lorem ipsum I guess calling of one colon function is much nicer for parser than calling of two of them nested whereas {{icfirst:}} has pretty wide usage ability. Regarding {{ic:}}: This was meant to make initials on each word in string regardless if it's article or preposition or so, therefore it was *not* intended to be use as regular titlecase. Actually it was born just as an complement (to have entire pair such as other similar functions) of {{icfirst:}}, which was the original purpose of this request. So it's not necessary to implement it, although I can imagine useful cases.
Both are feature creep. Neither is terribly useful. Robust string functions of some type might be added to ParserFunctions someday, which would allow you to do this kind of stuff and more, but a special tag for this in the parser itself is no good, and of dubious utility even in ParserFunctions (as opposed to more generalized functions that can produce this as well as more useful things).
