In particular, I'd like to talk about the Turkish alphabet. Basically it is just a Latin alphabet with some few extra letters. There is one detail however which makes it unlike most other Latin-derived alphabets (Azerbaijani alphabet is the only other case I know of). In the Turkish alphabet, there are two different types of the letter i: Dotted and dotless, each with their own upper and lowercase versions (I hope your installed fonts can display this):
The English lowercase i is the Turkish dotted lowercase i, and the English uppercase I is the Turkish uppercase dotless i.Dotted: i İ
Dotless: ı I
What's the problem? The answer is simple: Collation. Assume you have the string "SOMETHING" and want to transform it into "something". In virtually all locales, you just transform "SOMETHING" into lowercase and get "something". Not so with Turkish locale. Remember the two types of i? Transforming "SOMETHING" into lowercase would result in "somethıng" with the dotless lowercase i.
In case of FileZilla, this was the cause of a particular bug where on Turkish systems, some of the toolbar icons where missing. You must know that FileZilla addresses the toolbar icons with identifiers like "ART_SITEMANAGER" with the corresponding filename called "sitemanager.png". So if simply stripping the ART_, transforming the remainder to lowercase and then adding .png made FileZilla search for "sıtemanager.png" which obviously does not exist.
The solution is to use a locale-independent function to transform uppercase letters into their corresponding lowercase letters based on ASCII. We can do this since all the identifiers used by FileZilla are in fact valid ASCII strings.
A similar problem was in the directory listing parser where for some listing formats, the substring "dir" was case-insensitively searched for. Same solution.
There's still an outstanding issue with filename extensions for the automatic ASCII/binary filetype detection. I have thought hard, but couldn't come up with a good solution yet.
After the semantic split between turkey and Turkey, let's talk about a different class of splitters. By that I obviously mean wxSplitterWindow. I've been working on making the location of the message log configurable.
While not a hard task, I quickly became annoyed by the complexity of the class that manages the main window of FileZilla. I've spent quite some time to refactor the code. Essentially, I've moved most splitter related code to a new class. Initial testing was successful, at least no major regressions. But as always, Schroedinger's Cat is in the details.
