Wayne Pan

I love the movement in the community as of late regarding front end engineers. PPK (of quirksmode.org fame) has been making great strides in by trying to establish an organization called Fronteers. Now, I just read that Yahoo! is doing something even more unprecedented… Yahoo! Juku. Essentially a training program for Fronteers to learn from the top people in the field and become a full time Yahoo! employee.Regardless of how Yahoo! is doing as a company, nobody can’t fault their contributions (yui, yslow, design patterns library, etc) in terms of web front end.

Joel had an interesting take on start ups…

The one thing that so many of today’s cute startups have in common is that all they have is a simple little Ruby-on-Rails Ajax site that has no barriers to entry and doesn’t solve any gnarly problems. So many of these companies feel insubstantial and fluffy, because, out of necessity (the whole company is three kids and an iguana), they haven’t solved anything difficult yet. Until they do, they won’t be solving problems for people. People pay for solutions to their problems.        

There’s been a lot of talk lately about a another bubble, and it definitely feels this way. Everybody is following in Facebook’s footsteps to be open. Even fighting each other to see who can out open each other (re: OpenSocial, Verizon’s Open Network, etc.)I was discussing with a friend about the whole Facebook Apps thing… Look at these two graphs of an app called Drink Recipes on Facebook (taken from adonomics.com)

Daily Active Users

Valuation

Someone explain to me how the valuation is an inverse relationship to active users? There’s also a third graph of installs, but it’s can’t be based off that can it? Active users can be synonymous to daily page views, which is how most sites base their valuations off of. The current valuation of Drink Recipes is $1.45m, mind boggling considering 3 kids an an iguana or two could have made it…. I guess the key is to be one of those kids (or maybe a RoR coding iguana?)

We’ve just soft launched admob.com in Japanese so I figured I’d jot down some thoughts that might useful for people wanting to undertake a similar effort. I’ll cover how to internationalize (i18n) just the language strings on your php site using Smarty and gettext. True i18n efforts include number/date formatting and handling foreign currency, but that’s not in the scope of this article.Preparation

• Get gettext up and running - gettext is a GNU project that has all the tools needed to make i18n easier. PHP has built in gettext support. It’s fairly easy to set up on an linux box once you figure out what set of commands you need to run to start installing locales.
• Separate of code and display - we use Smarty templating system so there is a clean break between our code and display. Many benefits to doing that this that I won’t cover here.
• Make a cut off for features - Unless you’re using in-house translators, decide which features/pages won’t make it into your initial release. You’ll have constant churn on your code base, features constantly making it to production, and PMs constantly wordsmithing your pages during this project. I suggest making an i18n branch of your code and merging non-UI changes over during the project. Then close to the date of your i18n launch, plan for another round of translation. If your company is not in a rapid release cycle, I’m not sure why you’re taking advice from me ;).
• Find a GOOD translation firm - Trust me. A good translation firm can go a long way in i18n efforts. At a minimum, they must understand basic HTML tags. I would recommend looking for firm that has translators that are experienced in whatever industry you’re in.

Extracting and Translate

• Wrap all strings - The first task you need to do is to wrap all your display strings in tags so that the gettext parser will be able to make a .po file. This is the bulk of the work as you have to run through every code /template file. Strings in PHP are wrapped in _() and strings in Smarty are wrapped in {t}{/t} tags. It’s best practice to keep punctuation inside the wrapping while leaving as many HTML tags outside. However, do not break up whole sentences this will confuse your translators.If you have any screenshots, pictures, or logos with embedded strings, prepare to break those up or replicate them localized. Also be prepared to do something about your strings in javascript. We made a simple framework for handling translations in php and outputting localized versions on the fly. The alternative is to generate local specific .js files using your build step.
• String extraction script - Spend sometime writing a shell script that you can run on your code branch that will pull out all the strings. The Smarty gettext package includes a script that will run through your template files and build a simple .c file. After that you will need to use xgettext -j to make one large .po file. The following script will do the trick../tsmarty2c.php ../code > smarty.cxgettext --no-wrap -j smarty.cfind ../code/. -iname "*.inc" -exec xgettext --no-wrap -j -L PHP {} \;find ../code/. -iname "*.php" -exec xgettext --no-wrap -j -L PHP {} \;
• Test and test again - After you have a .po file go ahead and fill in the translations with random garbage like some random Japanese characters. Make your .mo file then QA the hell out of your site. I guarantee that you will be missing some strings. You want to avoid having to send your strings off to be translated, only to have to send off another batch.
• Translate! - Send the .po file to the firm and wait. Also bake in sometime for linguistics QA with the same firm… If you have any native speakers in house, plan some time to sit down with them to make sure the translations you are getting back make sense.
• Launch - If you’re using Capistrano to deploy your site, prepare a script to deploy your branch. Keep in mind when there are changes to the .mo, it is highly recommended to restart apache.

Maintenance

• Make i18n low impact - once the initial launch has happened, you want the impact of maintaining it to be unobtrusive as possible. Everybody developing front-end features by now should be aware of _() and {t} tags, however try to avoid letting i18n impede development progress for your core site.
• Make a translation schedule - Set up a schedule with your translations firm so they plan for when they’re going to get a new batch of strings from you. This will lessen turn around times and enable you to launch features in other languages as quickly as possible

I hope this provided some insight into internationalizing your website. I know when we started on the project, there wasn’t much info to be found online. Web 2.0 isn’t English only and I hope everybody designs their site keeping in mind the world is flat. As always, feel free to leave any questions in the comments.

54Amazing how many HTML tags you forget when you’re under the gun.