What does this site do:
It translates, or attempts to, klingon text. It does so by splitting words into syllables and looking for translations for them. For more details, please visit the homepage for the actual program, KTH.
This site here is actually a mere shell for that program, which runs on the server by using Linux Mono to run a C# executable. By now, the shell is pretty complex as well, which is why I have to explain quite a bit here.
Note: All parameters have tooltips to give short explanations about their functions.
"Simple" output means mere text output, no fance graphics. Effective, but not as nice as the complex output. However, it doesn't have a size restriction, so it may be more useful in some situations.
"Complex" output uses fancy graphics to simulate a klingon display (as seen in the game Star Trek Klingon). It can react to screen size, shrinking or growing as necessary, but only in a limited range - the minium size is 700x600 pixels free screen estate.
Since the enhanced text is hidden by default, you have to tell the website to show it:
"Hover" - as soon as your mouse merely hovers above a recognized klingon word the information is shown.
"Click" - you have to actually click on the word and hold the button. Perhaps more inconvinient, but has the advantage of not dazzling you when you scroll through the text with your mouse.
So when the text is longer than the surrounding field, it doesn't just overwrite it anymore, it creates a scrollable window inside the page. Looking better for the cost of enabled JS :-)
"Raw" - no additional compression is used. The server-browser communication should be gzip-compressed already.
"JS" - in addition to the gzip compression, the communication between server and browser is increased by replacing words and letter-combinations with single characters. More about this below.
"Translate" does exactly what it says. Depending on wheter or not you use JS compression, the text may be changed.
"Decompress Textfield" is used to decode the textfield, if you return from the result screen by going back.
Beyond direct input
While direct text input is the intended purpose, you can also link to this page with parameters, so you get instantly the result page.
To do this, you have to append the text you want to enhance with "?GETText=". If you want complex output add "&OC=X".
More about (web)KTH
This shell exists because the original program is rather cumbersome to use - sure, it will run on Linux (using Mono) and Windows, GUI or non-GUI - but you have to supply a load of text and can't just write it up. Nor will the output be simply displayed, you have to open the resulting HTML.
All this this shell changes - you can copy text into the text area or write it, and the result will already be in your browser. (With a nice, if simple, GUI surrounding it.)
How it works
The actual program
It's a rather primitive program to be honest. Hence the crude name which is intentionally wrong.
The program splits klingon words into their syllables(which are mostly regular) and then translates each syllable for itself. The result is a crude but helpful translation.
It's a PHP script that communicates with the KTH program on the server(running Mono) via the console.
Naturally, this is not the natural way for a website to talk to it's underlying program. Normally the underlying program would be part of the web server - like PHP is.
But since the program wasn't originally intended for server use - I only had that idea when I realized that a .Net program can be run be Mono - I had to improvise.
All communication between script and program is done via GZIP64 - that is, compressed with GZip and encoded as Base64. Among others, it improves performance.
The server is configured to compress all packets exchanged between Browser and itself with GZip, so in theory the communication is compressed already. However, that doesn't mean it can't still be improved.
My first try was LZW - but that seems to be only useful for repeated strings. So I turned to something simpler - a primitive Huffman encoding. Instead of trying to actually compress, I chose to replace.
What I did was chosing letters and "words"(actually HTML tags) and replacing them with single characters in the upper single-byte range. These characters are not part of the common latin alphabet - at least not part of the usual alphabet. (I.e. any character that doesn't have special markings like german Umlauts.)
This Sequence Replacement Compression, as I like to call it, works both ways of course. Even if the text going from browser to server saves only a few bytes, the text going from server to browser will save hundreds if not more, because I can replace large chunks like "<div class=", which occur many many times in the resulting HTML code.
Hence the SRC is merely optional. You can use it, but you don't have to. You lose nothing if you don't.