Audio ![]() LingoHut also incorporates pronunciation into its learning system, making it necessary to store, essentially, a recording of every word for every language. Probably the easiest way to do this is to keep each audio word in a separate file. What format you store it in will depend on a few things, which we will discuss shortly. Each file name will then have to be tied to the appropriate language word which is selected. The most straight forward way, going back to our original very simple example of a word list would be to have a third entry on each line, which is the file name. For example: dog/Hund/deu_hund.wav. This works well for storing word pairs or individual words with keys, as well as a database. What might sound tempting to do, if you using keys, is to store in an array or file a list of all sound file names along with the key. That is a mistake because while the key links the same concept, like a dog, the words will be different in each language. You would have to expand the key with a prefix like the language code (in this case, deu for German), so the audio file name "Hund" might be stored as deu_1 and for Italian "cane" it would be ita_1. Whichever you do it, it would be vital to ensure that any changes to the words mean a change in some way to the audio. For example, if someone prefers to use der "Rüde", you can esaily change the text, but the audio will now also need to be updated. Besides saving each audio word as a single file, there are two other storage methods I have seen. The first is putting the sound data directly into the database along with the word. That requires an encoding of the raw sound data into something which can be stored safely as normal text. The plus side is you do not have hundreds or thousands of audio files stored on your system (something shared hosting services hate). However, depending on how long the audio is, this could also blow up the size of your database. The other method is a bit trickier and can really only be done when you have all sound files completed and they will not be changed again. If this is the case, you can join the recordings together into large chunks, keeping track for each one of while audio chunk it is on, along with how many seconds in it is and the duration. While it may seem silly to do this, consider teaching someone a sentence. If you have the single sentence recorded, you can also store the information for each word, thus playing any fragment of the sentence. Pimsleur uses a method of asking the learner to repeat each word separately, then as a whole sentence. If you store the audio information this way, you can have one longer file rather than several smaller ones. Now what kind of files you use really depends on a few different factors. The main issue is what can you get your browser to play back properly. In the past, coding playback has been tricky, dependent on creating sound objects and linking in players which may or may not work with all browsers. With the introduction of more sophisticated sound libraries and HTML5, playback has become more flexible and reliable. Then it becomes a question of which works best. Most people look for files to be stored as MP3 files (.mp3), but the common data format of choice has been Wave files (.wav). MP3s are normally more compact and sound better, but you may not have the ability to play them. I have found playing sounds on the internet to be one of the most constantly changing and at times frustrating things to work with, beaten out only by playing streaming audio or recorded video. Site Translation ![]() In the age of globalization, you really need to have your website in more than one language if you wish to reach the international community. Naturally, LingoHut has the ability to wrap itself in many languages. This is what gives it the full power it has in the ESL (English as a Second Language) section. But while it might seem like an obvious thing to do, the method of doing it may not. Most web pages are stored as static files which do not change. For those people, having a multilingual site means having a separate page for each language. This is a real problem when you need to change the way your site looks, as you now have dozens of copies to change. Some sites which do more interactive stuff will have the pages built using something like Python, Perl, or PHP, so they filled in differently as needed before being delivered to your browser. This means the proper translations can be added to a page with only one source, so changes are easy. If you want to keep your pages static and not use a program to build them, you can use Javascript and Ajax to load in the proper translations after the page has loaded. What this looks like is a formatted page full of data but no text, just little animated wheels showing something is loading. This can be a disaster if the person has disabled Javascript or you have another slow element loading, like a large picture, because the text loads last. Once you figure out how to load it in, if that is what you plan to do, you will need to decide how to store it, which, perhaps unsurprisingly, goes back to the first issue of storing the words. Both are really translations between two (or more) languages. So again, you might have a file with an English instruction followed by a German instruction on each line which you load in and then place whichever version you need in the right place, using a preloader like PHP or a postloader like Javascript / Ajax. Bonded Pair I have focused just on a few issues that I have had to tackle myself and I know went into LingoHut. I do not know how Philipp handled them, whether it was in one of the ways I described or in a totally different way I do not even know about. Kendal started her article in this issue talking about "two dreamers" who came together to build something for everyone. To me, they represent how we need both the dreamers and the engineers to make things happen. This pair of dreamers is in a dataset all their own. |
The Technical Secrets of LingoHut, Maybe | |||
Writer: | Erik Zidowecki | ||
Images: | |||
|
All images are Copyright - CC BY-SA (Creative Commons Share Alike) by their respective owners, except for Petey, which is Public Domain (PD) or unless otherwise noted.