CSS text-transform is language-dependant: the Dutch case explained(firefoxnightly.tumblr.com) |
CSS text-transform is language-dependant: the Dutch case explained(firefoxnightly.tumblr.com) |
İ/i and I/ı
So the lowercase and uppercase are essentially split into two letters and then a new uppercase and lowercase form is created based on growing or shrinking the originals. I'm sure it seemed quite the elegant solution in the 1920s when they were working on the latinized Turkish alphabet.
The implication of this is that unlike the Dutch case, this affects all text-transform actions (uppercase, lowercase, and capitalize).
When we were doing our Turkish localized site I started digging into this, and I was horrified that no browser actually supports proper Turkish capitalization rules. Firefox in particular had a bug open since 2004 (now finally fixed as well). Asking around with Turkish web developers I heard of some crazy hacks (custom fonts!), but I got the feeling that Turkish web designers just avoid text-transform. This was not an option for us as we rely heavily on text-transform in our design (http://tr.mubi.com).
In the end I was able to piece together a surprisingly robust javascript replacement method with some help from Stack Overflow:
https://hg.mozilla.org/mozilla-central/rev/bb53aec4a302
Doesn't look too bad
I'd have expected something like a generic Unicode-aware/y text management layer, and CSS text transforms would just go through that layer.
Of course, this can't possibly work with Kanji without some special hack around.
A more constructive comment might be, "the spelling variant you have used is normally a noun meaning 'a person who depends on another for their upkeep or care', where here you want the more normal adjectival spelling 'dependent'."
Although fwiw it seems that even as an adjective "dependant" might fly: http://www.wordnik.com/words/dependant
A: The existing ligatures exist basically for compatibility and round-tripping with non-Unicode character sets. Their use is discouraged. No more will be encoded in any circumstances.
Language-aware bits are more gross, but then language often is. It's not nicely structured like most of the other things we encounter when transforming data.
I won't blame you for this, it is a common mistake, but Unicode goes far beyond merely mapping characters to integers. The Standard Annexes, Technical Reports and Technical Specifications cover pretty much all things localization from line breaking [UAX14] to regular expressions [UTS18] through date and time formatting [UTS35] or sorting [UTS10].
And as it turns out, both uppercasing and titlecasing are covered by [UAX44] as part of the SpecialCasing.txt file which provides lower, upper and title-casing (along with optional conditions) for characters with non-trivial mappings (trivial 1:1 mappings are covered in the base UnicodeData.txt file)
[UAX14] http://www.unicode.org/reports/tr14/
[UTS18] http://www.unicode.org/reports/tr18/
[UTS35] http://www.unicode.org/reports/tr35/
Making something more complicated doesn't make it better. Make it more complicated when you need to, not before.
There is some specific cases with accented Greek diphthongs, where the diacritic position changes in upper and lower case, but Mozilla is working on a fix.