I am currently using Dart to rewrite the entire application, which is fundamentally simple. It receives words in Turkish or Ottoman and translates them to Ottoman or Turkish. However, the parsing module needs more rules to divide the words (and phrases) into roots and suffixes. There are hundreds of rules, and using only code to describe the reasoning behind parsing seems to be the main reason I spend so much time trying to understand my own work.

I decided that I can just use knot to write the rules in a document and generate the code from it. It will surely take more time than just writing the code, but in the end, I will have a document describing the analysis and parsing rules that even I can understand.

I’m looking for a one-to-one mapping between the different visual elements of a word and its representation in UTF-8. The labels should be simple to remember, yet distinctive enough to represent visual variations of words.

I’m considering creating letter+digit codes. The letter part will reflect the most similar sound, and the digit will reflect the visual variation. In this case, I need a Latin letter for each letter in the Ottoman alphabet, but there are not enough letters in the standard Turkish alphabet to denote all the letters of Ottoman. So, how can I solve this?

For example, in Ottoman, a word is spelled as mnwr (mim-nun-vav-ra), following the Arabic orthography, but in Modern Turkish, the spelling reflects the pronunciation as münevver. Since a one-to-one mapping is not possible between these two writing systems, a set of possible Ottoman spellings must be produced using a regular expression.

When the parser sees münevver, it should convert this to a pattern like mv?nh?(a1)?ww?h?r. This pattern produces a set of strings, where mvnha1vvhr might be the longest and mnwr the shortest. By performing a dictionary search, the system can verify that there is a word in Ottoman spelled as mnwr, thus selecting it as the correct spelling.

The dictionary in our study consists of word labels. The system will look up a set of handwritten word images after this label lookup and search for these images in the document. It can also create a set of candidate images from the regular expression by rendering each candidate spelling.

In order to query a large collection in Ottoman, the user needs to write the query in Ottoman, which uses an Arabic-based alphabet with a completely different set of spelling rules. This limits usability, since most users will not be familiar with the spelling. Experts are, but we can’t assume all users will be able to use it.

There are various methods of transcribing Ottoman to modern Turkish. Many of these use diacritics to denote different long vowels. When it comes to consonants that are spelled identically in Turkish but correspond to different letters in Ottoman, most of these transcription systems are silent. They don’t represent the difference between the letters tha and sin for example, although the first is used in Arabic words considerably. Turks pronounce these two letters identically since Ottoman times, so they are written identically as s in Turkish.

The information content of these two writing systems is different. One has three s letters, the other has a rich set of vowels etc. The Latin-based Turkish script looks more verbose, so I decided to reduce this verbosity to get a set of probable Ottoman spellings.

There are two problems here. In Arabic-based writing systems, dots play a significant role, much more so than in Latin-based scripts. Therefore, these dots should be classified correctly.

The second problem is that the connected components are not always reliable. There are unduly divided components which are part of a single component. We can’t label them as they are, and uniting them into a uniform component requires manual intervention—something we try to avoid.

In the coming days, I’ll try to exemplify these problems and how we treat them.