« java-dep-check-0.3 and weird bugs it discoveredStatCVS and StatSVN »

Applications failing with Turkish locale

11/16/08

Permalink 07:07:16 pm, by Serkan KABA Email , 206 words   English (US)
Categories: Gentoo

Applications failing with Turkish locale

Generally default uppercase/lowercase implementation in class libraries/frameworks respect active locale's behavior. Due to difference in handling of letter I & i [1] applications may fail when locale-aware case conversion is not desired such as parsers, generators etc. The general fix for this issue is to use an English locale in case conversion. I'll give a few example bug reports.

  • A bug in java-gnome bindings generator I reported and its fix.
  • A Turkish locale specific bug in JAXB .
  • A bug I hit in Bazaar that hinders my bundle generation, merge process which only happens in branches with signed commits.
  • A bug in Exaile media player

I guess, I can give more if I google, but I think the above examples are enough to show why applications fail with Turkish locale.

1: http://www.i18nguy.com/unicode/turkish-i18n.html

Addition: I traced Bazaar bug to be really a bug in Python itself, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489740 for how Pardus and Debian fixed Turkish locale issues. Thanks to Jesus Rivero for quick follow up after my request of applying these patches in Gentoo. Hopefully they'll soon be incorporated in portage.
Further Addition: Fixes are committed to portage by Ali Polatel. See bug #250075.

Trackback address for this post

Trackback URL (right click and copy shortcut/link location)

4 comments

Comment from: Tim Kosse [Visitor] Email · http://filezilla-project.org
What a coincidence. I came across a similar problem today and also found that very same page on i18nguy.com

My problem was that FileZilla did not display all toolbar icons, see http://bugs.pardus.org.tr/show_bug.cgi?id=7669 (page content Turkish)
For the icons, FileZilla converts some string of the form "ART_SOMETHING" into "something.png".
The obvious but wrong way to do it would be to just lowercase the "SOMETHING" part.

With Turkish locale, calling wxString::MakeLower (which internally calls the locale dependent towlower) on "SOMETHING" does not equal "something".


I only wish things like these would be better documented. Something like "This function is locale dependent" including a link to a page with detailed examples should be mentioned in every API documentation.

Dotless uppercase I and dotted lowercase i are just too alien for most people to even consider possible unless somebody points it out to them.
11/16/08 @ 22:52
Comment from: robbat2 [Visitor] Email
I've been bugging folk for years about code that wasn't locale-aware for et_EE and tr_TR

et_EE - collation order misses a bunch of letters, so that any regex like y/[a-z]/[A-Z]/ does not give the expected replacement on some letters.
11/16/08 @ 23:32
Comment from: Serkan KABA [Member] Email · http://dev.gentoo.org/~serkan/
Thanks Tim Kosse I reported the issue to FileZilla bug tracker: http://trac.filezilla-project.org/ticket/4014
11/18/08 @ 19:10
Comment from: Serkan KABA [Member] Email · http://dev.gentoo.org/~serkan/
I added an ebuild for the new release candidate for testing. All the icons apperar in the toolbar now. Thanks.
11/29/08 @ 09:43

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
July 2009
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Search

XML Feeds

powered by b2evolution free blog software