Finite-State Turkish Syllabification Algorithm

I did not develop the Turkish syllabification algorithm merely as a text utility. The work converted an academically studied natural-language-processing approach directly into executable code. In August 2022, I prepared the chapter "Image and Audio Processing" for the academic book Artificial Intelligence from Theory to Practice, published by Nobel Academic Publishing. Under the heading "Multimedia from the Perspective of Natural Language Processing," I addressed Turkish syllabification with a deterministic finite automaton model. The book was published in December 2022 and registered under ISBN 978-625-427-802-0. The publisher's official record also lists me among the authors.

The C# implementation I shared is not a simplified example of the theoretical discussion in the book. It is a table-driven executable form of the same approach. I converted the state machine described academically through vowel and consonant patterns into an algorithm that advances at runtime without regular expressions, dictionaries, or backtracking.

The code is therefore not a later illustration of a theory presented in a book chapter. It is where academic study and software-development experience converge around the same problem.

The syllabification model in the book

Turkish words can be syllabified by following the arrangement of vowels and consonants rather than examining characters only in isolation. I used a two-symbol alphabet for this purpose in the book chapter:

A = vowel B = consonant

The actual characters of a word are first reduced to this abstract alphabet. For example:

Muhammet -> BABBABBA Ankara -> ABBABA Türkçe -> BABBA

The algorithm therefore does not need to know separate properties of m, h, k, or r. Only whether the character at a position is a vowel or consonant matters.

The automaton presented in the academic book contains 20 states including the initial and error states. State names represent the relevant vowel-consonant suffix observed up to that point:

0 Initial 1 A 2 B 3 AB 4 BA 5 BB 6 ABB 7 BAB 8 BBA 9 BBB 10 ABBB 11 BABB 12 BBAB 13 BBBA 14 ABBBB 15 BABBB 16 BBABB 17 BBBAB 18 BBABBB 19 Error

Each new symbol, together with the current state, determines exactly one next state. Because no state and input pair has more than one possible transition, the model is deterministic.

In the example given in the book, the expression Muhammet Ali KÖKER is processed by returning to the initial state at word boundaries, producing:

Mu-ham-met A-li KÖ-KER

A finite-state approach to Turkish is not unique to this implementation. Finite-state technologies have long been used in Turkish morphology, pronunciation generation, and syllabification. The Turkish pronunciation lexicon developed by Oflazer and Inkelas also relies on a finite-state architecture that produces pronunciation and morphological analysis from word forms.

The objective of my implementation was not to produce a complete pronunciation lexicon, but to identify syllable boundaries through a low-cost and explainable core.

From a DFA to a finite-state transducer

At first glance, the source code resembles a DFA implementation. Because it produces syllables rather than only an accept or reject result, it is technically more than that. The algorithm emits output while moving through the states.

The executable structure can therefore be described as:

M = (Q, Σ, δ, λ, q0)

where:

Q = set of states Σ = {end, consonant, vowel} δ = state-transition function λ = output function q0 = initial state

A pure DFA advances only through the transition function δ. In the source code, every transition also contains two pieces of information:

starting offset of the output character count of the output

These are stored in two constant matrices. A third matrix determines the next state:

States[inputClass, currentState] Counts[inputClass, currentState] Offsets[inputClass, currentState]

This structure brings the state machine closer to a deterministic finite-state transducer. The algorithm does not merely recognize a vowel-consonant sequence. As soon as sufficient context exists, it also knows which character interval to extract as a syllable from the original text.

The theoretical structure described through a transition table in the book is converted in code into three dense integer matrices. Decisions are stored as data rather than written as a long chain of if or switch conditions. This shortens the execution path and allows the state transitions to be inspected as a whole.

Step-by-step execution

Four primary variables are used during execution:

a = input class b = current state c = position in the text d = length of the syllable to emit

Initially, both the state and text position are zero. Each iteration applies the following sequence.

Classifying the character

If the end of the text has been reached, the input class is 0. Otherwise, the current character is searched in the vowel table:

0 = end of text 1 = consonant 2 = vowel

Vowels are stored in a sorted character array and checked with binary search. In addition to the basic Turkish vowels, the array contains uppercase and lowercase forms of â, î, and û.

Because the vowel table has constant length, classifying one character has constant practical cost. The general complexity of binary search is O(log V), but here V=22 is fixed.

Finding the output action

The current input class and state are used as indices into the output matrices:

length = Counts[a, b] offset = Offsets[a, b]

If the length is greater than zero, the syllable is extracted from the original text using:

start = c - offset length = length

This is why the algorithm requires no separate accumulation buffer. Instead of storing all previous characters independently, the automaton knows how many characters to move backward from its current state.

Position and state transition

After output is produced, the text position is incremented. If the text has not ended, the new state is read from:

b = States[a, b]

Processing continues until the input ends. The output row associated with the end-of-input class emits the final syllable that has not yet been published. No separate buffer-flush code is needed after the loop.

Lazy and streaming output

Returning IEnumerable<string> and using yield return is an important design decision. The entire text is not processed when the method is called. Processing begins when the result is actually enumerated.

This has three consequences:

