I’ve been exploring localizing websites by learning how to write and manage static web content as well as learning various content management systems such as Drupal and WordPress. One of the most interesting things was localizing JavaScript for applications and websites, a process that involves finding the strings of text that need to be taken out and prepared for translation, and then imported back to the source. This process sounds complicated but there are a few methods, known as internationalization frameworks, that can make extracting and inserting translated strings an efficient process. One of the important reasons for learning this method is so that with a larger project, all the engineer needs to do is pull out the strings and prepare them to send to a translator which can then be put back in the right places.
I learned that one of the best ways to do this was using a very simple and easy to use framework called 24Ways. But for this project, we wanted to try out a different but somewhat similar framework called LocalePlanet. At first glance, LocalePlanet seemed fairly straightforward and easy to implement. But after a few hours of running this framework, we realized that the program the author uses to extract strings, called GNU gettext, is actually not an executable program (it turns out its actually a command line program), and appeared to be geared towards developers that needed to prepare translation files for software programs in development. With no clear getting started guides or documentation that could be understood with our level of knowledge, we decided to change directions and go back to using the 24Ways method which we were more familiar with.
I wouldn’t discredit LocalePlanet at all, but it is unfortunate that it involves understanding a program that isn’t user friendly (specifically it requires using a command line program that was not obvious at the time). Using 24Ways involves setting up a folder structure where we have a language folder containing our strings in the root where js and and a folder for where a copy of the game is placed that will be eventually translated.
One of the easy mistakes to make when considering folders and files is to not link the .js files correctly in the main index.html file. In the above image, we forgot to include a backslash indicating that the link is to a file a folder up in the directory, so it should have been ../ instead of just two dots.
When choosing the game that we wanted to localize, we wanted to find something simple that didn’t contain many strings or too many files. This is because we wanted to focus on implementing the internationalization framework, also abbreviated as i18n.
Most of the games that we downloaded and tested out actually only contained one simple HTML file that ran the JavaScript or CSS directly in the HTML using a script tag. We thought it would make more sense however to remove all the JavaScript from the HTML and just make a new file called game.js and link it to the HTML in the <head> since we already have a js folder which contains our 24Ways function. This also cleans up the HTML and cuts down the number of lines of code in the file we had to deal with.
In implementing the 24Ways function, each string is ‘wrapped’ like this: _(s) where s is the string. The tricky part is that some strings that contain single or double quotes may have to be removed when placed in the strings file, otherwise they won’t output correctly. In the game over string on line 33, we didn’t realize that we needed to remove the single quotes when copying it into our strings file.
This image below is what the string will look like after it is translated:
And here is a look at the game we localized:
