In what way do they not work?

The magic words are not recognized, it tries to load templates with the ucfirst or lcfirst names.

http://tr.wikipedia.org/wiki/Kullan%C4%B1c%C4%B1:Brion_VIBBER/ucfirst-bug

Broken by r84057.

Heh... looks like that basically broke the case-insensitive matching of the keywords. :)

{{ucfırst:blah}} (using dotless lowercase i!) does work, as does {{UCFIRST:blah}}
(uppercase dotless I)

I have added Brion tests to our parser tests system with r99246.

$ cd tests
$ php parserTests.php --file=parser/bug31490.txt

Noted on CR; Special:Specialpages crashes with a fatal error as well: http://tr.wikipedia.org/wiki/%C3%96zel:%C3%96zelSayfalar

Looks like we'll do a quick revert on the lc() / uc() for the moment until we get a cleaner case-sensitive compare.

This .... I think will also partially revert r99074, which changes the uc() logic. I'm not sure if the $first parameter on uc()/lc() is used by anything other than ucfirst()/lcfirst() default implementations. icky :)

Ok, r99289 / r99290 backs out the lc/uc() implementations in r84057, r84080, part of r99074.

• Special:Specialpages now works (good!)
• {{ucfirst:}} works again
• {{lcfirst:}} works again

The existing ucfirst()/lcfirst() remain, which handle uppercasing the first letter of page titles.

ademozcna wrote:

Thank you. Other turkish wikis can be updated? do not work ucfirst, lcfirst.
Example: tr.wiktionary. http://tr.wiktionary.org/wiki/Ahat

ademozcna wrote:

no problem. ok.

ilhan wrote:

And how we will handle IPhone_4 -> iPhone_4. Now it works as this; IPhone_4 -> ıPhone_4
See http://tr.wikipedia.org/wiki/IPhone_4

We had a discussion on IRC about this bug last week with the operation team. The position was that we preferred reestablishing the magic word lcfirst & ucfirst functionality.

I have this bug on the top of my bug fixing task list but it need a proper patch to not break the magic word using a dotted i :-P

removing dep on tarball blockers for things that aren't in mw core.

• Bug 32707 has been marked as a duplicate of this bug. ***

Is this a duplicate of bug 28040, or are they subtly different?

Here is a summary of the issue this bug is about.

r84057 implemented string upper/lower casing methods for the Turkish language.

The MediaWiki code handling magic words normalize then to lower case using the content language (see lc() calls in MagicWord class). Hence a magic word such as lcfirst is treated just like a turkish word and end up upper cased with a dotted i.

Two possibilities:

• magic words could optionally be made an array referencing the language. Then we could use that language thus using the proper lc / uc implementations
• for turkish language, forge magic words aliases having dotted or dot less i. i.e. 'ucfirst' (with dot) could have an alias UCFIRST (without dot). Both would then be valid.

ilhan wrote:

(In reply to comment #15)

• magic words could optionally be made an array referencing the language. Then

we could use that language thus using the proper lc / uc implementations

Yes. This option seems better.

*** Bug 33299 has been marked as a duplicate of this bug. ***

The original issue was about lcfirst / ucfirst being broken on Turkish wikis. This has long been solved by reverting the code.

The issue derived to about our Turkish language class lacking uc() / lc() implementation. I have thus split that part in a new bug report : bug 33643

So there is nothing left in this bug.