| Q: How does the translator work? There are 29 scripts and 42 note cards. If printed, all the code would fill 373 pages, using 21,171 lines, 94,668 words, 510,623 printable characters, and 668,975 characters with spaces. This short summary barely scratches the surface of all the coding involved. These programs include:
The update server and web site is on a dual redundant pair of machines, at two different locations, with a replicated SQL server database. The web site is written in Perl. The updater runs on an 8-core Dell 1950 server in a 5-fiber data center and a two-T1 backup center. The translator will work even if both data centers were to go down. The translator goes directly to Google for all translations. No private or public messages are ever sent or stored. The primary use of the server is to allow only Second Life Mentors and authorized dealers to transfer the translator, and to control the email traffic used in-world for automatic updates. A scanner looks 20 to 96 meters for nearby avatars. Their name, viewer language code, distance, ID code and language is stored, sorted and displayed in the hover text scanner. The distances and languages are updated dynamically, and avatars that are out of range are removed from the list. Any text sent to you is buffered in a first-in, first-out buffer, and if the message passes the filters for Objects and Avatars, is sent to Google for language detection. Google performs the detection, and returns a JavaScript Object Notation (JSON) packet. The dial indicator is updated. The language codes may be updated if the quality is good. Because there is a limit to the number of HTTP requests per script, (25 in 20 seconds), the message and queue control flags are passed to another script. This allows the maximum number of messages possible and reduces the possibility of HTTP throttling to the absolute minimum that is possible. Each message is put into another FIFO with identifying information, and queued for translation. Google performs the translation, and returns a JSON packet with the converted text. After JSON is decoded, the Unicode and special web characters are converted to Second Life format. Arabic and Hebrew languages are flipped right to left. The final result is sent to you privately along with the name of the person that typed. The text you type may also be auto-detected. The system then sorts through the list of nearby avatars, and sends a request for translation to one to 16 possible scripts. The maximum number of avatars that can be detected in Second Life is 16. This allows the maximum number of messages possible before HTTP throttling may occur. Each translation is queued to Google. Google performs the translation, and returns a JSON packet with the converted text. After JSON is decoded, the Unicode and special web characters are converted to Second Life format. Unicode was one of the more complex subroutines, and many other translators do not handle the umlauts, accents, and other special characters. For example, one of the Cadillac' translators cannot handle the \\u0027quote; code, which is a space! This translator properly decodes all Unicode characters. Arabic and Hebrew languages are flipped right to left. The final result is sent to the avatar privately along with your name. There is a system of pipelines, message queues and message ageing using time stamps, sizes, and ID numbers to keep track of all the avatars, translations and queues. Multi-strided lists are used extensively. The message queues are dynamically adjusted for error conditions, age, and size constraints. Mono-compiled scripts are limited to 64K bytes of code plus stack and heap. I split many functions into multiple scripts. For example, the quick arrival of 10 incoming messages from a gesture, each 1024 bytes long, has to be stored, translated, and compared to see if they are 'Spam', thus using up more than 1/3 of the total memory just for the raw incoming text! There is code to control the buffers and discard useless or untimely messages. Google may or may not translate a packet or a language, the web site may be down, or throw an error, and Second Life may discard packets without notice due to HTTP throttling. All of these events are handled gracefully. There are special queues for Instant Messaging and language specific announcements. A script converts the ISO language codes to plain text for the hover text display, and also keeps track of the ISO codes that Google uses. The Menu system has a system state controller in the main translator script that control all operations, and a Menu controller script that abstracts the language of the display from the internal script logic. If you type in another language, the language code is sent to the Menu controller. The message requests from 4 other scripts the language-specific Menu help text, the On button text, the Off button text, and the non-changing text. A pop up menu is then displayed on a randomly assigned channel to prevent interference with other scripts. The menu scripts alone contain 840 pre-translated items. In addition, there are many language specific messages that are generated and translated dynamically to any of the 42 languages.
|