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.

The reason I had to stop was the lack of data, since without a considerable amount of data, statistical methods for both Natural Language Processing and Computer Vision fail. Producing and maintaining data seemed a much greater burden than providing technical solutions, so I mostly gave up the idea that a working solution is obtainable with classical OCR techniques. The research is still waiting for me to finish.

I am beginning this series of explorations in Computer Vision, Machine Learning, and related fields to document my achievements and provide a basis for further research. From time to time, I will provide results regarding the ideas discussed here. Currently, this is mostly a hobby/side project.

My current endeavor is to write a robust translation engine between Ottoman and Turkish in Dart.¹

Instead of performing a full-fledged morphological analysis like TRMorph, Google Research Morphological Analyzer, or Starlang Morphological Analyzer, our aim is to provide a surface-level to surface-level translation between Arabic and Turkish scripts.

It is true that it’s possible to use something like:

+-----------------+                +----------------+                 +---------------+
|                 |                |                |                 |               |
|                 |                |                |                 |               |
|    kelimeler    |    +------->   |  kelime+PLU    |  +----------->  |   کلمهلر      |
|                 |                |                |                 |               |
|                 |                |                |                 |               |
+-----------------+                +----------------+                 +---------------+

to translate between Turkish Latin and Ottoman, but there are two problems here:

1. There is no Ottoman morphological analyzer, and although grammatically Turkish, surface-level forms should be translated. Even morphological analyzers for Turkish in the Latin alphabet are relatively recent.

2. Translating the output of a Turkish Latin morphological analyzer to Ottoman seems like more work than writing a translation method itself.

For example, for the query kelimeler TRMorph gives

    kelime<N><pl>
    kel<Adj><0><N><p1s><dat><0><V><cpl:pres><3p>
    kel<Adj><p1s><Prn><dat><0><V><cpl:pres><3p>
    kelime<N><0><V><cpl:pres><3p>
    kelime<N><pl><0><V>
    kelime<N><pl><0><V><cpl:pres><3p>
    kelime<N><pl><0><V><cpl:pres><3s>

and although most of the items’ surface forms are identical, we need to work through all suffixes and their different kinds of connections. Also, as the surface form of Ottoman Turkish has less information, Ottoman morphological analysis would yield many more results than its corresponding counterpart.

Because of these hindrances and trying to come up with a quick-and-dirty yet workable solution, I have made the following observations:

1. Our part-of-speech system does not need to be highly specialized. Actually, we only need to have three classes: Nouns, verbs, and proper nouns. Proper nouns are grammatically nouns, but their orthography may require different rules. We will call these three word classes.

2. We can get away with a set of surface-level rules to translate suffixes for each word class. These rules use attributes that can be derived from Turkish Latin orthography.

These rules are:

• Part of Speech: The root class we discussed above.
• Last Vowel: The last vowel in a Turkish root that is required to find the actual suffix when vowel harmony is utilized.
• Last Consonant: The last consonant of the Turkish root. This is needed to find the palatalization/softening of certain consonants.
• Ends with Vowel: Whether the root ends with a vowel, like ata, or not.
• Has Single Vowel: Whether the root has a single vowel. This is important for aorist inflection irregularities in verbs.
• Last Vowel Hard: Whether the last vowel is one of a, ı, o, u (back vowels) or not.
• Last Consonant Hard: Whether the last consonant is one of p, ç, t, k and undergoes softening when it receives a suffix starting with a vowel.
• Has Consonant Softening: The inverse of the last consonant hard rule, occurring when a root ends with b, c, d, g and receives a suffix.

From these rules, which can be derived from the Turkish Latin forms of the words using regular expressions, we can write rules to translate Turkish to Ottoman and vice versa.

To be continued.

1. Dart has the little benefit of being able to run both on mobile (in Android and iOS) and servers with support for the web, so write once, run on Linux, iOS and Android is feasible without much architecture jumping. I hope Flutter gains more traction and becomes the mainstream way of writing mobile applications. ↩

The first one is used when there is a single expression to write:

(a, b) => a + b

The other is used when you need to write multiple statements in an anonymous function:

(a, b) { 
  return a + b; 
}