The complete syllable list is not created in advance.

If the consumer stops after the first few syllables, the remaining text is not processed.

No additional List<string> or list-growth cost is introduced.

A separate result string is created for every syllable, but there is no second collection holding all syllables. The automaton's own execution state therefore remains constant in size.

For a text of length n, every character is classified once and participates in one state transition. The total length of extracted substrings is also bounded by the text length in a valid syllabification flow. Therefore:

Time complexity: Θ(n) Auxiliary state: Θ(1) Output space: Θ(n)

If h is the number of syllables, at least h result strings are created. The algorithmic core uses constant space, while output allocation naturally depends on syllable count.

The raw data footprint of the three integer matrices and the vowel table is below one kilobyte. The design can therefore run locally and deterministically without large dictionaries or statistical models.

Value of the table-driven design

The implementation uses no regular expression. It does not scan the character sequence repeatedly. It does not split the word at every possible point and test the outcomes. It uses neither a morphological analyzer nor an external dictionary.

Every step is reduced to three accesses:

character class output action next state

This structure strengthens verifiability before performance. The complete transition table can be tested. Vowel, consonant, and end-of-text behavior can be validated separately for every state. The same input produces the same syllables on every execution.

The code structure directly matches the rule-based natural-language-processing approach emphasized in my book chapter. Instead of training a machine-learning model, the regular phonotactic structure of the language is converted into finite states. The rules described academically become constant transition tables in the implementation.

The source code should therefore not be viewed only as a syllabification helper class. It is one of the concrete algorithmic outputs of the natural-language-processing layer addressed in Artificial Intelligence from Theory to Practice.

Linguistic validity domain

The algorithm does not know a word's meaning, root, or suffixes. It makes decisions solely from vowel and consonant patterns. This choice provides a strong and explainable basis for native Turkish words:

merhaba -> mer-ha-ba ankara -> an-ka-ra çocuk -> ço-cuk türkçe -> türk-çe özdevinir -> öz-de-vi-nir

Complex consonant clusters in loanwords, abbreviations, URL fragments, numbers, and punctuation cannot be modeled completely with only a two-symbol alphabet.

The source code places every character absent from the vowel table into the consonant class. In addition to actual consonants, this class includes:

space punctuation digit apostrophe hyphen other Unicode characters

This behavior can allow spaces to be removed with Trim in simple sentences. The shared example can therefore appear to syllabify correctly. Formally, however, a space is not a consonant. Punctuation can also become attached to the final syllable:

Merhaba, -> Mer-ha-ba, Türkiye'de -> Tür-ki-ye'-de

A stronger production design should divide characters into at least four classes rather than three:

end of text word boundary consonant vowel

Alternatively, the syllabifier should operate only on word segments identified beforehand. Separating tokenization from syllabification also makes the state space of the automaton clearer.

Boundary conditions in the shared version

Although the algorithmic core is compact, the shared version contains an important difference between the matrix dimensions and the academic state table.

The transition matrix contains 19 columns for states 0 through 18. The output-length and offset matrices contain only 17 columns, covering states 0 through 16. Because the transition table can reach states 17 or 18 for selected patterns, the next iteration can access the output matrix out of bounds.

The error state numbered 19 in the academic table is also not represented explicitly in the executable code. Some error transitions in the explanatory table are directed to different operational states in the source arrays. This file alone does not establish whether that is an intentional recovery policy or a version mismatch between the tables.

In my step-by-step tracing of the source, some loanwords beginning with complex consonant clusters expose two separate risks:

A negative starting index for the substring to be extracted

An output-matrix boundary violation after entering state 17 or 18

Words such as program and strateji, both used in contemporary Turkish, make this validity boundary visible. Testing only native Turkish syllable patterns is therefore insufficient for a production version.

For hardening, the state and output tables should cover the same state space. Behavior for an unsupported pattern should also be selected explicitly:

raise an error return the word unchanged apply a rule-based fallback search for a dictionary exception

One of these policies should replace silent progress toward an invalid index.

From academic study to an engineering product

The main work in developing this algorithm was not merely listing Turkish syllable rules. I converted the rules into a finite state space, defined transitions in table form, and added syllable-emission actions to the same execution model.

The implementation combines three layers:

1. Modeling Turkish vowel-consonant patterns

1. Table-driven application of finite-automaton theory

1. Lazy, constant-state output generation in C#

This relationship shows that the academic reference at the beginning of the code is not only a bibliographic note. The "Image and Audio Processing" chapter in Artificial Intelligence from Theory to Practice did not limit audio and image processes to multimedia data. It treated text processing as another layer of the same system. The syllabifier is one of the directly executable examples of the "Multimedia from the Perspective of Natural Language Processing" approach in that chapter.

The code's technical value does not come from a large number of classes or abstractions. It comes from reducing a linguistic rule set to a linear-time transducer driven by constant tables. Source inspection also shows how important it is to keep the theoretical state table exactly consistent with its implementation tables.

For me, this work was a development experience at the intersection of natural-language processing, formal languages, and software optimization. The model explained in the academic chapter became a measurable algorithm in source code. This is where the transition from theory to implementation becomes visible.