I've always had a bit of a love affair with books and magazines. The dog-eared pages, the smell of the ink, the crack of the spine – like receiving a handwritten letter in the mail, it's a tactile experience that is satisfying in terms of its rarity in our digital world. As a designer, I am never ashamed to judge a book by its cover, and I delight in the visual details, typographic and otherwise. But is print becoming an anomaly, or in the frightening words of The Simpsons, is the medium dying?

More and more often, people are turning to the web for information. Newspaper circulation is declining, and blogs are becoming the go-to avenue for unedited, collective conversation. The web has the power to reach the masses, fluidly and flexibly, via searchable and linkable content, and slick, experiential interfaces. In this media-rich world, where we are bombarded with images in an aggressive, almost subliminal way, the internet seems the only medium that can keep up. We seem to be refusing to settle for anything less than constant On-Demand content, where the dissemination of information is free and democratic.

But all this is not news. What is changing, however, is that larger companies have started to forego more traditional avenues in favor of the broad outreach of the internet. A project we just completed for an architecture firm, a flash New Years greeting, reached thousands of clients and contacts around the world in a matter of seconds. Flexible in its delivery, and dramatic in design, the digital card was a perfect solution for a company that prides itself in green practices. Large and small companies alike have an increasing need for a variety of avenues to reach their target audience, and "going digital" can help them reach a new demographic. Likewise, some magazines (like the recently-retired Punk Planet, and teen 'zines ElleGirl and Teen People) have made the switch from print to digital (either by choice or necessity), allowing for a constant influx of user-driven content, and a cost-effective approach to visual communication. Sites like Craigslist have rendered the Classified section of the newspaper useless, as the up-to-the-minute content of the online portal can't be challenged.

In the ever-changing digital realm, however, content is disposable. While a beautiful book, or a screenprinted poster, or a letterpressed card may remain in your office indefinitely, as items of contemplation or "objets d'art," digital content dies quickly and absolutely. This isn't necessarily a bad thing. The web's ethereal and expendable qualities force us to constantly evolve, to consistently revisit our intentions and to design for lasting impact.

I will always, unwaveringly, be a die-hard print addict. There's just nothing like coherent, well-edited, beautiful print pieces, where the grid is king, typography is queen, and CMYK is the official language. I will often advocate print collateral over web-based material – the physical and portable benefits of print (and our visceral reaction to it) are too important– but I may have selfish motives. It's a YouTube world now (or maybe it's a *shameless plug alert* Jackass World), and the limitless reach of the internet is too exciting to write off. Our time is becoming more and more valuable as the world changes rapidly around us, and it's our responsibility as members of the creative and technical communities to be at the forefront of this evolution. And, for the purposes of full disclosure, I get my news online. C'est la vie.

Installing and configuring the Globalize plugin can be difficult, but it usually goes easily if you follow the instructions. There's nothing I can say about that that's not thoroughly covered elsewhere. Adapting your coding style to use it is almost as easy as advertised.

But once you have it up and running there are a lot of subtle things that can still give you headaches down the line. For many of our international sites, the workflow is this:

• The client goes back and forth on designs, and we make a prototype like usual.
• Before getting started, we installed the Globalize plugin. Once we have the site roughed out and the design is approved, Globalize has automatically generated a list of the unique phrases in our app. (You might want to clear the translations table and re-test every page so your list doesn't include obsolete or phased out phrases).
• Then we hand the list to our client, who sends it to the team of translators, who send it back to us, and we slurp it into the database with a simple script (just loop through the languages and Locale.set, then Locale.set_translation)

That's technically all you need to do to globalize your app. But, if you want your application to be as scalable as possible—or you'd like to keep your developers from pulling their hair out—here are some tips.

• If at all possible, never translate phrases over 256 characters. If you do, you'll have to change globalize_translations.tr_key and and globalize_translations.text to a "text" field instead of a "string" (or varchar). That will work just fine, but, if you can avoid having to do that, it will really pay off to be able to add an index to tr_key and language_id.
• Make sure your validation messages are each translated individually, not en-masse in your view, or your translators will have extra work. That is, you want to avoid adding this to your translations table: "Errors: Name cannot be blank. Email address is not valid.", and instead have several seperate rows like this: "Errors:", "Name cannot be blank", "Email address is not valid" and so forth.
• You may have to turn off view caching in your environments/production.rb if you're running a mongrel cluster, or you might get spontaneous, random language changes as your users navigate the site! (change config.action_controller.perform_caching and config.cache_classes to "false")
• Don't stress too much about translating the word "Browse..." or "Choose File" on your file upload buttons- you can't change that! That's controlled by the user's browser, and it probably looks fine to them already.
• Lastly, here's a handy query for generating statistics on how many translations you've added to the system for each language:

SELECT english_name, COUNT(*) num_phrases 
FROM globalize_languages gl LEFT JOIN globalize_translations gt ON gl.id = gt.language_id
GROUP BY english_name ORDER BY english_name

• And this rake task will generate a spreadsheet-checklist of phrases that still require translation.
  translation_checklist.rake
  Copy it to your lib/tasks folder, and run it to, in this case, make a pipe-delimited checklist, without a column for "English".

rake skip_languages=English delimiter="|" db:translation_checklist > whatever_file.csv

While identifying a problem, I always keep the A.C.E model in mind. A.C.E stands for Assess, Contain, Eliminate. Let me explain how the A.C.E model works as a trouble-shooting tool for development testing, after the launch of a website.

A. Assess. Trace the site or application activity from the launch date to the day the problem first occurred. Use any original or back-up data that you have on hand and compare it to the client copy. If there is something that was added or taken out, find out why. It could be a simple solution if the problem stems from something environmental or technical. Find out if there have been any changes (major or minor) in the client’s capacity to host the site or application (i.e. switched hosting companies, bought a new server, etc.).

Also look for any irregularities or errors that would not have come up during testing—things like too many user requests (a common issue in commercial sites or sites for huge corporations). Let the client know that an application or site designed to handle 10,000 unique visitors may have trouble handling hundreds of thousands, since the requests to view and use the site will lead to denial of service.

It is prudent to look at the type of hardware in use to narrow down any problems before and after the launch. We test using the minimal requirements of a site, knowing that if it works using moderate to contemporary equipment, it will work with cutting edge server equipment. Once the problem has been assessed and identified, we move to the next stage.

C. Containment. Whether it’s a small programming bug or a major error, it is the responsibility of the tester to be candid to the client about the extent of the situation. There are numerous factors as to why the bug got past the testing phase, such as not enough testing time, launch was pushed ahead of schedule, or the like. But the fact of the matter is the problem exists, and it has to be dealt with.

A tester would be able to contain the problem and anticipate if the solution could accidentally cause another issue. In this case, the best course of action would be to not take the application or site offline, but to limit outside access to the resource. It wouldn’t make any sense to continue to grant access to something that, in the user’s mind, does not work.

At worst, the application or site would have to limit user access for a few days until everything is corrected and functional. It is in the client’s best interest to welcome user feedback, as this feedback could improve client interaction. Now that there is an understanding of the expectations and requirements of the client, this knowledge can be applied to the next project.

E. Elimination of issues can take many forms but the results are always the same: resolution of outstanding issues and client satisfaction. No matter what the cause, it is important to learn from the recent crisis (and believe me, to the client, it was a crisis). For the next project, the professional will remember the causes of the issue and can take a different approach. In turn, the client can plan ahead and adjust for extra testing and leeway in case of delays.

The goal of research and the A.C.E model is to make sure that anything we do as professionals is up to the standards of our clients. Anyone with the right training can make an application or website and make it look pretty. But a professional will take into account the client’s individual needs, user expectation, and the scalability of the end product.

This methodology and practice, as outlined above, has obvious benefits, such as limiting usage while testing and Q&A occurs, as well as setting client expectations for deployments and quality control throughout a project, as well as during those critical days after launch. The world of software, like many other technical fields, present its own core list of challenges and we aim to achieve the highest level of stability and consistency for the websites we build.