In the software world from which I come (I'm an alum of Microsoft and Expedia), we would think of internationalization along three dimensions: translation into a local language, localization to use local conventions, and functionality that varies by locale. I figured it might be worth a discussion of how MyFlightbook breaks down along these dimensions.
I'll talk about each of these in successive blog posts, starting here with the first: translation.
Translation is pretty straightforward, albeit very lightly implemented. While I know varying degrees of several languages, I'm essentially monolingual. The fact that English is the world-wide language of aviation certainly makes it easier for MyFlightbook to get away with being all English than for other software programs, but nevertheless I am rigorous about ensuring that all of the code - whether on the website or in the mobile apps - can be localized and is not tied to English, even if much of the time English happens to be the only available language.
In fact, thanks to a French-speaking user who did the initial translation (and Google Translate, which helped with subsequent translations, which might be humorous, but I wouldn't know...), the iOS and Android apps are entirely bi-lingual. If you set your iOS or Android device to use French, the MyFlightbook UI will appear in French.
It's not seamless, however: much of the text used in display does come from the server, and the server is only lightly translated. So if you are using French settings, you may still see English inserted in numerous places because that text derives from the database or from the web site (which only has a few pages translated.)
The key thing, though, is that the code is structured to be easily translated. Specifically, this means that all text is kept outside of the code and loaded (based on language) as it is needed. Keeping the text separate from the code makes translation easier, since a linguist can take a file with text in it and just go through and translate each item, without having to have any coding capabilities. And it means that new languages can be added simply by adding appropriate translated text files.
If anybody is interested in helping to translate the website, all of the text is separate from the code, so it's pretty straightforward to do. (It's just a lot of text...)
Supporting different languages actually goes beyond just translation, though, particularly since MyFlightbook *pilots* speak and use a huge variety of languages. Most of this is pretty transparent - the system uses Unicode so it can handle data in Kanji, Hindi, Hebrew, Arabic, etc. without any issues. The main thing that the code needs to handle here is right-to-left languages like Hebrew or Arabic and ensuring that the appropriate alignment occurs based on language (i.e., not hardcoding left or right alignment, but instead keying off of the language).
In my next post, I'll talk about localization.