ayg wrote:

If this is added, the standard term is "titlecase", so "tc".

robchur wrote:

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".

robchur wrote:

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.

ayg wrote:

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).